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 .
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.
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
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.