HSRP vs VRRP vs GLBP
Choose a first-hop redundancy protocol from design requirements—not habit—and use one repeatable workflow to diagnose gateway failures.
Gateway Redundancy Learning Path
Start with the virtual-gateway idea, configure each major protocol, then compare and troubleshoot complete designs.
In This Lesson
Choose HSRP, VRRP, or GLBP from actual design requirements, then troubleshoot them with one protocol-neutral workflow. The emphasis is evidence, controlled testing, and fast fault isolation.
Quick Learning Map
Keep these three decisions in view as you work through the detailed lesson.
Match the requirement
Decide whether standards support, simple failover, or load sharing matters most.
Verify control state
Check peers, roles, virtual identity, timers, priority, and tracking.
Test the data path
Use a controlled failure to prove hosts retain gateway service.
HSRP vs VRRP vs GLBP at a Glance
Use this summary to establish the big picture before moving into commands, examples, and troubleshooting.
HSRP
Cisco-focused active and standby gateway redundancy.
VRRP
Standards-based master and backup gateway redundancy.
GLBP
Cisco gateway redundancy with host load sharing across forwarders.
FHRP comparison cheat sheet
| Characteristic | HSRP | VRRP | GLBP |
|---|---|---|---|
| Primary roles | Active / standby | Master / backup | AVG / AVF |
| Forwarders per group | One active | One master | Multiple AVFs possible |
| Design orientation | Cisco environments | Standards-based, multivendor | Cisco gateway load sharing |
| Higher priority preferred | Yes | Yes | Yes for AVG; AVF also uses weighting |
| Preemption | Configure explicitly | Commonly enabled by default | Role-specific behavior; configure deliberately |
| Host distribution | Across groups/VLANs by design | Across groups/VLANs by design | Built-in ARP-based virtual-MAC distribution |
| Concise verification | show standby brief | show vrrp brief | show glbp brief |
How to choose
Choose HSRP when
The environment is Cisco-focused, the operational team standardizes on HSRP, and simple active/standby behavior meets the goal.
Choose VRRP when
A standards-based protocol or multivendor interoperability is a primary requirement.
Choose GLBP when
Supported Cisco devices should distribute hosts across multiple gateway forwarders behind one virtual IP.
Also consider whether modern routed-access, stacking, chassis virtualization, or an anycast gateway changes the need for classic FHRP. Select the design first, then the protocol.
FHRP troubleshooting workflow
Protocol-neutral command checklist
show standby brief show standby show vrrp brief show vrrp show glbp brief show glbp
show ip interface brief show interfaces trunk show spanning-tree vlan 10 show ip route show track show ip arp 192.168.10.1
Collect outputs from both peers at the same time. A healthy-looking local state can be misleading if the peer sees a different VLAN, group, version, or authentication domain.
Symptoms, causes, and fixes
| Symptom | Likely cause | Corrective direction |
|---|---|---|
| Host cannot ARP for the VIP | No active/master/AVF, wrong VLAN, SVI down, or IP conflict | Verify group state, VLAN path, and duplicate addresses |
| Two active/master devices | Control messages do not pass or configurations differ | Check VLAN, multicast, version, group, timers, authentication |
| Wrong device forwards | Priority/preempt policy differs from design | Set explicit values and review recovery behavior |
| Gateway responds, remote path fails | Untracked upstream failure or missing route | Fix routing and track representative service health |
| Failure works, recovery flaps | Immediate preemption before dependencies converge | Add a supported preempt delay and test restoration |
| Intermittent asymmetric traffic | FHRP, STP root, and routing exit are misaligned | Align the preferred forwarder and Layer 2/3 topology |
Safe failover test plan
- Record baseline peer states, priorities, routes, tracking, ARP, and STP.
- Run client probes to the VIP and to a remote destination; these test different layers.
- Fail the active/master LAN interface, then restore it.
- Fail only the tracked uplink and verify priority or weighting changes.
- Power or reload a peer only in an approved lab or maintenance window.
- Measure traffic loss during both failover and recovery.
- Confirm MAC tables, ARP entries, routing, and preferred roles stabilize afterward.
Choosing and Testing an FHRP Design
Choose an FHRP based on platform support, interoperability, required load sharing and the operational habits of the team. A feature-rich protocol is not automatically the best choice if the environment needs a simple, predictable gateway and the team rarely operates the more advanced behavior.
Document the intended active device, virtual address, priority, preemption policy and tracking objects. Then test the dependency that tracking is meant to protect. Pulling a cable that is not tracked may prove only that the router can detect a physical failure, not that it can recognize a lost upstream service.
During a failover, observe gateway role, ARP or virtual MAC behavior, routing adjacency and application reachability. Record convergence time and any packet loss that matters to the workload. A test is complete when users can reach the required services again and the recovered device returns to its intended role without an unplanned second outage.
FHRP troubleshooting FAQs
Can pinging the virtual IP prove end-to-end health?
No. It proves the gateway can answer locally. Also test a remote destination and verify the routing path.
Should the STP root and active gateway match?
Usually yes for a VLAN. Alignment reduces traffic crossing between distribution switches before it is routed.
What is the most common design omission?
Failing to track upstream service health. A router can remain alive and keep the FHRP role after losing its useful exit path.
Review FHRP Fundamentals