CCNP Switch: Spanning Tree Configuration

CCNP Switch: Spanning Tree Configuration

STP Root Bridge

STP and its computations are predictable; however, other factors might subtly influence STP decisions, making the resulting tree structure neither expected nor ideal.

As the network administrator, you can make adjustments to the spanning-tree operation to control its behavior. The location of the Root Bridge should be determined as part of the design process. You can use redundant links for load balancing in parallel, if configured correctly. You can also configure Spanning Tree Protocol (STP) to converge quickly and predictably in the event of a major topology change.

Switch(config)# spanning-tree vlan vlan-id

Switch (config-if)# spanning-tree vlan vlan-id

Root Bridge Placement

Although STP is wonderfully automatic with its default values and election processes, the resulting tree structure might perform quite differently than expected. The Root Bridge election is based on the idea that one switch is chosen as a common reference point, and all other switches choose ports that have the best-cost path to the root. The Root BRIDGE election is also based on the idea that the Root Bridge can become a central hub that interconnects other legs of the network. Therefore, the Root Bridge can be faced with heavy switching loads in its central location.

If the Root Bridge election is left to its default state, several things can occur to result in a poor choice. For example, the slowest switch (or bridge) could be elected as the Root Bridge. If heavy traffic loads are expected to pass through the Root Bridge, the slowest switch is not the ideal candidate. Recall that the only criteria for Root Bridge election is that the switch must have the lowest Bridge ID (bridge priority and MAC address), which is not necessarily the best choice to ensure optimal performance. If the slowest switch has the same bridge priority as the others and has the lowest MAC address, the slowest switch will be chosen as the root.

A second factor to consider relates to redundancy. If all switches are left at their default states, only one Root Bridge is elected, with no clear choice for a backup. What happens if that switch fails? Another Root Bridge election occurs, but again, the choice might not be the ideal switch or the ideal location.

The final consideration is the location of the Root Bridge switch. As before, an election with default switch values could place the Root Bridge in an unexpected location in the network. More important, an inefficient spanning-tree structure could result, causing traffic from a large portion of the network to take a long and winding path just to pass through the Root Bridge. Figure 10-1 shows a portion of a real-world hierarchical campus network.

Figure 10-1 Campus Network with an Inefficient Root Bridge Election

Catalyst switches A and B are two access-layer devices; Catalysts C and D form the core layer, and Catalyst E connects a server farm into the network core. Notice that most of the switches use redundant links to other layers of the hierarchy, as suggested in Chapter 2, “Modular Network

Design.” At the time of this example, however, many switches, such as Catalyst B, still have only a single connection into the core. These switches are slated for an “upgrade,” in which a redundant link will be added to the other half of the core.

As you will see, Catalyst A will become the Root Bridge because of its low MAC address. All switches have been left to their default STP states—the bridge priority of each is 32,768 (or 32,768 plus the VLAN ID, if the extended system ID is enabled). Figure 10-2 shows the converged state of STP. For the purposes of this discussion, the root ports and designated ports are simply shown on the network diagram. As an exercise, you should work through the spanning-tree process yourself, based on the information shown in the figure. The more examples you can work out by hand, the better you will understand the entire spanning-tree process.

Figure 10-2 Campus Network with STP Converged

Notice that Catalyst A, one of the access-layer switches, has been elected the Root Bridge. Unfortunately, Catalyst A cannot take advantage of the 1-Gbps links, unlike the other switches.

Also note the location of the X symbols over the ports that are neither root ports nor designated ports. These ports will enter the Blocking state, and no data packets will pass through them. Finally, Figure 10-3 shows the same network with the blocking links removed. Now you can see the true structure of the final spanning tree.

Figure 10-3 Final Spanning-Tree Structure for the Campus Network

Catalyst A, an access-layer switch, is the Root Bridge. Workstations on Catalyst A can reach servers on Catalyst E by crossing through the core layer (Catalyst C), as expected. However, notice what has happened to the other access-layer switch, Catalyst B. Workstations on this switch must cross into the core layer (Catalyst D), back into the access layer (Catalyst A), back through the core (Catalyst C), and finally to the server farm (Catalyst E).

This action is obviously inefficient. For one thing, Catalyst A is probably not a high-end switch because it is used in the access layer. However, the biggest issue is that other access-layer areas are forced to thread through the relatively slow uplinks on Catalyst A. This winding path will become a major bottleneck to the users.

Root Bridge Configuration

To prevent the surprises outlined in the previous section, you should always do two things:

• Configure one switch as a Root Bridge in a determined fashion.
• Configure another switch as a secondary Root Bridge, in case of a primary Root Bridge failure.

As the common reference point, the Root Bridge (and the secondary) should be placed near the center of the Layer 2 network. For example, a switch in the distribution layer would make a better Root Bridge choice than one in the access layer because more traffic is expected to pass through the distribution-layer devices. In a flat switched network (no Layer 3 devices), a switch near a server farm would be a more efficient Root Bridge than switches elsewhere. Most traffic will be destined to and from the server farm and will benefit from a predetermined, direct path.

Switch(config)# spanning-tree extend system-id

You can configure a Catalyst switch to become the Root Bridge using one of two methods, which are configured as follows:

• Manually setting the bridge priority value so that a switch is given a lower-than-default Bridge ID value to win a Root Bridge election. You must know the bridge priorities of every other switch in a VLAN so that you can choose a value that is less than all the others. The command to accomplish this is as follows:

  Switch(config)# spanning- tree vlan vlan-list priority bridge-priority

The bridge-priority value defaults to 32,768, but you can also assign a value of 0 to 65,535. If STP extended system ID is enabled, the default bridge-priority is 32,768 plus the VLAN number. In that case, the value can range from 0 to 61,440, but only as multiples of 4096. A lower bridge priority is preferable.

Remember that Catalyst switches run one instance of STP for each VLAN (PVST+), so the VLAN ID must always be given. You should designate an appropriate Root Bridge for each VLAN. For example, you could use the following command to set the bridge priority for VLAN 5 and VLANs 100 through 200 to 4096:

Switch(config)# spanning- tree vlan 5, 1 00- 200 priority 4096

• Causing the would-be Root Bridge switch to choose its own priority, based on some assumptions about other switches in the network. You can accomplish this with the following command:

  Switch(config)# spanning- tree vlan vlan-id root {primary | secondary} [ diameter diameter]

This command is actually a macro on the Catalyst that executes several other commands. The result is a more direct and automatic way to force one switch to become the Root Bridge. Notice that the actual bridge priorities are not given in the command. Instead, the switch modifies its STP values according to the current values in use within the active network. These values are modified only once, when the macro command is issued. Use the primary keyword to make the switch attempt to become the primary Root Bridge. This command modifies the switch’s bridge priority value to become less than the bridge priority of the current Root Bridge. If the current root priority is more than 24,576, the local switch sets its priority to 24,576. If the current root priority is less than that, the local switch sets its priority to 4096 less than the current root.

For the secondary Root Bridge, the root priority is set to an artificially low value of 28,672. There is no way to query or listen to the network to find another potential secondary root simply because there are no advertisements or elections of secondary Root Bridges. Instead, the fixed secondary priority is used under the assumption that it will be less than the default priorities (32,768) that might be used on switches elsewhere. You can also modify the network diameter by adding the diameter keyword to this command. This modification is discussed further in the “Tuning Spanning-Tree Convergence” section later in the chapter.

As a final example, consider a switch that is currently using its default bridge priority for VLAN 100. In the extended system-id mode, the default priority is 32,768 plus 100 (the VLAN number). The output in Example 10-1 demonstrates this under the Bridge ID information. The default priority is greater than the current Root Bridge priority of 4200, so the local switch cannot become the root.

Example 10-1 Displaying the STP Bridge Priority Values

Switch# show spanning- tree vlan 1 00
VLAN0100
 Spanning tree enabled protocol ieee
 Root ID Priority 4200
 Address 000b.5f65.1f80
 Cost 4
 Port 1 (GigabitEthernet0/1)
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Bridge ID Priority 32868 (priority 32768 sys-id-ext 100)
 Address 000c.8554.9a80
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300
[output omitted]

Now, the automatic method is used to attempt to make the switch become root for VLAN 100, using the command demonstrated in Example 10-2.

Example 10-2 Using a Macro Command to Configure a Root Bridge

Switch(config)# spanning- tree vlan 1 00 root primary
% Failed to make the bridge root for vlan 100
% It may be possible to make the bridge root by setting the priority
% for some (or all) of these instances to zero.
Switch(config)#

Why did this method fail? The current Root Bridge has a bridge priority of 4200. Because that priority is less than 24,576, the local switch will try to set its priority to 4096 less than the current root. Although the resulting priority would be 104, the local switch is using an extended system ID, which requires bridge priority values that are multiples of 4096. The only value that would work is 0, but the automatic method will not use it. Instead, the only other option is to manually configure the bridge priority to 0 with the following command:

Switch(config)# spanning- tree vlan 1 00 priority 0

Remember that on switches that use an extended system ID, the bridge priority is the configured priority (multiple of 4096) plus the VLAN number. Even though the priority was set to 0 with the previous command, the switch is actually using a value of 100—priority 0 plus VLAN number 100, as the output in Example 10-3 reveals.

Example 10-3 Displaying Bridge Priorities with Extended System IDs

Switch# show spanning- tree vlan 1 00
VLAN0100
 Spanning tree enabled protocol ieee
 Root ID Priority 100
 Address 000c.8554.9a80
 This bridge is the root
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Bridge ID Priority 100 (priority 0 sys-id-ext 100)
 Address 000c.8554.9a80
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300
[output omitted]

NOTE The spanning-tree vlan vlan-id root command will not be shown in a Catalyst switch configuration because the command is actually a macro executing other switch commands. The actual commands and values produced by the macro will be shown, however. For example, the macro can potentially adjust the four STP values as follows:

Switch(config)# spanning-tree vlan 1 root primary
 vlan 1 bridge priority set to 24576
 vlan 1 bridge max aging time unchanged at 20
 vlan 1 bridge hello time unchanged at 2
 vlan 1 bridge forward delay unchanged at 15

Be aware that this macro doesn’t guarantee that the switch will become the root and maintain that status. After the macro is used, it is entirely possible for another switch in the network to have its bridge priority configured to a lower value. The other switch would become the new root, displacing the switch that ran the macro.

On the root, it is usually good practice to directly modify the bridge priority to an artificially low value (even priority 1 or 0) with the spanning-tree vlan vlan-id priority bridge-priority command. This makes it more difficult for another switch in the network to win the Root Bridge election, unless it is manually configured with a priority that is even lower.

Spanning-Tree Customization

The most important decision you can make when designing your spanning-tree topology is the placement of the Root Bridge. Other decisions, such as the exact loop-free path structure, will occur automatically as a result of the Spanning Tree Algorithm (STA). Occasionally, the path might need additional tuning, but only under special circumstances and after careful
consideration.
Recall the sequence of four criteria that STP uses to choose a path:

1. Lowest Bridge ID
2. Lowest root path cost
3. Lowest sender Bridge ID
4. Lowest sender port ID

The previous section discussed how to tune a switch’s Bridge ID to force it to become the Root Bridge in a network. You can also change the bridge priority on a switch to influence the value it uses in the sender Bridge ID that it announced as it relays BPDUs to other neighboring switches. Only the automatic STP computation has been discussed, using the default switch port costs to make specific path decisions. The following sections discuss ways you can influence the exact topology that results.

Tuning the Root Path Cost

The root path cost for each active port of a switch is determined by the cumulative cost as a BPDU travels along. As a switch receives a BPDU, the port cost of the receiving port is added to the root path cost in the BPDU. The port or port path cost is inversely proportional to the port’s bandwidth. If desired, a port’s cost can be modified from the default value.

NOTE Before modifying a switch port’s path cost, you should always calculate the root path costs of other alternate paths through the network. Changing one port’s cost might influence STP to choose that port as a root port, but other paths still could be preferred. You also should calculate a port’s existing path cost to determine what the new cost value should be. Careful calculation will ensure that the desired path indeed will be chosen.

Use the following interface-configuration command to set a switch port’s path cost:

Switch (config-if)# spanning- tree [ vlan vlan-id] cost cost

If the vlan parameter is given, the port cost is modified only for the specified VLAN. Otherwise, the cost is modified for the port as a whole (all active VLANs). The cost value can range from 1 to 65,535. There are standard or default values that correspond to port bandwidth, as shown in Table 10-2.

Table 10-2 STP Port Cost

For example, a Gigabit Ethernet interface has a default port cost of 4. You can use the following command to change the cost to 2, but only for VLAN 10:

Switch(config)# spanning- tree vlan 1 0 cost 2

You can see the port cost of an interface by using the following command:

Switch# show spanning- tree interface type mod/num [ cost]

As an example, GigabitEthernet 0/1 is configured as a trunk port, carrying VLANs 1, 10, and 20.
Example 10-4 shows the port cost for each of the VLANs.

Example 10-4 Displaying STP Port Cost Values on an Interface

Switch# show spanning- tree interface gigabitEthernet 0/1
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0001 Root FWD 4 128.1 P2p
VLAN0010 Desg FWD 2 128.1 P2p
VLAN0020 Root FWD 4 128.1 P2p

Tuning the Port ID

The fourth criteria of an STP decision is the port ID. The port ID value that a switch uses is actually a 16-bit quantity: 8 bits for the port priority and 8 bits for the port number. The port priority is a value from 0 to 255 and defaults to 128 for all ports. The port number can range from 0 to 255 and represents the port’s actual physical mapping. Port numbers begin with 1 at port 0/1 and increment across each module. (The numbers might not be consecutive because each module is assigned a particular range of numbers.)

Switch# show spanning-tree interface gigabitEthernet 3/16
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0010 Desg FWD 4 128.144 Edge P2p
VLAN0100 Desg FWD 4 128.144 Edge P2p
VLAN0200 Desg FWD 4 128.144 Edge P2p
Switch#

The entire port ID consists of the port priority followed by the port number. In the preceding example output, the port ID is 128.144. As a 16-bit quantity in hex, it is 8090. In addition, ports that are bundled into an EtherChannel or Port-channel interface always have a higher port ID than they would if they were not bundled.TIP Port numbers are usually intuitive on a fixed configuration switch, such as a 48-port Catalyst 3560. The STP port number is simply the interface number, from 1 to 48. However, it is not easy to find the STP port number in a switch with many modules and many ports. Notice how GigabitEthernet 3/16 is also known as port number 144 in the following example:

Switch# show spanning-tree interface gigabitEthernet 3/16
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0010 Desg FWD 4 128.144 Edge P2p
VLAN0100 Desg FWD 4 128.144 Edge P2p
VLAN0200 Desg FWD 4 128.144 Edge P2p
Switch#

The entire port ID consists of the port priority followed by the port number. In the preceding example output, the port ID is 128.144. As a 16-bit quantity in hex, it is 8090. In addition, ports that are bundled into an EtherChannel or Port-channel interface always have a higher port ID than they would if they were not bundled.

Obviously, a switch port’s port number is fixed because it is based only on its hardware location or index. The port ID, however, can be modified to influence an STP decision by using the port priority. You can configure the port priority with this interface-configuration command:

Switch(config-if)# spanning- tree [ vlan vlan-list] port- priority port-priority

You can modify the port priority for one or more VLANs by using the vlan parameter. The VLAN numbers are given as vlan-list, a list of single values or ranges of values separated by commas. Otherwise, the port priority is set for the port as a whole (all active VLANs). The value of portpriority can range from 0 to 255 and defaults to 128. A lower port priority value indicates a more preferred path toward the Root Bridge.

As an example, you can use the following command sequence to change the port priority of GigabitEthernet 3/16 from 128 (the default) to 64 for VLANs 10 and 100:

Switch(config)# interface gigabitethernet 3/1 6
Switch(config-if)# spanning- tree vlan 1 0, 1 00 port- priority 64

You can confirm the changes with the show spanning-tree interface command, as demonstrated in Example 10-5.

Example 10-5 Confirming STP Port Priority Values After Configuration

Switch# show spanning- tree interface gigabitEthernet 3/1 6
Vlan Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
VLAN0010 Desg FWD 4 64.144 Edge P2p
VLAN0100 Desg FWD 4 64.144 Edge P2p
VLAN0200 Desg FWD 4 128.144 Edge P2p
Switch#

Tuning Spanning-Tree Convergence

STP uses several timers, a sequence of states that ports must move through, and specific topology change conditions to prevent bridging loops from forming in a complex network. Each of these parameters or requirements is based on certain default values for a typical network size and function. For the majority of cases, the default STP operation is sufficient to keep the network loop free and enable users to communicate.

However, in certain situations, the default STP can cause network access to be delayed while timers expire and while preventing loops on links where loops are not possible. For example, when a single PC is connected to a switch port, a bridging loop is simply not possible. Another situation relates to the size of a Layer 2 switched network: The default STP timers are based on a benchmark network size.

In a network that is smaller, waiting until the default timer values expire might not make sense when they could be safely set to shorter values. In situations like this, you can safely make adjustments to the STP convergence process for more efficiency.

Modifying STP Timers

Recall that STP uses three timers to keep track of various port operation states and communication between bridges. The three STP timers can be adjusted by using the commands documented in the sections that follow. Remember that the timers need to be modified only on the Root Bridge because the Root Bridge propagates all three timer values throughout the network as fields in the configuration BPDU.

Manually Configuring STP Timers

Use one or more of the following global configuration commands to modify STP timers:

Switch(config)# spanning- tree [ vlan vlan-id] hello- time seconds
Switch(config)# spanning- tree [ vlan vlan-id] forward- time seconds
Switch(config)# spanning- tree [ vlan vlan-id] max- age seconds

Notice that the timers can be changed for a single instance (VLAN) of STP on the switch by using the vlan vlan-id parameters. If you omit the vlan keyword, the timer values are configured for all instances (all VLANs) of STP on the switch.

The Hello timer triggers periodic “hello” (actually, the configuration BPDU) messages that are sent from the root to other bridges in the network. This timer also sets the interval in which a bridge expects to hear a hello relayed from its neighboring bridges. Configuration BPDUs are sent every 2 seconds, by default. You can modify the Hello timer with the hello-time keyword, along with a value of 1 to 10 seconds, as in the following command:

Switch(config)# spanning- tree hello- time 1

The Forward Delay timer determines the amount of time a port stays in the Listening state before moving into the Learning state, and how long it stays in the Learning state before moving to the Forwarding state. You can modify the Forward Delay timer with the forward-time keyword. The default value is 15 seconds, but this can be set to a value of 4 to 30 seconds. This timer should be modified only under careful consideration because the value depends on the diameter of the network and the propagation of BPDUs across all switches. A value that is too low allows loops to form, possibly crippling a network.

The Max Age timer specifies a stored BPDU’s lifetime that has been received from a neighboring switch with a designated port. Suppose that BPDUs are being received on a nondesignated switch port every 2 seconds, as expected. Then an indirect failure, or one that doesn’t involve a physical link going down, occurs that prevents BPDUs from being sent. The receiving switch waits until the Max Age timer expires to listen for further BPDUs. If none is received, the nondesignated port moves into the Listening state, and the receiving switch generates configuration BPDUs. This port then becomes the designated port to restore connectivity on the segment.

To modify the Max Age timer, use the max-age keyword. The timer value defaults to 20 seconds but can be set from 6 to 40 seconds.

Automatically Configuring STP Timers

Modifying STP timers can be tricky, given the conservative nature of the default values and the calculations needed to derive proper STP operation. Timer values are basically dependent on the Hello Time and the switched network’s diameter, in terms of switch hops. Catalyst switches offer a single command that can change the timer values in a more controlled fashion. Although described earlier, the spanning-tree vlan vlan-list root macro command is a better tool to use than setting the timers with the individual commands. This global configuration command has the
following syntax:

Switch(config)# spanning- tree vlan vlan-list root {primary | secondary} [ diameter diameter [ hello- time hello-time]]

Here, STP timers will be adjusted according to the formulas specified in the 802.1D standard by giving only the network’s diameter (the maximum number of switches that traffic will traverse across a Layer 2 network) and an optional hello-time. If you do not specify a Hello Time, the default value of 2 seconds is assumed.

This command can be used only on a per-VLAN basis, to modify the timers for a particular VLAN’s spanning tree instance. The network diameter can be a value from one to seven switch hops. Because this command makes a switch become the Root Bridge, all the modified timer values resulting from this command will be propagated to other switches through the configuration BPDU.

As an example, suppose that a small network consists of three switches connected in a triangle fashion. The command output in Example 10-6 shows the current (default) STP timer values that are in use for VLAN 100.

Example 10-6 Displaying the STP Timer Values in Use

Switch# show spanning- tree vlan 1 00
VLAN0100
 Spanning tree enabled protocol ieee
 Root ID Priority 100
 Address 000c.8554.9a80
 This bridge is the root
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Bridge ID Priority 100 (priority 0 sys-id-ext 100)
 Address 000c.8554.9a80
 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
 Aging Time 300
[output omitted]

The longest path that a packet can take through the example network is 3 switches. This is considerably less than the reference diameter of 7 that is used to calculate the default timer values.
Therefore, you can safely assume that this network diameter is 3, provided that no additional switches will be added to lengthen the longest path. Suppose that a Hello Time of 1 second is also desired, to shorten the time needed to detect a dead neighbor. The following command attempts to make the local switch become the Root Bridge and automatically adjusts the STP timers:

Switch(config)# spanning- tree vlan 1 00 root primary diameter 3 hello- time 1 You can confirm the new timer values with the show spanning-tree vlan vlan-id command, as demonstrated in Example 10-7.

Example 10-7 Confirming STP Timer Configuration Changes

Switch# show spanning- tree vlan 1 00
VLAN0100
 Spanning tree enabled protocol ieee
 Root ID Priority 100
 Address 000c.8554.9a80
 This bridge is the root
 Hello Time 1 sec Max Age 7 sec Forward Delay 5 sec
 Bridge ID Priority 100 (priority 0 sys-id-ext 100)
 Address 000c.8554.9a80
 Hello Time 1 sec Max Age 7 sec Forward Delay 5 sec
 Aging Time 300

Redundant Link Convergence

Some additional methods allow faster STP convergence in the event of a link failure:

• PortFast—Enables fast connectivity to be established on access-layer switch ports to workstations that are booting up
• UplinkFast—Enables fast-uplink failover on an access-layer switch when dual uplinks are connected into the distribution layer
• BackboneFast—Enables fast convergence in the network backbone (core) after a spanningtree topology change occurs
  Instead of modifying timer values, these methods work by controlling convergence on specifically located ports within the network hierarchy

PortFast: Access-Layer Nodes

An end-user workstation is usually connected to a switch port in the access layer. If the workstation is powered off and then turned on, the switch will sense that the port link status has gone down and back up. The port will not be in a usable state until STP cycles from the Blocking state to the Forwarding state. With the default STP timers, this transition takes at least 30 seconds (15 seconds for Listening to Learning, and 15 seconds for Learning to Forwarding). Therefore, the workstation cannot transmit or receive any useful data until the Forwarding state finally is reached on the port.

On switch ports that connect only to single workstations or specific devices, bridging loops never should be possible. The potential for a loop exists only if the workstation had additional connections back into the network and if it was bridging traffic itself. For example, this can happen on PCs that are running Windows XP when network bridging has been enabled. In most situations, this is not very likely to happen.

Catalyst switches offer the PortFast feature, which shortens the Listening and Learning states to a negligible amount of time. When a workstation link comes up, the switch immediately moves the PortFast port into the Forwarding state. Spanning-tree loop detection is still in operation, however, and the port moves into the Blocking state if a loop is ever detected on the port.
By default, PortFast is disabled on all switch ports. You can configure PortFast as a global default, affecting all switch ports with a single command. All ports that are configured for access mode (nontrunking) will have PortFast automatically enabled. You can use the following global configuration command to enable PortFast as the default:

Switch(config)# spanning- tree portfast default

You can also enable or disable the PortFast feature on specific switch ports by using the following interface-configuration command:

Switch(config-if)# [ no] spanning- tree portfast

Obviously, you should not enable PortFast on a switch port that is connected to a hub or another switch because bridging loops could form. One other benefit of PortFast is that topology change notification (TCN) BPDUs are not sent when a switch port in PortFast mode goes up or down. This simplifies the TCN transmission on a large network when end-user workstations are coming up or shutting down.

Switch(config)# interface type mod/num
Switch(config-if)# switchport host
switchport mode will be set to access 
spanning-tree portfast will be enabled 
channel group will be disabled

You can display the current PortFast status with the following command:

Switch# show spanning- tree interface type mod/num portfast

For example, the following output shows that port FastEthernet 0/1 supports only access VLAN 10 and has PortFast enabled:

Switch# show spanning- tree interface fastethernet 0/1 portfast
VLAN0010 enabled
Switch#

UplinkFast: Access-Layer Uplinks

Consider an access-layer switch that has redundant uplink connections to two distribution-layer switches. Normally, one uplink would be in the Forwarding state and the other would be in the Blocking state. If the primary uplink went down, up to 50 seconds could elapse before the redundant uplink could be used.
The UplinkFast feature on Catalyst switches enables leaf-node switches or switches at the ends of the spanning-tree branches to have a functioning root port while keeping one or more redundant or potential root ports in Blocking mode. When the primary root port uplink fails, another blocked uplink immediately can be brought up for use.

To enable the UplinkFast feature, use the following global configuration command:

Switch(config)# spanning- tree uplinkfast [ max- update- rate pkts-per-second]

When UplinkFast is enabled, it is enabled for the entire switch and all VLANs. UplinkFast works by keeping track of possible paths to the Root Bridge. Therefore, the command is not allowed on the Root Bridge switch. UplinkFast also makes some modifications to the local switch to ensure that it does not become the Root Bridge and that the switch is not used as a transit switch to get to the Root Bridge. In other words, the goal is to keep UplinkFast limited to leaf-node switches that are farthest from the root.

First, the switch’s bridge priority is raised to 49,152, making it unlikely that the switch will be elected to Root Bridge status. The port cost of all local switch ports is incremented by 3000, making the ports undesirable as paths to the root for any downstream switches.

The command also includes a max-update-rate parameter. When an uplink on a switch goes down, UplinkFast makes it easy for the local switch to update its bridging table of MAC addresses to point to the new uplink. However, UplinkFast also provides a mechanism for the local switch to notify other upstream switches that stations downstream (or within the access layer) can be reached over the newly activated uplink.

The switch accomplishes this by sending dummy multicast frames to destination 0100.0ccd.cdcd on behalf of the stations contained in its Content-Addressable Memory (CAM) table. The MAC addresses are used as the source addresses in the dummy frames, as if the stations actually had sent them. The idea is to quickly send the multicast frames over the new uplink, giving upstream hosts a chance to receive the frames and learn of the new path to those source addresses.

These multicast frames are sent out at a rate specified by the max-update-rate parameter in packets per second. This limits the amount of bandwidth used for the dummy multicasts if the CAM table is quite large. The default is 150 packets per second (pps), but the rate can range from 0 to 65,535 pps. If the value is 0, no dummy multicasts are sent.

Switch# show spanning-tree uplinkfast
 UplinkFast is enabled
 Station update rate set to 150 packets/sec.
 UplinkFast statistics
 -----------------------
 Number of transitions via uplinkFast (all VLANs) : 2
 Number of proxy multicast addresses transmitted (all VLANs) : 52
 Name Interface List
 -------------------- ------------------------------------
 VLAN0001 Gi0/1(fwd)
 VLAN0010 Gi0/1(fwd)
 VLAN0100 Gi0/1(fwd)
 Switch#

BackboneFast: Redundant Backbone Paths

In the network backbone, or core layer, a different method is used to shorten STP convergence. BackboneFast works by having a switch actively determine whether alternate paths exist to the Root Bridge, in case the switch detects an indirect link failure. Indirect link failures occur when a link that is not directly connected to a switch fails.

A switch detects an indirect link failure when it receives inferior BPDUs from its designated bridge on either its root port or a blocked port. (Inferior BPDUs are sent from a designated bridge that has lost its connection to the Root Bridge, making it announce itself as the new root.) Normally, a switch must wait for the Max Age timer to expire before responding to the inferior BPDUs. However, BackboneFast begins to determine whether other alternate paths to the Root Bridge exist according to the following port types that received the inferior BPDU:

• If the inferior BPDU arrives on a port in the Blocking state, the switch considers the root port and all other blocked ports to be alternate paths to the Root Bridge.
• If the inferior BPDU arrives on the root port itself, the switch considers all blocked ports to be alternate paths to the Root Bridge.
• If the inferior BPDU arrives on the root port and no ports are blocked, however, the switch assumes that it has lost connectivity with the Root Bridge. In this case, the switch assumes that it has become the Root Bridge, and BackboneFast allows it to do so before the Max Age timer expires.

Detecting alternate paths to the Root Bridge also involves an interactive process with other bridges. If the local switch has blocked ports, BackboneFast begins to use the Root Link Query (RLQ) protocol to see if upstream switches have stable connections to the Root Bridge.

First, RLQ Requests are sent out. If a switch receives an RLQ Request and either is the Root Bridge or has lost connection to the root, it sends an RLQ Reply. Otherwise, the RLQ Request is propagated on to other switches until an RLQ Reply can be generated. On the local switch, if an RLQ Reply is received on its current root port, the path to the Root Bridge is intact and stable. If it is received on a nonroot port, an alternate root path must be chosen. The Max Age timer immediately is expired so that a new root port can be found.

BackboneFast is simple to configure and operates by short-circuiting the Max Age timer when needed. Although this function shortens the time a switch waits to detect a root path failure, ports still must go through full-length Forward Delay timer intervals during the Listening and Learning states. Where PortFast and UplinkFast enable immediate transitions, BackboneFast can reduce the maximum convergence delay only from 50 to 30 seconds.

To configure BackboneFast, use the following global configuration command:

Switch(config)# spanning- tree backbonefast

When used, BackboneFast should be enabled on all switches in the network because BackboneFast requires the use of the RLQ Request and Reply mechanism to inform switches of root path stability. The RLQ protocol is active only when BackboneFast is enabled on a switch. By default, BackboneFast is disabled.

Switch# show spanning-tree backbonefast
 BackboneFast is enabled
 Switch#

Troubleshooting STP

Because the STP running in a network uses several timers, costs, and dynamic calculations, predicting the current state is difficult. You can use a network diagram and work out the STP topology by hand, but any change on the network could produce an entirely different outcome. Then, figure in something like PVST+, in which you have one instance of STP running for each VLAN present. Obviously, simply viewing the STP status on the active network devices would be better.

You can display information about many aspects of the STP from a Catalyst switch command-line interface (CLI). Specifically, you need to find out the current Root Bridge and its location in the network. You also might want to see the Bridge ID of the switch where you are connected, to see how it participates in STP. Use the information in Table 10-3 to determine what command is useful for what situation.

Table 10-3 Commands for Displaying Spanning Tree Information