Virtual Router Redundancy Protocol (VRRP)

November 4, 2016 by Neel Rao

Filed under Network

Last modified November 5, 2016

Virtual Router Redundancy Protocol (VRRP)

 

The Virtual Router Redudnancy Protocol (VRRP) is a standards-based alternative to HSRP, defined in IETF standard RFC 2338. VRRP is so similar to HSRP, you only need to learn slightly different terminology and a couple of slight functional differences. After you understand HSRP operation and configuration, you will also understand VRRP. This section is kept brief, highlighting only the differences in the two protocols.

  • VRRP provides one redundant gateway address from a group of routers. The active router is called the aster router, while all others are in the backup state. The master router is the one with the highest router priority in the VRRP group.VRRP group numbers range from 0 to 255; router priorities range from 1 to 254 (254 is the highest; 100 is the default). The virtual router MAC address is of the form 0000.5e00.01xx, where xx is a two-digit hex VRRP group number.
  • VRRP advertisements are sent at 1-second intervals. Backup routers can optionally learn the advertisement Interval from the master router.
  • By default, all VRRP routers are configured to preempt the current master router, if their priorities are greater.
  • VRRP has no mechanism for tracking interfaces to allow more capable routers to take over the master role.

NOTE VRRP sends its advertisements to the multicast destination address 224.0.0.18 (VRRP), using IP protocol 112. VRRP was introduced in Cisco IOS Software Release 12.0(18)ST for routers. At press time, VRRP is available only for the Catalyst 6500 Supervisor 720 with Cisco IOS Software Release 12.2(14)SX.

Table 14-2 VRRP Configuration Commands

Task                                                                                                           Command Syntax

Assign a VRRP router priority (default 100).                                        vrrp group priority level

Alter the advertisement timer (default 1 second).                                vrrp group timers advertise [msec] interval

Learn the advertisement interval from the master router.                  vrrp group timers learn

Disable preempting (default is to preempt).                                             no vrrp group preempt

Change the preempt delay (default 0 seconds).                                       vrrp group preempt [delay seconds]

Use authentication for advertisements.                                                     vrrp group authentication string

Assign a virtual IP address.                                                                         vrrp group ip ip-address [secondary]

 

Gateway Load Balancing Protocol (GLBP)

 

You should now know how both HSRP and VRRP can be effective at providing 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 HSRP/VRRP, but the terminology is different, and the behavior is much more dynamic and robust.

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.

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.

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 preemptingbegins:

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.

GLBP Load Balancing

The AVG establishes load balancing by handing out virtual router MAC addresses to clients in a deterministic fashion. Naturally, the AVG must first 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 availablevirtual MAC address in reply. Traffic load is distributed evenly across all routers participatingas AVFs in the group, assuming each of the clients sends and receives the same amount oftraffic. This is the default method used by GLBP.
  • Weighted—The GLBP group interface’s weighting value determines the proportion of trafficthat 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 | weighted | 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 14-3 shows a typical network where three multiayer switches are participating in a common

GLBP group. Catalyst A 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, Catalyst B, and Catalyst C as AVFs for the group.

glbp

glbp

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.

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.

 

glbp2

glbp2

Server Load Balancing (SLB)

Each of the router redundancy protocols allows a router to mimic the identity of one or more others. This can also be handy to intelligently and transparently forward traffic to multiple destinations. In other words, one or more physical destinations can “hide” behind a single virtual IP address. You can configure the multilayer switch or router to decide which of the actual destinations services a request sent to the virtual address.

Server Load Balancing (SLB) is designed to provide a virtual server IP address to which clients can connect. The virtual server is, in fact, a group of real physical servers organized as a server farm.

The client never knows exactly which real server it is connecting with—only the multilayer switch running SLB knows that for sure.

Figure 14-5 shows an example of SLB in a switched network. Two server farms, FARM1 and FARM2, are made up of logical groupings of real physical servers. Each real server has a unique IP address. SLB causes each server farm to appear as a single virtual server, VSERVER1 and VSERVER2, respectively. Client machines make connections to the virtual server addresses, 10.1.250.1 and 10.1.250.2, while SLB completes the connection to one of the real servers.

glbp3

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 tohandle 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 multiple 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.

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

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

By default, any client from any IP address can make connections to the virtual server. To limit the access,

define only the IP subnet or address range (with subnet mask) that is allowed access. The inverse-mask here  resembles that of an access list, where a 1-bit ignores and a 0-bit matches.

Step 5 Put the virtual server into service:

Switch(config-slb-vserver)# inservice

By default, SLB does not allow connections to be made to a virtual server until it is put into service. If a

virtual server needs to be temporarily disabled for some reason, use the no inservice command.

Verifying Redundancy and Load Balancing

 To verify the operation of the features discussed in this chapter, you can use the commands listed in Table 14-3. In particular, look for the active router, standby or backup routers, and load-balancing methods in use.

Table 14-3 Redundancy and Load Balancing Verification Commands

Task                                                                       Command Syntax

 HSRP and VRRP

 Show HSRP status.                                                show standby brief

Show HSRP on an interface.                                  show standby type mod/num

Show VRRP status.                                                                show vrrp brief all

Show VRRP on an interface.                                  show vrrp interface type mod/num

 GLBP

Show status of a GLBP group.                               show glbp group

 SLB

Show server farms.                                                 show ip slb serverfarms

Show real servers.                                                   show ip slb reals

Show virtual servers.                                              show ip slb vserver

Show current SLB connections.                              show ip slb cons

 

 

 

Leave a Comment