Hands-On Lab: Configuring GLBP Weighting for Load Balancing Control

This hands-on lab configures GLBP weighting tied to interface tracking, allowing the proportion of clients each forwarder serves to shift automatically based on a router's own health rather than always splitting load evenly, refining the basic GLBP configuration covered earlier in this series.

GLBP WeightingWeighted Load BalancingGLBP Interface Tracking

~4 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

Lab Objective

Configure GLBP weighting on two routers so their initial weight reflects the number of healthy uplinks, link weighting to interface tracking, and verify the load-balancing ratio between the two forwarders shifts automatically when one router loses an uplink.

Lab Purpose

The basic GLBP lab covered earlier in this series demonstrated load balancing across two forwarders without addressing how much traffic each one actually receives. GLBP weighting allows this split to be proportional to each router's real health and capacity rather than assumed equal, and tracking automates adjusting that weight as conditions change.

Lab Topology

R1 ---- Gi0/1 ---- Switch1 (client-facing)
R1 ---- Gi0/2, Gi0/3 ---- two WAN uplinks

R2 ---- Gi0/1 ---- Switch1 (client-facing)
R2 ---- Gi0/2 ---- one WAN uplink

Virtual IP: 192.168.180.1/24
R1: 192.168.180.2, R2: 192.168.180.3

Task 1: Configure Basic GLBP

Configure GLBP as covered in the earlier lab, with both routers as active forwarders.

Task 2: Configure Interface Tracking for Each Uplink

Configure GLBP weighting on R1 to decrement when either of its two uplinks fails, and on R2 to decrement when its single uplink fails.

Task 3: Verify Initial Weighting Reflects Full Health

Confirm both routers report their full configured weight while all uplinks are healthy.

Task 4: Simulate One of R1's Two Uplinks Failing

Shut down one of R1's two uplink interfaces and observe the resulting weight change.

Task 5: Verify the Load-Balancing Ratio Shifts

Confirm R1 now forwards a smaller proportion of client traffic relative to R2, reflecting its reduced uplink capacity.

Solution and Verification

R1(config)# interface gigabitethernet0/1
R1(config-if)# glbp 1 ip 192.168.180.1
R1(config-if)# glbp 1 weighting 200 lower 100 upper 200

-- Starting weight of 200 (full health, both
-- uplinks); if weight drops to 100 or below,
-- this router stops actively forwarding
-- until it rises back to 200

R1(config-if)# glbp 1 weighting track 1 decrement 50
R1(config-if)# glbp 1 weighting track 2 decrement 50

R1(config)# track 1 interface gigabitethernet0/2 line-protocol
R1(config)# track 2 interface gigabitethernet0/3 line-protocol

R2(config)# interface gigabitethernet0/1
R2(config-if)# glbp 1 ip 192.168.180.1
R2(config-if)# glbp 1 weighting 100 lower 50 upper 100
R2(config-if)# glbp 1 weighting track 3 decrement 100

R2(config)# track 3 interface gigabitethernet0/2 line-protocol

R1# show glbp gigabitethernet0/1 1 | include Weighting

Track object 1 state Up decrement 50
Track object 2 state Up decrement 50
Weighting 200, low 100, high 200 (configured)

R2# show glbp gigabitethernet0/1 1 | include Weighting

Track object 3 state Up decrement 100
Weighting 100, low 50, high 100 (configured)
-- Both routers at full configured weight,
-- since all tracked uplinks are currently up

R1(config)# interface gigabitethernet0/2
R1(config-if)# shutdown

R1# show glbp gigabitethernet0/1 1 | include Weighting

Track object 1 state Down decrement 50
Track object 2 state Up decrement 50
Weighting 150, low 100, high 200 (configured)
-- R1's weight dropped from 200 to 150 --
-- still above its "low" threshold of 100,
-- so R1 remains an active forwarder, but
-- with reduced relative weight

R1# show glbp gigabitethernet0/1 1 | begin Forwarder

Forwarder  State    MAC address       Weight
1          Active   0007.b400.0101    150
2          Listen   0007.b400.0102    -

R2# show glbp gigabitethernet0/1 1 | begin Forwarder

Forwarder  State    MAC address       Weight
1          Listen   0007.b400.0101    -
2          Active   0007.b400.0102    100
-- R1 now forwards proportionally less
-- traffic (weight 150) relative to R2
-- (weight 100 but originally the two were
-- 200 vs 100, a 2:1 ratio -- now 150 vs 100,
-- a shift narrowing that gap since R1's
-- health has genuinely declined)

Key Takeaway

GLBP weighting extends the basic load-balancing behavior covered in an earlier lab by making the AVG's decisions about how many clients to assign each forwarder proportional to real-time health rather than a fixed assumption — combined with interface tracking, this allows the load-balancing ratio to automatically favor whichever router currently has the better actual uplink capacity, without requiring any manual reconfiguration when conditions change.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه