Building network automation solutions

9 module online course

Start now!

Category: EEM

Changing configuration with EEM – yes or no?

Daniel left a very relevant comment to my convoluted BGP session shutdown solution:

What I am currently doing is using EEM to watch my tracked objects and then issuing a neighbor shutdown command. Is there a functional reason I would not want to do it that way, and use the method you prescribe?

As always, the answer is “it depends.” In this case, the question to ask yourself is: “do I track configuration changes and react to them?

read more see 7 comments

Shut Down BGP Session Based on Tracked Object

In responses to my The Road to Complex Designs is Paved With Great Recipes post Daniel suggested shutting down EBGP session if your BGP router cannot reach the DMZ firewall and Cristoph guessed that it might be done without changing the router configuration with the neighbor fall-over route-map BGP configuration command. He was sort-of right, but the solution is slightly more convoluted than he imagined.

read more see 13 comments

Monitor multiple interfaces with a single EEM applet

Michael modified one of my EEM applets to monitor CRC errors on WAN interfaces and notify the operator (via e-mail) when an interface has more than two errors per minute. He wanted to monitor multiple interfaces and asked me whether it’s possible to modify the SNMP event detector somehow. I only had to point him to the event correlation feature of EEM version 2.4 and he sent me the following (tested) applet a few days later.

read more see 8 comments

Router reload after 15 minutes of failed pings

Jeroen sent me an interesting challenge: he would like to reload the router when the 3G WAN interface gets stuck (I thought my Nokia phone is the only one exhibiting this problem, but obviously I was wrong). The reload-on-failed-ping EEM applet I’ve published would be a perfect solution, but it uses track delay and the maximum delay timeout is three minutes, while Jeroen would like to wait 15 minutes before reloading the router.

read more see 16 comments

EEM QA: what were they (not) doing?

When I was writing the applet that should stop accidental scheduled router reloads, I wanted to use the action string match command to perform pattern matching on the output of the show reload command. Somehow the applet didn’t want to work as expected, so I checked the documentation on Cisco’s web site.

Reading the command description, I should have realized the whole thing must be broken. It looks like the documentation writer was fast asleep; even someone with a major in classical philosophy and zero exposure to networking should be able to spot the glaring logical inconsistencies.

read more see 5 comments

Stop accidental scheduled router reloads

Alexandra Stanovska wrote an excellent comment to my Schedule reload before configuring the router post:

It may come in handy creating some form of script that would display some basic upon logout - show debug, show reload etc.

The new capabilities of CLI event detector introduced in EEM 3.0 allow us to catch CLI commands in a particular parser mode. Writing an EEM applet that catches exec-mode exit or logout and performs a few checks is thus a trivial task.

read more see 1 comments

Time-Based Static Routes

Before someone accuses me of being totally FCoE/DCB-focused, here’s an interesting EEM trick. Damian wanted to have time-dependent static routes to ensure expensive backup path is only established during the working hours. I told him to use cron with EEM to modify router configuration (and obviously lost him in the acronym forest)... but there’s an even better solution: use reliable static routing and modify just the track object’s state with EEM.

read more see 5 comments

Bug in EEM SNMP event detector

Jared Valentine found an interesting bug in the EEM’s SNMP event detector: if you’re triggering your EEM applet when the increment of an SNMP variable exceeds the threshold, you cannot re-arm the applet; the exit-type increment does not work. He fixed the problem with a somewhat more convoluted approach:

  • The first EEM applet reads the SNMP variable, waits a second, does a second read and stores the difference in a counter.
  • The second EEM applet is triggered based on the counter values.

I’m collecting tips like this one in the Embedded Event Manager (EEM) workshop. You can attend an online version of the workshop; we can also organize a dedicated event for your networking team.

Here’s the source code for the first applet (he had to execute CLI show commands to work around the CB-QoS MIB limitations).

read more see 1 comments

Update: workaround for sluggish CB-QoS MIB

More than a year ago, I wrote about the very slow update rate of the variables in the CB-QoS MIB. In August WB found a workaround (do a show policy-map interface before reading the counters) and now Jared has tested it and confirmed that it works. He’s configured a simple EEM applet that executes the show command once per second:

event manager applet UpdateMibTables 
event timer watchdog time 1
action 1.0 cli command "enable"
action 2.0 cli command "show policy-map int dialer0"

With this fix, he can use the SNMP variables in other EEM applets to detect VoIP calls within 1-2 seconds.

Don’t forget: numerous EEM topics are described in the Embedded Event Manager (EEM) workshop. You can attend an online version of the workshop; we can also organize a dedicated event for your networking team.

see 2 comments

Send a SNMP trap from an EEM applet

The engineer who wanted to detect specific DoS attack (WAN link overload) with EEM applet asked for something more in his original question: he wanted to receive a SNMP trap on the NMS when the DoS attack is detected. Implementing this requirement with an EEM applet is simple; you just need to add the trap keyword to the event manager applet configuration command.

EEM-SNMP integration is described in the Embedded Event Manager (EEM) workshop. You can attend an online version of the workshop; we can also organize a dedicated event for your networking team.

read more see 1 comments

Detect short bursts with EEM

Last week I’ve described how you can use EEM to detect long-term interface congestion which could indicate denial-of-service attack. The mechanism I’ve used (the averaged interface load) is pretty slow; using the lowest possible value for the load-interval (30 seconds) it takes almost a minute to detect a DOS attack (see below).

If you want to detect outbound bursts, you can do better: you can monitor the increase in the number of output drops over a short period of time.

read more see 3 comments

Detect DoS Attacks with EEM

Someone sent me an interesting question a while ago: “is it possible to detect DOS flooding with an EEM applet?” Of course it is (assuming the DOS attack results in very high load on the Internet-facing interface) and the best option is the EEM interface event detector.

Detecting interface overload with EEM

Detecting interface overload with EEM

The interface event detector is more user-friendly than the SNMP event detector. You can specify interface name and parameter name in the interface event detector; with SNMP event detector you have to specify SNMP object identifier (OID). The interface event detector stores the interface name, measured parameter name and its value in three convenient environment variables that you can use to generate syslog messages or alert the operators via e-mail.

read more see 5 comments