Lets take a took at events detectors today
Allows any EEM policy to publish an event. This provides the ability for one policy to trigger another policy.
There will be two events say EventA and EventB. EventA defines an action to publish event with subsystem value of 798 and any type of event.
The subsystem value of 798 specifies that a publish event has occurred from an EEM policy. The second policy EventB is triggered when EventA occurs with subsystem 798.
An argument can be passed from EventA to EventB.
Below is an example of event application. Here EventA is triggered every 20 seconds and when reliability of interface Gi1 is 255. When both these conditions are met, EventA will send a syslog msg and publish the event with sub-system 798, event type 1 and arg1 as value of reliability.
EventB will run when EventA has published the event and will use the argument passed from EventA.
Below are the details for detector application. Four arguments can be passed from EventA and can be called in EventB using _application_data1/2/3/4.
2. CLI event
Event CLI pattern will match on a command run by a user and will be triggered based on the event. It uses a regular expression to match a command and fully expanded commands are matched.
Even if short form of command is matched, the IOS will expand it first and then match it with the cli.
The cli event operates in 3 modes:
- CLI command is executed after policy ran and exits
- The variable _exit_status will determine that cli needs to be executed or not:
- 0- Skip cmd
- 1- run cmd
event cli pattern <> sync yes
Below is an example to print any cli command entered by user and then execute the command as we have set the exit status to 1.
Lets now change the exit status to 1. As soon as I came out of EEM config mode, I could not run any command.
No output of show run and even reload command dint work. To come out of this situation I had to reload the router, as config was not saved. So be cautious while using “sync yes skip yes”
** This EEM can also be used for accounting logs with exit_status 1.
- Event is published and cmd is run
event cli pattern <> sync no skip no
– Asynchronous with command skipping
- Event is published and cmd is not run
event cli pattern <> sync no skip yes
*Key note: Character “\x3f” is used in place of ? , and this will be encoded as ? only.
- Publishes an event when a named counter crosses the defined threshold
In the below example, we have configured two events:
Event Counter: This will be triggered whenever “sh.* ip you.*” (* means anything) matches in the cli entered and an action is defined to increment the value of counter named “COUNT” by 1.
Event CounterA: CounterA is using counter as detector and will be trigged when the value of COUNT is between 3 to 6.
Now lets run the cli “sh ip rou”. In the first 3 occurrences, only Event Counter was triggered and on 4th occurrence , we can see Event CounterA being triggered.
We are using builtin “_counter_value” to return the value of counter COUNT.
4. GOLD: Generic online diagnostic
The EEM is triggered when GOLD failure event occurs when monitoring one or more cards and optional subcards
I cannot simulate this on virtual device. However, below is the example from Cisco documentation guide:
Router(config)# event manager applet gold-match
Router(config-applet)# event gold card all subcard all new-failure true
Router(config-applet)# action 1.0 syslog msg “A GOLD failure event has occurred”
- The EEM is triggered when the counter for parameter being monitored for an interface crosses a threshold.
- Threshold can be an absolute or incremental value
- Counter can be reset after an elapsed time or when ‘exit value’ is crossed
Below are the parameters which can be monitored with interface detector. In Application detector, we used reliability. Lets now use the interface resets.
We are going the remove OSPF configuration from interface , it interface Gi1 flaps more than once.
Below is the interface config and OSPF neighborship.
Bounced the interface and the counter for interface resets incremented by one.
On the second flap, EEM is triggered and removed the OSPF from interface Gi1.
6. IOSwdSysmon: Watchdog System Monitor
The EEM run on the basis of Cisco IOS system monitor counters crossing a threshold. It is basically used for monitoring CPU and memory tasks.
As the name suggests, an EEM will run when an IP SLA operation is triggered. Below is the sample config for ipsla to track the interface Gi0/4/0 using icmp-echo. Once sea goes down, event will be triggered and EEM runs.
Made the link shut on other end and EEM ran with syslog message specific in action. Here I am making use of builtin $_ipsla_dest_ip_addr
Event detector neighbor-discovery is used to run EEM when a Cisco Discovery Protocol (CDP) or Link Layer Discovery Protocol (LLDP) cache entry changes or a interface link status changes.
On R1, we have 2 cdp neighbors to R3 and R5. Lets monitor the CDP on Gi1 towards R3.
We can monitor all cdp events including add, delete and update.
Below are the builtins for CDP and LLDP.
Lets ask device to print a message whenever cdp event occurs on Gi1 and it should tell what type of event , on which interface and neighbor name, issue occurred.
I did shut the interface on R3 and then unshut it. We can see we have logs for delete and add respectively.
Event none is used to manually run the EEM without any events specified. The command to manually run an EEM is “event manager run Event-Name”
Here I have two events, one with ipsla event and another with none.
The event IPSLA cannot be run manually as its not registered with none Event detector.
To be continued…
- Embedded Event Manager (EEM) – Basic Overview- Part I
- Embedded Event Manager (EEM) – Event Detectors- Part II
- Embedded Event Manager (EEM) – Event Detectors- Part III
- Embedded Event Manager (EEM) – Event Actions- Part IV