Is There a Way to Determine Why Traps Are Not Showing In Spectrum?
If a device is sending traps to the SpectroSERVER and the user is not seeing them in OneClick, you can send a debug action to the SpectroSERVER to toggle runtime tracing of alerts. Incoming alerts can either be traced by IP address, a matching trap OID prefix or even all alerts without any filtering. The SpectroSERVER will print messages to the <SPECROOT>/SS/VNM.OUT file whenever an alert is received and will also give details about how the alert is handled. If an event is generated for the alert the event code and model handle will be printed as well.
To add an alert trace item, send the following action to the VNM model: 0x10245
Example, via CLI: ./update action=0x10245 mh=<VNM_Model_Handle>
The action to stop the trace is: 0x10246
Both actions will take up to two optional parameters, where you can specify the IP and/or trap OID to trace. The trace types are identified by the attribute ID, with ID '0' signifying an OID trace (trap OID must start with the debug OID to be traced), and ID '1' specifying an IP address (all traps having that IP will be traced). Both options can be used together, which will then trace a specific OID (or a set starting with the debug OID) for a specific device. More general options (e.g. trace all traps from IP X) will supersede less general ones (trace only trap A from IP X).
Examples: E.g. to turn on all debug you would use:
./update action=0x10245 mh=<VNM mh>
To turn on debug for alert 126.96.36.199.188.8.131.52:
./update action=0x10245 mh=<VNM mh> index=0,attr=0,type=0x12,val=184.108.40.206.220.127.116.11
To turn off debug for IP 10.10.5.1:
./update action=0x10246 mh=<VNM mh> index=0,attr=1,type=0x13,val=10.10.5.1
To turn on debug only for alert OID 18.104.22.168.4.11.1 and IP 22.214.171.124:
./update action=0x10245 mh=<VNM mh> index=0,attr=0,type=0x12,val=126.96.36.199.4.11.1 index=1,attr=1,type=0x13,val=188.8.131.52
If this debug does not show the trap that is being sent from the device, we would recommend that you start a sniffer trace on the SpectroSERVER and reproduce the issue. Once complete, please feel free to open a CA Support Ticket and we would be glad to review the packet data.