SNMP - sending traps to specific hosts

This was an issue I ran into awhile ago. I was trying to send BGP traps to one host, and PIM traps to another. As you can see below, BGP traps were getting sent to both hosts when I used version 1.

When I had version 2c specified, traps were only sent to the host configured for BGP. I do not know if this is difference in the protocol, but it is something you may want to be aware of if you need to send traps to different hosts.

Version 1, traps get sent to both hosts:

R1#sho run | inc snmp
snmp-server enable traps bgp
snmp-server enable traps pim
snmp-server host 2.2.2.2 public  bgp
snmp-server host 3.3.3.3 public  pim

R1#clear ip bgp *
R1#
00:11:49: %BGP-5-ADJCHANGE: neighbor 172.12.14.4 Down User reset
00:11:49: SNMP: Queuing packet to 2.2.2.2
 00:11:49: SNMP: V1 Trap, ent bgp, addr 172.12.12.1, gentrap 6, spectrap 2 
 bgpPeerEntry.14.172.12.14.4 = 00 00  
 bgpPeerEntry.2.172.12.14.4 = 1
00:11:49: SNMP: Queuing packet to 3.3.3.3
00:11:49: SNMP: V1 Trap, ent bgp, addr 172.12.13.1, gentrap 6, spectrap 2 
  bgpPeerEntry.14.172.12.14.4 = 00 00  
 bgpPeerEntry.2.172.12.14.4 = 1
00:11:49: SNMP: Packet sent via UDP to 2.2.2.2
00:11:49: SNMP: Packet sent via UDP to 3.3.3.3

Version 2c, traps get sent to one as desired:

R1#sho run | inc snmp
snmp-server enable traps bgp
snmp-server enable traps pim
snmp-server host 2.2.2.2 version 2c public  bgp
snmp-server host 3.3.3.3 version 2c public  pim

R1#clear ip bgp *
R1#
00:13:09: %BGP-5-ADJCHANGE: neighbor 172.12.14.4 Down User reset
R1#
00:13:09: SNMP: Queuing packet to 2.2.2.2
00:13:09: SNMP: V2 Trap, reqid 21, errstat 0, erridx 0 
 sysUpTime.0 = 78967 
  snmpTrapOID.0 = bgpTraps.2 
 bgpPeerEntry.14.172.12.14.4 = 00 00  
 bgpPeerEntry.2.172.12.14.4 = 1
00:13:09: SNMP: Packet sent via UDP to 2.2.2.2
R1#

Sending Logs as SNMP Traps

I have been reading Chapter 9 of Routing TCP/IP Vol. II this week. It has a good overview of the non-core topics such as snmp, rmon, ntp, etc. I recommend it for anyone struggling with these topics or just wanting a concise review.

This example shows how to configure a router to send logs to an snmp-server and verify it.

The first thing you must do is configure a server. Without this, you want be able to see any debugging because the router won't send any packet out.

R8(config)#snmp-server host 4.4.4.4 public syslog
R8(config)#snmp-server enable traps syslog
R8(config)#logging console warnings
R8(config)#logging buffered 16384 debugging

I have also decided to buffer the logs instead of send them to the console. This is not required just a way to keep everything less cluttered on the console screen. What this configuration does is buffer all log messages of debugging level or lower. Then these messages are sent via SNMP to the server at 4.4.4.4. Let's debug snmp packets, then a quick shutting/no shutting of an interface will give us some messages to view:

R8#debug snmp packets
SNMP packet debugging is on

R8(config)#int f0/0
R8(config-if)#no snmp trap link-status
R8(config-if)#shut
R8(config-if)#no shut

R8#sho logging | beg Log Buffer
Log Buffer (16384 bytes):

*Mar 2 18:33:38.565: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 2 18:33:40.117: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 192.168.8.8 on interface FastEthernet0/0 (vrf default)
*Mar 2 18:33:40.641: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
*Mar 2 18:33:40.669: SNMP: Queuing packet to 4.4.4.4
*Mar 2 18:33:40.669: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 192.168.78.8, gentrap 6, spectrap 1
clogHistoryEntry.2.58 = LINK
clogHistoryEntry.3.58 = 4
clogHistoryEntry.4.58 = UPDOWN
clogHistoryEntry.5.58 = Interface FastEthernet0/0, changed state to up
clogHistoryEntry.6.58 = 15322065
*Mar 2 18:33:40.921: SNMP: Packet sent via UDP to 4.4.4.4
*Mar 2 18:33:42.513: %SYS-5-CONFIG_I: Configured from console by console

I disabled snmp trap link-status to show that we are not using this feature to send traps. Notice the entry labeled clogHistoryEntry.5.58, this is exactly the same message as our logging message a few lines up. We only get linkup messages with this basic config.

To modify the configuration we use the logging history command:

R8(config)#logging history ?
<0-7> Logging severity level
alerts Immediate action needed (severity=1)
critical Critical conditions (severity=2)
debugging Debugging messages (severity=7)
emergencies System is unusable (severity=0)
errors Error conditions (severity=3)
informational Informational messages (severity=6)
notifications Normal but significant conditions (severity=5)
size Set history table size
warnings Warning conditions (severity=4

R8(config)#logging history size 2

Here I set the history size to 2 so I am able to view the last 2 messages sent with the following command:

R8#sho logging history
Syslog History Table:2 maximum table entries,
saving level notifications or higher
149 messages ignored, 11 dropped, 0 recursion drops
57 table entries flushed
SNMP notifications enabled, 45 notifications sent
entry number 58 : LINK-3-UPDOWN
Interface FastEthernet0/0, changed state to up
timestamp: 15322065
entry number 59 : SYS-5-CONFIG_I
Configured from console by console
timestamp: 15345618

Pretty basic scenario. It is important to remember this is different from the usual way of sending linkup/linkdown traps. Here, we are not using "snmp-server enable traps snmp linkup linkdown" or the interface command "snmp trap link-status".

Also, I think I figured out why linkdowns are not being sent, if I manually configure the logging level to "notifications" it works:

R8(config)#logging history notifications
R8(config)#int f0/0
R8(config-if)#shut

R8#sho logging

*Mar 2 18:46:38.885: SNMP: Packet sent via UDP to 4.4.4.4
*Mar 2 18:46:39.981: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to administratively down
*Mar 2 18:46:40.057: SNMP: Queuing packet to 4.4.4.4
*Mar 2 18:46:40.061: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 192.168.78.8, gentrap 6, spectrap 1
clogHistoryEntry.2.72 = LINK
clogHistoryEntry.3.72 = 6
clogHistoryEntry.4.72 = CHANGED
clogHistoryEntry.5.72 = Interface FastEthernet0/0, changed state to administratively down
clogHistoryEntry.6.72 = 15399999
*Mar 2 18:46:40.309: SNMP: Packet sent via UDP to 4.4.4.4
*Mar 2 18:46:40.981: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/0, changed state to down
*Mar 2 18:46:41.033: SNMP: Queuing packet to 4.4.4.4
*Mar 2 18:46:41.033: SNMP: V1 Trap, ent ciscoSyslogMIB.2, addr 192.168.78.8, gentrap 6, spectrap 1
clogHistoryEntry.2.73 = LINEPROTO
clogHistoryEntry.3.73 = 6
clogHistoryEntry.4.73 = UPDOWN
clogHistoryEntry.5.73 = Line protocol on Interface FastEthernet0/0, changed state to down
clogHistoryEntry.6.73 = 15400099

Not sure why I needed that because according to the "show logging history", notifications were the default level. However, it appears they aren't because the command shows up in the config:

R8#sho run | inc logging his
logging history size 2
logging history notifications
R8#

Multicast Heartbeat - Generating SNMP Traps

This was a topic I ran into while browsing the multicast configuration guide today. I had dynamips up and running so I created a small lab.

Topology:

R1---R2---R5---R7

R1 is sending traffic to 225.0.0.7
R2 is the BSR/RP
R5 is will be configured for hearbeat
R7 has "ip igmp join-group 225.0.0.7" on one of its interfaces.

The commands to enable multicast heartbeat are very simple:

R5(config)#snmp-server host 9.9.9.9 traps public ipmulticast
R5(config)#snmp-server enable traps ipmulticast

R5(config)#ip multicast heartbeat 225.0.0.7 ?
<1-100> Minimal number of intervals where the heartbeats must be seen

R5(config)#ip multicast heartbeat 225.0.0.7 1 ?
<1-100> Number of intervals to monitor for heartbeat

R5(config)#ip multicast heartbeat 225.0.0.7 1 2 ?
<10-3600> Length of intervals in seconds

R5(config)#ip multicast heartbeat 225.0.0.7 1 2 10
R5(config)#

You will see this message:

R5#
*Mar 1 00:29:58.523: MHBEAT(0): Unless packets sent to 225.0.0.7 are seen in 1 out of 2 intervals of 10 seconds, an SNMP trap may be emitted.

Let's debug SNMP packets and the heartbeat so we can see the trap:

R5#debug snmp packets
SNMP packet debugging is on
R5#debug ip mhbeat
IP multicast heartbeat debugging is on

Now on R1 start sending packets, then stop:

R1#ping 225.0.0.7 re 2

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 225.0.0.7, timeout is 2 seconds:

Reply to request 0 from 150.100.56.7, 160 ms
Reply to request 1 from 150.100.56.7, 148 ms
R1#

Let's check R5. After a short while we see the following:

*Mar 1 00:38:48.555: MHBEAT(0): SNMP Trap for missing heartbeat
*Mar 1 00:38:48.575: SNMP: Queuing packet to 9.9.9.9
*Mar 1 00:38:48.575: SNMP: V1 Trap, ent ciscoExperiment.2.3.1, addr 150.100.56.5, gentrap 6, spectrap 1
ciscoIpMRouteHeartBeatEntry.2.225.0.0.7 = 0.0.0.0
ciscoIpMRouteHeartBeatEntry.3.225.0.0.7 = 10
ciscoIpMRouteHeartBeatEntry.4.225.0.0.7 = 2
ciscoIpMRouteHeartBeatEntry.5.225.0.0.7 = 0
*Mar 1 00:38:48.827: SNMP: Packet sent via UDP to 9.9.9.9

For reference, here is the link to the DocCD:

IP Multicast Heartbeat