In my previous post, I stated that EEM has these Event Detectors which are used to catch the events and then trigger policies which you have created.  So the ability to do anything with EEM relies greatly upon the detectors themselves.  After all, if you want to be able to do something (with a policy), you have to be able to detect the trigger.  It would be a little like having a policy to open the door for someone when they arrived at your doorstep.  The policy would be opening the door but without the ability to detect whether or not someone was at your door, you’d have a hard time.  The detector in this case, determining whether or not someone was at your door, is critical to the entire operation.  Such is the case with the EEM event detectors.  So what are they?  These are the list of event detectors supported by the various versions of Cisco IOS.

So what are these and what can they do?  Here’s a brief comment about each one but I’ll talk about each one in depth in future posts. Some of them are more common than others.  For example, I done think that many people use the GOLD ED but Syslog and CLI are extremely popular.

Syslog – Monitors the syslog messages sent by the device.  You can use this to match using a regular expression and act accordingly.

CLI – This ED is used everytime a CLI command is issued by a user.  What’s great about this ED is that you can configure it so that you can suspend the CLI command that the user issued until the completion of the policy.  This means that you can use your policy to disallow access to that CLI command.

Timer – This ED is used to setup a countdown (and stop) timer, a countdown (and restart counting down) timer, a specific time,  or a recurring interval timer.  The coundown (and stop) timer acts like a kitchen egg timer.  After a specific number of seconds, the EEM server fires off the associated policy.  The timer is NOT restarted with this timer. There is atimer that does support that type of functionality.  In essence, it counts down, fires off the policy and starts counting down again.  So the end result is, you can have something fire every 42 seconds, for example.   Third, there is a specific time timer which fires off at a specific time, say, August 23, 2009 at 9:03am.  The fun with this one is that you have to configure the time in number of seconds past midnight January 1, 1970.  (Use an online conversion utility like this one).  Finally, there’s a timer which behaves just like the UNIX cron utility (or Cisco’s Kron).

None – This ED is not triggered by any event that happens within IOS.  It is used to be triggered by hand or by another script.

SNMP – This ED polls a specific OID.  The value can then be processed and a policy can act accordingly.

Interface – This ED is used to process the interface counters which can be seen when you type ’show interface’.  There are 22 some odd counters that can be monitored with this ED.

Counter – Along with the None ED, this is another detector that can be used to trigger another policy.  The counter is a value that can be manipulated from within the policies and referenced by other policies.  For instance, you can have one policy update the counter and have another policy (which uses the counter ED) rely upon the counter value set previously to trigger.

Watchdog/WD System Monitor - These two EDs monitor the CPU and memory within the device.  The Watchdog ED is used for non-modular code and the WD System Monitor is used on the new modular code.  This is handy when you are concerned about processes using too much CPU or memory.

OIR (Online Insertion and Removal) – This ED triggers upon the insertion and removal of cards.  For example, if a line card in a 6500 chassis was removed and replaced, this ED would trigger.

Application Specific – This ED is used by a policy to publish an event which can then be used to trigger another event.

Generic Online Diagnostic (GOLD) - The Generic Online Diagnostic (GOLD) is a framework for diagnotics which is currently implemented in some Cisco IOS products.  It is designed to help detect hardware problems that can occur on devices.  The results of these tests can be captured using the GOLD ED.

Resource – Cisco has a feature which allows a more in-depth view of the allocation of resources such as CPU, memory and buffers called the Embedded Resource Manager.  This utility is able to generate events such that they can be captured by the Resource ED.

Redundancy Framework -The Redundancy Framework is a feature which provides high availablity to various Cisco devices, such as the Cisco 6500 series switches.  It is one of the elements that allows the device to support NSF/SSO functionality.  The redundancy framework generates events which can be detected by the redundancy framework ED.

Enhanced Object Tracking – Yes, the vary same feature that allows you to track IP SLA statistics, routes, track lists, etc.  These events can be detected by the Enhanced Object Tracking ED.

EEM-RPC – This event detector can accept SOAP commands over SSHv2.  The commands are formatted as XML code which tell the event detector to fire off an EEM policy.

SNMP Notification – This event detector can detect SNMP trap messages which are sent to the device.  This allows the ability to peform an action (through a policy) in response to an SNMP trap detected from another system

NetFlow – Supports Flexible NetFlow which allows the detection of various flow attributes such as the destination IP address or port number.  It also allows the detection of flow rate so the ED can trigger if the flow rate exceeds a specific threshold.

IP SLAs – This event detector supports the IP SLA functionality that is available within IOS.  It allows the detection of changes in the failing or meeting of a programmed SLA.

Routing – Allows the detection of Routing Information Base (RIB) events such as the addition, remove or modification of a route.

Custom CLI – Allows the creation of custom CLI commands which allow the addtion of special characters such as ‘?’ or ‘Enter’.

Cisco’s Embedded Event Manager is probably the most under-utilized ability of the Cisco IOS.  It has been available for sometime time and is built into almost all modern IOS based products.  Notice that I stated IOS based, this excludes ASA, PIX, and some of the more esoteric Cisco products.  But it is available on switches and routers (including the XR line).  Here’s how it works:

In the normal operations of the switch or router, events happen all the time.  These events can be someone issuing a CLI command, a syslog message, an SNMP trap, etc.    As these things happen, they can be detected by the EEM Event Detectors, which are running all the time in the background.  The Event Detectors send their information to the EEM server. Here’s a picture from the Cisco website

The EEM server can then be programmed to fire off an EEM policy.  The policy is what you can program.  Currently there are two different types of polices:  applets and Tool Command Language (Tcl) scripts.  These applets and Tcl scripts can be programmed to do all sorts of fun things.  They can send syslog messages, SNMP traps, fire off e-mails, even open raw sockets.  That’s right, you read it right, you can open raw sockets! If you’re not familiar with Tcl, get familar.  It’s a lot like Perl and Python just a new syntax but it has them same power.   Let that soak it, you have a script interpreter built into your router!

Think about the power you have now.  You can program your router to detect the user typing a specific CLI command, stop them, and fire off an e-mail in response.  You can capture the MAC address table every five minutes, detect any changes, and syslog it off. To get a better feeling about what people are doing out there, check out the Cisco Beyond page.

I plan on writing a lot about this in the future so expect Tcl scripts, applets, discussions about how to all sorts of things.  Let me know if there’s something you’d like to see.