CCNP 642-811 BCMSN Exam Certification Guide - Cisco press

338 Chapter 14: Router Redundancy and Load Balancing

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 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 720 with Cisco IOS Software Release 12.2(14)SX.

To provide a virtual router, multiple switches (routers) are assigned to a common GLBP group. Rather than 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 have 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 upon 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.

Router Redundancy in Multilayer Switching 339

As with HSRP, another router cannot take over an active role until the current active router fails. GLBP does allow a router to preempt and become the AVG if it has a higher priority than the current AVG. Use the following command to enable preempting and to set a time delay before preempting begins:

Switch(config-if)# glbp group preempt [delay minimum seconds]

Active Virtual Forwarder

GLBP uses 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 must first define an interface as a tracked object with the following global configuration command:

Switch(config)# track object-number interface type mod/num {line-protocol | 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 preempt another when it has a higher weight value.

Router Redundancy in Multilayer Switching 341

Figure 14-3 Multilayer Switches in a GLBP Group

In this figure, round robin load balancing is being used. Each of the client PCs look 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.

342 Chapter 14: Router Redundancy and Load Balancing

Redundancy is also inherent in the GLBP group—Catalyst A 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 14-4 shows how these redundancy features react when the current active AVG fails. Catalyst A, prior to its failure, was the AVG because of its higher GLBP priority. After it failed, Catalyst B became the AVG, answering ARP requests with the appropriate virtual MAC address for gateway 192.168.1.1. Catalyst A had also been acting as an AVF, participating in the gateway load balancing. Catalyst B also picks up this responsibility, using its virtual MAC address 0000.0000.0002 as well as the one Catalyst A had been using, 000.0000.0001. Therefore, any hosts that know the gateway by any of its virtual MAC addresses can still reach a live gateway or AVF.

Figure 14-4 How GLBP Reacts to a Component Failure

344 Chapter 14: Router Redundancy and Load Balancing

SLB controls how traffic is load balanced across the set of real servers. Load balancing can be configured as one of the following methods:

■Weighted round-robin—Each real server is assigned a weight that gives it the capability to handle connections, relative to the other servers. For a weight n, a server is assigned n new connections before SLB moves on to the next server.

■Weighted least connections—SLB assigns new connections to the real server with the least number of active connections. Each real server is assigned a weight m, where its capacity for active connections is m divided by the sum of all server weights. SLB assigns new connections to the real server with the number of active connections farthest below its capacity. New connections are rate-limited, allowing the number of connections to increase gradually to keep the server from becoming overloaded.

You can also assign connections so that they are “sticky”—the same client is connected to the last real server that it used.

By keeping the actual addresses of the real servers hidden from the outside world, an extra layer of security is possible. Also, because each virtual server is mapped to mutliple real servers, any of the real servers can be taken down for maintenance at any time.

SLB Configuration

SLB is configured in two basic stages. First, the server farms are defined and populated with real servers. Then, the virtual servers are defined and linked with the appropriate server farms.

TIP SLB is a versatile and robust feature. As a result, many configuration commands can be used. The BCMSN course presents only the basic SLB operation. Therefore, this text covers just the commands needed to define server farms and virtual servers and bring them into service.

If you plan on using SLB in your network, you would be wise to take advantage of the full set of its capabilities. Refer to the Cisco documentation or to the Cisco Press title, Cisco Field Manual: Catalyst Switch Configuration, for more details.

Server Farms

Configure each server farm by following this series of steps:

Step 1 Name the server farm:

Switch(config)# ip slb serverfarm serverfarm-name

The server farm is given a descriptive name, up to 15 characters.

Server Load Balancing (SLB) 345

Step 2 Choose a load-balancing method.

Switch(config-slb-sfarm)# predictor {roundrobin | leastconns}

Either weighted round-robin (the default) or weighted least connections can be used.

Step 3 Identify the real servers in the server farm:

Switch(config-slb-sfarm)# real ip-address

The server’s actual IP address is given.

Step 4 Assign a weight for the relative server capacity:

Switch(config-slb-real)# weight weighting-value

The weighting value (1 to 255, default 8) indicates the server’s capacity to accept new connections, relative to the other real servers in the server farm.

Step 5 Put the real server into service:

Switch(config-slb-real)# inservice

By default, SLB cannot use a real server until it is manually put into service. Later, the real server can be taken out of service for maintenance with the no inservice command. This removes it from use in the SLB server farm until it is returned to service again. (To take a real server out of service, first get into the real server configuration mode by using the commands from Steps 1 and 3.)

Virtual Servers

Configure each virtual server by the following series of steps:

Step 1 Name the virtual server:

Switch(config)# ip slb vserver virtual-server-name

The virtual server is given a descriptive name, up to 15 characters.

Step 2 Assign the virtual server to a server farm:

Switch(config-slb-vserver)# serverfarm serverfarm-name

SLB uses the virtual server as the front end for the server farm named. This server farm must already be configured, populated with one or more real servers.

Step 3 Assign an IP address to the virtual server:

Switch(config-slb-vserver)# virtual ip-address

Step 4 Control access to the virtual server:

Switch(config-slb-vserver)# client ip-address inverse-mask