Showing results for 
Search instead for 
Did you mean: 

3560/3750-E and trackingobject event within an applet


I have successfully created and implemented an EEM script that tracks multiple objects on a router;

Part configuration;

event manager applet PO1_DOWN

event tag PORT track 10 state down

event tag TOMPABX track 20 state up


correelate event PORT and event TOMPABX

action1.0 cli command "enable"



However on an older 3560 (WS-C3560-48PS-E, running 12.2(55)SE8) there is no track option.


event manager applet PO1_DOWN event tag PORT <no track option)!!!

Is there a way round this so I can track multiple objects and is this restriction still on the newer 3560/3750-X Switches?

Thanks in advance,


Hall of Fame Cisco Employee

Even on 15.0(2)SE5, the track ED is not present.  What are the objects you are tracking?


Thanks for the reply Joseph.

The obejcts I am tracking are icmp reachability and links failing.

I need the CLI commands (shutdown a specific interface on the Switch) to be run when the links have failed and remote hosts are available. If the remote hosts are not available, I do NOT want the script run.

Hope that makes sense.

Cheers Paul

Hall of Fame Cisco Employee

The IPSLA event detector does exist, and you can use multiple events within EEM to test them, but this likely won't work the way you want.  What you might need to do is use the timer ED to wake up periodically, then run the "show track" command to see if the tracked object is up or not, and take the appropriate action.


Yes, I saw the IPSLA ED and will look to test it.

Also, is there a way to have a "conditional" event and then trigger? How would that script be written?

For example, I need to only shutdown an interface on the switch, IF a port-channel fails AND an ICMP echo fails, but If the port-channel fails, but the ICMP echo IS successful, I do NOT shutdown the local interface on the Switch.

Hall of Fame Cisco Employee

The way EEM events work, what you describe isn't directly possible.  That's why I suggested the timer approach.  Using that, you can check a number of things at one time and make a decision based on results as to what you want to do.

With EEM multiple events, you can create a boolean expression to say p-c fails AND ICMP echo fails, then do foo, but the way it works is that you need EVENTS to occur within a window for the expression to be true.  Meaning that if the p-c fails, but the ping has been failing, you won't trigger the policy.


Right, that starts to make sense and confirms some of the strange results I got when testing today with a boolean expression.

With regards to increasing the window timeframe, is it just a matter of adding a to the trigger as shown in my configs?

Hall of Fame Cisco Employee

Yes, you can increase the period.  However, I'm not sure you'll get the results you want.  You could still get a case where the ping fails after an hour, and the policy doesn't fire.


Given my set of requirements for this particular solution and the testing results with the trigger period, I think we're good to go now.

Out of curiosity, would you know or is it published anywhere what the "default" window period is for multiple events to trigger the action? Also, for an extended trigger period time, I assume there would be no noticeable overhead on CPU etc.

Thanks again for all your help on this.

Hall of Fame Cisco Employee

By default, the events need to happen concurrently.  Therefore, it's almost always required to specify a desired time window when you use "and".


Joe - The requirement I originally had has now changed slighly.

I need to now shutdown an interface, only if another interface has failed and an icmp IS reachable. That was easy as I could monitor the 2 syslog pattern events and then act. This worked well.

However, I assume I could still use IPSLA to confirm reachability and then act. I don't know how that is configured as there will be no syslog notification.

Any help appreciated.

Hall of Fame Cisco Employee

You can react to the syslog, then run the "show ip sla stat NUM" command to get the current state of the IPSLA collector.  Parse the output using a regular expression, then continue with the policy if you detect an OK status.

Content for Community-Ad