Load balancing can be one of the telltale signs that indicate whether a network has been carefully planned or if it has grown up like weeds. By allowing redundant links to effectively double the available bandwidth, load balancing is something that every network should strive to implement.
This chapter briefly mentions the most popular alternatives available for implementing load balancing. As you go through this section, recognize that none of these accomplish round robin or per-packet load balancing. Therefore, although these techniques are most often referred to with the name load balancing, the name load sharing or load distribution might be more appropriate. However, do not get hung up with trying to achieve an exact 50/50 split when you implement load balancing over a pair of links. Just remember that any form of load balancing is preferable to the default operation of most campus protocols where only a single path is ever used.
Remember the Requirements for Load Balancing
Before diving into the details of various approaches to load balancing, it is worth pausing to examine some high-level considerations of load balancing. When thinking about load balancing, first look at the number of available paths. If you have only one set of paths through your network, load balancing (and, therefore, redundancy) is not possible. Most network designers strive to achieve two paths, as typically seen connected to an IDF/access layer switch. In some cases, especially inside a large campus core, more than two paths might be available.
Another consideration is the ease with which you can configure, manage, and troubleshoot a particular load balancing scheme. For example, the Root Bridge placement form of Spanning Tree load balancing is very easy to implement and troubleshoot.
Also, look at the flexibility of each style of load balancing. For instance, although Root Bridge placement scores very high on the simplicity scale, it can only be implemented in selected topologies (such as the Layer 2 triangles used by the multilayer model). By way of contrast, the portvlancost method of Spanning Tree load balancing is very flexible (however, it is also more complex).
Finally, consider the intelligence of a load balancing scheme. For example, some techniques such as EtherChannel use a very simple XOR algorithm on the low-order bits of IP or MAC address. On the other hand, Layer 3 routing protocols offer very sophisticated and tunable load balancing and, more importantly, path selection tools.
Important load balancing considerations include:
- Available paths
- Ease of configuration, management, and troubleshooting
Spanning Tree load balancing is useful within a redundant Layer 2 domain. As discussed in Chapter 7, there are four techniques available for load balancing under the Spanning-Tree Protocol:
- Root Bridge placement
- Port priority (portvlanpri)
- Bridge priority
- Port cost (portvlancost)
As discussed in Chapter 7 and earlier in this chapter, Root Bridge placement is the simplest and most effective technique if the network’s traffic flows support it. Fortunately, the multilayer model with routing switches (MLS) automatically generates a topology where the Root Bridges can be alternated between redundant MDF switches within a distribution block.
When working with the Spanning-Tree Protocol, try not to use the Root Bridge placement form of Spanning Tree load balancing.
Root Bridge placement is not effective in less constrained topologies such as campus-wide VLANs. In these cases, it is best to use the portvlancost form of load balancing. Although portvlancost is harder to use than Root Bridge placement, it is useful in almost any redundant topology. Think of it as the Swiss army knife of Spanning Tree load balancing.
When working with the Spanning-Tree Protocol, use portvlancost load balancing when the use of Root Bridge placement is not possible.
In situations where Layer 3 switching is being used, HSRP plays an important role. When using Layer 3 switching in networks that contain Layer 2 loops in the distribution block, such as with the multilayer model and routing switches (MLS), Spanning Tree and HSRP load balancing should be deployed in a coordinated fashion. For example, the network in Figure 15-9 modified the Spanning Tree parameters to force the odd VLANs to use the left link and the even VLANs to use the right link. HSRP should be added to this design by making MDF-A the active HSRP peer for the odd VLANs and MDF-B the active peer for the even VLANs.
Be sure to coordinate HSRP and Spanning Tree load balancing. This is usually required in networks employing routing switches and the multilayer model.
In cases where the switching router (8500) approach to the multilayer model is in use, HSRP might be the only option available for load balancing within each distribution block (there are no loops for Spanning Tree to be effective). Consequently, two HSRP groups should be used for each subnet. This configuration was discussed in Chapter 11 and is referred to as Multigroup HSRP (MHSRP). MHSRP can be used to load balance by alternating the HSRP priority values.
Use MHSRP load balancing for networks using switching router technology.
Figure 15-10 illustrates an example that provides load balancing for one subnet/VLAN on an IDF switch.
Figure 15-10. MHSRP Load Balancing
Both of the MDF switches are assigned two real IP addresses, 10.0.1.3 and 10.0.1.4. Rather than using a single standby group (which results in only one router and one riser link actively carrying traffic), two standby groups are configured. The first standby group uses an IP address of 10.0.1.1 and the priority of MDF-A has been increased to make it the active peer. The second standby group uses 10.0.1.2 and has MDF-B configured as the active peer. If both MDF switches are active, both riser links and both devices actively carry traffic. If either MDF device fails, the other MDF takes over with 100 percent of the load.
Another advantage in using Layer 3 switching is that IP routing protocols support very intelligent forwarding and path determination mechanisms. Whereas it can take considerable configuration to enable load balancing over two paths using techniques such as Spanning Tree load balancing and HSRP, Cisco routers automatically load balance up to six equal-cost paths (although Catalyst 8500s currently only load balance over two equal-cost paths because of the microcode memory limitations). Moreover, Layer 3 routing protocols support extensive path manipulation tools such as distribute lists and route maps.
Given that the multilayer design model focuses on Layer 3 switching in the MDF/distribution layer closets (and possibly the core), IP routing can be an extremely effective approach to load balancing across critical areas of the network such as the core (expensive WAN links are another area).
One of the benefits in using ATM in a campus environment is the sophistication of Private Network-Network Interface (PNNI) as an ATM routing and signaling protocol. Like IP, PNNI automatically load balances traffic over multiple paths. However, unlike IP, PNNI does not perform routing on every unit of information that it receives (cells). Instead, ATM only routes the initial call setup that is used to build the ATM connection. After the connection has been established, all remaining cells follow this single path. However, other calls between the same two ATM switches can use a different set of paths through a redundant ATM network (therefore, PNNI is said to do per connection load balancing). In this way, all of the paths within the ATM cloud are automatically utilized.
For more information on ATM, LANE, and PNNI, please consult Chapter 9, “Trunking with LAN Emulation.”
A final form of load balancing that can be useful for campus networks is EtherChannel. EtherChannel can only be used between a pair of back-to-back switches connected between two and eight links (although some platforms allow limited combinations). It uses an XOR algorithm on the low-order bits of MAC or IP addresses to assign frames to individual links. For more information, see Chapter 8, “Trunking Technologies and Applications.”
The 802.3ad committee of the IEEE is working on a standards-based protocol similar to Cisco’s EtherChannel.