Hands-On Lab: Configure GLBP Redundancy

This hands-on lab configures GLBP between two routers to achieve load balancing across both routers simultaneously, verifying that different hosts receive different virtual MAC addresses and therefore route through different physical gateways.

GLBP ConfigurationActive Virtual GatewayGLBP Load Balancing

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

Lab Objective

Configure GLBP on two routers sharing a virtual IP address, verify one becomes the Active Virtual Gateway while both actively forward traffic, and confirm different client hosts are assigned different virtual MAC addresses pointing to different physical routers.

Lab Purpose

Unlike HSRP, covered in the previous lab, where only the active router ever forwards traffic while the standby sits idle, GLBP allows both routers to simultaneously forward traffic by handing out different virtual MAC addresses to different hosts, making full use of both routers' bandwidth capacity.

Lab Topology

R1 ---- Gi0/1 ---- Switch1
R2 ---- Gi0/1 ---- Switch1

R1: 192.168.16.2/24
R2: 192.168.16.3/24
Virtual IP: 192.168.16.1/24

PC-A: 192.168.16.10/24, gateway 192.168.16.1
PC-B: 192.168.16.11/24, gateway 192.168.16.1

Task 1: Configure Basic Addressing

Configure both routers' interfaces on the shared segment.

Task 2: Configure GLBP on Both Routers

Configure the virtual IP address on both routers using GLBP group 1.

Task 3: Set Priority to Establish the AVG

Set R1's GLBP priority higher than R2's so R1 becomes the Active Virtual Gateway.

Task 4: Verify the AVG and Active Virtual Forwarders

Confirm R1 is the AVG and both routers appear as active forwarders.

Task 5: Verify Load Balancing Across Clients

Confirm PC-A and PC-B receive different virtual MAC addresses when they ARP for the gateway.

Solution and Verification

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 192.168.16.2 255.255.255.0
R1(config-if)# no shutdown

R2(config)# interface gigabitethernet0/1
R2(config-if)# ip address 192.168.16.3 255.255.255.0
R2(config-if)# no shutdown

R1(config)# interface gigabitethernet0/1
R1(config-if)# glbp 1 ip 192.168.16.1
R1(config-if)# glbp 1 priority 150

R2(config)# interface gigabitethernet0/1
R2(config-if)# glbp 1 ip 192.168.16.1

R1# show glbp brief

Interface   Grp  Fwd Pri  State   Address         Active router
Gi0/1       1    -   150  Active  192.168.16.1    local
Gi0/1       1    1   -    Active  0007.b400.0101  local
Gi0/1       1    2   -    Active  0007.b400.0102  192.168.16.3
-- R1 is the AVG (150 priority), and BOTH
-- forwarders (1 and 2) are Active -- this
-- confirms both R1 and R2 are actively
-- forwarding, unlike HSRP's single active
-- forwarder model

PC-A> arp -a 192.168.16.1

192.168.16.1    0007.b400.0101
-- PC-A received virtual MAC for forwarder 1
-- (pointing to R1)

PC-B> arp -a 192.168.16.1

192.168.16.1    0007.b400.0102
-- PC-B received a DIFFERENT virtual MAC, for
-- forwarder 2 (pointing to R2) -- both PCs
-- believe they are using the exact same
-- gateway IP, yet their traffic actually
-- flows through different physical routers

Key Takeaway

GLBP's load balancing happens entirely at the ARP response level, discussed earlier in this series regarding address resolution: the AVG (R1) responds to different hosts' ARP requests for the virtual IP with different virtual MAC addresses, transparently spreading forwarding load across both routers while every host still believes it shares one single gateway.

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

مقالات مرتبط

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.

ادامه