Generating syslog alarms for RTR/IP SLA probes

From Internetworkpro

This page or section provides device configuration instructions Please note that the information on this page has not been checked for accuracy and is not intended as a replacement to documentation. Please ensure you understand your desired objectives before attempting to apply any examples listed. See more examples at Category:Configuration

Well, rmon was developed for such purposes. But rmon cannot track every OID, generate subsequent alarms or pay attention to other conditions you want to include for such alarms.

For such scenarios, the IOS embedded event manager (EEM) comes to the rescue.

I explain this on an alering scenario for IP SLA probes, which do not have log message capability.

First define your probe:

rtr 1
 type echo protocol ipIcmpEcho 10.1.3.1
 frequency 30

This probe will send ICMP echo requests every 30 seconds to the host 10.1.3.1

Then create an event manager applet

event manager applet rtr_probe_fail
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.1 get-type exact entry-op eq entry-val 1 exit-op eq exit-val 2 poll-interval 5
 action 1.0 syslog priority critical msg "RTR probe failed"

This tells the event managet to query the Timeout property OID within the RTT definition. The event manager will poll the OID every 5 seconds. If a timeout happened, a syslog message is generated.

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.3.6.1.4.1.9.9.42.1.2.9.1.6

If you want to be notified when the probe becomes successful again (no Timeout), add another applet:

event manager applet rtr_probe_alive
 event snmp oid 1.3.6.1.4.1.9.9.42.1.2.9.1.6.1 get-type exact entry-op eq entry-val 2 exit-op eq exit-val 1 poll-interval 5
 action 1.0 syslog priority critical msg "RTR probe recovered"

This applet does the same as the previous one, except that it queries for the opposite values.

Now, schedule your probe:

rtr schedule 1 life forever start-time now

and you're set.

Of course, you can extend this functionality to almost all types of OID a router provides. Furtermore, aditional logs can be fired with subsequent action lines:

 action 1.1 ...

There are various actions available, syslog, trap, reloading and sending an email :)