We went through a long exercise a couple of years ago to analyse what TrapEXPLODER did with v1, v2c and v3 traps. We never managed to get TX to forward SNMPv3 traps correctly. There's some CA documentation which talks about "blind forwarding" - this is all it can do because TX is not able to decrypt the SNMPv3 traps and read the contents. However this resulted in the resulting alarm in Spectrum being posted against the server running TX and not the device sending the trap.
To get around this limitation we have had to configure managed devices to send traps directly to Spectrum directly, bypassing TX. In our environment we have TX listening on UDP/162 on each SpectroSERVER and Spectrum listening on UDP/1692. So any SNMPv3 devices are configured to send traps to UDP/1692. This isn't ideal as we then require customer firewalls/ACLs to be changed to allow traffic through on this non-standard port.
Another discovery we made was that SNMPv3 informs would not processed correctly either. We never got to the root cause of this so we always insist on devices being configured for SNMPv3 traps.
------------------------------
Solution Designer
KCOM Group PLC
------------------------------
Original Message:
Sent: 08-19-2019 06:07 PM
From: Patrick Murtey
Subject: Trap Exploder and Spectrum receiving v3 traps
Hi All,
We are finally making the move to SNMPv3 on our network equipment. We have modeled devices in Spectrum with the V3 profiles just fine, but I have concerns about receiving and forwarding of v3 traps. We have the eHealth Trapexploder and have been forwarding v1,v2 traps to our Distributed Spectrum environment for years successfully. Can someone tell me what the best way to configure our current trapexploder to Spectrum integration so we continue to utilize this configuration successfully.
TIA