One of my readers has to deal with a crappy Network Termination Equipment (NTE)1 that does not drop local link carrier2 when the remote link fails. Here’s the original ASCII art describing the topology:
He’d like to use interface SNMP counters on the firewall to detect the PE-NTE link failure. He’s using static default route toward PE on FW, and tried to detect the link failure with ifOutDiscards counter.
During the Campus Evolution with Cat9K presentation (I hope I got it right - the whole event was an absolute overload) the presenter mentioned the benefits of brand-new model-driven telemetry, which immediately caused me to put my academic hat on and state that we had model-driven telemetry for at least 30 years.
Don’t believe me? Have you ever looked at an SNMP MIB description? Did it look like random prose to you or did it seem to have some internal structure?
One of my readers decided to build a large DMVPN network with BGP as the WAN routing protocol (good choice!) and configured BGP SNMP traps with snmp-server enable traps bgp command on the hub router to detect spoke router failures. Turns out that’s not exactly a good idea.
Brian Christopher Raaen asked a great question in a comment to my OpenStack/Quantum SDN-Based Virtual Networks post:
Other than some syntax difference what do these new HTTP-based APIs add that SNMP couldn’t already do?
Short answer: In theory nothing, apart from familiarity and convenient programming libraries. In practice, there’s a huge gap between theory and practice. See “Hands-on experience” at the bottom of the article.
The engineer who wanted to detect specific DoS attack (WAN link overload) with EEM applet asked for something more in his original question: he wanted to receive a SNMP trap on the NMS when the DoS attack is detected. Implementing this requirement with an EEM applet is simple; you just need to add the trap keyword to the event manager applet configuration command.
EEM-SNMP integration is described in the Embedded Event Manager (EEM) workshop. You can attend an online version of the workshop; we can also organize a dedicated event for your networking team.
If you use multiple SNMP servers in your network, you might want to limit the traps each server receives. Configuring this functionality is easy: just list the traps you want a server to receive at the end of the snmp-server host configuration command.
When you specify the list of SNMP trap types a server should receive, a trap is sent to the server only if it’s listed in the snmp-server host command and enabled with the snmp-server enable traps command.
IOS can generate numerous SNMP traps, but you have to enable most of them manually. Configuring a server that receives SNMP traps with the snmp-server host address community traps is not enough; you have to enable individual trap categories with the snmp-server enable traps group [ trap ] command.
In older releases, the standard SNMP traps (for example, link up/down traps) are enabled by default and cannot be disabled with the snmp-server enable traps command. Newer IOS releases have added the snmp-server enable traps snmp [ authentication | coldstart | linkdown | linkup | warmstart ] global configuration command. These releases require you to enable standard SNMP traps manually; otherwise the router will not generate them.
If you want to see the whole list, configure snmp-server enable traps and execute show running | include snmp-server enable. IOS 12.4T network management reference guide also includes a comprehensive list of all options.