CCNP SWITCH – Spanning Tree (STP)

Spanning Tree Protocol (STP) is designed to prevent problems related to bridging loops. STP solves the problem by blocking redundant paths and allowing only a single active path.

Spanning tree works by selecting a root switch then selecting a loop-free path from the root switch to every other switch. To do that, spanning tree must choose a single root bridge, one root port for each nonroot switch, and a single designated port for each network segment.

Several different versions of Spanning Tree have been introduced over the years. Here are a few:

Common Spanning Tree (CST)
IEEE 802.1D, One instance of spanning tree runs for the entire switched network resulting in low CPU requirements, but suboptimal traffic paths when multiple VLANs are used. It is also slow to converge.

Per VLAN Spanning Tree Plus (PVST+)
One instance of STP per VLAN, more resources required, slow convergence still, includes portfast, BPDU guard, BPDU filter, Root Guard, and Loop Guard.

Rapid STP (RSTP)
IEEE 802.1w, One instance of STP, but very fast convergence time. Still suboptimal traffic flows because only a single instance for the entire switched network.

Multiple Spanning Tree (MST)
An IEEE standard that allows you to map multiple VLANS with similar traffic flow requirements into the same spanning-tree instance. MST also supports RSTP for fast convergence. Each instance supports Portfast, BPDU guard, BPDU filter, Root Guard, and Loop Guard.

PVRST+
A Cisco enhancement to RSTP that behaves similar to PVST+. It supports a separate instance of RSTP for each VLAN and each instance supports Portfast, BPDU guard, BPDU filter, Root Guard, and Loop Guard. This option has the largest CPU and memory requirements.

Note: MST and PVRST+ have become the dominate spanning-tree protocols of choice and in Cisco switches, PVST+ is the default flavor of STP that is enabled when a VLAN is created.

STP Path Selection

Spanning tree builds the tree structure attempting to use the fastest links it has available for the active paths. STP uses the following steps to select its paths:

1. Lowest root bridge ID (BID)
2. Lowest path cost to the root
3. Lowest sender bridge ID
4. Lowest sender port ID (PID)

STP Definitions

Bridge ID – bridge priority + MAC Address
Bridge Priority – 0-65,535
Default Priority – 32,768
Port ID – port priority + port number
Port Priority – 0-240 (default is 128, increments of 16)
Path Cost – The cumulative cost of all links between the switch and the root bridge

STP Convergence

1. Root bridge election
Each VLAN elects one root bridge. All ports on the root bridge act as designated ports, which send and receive traffic as well as BPDUs. The bridge with the lowest priority becomes root.
2. Root ports are determined on all non-root bridges
Each non-root bridge is assigned a single root port that sends and receives traffic. The root port is chosen based on the port with the lowest-cost path between the non-root bridge and the root bridge. If two paths are equal cost, the port with the lowest port ID (priority + port number) will win.
3. Designated port selection
Each segment has a single designated port. Designated ports are chosen from non-root ports that have the lowest path cost to the root bridge. In the event of a tie, the bridge ID acts as a tiebreaker (lowest wins). All ports on a root bridge are designated ports.

Spanning Tree Port Roles

STP Path Cost

Spanning-tree uses a link cost calculation to determine the the root ports on non-root switches. It is calculated by adding the costs of all links between the root bridge and the local switch.

• 10 Gbps = Cost 2
• 1 Gbps = Cost 4
• 100 Mbps = Cost 19
• 10 Mbps = Cost 100

Rapid Spanning Tree

Rapid Spanning Tree Protocol (IEEE 802.1w) was introduced to dramatically speed up STP’s convergence when network changes occur. RSTP can revert to 802.1D (common spanning-tree) to inter-operate with legacy bridges on a per-port basis. A rapid version of PVST+, RPVST+ is a per-VLAN implementation of rapid spanning-tree.

RSTP Port States

Note: In every RSTP port state, BPDU frames are accepted and processed.

Switch A(config-if)# interface fa 0/2
Switch A(config-if)# spanning-tree vlan 11-20 port priority 20
Switch A(config-if)# switchport mode trunk

In this example, VLANs 1-10 would traverse the left link (priority of 20 is less than default of 32)and use the right link as a backup only, while VLANs 11-20 would prefer the right uplink and use the left link as a backup only. This way both uplinks are being used, but only one for each VLAN. Make sure you understand how this works because this is a very common implementation design.

PortFast

Spanning Tree Portfast causes layer 2 switch interfaces to enter forwarding state immediately, bypassing the listening and learning states. It should be used on ports connected directly to end hosts like servers or workstations. Note: If portfast isn’t enabled, DHCP timeouts can occur while STP converges, causing more problems.
To configure PortFast:

Switch# conf t
Switch (config)# int fa 3/1
Switch (config-if)# [no] spanning-tree portfast

To verify PortFast on an interface:

Switch# sh spanning-tree int fa 3/1 portfast

PortFast can be configured globally on an access switch for all interfaces to save configuration time. Also, it only applies to access interfaces, not trunks. Use the spanning-tree portfast trunk command if it is required on a trunk. If you do so, make sure to disable it explicitly on uplink interfaces.
To configure PortFast globally:

Switch# spanning-tree portfast default

Switchport Mode Host

To configure PortFast and disable both channeling and trunking negotiation on an interface:

Switch (config-if)# switchport host

RPVST+ Configuration

1. Enable RPVST+ globally on all switches Switch(config)#spanning-tree mode rapid-pvst
2. Designate and configure a primary root bridge Switch(config)#spanning-tree vlan 2 root primary
3. Designate and configure a secondary root bridge Switch(config)#spanning-tree vlan 2 root secondary
4. Verify the configuration Switch#show spanning-tree vlan 2

Multiple Spanning Tree

MST, or 802.1s, expands upon the IEEE 802.1w RST algorithm in an attempt to reduce the number of STP instances, thus reducing the required CPU cycles on a switch. MST enables you to group VLANs and associate them with spanning tree instances. Each instance’s topology can be independent of the rest, allowing VLANs to be grouped and load balanced for fault tolerance measures. MST is also backwards compatible with all older STP variations.

Switches participating in MST that have the same MST configuration information are referred to as a region. Switches with different MST configurations or that are running legacy 802.1D are considered separate MST regions.

Note: Switches in the same MST region must have the exact same MST configuration to work properly (including revision number).

MST is usually not implemented in campus environments because if you follow the local VLAN model (recommended by Cisco), there should not be that many VLANs on any given switch because they should only extend to the switch block boundary. That makes RPVST+ a better choice because of it’s simpler configuration. Because MST is still often deployed, Cisco definitely still considers it an important topic on the SWITCH exam.

Multiple Spanning Tree Regions

Each switch that runs MST in the network has a single MST configuration consisting of the following 3 items:

• Configuration name (alphanumeric)
• Configuration revision number
• A 4096-element table that associates each VLAN to a given instance (The default MST instance is for all VLANs is MST00 )

MST Configuration

MST must be manually configured on each participating switch. Apply the following configurations on each switch that runs MST:
Enable MST globally:

Switch(config)# spanning-tree mode mst

Enter MST Submode:

Switch(config)# spanning-tree mst configuration Switch(config-mst)# sh current

1. Define a configuration name:

Switch(config-mst)# name XYZ

2. Set the MST revision number:

Switch(config-mst)# revision 1

3. Map the VLANs to an MST instance:

Switch(config-mst)# instance 1 vlan 3, 5, 7
Switch(config-mst)# instance 2 vlan 2, 4, 6

Display configuration to be applied:

Switch(config-mst)# show pending 

Note: This step is important because without it, you will be unable to verify the configuration.
Display current running MST configuration:

Switch(config-mst)# show current

Apply the configuration:

Switch(config-mst)# end

Cancel the configuration:

Switch(config-mst)# abort

Assign an MST root bridge:

Switch(config)# spanning-tree mst 2 root primary

Verification Commands

Switch# show spanning-tree mst

Switch# show spanning-tree mst 1 (to view MST info for a single instance)

Switch# show spanning-tree mst 1 detail

Switch# show spanning-tree mst interface fa 0/3

Spanning Tree Enhancements

BPDU Guard

Prevents problems related to switches accidentally being connected to PortFast-enabled ports. Bridging loops would normally instantly occur. It places the port in err-disable state if it receives a BPDU – disabling the interface.
To enable BPDU Guard globally on the switch:

Switch(config)# spanning-tree portfast edge bpduguard default

To enable BPDU Guard at the interface level:

Switch(config)# spanning-tree bpduguard enable

BPDU Filtering

Prevents BPDUs from being transmitted from PortFast-enabled interfaces.
When enabled globally on the switch:

• Configures all PortFast ports for BPDU filtering
• If BPDUs are seen, the port looses its PortFast status, BPDU filtering is disabled, and STP resumes default operation on the port
• When the port comes up, it sends 10 BPDUs, if it hears any BPDUs during that time PortFast and BPDU filtering are disabled

When applied to an individual port:

• It ignores all BPDUs it receives
• It does not transmit BPDUs
• Because it ignores incoming BPDUs, this can lead to bridging loop scenarios

Note: If you enable BPDU Guard and BPDU filtering on the same interface, BPDU Guard has no effect because BPDU filtering has precedence over BPDU Guard.
To enable BPDU filtering globally on the switch:

Switch(config)# spanning-tree portfast bpdufilter default

To enable BPDU filtering at the interface level:

Switch(config)# spanning-tree bpdufilter enable

To verify:

Switch# show spanning-tree summary 

OR

Switch# show spanning-tree interface fa 0/3 detail

Root Guard

Root guard was developed to control where root bridges can be located within the network. Switches learn about and elect root bridges based on BPDUs they receive, so if a new switch is added to the environment with a lower bridge priority than the current root bridge, the new switch will become root – and in turn disrupt your carefully planned traffic patterns. To prevent this from occurring, root guard can be applied to interface where a root bridge should never been seen.
When root guard is applied to an interface, it forces the port to essentially always remain a designated interface, never allowing it to transition to a root port. If a root guard-enabled port received a superior BPDU, it immediately moves the port to a root-inconsistent STP state (essentially the same as the listening state) and does not forward any traffic out that port.
When the root guard protected port stops receiving superior BPDUs, it automatically unblocks the port and proceeds through its normal listening, learning, and eventually forwarding states. No intervention is required.
To enable root guard on an interface:

Switch(config)# int fa 4/4
Switch(config-if)# spanning-tree guard root

Loop Guard

Most bridging loops that occur when STP is active happen when a port in blocking state stops receiving BPDUs on the interface and therefore transition the port to forwarding state – creating an all-ports-forwarding loop. It blocks ports on a per-VLAN basis, so on trunks it will only block that VLAN – not the whole trunk.
Loop guard should be applied to all non-designated ports (ex. root, alternate).
To enable loop guard on an interface:

Switch(config)# int fa 4/4
Switch(config-if)# spanning-tree guard loop

To enable loop guard globally on the switch:

Switch(config)# spanning-tree loopguard default

To verify:

Switch# show spanning-tree interface fa 0/3 detail

UDLD

UDLD is another loop-prevention mechanism for STP. It tries to discover unidirectional links before they grow into bridging loops. This situation is much more common in fiber optic networks where there is a physical Rx/Tx pair and a situation can arrise where one is not functioning correctly.
STP relies on constant and consistant reception of BPDU messages. If a switch stops receiving BPDUs on a designated (upstream) port, STP ages out the information for the port and transitions it into forwarding state. This will lead to a loop.
UDLD sends UDLD protocol packets to its neighbor switch – 15 seconds is the default. The neighbor is then expected to echo packet the packets before a timer expires. If the switch does not hear a reply it waits, before finally shutting down the port.
There are two UDLD modes:
Normal
UDLD simply places the port into an undetermined state if it stops hearing responses from its directly-connected neighbor
Aggressive (Preferred)
Tries to re-establish the connection up to 8 times, then puts the port in err-disable state (essentially shutting down the port)
Note: UDLD is enabled by default on all Ethernet fiber-optic interfaces.
To enable UDLD on an interface:

Switch(config)# int fa 4/4 

Switch(config-if)# udld port {aggressive}

To enable UDLD globally on all fiber ports:

Switch(config)# udld {enable | aggressive}

Note: While both loop guard and aggressive UDLD have many overlapping functions, enabling both provides the best protection.

Flex Links

Flex links is a layer 2 solution that allows you to disable STP at the access layer, while maintaining link redundancy and loop avoidance. Flex links allow a convergence time of less than 50 milliseconds (super fast).
Flex links work by combining a pair of links on a common access switch. One link is active, while the other acts as a backup if the other link fails for any reason. The interfaces can be physical ports or EtherChannel bundles.
Some more details:

• A single backup port is allowed per active port and they must both be on the same switch or stack
• The active and backup links can be dissimilar types and work just fine (ex. fasteth/gig, gig/etherchannel, etc..)
• STP is always disabled on Flex links

The configuration is done exclusively on the “active” interface with the following command:

Switch(config)# int fa 4/4
Switch(config-if)# switchport backup interface fa 5/17

To verify:

Switch# sh int switchport backup

Spanning Tree Best Practices

• Something to consider with spanning tree is the lack of multipathing options. STP eliminates loops by creating a tree structure where a single link is created to each switch. This means that even with all the redundant links you put in place, STP will always only allow one – reducing much of your available bandwidth.Because of this and other limitations, it is recommended to use layer 3 at both the distribution and core layers. Using layer 3 between the distribution and core allows you to use multipathing (up to 16 paths) using Equal-Cost Multipathing (ECMP) without the dependency of STP. Also, be aware that the new Nexus 7ks allow layer 2 multipathing with two links using virtual port channels.
• Because a 50 second network convergence delay is usually not acceptable in modern networks, RSTP is preferred.
• STP should absolutely be used on the network edge to prevent user/wiring errors from propagating throughout the network.
• A root bridge should be manually assigned in every STP topology.
• If using PVST+ or RPVST+, assign a root bridge for each VLAN using the command: #spanning-tree vlan ID root.
• If using HSRP, make sure the STP root bridge and HSRP active router are assigned to the same device if possible.
• Use the STP Enhancements (sometimes referred to as the STP toolkit) to optimize the topology
• Loop guard – Implement on layer 2 uplink ports between access and distribution layer
• Root guard – Implement on distribution switch ports facing the access ports
• UplinkFast- Implement on uplink ports from access to distribution switches
• BPDU guard or root guard- Implement on access ports connected to end devices, as is PortFast
• UDLD -Sometimes implemented on fiber ports between switches

Troubleshooting Spanning Tree

Duplex Mismatch
If one side of a link is set to half duplex and the other is set to full, then the potential exists that the full duplex side will begin sending lots of traffic to the half duplex interface. If that happens, the half duplex interface will experience collisions when it attempts to transmit STP BPDUs. The full duplex interface will therefore never receive them, and assume other interfaces on the switch in blocking state can transfer to a forwarding state – creating a loop.
Unidirectional link failure
This occurs when a hardware failure causes a normally two-way link to become a one-way link. The potential loop problem is the same as with the duplex mismatch issue, with one side moving from blocking to forwarding because they stop receiving superior BPDUs on the interface.
Aggressive UDLD can prevent loops from forming when this occurs by putting the offending port into err-disable state. Cisco recommends using agressive UDLD on all point-point links in a switched environment.
Frame Corruption
This is a very uncommon cause of STP loops, but it exists when errors on an interface do not allow BPDU frames from being received. Again, a port moves from blocking to forwarding because they stop receiving superior BPDUs on the interface. This could be caused by a duplex mismatch, bad cable, or incorrect cable length.
Resource Errors
If for any reason the CPU of a switch is over-utilized, there exists the possibility that it will be unable to send out BPDUs. STP is generally not very resource intensive, but be careful when running PVST+.
PortFast-related Errors
PortFast interfaces move directly into forwarding state, so if a hub or switch gets connected to an edge port configured with PortFast, a loop will form. BPDU Guard can prevent this condition.

General STP Troubleshooting Methodology

1. Develop a plan
2. Isolate the cause and correct an STP problem
3. Document findings

Develop a plan
In order to make a plan, you must know the following parts of the network:

• The switched topology
• The location of the root bridge
• The location of blocking ports

Correct the problem
The best way to determine a loop is to capture packets on a saturated link and look for duplicate packets. Another option is to look for abnormally high interface utilization values. Some common symptoms include HSRP may complain of duplicate IP addresses, consistent flapping of MAC values because MAC addresses should not flap.
Restore connectivity
Most of the time administrators do not have the luxury of time to identify the root cause of a loop, instead they must stop it as quickly as possible. Here are some options:

• Disable every port that is providing redundancy, starting with areas of the network more affected. Try to disable ports you know should be in blocking state if possible.
• If it is difficult to pin down, increase the level of STP logging on the switches. The loops form when a port moves into forwarding state, so it can latter be identified.

Try this:

Switch# debug spanning-tree events

To log the events:

Switch(config)# logging buffered

Check Port Statuses
Start with blocking ports first – here are some more guidelines:

• Make sure both root and blocking ports are receiving BPDUs (enter multiple times to see if the number is increasing)

  Switch# sh spanning-tree vlan ID detail

• Look for duplex mismatch errors using the

  show interface 

  command

• Check port utilization with the

  show interface

  command. Look at the load, input/output values for abnormally high rates.

• Look for an increase of input error fields using the

  show interface

  command.

• Check for resource errors

Resource Errors
Use the show process cpu command to check whether the CPU utilization is nearing 100%.
Disable Unnecessary Features
Sometimes it becomes easier to identify a solution when the network is simplified. Try disabling unnecessary features to reduce complexity. Save the configuration before making the changes so it can be restored after the issue is resolved.
Document Findings
It is important to document both your findings and any changes to the network after the dust clears. Current and detailed documentation also reduces troubleshooting time in the future.