Gateway Load Balancing Protocol
You should now know how both HSRP and VRRP can effectively provide a redundant gateway (virtual router) address. You can accomplish load balancing by configuring only multiple HSRP/ VRRP groups to have multiple virtual router addresses. More manual configuration is needed so that the client machines are divided among the virtual routers. Each group of clients must point to the appropriate virtual router. This makes load balancing somewhat labor-intensive, having a more or less fixed, or static, behavior.
The Gateway Load Balancing Protocol (GLBP) is a Cisco-proprietary protocol designed to overcome the limitations of existing redundant router protocols. Some of the concepts are the same as with HSRP/VRRP, but the terminology is different and the behavior is much more dynamic and robust.
NOTE GLBP was introduced in Cisco IOS Software Release 12.2(14)S for routers. At press time, GLBP is available only for the Catalyst 6500 Supervisor 2 with IOS Release 12.2(14)SY4 or later, and Supervisor 720 with IOS Release 12.2(17a)SX4 switch platforms.
To provide a virtual router, multiple switches (routers) are assigned to a common GLBP group. Instead of having just one active router performing forwarding for the virtual router address, all routers in the group can participate and offer load balancing by forwarding a portion of the overall traffic.
The advantage is that none of the clients has to be pointed toward a specific gateway address; they can all have the same default gateway set to the virtual router IP address. The load balancing is provided completely through the use of virtual router MAC addresses in ARP replies returned to the clients. As a client sends an ARP request looking for the virtual router address, GLBP sends back an ARP reply with the virtual MAC address of a selected router in the group. The result is that all clients use the same gateway address but have differing MAC addresses for it.
Active Virtual Gateway
The trick behind this load balancing lies in the GLBP group. One router is elected the active virtual gateway (AVG). This router has the highest priority value, or the highest IP address in the group, if there is no highest priority. The AVG answers all ARP requests for the virtual router address. Which MAC address it returns depends on which load-balancing algorithm it is configured to use. In any event, the virtual MAC address supported by one of the routers in the group is returned.
The AVG also assigns the necessary virtual MAC addresses to each of the routers participating in the GLBP group. Up to four virtual MAC addresses can be used in any group. Each of these routers is referred to as an active virtual forwarder (AVF), forwarding traffic received on its virtual MAC
address. Other routers in the group serve as backup or secondary virtual forwarders, in case the AVF fails. The AVG also assigns secondary roles.
Assign the GLBP priority to a router with the following interface configuration command:
Switch(config-if)# glbp group priority level
GLBP group numbers range from 0 to 1023. The router priority can be 1 to 255 (255 is the highest priority), defaulting to 100.
As with HSRP, another router cannot take over an active role until the current active router fails. GLBP does allow a router to pre-empt and become the AVG if it has a higher priority than the current AVG. Use the following command to enable pre-empting and to set a time delay before pre-empting begins:
Switch(config-if)# glbp group preempt [delay minimum seconds] Routers participating in GLBP must monitor each other's presence so that another router can assume the role of a failed router. To do this, the AVG sends periodic hello messages to each of the other GLBP peers. In addition, it expects to receive hello messages from each of them.
Hello messages are sent at hellotime intervals, with a default of 3 seconds. If hellos aren't received from a peer within a holdtime, defaulting to 10 seconds, that peer is presumed to have failed. You can adjust the GLBP timers with the following interface-configuration command:
Switch(config-if)# glbp group timers [msec] hellotime [msec] holdtime
The timer values normally are given in seconds, unless they are preceded by the msec keyword, to indicate milliseconds. The hellotime can range from 1 to 60 seconds or from 50 to 60,000 milliseconds. The holdtime must be greater than the hellotime and can go up to 180 seconds or 180,000 milliseconds. You always should make the holdtime at least three times greater than the hellotime to give some tolerance to missed or delayed hellos from a functional peer.
TIP Although you can use the previous command to configure the GLBP timers on each peer router, it isn't necessary. Instead, just configure the timers on the router you have identified as the AVG. The AVG will advertise the timer values it is using, and every other peer will learn those values if they have not already been explicitly set.
Active Virtual Forwarder
By default, GLBP uses the periodic hello messages to detect AVF failures, too. Each router within a GLBP group must send hellos to every other GLBP peer. Hellos also are expected from every other peer. For example, if hellos from the AVF are not received by the AVG before its holdtime timer expires, the AVG assumes that the current AVF has failed. The AVG then assigns the AVF role to another router.
Naturally, the router that is given the new AVF role might already be an AVF for a different virtual MAC address. Although a router can masquerade as two different virtual MAC addresses to support the two AVF functions, it doesn't make much sense to continue doing that for a long period of time. The AVG maintains two timers that help resolve this condition.
The redirect timer is used to determine when the AVG will stop using the old virtual MAC address in ARP replies. The AVF corresponding to the old address continues to act as a gateway for any clients that try to use it.
When the timeout timer expires, the old MAC address and the virtual forwarder using it are flushed from all the GLBP peers. The AVG assumes that the previously failed AVF will not return to service, so the resources assigned to it must be reclaimed. At this point, clients still using the old MAC address in their ARP caches must refresh the entry to obtain the new virtual MAC address.
The redirect timer defaults to 600 seconds (10 minutes) and can range from 0 to 3,600 seconds (1 hour). The timeout timer defaults to 14,400 seconds (4 hours) and can range from 700 to 64,800 seconds (18 hours). You can adjust these timers with the following interface-configuration command:
Switch(config-if)# glbp group timers redirect redirect timeout
GLBP also can use a weighting function to determine which router becomes the AVF for a virtual MAC address in a group. Each router begins with a maximum weight value (1 to 254). As specific interfaces go down, the weight is decreased by a configured amount. GLBP uses thresholds to determine when a router can and cannot be the AVF. If the weight falls below the lower threshold, the router must give up its AVF role. When the weight rises above the upper threshold, the router can resume its AVF role.
By default, a router receives a maximum weight of 100. If you want to make a dynamic weighting adjustment, GLBP must know which interfaces to track and how to adjust the weight. You first must define an interface as a tracked object with the following global configuration command:
Switch(config)# track object-number interface type mod/num {line-protocol I ip routing} The object-number is an arbitrary index (1 to 500) that is used for weight adjustment. The condition that triggers an adjustment can be line-protocol (the interface line protocol is up) or ip routing (IP routing is enabled, the interface has an IP address, and the interface is up).
Next, you must define the weighting thresholds for the interface with the following interface configuration command:
Switch(config-if)# glbp group weighting maximum [lower lower] [upper upper]
The maximum weight can range from 1 to 254 (default 100). The upper (default maximum) and lower (default 1) thresholds define when the router can and cannot be the AVF, respectively.
Finally, you must configure GLBP to know which objects to track so that the weighting can be adjusted with the following interface configuration command:
Switch(config-if)# glbp group weighting track object-number [decrement value]
When the tracked object fails, the weighting is decremented by value (1 to 254, default 10).
Likewise, a router that might serve as an AVF cannot pre-empt another when it has a higher weight value.
GLBP Load Balancing
The AVG establishes load balancing by handing out virtual router MAC addresses to clients in a deterministic fashion. Naturally, the AVG first must inform the AVFs in the group of the virtual MAC address that each should use. Up to four virtual MAC addresses, assigned in sequential order, can be used in a group.
You can use one of the following load-balancing methods in a GLBP group:
■ Round robin—Each new ARP request for the virtual router address receives the next available virtual MAC address in reply. Traffic load is distributed evenly across all routers participating as AVFs in the group, assuming that each of the clients sends and receives the same amount of traffic. This is the default method used by GLBP.
■ Weighted—The GLBP group interface's weighting value determines the proportion of traffic that should be sent to that AVF. A higher weighting results in more frequent ARP replies containing the virtual MAC address of that router. If interface tracking is not configured, the maximum weighting value configured is used to set the relative proportions among AVFs.
■ Host-dependent—Each client that generates an ARP request for the virtual router address always receives the same virtual MAC address in reply. This method is used if the clients have a need for a consistent gateway MAC address. (Otherwise, a client could receive replies with different MAC addresses for the router over time, depending on the load-balancing method in use.)
On the AVG router (or its successors), use the following interface configuration command to define the method:
Switch(config-if)# glbp group load-balancing [round-robin I weighted I host-dependent]
Enabling GLBP
To enable GLBP, you must assign a virtual IP address to the group by using the following interface configuration command:
Switch(config-if)# glbp group ip [ip-address [secondary]]
If the ip-address is not given in the command, it is learned from another router in the group. However, if this router is to be the AVG, you must explicitly configure the IP address; otherwise, no other router knows what the value should be.
Figure 13-3 shows a typical network in which three multilayer switches are participating in a common GLBP group. CatalystA is elected the AVG, so it coordinates the entire GLBP process. The AVG answers all ARP requests for the virtual router 192.168.1.1. It has identified itself, CatalystB, and CatalystC as AVFs for the group.
Figure 13-3 Multilayer Switches in a GLBP Group
AVG Standby AVG
AVF vMAC 0000.0000.0001 AVF vMAC 0000.0000.0002 AVF vMAC 0000.0000.0003
VLAN 50 VLAN 50 VLAN 50
192.168.1.10 192.168.1.11 192.168.1.12
0000.aaaa.aaaa 0000.bbbb.bbbb 0000.cccc.cccc
VLAN 50 VLAN 50 VLAN 50
192.168.1.10 192.168.1.11 192.168.1.12
0000.aaaa.aaaa 0000.bbbb.bbbb 0000.cccc.cccc
- VLAN 50
In this figure, round-robin load balancing is being used. Each of the client PCs looks for the virtual router address in turn, from left to right. Each time the AVG replies, the next sequential virtual MAC address is sent back to a client. After the fourth PC sends a request, all three virtual MAC
addresses (and AVF routers) have been used, so the AVG cycles back to the first virtual MAC address.
Notice that only one GLBP group has been configured, and all clients know of only one gateway IP address: 192.168.1.1. However, all uplinks are being utilized, and all routers are proportionately forwarding traffic.
Redundancy is also inherent in the GLBP group: CatalystA is the AVG, but the next-highest priority router can take over if the AVG fails. All routers have been given an AVF role for a unique virtual MAC address in the group. If one AVF fails, some clients remember the last-known virtual MAC address that was handed out. Therefore, another of the routers also takes over the AVF role for the failed router, causing the virtual MAC address to remain alive at all times.
Figure 13-4 shows how these redundancy features react when the current active AVG fails. Before its failure, CatalystA was the AVG because of its higher GLBP priority. After it failed, CatalystB became the AVG, answering ARP requests with the appropriate virtual MAC address for gateway 192.168.1.1. CatalystA also had been acting as an AVF, participating in the gateway load balancing. CatalystB also picks up this responsibility, using its virtual MAC address 0000.0000.0002 along with the one CatalystA had been using, 000.0000.0001. Therefore, any hosts that know the gateway by any of its virtual MAC addresses still can reach a live gateway or AVF.
You can implement the scenario shown in Figures 13-3 and 13-4 with the configuration commands in Example 13-7 for CatalystA, CatalystB, and CatalystC, respectively.
Example 13-7 Configuring GLBP Load Balancing
|
CatalystA(config)# interface vlan 50 |
|||||
|
CatalystA(config-if)# ip address 192.168.1 |
.10 |
255 |
255 |
255 |
0 |
|
CatalystA(config-if)# glbp 1 priority 200 |
|||||
|
CatalystA(config-if)# glbp 1 preempt |
|||||
|
CatalystA(config-if)# glbp 1 ip 192.168.1. |
1 |
||||
|
CatalystB(config)# interface vlan 50 |
|||||
|
CatalystB(config-if)# ip address 192.168.1 |
.11 |
255 |
255 |
255 |
0 |
|
CatalystB(config-if)# glbp 1 priority 150 |
|||||
|
CatalystB(config-if)# glbp 1 preempt |
|||||
|
CatalystB(config-if)# glbp 1 ip 192.168.1. |
1 |
||||
|
CatalystC(config)# interface vlan 50 |
|||||
|
CatalystC(config-if)# ip address 192.168.1 |
.12 |
255 |
255 |
255 |
0 |
|
CatalystC(config-if)# glbp 1 priority 100 |
|||||
|
CatalystC(config-if)# glbp 1 ip 192.168.1. |
1 |
Figure 13-4 How GLBP Reacts to a Component Failure
AVF vMAC 0000.0000.0001
GLBP Group 1 Priority 200 VLAN 50 192.168.1.10 0000.aaaa.aaaa
Catalyst A
'Active AVG "AVF vMAC 0000.0000.0002 AVF vMAC 0000.0000.0001
GLBP Group 1 Priority 150 VLAN 50 192.168.1.11 0000.bbbb.bbbb
Gateway: 192.168.1.1 Gateway ARP: 0000.0000.0001
Catalyst A
Gateway: 192.168.1.1 Gateway ARP: 0000.0000.0001
Catalyst C
Gateway: 192.168.1.1 Gateway ARP: 0000.0000.0001
AVF vMAC 0000.0000.0003
GLBP Group 1 Priority 100 VLAN 50 192.168.1.12 0000.cccc.cccc
Catalyst C
Gateway: 192.168.1.1 Gateway ARP: 0000.0000.0001
Gateway: 192.168.1.1 Gateway ARP: 0000.0000.0002
Gateway: 192.168.1.1 Gateway ARP: 0000.0000.0003
You can verify GLBP operation with the show glbp [brief] command, as demonstrated in Example 13-8. With the brief keyword, the GLBP roles are summarized showing the interface, GLBP group number (Grp), virtual forwarder number (Fwd), GLBP priority (Pri), state, and addresses.
Example 13-8 Verifying GLBP Operation
|
CatalystA# |
show glbp brief |
|||||||
|
Interface |
Grp |
Fwd |
Pri State |
Address |
Active router |
Standby |
router |
|
|
Vl50 |
1 |
200 Active |
192.168.1 |
1 |
local |
192.168 |
1.11 |
|
|
Vl50 |
1 |
1 |
7 Active |
0007.b400 |
0101 |
local |
||
|
Vl50 |
1 |
2 |
7 Listen |
0007.b400 |
0102 |
192.168.1.11 |
||
|
Vl50 |
1 |
3 |
7 Listen |
0007.b400 |
0103 |
|||
|
CatalystA# |
||||||||
|
CatalystB# |
show glbp |
brief |
||||||
|
Interface |
Grp |
Fwd |
Pri State |
Address |
Active router |
Standby |
router |
|
Example 13-8 Verifying GLBP Operation (Continued)
|
V150 |
1 |
150 |
Standby |
192.168.1 |
1 |
192.168 |
1 |
10 |
local |
||
|
V150 |
1 |
1 |
7 |
Listen |
0007.b400 |
0101 |
192.168 |
1 |
10 |
||
|
V150 |
1 |
2 |
7 |
Active |
0007.b400 |
0102 |
1oca1 |
||||
|
V150 |
1 |
3 |
7 |
Listen |
0007.b400 |
0103 |
192.168 |
1 |
13 |
||
|
Cata1ystB# |
|||||||||||
|
Cata1ystC# |
show glbp brief |
||||||||||
|
Interface |
Grp |
Fwd |
Pri |
State |
Address |
Active |
router |
Standby |
router |
||
|
V150 |
1 |
100 |
Listen |
192.168.1 |
1 |
192.168 |
1 |
10 |
192.168 |
1.11 |
|
|
V150 |
1 |
1 |
7 |
Listen |
0007.b400 |
0101 |
192.168 |
1 |
10 |
||
|
V150 |
1 |
2 |
7 |
Listen |
0007.b400 |
0102 |
192.168 |
1 |
11 |
||
|
V150 |
1 |
3 |
7 |
Active |
0007.b400 |
0103 |
1oca1 |
||||
|
Cata1ystC# |
|||||||||||
Notice that CatalystA is shown to be the AVG because it has a dash in the Fwd column and is in the Active state. It also is acting as AVF for virtual forwarder number 1. Because the GLBP group has three routers, there are three virtual forwarders and virtual MAC addresses. CatalystA is in the Listen state for forwarders number 2 and 3, waiting to be given an active role in case one of those AVFs fails.
CatalystB is shown to have the Standby role, waiting to take over in case the AVG fails. It is the AVF for virtual forwarder number 2.
Finally, CatalystC has the lowest GLBP priority, so it stays in the Listen state, waiting for the active or standby AVG to fail. It is also the AVF for virtual forwarder number 3.
You also can display more detailed information about the GLBP configuration and status by omitting the brief keyword. Example 13-9 shows this output on the AVG router. Because this is the AVG, the virtual forwarder roles it has assigned to each of the routers in the GLBP group also are shown.
Example 13-9 Displaying Detailed GLBP Configuration and Status Information
CatalystA# show glbp Vlan50 - Group 1 State is Active
7 state changes, last state change 03:28:05 Virtual IP address is 192.168.1.1 Hello time 3 sec, hold time 10 sec
Next hello sent in 1.672 secs Redirect time 600 sec, forwarder time-out 14400 sec Preemption enabled, min delay 0 sec Active is local
Standby is 192.168.1.11, priority 150 (expires in 9.632 sec) Priority 200 (configured)
Weighting 100 (default 100), thresholds: lower 1, upper 100
continues
Example 13-9 Displaying Detailed GLBP Configuration and Status Information (Continued)
|
Load balancing: round-robin |
|
|
There are 3 forwarders (1 active) |
|
|
Forwarder 1 |
|
|
State is Active |
|
|
3 state changes, last state change 03:27: |
37 |
|
MAC address is 0007.b400.0101 (default) |
|
|
Owner ID is 00d0.0229.b80a |
|
|
Redirection enabled |
|
|
Preemption enabled, min delay 30 sec |
|
|
Active is local, weighting 100 |
|
|
Forwarder 2 |
|
|
State is Listen |
|
|
MAC address is 0007.b400.0102 (learnt) |
|
|
Owner ID is 0007.b372.dc4a |
|
|
Redirection enabled, 598.308 sec remaining |
(maximum 600 sec) |
|
Time to live: 14398.308 sec (maximum 14400 |
sec) |
|
Preemption enabled, min delay 30 sec |
|
|
Active is 192.168.1.11 (primary), weighting |
100 (expires in 8.308 sec) |
|
Forwarder 3 |
|
|
State is Listen |
|
|
MAC address is 0007.b400.0103 (learnt) |
|
|
Owner ID is 00d0.ff8a.2c0a |
|
|
Redirection enabled, 599.892 sec remaining |
(maximum 600 sec) |
|
Time to live: 14399.892 sec (maximum 14400 |
sec) |
|
Preemption enabled, min delay 30 sec |
|
|
Active is 192.168.1.13 (primary), weighting |
100 (expires in 9.892 sec) |
|
CatalystA# |
|
Continue reading here: Redundant Switch Supervisors
Was this article helpful?