While troubleshooting issues with Cisco Prime Infrastructure (CPI) 1.3 and snmp trap alarms, I was introduced to using tcpdump on our CPI server to figure out if it was actually getting the snmp trap that we weren’t getting notifications on. Below is a very basic tutorial for those who may find it useful. Depending on the type of trap you are troubleshooting, you may need a maintenance window to test it. For me, it was IPSLA up–>down status messages that CPI wasn’t alarming on. To test this, I had to start the packet capture on CPI then shut down the edge interface to our ISP to see if the IPSLA actually triggered the trap and the switch sent it to CPI.
ssh to your CPI instance with the admin user
[sdewndr@jumpbox ~]$ ssh admin@prime
Gain root access (if you have not set this up yet read THIS article first)
PRIME/admin#root
Enter root patch password :
Starting root bash shell ...
ade #
Switch to superuser
ade # su -
[root@PRIME ~]#
Since this isn’t really a tutorial on tcpdump (not that I could write one anyway) I’m not going to get into too much detail about the following command. I will go over it briefly however and what each switch is used for. Do your own research on other possible options. The syntax provided by TAC was:
[root@PRIME ~]#tcpdump -vv "host 192.168.1.1 and port 162" -i eth0 -s0 -w ipsla.pcapng
- -vv: more verbose capture
- “host x.x.x.x and port xxx”: must be in quotes, the IP address of the trap sender and port CPI is expecting to receive it on
- -i eth0: -i is interface and eth0 is the interface CPI is using
- -s0: save the whole packet, do not limit how many bytes per packet are saved
- -w: write the packet capture to a file so we can export it
- ipsla.pcapng: the file name you are writing too (file must end with .pcapng or .pcap depending on Wireshark version)
You can stop the capture by simply pressing control -c on your keyboard. I suggest you try the command on your CPI server to make sure you don’t get any syntax errors before actually triggering your trap. If there are no syntax errors, trigger the trap and you should see the counter increment if the trap is being received by CPI. To make sure CPI is also getting “alarm clear” trap, make sure you reverse whatever you did to trigger the trap. For instance, if you wanted to make sure you get a trap when an interface goes down – shut down the interface and then bring it back up. You should get two packets, once you have them both use cntrl C to end the capture and then we can transfer the capture off CPI to view in Wireshark.
[root@PRIME ~]#scp ipsla.pcapng username@10.1.1.252:/dir/dir/etc...
If this posts answers your question or is helpful, please consider rating it and/or marking as answered.
If this posts answers your question or is helpful, please consider rating it and/or marking as answered.
