Layer 3 Redundancy

The remainder of this chapter focuses on Layer 3 redundancy issues. When you think of Layer 3 redundancy, you're normally dealing with having multiple paths to a destination. This section, however, deals with another type of Layer 3 redundancy: default gateways and server load balancing. I'll begin by talking about some of the issues of default gateway redundancy and some of the solutions that are available, but don't work very well. The main part of this section deals with Cisco's Hot Standby Routing Protocol (HSRP), as well as other solutions that are better at dealing with default gateway redundancy, such as the Single Router Mode (SRM) redundancy and Gateway Load Balancing Protocol (GLBP) solutions.

Problems of Traditional RP Redundancy

You can easily place two RPs at the distribution layer of each switch block to provide redundancy for end stations to leave their VLAN. However, this might not provide a true fault-tolerant solution. This is especially true for situations in which end stations do not support a router discovery protocol to learn which routers they can use or they can't be configured to use more than one default gateway address.

Proxy ARP Issues

Some end stations can use Proxy ARP to discover the IP address of the default gateway. In this situation, the end station dynamically acquires the IP address and MAC address of the default gateway and sends all its inter-VLAN traffic to this RP. To begin, the end station doesn't know how to reach the destination, and generates an ARP request for the destination. Obviously, if the destination is not in the same VLAN, no one responds and the end station assumes that the destination is not reachable. However, a Cisco router can proxy this ARP by sending back its own MAC address to the end station, and the end station can then use the router to send traffic out of the subnet. From the end station's perspective, it thinks it's sending traffic directly to the destination, but it's actually being relayed by the router. On Cisco RPs, Proxy ARP is enabled by default.

However, a problem arises when the default gateway fails. In this situation, the end station still sends its information to the failed default gateway, where the traffic is dropped. Sometimes a client re-performs the ARP after a lengthy period of time to verify the destination's (default gateway's) existence. (At this point, it will have discovered that the default gateway has failed and then another RP can perform the proxy.) However, in most implementations of ARP, the end station continues to use the same failed default gateway MAC address unless it is rebooted.

Proxy ARP is used when an end station ARPs for a destination device's MAC address that is on a different subnet. A Cisco RP can respond back to the end station with its own MAC address, making it appear that the destination is on the same segment. This behavior is enabled by default on Cisco RPs. The main disadvantage is that if the RP fails, the end station won't discover this unless it reboots or re-ARPs.

ICMP Router Discover Protocol Issues

The ICMP Router Discover Protocol (IRDP) is not a routing protocol like OSPF or RIP, but is an extension to ICMP that allows an end station to automatically discover the default gateways connected to the same VLAN. IRDP is covered in RFC 1256. In this environment, the RPs periodically generate special multicast packets that announce the router's existence to the clients. This time period is usually between 5 and 10 minutes. Learned information usually has a maximum lifetime of 30 minutes on the client if no more IRDP messages are heard from the advertising RP. The multicast packet includes the RP's address and a lifetime value.

With IRDP, end stations can dynamically discover other RPs when their primary default gateway fails. However, this might take up to 30 minutes, based on the lifetime value in the original multicast packet from the RP. And even if you might consider using IRDP with your access layer devices, most end-station IP protocol stacks do not support IRDP.

IRDP extends ICMP by allowing an end station to dynamically learn the default gateways that exist in the VLAN. RPs announce themselves every 5 10 minutes and end stations hold this information for up to 30 minutes. The main problem with IRDP is that if the primary RP fails, it might take up to 30 minutes before using a different RP.

Routing Protocol Issues

To overcome these two previous problems, you might be able to run a routing protocol on the end station, if the client supports this type of function. With IP, the only routing protocol that most end stations might support is RIP. In RIP, the end station could make intelligent decisions about which Layer 3 RP to use to access other subnets. However, the issue with RIP is that its convergence is very slow it could take up to 180 seconds before an alternative RP is chosen when the current primary RP fails. With TCP sessions, this would cause a timeout. Because of this, as well as all the additional overhead that RIP creates, this solution is not very desirable for your end stations and this assumes that your end stations and other network devices support a routing protocol such as RIP.

User Device Issues

In most campus environments, end stations are assigned a single IP address for the default gateway (which is usually done via DHCP). In this environment, if the RP were to fail, the end station would lose its capability to access other networking devices outside of its VLAN. Unfortunately, there is no redundancy in this implementation because an end station can have only one default gateway address configured (whether it is assigned via DHCP or statically configured).

HSRP

HSRP is a Cisco-proprietary protocol that provides a single definition of a default gateway on the end station and Layer 3 redundancy for overcoming the issues of IRDP, Proxy ARP, and end-station routing protocols. Unlike the four previous solutions, HSRP is completely transparent to the end stations you do not have to perform any additional configuration on the end stations themselves. HSRP allows Cisco RPs to monitor each other's status, which provides a very quick failover when a primary default gateway fails. This is done by establishing HSRP groups.

With HSRP, a group of RPs represent a single virtual default gateway. This virtual default gateway has a virtual IP address and a virtual MAC address. If the primary RP fails, another RP in the HSRP group takes over and processes the frames sent by the end stations to the virtual MAC address.

An advantage of HSRP groups is that different subnets (VLANs) can have different default gateways, thus providing load balancing. Also, within each HSRP group, there is a primary default gateway and the capability to use multiple routers to perform a backup function. You can have up to 255 standby groups per RP, providing up to 255 default gateways. RPs can provide backup for multiple primary default gateways. Each standby group keeps track of the primary RP that's currently forwarding traffic sent to the virtual MAC address. Note that only one RP is actually forwarding traffic with HSRP.

Once nice feature of HSRP is that you can customize it based on the size of your network. For instance, if you have a VLAN with 1,000 devices in it, you can set up two HSRP groups: one group for 500 devices and another group for the other 500 devices. You can then assign RPs to each group. For example, if you had only two RPs, you could have RP1 be the active RP for group 1, but the standby for group 2 and vice versa for RP2. Through this process, you can have both of your RPs forwarding traffic while still providing redundancy if the active RP in either group fails, the other RP promotes itself to an active state.

HSRP is a Cisco-proprietary protocol that provides default gateway redundancy. You can create a total of 255 groups, allowing for load balancing between RPs. A router can belong to several groups.

HSRP Operation

As mentioned in the previous section, only one RP actually forwards traffic for an HSRP group. Using a priority scheme, one RP is elected as the forwarding router and the others perform as backups for a group. Each RP has a default priority of 100, which you can manipulate. The RP with the highest priority in the group is elected as the active router, and the other RPs are placed in standby mode. The active RP responds to any ARP packets from end stations and replies with the virtual MAC address of the group.

Each HSRP group must have a unique virtual IP address and a virtual MAC address, which means these numbers must be unique across different groups. This MAC address is 0000.0c07.acXX. The 0000.0c is Cisco's vendor code. The 07-ac is HSRP's well-known address. The XX is the group number (in hexadecimal) for the HSRP group. Therefore, each HSRP group must have a unique number to ensure that the MAC address is unique in a VLAN.

With HSRP, the end stations would perform an IP-ARP with the virtual IP address, requesting the virtual MAC address of the default gateway RP. Note that in this setting, the end stations are completely unaware of the actual RPs handling traffic destined for a virtual router. Even when the primary fails and the standby RP starts handling traffic for the broadcast domain, the end stations still think they're talking to the same RP.

Types of RPs

Every HSRP group contains RPs that perform certain roles. Each HSRP group of RPs contains the following types of RPs:

• Virtual RP

• Active RP

• Standby RP

• Other HSRP RPs

The role of the virtual RP is to provide a single RP that's always available to the end stations. It is not a real RP because the IP and MAC addresses of the virtual RP are not physically assigned to any one interface on any of the RPs in the broadcast domain.

The role of the active and standby RPs is based on the priority of the RPs in the HSRP group. The RP with the highest priority is elected as the active RP, and the one with the second highest priority is elected as standby RP. If the priorities are the same, the IP address of the RP is used as a tiebreaker. In this situation, the RP with the higher IP address is elected for the role.

The active RP is responsible for forwarding all traffic destined to the virtual RP's MAC address. A second RP is elected as a standby RP. The standby RP keeps tabs on the active RP by looking for HSRP multicast messages, called HSRP hellos. The active RP generates a hello every 3 seconds. If the standby RP does not see any hellos for 10 seconds from the active RP, the standby RP promotes itself and begins performing the functions of the active RP. Like the active RP, the standby RP also announces itself every 3 seconds so that if it fails, one of the other HSRP routers in the standby group can assume the standby RP role.

The other RPs in the HSRP group, if any exist, listen for the hello multicasts from the standby and active RPs to ensure that they are performing their respective roles. When the active RP fails, the view from the end stations' perspective is the same they're still forwarding their frames to the virtual MAC address. When this happens, the standby RP starts processing the frames sent to the virtual MAC address and one of the other HSRP routers in the group is elected to the standby role.

Each group has a virtual IP and MAC address associated with it, which end stations use to send traffic. The MAC address is 0000.0c07.acXX, where XX represents the HSRP group number in hex. The active RP forwards traffic to and from the VLAN. The standby RP watches to make sure that the active RP sends out its hellos if it doesn't, the standby RP promotes itself to an active state.

If any end station uses a real MAC address of one of the RPs in the broadcast domain, that specific RP whether it is active, standby, or another RP processes and forwards the frame.

HSRP Multicast Messages

To determine which RPs will become the active and standby RPs, all the RPs in the HSRP group initially send out HSRP multicast messages. These UDP messages, using port number 1985, are addressed to the all-router multicast address (224.0.0.1) with a Time-To-Live (TTL) value of 1. A TTL of 1 ensures that any multicast routing protocol that's running will not forward the message to a different subnet. The HSRP message contains the following information:

• HSRP version number

• Op code message type:

  • Hello messages These messages are used by the RPs for the election process as well as by the active and standby RPs when they have been elected.

  • Resign messages These messages are used by an RP when it wants to stop performing the function of the active RP.

  • Coup messages These messages are used by an RP that wants to become the active RP.

• Current HSRP state (see the next section).

• Hello time interval of HSRP messages (defaults to 3 seconds) that is, how often HRSP messages are generated.

• Hold-down time interval (defaults to 10 seconds) the length of time that a hello message is considered valid.

• Priority of the RP used to elect the active and standby RPs.

• Standby group number (0 255).

• Authentication password, if configured.

• Virtual IP address of the HSRP group the default gateway IP address that your end stations should use.

HSRP States

HSRP supports six different states. An RP may go through all these states or only a few of them, depending on whether it becomes an active or standby RP.

• Initial

• Learning

• Listening

• Speaking

• Standby

• Active

When the RPs are enabled, they start in an initial state. Note that they have not begun the HSRP process in an initial state only the RPs themselves and their associated interfaces have been activated. In a learning state, an RP listens for an active RP. The RP initially has no knowledge of any other HSRP routers. In this state, its purpose is to discover the current active and standby RPs and the virtual IP address for the group.

After the RP sees a multicast from the active/standby RP, it learns about the virtual IP address. This is called the listening state. In this state, the RP is neither the active nor standby RP. If there's already a standby and active RP, the listening RP remains in this state and does not proceed to any of the next three states. The exception to this is if you've configured preemption. With preemption, a new RP with a higher priority can usurp an existing active or standby RP.

If the RP enters the speaking state, the RP propagates multicast messages so that it can participate in the election process for the standby or active role. These hellos are sent out periodically so that other RPs in the group know about everyone's existence. Note that for an RP to enter this state, it must have the virtual IP address configured on it.

Based on the RP's priority, it either becomes a standby or active RP. In a standby state, the RP is the next in line to assume the role of the active RP if the active RP fails. In an active state, the RP is responsible for forwarding all traffic sent to the virtual MAC address of the broadcast domain. There can be only one active and one standby RP. Both of these RPs generate periodic hellos to other RPs in the group to guarantee that end stations always have a default gateway that can forward their traffic if either of them fails.

It's important to point out that if you don't configure preemption, the first RP that comes up takes on the active role and the second RP takes on the standby role. Therefore, if you're setting up load balancing between RPs so that certain RPs handle traffic for certain VLANs and other RPs handle traffic for other VLANs, you'll want to use preemption so that whenever a failed RP comes back online, it resumes its former role.

Remember the HSRP states, the order in which they are processed, and what happens in each state.

HSRP Configuration

Only one command is necessary to enable HSRP. To do so, execute the following standby command on the RP's interface. Use a subinterface for a trunk port and a VLAN interface for an internal RP:

 Router(config)# interface type [slot_#/]port_# 

or

 Switch(config)# interface vlan VLAN_# Switch(config-if)# standby [group_#] ip IP_address 

After you execute this command on an active interface, the RP enters the learning state. In this command, group_# is optional. If you omit it, it defaults to 0. Note that group_# is required if you have multiple standby groups. Remember that the IP address you specify in the standby command is not the actual IP address that's on the interface, but rather the virtual IP address. You need to take the virtual IP address and either hard-code it as the default gateway address on end stations or put it in your DHCP server configuration.

To ensure that the end stations do not discover the real MAC address of the RP's LAN interface, enabling HSRP disables ICMP redirects. You'll see the no ip redirects command appear on the RP's interface.

To influence which RPs perform the active and standby roles, you can increase the RPs priorities. To do so, execute the following standby command on the RP's interface:

 Switch(config-if)# standby [group-number] priority new_priority 

Remember that the higher the priority, the more likely it is that the RP will become a standby or active RP. The priority defaults to 100 but can be set from 0 to 255. To configure an RP so that it can preempt the current standby or active RP, use the preempt parameter:

 Switch(config-if)# standby [group-number] preempt [delay delay_value] 

The default delay is 0 seconds, which causes the RP to immediately begin the preemption process. You can delay this by putting in a delay value from 0 to 3,600 seconds (one hour). The one problem with preemption is that it causes a slight disruption in traffic as the currently active RP demotes itself and the new RP promotes itself.

To modify the hello and hold-down times, execute the following standby command:

 Switch(config-if)# standby [group_#] timers hello_time holddown_time 

Here, hello_time defaults to 3 seconds and can range from 0 to 255 seconds. holddown_time defaults to 10 seconds and has the same range of valid values. Note that holddown_time should be at least three times greater than hello_time to ensure proper functioning of HSRP.

It is a common practice to adjust these timers to smaller values to speed up HSRP convergence. However, care must be taken to not set these values too small, which might cause inadvertent switchovers.

If you want to configure authentication, execute the following standby command on the interface:

 Router(config-if)# standby [group-number] authentication password 

The password can be up to eight characters; if omitted, the password defaults to cisco. The password needs to match on all HSRP routers in the same group.

Use the standby ip command to activate HSRP on your RP. Use the standby priority command to change the RP's priority the highest priority becomes the active RP and the second highest priority becomes the standby RP. The default priority is 100. Use the standby preempt command to enable preemption (disabled by default). HSRP routers send out hellos every 3 seconds, with a hold-down period of 10 seconds.

Interface Tracking

In certain cases, it might be necessary for the active RP to step down from its role and let another RP assume the role. Consider the example shown in Figure 7.3. In this example, RP-B is the active RP for VLAN 20. If RP-B fails, RP-A notices this after missing the hello messages from RP-B. RP-A promotes itself and starts forwarding frames that are destined to the virtual MAC address.

Figure 7.3. HSRP example.

Let's assume, however, that RP-B does not fail but instead its interface vlan40 fails (connected to the core), as shown in Figure 7.4. Without HSRP running, RP-B would detect the failure and generate an ICMP redirect message to RP-A. This would allow RP-A to handle the redirected traffic. However, if RP-A and RP-B are participating in an HSRP group, ICMP redirects are disabled. This means that RP-B still functions as the active RP and handles all traffic sent to the virtual MAC address. The problem that this causes is that after the Layer-3 routing protocol has converged, the traffic still reaches its destination. However, to reach the destination, the traffic must pass through both RP-B and RP-A, thus introducing unnecessary latency.

Figure 7.4. HSRP example without interface tracking.

To overcome this problem and still be able to deploy HSRP, you can employ the HSRP interface tracking feature. Interface tracking allows the active RP to lower its priority when one of the interfaces that it's tracking fails. This would allow another RP to assume the active role. In the example shown in Figure 7.4, RP-B, with interface tracking configured, would lower its priority essentially telling the other RPs that it no longer wants to serve as the active RP. When RP-A sees that RP-B is advertising a lower priority than itself, RP-A promotes itself and handles all traffic destined for the virtual MAC address. The advantage of this approach is that the traffic from the user will only traverse one RP: RP-A.

To configure interface tracking, execute the following command on the HSRP group interface:

 Switch(config-if)# standby [group_#] track interface_type interface_#                          [decrement_value] 

The track parameter is used to enter the interface that you want the HSRP RP to track. If this interface fails, for whatever reason, the active RP decrements its HSRP priority by the configured value. Note that decrement_value is optional and, if omitted, defaults to a decrement of 10 for the priority.

Verifying HSRP

To verify the overall operation of HSRP, use the show standby command on the RP:

 Switch# show standby Vlan 1 - Group 1   Local state is Active, priority 110, may preempt   Hellotime 3 holdtime 10   Next hello sent in 0:00:01   Hot standby IP address is 172.16.10.1 configured   Active router is local   Standby router is 172.16.10.2 expires in 0:00:07   Standby virtual mac address is 0000.0c07.ac01 Tracking interface states for 3 interfaces, 3 up:   Up  Vlan1 Priority decrement: 10 

In the preceding output, you can see that the active RP is 172.16.10.1 and the standby RP is 172.16.10.2

For a shorter description, add the brief parameter to the preceding command:

 Router# show standby brief                                Active      Standby Group Interface  Grp Prio P State    addr        addr    addr Vlan1      1   100    Standby  172.17.10.2 local   172.16.10.254 

In this example, this router, for VLAN 1, is in a standby state and the virtual IP address for the standby group is 172.16.10.254.

For additional troubleshooting, you can use the debug standby command from Privilege EXEC mode. This command displays all HSRP messages that have been sent and received by the RP.

Single Router Mode Redundancy

Single Router Mode (SRM) provides an alternative type of redundancy in which dual MSFC cards are installed on dual SEs and both MSFC cards are in the active state and processing traffic. One of the problems of using two active MSFC cards in the same chassis is that you have to configure them separately unless you're using RPR or RPR+. SRM is different from RPR and RPR+. SRM provides Layer 3 redundancy while RPR and RPR+ provide card-level redundancy.

SRM has the following requirements:

• The dual MSFC cards must run the same IOS software and have the same configuration.

• The SEs must be configured for high availability.

SRM Basics

With SRM, one MSFC card is the designated RP and the other is the nondesignated RP. The designated RP is responsible for forwarding all Layer 3 traffic. The nondesignated RP has the same configuration as the designated RP and supports auto-synchronization between the designated and nondesignated RPs. Actually, you can configure only the designated RP. The nondesignated RP is in an operational state, but all of its interfaces are disabled (down and down). The nondesignated card is invisible to other Layer 3 devices in the network; it's basically in a passive state. The nondesignated card keeps tabs on the designated card.

SRM has the following advantages over HSRP:

• Only one set of IP addresses is used, which conserves address space both the designated and nondesignated RPs use the same IP addresses.

• Because only one RP is active at a time, there are fewer routing peers to deal with, which simplifies the Layer 3 topology.

• Configuration is simplified because only the designated RP has to be configured, and its configuration is automatically synchronized with the nondesignated RP.

SRM Operation

If the designated card fails, the nondesignated card enables its interfaces, builds a routing table, and starts forwarding traffic. Here is a detailed list of the steps that occur when the designated RP fails:

1. The nondesignated RP activates its interfaces.

2. The new designated RP begins to build a routing table.

3. The SE maintains the old FIB table for two minutes and uses this information for multilayer switching.

4. After the new designated RP has built a routing table, a new CEF table is built and downloaded from the MSFC to the SE. This is true whether or not the RP has completed Layer 3 convergence.

SRM's advantages include the following: only one set of IP addresses, fewer RP peers, and less configuration. Remember the four steps that SRM goes through when the active MSFC card fails and the redundant card takes over.

SRM Configuration and Verification

Before you enable SRM, Cisco recommends that you save the configuration on both MSFC cards (assuming that there is a preexisting configuration). Do so by using the following command:

 Switch# copy running-config bootflash:no_srm_config 

You can actually use any name you want for the backup file. When this is done, you're ready to enable SRM. The configuration of SRM is very simple:

 Switch(config)# redundancy Switch(config-r)# high-availability Switch(config-r)# single-router-mode 

Notice that you are taken into a Subconfiguration mode where you must enter the high-availability and single-router-mode commands. After this is done, you can use the show redundancy command to verify the configuration of SRM:

 Switch# show redundancy Designated Router: 1   Non-designated Router:2 Redundancy Status: non-designated Config Sync AdminStatus : enabled Config Sync RuntimeStatus: enabled 

Virtual Router Redundancy Protocol

Virtual Router Redundancy Protocol (VRRP) performs a similar function as Cisco's proprietary HSRP. The one major downside to HSRP is that it is a proprietary protocol. VRRP, however, is an open standard and is defined in IETF's RFC 2338. Like HSRP, VRRP has end stations that use a virtual router for a default gateway. VRRP is supported for Ethernet media types as well as in VLANs and MPLS VPNs.

VRRP and HSRP are very similar protocols. One main difference between VRRP and HSRP is that HSRP uses a virtual IP address for the default gateway, whereas VRRP can use either a virtual IP address or the interface address of the master router. If a virtual IP address is used, an election process takes place to choose a master router. The router with the highest priority is chosen as the master. All other routers are backup routers. If a real IP address is used, the router that has that address assigned to its interface must be the master router.

VRRP is an IP protocol and has an IP protocol number of 112. The VRRP master router is responsible for generating VRRP multicast messages. It sends these messages to a multicast address of 224.0.0.18. The master typically generates these messages every second. If the master VRRP router fails, a backup VRRP router seamlessly processes the traffic sent to the master router's IP address. VRRP supports preemption so that a failed master, after it has been repaired, can resume its role as master.

VRRP supports Ethernet, VLANs, and MPLS VPNs. There is a master RP and backup RPs. VRRP can use either a virtual IP address or an address from a router to serve as the default gateway address. If a virtual address is used, the RP with the highest priority is elected as master if a physical IP address is used, the RP with the configured address becomes the master. Hello messages are typically generated as multicasts every second.

Gateway Load Balancing Protocol

The Gateway Load Balancing Protocol (GLBP) is a Cisco-proprietary protocol, like HSRP. One of the limitations of HSRP and VRRP is that only one router in the HSRP group is active and can forward traffic for the group the rest of the routers sit idle. This is not an efficient process where one or more RPs are not processing any traffic, nor are you taking advantage of the bandwidth of the connections that these other RPs are connected to.

Cisco designed GLBP to rectify this issue. GLBP allows the dynamic assignment of a group of virtual addresses to end stations. With GLBP, up to four RPs in the group can participate in the forwarding of traffic. Plus, if a GLBP RP fails, fault detection occurs automatically and another GLBP RP picks up the forwarding of packets for the failed RP.

GLBP Operation

In GLBP, there are two types of routers: Active Virtual Gateway (AVG) and Active Virtual Forwarder (AVF). The AVG is the master gateway device and is responsible for assigning virtual MAC addresses to end stations when the end stations perform an ARP for the GLBP default gateway address. Basically, the AVG is responsible for address management in the GLBP group.

An AVF is an RP that forwards traffic for a GLBP group. The AVG is also an AVF. Basically, up to four RPs configured in the same GLBP group are AVFs.

I'll use Figure 7.5 to give a basic illustration of how GLBP works. In this example, RP-A is the master (AVG). When PC-A sends an ARP request for the default gateway MAC address, the AVG is responsible for responding back with a virtual MAC address to the end station. In this example, it responded back with its own virtual MAC address. PC-B then ARPs for the same gateway address. RP-A responds back with a virtual MAC address. Based on the load-balancing algorithm used by GLBP, RP-A responds back with a different virtual MAC address (RP-B's). Load balancing is discussed in the next section. As you can see from this example, both RP-A and RP-B are forwarding traffic for the same VLAN.

Figure 7.5. GLBP operation.

GLBP also supports interface tracking. With interface tracking, if a tracked interface on an AVF fails, the AVF demotes itself and has another AVF pick up the processing associated with this failed interface. This process is similar to HSRP's interface tracking feature.

GLBP is an enhanced version of HSRP. It enables you to have multiple RPs in the group forwarding traffic. The AVG is responsible for address management in the GLBP group. An AVF is an RP that forwards traffic for a GLBP group. The AVG is also an AVF. Up to four RPs in the same GLBP group are AVFs.

Load Balancing with GLBP

Multiple RPs can be used to forward traffic with GLBP to perform load balancing. GLBP supports three methods of load balancing:

• Round-robin

• Weighted

• Host-dependent

The default method of load balancing is round-robin. With round-robin load balancing, the AVG assigns a different AVF default gateway address to each client. If you have two RPs and six clients, three clients will use the AVG and three will use the AVF.

With weighted load balancing, a weighting factor is used to determine which AVF's address the AVG RP assigns to an end station. This enables you to tune GLBP so that a certain amount of hosts use one RP rather than another if there is a difference in processing power between the RPs.

With host-based load balancing, a host is assigned the same virtual gateway address each time. However, if the RP associated with this address fails, another RP within GLBP can pick up the processing so that redundancy is provided.

Server Load Balancing

Server Load Balancing (SLB) provides a simple form of load balancing for critical services in your network. In SLB, you have two types of servers: virtual and real. The virtual server is the server that end stations send their TCP/IP requests to. The IOS SLB software then redirects this request to a real server in your network. Because most clients use DNS to resolve DNS names to IP addresses, make sure that your DNS server contains the virtual IP address used by SLB.

SLB provides the following advantages:

• It's easy to perform maintenance on a physical server in the server group by removing the redirection entry in the IOS.

• The real addresses are not known to outside devices, thus enhancing your security.

• Because end-station requests are distributed among a group of servers, higher performance can be achieved.

• If you need to move your group of servers or change their IP addresses, end stations don't need to know about these changes because they're made on the IOS device performing SLB.

SLB Operation

SLB operates by having end stations send their traffic to a virtual IP address. SLB has a group of real servers associated with the virtual IP address and redirects the request to one of the internal servers. Two load-balancing algorithms can be used with SLB:

• Directed mode

• Dispatched mode

With directed mode, the IP address chosen for the virtual address is not configured on any of the servers in the SLB group. In this sense, it is similar to the virtual address used by HSRP. In directed mode, SLB performs Network Address Translation (NAT) on the packets to and from the real server.

In dispatched mode, an IP address you choose is known to all the real servers. When in dispatched mode, SLB uses the real MAC address of the server that will have traffic redirected to it. The best way to remember the difference between directed and dispatched mode is that directed mode basically performs at Layer 3 while dispatched mode performs at Layer 2.

SLB has end stations send their traffic to a virtual IP address. SLB has a group of real servers associated with the virtual IP address and redirects the request to one of the real servers. In directed mode, the virtual IP address is unknown to the real servers: SLB performs NAT on the packet. In dispatch mode, the real servers know about the virtual IP address. SLB changes the MAC address to one of the real servers' MACs.

SLB Configuration and Verification

When configuring SLB, you actually perform two sets of configurations: You define the real servers and define the virtual address. The first thing you need to do is to define your server farm, which specifies the IP addresses your real servers are using. Here's the configuration to use:

 Switch(config)# ip slb serverfarm server_farm_name Switch(config-slb-sfarm)# real real_IP_address_of_the_server Switch(config-slb-real)# inservice Switch(config-slb-real)# exit 

The first command, ip slb serverfarm, assigns a name to the group of real servers and takes you into a subconfiguration mode to specify your real server's IP addresses. Use the real command to specify the IP address used on the server's NIC. When you've entered the real command, you're taken into a sub-subconfiguration mode, where you must enable the use of the real server with the inservice command. To add another server, use the exit command to back up one level and use the real command again to enter the next server's IP address.

When you've created your group of servers, you're ready to associate them with a virtual IP address. Use the following configuration to do so:

 Switch(config)# ip slb vserver virtual_server_name Switch(config-slb-vserver)# virtual IP_address [tcp|udp port_#] Switch(config-slb-vserver)# serverfarm server_farm_name Switch(config-slb-vserver)# inservice Switch(config-slb-vserver)# client IP_address [subnet_mask] 

To create your virtual server information, use the ip slb vserver command. This command assigns a name to your virtual server and takes you into a subconfiguration mode. In the subconfiguration mode, use the virtual command to assign the virtual IP address used by the end stations. You can optionally specify that only traffic destined to the configured TCP or UDP port number should be redirected you can specify the port number or its name.

Follow this with the serverfarm command, which references the name of the server farm you created with the ip slb serverfarm command discussed previously. The inservice command activates the use of SLB with the virtual address. Optionally, you can use the client command to restrict which end stations can use SLB by default, all end stations use SLB if they have the virtual IP address in their packets. You can use the subnet mask value to cover a single client or clients from a range of addresses.

After you've configured SLB, you can use a handful of show commands to verify your configuration:

 Switch# show ip slb vserver|cons|stats 

Here's an example of the preceding show command with the vserver parameter:

 Switch# show ip slb vserver slb vserver     prot  virtual        state       cons --------------- ----- -------------- ----------- ---- HTTP_Server     TCP   192.168.1.5:80 OPERATIONAL    0 

In this example, one virtual server is configured, 192.168.1.5, for TCP 80 (www) traffic and it is enabled with the inservice command (OPERATIONAL).

Here's an example with the cons parameter:

 Switch# show ip slb cons Vserver      prot  client          real         state    nat ------------------------------------------------------------- HTTP_Server  TCP   200.200.200.20  192.168.1.10 CLOSING  none 

This command shows the connections that SLB is monitoring. In this example, a TCP HTTP connection is completing between an end station (200.200.200.20) and a real server (192.168.1.10).