Solved: Re: HSRP taking a long time to recover

rakyomin78 · ‎08-08-2012

I was trying to do a HSRP test by reaching loopbacks of two routers from my pc. My PC can reach 192.168.100.151/32 almost immediately, however 192.168.100.150 takes 20sec to reach after i remove te1/1. I would like to find out if there's misconfiguration of my HSRP...

HSRP configuration for C7609-1

interface Vlan101

ip address 192.168.101.1 255.255.255.0

ip router isis

standby version 2

standby 101 ip 192.168.101.3

standby 101 timers msec 500 msec 1500

standby 101 priority 110

standby 101 preempt delay minimum 5

standby 101 track TenGigabitEthernet1/1 20

end

router isis

net 49.0001.1921.6810.0150.00

is-type level-1

nsf cisco

C7609-1#

HSRP configuration for C7609-2

interface Vlan101

ip address 192.168.101.2 255.255.255.0

ip router isis

standby version 2

standby 101 ip 192.168.101.3

standby 101 timers msec 500 msec 1500

standby 101 preempt

end

router isis

net 49.0001.0192.1681.1510.00

is-type level-1

nsf cisco

C7609-2#

HSRP events

C7609-1#

*Aug 8 08:59:48.359: HSRP: Vl101 Grp 101 ARP src 192.168.101.101 tgt 192.168.101.3, reply with mac 0000.0c9f.f065

C7609-1#

*Aug 8 08:59:58.503: %TRACKING-5-STATE: 1 interface Te1/1 line-protocol Up->Down

C7609-1#

*Aug 8 08:59:58.503: HSRP: Vl101 Grp 101 Track 1 object changed, state Up -> Down

*Aug 8 08:59:58.503: HSRP: Vl101 Grp 101 Priority 110 -> 90

C7609-1#

*Aug 8 08:59:59.991: HSRP: Vl101 Grp 101 Standby router is unknown, was 192.168.101.2

*Aug 8 08:59:59.991: HSRP: Vl101 Nbr 192.168.101.2 no longer standby for group 101 (Active)

*Aug 8 08:59:59.991: HSRP: Vl101 Nbr 192.168.101.2 Was active or standby - start passive holddown

C7609-1#

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 Active: j/Coup rcvd from higher pri router (100/192.168.101.2)

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 Active router is 192.168.101.2, was local

*Aug 8 09:00:47.023: HSRP: Vl101 Nbr 192.168.101.2 is no longer passive

*Aug 8 09:00:47.023: HSRP: Vl101 Nbr 192.168.101.2 active for group 101

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 active 1->0, passive 0->1

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 Active -> Speak

*Aug 8 09:00:47.023: %HSRP-5-STATECHANGE: Vlan101 Grp 101 state Active -> Speak

C7609-1#

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 HA send sync state Speak

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 Redundancy "hsrp-Vl101-101" state Active -> Speak

*Aug 8 09:00:47.023: HSRP: Vl101 Removed 192.168.101.3 from ARP

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 Deactivating MAC 0000.0c9f.f065

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 Removing 0000.0c9f.f065 from MAC address filter

*Aug 8 09:00:47.023: HSRP: Vl101 Grp 101 HA send sync hellotime 500 and holdtime 1500

*Aug 8 09:00:47.023: HSRP: Vl101 IP Redundancy "hsrp-Vl101-101" update, Active -> Speak

C7609-1#

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 Speak: d/Standby timer expired (unknown)

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 Standby router is local

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 active 0, passive 1

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 Speak -> Standby

*Aug 8 09:00:48.783: %HSRP-5-STATECHANGE: Vlan101 Grp 101 state Speak -> Standby

C7609-1#

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 HA send sync state Standby

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 Redundancy "hsrp-Vl101-101" state Speak -> Standby

*Aug 8 09:00:48.783: HSRP: Vl101 IP Redundancy "hsrp-Vl101-101" standby, unknown -> local

*Aug 8 09:00:48.783: HSRP: Vl101 IP Redundancy "hsrp-Vl101-101" update, Speak -> Standby

C7609-1#

Timeout when te1/1 is removed

The virtual IP and 192.168.100.151/32 has minimum disruption, but the 192.168.100.150/32 has long disruption which I suspect could be related to ARP cache, but I would like to confirm with you all....

C7609-2 route to loopback

C7609-2#sh ip route 192.168.100.0

Routing entry for 192.168.100.0/32, 2 known subnets

Attached (1 connections)

i L1 192.168.100.150 [115/20] via 192.168.70.1, 00:11:33, Vlan70

[115/20] via 192.168.40.1, 00:11:33, Vlan40

[115/20] via 192.168.30.1, 00:11:33, Vlan30

[115/20] via 192.168.1.1, 00:11:33, Port-channel1

C 192.168.100.151 is directly connected, Loopback0

C7609-2#

C7609-1 route to loopback

C7609-1#sh ip route 192.168.100.0

Routing entry for 192.168.100.0/32, 2 known subnets

Attached (1 connections)

C 192.168.100.150 is directly connected, Loopback0

i L1 192.168.100.151 [115/20] via 192.168.70.2, 00:12:40, Vlan70

[115/20] via 192.168.40.2, 00:12:40, Vlan40

[115/20] via 192.168.30.2, 00:12:40, Vlan30

[115/20] via 192.168.1.2, 00:12:40, Port-channel1

C7609-1#

Hope experts from here can help to clarify....I believe the HSRP configuration is fine... but the long period of timeout to 192.168.100.150 might be due to ARP cache and not the HSRP...

Giuseppe Larosa · ‎08-08-2012

Hello Rakyomin78,

there are some missing details in your post:

where is connected the tracked interface te1/1 on C7609-1?

Is it the link to the L2 LAN switch?

ISIS is enabled on SVI vlan 101, each C7609 should see the other C7609 loopback also via Vlan101 unless your show ip route are taken when connectivity in vlan 101 is broken.

But if connectivity is broken in vlan 101 when te1/1 is failed on C7609-1 we should see ISIS adjacency to flap in the log messages. (you may have filtered only HSRP messages, ok this is fine)

The surviving C7609 device in Vlan101 should take over and it should send out a gratuitous ARP to refresh the CAM table of the L2 LAN switch. There is no need for a change in ARP entry in the host

From the log messages we see:

*Aug 8 08:59:58.503: HSRP: Vl101 Grp 101 Track 1 object changed, state Up -> Down

*Aug 8 08:59:58.503: HSRP: Vl101 Grp 101 Priority 110 -> 90

C7609-1#

*Aug 8 08:59:59.991: HSRP: Vl101 Grp 101 Standby router is >>>>unknown>>>>, was 192.168.101.2

And later

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 Speak -> Standby

*Aug 8 09:00:48.783: %HSRP-5-STATECHANGE: Vlan101 Grp 101 state Speak -> Standby

It looks like that connectivity in Vlan 101 is broken when te1/1 goes up to down and then later the connectivity is restored but in the middle an STP activity in vlan 101 may have occurred

Who is the STP root bridge for Vlan 101 ( assuming PVST+ is running) among C7609-1, C7609-2 and the L2 LAN switch?

What is the exact topology of vlan 101, is it permitted on any L2 trunk link in addition to links C7609-1 to L2 switch and C7609-2 to L2 switch?

Hope to help

Giuseppe

View solution in original post

Giuseppe Larosa · ‎08-08-2012

Hello Rakyomin78,

there are some missing details in your post:

where is connected the tracked interface te1/1 on C7609-1?

Is it the link to the L2 LAN switch?

ISIS is enabled on SVI vlan 101, each C7609 should see the other C7609 loopback also via Vlan101 unless your show ip route are taken when connectivity in vlan 101 is broken.

But if connectivity is broken in vlan 101 when te1/1 is failed on C7609-1 we should see ISIS adjacency to flap in the log messages. (you may have filtered only HSRP messages, ok this is fine)

The surviving C7609 device in Vlan101 should take over and it should send out a gratuitous ARP to refresh the CAM table of the L2 LAN switch. There is no need for a change in ARP entry in the host

From the log messages we see:

*Aug 8 08:59:58.503: HSRP: Vl101 Grp 101 Track 1 object changed, state Up -> Down

*Aug 8 08:59:58.503: HSRP: Vl101 Grp 101 Priority 110 -> 90

C7609-1#

*Aug 8 08:59:59.991: HSRP: Vl101 Grp 101 Standby router is >>>>unknown>>>>, was 192.168.101.2

And later

*Aug 8 09:00:48.783: HSRP: Vl101 Grp 101 Speak -> Standby

*Aug 8 09:00:48.783: %HSRP-5-STATECHANGE: Vlan101 Grp 101 state Speak -> Standby

It looks like that connectivity in Vlan 101 is broken when te1/1 goes up to down and then later the connectivity is restored but in the middle an STP activity in vlan 101 may have occurred

Who is the STP root bridge for Vlan 101 ( assuming PVST+ is running) among C7609-1, C7609-2 and the L2 LAN switch?

What is the exact topology of vlan 101, is it permitted on any L2 trunk link in addition to links C7609-1 to L2 switch and C7609-2 to L2 switch?

Hope to help

Giuseppe

rakyomin78 · ‎08-13-2012

Hi,

Thank you for your reply. Anyway we have found out the problem.

The long recovery time was actually not HSRP but STP...I have neglected that the network is a mixed of L2 and L3 redundancy...