IP SLA stops probing when one or more interfaces goes to standby

[sveinbarlund]

I have set up two 3925 in a hot-standby configuration.
If i configure track with IP SLA, the IP SLA stops probing (ping) as soon as at least one interface goes to standby. IP SLA probes are declared Down.

If all standby interfaces go to Active (by manipulating priority or turning off the other router), the IP SLA ping probes start again.

I have not seen this described as intended behavior, feature, or caveat. Is it likely to be a bug in this particular IOS version?

IOS version is 15.3(3)M2  (with technology/license: ipbasek9, securityk9, and uck9)

--

Svein

[yusuf habibi]

please share your HSRP & IP SLA config :)

if you using track command on HSRP, you should define command 'preempt' both of HSRP (active/standby)

[sveinbarlund]

Below is my HSRP and IP SLA config.

HSRP with preemption is working, except for the intended ip sla priority manipulation.

The problem is only that IP SLA stops sending out PING probes and declares Down state when one or more HSRP interfaces go to standby. This even if the IP SLA is totally unrelated to the HSRP tracking.

Config for the normally standby router (the other has slightly higher standby pri):

interface Vlan10
 description Internal net
 ip address 172.24.1.202 255.255.240.0
 standby 1 ip 172.24.1.200
 standby 1 priority 100
 standby 1 preempt
 standby 1 name HSRP1
 standby 1 track 1 decrement 10
 standby 1 track 2 decrement 10
!
interface Vlan20
 description Outside net
 ip address 10.5.1.102 255.255.255.0
 standby 2 ip 10.5.1.100
 standby 2 priority 100
 standby 2 preempt
 standby 2 name HSRP2
 standby 2 track 1 decrement 10
 standby 2 track 2 decrement 10
!
track 1 ip sla 11 reachability
track 2 ip sla 12 reachability
!
ip sla 11
  icmp-echo 172.24.1.1
  timeout 5000
  frequency 10
  threshold 500
ip sla schedule 11 start-time now life forever
!
ip sla 12
  icmp-echo 10.5.1.201
  timeout 5000
  frequency 10
  threshold 500
ip sla schedule 12 start-time now life forever

sbc02#show stand bri
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Vl10        1    80  P Standby 172.24.1.201    local           172.24.1.200
Vl20        2    80  P Standby 10.5.1.101      local           10.5.1.100

sbc02#show ip sla summ
IPSLAs Latest Operation Summary
Codes: * active, ^ inactive, ~ pending
ID           Type        Destination       Stats       Return      Last
                                           (ms)        Code        Run
-----------------------------------------------------------------------
*11          icmp-echo   172.24.1.1        -           Unknown     -

*12          icmp-echo   10.5.1.201        -           Unknown     -

If I do a shutdown of  Vlan10 and Vlan20 and then "no shut",  the IP SLA kicks back into action.

[paul driver]

Hello

Is just one rtr acting the primary for both vlans - Does this router has its priority set higher than the default 100 as shown in you post?

I would first make the primary rtr have a higher priority value than the HSRP default

res

Paul

[yusuf habibi]

check this article 'Tracking using IP SLA'

you should define source-ip or source-interface to starts IP SLA.

and make sure the routing protocol able to reach the IP Address for icmp-echo

[sveinbarlund]

I have checked and double checked all your suggestions.

The strange thing is that ANY ip sla probing stops, even to an internal interface,  when HSRP interface(s) go to standby state.

I have now tried with a different IOS version: 15.2(4)M6, but still with the same result.

???
--

[sveinbarlund]

I think I am on to something:

If I remove the redundancy inter-device configuration from at least one of the routers, the ip sla works as expected.

DELETED: redundancy inter-device
DELETED: scheme standby HSRP1
!
redundancy
!
!
ipc zone default
 association 1
  no shutdown
  protocol sctp
   local-port 5005
    local-ip 172.24.1.202
   remote-port 5005
    remote-ip 172.24.1.201

With this change, the IP SLA and HSRP failover work OK, but I am unsure of what effect it may have on stateful failover for SIP VOIP connections.