Embedded Event Manager is a feature of the Cisco IOS operating system that allows you to write handlers for various system events. The core of EEM is a special process known as an EEM server that acts as a middleware agent between event detectors and EEM event subscribers. There is a fixed number of event detectors that post an event when a programmed condition is met.
CLI event detector – detects various commands typed in CLI based on regular expression matching
Syslog event detector – responds to various syslog strings, allowing for matching on regular expressions just like CLI detector
Interface counter – responds to various interface’s counters crossing threshold settings
Counter – responds to the change of value of a generic system counter
SNMP – monitors
None –a special case of event detector triggered when a user issues the command "event manager run" to execute a named EEM script/applet
Watchdog – generates periodic timer events and allows the EEM script to be run at repeating time intervals
The other parts of the EEM system—event subscribers—are defined and registered with the EEM server as either EEM applets or scripts. Applets are simple programs written using a very basic set of CLI commands that start with an action keyword. Scripts are special TCL scripts written to handle EEM events. The applets are easy to write and powerful enough to perform many functions including CLI commands, email sending, SNMP/Syslog message generation, and implementing basic program logic (such as branching or computations).
Every EEM applet has a name and a detector condition defined to trigger the applet. The applet may access global variables defined using the command event manager environment or the parameters passed to them by an event detector. There are predefined environment variables accessible to the EEM scripts, specific to every event detector.You may also list the variables for an event detector using the command show event manager detector <NAME> detailed. Every applet definition starts with a group of event commands that specify the event detector and the condition to trigger the applet. Normally there is only one event defined for an applet. If you define multiple events, you must further specify how they co-relate to each other
event manager applet INTERFACE_LOAD
event tag 1 interface name Serial0/0/0 parameter rxload entry-op gt entry-val 153 entry-type value poll-interval 30
action 0.0 cli command "enable"
action 1.0 cli command "conf t"
action 2.0 cli command "interface Serial 0/0/0"
action 3.0 cli command "ip access-group CRITICAL_TRAFFIC in"
action 4.0 mail server "155.1.146.100" to "noc@INE.com" from "r5@INE.com" subject "Interface Alert" body "Interface ...
Register the applet with the “none” event detector to be able to run the applet from the CLI for “dry-run” testing purposes. Enable EEM debugging commands to track the CLI and E-Mail actions and run the applet manually first.
event manager applet INTERFACE_LOAD
event tag 2.0 none
Rack1R5#debug event manager action cli
Rack1R5#event manager run INTERFACE_LOAD
EEM Scripting - Syslog Events
---------------------------------------
event manager applet INTERFACE_SHUTDOWN
event tag 1.0 syslog pattern "Interface GigabitEthernet1.*changed.*down"
action 1.0 cli command "enable"
action 2.0 cli command "conf t"
action 3.0 cli command "interface GigabitEthernet1"
action 4.0 cli command "no shutdown"
action 5.0 cli command "end"
action 6.0 cli command "show users"
EEM Scripting: CLI Events
----------------------------------
The CLI event detector allows for monitoring certain CLI patterns and publishes an event if a match occurs. The event monitoring configuration could use the parameter sync set to either “yes” or “no” to define a synchronous or asynchronous applet. When the applet event condition is synchronous, the EEM server will hold the matched CLI command execution until the script terminates. The script should return an exit value in the variable $_exit_status , and this will determine whether the triggered command will run (status 1) or not (status 0). Asynchronous event handlers will let the CLI command execute and the event will be posted after that. The script cannot affect the command execution. Notice that asynchronous CLI events require a set of additional parameters, such as number of occurrences and the time window for the occurrences. Another command we use in the script below is the puts action. It allows you to display arbitrary text on the console, provided that the script is synchronous.
event manager applet SHOW_RUN_FILTER
event tag 1.0 cli pattern "show run" sync yes
action 1.0 cli command "enable"
action 2.0 cli command "show run | exclude username"
action 3.0 puts $_cli_result
!
! Exit status of 0 block execution of the original command
!
action 4.0 set $_exit_status 0
R5#show event manager policy registered event-type cli
EEM Scripting: Periodic Scheduling
-----------------------------------------------
Event applets may be configured to respond to periodic or timed events—for example, to fire every time interval or start at a fixed time in the future.
event manager applet SHOW_RUN_EVERY_5MIN
event tag 1.0 timer watchdog time 300
!
! We use write term as we intercepted show runin the previous task
!
action 1.0 cli command "enable"
action 2.0 cli command "write term"
action 3.0 syslog msg "Configuration Saved"
DHCP Relay
------------
DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero . Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!) A switch with DHCP Snooping enabled will drop packets on untrusted ports that contain Option 82 or have a non-zero giaddr (e.g. 0.0.0.0).
just a couple of sub-options, namely the “remote-id” (option ID 0×2) and the “circuit-id” (ID 0×01). Those two are supposed to identify the remote device and the port where the DHCP request was received.
the giaddr is used in DHCP relay scenarios to indicate which pool/subnet the DHCP server should assign the address from.
Option 82 is used in provider networks to give extra information to the DHCP server regarding where a device is located.
we have two options:
1. Tell the switch not to set Option 82
no ip dhcp snooping information option
2. Tell the router to ignore Option 82
ip dhcp relay information trust-all --This command instructs the DHCP server that blank giaddr is acceptable, even if option 82 is set.
