Every device on a LAN is configured with a default gateway — a single IP address it sends all traffic to when the destination is outside its own subnet. But what happens if that gateway router fails? Every single host relying on it instantly loses connectivity to anything beyond the local subnet, even if a perfectly good backup router sits right next to it. First Hop Redundancy Protocols (FHRPs) solve this single point of failure by allowing multiple routers to share a virtual IP address, so if one fails, another instantly and transparently takes over.
The Problem: A Single Point of Failure
Consider a subnet 192.168.1.0/24 with hosts configured to use 192.168.1.1 as their default gateway — the LAN interface of Router A. If Router A crashes, loses power, or its interface fails, every host on that subnet loses all off-subnet connectivity, even if Router B is sitting right there, fully functional, with its own interface on the same subnet. Hosts have no built-in mechanism to detect the failure and switch to Router B automatically — they were configured with one static gateway IP.
flowchart TD
subgraph LAN 192.168.1.0/24
PC1[Host A]
PC2[Host B]
end
RA[Router A<br/>192.168.1.2]
RB[Router B<br/>192.168.1.3]
PC1 -.Default Gateway.-> RA
PC2 -.Default Gateway.-> RA
RA --> Internet1[Internet/WAN]
RB --> Internet2[Internet/WAN]
style RA fill:#f66The Solution: A Shared Virtual Gateway
FHRPs solve this by creating a virtual IP address (and virtual MAC address) that is shared between two or more physical routers. Hosts are configured to use this virtual IP as their default gateway, instead of any single router’s real interface IP. Behind the scenes, the routers elect an active/primary router that actually forwards traffic for that virtual IP. If the active router fails, a standby/backup router detects the failure (through missed hello messages) and takes over the virtual IP and MAC almost instantly — often within one to three seconds — with zero reconfiguration needed on the end hosts.
flowchart TD
subgraph LAN 192.168.1.0/24
PC1[Host A]
PC2[Host B]
end
VIP[Virtual IP: 192.168.1.1<br/>Virtual MAC: shared]
RA[Router A - ACTIVE<br/>Real IP: 192.168.1.2]
RB[Router B - STANDBY<br/>Real IP: 192.168.1.3]
PC1 -.Default Gateway.-> VIP
PC2 -.Default Gateway.-> VIP
VIP --- RA
VIP -.failover.-> RBThe Three Major FHRP Protocols
| Protocol | Full Name | Vendor | Key Characteristic |
|---|---|---|---|
| HSRP | Hot Standby Router Protocol | Cisco proprietary | Active/Standby model; simple and widely deployed |
| VRRP | Virtual Router Redundancy Protocol | Open standard (RFC 5798) | Multi-vendor interoperable; Master/Backup model |
| GLBP | Gateway Load Balancing Protocol | Cisco proprietary | Adds load balancing — multiple routers actively forward traffic simultaneously |
Key Conceptual Difference: HSRP/VRRP vs GLBP
HSRP and VRRP both follow an Active/Standby model — only one router forwards traffic for the virtual IP at any given time; the other(s) sit idle, ready to take over. This is simple and predictable but means the standby router’s capacity is “wasted” during normal operation.
GLBP improves on this by allowing multiple routers to actively forward traffic simultaneously — it acts like a virtual gateway that load-balances which physical router handles each host’s traffic (via ARP responses returning different virtual MAC addresses to different hosts), making better use of all available router capacity.
How HSRP Works, Step by Step
- Routers participating in an HSRP group are assigned priorities (default 100; higher wins).
- The router with the highest priority becomes Active; the next-highest becomes Standby.
- Both exchange periodic Hello messages (multicast, by default every 3 seconds) to confirm they are alive.
- If the Active router misses Hello messages for the hold time (default 10 seconds), the Standby router assumes the Active role and takes over the virtual IP/MAC.
- Optionally, preemption can be configured so that when a higher-priority router comes back online after a failure, it reclaims the Active role automatically.
sequenceDiagram
participant RA as Router A (Active)
participant RB as Router B (Standby)
loop Every 3 seconds
RA->>RB: HSRP Hello (Active, priority 110)
RB->>RA: HSRP Hello (Standby, priority 100)
end
Note over RA: Router A fails / interface goes down
Note over RB: No Hello received for 10 seconds (hold time)
RB->>RB: Assumes Active role, takes over Virtual IP + MACConfiguring HSRP on Cisco IOS
Router A (intended primary — higher priority)
RouterA(config)# interface GigabitEthernet0/1
RouterA(config-if)# ip address 192.168.1.2 255.255.255.0
RouterA(config-if)# standby 1 ip 192.168.1.1
RouterA(config-if)# standby 1 priority 110
RouterA(config-if)# standby 1 preemptRouter B (standby — lower/default priority)
RouterB(config)# interface GigabitEthernet0/1
RouterB(config-if)# ip address 192.168.1.3 255.255.255.0
RouterB(config-if)# standby 1 ip 192.168.1.1
RouterB(config-if)# standby 1 priority 100
RouterB(config-if)# standby 1 preemptHosts on this subnet are then configured with 192.168.1.1 as their default gateway — a virtual address neither router “owns” individually.
Enabling Interface Tracking (Important Real-World Addition)
A router can still show as “up” and win the HSRP election even if its uplink/WAN interface has failed — meaning it would become Active but have no actual path forward, a scenario called “black-holing” traffic. Interface tracking solves this by reducing a router’s HSRP priority automatically if a tracked interface goes down, allowing the other router to take over even though the LAN-facing interface itself is still up.
RouterA(config-if)# standby 1 track GigabitEthernet0/0 decrement 20If Router A’s WAN interface (Gi0/0) fails, its HSRP priority drops by 20 (from 110 to 90), falling below Router B’s priority of 100, causing Router B to become Active instead.
Verifying HSRP
Router# show standby briefInterface Grp Pri P State Active Standby Virtual IP
Gi0/1 1 110 P Active local 192.168.1.3 192.168.1.1Router# show standbyGigabitEthernet0/1 - Group 1
State is Active
9 state changes, last state change 00:15:32
Virtual IP address is 192.168.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
Preemption enabled
Active router is local
Standby router is 192.168.1.3, priority 100
Priority 110 (configured 110)Configuring VRRP (Vendor-Neutral Alternative)
RouterA(config)# interface GigabitEthernet0/1
RouterA(config-if)# ip address 192.168.1.2 255.255.255.0
RouterA(config-if)# vrrp 1 ip 192.168.1.1
RouterA(config-if)# vrrp 1 priority 110Verify:
Router# show vrrp briefVRRP terminology differs slightly (Master/Backup instead of Active/Standby), but the underlying purpose and mechanism are conceptually identical to HSRP — a shared virtual IP with automatic failover.
Comparison Table: HSRP vs VRRP vs GLBP
| Feature | HSRP | VRRP | GLBP |
|---|---|---|---|
| Vendor | Cisco proprietary | Open standard | Cisco proprietary |
| Roles | Active / Standby | Master / Backup | Active Virtual Gateway (AVG) + Active Virtual Forwarders (AVFs) |
| Load balancing across routers | No (only one forwards) | No (only one forwards) | Yes (multiple routers forward simultaneously) |
| Default Hello Timer | 3 sec | 1 sec | 3 sec |
| Virtual MAC | 0000.0c07.acXX | 0000.5e00.01XX | Multiple virtual MACs, one per AVF |
| Multi-vendor interoperability | No | Yes | No |
FHRP on Linux — keepalived (VRRP Implementation)
Linux servers acting as gateways or load balancers commonly use keepalived, which implements VRRP, to achieve the same first-hop redundancy concept.
sudo apt install keepalived -y
sudo nano /etc/keepalived/keepalived.confvrrp_instance VI_1 {
state MASTER
interface eth0
virtual_router_id 51
priority 110
advert_int 1
virtual_ipaddress {
192.168.1.1
}
}sudo systemctl restart keepalived
sudo systemctl status keepalived
ip addr show eth0 # virtual IP appears here when this node is MasterThis is exactly the same underlying concept as Cisco HSRP/VRRP, just implemented in software on a Linux host — commonly used for redundant Linux-based firewalls, load balancers, or gateway VMs.
Simulating FHRP Failover Logic in Python
class FHRPRouter:
def __init__(self, name, priority):
self.name = name
self.priority = priority
self.alive = True
def elect_active(routers):
candidates = [r for r in routers if r.alive]
if not candidates:
return None
return max(candidates, key=lambda r: r.priority)
router_a = FHRPRouter("RouterA", 110)
router_b = FHRPRouter("RouterB", 100)
routers = [router_a, router_b]
active = elect_active(routers)
print(f"Active router: {active.name}")
# Simulate Router A failing
router_a.alive = False
active = elect_active(routers)
print(f"After failure, Active router: {active.name}")Output:
Active router: RouterA
After failure, Active router: RouterBThis mirrors the essential logic of FHRP election — highest priority among alive candidates wins the Active role.
Best Practices
- Always configure object/interface tracking so that WAN/uplink failures trigger failover, not just direct interface-down events.
- Use preemption carefully — while it ensures the intended primary router resumes control after recovery, it can cause a brief, unnecessary “flap” if the recovering router is unstable (consider a
preempt delay). - Keep Hello and Hold timers consistent with your failover speed requirements — faster timers mean quicker failover but more control-plane overhead.
- Use VRRP instead of HSRP in multi-vendor environments where interoperability with non-Cisco equipment is required.
- Document virtual IP addresses clearly and separately from real router interface IPs to avoid confusion during troubleshooting.
- Consider GLBP when you want to actively use the capacity of all redundant routers rather than leaving a standby router idle.
Troubleshooting
| Symptom | Likely Cause | Fix |
|---|---|---|
| Both routers claim Active simultaneously (“split-brain”) | Hello messages blocked (ACL, VLAN misconfiguration, or physical link failure between routers) | Verify Layer 2 connectivity and multicast/ACL permissions for HSRP/VRRP hellos |
| Failover doesn’t happen when uplink fails | No interface tracking configured | Add standby track (HSRP) or equivalent VRRP tracking |
| Failover works, but wrong router remains Active after recovery | Preemption not configured, or priorities misconfigured | Verify standby preempt and priority values |
| Hosts lose connectivity despite standby router being healthy | Hosts configured with a real router IP instead of the virtual IP as gateway | Correct host default gateway configuration to use the virtual IP |
| Virtual MAC conflicts with another HSRP group | Duplicate group numbers on the same VLAN | Use unique HSRP/VRRP group numbers per VLAN/subnet |
Conclusion
First Hop Redundancy Protocols eliminate the default gateway as a single point of failure by allowing two or more routers to share a virtual IP and MAC address, with automatic, near-instant failover if the active router fails — all without requiring any reconfiguration on end hosts. Whether using Cisco’s HSRP, the open-standard VRRP, or the load-balancing GLBP, the underlying goal is the same: keep the “first hop” out of the local network reliable, even when individual hardware fails.
References
- RFC 5798 – Virtual Router Redundancy Protocol (VRRP) Version 3 — https://datatracker.ietf.org/doc/html/rfc5798
- Cisco HSRP Configuration Guide — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-16/fhp-xe-16-book/fhp-hsrp.html
- Cisco GLBP Overview — https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipapp_fhrp/configuration/xe-16/fhp-xe-16-book/fhp-glbp.html
- keepalived Documentation — https://www.keepalived.org/manpage.html
- Cisco First Hop Redundancy Protocols Comparison — https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/hot-standby-router-protocol-hsrp/product_data_sheet0900aecd8007ffee.html
