The preceding example shows one way to configure the priority to a lower value to become the root. Optionally, the spanning-tree vlan vlan-id root {primary | secondary} [diameter
diameter] command could be used. This command causes the switch to set the priority lower. The
optional diameter parameter causes this command to lower the Hello, forward delay, and maxage timers. (This command does not get placed into the configuration, but rather it acts as a macro, being expanded into the commands to set priority and the timers.)
Optimizing Spanning Tree
Left to default settings, IEEE 802.1D STP works, but convergence might take up to a minute or more for the entire network. For instance, when the root fails, a switch must wait on the 20-second maxage timer to expire. Then, newly forwarding ports spend 15 seconds each in listening and learning states, which makes convergence take 50 seconds for that one switch.
Over the years, Cisco added features to its STP code, and later the IEEE made improvements as well. This section covers the key optimizations to STP.
PortFast, UplinkFast, and BackboneFast
The Cisco-proprietary PortFast, UplinkFast, and BackboneFast features each solve specific STP problems. Table 3-5 summarizes when each is most useful, and the short version of how they improve convergence time.
Table 3-5 PortFast, UplinkFast, and BackboneFast
NOTE When using the primary option, the spanning-tree vlan command sets the priority to 24,576 if the current root has a priority larger than 24,576. If the current root’s priority is 24,576 or less, this command sets this switch’s priority to 4096 less than the current root. With the secondary keyword, this switch’s priority is set to 28,672. Also note that this logic applies to when the configuration command is executed; it does not dynamically change the priority if another switch later advertises a better priority.
KEY POINT
Feature Requirements for Use How Convergence Is Optimized PortFast Used on access ports that are not
connected to other switches or hubs
Immediately puts the port into forwarding state once the port is physically working UplinkFast Used on access layer switches that
have multiple uplinks to distribution/core switches
Immediately replaces a lost RP with an alternate RP, immediately forwards on the RP, and triggers updates of all switches’ CAMs
BackboneFast Used to detect indirect link failures, typically in the network core
Avoids waiting for Maxage to expire when its RP ceases to receive Hellos; does so by querying the switch attached to its RP
PortFast
PortFast optimizes convergence by simply ignoring listening and learning states on ports. In effect, convergence happens instantly on ports with PortFast enabled. Of course, if another switch is connected to a port on which PortFast is enabled, loops may occur. So, PortFast is intended for access links attached to single end-user devices. To be safe, you should also enable the BPDU Guard and Root Guard features when using PortFast, as covered later in this chapter.
UplinkFast
UplinkFast optimizes convergence when an uplink fails on an access layer switch. For good STP design, access layer switches should not become root or become transit switches. (A transit switch is a switch that forwards frames between other switches.) Figure 3-7 shows the actions taken when UplinkFast is enabled on a switch, and then when the Root Port fails.
Figure 3-7 UplinkFast Operations
Upon enabling UplinkFast globally in a switch, the switch takes three actions: ■ Increases the root priority to 49,152
■ Sets the post costs to 3000
■ Tracks alternate RPs, which are ports in which root Hellos are being received
As a result of these steps, SW3 can become root if necessary, but it is unlikely to do so given the large root priority value. Also, the very large costs on each link make the switch unlikely to be used as a transit switch. When the RP port does fail, SW3 can fail over to an alternate uplink as the new RP and forward immediately.
SW1 Fa0/1 Fa0/3 Fa0/2 RP: FWD Alt. RP: BLK Makes Fa0/2 the RP
Moves to forwarding state immediately
Sends multicasts for each
source MAC for local MACs
Enable Uplink Fast:
Sets priority to 49,152 Sets port costs to 3000 Tracksalternate RPs MAC 0200.3333.3333 0200.3333.3333 0100.0CCD.CDCD Root Switch Priority 8192 Non-Root Switch Priority (Default) 32768 Access Design SW3 SW2 RP Link Failure Occurs Dst. MAC Src. MAC R3 1 4 2 3
Optimizing Spanning Tree 75
The final step in Uplink Fast logic causes the switches to time-out the correct entries in their CAMs, but it does not use the TCN process. Instead, the access switch finds all the MAC addresses of local devices and sends one multicast frame with each local MAC address as the source MAC— causing all the other switches to update their CAMs. The access switch also clears out the rest of the entries in its own CAM.
BackboneFast
BackboneFast optimizes convergence for any generalized topological case, improving convergence when an indirect failure occurs. When some direct failures occur (for instance, a switch’s RP interface fails), the switch does not have to wait for maxage to expire. However, when another switch’s direct link fails, resulting in lost Hellos for other switches, the downstream switches indirectly learn of the failure because they cease to receive Hellos. Any time a switch learns of an STP failure indirectly, the switch must wait for maxage to expire before trying to change the STP topology.
BackboneFast simply causes switches that indirectly learn of a potential STP failure to ask their upstream neighbors if they know about the failure. To do so, when the first Hello goes missing, a BackboneFast switch sends a Root Link Query (RLQ) BPDU out the port in which the missing Hello should have arrived. The RLQ asks the neighboring switch if that neighboring switch is still receiving Hellos from the root. If that neighboring switch had a direct link failure, it can tell the original switch (via another RLQ) that this path to the root is lost. Once known, the switch experiencing the indirect link failure can go ahead and converge without waiting for maxage to expire.
PortFast, UplinkFast, and BackboneFast Configuration
Configuration of these three STP optimizing tools is relatively easy, as summarized in Table 3-6.
Table 3-6 PortFast, UplinkFast, and BackboneFast Configuration
NOTE All switches must have BackboneFast configured for it to work correctly.
Feature Configuration Command
PortFast spanning-tree portfast (interface subcommand) spanning-tree portfast default (global)
UplinkFast spanning-tree uplinkfast [max-update-rate rate] (global) BackboneFast spanning-tree backbonefast (global)
PortChannels
When a network design includes multiple parallel segments between the same pair of switches, one switch ends up in a forwarding state on all the links, but the other switch blocks all but one of the ports of those parallel segments. As a result, only one of the links can be used at any point in time. Using Fast EtherChannel (FEC) (using FastE segments) and Gigabit EtherChannel
(GEC) (using GigE segments) allows the combined links to be treated as one link from an STP
perspective, so that all the parallel physical segments are used. (When configuring a Cisco switch, a group of segments comprising an FEC or GEC is called a PortChannel.) Most campus designs today use a minimum of two segments per trunk, in a PortChannel, for better availability. That way, as long as at least one of the links in the EtherChannel is up, the STP path cannot fail, and no STP convergence is required.
Load Balancing Across PortChannels
When a switch decides to forward a frame out a PortChannel, the switch must also decide which physical link to use to send each frame. To use the multiple links, Cisco switches load balance the traffic over the links in an EtherChannel based on the switch’s global load-balancing configuration.
Load-balancing methods differ depending on the model of switch and software revision. Generally, load balancing is based on the contents of the Layer 2, 3, and/or 4 headers. If load balancing is based on only one header field in the frame, a bitmap of the low-order bits is used; if more than one header field is used, an XOR of the low-order bits is used.
For the best balancing effect, the header fields on which balancing is based need to vary among the mix of frames sent over the PortChannel. For instance, for a Layer 2 PortChannel connected to an access layer switch, most of the traffic going from the access layer switch to the
distribution layer switch is probably going from clients to the default router. So most of the frames have different source MAC addresses, but the same destination MAC address. For packets coming back from a distribution switch toward the access layer switch, many of the frames might have a source address of that same router, with differing destination MAC addresses. So, you could balance based on source MAC at the access layer switch, and based on destination MAC at the distribution layer switch—or balance based on both fields on both switches. The goal is simply to use a balancing method for which the fields in the frames vary.
The port-channel load-balance type command sets the type of load balancing. The type options include using source and destination MAC, IP addresses, and TCP and UDP ports—either a single field or both the source and destination.
Optimizing Spanning Tree 77
PortChannel Discovery and Configuration
You can explicitly configure interfaces to be in a PortChannel by using the channel-group number mode on interface subcommand. You would simply put the same command under each of the physical interfaces inside the PortChannel, using the same PortChannel number.
You can also use dynamic protocols to allow neighboring switches to figure out which ports should be part of the same PortChannel. Those protocols are the Cisco-proprietary Port Aggregation
Protocol (PAgP) and the IEEE 802.1AD Link Aggregation Control Protocol (LACP). To dynami-
cally form a PortChannel using PAgP, you still use the channel-group command, with a mode of auto or desirable. To use LACP to dynamically create a PortChannel, use a mode of active or passive. Table 3-7 lists and describes the modes and their meanings.
Table 3-7 PAgP and LACP Configuration Settings and Recommendations
When PAgP or LACP negotiate to form a PortChannel, the messages include the exchange of some key configuration information. As you might imagine, they exchange a system ID to determine which ports connect to the same two switches. The two switches then exchange other information about the candidate links for a PortChannel; several items must be identical on the links for them to be dynamically added to the PortChannel, as follows:
■ Same speed and duplex settings. ■ If not trunking, same access VLAN.
■ If trunking, same trunk type, allowed VLANs, and native VLAN.
■ On a single switch, each port in a PortChannel must have the same STP cost per VLAN on all links in the PortChannel.
■ No ports can have SPAN configured. PAgP
Setting
LACP 802.1AD
Setting Action
on on Disables PAgP or LACP, and forces the port into the PortChannel off off Disables PAgP or LACP, and prevents the port from being part of a
PortChannel
auto passive Uses PAgP or LACP, but waits on other side to send first PAgP or LACP message
desirable active Uses PAgP or LACP, and initiates the negotiation
NOTE Using auto (PAgP) or passive (LACP) on both switches prevents a PortChannel from forming dynamically. Cisco recommends the use of desirable mode (PAgP) or active mode (LACP) on ports that you intend to be part of a PortChannel.
When PAgP or LACP completes the process, a new PortChannel interface exists, and is used as if it were a single port for STP purposes, with balancing taking place based on the global load- balancing method configured on each switch.