How to Configure First-Hop Redundancy with GLBP on Cisco Routers: Load Balancing and Failover

Abdul Wahab Junaid

3 years ago

How to Configure First-Hop Redundancy with GLBP on Cisco Routers

I always tell people learning first-hop redundancy protocols that HSRP and VRRP solve half the problem — they give you failover, but one router sits idle doing nothing until its partner dies. GLBP (Gateway Load Balancing Protocol) was Cisco’s answer to that waste: why let a perfectly healthy router sit as a cold standby when it could be actively forwarding traffic right now? That’s the entire value proposition of GLBP, and once you understand how it virtualizes multiple MAC addresses behind one virtual IP, the configuration is quick to pick up.

The Problem GLBP Solves

In a typical LAN, hosts point to a single default gateway IP address. If that gateway router fails, every device behind it loses its path out unless something takes over instantly. HSRP and VRRP solve this by presenting a virtual IP and virtual MAC shared by an active/standby router pair — but only the active router actually forwards traffic. The standby router’s uplink bandwidth goes completely unused during normal operation.

GLBP fixes this by allowing all members of the group to actively forward traffic simultaneously, while still presenting a single virtual IP to hosts. It achieves this cleverly: instead of one virtual MAC, GLBP hands out different virtual MAC addresses to different hosts in response to ARP requests, spreading traffic across all group members.

GLBP Roles and Terminology

AVG (Active Virtual Gateway) — one router per group elected to own the virtual IP and respond to ARP requests, assigning virtual MACs to AVFs
AVF (Active Virtual Forwarder) — each group member that actually forwards traffic for a portion of the client population, identified by its own virtual MAC
Virtual IP (VIP) — the single gateway IP address configured on all client devices
GLBP priority — determines AVG election, similar to HSRP priority
Weighting — determines a router’s forwarding capacity/eligibility as an AVF, useful for tracking interface health

GLBP Load-Balancing Methods

Round-robin — each AVF gets an equal share of ARP responses (default)
Weighted — AVFs get a share of traffic proportional to their configured weight
Host-dependent — a given host is always mapped to the same AVF, useful for maintaining session persistence

Topology for This Guide

Two routers, R1 and R2, both on the same LAN segment (VLAN 10, subnet 192.168.10.0/24), providing redundant/load-shared default gateway service for hosts in that VLAN.

Hosts (192.168.10.0/24) --- R1 (.2) --- R2 (.3) --- Upstream
                Virtual IP: 192.168.10.1

Step 1: Basic GLBP Configuration on R1

R1(config)# interface GigabitEthernet0/1
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

Step 2: Basic GLBP Configuration on R2

R2(config)# interface GigabitEthernet0/1
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)# glbp 10 preempt

R1, with the higher priority (150 vs 100), becomes the AVG. Both routers, however, still act as AVFs and forward traffic for their share of client ARP responses.

Step 3: Choose a Load-Balancing Method

Round-robin is default, but you can be explicit or switch to weighted:

R1(config-if)# glbp 10 load-balancing round-robin

For weighted distribution, favoring R1 with more forwarding capacity:

R1(config-if)# glbp 10 weighting 150
R1(config-if)# glbp 10 load-balancing weighted
R2(config-if)# glbp 10 weighting 100
R2(config-if)# glbp 10 load-balancing weighted

With weighted load balancing, R1 (weight 150) receives proportionally more client assignments than R2 (weight 100).

Step 4: Object Tracking for Uplink Failure

Just like HSRP, GLBP should track upstream interface health so a router with a dead WAN uplink stops being preferred as AVG/AVF:

R1(config)# track 1 interface GigabitEthernet0/2 line-protocol
R1(config)# interface GigabitEthernet0/1
R1(config-if)# glbp 10 weighting track 1 decrement 60

If GigabitEthernet0/2 (the upstream link) goes down, R1’s weighting drops by 60, potentially falling below the forwarding threshold and shifting traffic to R2.

Set the lower threshold that determines when a router stops being an AVF:

R1(config-if)# glbp 10 weighting 150 lower 90 upper 140

Step 5: Authentication (Recommended for Production)

R1(config-if)# glbp 10 authentication md5 key-string GLBPSecureKey123
R2(config-if)# glbp 10 authentication md5 key-string GLBPSecureKey123

This prevents rogue routers from joining the GLBP group and hijacking gateway responsibilities.

Step 6: Verification

R1# show glbp brief
Interface   Grp  Fwd Pri State    Address         Active router   Standby router
Gi0/1       10   -   150 Active   192.168.10.1    local           192.168.10.3
Gi0/1       10   1   150 Active   192.168.10.2    local           -
Gi0/1       10   2   100 Listen   192.168.10.4    192.168.10.3    -

Detailed view:

R1# show glbp GigabitEthernet0/1 10
GigabitEthernet0/1 - Group 10
  State is Active
    2 state changes, last state change 00:14:32
  Virtual IP address is 192.168.10.1
  Hello time 3 sec, hold time 10 sec
  Redirect time 600 sec, forwarder time-out 14400 sec
  Preemption enabled, min delay 0 sec
  Active is local
  Standby is 192.168.10.3, priority 100 (expires in 9.632 sec)
  Priority 150 (configured)
  Weighting 150 (configured 150), thresholds: lower 90, upper 140
  Load balancing: round-robin
  Group members:
    aabb.cc00.1000 (192.168.10.2) local
    aabb.cc00.2000 (192.168.10.3)
  There are 2 forwarders (1 active)
  Forwarder 1
    State is Active
    1 state change, last state change 00:14:20
    MAC address is 0007.b400.0a01 (default)
    Owner ID is aabb.cc00.1000
    Time to live: 14400 sec (14382.192 sec remaining)
    Preemption enabled, min delay 0 sec
    Active is local, weighting 150

Check ARP resolution to confirm clients are receiving different virtual MACs:

Host1# arp -a
? (192.168.10.1) at 0007.b400.0a01 [ether] on eth0
Host2# arp -a
? (192.168.10.1) at 0007.b400.0a02 [ether] on eth0

Note both hosts resolved the same virtual IP but to different virtual MAC addresses, confirming load distribution is working.

Real-World Enterprise Scenario

Consider a branch office with two edge routers dual-homed to different ISPs for redundancy. With HSRP, one router would sit idle unless the active one failed — wasting half the available WAN capacity during normal operation. Switching to GLBP lets both routers actively forward traffic for different client subsets simultaneously, doubling effective outbound throughput utilization during steady-state operation while still providing seamless failover if either router or its uplink fails. This is a very common design pattern for branch and campus edge redundancy where bandwidth utilization efficiency matters as much as availability.

Security Best Practices

Always enable MD5 authentication on GLBP groups in production, since default GLBP has no built-in trust verification
Restrict which VLANs/interfaces GLBP can operate on using access control at the switch/VLAN boundary
Use object tracking on both routers so a WAN failure properly demotes forwarding priority rather than blackholing traffic silently
Log and alert on %GLBP-6- state change syslog messages to detect flapping early

Common Configuration Mistakes

Forgetting preempt, meaning a higher-priority router won’t reclaim AVG status after recovering from a failure
Mismatched GLBP group numbers or virtual IPs between routers, resulting in two separate GLBP groups instead of one
Not configuring object tracking, so a dead upstream link doesn’t affect GLBP weighting/priority
Assuming GLBP requires identical configuration on both routers — priorities and weights are intentionally different to control AVG/AVF behavior
Overlooking authentication, leaving the group vulnerable to spoofed GLBP hellos

Troubleshooting Checklist

show glbp brief — quick overview of group state across routers
show glbp <interface> <group> — detailed AVG/AVF and forwarder status
Confirm hello/hold timers match between routers (glbp 10 timers)
Verify VLAN/interface connectivity between GLBP peers (they must be Layer 2 adjacent)
Check for authentication mismatches if a router unexpectedly fails to join the group

Performance Tuning

Lower glbp 10 timers hello/hold values in latency-sensitive environments for faster failover detection, but avoid making them so aggressive that normal jitter triggers false failovers
Use weighted load balancing intentionally when your routers have unequal uplink bandwidth, rather than relying on default round-robin
Monitor per-forwarder traffic distribution with show glbp counters to confirm real-world load is actually balanced as expected

FAQs

How is GLBP different from HSRP and VRRP? HSRP and VRRP use a single active router for forwarding with others in standby; GLBP allows multiple routers to actively forward simultaneously via distinct virtual MACs.

Is GLBP a Cisco-proprietary protocol? Yes, unlike VRRP (an open IETF standard), GLBP is Cisco proprietary and only runs between Cisco devices.

Can GLBP support more than two routers in a group? Yes, GLBP supports up to four active forwarders per group, elected by the AVG.

Does GLBP require the same subnet on all member routers? Yes, all GLBP group members must share the same Layer 2 segment and subnet.

Summary

GLBP earns its place in the first-hop redundancy conversation by refusing to let a healthy router sit idle. By separating the AVG (control plane) role from multiple AVFs (data plane), it spreads outbound traffic across every group member while preserving the simplicity of a single virtual gateway IP for hosts. Combine it with MD5 authentication and object tracking on WAN uplinks, and you get both efficient bandwidth utilization and fast, safe failover in one package.

References

Cisco: Configuring GLBP
Cisco IOS-XE First Hop Redundancy Protocols Configuration Guide