First-hop redundancy protocols
Why hosts need a redundant default gateway and how HSRP, VRRP and GLBP provide virtual gateway failover at concept level.
Why FHRP exists
Hosts know exactly one default gateway. If that router dies, the subnet is cut off even when a second path exists — FHRPs solve this by presenting a virtual gateway: a virtual IP (and virtual MAC) shared by two or more routers. The host's gateway never changes; the active role moves between routers.
- Setup
- R1 pri 110, R2 pri 100, virtual 192.168.10.1
- Event
- R1's uplink (not the LAN) fails
- R1 keeps answering ARPs for the virtual MAC — LAN is still up — but it can't forward upstream.
- With
standby 10 track Gi0/1 50, the failed uplink drops R1's effective priority to 60. - R2 (100, preempt enabled) takes the virtual IP/MAC — hosts notice nothing but a few lost pings.
FHRP failover is client-transparent — the gateway IP/MAC never changes.
HSRP, VRRP, GLBP
FHRP protocols compared
| Protocol | Vendor | Roles | Load balancing | Virtual MAC |
|---|---|---|---|---|
| HSRP | Cisco | Active + Standby (+ listeners) | One active per group — balance via multiple groups | 0000.0c07.acXX (XX = group) |
| VRRP | Open (RFC 5798) | Master + Backup(s) | One master per group | 0000.5e00.01XX |
| GLBP | Cisco | AVG + AVFs | Per-client round-robin virtual MACs — true balancing in one group | 0007.b400.XXYY |
FHRP defaults (HSRP)
| Parameter | Default |
|---|---|
| Hello timer | 3 s |
| Hold timer | 10 s |
| Priority | 100 (higher wins) |
| Preemption | Disabled by default |
| Virtual MAC (HSRPv1) | 0000.0c07.acXX — v2 uses 0000.0c9f.fXXX; the MAC alone does not identify the physical active router |
With HSRP preemption off, a recovered higher-priority router does NOT take back the active role (VRRP would preempt).
Preemption and tracking
Preemption controls whether a router with higher priority takes the active/master role back after recovering. In HSRP it is off by default — like OSPF DR election, the incumbent keeps the role — while VRRP preempts by default. Enable standby <g> preempt on HSRP where deterministic roles matter. Tracking (standby <g> track <interface>) decrements priority when an uplink fails so the standby with a live upstream path wins.
Verifying FHRP
show standby/show vrrp— role, priority, timers, virtual addresses.- A virtual MAC in client ARP tables confirms the virtual router is being served — it does not identify which physical router holds the active role; check
show standby/show vrrpfor that. - Test failover by simulating uplink failure, not by rebooting — uplink tracking is the real-world trigger.
Common mistakes
- Expecting preemption by default — it's off; the current active keeps the role.
- Assuming HSRP balances traffic — only GLBP does per-client balancing in one group.
- Forgetting uplink tracking — a router with a dead WAN keeps the active role and blackholes the subnet.
- Pointing clients at individual router IPs — they must use the virtual IP.
Observation: R1's uplink is down; clients still lose connectivity.
- No priority tracking on the uplink
- R2's preempt not enabled
- Clients configured with R1's real IP instead of the virtual IP
| Check | Indicates |
|---|---|
show standby on both routers | Reveals actual priorities, tracked interfaces and preempt flags. |
| Client gateway address | A real-IP gateway means the client never used the FHRP. |
Correction: Add tracking and preempt, and point clients at the virtual IP.
Uplink failure flips the active role and client traffic reroutes automatically.
Related resources
Sources
- Cisco CCNA 200-301 v1.1 Exam Topics (official PDF) — reviewed 2026-11-02
- RFC 5798 — Virtual Router Redundancy Protocol (VRRP) Version 3 — reviewed 2026-11-02
Targets CCNA 200-301 v1.1 objectives. Supplemental blocks are labeled beyond exam scope.