CCNP BCMSN Exam Cram 2 (Exam Cram 642-811)
| 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.
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.
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 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:
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.
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 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.
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.
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.
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.
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:
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:
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:
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.
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.
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:
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:
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:
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 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). |