If you’ve worked with HSRP or VRRP before, you already know their biggest limitation: only one router in the group actually forwards traffic at a time. The rest just sit there in standby, burning bandwidth and money while they wait for something to fail. That always bothered me on networks where I had two perfectly good routers and only one of them was doing any work.
GLBP was Cisco’s answer to that problem. I want to walk you through exactly how it works, how to configure it properly, and the mistakes I’ve seen (and made) when deploying it in production.
What GLBP Actually Solves
Gateway Load Balancing Protocol is a Cisco-proprietary first-hop redundancy protocol (FHRP), just like HSRP. But instead of electing one active router and leaving everyone else idle, GLBP lets multiple routers in a group forward traffic simultaneously. It does this by handing out different virtual MAC addresses to different hosts, all while those hosts think they’re pointing to a single default gateway IP.
I like to describe it this way: HSRP and VRRP give you one virtual gateway with one active forwarder. GLBP gives you one virtual gateway IP but up to four active forwarders sharing the load. That’s a meaningful difference if you’ve got expensive router hardware sitting idle half the time.
Networking Fundamentals You Need First
Before diving into GLBP specifics, you need to be comfortable with a few concepts:
- Default gateway: the device a host sends traffic to when the destination isn’t on its local subnet.
- First-hop redundancy: the general idea of having more than one router able to act as that default gateway, so a single router failure doesn’t take down the subnet.
- ARP and virtual MAC addresses: hosts resolve the gateway’s IP to a MAC address via ARP. FHRPs work by controlling which MAC address gets returned in that ARP response.
GLBP builds on all of this but adds a layer most engineers haven’t touched: it actually load-balances the ARP responses themselves.
How GLBP Works Under the Hood
A GLBP group elects one Active Virtual Gateway (AVG). The AVG is responsible for answering ARP requests for the shared virtual IP address, and it decides which physical router (called an Active Virtual Forwarder, or AVF) gets assigned to each host.
Here’s the flow I always explain to junior engineers:
- All routers in the GLBP group share a single virtual IP address.
- One router wins the AVG election based on priority (default 100, highest wins; tie broken by highest IP).
- The AVG assigns each member router (including itself) a unique virtual MAC address, making it an AVF.
- When a host ARPs for the gateway IP, the AVG replies with one of the AVF MAC addresses — round-robin, weighted, or host-dependent, depending on the load-balancing method configured.
- Each AVF forwards traffic sent to its own virtual MAC. If an AVF or the AVG fails, the remaining routers take over its responsibilities.
GLBP supports up to four AVFs per group, and it can run up to 1024 GLBP groups per interface (though I’ve never seen anyone need more than a handful).
Load-Balancing Methods
- Round-robin (default): each new ARP request is answered with the next AVF’s MAC in sequence.
- Weighted: AVFs with higher weight get proportionally more hosts assigned to them — useful when your routers aren’t identical in capacity.
- Host-dependent: the same host always gets mapped to the same AVF’s MAC, which keeps things predictable for troubleshooting or asymmetric routing concerns.
Basic GLBP Configuration
Let’s build a real lab. I’ll use two routers, R1 and R2, both connected to the same LAN segment on Gi0/0, sharing virtual IP 192.168.10.1.
On R1 (intended primary/AVG):
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 192.168.10.2 255.255.255.0
R1(config-if)# glbp 10 ip 192.168.10.1
R1(config-if)# glbp 10 priority 150
R1(config-if)# glbp 10 preempt
R1(config-if)# no shutdown
On R2 (secondary):
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip address 192.168.10.3 255.255.255.0
R2(config-if)# glbp 10 ip 192.168.10.1
R2(config-if)# glbp 10 priority 100
R2(config-if)# no shutdown
Notice I only enabled preempt on R1. That’s deliberate — preempt tells a router to reclaim the AVG role once it comes back online after a failure, and I generally only want that behavior on the router I’ve designated as primary, to avoid unnecessary flapping.
Verifying the Configuration
R1# show glbp brief
Interface Grp Fwd Pri State Address Active router Standby router
Gi0/0 10 - 150 Active 192.168.10.1 local 192.168.10.3
Gi0/0 10 1 - Active 0007.b400.0a01 local -
Gi0/0 10 2 - Listen 0007.b400.0a02 192.168.10.3 -
R1# show glbp
GigabitEthernet0/0 - Group 10
State is Active
2 state changes, last state change 00:04:12
Virtual IP address is 192.168.10.1
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.328 secs
Redirect time 600 sec, forwarder timeout 14400 sec
Preemption enabled, min delay 0 sec
Active is local
Standby is 192.168.10.3, priority 100 (expires in 9.600 sec)
Priority 150 (configured)
Weighting 100 (default 100), thresholds: lower 1, upper 100
Load balancing: round-robin
Group members:
0001.4200.1001 (192.168.10.2) local
0001.4200.2001 (192.168.10.3)
There are 2 forwarders (1 active)
Forwarder 1
State is Active
1 state change, last state change 00:04:11
MAC address is 0007.b400.0a01 (default)
Owner ID is 0001.4200.1001
Redirection enabled
Preemption enabled, min delay 0 sec
Active is local, weighting 100
I always check this output right after deployment — the “State is Active,” the group members list, and the forwarder count tell you immediately whether the election went the way you intended.
Enterprise Scenario: Load-Balancing a Distribution Layer
Here’s a real-world case I dealt with: a customer had two Cisco ISR routers acting as the gateway for a /24 subnet with roughly 200 hosts, and both routers had identical WAN uplinks. With HSRP, one router carried 100% of the outbound traffic while the other did nothing unless there was a failure. Switching to GLBP with weighted load balancing let both routers actively forward traffic, effectively doubling the usable throughput of that distribution layer without adding hardware.
Configuration for weighted load balancing looked like this:
R1(config-if)# glbp 10 load-balancing weighted
R1(config-if)# glbp 10 weighting 150
R2(config-if)# glbp 10 load-balancing weighted
R2(config-if)# glbp 10 weighting 100
With this setup, R1 (weighting 150) handles roughly 60% of hosts and R2 handles roughly 40%, matching their relative uplink capacity.
Securing GLBP with Authentication
GLBP hellos are sent as multicast UDP packets, and by default there’s no authentication. On a shared or less trusted segment, I always recommend enabling MD5 authentication to prevent a rogue device from injecting itself into the group and hijacking traffic.
R1(config-if)# glbp 10 authentication md5 key-string MyStrongKey123
R2(config-if)# glbp 10 authentication md5 key-string MyStrongKey123
Plaintext authentication also exists (glbp 10 authentication text PASSWORD) but I don’t recommend it — it offers essentially no real protection, just accidental-misconfiguration protection.
Tuning Timers
Default hello/hold timers are 3 seconds and 10 seconds. On links where you need faster failover — say, a data center core — you can tighten these, but be careful not to go so aggressive that normal jitter triggers false failovers.
R1(config-if)# glbp 10 timers 1 3
I generally don’t go below a 1-second hello on production hardware unless the platform and CPU headroom clearly support it.
Common Configuration Mistakes
- Mismatched GLBP group numbers or virtual IPs between routers — they’ll never form a group, and you’ll see each router thinking it’s alone.
- Forgetting preempt on the intended primary, leading to a permanently “wrong” AVG after a reboot.
- Not matching authentication strings — the group won’t form, but the failure mode isn’t always obvious in the logs.
- Assuming all four AVFs are always active — if you only have two routers, you only get two forwarders, no matter what the theoretical max is.
- Ignoring asymmetric routing concerns with round-robin load balancing when running stateful firewalls or NAT downstream — host-dependent balancing avoids a lot of headaches there.
Troubleshooting GLBP
My go-to commands, roughly in order:
show glbp
show glbp brief
debug glbp packets
debug glbp errors
show ip interface brief
If routers aren’t forming a group, check basic Layer 2/3 connectivity first (they need to be on the same subnet and able to exchange multicast hellos), then check for mismatched priorities, authentication, or ACLs blocking UDP port 3222.
Performance Tuning Notes
- Use weighted load balancing when your routers have different forwarding capacities.
- Use host-dependent balancing if you run stateful inspection or NAT downstream, to avoid asymmetric flows.
- Keep GLBP groups aligned with VLANs/subnets — don’t try to force one group across mismatched segments.
- Monitor forwarder counts with
show glbp briefafter any topology change to confirm load is actually being distributed as expected.
FAQs
Is GLBP better than HSRP or VRRP? It depends on your goal. If you need active-active load sharing across identical-cost links, GLBP wins. If you just need simple, standards-based failover, VRRP or HSRP is simpler to reason about.
Is GLBP a Cisco-only protocol? Yes. GLBP is Cisco proprietary and generally requires Cisco IOS/IOS-XE devices on both ends of the group.
How many routers can be in a GLBP group? Up to four AVFs, though only one AVG handles ARP responses at a time.
Does GLBP support IPv6? Yes, IOS supports GLBP for IPv6 as well, with largely the same configuration model.
Summary
GLBP gave me a way to stop wasting a perfectly capable second router. Instead of one router sitting idle in standby, I can spread load across both, tune how that load is distributed, and still get the automatic failover I’d get from HSRP or VRRP. The tradeoff is a bit more complexity — you’re now reasoning about AVGs, AVFs, and load-balancing methods instead of just active/standby — but for most enterprise distribution layers, that complexity is worth it.
