HSRP, VRRP and GLBP all solve the same problem, giving a LAN a default gateway that survives losing a router, but they make different trade-offs. HSRP is Cisco's default, simple and widely deployed. VRRP is the open standard, vendor neutral, with a faster default failure detector. GLBP is Cisco's load-balancing variant, more complex, but it is the only one of the three that puts traffic on both routers at the same time for the same gateway address.
Most comparisons of these three protocols are a table and nothing else. This one is built on a lab where all three run simultaneously on the same pair of routers: two iol-xe nodes in CML on IOS XE 17.18.2, three parallel segments, one FHRP each. HSRP group 10 on Et0/0, VRRP group 20 on Et0/1, GLBP group 30 on Et0/2. R1 carries priority 110 on all three, so R1 should win every election, and the interesting question is what R2 does while it is losing.
The short answer, before any of the detail: under HSRP and VRRP, R2 sits there and listens. Under GLBP, R2 is an active forwarder for the same virtual IP R1 owns. That is the one difference that changes your capacity planning. Almost everything else is vocabulary, default timers and vendor politics.
All Three Protocols, One Pair of Routers
The configuration side is small enough to show in full. This is R1, the preferred router, with priority 110 on every group:
interface Et0/0
standby 10 ip 10.0.10.254
standby 10 priority 110
standby 10 preempt
!
fhrp version vrrp v3
interface Et0/1
vrrp 20 address-family ipv4
address 10.0.20.254
priority 110
!
interface Et0/2
glbp 30 ip 10.0.30.254
glbp 30 priority 110
glbp 30 preemptR2 is identical except that it leaves priority at the default 100 and does not set preempt. That asymmetry matters later, when R1 comes back from the failover test.
Notice the VRRP stanza does not look like the VRRP you remember. The legacy vrrp 20 ip 10.0.20.254 one-liner is gone on modern IOS XE: you enable fhrp version vrrp v3 globally, then configure the group under an address family. If a decade-old VRRP config silently does nothing on a 17.x box, that is why.
HSRP: One Active, One Standby
Start with the protocol most networks already run. HSRP elects one Active router and one Standby router per group, and only the Active forwards. Here is the same command on both routers in steady state:
R1# show standby brief
P indicates configured to preempt.
|
Interface Grp Pri P State Active Standby Virtual IP
Et0/0 10 110 P Active local 10.0.10.2 10.0.10.254
R2# show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Et0/0 10 100 Standby 10.0.10.1 local 10.0.10.254Read those two blocks together and nothing is left ambiguous. R1 says it is Active with local in the Active column and 10.0.10.2 as its Standby, R2 says the reverse, and both print the same virtual IP. The P flag appears on R1 only, because only R1 was configured to preempt. (If both routers print Active with Standby unknown, the hellos are not crossing and you have a different article to read.)
The brief output does not show you the virtual MAC, which is the detail that actually identifies the protocol on the wire. For that you need show standby with no keyword:
Ethernet0/0 - Group 10
State is Active
2 state changes, last state change 00:01:04
Virtual IP address is 10.0.10.254
Active virtual MAC address is 0000.0c07.ac0a (MAC In Use) <-- 0000.0c07.acXX, XX = group
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.712 secs
Preemption enabled
Active router is local
Standby router is 10.0.10.2, priority 100 (expires in 10.672 sec)
Priority 110 (configured 110)
Group name is "hsrp-Et0/0-10" (default)Group 10 is 0x0a, and the virtual MAC ends in ac0a. The mapping is that direct. Note also the timers printed here, hello 3 seconds and hold 10 seconds, because those are the numbers VRRP is about to beat. If you want the full build rather than the verification, the walkthrough on setting up an HSRP group from scratch covers priority, preempt and tracking in order.
VRRP: Master and Backup, and a Faster Default Clock
VRRP does the same job with different words. There is no Active and no Standby. There is a MASTER and there are BACKUPs:
R1# show vrrp brief
Interface Grp A-F Pri Time Own Pre State Master addr/Group addr
Et0/1 20 IPv4 110 0 N Y MASTER 10.0.20.1(local) 10.0.20.254
R2# show vrrp brief
Interface Grp A-F Pri Time Own Pre State Master addr/Group addr
Et0/1 20 IPv4 100 3609 N Y BACKUP 10.0.20.1 10.0.20.254Three fields are worth stopping on. A-F is the address family, which only exists because this is VRRPv3. Own is N on both routers, meaning neither owns 10.0.20.254 as a real interface address (if one did, it would run at priority 255 and the election would be over before it started). Pre is Y on both, and that is a default: VRRP preempts unless you turn it off, which is the opposite of HSRP and an easy way to surprise yourself during a migration.
The Time column is the one worth internalising. It is the master down interval in milliseconds, and R2 prints 3609. That is not a round number by accident. VRRP's master down interval is three advertisement intervals plus a skew derived from priority: 3 x 1000 ms, plus ((256 - 100) / 256) x 1000, which is 609 ms. A lower priority backup waits fractionally longer before declaring the master dead, which is how VRRP breaks ties between multiple backups without a fight. R1 prints 0 because it is the master and is not waiting for anybody.
So on defaults, VRRP declares failure at roughly 3.6 seconds where HSRP waits its full 10 second hold. That is the only performance argument for VRRP that survives contact with a lab, and it disappears the moment you tune HSRP timers, which most production designs do. For the election mechanics and the priority 255 owner case, see how VRRP elects a master, and if you want to type it out yourself there is a hands-on lab that runs VRRP and HSRP side by side.
GLBP: Both Routers Forward for the Same Virtual IP
This is the section that justifies the whole comparison. GLBP splits the job in two. One router is the Active Virtual Gateway (AVG), which answers ARP for the virtual IP. Up to four routers are Active Virtual Forwarders (AVFs), each owning its own virtual MAC. The AVG hands out different forwarder MACs to different hosts as they ARP, so traffic for one gateway address leaves the subnet through more than one router.
Here is what that looks like on both sides:
R1# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Et0/2 30 - 110 Active 10.0.30.254 local 10.0.30.2
Et0/2 30 1 - Active 0007.b400.1e01 local -
Et0/2 30 2 - Listen 0007.b400.1e02 10.0.30.2 -
R2# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Et0/2 30 - 100 Standby 10.0.30.254 10.0.30.1 local
Et0/2 30 1 - Listen 0007.b400.1e01 10.0.30.1 -
Et0/2 30 2 - Active 0007.b400.1e02 local -The Fwd column is the key. The row with - is the gateway role, and there R1 is Active and R2 is Standby, which reads exactly like HSRP. The numbered rows are the forwarder roles, and there the picture inverts: R1 is Active for forwarder 1 and only Listening for forwarder 2, while R2 is Active for forwarder 2 and only Listening for forwarder 1.
Put plainly, R2 is the standby gateway and a live forwarder at the same time. It is passing data plane traffic for 10.0.30.254 while R1 is perfectly healthy. Do the same comparison on the HSRP segment and R2 is doing nothing but counting hellos. That is the difference, and it is the reason GLBP exists.
The virtual MACs decode as neatly as HSRP's. Group 30 is 0x1e, and the two forwarders are 0007.b400.1e01 and 0007.b400.1e02: group, then forwarder number. You can read a GLBP show mac address-table and know immediately which forwarder a host was handed.
One honest caveat about what this proves. There were no clients on the GLBP segment, so you are seeing both routers hold an Active forwarder role, not a measured 50/50 traffic split. The split follows from the roles: the AVG round-robins forwarder MACs across ARP replies by default, so with enough hosts the load lands roughly evenly. With four hosts and one of them running a backup job, it will not. The weighted and host-dependent balancing modes exist precisely because round-robin is a poor proxy for bytes.
The Virtual MAC Is the Fingerprint
If you inherit a network and want to know which FHRP is running without reading anybody's configuration, look at the gateway MAC in a host ARP table. Each protocol owns a distinct range, and the group number is encoded in it:
The HSRP and GLBP values above came straight out of this lab. The VRRP one is the range from RFC 5798, because show vrrp brief does not print the virtual MAC at all, which is a small but real operational annoyance when you are trying to match a MAC to a router in a hurry.
The GLBP range has a practical consequence. HSRP and VRRP put one extra MAC per group into every switch CAM table on the segment. GLBP puts up to four. On a large campus with many groups that is not free, and it is one of the quieter reasons GLBP stays rare.
The Side-by-Side Comparison
Watching a Failover Actually Happen
Steady state output is only half the story. The lab shut R1's HSRP interface on a timer to see what the pair does when the preferred router disappears. R1 first:
*Jul 20 22:34:11.877: %HSRP-5-STATECHANGE: Ethernet0/0 Grp 10 state Active -> Init
Interface Grp Pri P State Active Standby Virtual IP
Et0/0 10 110 P Init unknown unknown 10.0.10.254R1 keeps its priority of 110 and its preempt flag, but it is in Init and it has no idea who the Active or Standby routers are, because it cannot hear anything. The detail view goes further and reports State is Init (interface down) along with Active virtual MAC address is unknown (MAC Not In Use). That last phrase is the one to remember: a router in Init is not just not forwarding, it has stopped answering for the virtual MAC entirely.
Now R2, one millisecond earlier on its own clock:
*Jul 20 22:34:11.876: %HSRP-5-STATECHANGE: Ethernet0/0 Grp 10 state Standby -> Active
Interface Grp Pri P State Active Standby Virtual IP
Et0/0 10 100 Active local unknown 10.0.10.254Two things there are worth arguing about at design review. First, R2 took over immediately rather than waiting out a 10 second hold. An administrative shutdown is a graceful exit, so the Active router sends a Resign and the Standby promotes on the spot. The 10 second hold is the worst case, what you pay when the Active dies silently. To see it actually elapse you have to break the path without telling the router about it.
Second, R2 has no P in its state line and R1 does. When R1 comes back it preempts, and the gateway moves a second time. That is usually what you want with an asymmetric design, but it is also a second outage window, and it is why preempt delay exists. VRRP would have done this without you asking.
When HSRP Wins
- You are a Cisco-only shop. HSRP is the default, well understood, and universally documented for Cisco networks.
- Your operators are HSRP-trained. Switching to VRRP for marginal benefits is rarely worth retraining.
- You want simple operations. The HSRP state machine is more verbose than VRRP's, but
show standby briefanswers the only question that matters in one line, and the troubleshooting tooling is mature. - You want the failover behavior to be explicit. HSRP does not preempt unless you tell it to, which makes "who is Active right now" a decision you made rather than one the protocol made for you.
- You inherited an HSRP deployment. Migrating to something else is rarely justified by performance or cost.
When VRRP Wins
- Multi-vendor environment. Mandatory if any non-Cisco router participates in the FHRP group. HSRP and GLBP are not options here at all.
- Faster default failure detection matters. The 3.609 second master down interval this lab printed is genuinely better than HSRP's 10 second hold, if you are stuck on defaults.
- You want IETF-standard protocols across the board. Operational discipline and vendor neutrality as a policy, not a performance argument.
- VRRPv3 IPv6 design. The address-family syntax handles IPv4 and IPv6 in the same group structure, which is cleaner than bolting an IPv6 group onto HSRPv2.
When GLBP Wins
- You specifically need active/active gateway forwarding without splitting VLANs. The lab output above is the whole argument: both routers Active for one virtual IP, no per-VLAN choreography required.
- Cisco-only with homogeneous routers. GLBP needs Cisco on both ends and works best when the forwarders have similar capacity, because the default hand-out does not know or care that one of them is smaller.
- You have idle redundant capacity and a single large VLAN where the per-VLAN trick does not help you.
In practice, GLBP shows up less often than its capabilities suggest. Most Cisco campus designs use HSRP with different active gateways per VLAN, which achieves load distribution at the VLAN level without GLBP's extra virtual MACs, extra state and extra explaining at 3am.
Failover Times Compared
The second row is the one most comparisons leave out. The failover this lab captured completed instantly, because a shutdown is a polite exit. Default timers only decide how long you wait when a router dies without saying goodbye, which is exactly the case your maintenance window will never reproduce. With BFD or interface tracking driving the decision, all three converge in similar timeframes and the protocol you picked stops mattering.
Design Impact
The most common production pattern across all three:
- Two distribution switches per VLAN
- FHRP (HSRP, VRRP or GLBP) configured for the VLAN
- Object tracking on the upstream interface to decrement priority or weighting on uplink failure
- STP root alignment with the active FHRP gateway per VLAN
- For HSRP and VRRP: alternate which switch is active per VLAN to spread load
- For GLBP: both switches active in the same VLAN, hosts distributed automatically
HSRP and VRRP achieve load distribution by being active on different VLANs on different switches. GLBP achieves it inside a single VLAN by handing different hosts different forwarder MACs, which is what the Fwd 1 and Fwd 2 rows above are showing you. The per-VLAN approach is more common because it lines up with per-VLAN STP root assignment, and because a human can look at a diagram and say which box carries which VLAN.
Step 3 is the one people skip, and it is the one that causes the outage where the gateway stays Active on a router that has lost its uplink. Whichever FHRP you run, wire the priority to something real: an interface, a route, or an IP SLA probe that tests whether the upstream path is actually usable. For the STP side of the same problem, the write-up on keeping the spanning tree root on the same box as the active gateway covers why a misaligned pair sends every packet across your interswitch link twice.
Migrating Between FHRPs
Migration paths exist but are operationally fragile:
The "configure the new one alongside the old one, migrate, then remove" approach minimises disruption. Both FHRPs run at once on different group numbers and different virtual IPs, and hosts keep the old gateway address until DHCP renews them onto the new one. The failure mode to watch for is the half-migrated subnet where your ACLs only permit one of the two gateways.
Recommendations
Default recommendations for typical scenarios:
What This Was Captured On
iol-xe nodes, IOS XE 17.18.2Gotchas
- The legacy VRRP one-liner is gone on modern IOS XE. You need
fhrp version vrrp v3and thenvrrp 20 address-family ipv4with the address as a sub-command. Old configs and old study guides both mislead you here. - VRRP preempts by default and HSRP does not. Migrate a design that relied on "whoever came up first stays Active" and VRRP will quietly invert it the first time a router reloads.
- A GLBP standby gateway is not idle. R2 is the standby AVG while being the Active forwarder for
0007.b400.1e02. Take that router out for maintenance expecting it to be doing nothing and you are dropping live sessions. - Do not read
show glbp briefas one state. There is a gateway row and there are forwarder rows, and they disagree on purpose. TheFwdcolumn tells them apart. - Default timers do not describe an administrative shutdown. The 10 second hold and 3.6 second master down interval only apply to silent failures, so testing failover by shutting a port always looks better than reality.
- Two Actives is a hello problem, not a priority problem. If both routers claim the role and both print
Standby unknown, the protocol is fine and the path between them is not. That failure has its own walkthrough on what to check when both routers say they are Active.
Key Takeaways
- The only functional difference between the three is whether the backup forwards. HSRP and VRRP keep it idle, GLBP does not.
- Vocabulary maps directly: Active/Standby is HSRP, MASTER/BACKUP is VRRP, AVG plus AVF is GLBP.
- The virtual MAC identifies the protocol and encodes the group:
0000.0c07.ac0ais HSRP group 10,0007.b400.1e01is GLBP group 30 forwarder 1. - VRRP's advantage on defaults is real but small: a 3.609 second master down interval against HSRP's 10 second hold, and it evaporates as soon as you tune timers or add tracking.
- GLBP costs up to four virtual MACs per group in every CAM table on the segment, which is a large part of why per-VLAN HSRP won the deployment argument.
- Whatever you pick, the priority has to track something real. An FHRP that stays Active on a router with a dead uplink is worse than no FHRP at all.
Summary
HSRP for Cisco-only simplicity. VRRP for multi-vendor networks and an IETF-standard preference. GLBP for the specific case where you need two routers forwarding for one gateway address inside one VLAN. All three converge in similar time once you tune them or drive them from BFD, and all three fail over instantly when a router leaves gracefully. Default timers favor VRRP, and the lab printed the exact number: 3,609 milliseconds against 10 seconds.
The right answer is mostly determined by what is already in your network. Most enterprises run HSRP because they were Cisco shops and HSRP was the default, and few have a real reason to migrate. If you are choosing rather than inheriting, work through the rest of the first-hop redundancy protocol guides and pick based on what your operators can troubleshoot at 3am, not on a millisecond in a datasheet.