Imagine your network's default gateway goes down, and every workstation loses connectivity. First Hop Redundancy Protocols (FHRPs) like HSRP, VRRP, and GLBP are designed to prevent that—but when failover doesn't work, the entire network suffers. For the CCNA 200-301 exam (objective 3.8), you must be able to systematically troubleshoot FHRP failover issues. This chapter will equip you with the exact diagnostic steps, show commands, and common pitfalls to identify and fix a non-functional FHRP failover in an enterprise network.
Jump to a section
Consider a commercial airliner with two pilots: Captain and First Officer. The Captain (Active) flies the plane, while the First Officer (Standby) monitors. They communicate every few seconds via intercom to confirm all is well. If the Captain becomes incapacitated, the First Officer is supposed to take control immediately. But what if the takeover fails?
Communication breakdown: The intercom system fails—the First Officer never hears that the Captain is silent. In networking, this is like HSRP hello packets being dropped due to a misconfigured access list or VLAN mismatch.
Priority confusion: The Captain and First Officer have the same seniority, so neither knows who should lead. In HSRP, if both routers have the same priority (default 100) and preempt is disabled, the first to come up stays active, but after a reboot, the other might not take over correctly.
Silent failure: The Captain is alive but not flying—he's just not talking. The First Officer assumes all is well. In networking, a router might be in 'listen' or 'speak' state but never transition to active because it doesn't receive hellos from the active router due to a Layer 2 issue.
No preemption: The Captain recovers but doesn't retake control. In HSRP, if preempt is not configured, the original active router won't reclaim its role after a failure, leading to a suboptimal forwarding path.
Just as a failed co-pilot takeover can crash a plane, a failed FHRP failover can crash your network's connectivity. The key is to verify that all pieces—hello communication, priority, preemption, and Layer 2 connectivity—are working together.
What is FHRP and Why Failover Matters
First Hop Redundancy Protocols (FHRPs) allow two or more routers to share a virtual IP address and MAC address, acting as a single default gateway for hosts. The active router forwards traffic; the standby router takes over if the active fails. Failover is the process by which the standby becomes active. When failover doesn't work, hosts lose connectivity to the virtual gateway. The CCNA exam tests your ability to diagnose why failover fails using show and debug commands.
How FHRP Failover Works Step-by-Step
Let's use HSRP (Hot Standby Router Protocol) as the primary example, as it's most common on CCNA. VRRP and GLBP have similar mechanics.
Election: Routers exchange hello messages (every 3 seconds by default, hold time 10 seconds). The router with the highest priority (default 100) becomes active. If priorities are equal, the highest IP address wins.
State Machine: Each interface goes through states: Initial, Learn, Listen, Speak, Standby, Active. The standby router monitors hellos from the active. If no hellos are received within the hold time, the standby declares the active dead and transitions to active.
Virtual MAC: HSRP uses virtual MAC 0000.0c07.acXX (XX = group number in hex). VRRP uses 0000.5e00.01XX. GLBP uses 0007.b400.XXYY. The active router responds to ARP requests for the virtual IP with this MAC.
Failover Trigger: The trigger is silence—the standby stops receiving hello packets. The standby then sends a coup message (HSRP) or transitions immediately (VRRP) to become active.
Key States, Timers, and Defaults
HSRP: Hello time 3 sec, hold time 10 sec. States: Initial (disabled), Learn (router doesn't know virtual IP), Listen (knows virtual IP, not active/standby), Speak (sends hellos, participates in election), Standby (next to become active), Active.
VRRP: Hello time 1 sec (default), hold time 3 sec (3.609 sec actually, but 3x hello). VRRP has only three states: Initialize, Master, Backup. Master sends hellos; if backup misses 3 consecutive hellos, it becomes master.
GLBP: Hello time 3 sec, hold time 10 sec. AVG (Active Virtual Gateway) elects AVFs (Active Virtual Forwarders). Failover involves AVG reelection and AVF reassignment.
IOS CLI Verification Commands
Always start with show standby or show vrrp or show glbp.
Router# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Gi0/0 1 100 P Active local 10.1.1.2 10.1.1.1For detailed info:
Router# show standby
GigabitEthernet0/0 - Group 1
State is Active
2 state changes, last state change 00:02:15
Virtual IP address is 10.1.1.1
Active virtual MAC address is 0000.0c07.ac01
Local virtual MAC address is 0000.0c07.ac01 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.152 secs
Preemption enabled, min delay 0 sec
Active router is local
Standby router is 10.1.1.2, priority 100 (expires in 8.704 sec)
Priority 110 (configured 110)
IP redundancy name is "hsrp-Gi0/0-1" (default)Key things to check: State, Active router IP, Standby router IP, timers, preemption.
Interaction with Related Protocols
Spanning Tree Protocol (STP): If the switch ports connecting to the FHRP routers are in blocking state, hellos won't be exchanged. Ensure portfast and uplinkfast are configured appropriately.
VLANs: FHRP operates per VLAN. Misconfigured VLAN membership or trunk allowed VLANs can isolate routers.
IP Routing: The standby router must have a route to the virtual IP subnet. If not, it may become active but cannot forward traffic.
Access Lists: ACLs applied to the interface can block HSRP/VRRP/GLBP multicast packets (224.0.0.2 for HSRPv1, 224.0.0.102 for HSRPv2, 224.0.0.18 for VRRP, 224.0.0.102 for GLBP).
Verify Layer 2 Connectivity
Start by ensuring both routers can communicate at Layer 2. Check the switchport configuration connecting to each router: VLAN assignment, trunk allowed VLANs, and STP state. Use `show interfaces trunk` and `show spanning-tree vlan X` on the switches. For example, if the active router's port is in blocking state, it won't receive hellos from the standby. Also verify that the routers are in the same VLAN. A common mistake is placing one router in VLAN 10 and the other in VLAN 20—they won't see each other's hellos. Use `ping` from each router to the other's interface IP to confirm Layer 3 reachability, but note that FHRP hellos are multicast at Layer 2, so a successful ping doesn't guarantee hello delivery (e.g., if IGMP snooping filters the multicast).
Inspect FHRP State on Both Routers
Run `show standby brief` on both routers. Look for the state: one should be Active, the other Standby. If both are Active, you have a split-brain scenario (likely due to Layer 2 isolation). If both are Standby or in Listen/Speak, the election hasn't completed. Check the 'Active' column: if it says 'unknown' or 'local' incorrectly, something is wrong. Also verify the virtual IP address is the same on both. If one router shows a different virtual IP, the group configuration is mismatched. For VRRP, use `show vrrp brief`; for GLBP, `show glbp brief`. Expected output for a working HSRP group: one router shows 'Active', the other 'Standby'.
Check Hello Packet Exchange with Debug
Use debug commands to see if hellos are being sent and received. On the standby router, run `debug standby tpid` (for HSRP) or `debug vrrp packet` or `debug glbp packet`. Look for 'Hello out' and 'Hello in' messages. If you see outgoing hellos but no incoming, the standby is not hearing the active. This indicates a Layer 2 issue (VLAN, trunk, STP) or an ACL blocking the multicast. If you see incoming hellos but the state doesn't change, check timers. For example, if the hold time is mismatched (10 sec on one, 5 sec on the other), the standby may declare active dead prematurely or never. Important: Use debug sparingly in production; on the exam, you'll be given debug output to interpret.
Verify Timers and Preemption Settings
Compare hello and hold timers on both routers using `show standby`. They must match for proper operation. Mismatched timers can cause flapping—the standby may keep thinking the active is dead. Also check preemption: if preempt is not configured, the original active router will not reclaim its role after a failure. This is a common exam scenario: after a reboot, the standby remains active even though the original active has higher priority. Use `standby X preempt` to enable. For VRRP, preempt is enabled by default. For GLBP, preempt is also enabled by default for the AVG. Also check the priority values: the router with higher priority should be active. If both have same priority, the higher IP wins.
Examine Virtual MAC and ARP Behavior
After failover, hosts should update their ARP cache. But if the virtual MAC doesn't change (e.g., because the new active didn't send a gratuitous ARP), traffic may still go to the old active. Use `show ip arp` on the routers to see the virtual IP mapped to the correct virtual MAC. On the switch, check the MAC address table for the virtual MAC: `show mac address-table | include 0000.0c07.ac` (for HSRP). If the virtual MAC is not learned on the correct port, the switch may be flooding or dropping frames. Also verify that the router's interface MAC is the virtual MAC for the virtual IP. For HSRP, the router should respond to ARP requests for the virtual IP with the virtual MAC.
Test Failover Manually and Verify
Simulate a failure by shutting down the active router's interface or by changing its priority to force a transition. On the active router, do `interface Gi0/0` then `shutdown`. Then check the standby router's state with `show standby brief`—it should become Active within the hold time (10 seconds). Bring the interface back up; if preempt is enabled, the original active should reclaim. Use `show standby` to see state changes and timers. Also test connectivity from a host by pinging the virtual IP continuously during the failover; expect one or two dropped pings (the convergence time). If more than a few pings drop, the failover is too slow—check timers and preemption delay.
Scenario 1: Campus Network with Dual Routers
An enterprise campus has two routers (R1 and R2) serving as default gateways for VLAN 10 (10.1.10.0/24). HSRP is configured with virtual IP 10.1.10.1. R1 has priority 110 (preempt enabled), R2 priority 100. One day, R1's uplink switch port goes into errdisable state due to a loop. The standby (R2) should take over, but it doesn't. The network engineer checks show standby brief and sees R2 is still in Standby state, even though R1 is unreachable. The issue: the switch port connecting to R2 is blocking STP for VLAN 10 because RSTP reconverged after the loop. The engineer fixes STP by enabling PortFast on access ports and configuring uplinkfast. The failover then works.
Scenario 2: Data Center with VRRP
In a data center, two routers run VRRP for a server subnet. The master router reboots for maintenance. The backup becomes master, but after the maintenance, the original master does not reclaim its role because VRRP preempt is enabled by default, but the backup has a higher IP address (since both have priority 100). The engineer expected the original master to come back as master, but it remains backup. The solution: configure a higher priority on the desired master and ensure preempt is enabled (it is by default). The engineer changes the priority on the original master to 120 and verifies with show vrrp.
Scenario 3: GLBP with Unequal Load Balancing
A network uses GLBP to load balance between two routers. The AVG (Active Virtual Gateway) fails, and the backup AVG takes over. However, the AVF weighting and load balancing are misconfigured, causing one router to handle all traffic. The engineer uses show glbp to see the weighting and adjusts the weighting values to achieve 50/50 split. Also, the virtual MACs are reassigned after failover, requiring hosts to re-ARP. The engineer ensures gratuitous ARPs are sent by verifying glbp forwarder preempt is enabled.
Common Pitfalls
ACLs blocking multicast: An inbound ACL on the interface can block HSRP hellos (224.0.0.2). Always check with show access-lists.
VLAN mismatch: Routers in different VLANs won't exchange hellos. Use show vlan on switches.
Timer mismatch: One router has hello 1 sec, hold 3 sec; other has default 3/10. The standby may never declare active dead because it expects hellos every 3 sec but gets them every 1 sec—actually it will work, but if the active fails, the standby may wait longer than expected. Mismatch can cause flapping.
Preemption not configured: After a failure, the original active doesn't reclaim. Always enable preempt on the desired master.
What the Exam Tests
CCNA 200-301 objective 3.8 covers 'Troubleshoot first hop redundancy protocols (FHRP)'. You will be given a scenario with two routers configured with HSRP, VRRP, or GLBP, and a failure condition. You must identify why failover is not working based on show command output. Common topics: state transitions, timer mismatches, priority, preemption, virtual MAC, and Layer 2 issues.
Most Common Wrong Answers
'The standby router is not receiving hellos because the active router has a higher priority.' Wrong: Priority affects election, not hello delivery. Both send hellos regardless of priority.
'The virtual IP address is not configured on the standby router.' Wrong: The virtual IP must be configured on both routers; if missing on one, that router cannot become active. But the exam often shows the virtual IP configured correctly.
'Preemption is enabled, so the standby will not take over.' Wrong: Preemption allows the higher priority router to reclaim, not prevent takeover. The standby takes over regardless of preemption when the active fails.
'The hold time is too short, causing flapping.' Wrong: A short hold time may cause false failover, but if failover is not happening, the hold time might be too long (e.g., 30 sec) causing slow detection. But the exam typically tests mismatched timers.
Specific Values and Commands
HSRP default timers: Hello 3 sec, Hold 10 sec.
HSRP virtual MAC: 0000.0c07.acXX (group in hex).
VRRP default timers: Hello 1 sec, Hold 3 sec (actually 3.609 sec).
VRRP virtual MAC: 0000.5e00.01XX.
GLBP default timers: Hello 3 sec, Hold 10 sec.
GLBP virtual MAC: 0007.b400.XXYY.
State order: Initial -> Learn -> Listen -> Speak -> Standby -> Active (HSRP).
show standby brief output: Look for state, active, standby, virtual IP.
debug standby output: Look for 'Hello out' and 'Hello in'.
Decision Rule for Scenario Questions
Check if both routers have the same virtual IP and group number. If not, it's a configuration mismatch.
Check the state: if both are Active, it's a split-brain due to Layer 2 isolation. If one is Active and the other is Standby, failover is likely working, but check if the active is the intended one (priority).
If the standby never becomes active after the active fails, check if the standby is receiving hellos (debug). If not, look at Layer 2 (VLAN, trunk, STP, ACL). If yes, check timers and hold time expiry.
If the active fails and the standby becomes active but the original active doesn't reclaim, check preemption.
Always look at the 'Active' column: if it says 'unknown', the router doesn't know who is active—usually a hello issue.
HSRP default hello timer is 3 seconds, hold timer is 10 seconds.
VRRP default hello timer is 1 second, hold timer is 3 seconds (3.609 sec).
HSRP states in order: Initial, Learn, Listen, Speak, Standby, Active.
Virtual MAC for HSRP is 0000.0c07.acXX (XX = group number in hex).
Preemption must be enabled for a higher-priority router to reclaim active role after a failure.
Common failover failure causes: Layer 2 issues (VLAN mismatch, STP blocking), ACLs blocking multicast, timer mismatch, and preemption disabled.
Use 'show standby brief' and 'debug standby' to diagnose HSRP failover issues.
These come up on the exam all the time. Here's how to tell them apart.
HSRP (Hot Standby Router Protocol)
Cisco proprietary
Default hello 3 sec, hold 10 sec
States: Initial, Learn, Listen, Speak, Standby, Active
Virtual MAC: 0000.0c07.acXX
Preempt disabled by default
Supports multiple groups per interface
VRRP (Virtual Router Redundancy Protocol)
Open standard (RFC 3768)
Default hello 1 sec, hold 3 sec (3.609 sec)
States: Initialize, Backup, Master
Virtual MAC: 0000.5e00.01XX
Preempt enabled by default
Supports multiple groups per interface (but typically one)
Mistake
The standby router will become active immediately when the active router fails.
Correct
The standby waits for the hold timer to expire (default 10 sec for HSRP, 3 sec for VRRP) before transitioning to active. This delay is intentional to avoid flapping.
Candidates think failover is instant because they've seen fast failover in other contexts (e.g., EtherChannel).
Mistake
If both routers have the same priority, the one with the higher IP address becomes active.
Correct
This is true for HSRP and VRRP. But if preempt is disabled, the first router to come up becomes active and stays active, regardless of IP address.
Candidates often forget that preemption affects whether the higher IP can take over after the initial election.
Mistake
HSRP uses the virtual IP address as the source IP for hello packets.
Correct
HSRP hellos use the actual interface IP address as the source, not the virtual IP. The virtual IP is carried in the packet payload.
Candidates assume the virtual IP is used for all communication because it's the gateway address.
Mistake
The standby router must have a route to the virtual IP subnet to become active.
Correct
The standby router becomes active based on hello loss, not routing table. However, to forward traffic, it must have a route to the subnet, but that's a separate issue.
Candidates confuse FHRP failover conditions with routing protocol convergence.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, verify that the standby router is receiving hellos from the active. Use 'debug standby tpid' on the standby to see if hellos stop after the shutdown. If hellos continue, there may be another router acting as active (split-brain). If hellos stop but the standby doesn't transition, check the hold timer: it may be set to a very high value (e.g., 30 seconds), so the standby hasn't yet declared the active dead. Also ensure the standby's interface is up and in the same VLAN. Another common issue: the standby router's interface has an ACL blocking the HSRP multicast (224.0.0.2). Use 'show ip access-lists' to check. Finally, verify that the virtual IP is configured identically on both routers.
HSRPv1 uses multicast address 224.0.0.2 and supports group numbers 0-255. HSRPv2 uses multicast 224.0.0.102, supports group numbers 0-4095, and includes a 6-byte identifier in the packet for better authentication. HSRPv2 also supports IPv6. For CCNA, you should know that both versions exist and that the 'standby version 2' command enables it. If one router uses v1 and the other v2, they won't communicate—a common failover issue. Use 'show standby' to see the version.
Yes, as long as both devices support HSRP. The configuration is the same. However, ensure both devices are in the same VLAN and have IP connectivity. Also, the Layer 3 switch may have SVIs (Switch Virtual Interfaces) that can participate in HSRP. Note that on some platforms, the switch may need 'no switchport' on the interface if it's a routed port.
'standby track' allows you to decrement the HSRP priority if a tracked interface goes down. For example, if the active router's uplink fails, its priority drops, and the standby takes over. This provides faster failover for upstream failures. The syntax is 'standby [group] track [interface] [decrement-value]'. The default decrement is 10. On the exam, you may be asked why a router with higher priority is not active—check if tracking decremented its priority.
This is a split-brain scenario, usually caused by a Layer 2 failure between the routers. They cannot hear each other's hellos, so each thinks it is the only active router. Check the switch connecting them: VLAN membership, trunk allowed VLANs, STP state. Also verify that the multicast address is not being filtered. Use 'show spanning-tree vlan X' to see if any ports are blocking. Another cause: both routers have the same priority and preempt is disabled, but they came up at different times—actually, that wouldn't cause split-brain; only one would be active. Split-brain requires complete isolation.
In HSRP, preempt is disabled by default. You must explicitly configure 'standby [group] preempt' to allow a higher-priority router to reclaim the active role. In VRRP, preempt is enabled by default. This means that if a VRRP router with higher priority comes online, it will automatically become the master. However, VRRP also has a 'preempt delay' option to prevent flapping. On the exam, remember that VRRP's default behavior is to preempt, while HSRP's is not.
Simulate a failure by shutting down the active router's interface. On the standby, use 'show standby brief' to see if it transitions to Active within the hold time (10 seconds). Also ping the virtual IP from a host during the failover—expect 1-2 lost pings. After bringing the active router back up, if preempt is enabled, it should reclaim. Use 'show standby' to see state changes and timers. Also check the switch's MAC address table to ensure the virtual MAC is learned on the correct port. Finally, check logs with 'show log' for HSRP state changes.
You've just covered Troubleshoot: FHRP Failover Not Working — now see how well it sticks with free CCNA 200-301 practice questions. Full explanations included, no account needed.
Done with this chapter?