IP SLA + Embedded Event Manager

Imagine the problem - there is an office connected to 2 different Internet providers via a router from Cisco and you need to provide service redundancy.

There can be several solutions (2 static routes by default, dynamic routing, etc.), but there are always restrictions for their use. For example, 2 static routes by default will perform the task only if the line protocol on the interface crashes towards the provider.


I want to make a reservation right away - this solution is not positioned as a panacea or the only right one for the task. This is just one way of looking at the problem, additionally giving an initial idea of ​​the Cisco IOS mechanisms - IP Service Level Agreements and Embedded Event Manager .

IP Service Level Agreements
IP SLA mechanism performs a simple function - measuring critical for various applications (including multimedia) IP network parameters: delay, jitter, resource availability, etc. The architecture is simple and transparent - for measuring parameters between 2 devices on the network (in our case, Cisco routers), one of the devices generates measurement requests (sla monitor), and the second responds to them (sla responder).

Embedded Event Manager
EEM - a mechanism that allows you to respond to various events (events) occurring with the device. Examples of events are the appearance of a specific message in the logging buffer, the command entered in the CLI, SNMP trap, the event generated by the IP SLA subsystem, and much more. These events can be handled in 2 ways - applet (written directly into the IOS CLI) or script (written to TCL and loaded into the router). Thus, EEM is a very flexible mechanism for expanding the functionality of the router - relatively speaking, the number of applications is limited only by your imagination and programming skills.

How do these 2 mechanisms help in our case? It’s very simple - IP SLA will use icmp (in this case, you do not need to configure sla responder) to check the availability of an Internet resource and if it is unavailable, generate an event that we will process using EEM. In the above example, I just change the default route to another provider, but you can make more complex changes to the configuration - change the ACL, NAT rules, and more.

A necessary note - in order to process events from IP SLAs, EEM v3.0 is required (starting from IOS 12.4 (22) T).

Test topology:

CPE - a router installed in the office, on which all the described configurations will be performed. ISP1 and ISP2 are provider routers. For simplicity, NAT is configured on them.

SLA Configuration:

ip sla 1
 icmp-echo 10.0.0.1
 frequency 30
ip sla schedule 1 life forever start-time now
ip sla reaction-configuration 1 react timeout threshold-type immediate action-type triggerOnly
ip sla enable reaction-alerts

In this piece of the config, we create a sla monitor at number 1, which will send icmp requests to 10.0.0.1 every 30 seconds ( frequency 30 ), starting from the current moment ( start-time now ) and constantly ( life forever ). The next 2 lines set the reaction according to the results of the sla monitor, in this case, the generation of an event by timeout ( react timeout threshold-type immediate action-type triggerOnly ).

EEM Configuration:

event manager directory user policy "disk0: /"
event manager policy ipsla.tcl type user

Everything is transparent here - we set the directory where the TCL scripts previously loaded (for example with tftp) are saved and set ipsla.tcl as a custom event handler.

You can check the installed scripts for event processing with the show event manager policy registered command :

No. Class Type Event Type Trap Time Registered Name
1 script user ipsla Off Mon Oct 12 22:04:00 2009 ipsla.tcl
 operation-id {1}
 nice 0 queue-priority normal maxrun 20.000 scheduler rp_primary

TCL script executing all the logic:

1. :: cisco :: eem :: event_register_ipsla operation_id 1
2.  
3. # import EEM symbols
4. namespace import :: cisco :: eem ::
5. namespace import :: cisco :: lib ::
6.  
7. # getting EEM environment data
8. array set evtData [event_reqinfo]
9. set evt_cond $ evtData (condition)
10.  
11. if {$ evt_cond == "Cleared"} {
12.    action_syslog msg "IPSLA condition cleared"
13.    exit 0 0
14. }
15.  
16. # log message
17. action_syslog msg "IPSLA condition occured, changing default route to another ISP"
18.  
19. # ope Cisco CLI
20. if {[catch {cli_open} result]} {
21.    puts stderr "CLI OPEN failed ($ result)"
22.    exit 0 0
23. }
24.  
25. array set cfd $ result
26.  
27. # get default route and put gateway ip address to $ ip_nexthop
28. catch {cli_exec $ cfd (fd) "sh ip route 0.0.0.0 0.0.0.0 | inc \\\ *"} result
29. regexp {[0-9] + \. [0-9] + \. [0-9] + \. [0-9] +} $ result ip_nexthop
30.  
31. # delete current default route
32. cli_exec $ cfd (fd) "enable"
33. cli_exec $ cfd (fd) "configure terminal"
34. cli_exec $ cfd (fd) "no ip route 0.0.0.0 0.0.0.0"
35.  
36. # set default route via another ISP
37. switch $ ip_nexthop {
38.    192.168.0.6 {cli_exec $ cfd (fd) "ip route 0.0.0.0 0.0.0.0 192.168.0.2"}
39.    192.168.0.2 {cli_exec $ cfd (fd) "ip route 0.0.0.0 0.0.0.0 192.168.0.6"}
40. }
41. cli_exec $ cfd (fd) "end"
42.  
43. catch {cli_close $ cfd (fd) $ cfd (tty_id)}
44. exit 0 0
45.  

There is no particular sense in line-by-line, therefore, I note only the principal points. Line 1 - specifies the type of event being processed, in our case, just IP SLA with number 1 ( operation_id 1 ). Lines 4-5 make it possible to use the TCL extensions built into the router (for example, action_syslogfor logging). In 11-14 we check the event condition parameter, this is necessary, since the IP SLA event is generated 2 times - when the event was completed (Occured) and when it was cleared (Cleared). In our case, the routing needs to be changed only when the event occurred and 10.0.0.1 became unavailable. The remaining lines of the script, it seems to me, do not need additional clarifications - everything is clear from the comments. Also, for use in real conditions, it is necessary to add error handling to the script (as for example in lines 20-23), here I omitted this for convenience.

I hope this small example gives an initial idea of ​​IP SLA and EEM, as well as the potential use of these mechanisms.

UPD: migrated to the Cisco community