03-15-2018 05:15 AM - edited 03-01-2019 06:28 PM
Hello,
on a 2960-X Switch with 6 stack members, running 15.2.(4)E4, I have a EEM TCL script registred in EEM. Now I updated the script and want to replace it. So I unregistered it with "no event manager policy <scriptname>". A "show event manager policy registered" shows that the script is no longer registered.
Now when an event comes up which would trigger the (unregistred) policy, the EEM fires the script !!
It is still active, even if I suspend the scheduler with "event Manager scheduler suspend".
When I do a "remote command all show event manager policy registered, I can see that the policy is still registered on all stack members, except the master.
So when I register the new version of that script, EEM fires both versions although the file of the old version does not exists on the flash anymore!??
How can I "unregister" the scripts from all the stack members, so that only the new script is executed?
Kind regards,
Andreas
Solved! Go to Solution.
03-20-2018 02:41 AM
Hi,
I verified that after a reboot each (member)switch registered it's own instance of a (EEM)script. When an event is triggered, both the master and the corresponding member(for e.g. link-up) executes the script. So it runs twice under a race condition. Unregistering the script (on the master) does not prevent from running on a member - it's still registered on the member(s). So, you're right this is definitely a bug, which I'll report to cisco.
I found a workaround for unregister a (EEM)script from a particular member.
I do a 'session <switch-member-number>', then I open a tcl-shell and unregister each script via 'ios_config "no event manager policy <scriptname>"'. And 'exit' at the end to get back to the master.
Kind regards,
Andreas
03-15-2018 10:52 AM
Hmmm, I didn't realize they added full EEM to the 2960-X. But this sounds like a bug in any event. The config should be synced across the members. I recommend a TAC case for this as I didn't find any known issues.
03-16-2018 12:24 AM
Hello Joe, thank you for your reply.
what I found out in addition yesterday is, that this behavior takes place for only one of my scripts. I unregistered one of my other scripts (which is slightly smaller) and the switch does not execute it anymore even the script is still registered on the stack members(not on the master anymore).
Could it be that there is something in this particular script that might disrupt the EEM(or its memory) ?
So, I would like to ask you if you can have a look at my script, before I open a TAC case? To my shame, the script is not very smart, maybe thats the Problem.
Kind regards,
Andreas
03-16-2018 03:41 AM
Regardless of the script, when you unregister it, new instances should not be invoked. That said, unregistering a script won't terminate any running instance. A reload may be required for that if the script is locked up. But new instances should not run. This is why I think you have hit a bug.
03-20-2018 02:41 AM
Hi,
I verified that after a reboot each (member)switch registered it's own instance of a (EEM)script. When an event is triggered, both the master and the corresponding member(for e.g. link-up) executes the script. So it runs twice under a race condition. Unregistering the script (on the master) does not prevent from running on a member - it's still registered on the member(s). So, you're right this is definitely a bug, which I'll report to cisco.
I found a workaround for unregister a (EEM)script from a particular member.
I do a 'session <switch-member-number>', then I open a tcl-shell and unregister each script via 'ios_config "no event manager policy <scriptname>"'. And 'exit' at the end to get back to the master.
Kind regards,
Andreas
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide