Cisco IP SLA monitoring

Cisco IP SLA monitoring

Description

This plugin checks for the status of IP SLA probes configured on Cisco routers.

IP SLAs can be configured as follows on routers (tested on IOS 12.4T):

! Ping probe example ! (target must be another Cisco box configured as IP SLA responder) ip sla 1 icmp-jitter 10.10.10.10 tag PING frequency 300

! Jitter probe example ! (target must be another Cisco box configured as IP SLA responder) ip sla 2 udp-jitter 10.10.10.10 5000 tag JITTER frequency 300   ! VoIP G729a probe example ! (target must be another Cisco box configured as IP SLA responder) ip sla 3 udp-jitter 10.10.10.10 5000 codec g729a tag VOIP frequency 300

! DNS probe example ip sla 4 dns www.google.com name-server 8.8.8.8 tag DNS frequency 300

! HTTP probe example

ip sla 5 http get http://www.google.com/ name-server 8.8.8.8 cache disable tag HTTP frequency 300

Notes

You may also want to configure some thresholds to make the probe fail when it takes too long for instance. This is quite important because this Nagios plugin will not accept warning and critical boundaries. These should be configured on the IP SLA itself. This plugin only checks the return status of such IP SLAs and it succeeds only when IP SLAs succeed on the remote router. In other words, this plugin checks if the configured IP SLA is met or not.

Modes

Single SLA mode

In this mode you specify which IP SLA you want to check (identified by Tag). The plugin will then connect to the router using SNMP (v2c for now), make sure that there's an IP SLA configured that corresponds to the supplied Tag, retrieve some probe specific information and report its status back to Nagios (including probe specific performance data).

Pros & Cons:       + granular monitoring of IP SLAs       + probe specific status information & perf data       - less scalable; possibly many IP SLA services per router   Example 1:

$ ./check_cisco_ipsla.pl -H 10.10.10.10 -c public -i DNS

IP SLA 4 # DNS ( dns probe to www.google.com ) status: OK | RTT=41;Query=www.google.com   Example 2:

$ ./check_cisco_ipsla.pl -H 10.10.10.10 -c public -i HTTP

IP SLA 5 # HTTP ( http probe to http://www.google.com/ ) status: OK | DNS=2;TCP=3;HTTP=4;Total=9;Query=http://www.google.com/

Multi SLA mode

In this mode you specify the keyword "ALL" as IP SLA tag (i.e. "-i ALL" on command line). The plugin will then connect to the router using SNMP (v2c for now), list all configured IP SLAs, retrieve their status, and report all that information back to Nagios. If only one IP SLA fails, the whole Nagios service will fail. Also, the plugin will report the completion time of all IP SLAs configured in the performace data section. In this mode the plugin generates a multi-line output.

Pros & Cons:

     - no granular monitoring of IP SLAs      - no probe specific status information & perf data      + scalable; only one IP SLA service per router

Example 3:

$ ./check_cisco_ipsla.pl -H 10.10.10.10 -c public -i ALL

IP SLA status: OK | Total-Time=469 IP SLA 1 # PING_London ( icmp-jitter ) status: OK IP SLA 2 # JITTER_Tokyo ( udp-jitter ) status: OK IP SLA 3 # VOIP_NewYork ( udp-jitter g729a ) status: OK IP SLA 4 # DNS_Paris ( dns ) status: OK IP SLA 5 # HTTP_Google ( http ) status: OK | PING_London=18 JITTER_Tokyo=250 VOIP_NewYork=106 DNS_Paris=32 HTTP_Google=81 Version 0.1:

Changelog

New features:

  • First public release
  • Single SLA mode + Multi SLA mode
  • Support for HTTP probe
  • Support for DNS probe
  • Support for VOIP/g729a probe
  • Support for ICMP probe
  • Support for Jitter probe

Todo list:

  • P1:Add support for all remaining probe types
  • P2:Better error reporting
  • P2:Clean Perl programming
  • P3:Evaluate perf data from plugin (warning+critical thresholds)
  • P4:Dynamically set & run probes without prior router config

Known bugs:  - BUG0001: supplying a wrong SNMP community string makes the plugin always succeed!  - BUG0002: in multi SLA mode, an empty line is displayed after the 1st one