Overview： HSRP link down recovery
Goal: Animate Lab captured packets to show HSRP link down recovery criticla details. E.g., event-state, timer.
Topology: 2 routers and 1 host are connected to a switch.
Steps: 1) HSRP election is done. R1, R2 sends Hello periodically.
2) Bring down R1's HSRP interface and causes Active router disbaled.
3) R2 becoems Activwe after Active timer timeout.
Configure HSRP routers
- R1, R2 are in HSRP group 1. Thier R1 priorities are 100, 105 respectively. HSRP group 1 vurtual IP address
is 192.168.1.1, virtual MAC is 00:00:0c:07:ac:01 (MAC.virt).
In the beginning of this Lab, HSRP has elected R1 as Active and R2 as Standby routers.
H1 ping 10.1.1.1: OK
H1 ping 10.1.1.1 (Loopback address). The destinaion MAC is virtual MAC.
When S1 receives ping, it finds out that the destination MAC is in the MAC table and forwards ping to interface Fa0/1.
R2 receives the last Hello from R1
At tick 13, R2 receiives the last Hello from R1 (Active). R2 restarts the Active timer (10 seconds.)
Ping failure: switched to R1
H1 continues to pong 10.1.1.1 and S1 forwarss pings to R1 and dropped. This is because the switch still thinks the virtual MAC address is located at Fa0/1. This will change as soon as R2 figures out that the Active router is in trouble.
R1 link down, no more Active
At tick 16, R1 link down at E0/0. A big red cross marks E0/0. In R1's HSRP status shows Active and Standby routers become unknown. But P2 still thinks R1 is Actie.
R2 Active timeout.
At tick 13, R2 receives the last Hello from R1 before link down (at tick 16). R2 then started the Active timer (10 sec). Now at tick 33, the Actuve timer expires. According to the rules defined by RFC2281, R2 takes over and becoems Actoive. R2 also sends Hellop, ARP reply to notify thers.,
Switch updates it MAC table
When switch S1 receives ARP reply from F0/2, the virtual MAC's entry is updated and changed from (MAC.virt , F0/1) to (MAC.virt, F0/2). That is, the interface to switch to the new Active router is F0/2.
Ping OK. Link failover time 7 sec
H1 pings 10.1.1.1 again. This time, it is switched to S1's F0/2 interface and routed to the loopback interface. The loopback interface sends an echo back. H1 receives echo at tick 49. In this lab, link failover recovery time is less 7 sec (tick 16~49, 5 tick/sec). This is expected as we define Active timer to 10 second.
Appendix B: HSRP configuration commands
R1(config)#interface eth0/0 R1(config-if)#standby 1 ip 192.168.1.1 R1(config-if)#standby 1 priority 105 R1(config-if)#standby 1 preempt R1(config-if)# ; Priority default 100. R2(config)#interface eth0/0 R2(config-if)#standby 1 ip 192.168.1.1 R2#
Appendix A: FAQ
Q1. Howw does R2 change from Standby to Active? A. This change is defined by RFC2281 state table. First, we observe the following from the animation: - At tick 14, the last Hello departed from R1. - At tick 17. the last Hello from R1 arrives at R2. R2 started Actuve timer. - At tick 33, R2 Active timer timeout, R2 sends 4 packets out. R2 state is changed to Actove. Then we interpret RFC 2281 as follows: i. Active timer timeout: This is event "c" in the RFC2281 state table. ii. R2's current state is State 5 (Standby). iii. Execute the actions defined in c-row, 50column: CDFI/6 /6: Change the state to 6 (Active) CDF: C: stop Active timer D: Stop Stanbdby timer F: Send Hello Q2: Why R2 state is changed to Active (tick 35) 2 ticks later than sending 4 packets (tick 33). A. The possible reasons are: - The state is gathered by polling virtual router once every 0.5 second while packet timing unit tick is 200 ms. - Virtual router may be a bit slow to respond to commands. Q3: How to locate relevant sections in A. RFC2281?RFC2281 http://www.faqs.org/rfcs/rfc2281.html - Active timer expiration ecet：RFC > 5.5 Events > c - Active timer expiry. - State table. RFC > 5.7 State Transitions > CDFI/6 (row c, colum 5- Standby) - Actions:: RFC > 5.6 Actions > CDF
|Single step forward|
|Backup one step|
|Read the next page|
|Read the last page|
|Don’t show me this message next time.|