IP SLA + Embedded Event Manager

Imagine the task - there is an office connected to 2m different ISPs via a router from Cisco and you need to provide a backup service.

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


At once I want to make a reservation - this solution is not positioned as a kind of panacea or the only true for the problem. This is just one of the views on the problem, which additionally gives an initial overview of the Cisco IOS mechanisms - IP Service Level Agreements and Embedded Event Manager .
')
IP Service Level Agreements
The IP SLA mechanism performs a simple function — it measures critical IP network parameters for various applications (including multimedia): latency, 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 is a mechanism for reacting to various events (events) occurring with a device. Examples of events are the appearance of a specific message in the logging buffer, a command entered into the CLI, SNMP trap, an event generated by the IP SLA subsystem, and much more. You can handle these events in 2 ways - applet (written directly to the IOS CLI) or script (written in TCL and loaded into the router). Thus, EEM is a very flexible mechanism for extending the functionality of the router - relatively speaking, the number of application options is limited only by your imagination and programming skills.

How will these 2 mechanisms help in our case? Very simple - IP SLA will use icmp (in this case, it is not necessary to set up the responder) check the availability of any Internet resource and, if it is unavailable, generate an event that we will process using EEM. In this example, I simply change the default route to another provider, but you can make more complex configuration changes — change ACLs, NAT rules, and so on.

Necessary note - to process events from IP SLA, EEM v3.0 is required (starting with IOS 12.4 (22) T).

Test Topology:

CPE is a router installed in the office where all the described configurations will be performed. ISP1 and ISP2 - providers routers. For simplicity, they are configured NAT.

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
 ip sla enable reaction-alerts

In this piece of the config, we create 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 to the results of the sla monitor, in this case, the event timeout ( react time 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 preloaded (for example, with tftp) TCL scripts are saved and install ipsla.tcl as a custom event handler.

You can check the installed scripts for event handling using 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 that executes all the logic:

1. :: cisco :: eem :: event_register_ipsla operation_id 1
3. # import EEM symbols
4. namespace import :: cisco :: eem ::
5. namespace import :: cisco :: lib ::
7. # getting EEM environment data
8. array set evtData [ event_reqinfo ]
9. set evt_cond $ evtData ( condition )
11. if {$ evt_cond == "Cleared"} {
12. action_syslog msg "IPSLA condition cleared"
13. exit 0 0
14. }
16. # log message
17. action_syslog msg "IPSLA condition occured, changing default route to another ISP"
19. # ope Cisco CLI
20. if {[catch {cli_open} result ] } {
21. puts stderr "CLI OPEN failed ($ result)"
22. exit 0 0
23. }
25. array set cfd $ result
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
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"
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"
43. catch {cli_close $ cfd (fd) $ cfd (tty_id)}
44. exit 0 0

There is no particular disassembling of the line by line, therefore I will only note the principal points. Line 1 - sets the type of event being processed, in our case, just IP SLA number 1 ( operation_id 1 ). Lines 4-5 enable the use of TCL extensions built into the router (for example, action_syslog for logging). At 11-14, we check the event condition parameter, this is necessary, since the IP SLA event is generated 2 times - when the event has occurred (Occured) and when it has 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 explanations - everything is clear from the comments. Also, for use in real conditions, it is necessary to add error handling to the script (as in lines 20-23, for example), here I omitted it for convenience of perception.

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

UPD: moved to the Cisco community