This article will explain how a spoof SNMP trap can generate to verify that the traps are being received at the trap viewer after configuration of the traps.
Traps are only generate when there is an event on the chassis.
In an initial configuration or when there is change in the target knob for sending the traps there will be a need to test and see how the traps are being received at the viewer.
The knob that we can use to generate spoof traps is the following and it is executed in operational mode. keep in mind that that all the snmp/trap configuration needs to be done and there must be network reachability to the trap viewer.
kvillegas@Contrabando> request snmp spoof-trap ?
Possible completions:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | <trap> The name of the trap to spoof adslAtucInitFailureTrap adslAtucPerfESsThreshTrap adslAtucPerfLofsThreshTrap adslAtucPerfLolsThreshTrap adslAtucPerfLossThreshTrap adslAtucPerfLprsThreshTrap adslAtucRateChangeTrap adslAturPerfESsThreshTrap adslAturPerfLofsThreshTrap adslAturPerfLossThreshTrap adslAturPerfLprsThreshTrap adslAturRateChangeTrap alarmActiveState (Long output, it was cut) |
Using this knob, we can generate traps to test the SNMP configuration, otherwise a technical will need to be at the site and generate a trap for example removing a FRU.
There is the possibility to create variables to send to the NSM, using “variable-bindings”, this knob will allow us to add in specific into the trap message which will
help in testing the trap viewer, for example,
1 | > request snmp spoof-trap linkdown variable-bindings "ifIndex[ge-0/1/0.0] = ge-0/1/0.0, ifAdminStatus[ge-0/1/0.0] = 2, ifOperStatus[ge-0/1/0.0] = 2" |
