cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1415
Views
10
Helpful
8
Replies

SNMP switch link status traps

rsgamage1
Level 3
Level 3

There's a 3560 switch running RSTP and it has two up-link ports , one obviously is in Forwarding state whereas the other is in Blocking state. SNMP traps need to be captured for both linkup/down events. Is it possible to capture traps corresponding to STP Forwarding status changes?

If the Forwarding link goes down will the event trap be buffered and sent via new the up-link, once STP is converged?

Thanks for the clarification.

8 Replies 8

Joe Clarke
Cisco Employee
Cisco Employee

You can enable BRIDGE-MIB traps with:

snmp-server enable traps bridge topologychange

That will cause the switch to send the topologyChange trap whenever a port transitions from the learning state to the forwarding state, or the forwarding state to the blocking state. You might also want to enable the newroot trap as well.

Thanks for the comment.My interest is mainly in linkup/linkdown traps.

snmp-server enable traps snmp authentication linkdown linkup coldstart

Isn't it possible to receive link status traps under the circumstances described?

Your question specifically mentioned STP state transitions. If you want linkup/down traps, the command you just mentioned will work. To enable/disable them on specific interfaces, use the interface command:

[no] snmp trap link-status

Yes, my scenario is related to STP transitions however I'm interested in linkup/down traps.

The following question is about the STP forwarding link in particular.

If the Forwarding link goes down will the event trap be buffered and sent via new the up-link, once STP is converged?

No, the trap will be dropped. UDP is connectionless, so it will be fired, then forgotten. If you need some reliability, consider using informs instead.

Question of UDP comes only if the trap is attempted to be forwarded via the failed link. What if the switch buffers this trap and sends via the new up-link port(ex-blocking) after STP convergence?

I performed a few tests using RSTP to see that the linkdown traps are sent consistently irrespective of the STP role of the port. (However, when 802.1d is used I lost all the linkdown traps, which ,according to my understanding, was caused by the convergence delay)

Does it imply that my argument of buffer management holds true? Or is it just a coincidence? Could you also confirm this based on your experience?

My experience has been that with reconverging networks (i.e. boot time, STP events, etc.) that trap reliability drops off dramatically. I don't know all the details on your config or topology, but I do know that if reliability of traps is important, informs are the way to go. This way, there is more of a guarantee that the manager will see the notification.

Thanks for the point on SNMP inform notifications and also for sharing your experiences.