×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Object tracking default-state not working?

Unanswered Question

I am using an object tracker to trigger an EEM applet to bypass a device when the object is not reachable.  The bypass is achieved by changing the dot1q encapsulation on the 174 sub-interface to 175, the default encapsulation for this interface is 174. 



!


ip sla 2


icmp-echo 10.230.68.218 source-interface GigabitEthernet0/1.174


timeout 1000


threshold 30000


frequency 1


ip sla schedule 2 life forever start-time now


!


track 2 ip sla 2 reachability


!


event manager applet BYPASS


event track 2 state down


action 1 cli command "enable"


action 2 cli command "config t"


action 3 cli command "int Gi0/1.174"


action 4 cli command "encapsulation dot1q 175"


action 5 syslog msg "Device Bypassed on Gi0/1.174"


action 6 snmp-trap strdata "DEVICE-BYPASSED"


!


event manager applet UNBYPASS


event track 2 state up


action 1 cli command "enable"


action 2 cli command "config t"


action 3 cli command "int Gi0/1.174"


action 4 cli command "encapsulation dot1q 174"


action 5 syslog msg "Device Unbypassed on Gi0/1.174"


action 6 snmp-trap strdata "DEVICE-UNBYPASSED"


!



This works as expected except in the case where the tracked object is not reachable on initial router boot, in this case the router doesn’t detect a transition of the tracking object from up -> down and therefore does not execute the associated EEM applet.  I attributed this to the router having a default object state of down and tried setting the default state to up using the following line, but this had no effect.



!


track 2 ip sla 2 reachability


default-state up


!



I also tried changing the object tracking type from reachability to state but did have any effect either.



I was able to get this to work by changing the default encapsulation of the 174 sub-int to 175 but I would prefer not to do this since it may be misinterpreted by the user. Is there another way to accomplish this or is there an IOS bug here?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
KR ISG Network Mon, 08/19/2013 - 16:14
User Badges:

Hi Christopher, Have you ever managed to resolve this? We're having the same issue when the tracked object remains unreachable/down after router reload.  EEM apears to need a track state change to kick in (up->down). 

I ended up creating a second object tracker (102 in the below example) that tracks the first object (2 in the below example) such that it is only up when the other is down.  This way only one of the 2 object can ever be up at one time and you can trigger the eem applets based on this.  Have been using this for several years in a fielded system no issues.


!

ip sla 2

icmp-echo 10.10.10.10 source-interface GigabitEthernet0/0.174

timeout 1000

threshold 30000

frequency 1

!

ip sla schedule 2 life forever start-time now

!

track 2 ip sla 2 reachability

delay down 3 up 3

!

track 102 list boolean and

object 2 not

!

event manager applet BYPASS

event track 102 state up

action 010 cli command "enable"

action 020 cli command "config t"

action 100 cli command "int Gi0/0.174"

action 101 cli command "encapsulation dot1q 175"

!

event manager applet UNBYPASS

event track 2 state up

action 010 cli command "enable"

action 020 cli command "config t"

action 100 cli command "int Gi0/0.174"

action 101 cli command "encapsulation dot1q 174"

!

KR ISG Network Wed, 08/21/2013 - 22:02
User Badges:

Thanks Chris, I've just tested your workaround in the lab and it worked just fine. Going to prod tomorrow. Thanks again!

Actions

This Discussion