Cisco IOS Embedded Event Manager (EEM)

Lessons Discussion
41

Hi Laz
Thank you for your replay
My issue is: I have a bunch of ASR901 routers, and a lot of them got stuck, when it goes stuck , the ospf protocol goes down and i lost the connection
in addition I can not login to router and i can not do any thing
even by console .
to fix this issue i have to go to field and restart the router
so that is why i am looking for EEM command
when routers go down and all line protocol of interfaces go down
it will reload automatically
and no need to visit the field

for example i am doing now EEM command for one interface
but now i want for all interface in same time :

event manager applet OSPF_DOWN 
 event syslog pattern "Nbr 192.168.12.1 on FastEthernet0/0 from FULL to DOWN"
 action 1.0 reload

can you help
and if you have better solution can you guide us
thank you .

42

Hello Ridhwan

Yes, I understand your difficulty. The primary issue here is the connectivity you need to log in remotely so you can avoid having to go out into the field and restart the router. Can you create a script that tests IP connectivity with your main site? Or with the IP address of the device through which you are connecting remotely? That way you are only testing a single element rather than the line protocol going down on all interfaces.

You can use ping to test IP connectivity to an address at your main site just to confirm that connectivity is active. As soon as this is lost, for whatever reason, the device will reboot.

Now whether or not you will want to do this depends upon how often this takes place, and how many devices depend upon this particular router for connectivity. Also, if connectivity with your main site or your admin PC is lost, does that mean that all connectivity is lost, and if so, is it still OK to reboot the device? You may want to examine and weigh these issues as well to make your decision as to what event you want to cause the reboot to take place.

Finally, concerning the problem itself, you should determine what is causing this issue and resolve it. The EEM script to reboot the device should only be a temporary solution.

Let us know how you get along!

I hope this has been helpful!

Laz

43

A post was merged into an existing topic: IP SLA and EEM Script

44

I’m trying to understand the different sync and skip options. In this lesson it says “The “sync yes” parameter is required. This tells EEM to run the script before running the show run command”. However in these notes it says this “The sync yes keywords will cause the EEM script and the CLI command to be run simultaneously”. https://notes.networklessons.com/eem-sync-and-skip-keywords

Any type of clarification would be appreciated.

thank you,

Chase

45

Hello Chase

The confusion seems to come from the use of the word “simultaneously.” A better word to be used would probably be “synchronously”. I’ve made the change in the NetworkLessons note. In the context of EEM, the “sync yes” parameter does not mean that the EEM script and the CLI command will run at the exact same time.

What it actually means is that when a CLI command that triggers an EEM applet is entered, the EEM applet will start executing immediately without waiting for the CLI command to finish. However, the CLI command will not be executed until the EEM script has finished running. So, they are not running at the exact same time, but the EEM script starts running immediately when the CLI command is entered.

On the other hand, if you use “sync no”, the EEM script will not start running until the CLI command has finished executing.

This is why the lesson says “The ‘sync yes’ parameter is required. This tells EEM to run the script before running the show run command”. It’s a bit of a simplification, but it captures the essential point: with “sync yes”, the EEM script starts running immediately and the CLI command waits for it to finish.

Ultimately, I would suggest you experiment with the various options to see the behavior on a real or simulated device. It’s the best way to really understand deeply how these keywords affect the behavior of the EEM script and the related CLI commands.

I hope this has been helpful!

Laz

1 Like
46

Much appreciated Laz! Thank you for all that you guys do!

1 Like
47

What’s the difference between an exit code of 0 and 1? Thanks

48

Hello Nicholas

The exit status variable is used to represent either a successful exit or a failed exit from the applet. An exit status of 0 represents a successful exit status. A non-zero value like “1” represents a failed exit status.

Exit status values can range from 0 to 255. Typically, the values of the exit status will be either 0 or 1 to represent success or failure. However, values 2-255 can be used to specify specific reasons for a failure. By default these are not used, but you can configure them for more complex EEM scripts to issue a different exit value depending upon why the script failed.

For more info, take a look at this Cisco command reference:

I hope this has been helpful!

Laz

1 Like
49

Thanks for the info Laz

1 Like
50

Hello, everyone. I have some questions.

1

R1(config)#do show run | begin event manager
event manager applet NO_INT
 event cli pattern "show running-config" sync yes
 action 0.9 cli command "enable"
 action 1.0 cli command "show ip interface brief"
 action 1.1 puts "$_cli_result"
 action 2.0 set _exit_status "1"

What exactly is the cli_result variable? I somehow get it but at the same time, not really. What does the puts "$_cli_result" achieve? The keyword puts makes me think that something is put/added inside this variable. I know that without this variable, the output of show ip interface brief won’t be displayed. So what is a good definition of this variable and what it achieves?

2
The sync yes and sync no options confuse me a lot. Cisco documentation defines them as following:

Synchronous publishing of CLI events–The CLI command is not executed until the EEM policy exits, and the EEM policy can control whether the command is executed. The read/write variable, _exit_status, allows you to set the exit status at policy exit for policies triggered from synchronous events. If _exit_status is 0, the command is skipped, if _exit_status is 1, the command is run.

Asynchronous publishing of CLI events–The CLI event is published, and then the CLI command is executed.

Asynchronous publishing of CLI events with command skipping–The CLI event is published, but the CLI command is not executed

What sync essentialy means is that the EEM policy is ran first, then the command while async executes both the command and the policy at the same time?

This part is probably the most confusing regarding EEM. Why are there these two options? Sync could be useful if we want to EEM to run instead of a command that was typed but the same can just be achieved by using async and telling EEM to skip the command. I can’t think of many things at the moment where sync would achieve something that async cannot.

3
And the final thing that I don’t understand is this:

R1(config-applet)#do show event manager policy reg
No.  Class     Type    Event Type          Trap  Time Registered           Name
1    applet    user    cli                 Off   Sun Jun 22 12:26:55 2025  1
 pattern {1} sync yes
 maxrun 20.000
 action 1.0 puts "First one!"

This simply types out “First one!” into the console.
obrĂĄzok

Let me configure another applet

R1(config)#do show event manager policy reg
No.  Class     Type    Event Type          Trap  Time Registered           Name
2    applet    user    cli                 Off   Sun Jun 22 12:31:13 2025  2
 pattern {show running-config} sync no skip yes
 maxrun 20.000
 action 2.0 puts "Second one"

This one will print out “Second one” when I type in the running config.
obrĂĄzok

However, why does it use Syslog for this? For sync events, puts uses the console while for async events, it just uses Syslog…

Thank you.
David

51

Hello David

This variable essentially contains the output of the commands that were run. Specifically, it stores the text output of the last CLI command that has been executed by an action command. Every time the action command results in some output, that output is stored in this variable, and any previously stored text is replaced. So in the code you shared, it is the cli_result variable contains the output of the show ip interface brief command. The puts keyword simply displays the contents. It’s like “print” in more conventional coding languages. Without puts the output simply remains captured in the variable but isn’t displayed. This is useful because you can then manipulate the output however you want using that variable.

These options allow you more granular control over whether and how specific commands in the applet are run or not run.

With sync yes, the CLI command is delayed until the EEM applet finishes executing. So it’s not “parallel” execution but rather synchronized such that the script runs first, then the command.

With sync no, the CLI command runs first, then the applet is triggered after the command is accepted (but before it is applied), so that you can still intervene and that’s the key.

Even though the CLI has already accepted the command (sync no), you have a brief window, right after command entry but before it executes, where the EEM applet can intervene by taking actions (e.g., logging or canceling the command via skip yes).

This is expected behavior. When we use sync yes the EEM policy runs in the foreground, that is, in the same context as the CLI session. That means that puts outputs directly to the console (as if you typed the message yourself).

When we use sync no the EEM policy runs in the background. puts sends output to syslog as the CLI session is no longer tied to the policy. This behavior results in synchronous policies interacting with the user’s session, while asynchronous policies are decoupled from the CLI, and appear as Syslog messages.

I hope this has been helpful!

Laz