HSRP

HSRP

Cisco's Hot Standby Router Protocol (HSRP) plays an important role in most campus networks. The primary mission of HSRP is providing a redundant default gateway for end stations. However, it can also be used to provide load balancing. This section discusses both of these issues.

Many end stations allow only a single default gateway. Normally, this makes these hosts totally dependent on one router when communicating with all nodes off the local subnet. To avoid this limitation, HSRP provides a mechanism to allow this single IP address to be shared by two or more routers as illustrated in Figure 11-26.

Figure 11-26. HSRP Allows Multiple Routers to Share IP and MAC Addresses

Although both routers are assigned unique IP addresses as normal (10.1.1.2 and 10.1.1.3), HSRP provides a third address that both routers share. The two routers exchange periodic hello messages (every three seconds by default) to monitor the status of each other. One router is elected the active HSRP peer and handles all router responsibilities for the shared address. The other node then acts as the standby HSRP peer. If the standby peer misses three HSRP hellos, it then assumes that the active peer has failed and takes over the role of the active peer.

One of the subtleties of HSRP is that the routers do not just share an IP address. To create a truly transparent failover mechanism, they must also share a MAC address. The routers therefore use an algorithm to create a shared virtual MAC address. As with the shared IP address, the active peer is the only node using the derived MAC address. However, if the active peer fails, the other device not only adopts the shared IP address, but also the shared MAC address. By doing so, the ARP cache located in every end station on the network does not require updating after a failover situation.

Tip

Although the shared MAC address prevents ARP cache problems during an HSRP failover scenario, it can be a problem when initially testing HSRP. For example, assume that you convert an existing router using the 10.1.1.1 address into an HSRP configuration where 10.1.1.1 becomes the shared IP address. At this point, the end stations still have the real MAC address associated with the original router, not the virtual MAC address created by HSRP. To solve this problem, reboot the end stations or clear their ARP caches.

Note that HSRP can be useful even in cases where the TCP/IP stack running on your clients supports multiple default gateways. In some cases, the mechanisms used by these stacks to failover to an alternate default gateway do not work reliably. In other cases, such as with current Microsoft stacks, the redundancy feature only works for certain protocols (such as TCP, but not UDP). In either case, most organizations do not want to leave default gateway reliability to chance and instead implement HSRP.

Tip

HSRP is useful even if your TCP/IP stack allows multiple default gateways.

Example 11-18 presents a sample HSRP configuration for the Router-A in Figure 11-26.

Example 11-18 HSRP Configuration for Router-A

 interface Ethernet0  description Link to wiring closet Catalysts  ip address 10.1.1.2 255.255.255.0  standby 1 priority 110  standby 1 preempt  standby 1 ip 10.1.1.1  standby 1 track Ethernet1 15 ! interface Ethernet1  description Link to backbone  ip address 10.1.2.2 255.255.255.0 

The real IP address is assigned with the usual ip address command. HSRP parameters are then configured using various standby commands. The shared IP address is added with standby group_number ip ip_address command. This command needs to be entered on both routers.

Tip

The group_number parameters on both routers must match.

In most campus designs, some thought should be given as to the proper placement of the active peer. In general, the following guidelines should be used:

• The active HSRP peer should be located near or at the Spanning Tree Root Bridge.

• A router should relinquish its role as the active HSRP peer if it looses its connection to the backbone.

In networks that contain Layer 2 loops, the Spanning Tree Root Bridge acts as the center of the universe. Other bridges then look for the most efficient path to this device. By placing the active HSRP peer at or near the Root Bridge, the Spanning-Tree Protocol automatically helps end-user traffic follow the best path to the default gateway. For example, if Router-A is the active HSRP peer in Figure 11-26 but Cat-B is the Spanning Tree Root Bridge, Segment-1 has a port in the Blocking state. This forces all of the default gateway traffic to take an inefficient path through Cat-B (using Segment 2 and Segment 3). By co-locating the active HSRP peer and the Root Bridge at Cat-A and Router-A, this unnecessary bridge hop can be eliminated.

To force Cat-A to be the Root Bridge, the set spantree root or set spantree priority commands discussed in Chapter 6 can be used. To force Router-A to the active HSRP peer, the standby group_number priority priority_value command can be used. The peer with the highest priority_value becomes the active peer (the default is 100). In this case, Router-A has a configured priority of 110, making it win the active peer election. However, if Router-A boots after Router-B, it does not supercede Router-B by default (it waits for Router-B to fail first), creating the same inefficient pattern discussed earlier. This can be avoided by configuring the standby group_number preempt command. This causes a router to instantly take over as soon as it has the highest priority.

Tip

Unlike the Spanning-Tree Protocol where lower values are always preferred, HSRP prefers higher values.

The second guideline speaks to a situation where a router has the highest priority, but it has lost its connection to the rest of the network. For example, Router-A is the active HSRP peer but its Ethernet1 link goes down. Although this does not prevent traffic from reaching the backbone (Router-A can use its Ethernet0 interface to send traffic to the backbone through Router-B), it does lead to an inefficient flow. To prevent this situation, the standby track option can be used as shown in Example 11-18. The value indicated by the standby track command is the value that gets decremented from the node's priority if the specified interface goes down. Multiple standby track commands can be used to list multiple interfaces to track (if more than one interface goes down, the decrement values are cumulative). In this example, if Router-A loses interface Ethernet1, the priority is lowered to 95. Because this is lower than the default priority of 100 being used by Router-B, Router-B takes over as the active peer and provides a more optimal flow to the backbone.

Although the configuration discussed in this section does provide a redundant default gateway for the end stations connected to Cat-C, it does suffer from one limitation: Router-A is handling all of the traffic. To eliminate this problem, multiple VLANs should be created on Cat-C. Each VLAN uses a separate group_number on the standby command. Then, the VLANs should alternate active peers between the two routers. For example, Router-A could be the active peer for all odd-numbered VLANs, and Router-B could be the active peer for all even-numbered VLANs. Example 11-19 presents a sample configuration for Router-A (two VLANs and an ISL interface are used).

Example 11-19 ISL HSRP Configuration for Router-A

 interface FastEthernet0/0/0  description Link to wiring closet Catalyst  no ip address ! interface FastEthernet0/0/0.1  encapsulation isl 1  ip address 10.1.1.3 255.255.255.0  standby 1 priority 110  standby 1 preempt  standby 1 ip 10.1.1.1  standby 1 track FastEthernet0/0/1 15 ! interface FastEthernet0/0/0.2  encapsulation isl 2  ip address 10.1.2.2 255.255.255.0  standby 2 priority 100  standby 2 preempt  standby 2 ip 10.1.2.1 ! interface Ethernet0/0/1  description Link to backbone  ip address 10.1.3.2 255.255.255.0 

Example 11-20 shows the corresponding configuration for Router-B.

Example 11-20 ISL HSRP Configuration for Router-B

 interface FastEthernet0/0/0  description Link to wiring closet Catalyst  no ip address ! interface FastEthernet0/0/0.1  encapsulation isl 1  ip address 10.1.1.4 255.255.255.0  standby 1 ip 10.1.1.1  standby 1 priority 100  standby 1 preempt ! interface FastEthernet0/0/0.2  encapsulation isl 2  ip address 10.1.2.3 255.255.255.0  standby 2 ip 10.1.2.1  standby 2 priority 110  standby 2 track FastEthernet0/0/1 15  standby 2 preempt ! interface Ethernet0/0/1  description Link to backbone  ip address 10.1.3.3 255.255.255.0 

Tip

Alternate HSRP active peers for different VLANs between a pair of routers. This provides load balancing in addition to redundancy.

As discussed earlier, alternating HSRP active peer placements should obviously be coordinated with the Spanning Tree Root Bridge configuration. Cat-A should be the Root Bridge for the odd VLANs, and Cat-B should be the Root Bridge for the even VLANs.

Tip

The HSRP syntax allows a single standby group to be created without specifying the group_number parameter. However, I recommended that you always specify this parameter so that it is much easier to add other standby groups in the future. Also, using the default standby group can lead to very strange behavior if you accidentally use it in an attempt to configure HSRP for multiple VLANs.

Load Balancing with MHSRP

Using Spanning Tree and multiple VLANs can be effective if Layer 2 loops and multiple VLANs exist on Cat-C, the wiring closet switch. However, this is not always the case. Many network designers want to deploy networks similar to the one illustrated in Figure 11-27.

Figure 11-27. A Network Using a Single VLAN in the Wiring Closet

The design in Figure 11-27 has the wiring closet switch directly connected to a pair of switching routers such as the Catalyst 8500. This eliminates all Layer 2 loops and removes Spanning Tree from the equation (although there is a link between the two routers, it is a separate subnet). Furthermore, because a single VLAN is in use on Cat-C, the wiring closet switch, the alternating VLANs trick cannot be used.

In this case, the most effective solution is the use of Multigroup HSRP (MHSRP). This feature allows multiple HSRP group_numbers to be used on a single interface. For example, Example 11-21 shows a possible configuration for Router-A.

Example 11-21 MHSRP Configuration on a Catalyst 8500

 interface FastEthernet0/0/0  description Link to wiring closet Catalyst  ip address 10.1.1.3 255.255.255.0  standby 1 ip 10.1.1.1  standby 1 priority 110  standby 1 track FastEthernet0/0/1 15  standby 1 preempt  standby 2 ip 10.1.1.2  standby 2 priority 100  standby 2 preempt 

Note

Some of the low-end routers use a Lance Ethernet chipset that does not support MHSRP. However, all of the devices suitable for campus backbone use do support MHSRP.

The code in Example 11-21 creates two shared addresses between Router-A and Router-B for a single subnet. Load balancing can then be implemented by having half of the hosts on Cat-C use 10.1.1.1 as a default gateway and the other half use 10.1.1.2. The potential downside is that you have to come up with some way of configuring different hosts to use different default gateways. Fortunately, DHCP provides a simple and effective technique to accomplish this.

Because existing DHCP standards do not provide for server-to-server communication, organizations are forced to divide every scope (a scope can be loosely defined as a subnet's worth of DHCP addresses) of addresses into two blocks (assuming they want redundant DHCP servers). Each of two redundant DHCP servers receives one half of each scope. For example, a /24 subnet with 54 addresses reserved for fixed configuration leaves 200 addresses available for DHCP. 100 of these addresses can be placed on the first DHCP server and the other 100 are placed on the second DHCP server. If one of the DHCP servers fails, the other can provide addresses for clients on the network (assuming that no more than 100 new addresses are required). Because each server has its own block of globally unique addresses for every server, the lack of a server-to-server protocol is not a problem.

DHCP supports a variety of options that can be used to configure client stations. The DHCP Option 3 allows DHCP servers to provide a default gateway (or a list of default gateways) to clients. Simply configure one DHCP server with the first shared HSRP address (10.1.1.1 in Figure 11-26) and the other DHCP server with the second shared HSRP address (10.1.1.2).

For this technique to work, it requires a fairly random distribution of leases between the two DHCP servers. If one server ends up issuing 90 percent of the leases, one of the routers likely receives 90 percent of the traffic. To help ensure a random distribution, you should place the two DHCP servers close to each other (generally in the same server farm). You can also alternate the order of ip helper-address statements between the two routers. For example, assuming that the DHCP servers have the addresses 10.1.55.10 and 10.1.55.11, Router-A might use the ip helper-address configuration in Example 11-22.

Example 11-22 IP Helper Address Configuration for Router-A

 interface FastEthernet0/0/0  ip helper-address 10.1.55.10  ip helper-address 10.1.55.11 

Conversely, Router-B can then use the opposite order as demonstrated in Example 11-23.

Example 11-23 IP Helper Address Configuration for Router-B

 interface FastEthernet0/0/0  ip helper-address 10.1.55.11  ip helper-address 10.1.55.10 

This causes Router-A to give a slight advantage to the DHCP server located as 10.1.55.10, but Router-B gives an advantage to the other DHCP server. In general, both servers have an equal chance of responding first to the DHCP_DISCOVER packets that clients use to request a lease.

Tip

If this DHCP and MHSRP trick is not to your liking, consider placing a Layer 3 switch in the IDF wiring closet. Although this can be cost-prohibitive, it allows all devices connected to that IDF to use the IDF switch itself as a default gateway. The Layer 3 routing capabilities in the IDF switch can then choose the best path to use into the campus backbone and automatically balance the load over both uplinks. However, I should also point out that this can be difficult to implement with routing switch (MLS) devices. In general, it is much easier to accomplish with switching router designs such as the Catalyst 8500 and the native IOS router mode of the 6000.