Traps Not Received At Spectrum End

[Legacy User]

Hi All,

 

I have Spectrum 10.x configured in my environment. Its a common issue which turns up in all Spectrum release.

 

Issue:- 

The trap is sent from the device end, but its not getting received at Spectrum end.

How do we troubleshoot later , why wasn't the trap received, whereas trap was received at another source of tool.

 

Has someone come across the same scenario ?

[ackjo04]

Guneet,

 

If the issue is reproducible on demand, the easiest way to trouble shoot is to start a sniffer on the SpectroSERVER system where the trap is being sent and verify if the trap even reached the SpectroSERVER system or not. If not, then the issue is somewhere in the network.

 

If the trap is received by the SpectroSERVER system but not being processed on the Spectrum model as expected, then examining the trap contents may give us a clue.

 

If the contents look good, then examine how the trap is configured in Spectrum.

 

If the issue is not reproducible on demand, then start the sniffer on the SpectroSERVER system only sniffing on the trap port Spectrum is configured to listen to. That way you are not sniffing all traffic. Then, when the issue occurs, check the as noted above.

 

Joe

[Legacy User]

Hi Joe,

 

Can we have the sniffer running continuously on Spectrum Server, filtered at port 162,without impacting its performance ?

[ackjo04]

Running the sniffer should have no impact on Spectrum. The biggest impact you may have is if you do not filter for and save only the trap packets (port 162) the sniffer file can grow quite large very quickly. So, ensure the sniffer is setup to only capture trap packets.

 

Joe

[Frank Tonjes]

In my experience - on a Linux host, if the OS can see the trap with tcpdump, Spectrum will also always see it,

 

On a linux box you can run (as root)

 

tcpdump -i <interface> dup port 162 and src <IP ADDRESS>

 

This will display all traps coming in from that IP address.

 

There are also options to capture the dump in a wireshark friendly format for analysis from another machine.

 

Regards,

Frank

[sirha02]

Hi Guneet,

 

It would also be worth to check the process SpectroSERVER.exe is listening on Port 162. Assuming the SpectroSERVER is running on Windows, from the command prompt, run the below command to redirect the output to filename check_ports:

 

netstat -abn > check_ports.txt

 

Now run the below command to open the file created

 

check_ports.txt

 

Verify in the file check_ports.txt, the process SpectroSERVER.exe is listening on port 162. If there is some other process/service other than SpectroSERVER.exe listening on port 162, stop that process/service. Restart the SpectroSERVER.exe, run the above commands again to verity SpectroSERVER.exe is listening on port 162.

 

Hope the above helps

 

 

[Legacy User]

Thanks For the response Sirha02.

The Spectroserver is running on port 162. It is not a regular issue.

Some of the traps are dropped. I cant troubleshoot why the trap was not received or processed at Spectrum end.

Whereas its received at other monitoring tools end.

[sirha02]

Hi Guneet,

 

No problem, you could try Joe's suggestion. Am not sure with regards to impact on SpectroSERVER Performance 

 

Best Regards,

Hamza Sirajuddin

[PhucsiNGUYEN]

You can also send an udp packet with netcat (command : nc -u). If your SpectroServer gets that packet,it means there's a firewall is blocking your flow. Just a reminder, udp doesn't have hand shake so maybe your link or midle devices dropped that trap snmp packet.