Multiple Spanning Tree
Multiple Spanning Tree (MST) extends the IEEE 802.1w RST algorithm to multiple spanning trees. The main purpose of MST is to reduce the total number of spanning-tree instances to match the physical topology of the network and thus reduce the CPU cycles of a switch. PVRST+ runs STP instances for each VLAN and does not take into consideration the physical topology that might not require many different STP topologies. MST, on the other hand, uses a minimum number of STP instances to match the number of physical topologies present.
Figure 3-15 shows a common network design, featuring an access Switch A, connected to two Building Distribution submodule Switches D1 and D2. In this setup, there are 1000 VLANs, and the network administrator typically seeks to achieve load balancing on the access switch uplinks based on even or odd VLANs—or any other scheme deemed appropriate.
Figure 3-15 illustrates two links and 1000 VLANs. The 1000 VLANs map to two MST instances. Rather than maintaining 1000 spanning trees, each switch needs to maintain only two spanning trees, reducing the need for switch resources. This concept of two MST instances for the topology, as shown in Figure 3-15, extends to 4096 VLANs. MST converges faster than PVRST+ and is backward compatible with 802.1D STP, 802.1w (RSTP), and the Cisco PVSTP+ architecture.
MST allows for the building of multiple spanning trees over trunks by grouping and associating VLANs to spanning-tree instances. Each instance may have a topology that is independent of other spanning-tree instances. This architecture provides multiple forwarding paths for data traffic and enables load balancing. A failure in one forwarding path does not affect other instances with different forwarding paths; hence, this architecture improves network fault tolerance.
In large networks, using different VLANs and a different spanning-tree topology enables better administration of the network and use of the redundant paths available. An MST spanning-tree instance might exist only on bridges that have compatible VLAN instance assignments. Configuring a set of bridges with the same MST configuration information allows them to participate in a specific set of spanning-tree instances. The term MST region refers to the set of interconnected bridges that have the same MST configuration.
Implementation of MST is not required if the Enterprise Campus Model is being employed because the number of active VLAN instances, and hence the STP instances, would be small and stable due to the design.
In the scenario described in Figure 3-15, only two different final logical topologies exist and therefore require only two spanning-tree instances. There is no need to run 1000 instances if, as shown in Figure 3-15, half of the 1000 VLANs map to a different spanning-tree instance.
In a network running MST, as depicted in Figure 3-16, the following is true:
From a technical standpoint, MST is the best solution for the scenario presented in Figure 3-16. Because MST is a newer protocol, however, the following issues could arise:
MST enables you to build multiple spanning trees over trunks by grouping VLANs and associating them with spanning-tree instances. Each instance can have a topology independent of other spanning-tree instances. This architecture provides multiple active forwarding paths for data traffic and enables load balancing.
Network fault tolerance is improved over Common Spanning Tree (CST) because a failure in one instance (forwarding path) does not necessarily affect other instances. This VLAN-to-MST grouping must be consistent across all bridges within an MST region.
In large networks, you can more easily administer the network and use redundant paths by locating different VLAN and spanning-tree assignments in different parts of the network. A spanning-tree instance can exist only on bridges that have compatible VLAN instance assignments.
You must configure a set of bridges with the same MST configuration information, which allows them to participate in a specific set of spanning-tree instances. Interconnected bridges that have the same MST configuration are referred to as an MST region. Bridges with different MST configurations or legacy bridges running 802.1D are considered separate MST regions.
MST Regions
The main enhancement introduced by MST is the ability to map several VLANs to a single spanning-tree instance. This raises the problem, however, of determining what VLAN is to be associated with what instance. More precisely, based on received BPDUs, devices need to identify these instances and the VLANs that are mapped to the instances.
In the case of the 802.1Q standard, all instances map to a unique and common instance and are therefore less complex. In the case of PVST+, each VLAN carries the BPDUs for its respective instance (one BPDU per VLAN).
Each switch that runs MST in the network has a single MST configuration that consists of three attributes:
-
An alphanumeric configuration name (32 bytes)
-
A configuration revision number (2 bytes)
-
A 4096-element table that associates each of the potential 4096 VLANs supported on the chassis to a given instance
To be part of a common MST region, a group of switches must share the same configuration attributes. It is up to the network administrator to properly propagate the configuration throughout the region.
To ensure a consistent VLANs-to-instance mapping, the protocol must exactly identify the boundaries of the regions. For that purpose, the characteristics of the region are included in BPDUs. Switches do not propagate the exact VLANs-to-instance mapping in the BPDU because the switches need to know only whether they are in the same region as a neighbor. Therefore, switches only send a digest of the VLANs-to-instance mapping table, along with the revision number and the name. When a switch receives a BPDU, it extracts the message digest, a numerical value derived from the VLANs-to-instance mapping table through a mathematical function, and compares it with its own computed digest. If the digests differ, the port receiving the BPDU is at the boundary of a region.
In generic terms, a port is at the boundary of a region if the designated bridge on its segment is in a different region or if it receives legacy 802.1D BPDUs. In Figure 3-17, the port on B1 is at the boundary of Region A, whereas the ports on B2 and B3 are internal to Region B.
Extended System ID for MST
As with PVRST+, the 12-bit Extended System ID field is used in MST, as shown in Figure 3-18. In MST, this field carries the MST instance number.
Configuring MST
Enabling MST is a multistep process that involves mapping ranges of VLANs to a single MSTI.
Because MST is applicable to multiple VLANs, it requires some additional configuration beyond that needed for PVRST+. After you enable MST with the command spanning-tree mode mst, you must configure regions and instances with additional configuration commands.
Consider Figure 3-19 with three switches with six VLANs that need to be implemented. Spanning tree must be configured across these three switches. The Switches A and B are distribution switches. Either of them would be a possible candidate to perform the root bridge role.
A possible solution is to use MST with two instances, each instance grouping half the needed VLANs. Switch A would be the root for the first instance with odd VLANs assigned to it, Switch B would be the root for the second instance with even VLANs assigned to it.
Table 3-8 shows the various steps involved in configuring MST in a network, and Example 3-4 shows a user configuring Switches A and B to reflect the final configuration, as shown in Figure 3-20. Switch A is configured root for instance 1 and Switch B is configured root for instance 2, but the rest of the configuration, including name and VLAN grouping to instances, are identical.
Table 3-8: Steps to Configure MST in IOS-Based Cisco Catalyst Switches
Open table as spreadsheet | Step | Description | Notes and Comments |
| 1. | Enters MST configuration submode. | You can use the no keyword to clear the MST configuration. |
| 2. | Displays the current MST configuration. | This command can be used in configuration mode to display the current configuration before making changes. |
| 3. | Switch(config-mst)# name name | |
| 4. | Sets the MST configuration revision number. | The revision number can be any unassigned 16-bit integer. It is not incremented automatically when you commit a new MST configuration. |
| 5. | Maps the VLANs to an MST instance. | If you do not specify the vlan keyword, you can use the no keyword to unmap all the VLANs that were mapped to an MST instance. If you specify the vlan keyword, you can use the no keyword to unmap a specified VLAN from an MST instance. |
| 6. | Switch(config-mst)# show pending | Displays the new MST configuration to be applied. |
| 7. | Switch(config-mst)# end | Applies the configuration and exit MST configuration submode. |
| 8. | | Assigns root bridge for MST instance. This syntax makes the switch root primary or secondary (only active if primary fails). It sets primary priority to 24576 and secondary to 28672. |
| 9. | | This enables MAC address reduction, also known as extended system ID in Cisco IOS Software. |
| 10. | | This command is required if the neighboring switch is using a prestandard version of MST. |
Example 3-4: Configuring MST for Topology Shown in Figure 3-20
SwitchA(config)# spanning-tree mode mst
SwitchA(config)# spanning-tree mst configuration
SwitchA(config-mst)# name XYZ
SwitchA(config-mst)# revision 1
SwitchA(config-mst)# instance 1 vlan 11, 21, 31
SwitchA(config-mst)# instance 2 vlan 12, 22,32
SwitchA(config)# spanning-tree mst 1 root primary
SwitchB(config)# spanning-tree mode mst
SwitchB(config)# spanning-tree mst configuration
SwitchB(config-mst)# name XYZ
SwitchB(config-mst)# revision 1
SwitchB(config-mst)# instance 1 vlan 11, 21, 31
SwitchB(config-mst)# instance 2 vlan 12, 22,32
SwitchB(config)# spanning-tree mst 2 root primary
Example 3-5 illustrates a user changing the spanning-tree mode to MST and configuring the MST region by mapping the range of VLANs to Instance 1.
Example 3-5: Sample Output of Configuring MST and Mapping VLANs to Instances on Cisco IOS–Based Catalyst Switches
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# spanning-tree mode mst
Switch(config)# spanning-tree mst configuration
Switch(config-mst)# show current
Current MST configuration
Name []
Revision 0
Instance Vlans mapped
-------- -----------------------------------------------------------
0 1-4094
---------------------------------------------------------------------
Switch(config-mst)# name cisco
Switch(config-mst)# revision 1
Switch(config-mst)# instance 1 vlan 1-10
Switch(config-mst)# show pending
Pending MST configuration
Name [cisco]
Revision 1
Instance Vlans mapped
-------- -----------------------------------------------------------
0 11-4094
1 1-10
Switch(config-mst)# end
The show current command in Example 3-5 displays the current MST configuration on the switch. The show pending command details the uncommitted MST configuration. Catalyst switches discard the pending configuration if the administrator aborts the configuration changes by using the abort command. In addition, Catalyst switches save the MST configuration when issuing the end command, as shown in Example 3-5.
Example 3-6 illustrates a user displaying MST protocol information for MSTIs configured on the switch.
Example 3-6: Displaying MST Protocol Information on Cisco IOS–Based Catalyst Switches
Switch# show spanning-tree mst
###### MST00 vlans mapped: 5-4094
Bridge address 0009.e845.6480 priority 32768 (32768 sysid 0)
Root this switch for CST and IST
Configured hello time 2, forward delay 15, max age 20, max hops 20
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa3/24 Desg FWD 2000000 128.152 Shr
Fa3/32 Desg FWD 200000 128.160 P2p
Fa3/42 Back BLK 200000 128.170 P2p
###### MST01 vlans mapped: 1-2
Bridge address 0009.e845.6480 priority 32769 (32768 sysid 1)
Root this switch for MST01
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa3/24 Desg FWD 2000000 128.152 Shr
Fa3/32 Desg FWD 200000 128.160 P2p
Fa3/42 Back BLK 200000 128.170 P2p
###### MST02 vlans mapped: 3-4
Bridge address 0009.e845.6480 priority 32770 (32768 sysid 2)
Root this switch for MST02
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa3/24 Desg FWD 2000000 128.152 Shr
Example 3-7 illustrates a user displaying MST protocol information for a specific MSTI.
Example 3-7: Displaying MST Protocol Instance Information
Switch# show spanning-tree mst 1
###### MST01 vlans mapped: 1-2
Bridge address 0009.e845.6480 priority 32769 (32768 sysid 1)
Root this switch for MST01
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Fa3/24 Desg FWD 2000000 128.152 Shr
Fa3/32 Desg FWD 200000 128.160 P2p
Fa3/42 Back BLK 200000 128.170 P2p
Example 3-8 illustrates a user displaying MST protocol information for a specific interface.
Example 3-8: Displaying MST Protocol Information for a Specific Interface
Switch# show spanning-tree mst interface FastEthernet 3/24
FastEthernet3/24 of MST00 is designated forwarding
Edge port: no (default) port guard : none (default)
Link type: shared (auto) bpdu filter: disable (default)
Boundary : internal bpdu guard : disable (default)
Bpdus sent 81, received 81
Instance Role Sts Cost Prio.Nbr Vlans mapped
-------- ---- --- --------- -------- -------------------------------
0 Desg FWD 2000000 128.152 5-4094
1 Desg FWD 2000000 128.152 1-2
2 Desg FWD 2000000 128.152 3-4
Example 3-9 illustrates a user displaying detailed information for a specific instance.
Example 3-9: Displaying MST Protocol Details
Switch# show spanning-tree mst 1 detail
###### MST01 vlans mapped: 1-2
Bridge address 0009.e845.6480 priority 32769 (32768 sysid 1)
Root this switch for MST01
FastEthernet3/24 of MST01 is designated forwarding
Port info port id 128.152 priority 128 cost 2000000
Designated root address 0009.e845.6480 priority 32769 cost 0
Designated bridge address 0009.e845.6480 priority 32769 port id 128.152
Timers: message expires in 0 sec, forward delay 0, forward transitions 1
Bpdus (MRecords) sent755, received 0
FastEthernet3/32 of MST01 is designated forwarding
Port info port id 128.160 priority 128 cost 200000
Designated root address 0009.e845.6480 priority 32769 cost 0
Designated bridge address 0009.e845.6480 priority 32769 port id 128.160
Timers: message expires in 0 sec, forward delay 0, forward transitions 1
Bpdus (MRecords) sent 769, received 1
FastEthernet3/42 of MST01 is backup blocking
Port info port id 128.170 priority 128 cost 200000
Designated root address 0009.e845.6480 priority 32769 cost 0
Designated bridge address 0009.e845.6480 priority 32769 port id 128.160
Timers: message expires in 5 sec, forward delay 0, forward transitions 0
Bpdus (MRecords) sent 1, received 769
Spanning Tree Enhancements
STP is a mature protocol, benefiting from years of development and production deployment; however, STP makes assumptions about the quality of the network and it can fail. Those failures are generally high profile failures because of the extent to which they impact the network. STP is designed to never open, even temporarily, a loop during its operation. However, like any protocol, it is based on some assumptions that might not be valid in the network. To help STP converge faster and for the protocol behavior to match your network infrastructure, several features are available to filter the way Bridge Protocol Data Units (BPDU) are sent or received, and to alter the way the network should react if an unexpected network topology change occurs.
| Note | Unless otherwise explicitly stated, STP in this section refers to all versions of STP such as 802.1D, PVST+, PVRST+ and MST. |
For example, 802.1D does not prevent unwanted devices from becoming the root bridge of the spanning tree, and no mechanism exists to selectively discard BPDUs from certain ports. The Cisco STP toolkit provides tools to better manage STP. Features such as Root Guard and BPDU Guard solve the problem of unauthorized or inappropriate devices causing network topology changes.
In addition, network device failures can cause bridging loops or black holes in the network. The Cisco Unidirectional Link Detection (UDLD) and Loop Guard features prevent network device failures that are due to faulty hardware or software errors.
Problems such as link duplex mismatch, unidirectional link failure, frame corruption, resource errors, and misconfigurations can disrupt the spanning tree, which in turn disrupts network traffic. As a result, understanding how to troubleshoot spanning-tree problems is critical in maintaining high network availability. The following best practices for spanning tree prevent problems and aid in quick network recovery if unforeseen anomalous events occur.
This remaining section of this chapter introduces the STP enhancements with sample configurations. This section also discusses how to tune STP for higher availability and resiliency.
STP does not provide for checks and balances to ensure high availability in multilayer switched networks. As a result, Cisco introduced features such as the following to help fine-tune and increase resiliency of STP:
-
BPDU Guard: Prevents accidental connection of switching devices to PortFast-enabled ports, as shown in Figure 3-21. Connecting switches to PortFast-enabled ports can cause Layer 2 loops or topology changes.
Figure 3-21: Enabling BPDU Guard/Filter at Access Ports
-
BPDU filtering: Restricts the switch from sending unnecessary BPDUs out access ports.
-
Root Guard: Prevents switches connected on ports configured as access ports from becoming the root switch.
BPDU Guard
BPDU Guard puts an interface configured for STP PortFast in the err-disable state upon receipt of a BPDU, as shown in Example 3-10. The BPDU Guard disables interfaces as a preventive step to avoid a potential bridging loop.
Example 3-10: BPDU Guard Log Messages on a Catalyst Switch
2009 May 12 15:13:32 %SPANTREE-2-RX_PORTFAST:Received BPDU on PortFast enable port.
Disabling 2/1
2009 May 12 15:13:32 %PAGP-5-PORTFROMSTP:Port 2/1 left bridge port 2/1
The STP BPDU Guard shuts down PortFast-configured interfaces that receive BPDUs, rather than putting them into the STP blocking state (the default behavior). In a valid configuration, PortFast-configured interfaces should not receive BPDUs. Reception of a BPDU by a PortFast-configured interface signals an invalid configuration, such as connection of an unauthorized device. BPDU Guard provides a secure response to invalid configurations, because the administrator must manually reenable the err-disabled interface after fixing the invalid configuration. It is also possible to set up a time-out interval after which the switch automatically tries to reenable the interface. However, if the invalid configuration still exists, the switch err-disables the interface again.
To enable BPDU Guard or to disable BPDU Guard on a Cisco IOS–based Catalyst switch, use the following global configuration command:
Example 3-11 illustrates a user configuring and verifying the spanning-tree PortFast BPDU Guard feature.
At the interface level, you can enable BPDU guard on any port by using the spanning-tree bpduguard enable interface configuration command without also enabling the PortFast feature. When the port receives a BPDU, it is put in the error-disabled state.
Example 3-11: Configuring and Verifying BPDU Guard on Cisco IOS–Based Catalyst Switches
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# spanning-tree portfast edge bpduguard default
Switch(config)# end
Switch# show spanning-tree summary totals
Root bridge for: none.
PortFast BPDU Guard is enabled
Etherchannel misconfiguration guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Default pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active
-------------------- -------- --------- -------- ---------- ---------
34 VLANs 0 0 0 36 36
BPDU Filtering
BPDU filtering supports the ability to prevent Catalyst switches from sending BPDUs on PortFast-enabled interfaces. Ports configured for the PortFast feature typically connect to host devices. Hosts do not participate in STP and hence drop the received BPDUs. As a result, BPDU filtering prevents unnecessary BPDUs from being transmitted to host devices.
When enabled globally, BPDU filtering has these attributes:
-
It affects all operational PortFast ports on switches that do not have BPDU filtering configured on the individual ports.
-
If BPDUs are seen, the port loses its PortFast status, BPDU filtering is disabled, and the STP sends and receives BPDUs on the port as it would with any other STP port on the switch.
-
Upon startup, the port transmits ten BPDUs. If this port receives any BPDUs during that time, PortFast and PortFast BPDU filtering are disabled.
When enabled on an individual port, BPDU filtering has these attributes:
Table 3-9 lists all the possible PortFast BPDU filtering combinations.
Table 3-9: PortFast BPDU Filtering Port Configurations
Open table as spreadsheet | Per-Port Configuration | Global Configuration | PortFast State | PortFast BPDU Filtering State |
| Default | Enable | Enable | Enable |
| Default | Enable | Disable | Disable |
| Default | Disable | Not applicable | Disable |
| Disable | Not applicable | Not applicable | Disable |
| Enable | Not applicable | Not applicable | Enable |
If you enable BPDU Guard on the same interface as BPDU filtering, BPDU Guard has no effect because BPDU filtering takes precedence over BPDU Guard.
To enable PortFast BPDU filtering globally on the switch, use the following command on Cisco IOS–based Catalyst switches:
To enable PortFast BPDU filtering on a specific switch port, enter this command:
To verify the configuration, use the following command on Cisco IOS–based Catalyst switches:
Example 3-12 illustrates verification of spanning-tree configuration on the switch.
Example 3-12: Verifying Portfast BPDU Filter Status on a Cisco Catalyst Switch
PxD1# show spanning-tree summary
Switch is in pvst mode
Root bridge for: none
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
EtherChannel misconfig guard is enabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short
Name Blocking Listening Learning Forwarding STP Active
-------------- ---- -------- ------- -------- ---------- ---------
VLAN0001 2 0 0 6 8
----------------- -- -------- ------- -------- ---------- ---------
1 vlan 2 0 0 6 8
Example 3-13 illustrates how to verify the PortFast BPDU filtering status on a specific switch port.
Example 3-13: Verifying PortFast BPDU Filtering on a Specific Switch Port
Switch# show spanning-tree interface fastEthernet 4/4 detail
Port 196 (FastEthernet4/4) of VLAN0010 is forwarding
Port path cost 1000, Port priority 160, Port Identifier 160.196.
Designated root has priority 32768, address 00d0.00b8.140a
Designated bridge has priority 32768, address 00d0.00b8.140a
Designated port id is 160.196, designated path cost 0
Timers:message age 0, forward delay 0, hold 0
Number of transitions to forwarding state:1
The port is in the portfast mode by portfast trunk configuration
Link type is point-to-point by default
Bpdu filter is enabled
BPDU:sent 0, received 0
Root Guard
Root Guard is useful in avoiding Layer 2 loops during network anomalies. The Root Guard feature forces an interface to become a designated port to prevent surrounding switches from becoming a root switch. In other words, Root Guard provides a way to enforce the root bridge placement in the network. Catalyst switches force Root Guard–enabled ports to be designated ports. If the bridge receives superior STP BPDUs on a Root Guard–enabled port, the port moves to a root-inconsistent STP state (effectively equal to a listening state), and the switch does not forward traffic out of that port. As a result, this feature effectively enforces the position of the root bridge.
Figure 3-22 shows a sample topology to illustrate the Root Guard feature. Switches A and B comprise the core of the network, and Switch A is the root bridge for a VLAN. Switch C is an access layer switch. The link between Switch B and Switch C is blocking on the Switch C side. Figure 3-22 shows the flow of STP BPDUs with arrows.
In Figure 3-22, when Switch D is connected to Switch C, it begins to participate in STP. If the priority of Switch D is 0 or any value lower than that of the current root bridge, Switch D becomes the root bridge for that VLAN based on normal STP guidelines. In this specific scenario, however, having Switch D as the root causes the Gigabit Ethernet link that is connecting the two core switches to block, thus causing all the data in that particular VLAN to flow via a 100-Mbps link across the access layer. If there is more data flowing between the core switches in that VLAN than this link may accommodate, packet loss can occur, causing performance issues or network connectivity problems. An even worse scenario might occur if Switch D is unstable and causes frequent reconvergence of the root bridge.
The Root Guard feature can protect against such issues. After the Root Guard feature is enabled on a port, the switch does not enable that port to become an STP root port. The port remains as an STP-designated port. In addition, if a better BPDU is received on the port, Root Guard disables (err-disables) the port rather than processing the BPDU. If an unauthorized device starts sending BPDUs with a better bridge ID, the normal STP process would elect the new switch as the root switch. By disabling the port, the network topology is protected.
The current design recommendation is to enable Root Guard on all access ports so that a root bridge is not established through these ports. In Figure 3-22, enable Root Guard on Switches A, B, and C on the following ports:
-
Switch A (Distribution/Core): Any access port
-
Switch B (Distribution/Core): Any access port
-
Switch C (Access): Any access port including the port connecting to Switch D
In this configuration, Switch C blocks the port connecting to Switch D when it receives a better (superior) BPDU. The port transitions to a special STP state (root-inconsistent), which is effectively the same as the listening state. No traffic passes through the port in root-inconsistent state.
When Switch D stops sending superior BPDUs, the port unblocks again and goes through regular STP transition of listening and learning, and eventually to the forwarding state. Recovery is automatic; no intervention is required.
In addition, Catalyst switches log the following message when a Root Guard–enabled port receives a superior BPDU:
To enable Root Guard on a Layer 2 access port to force it to become a designated port, or to disable Root Guard, use the following interface-level command on Cisco IOS–based Catalyst switches:
Example 3-14 illustrates a user enabling the Root Guard feature on FastEthernet interface 5/8 and verifying the configuration.
Example 3-14: Configuring and Verifying Root Guard on Cisco IOS–Based Catalyst Switches
Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# interface FastEthernet 5/8
Switch(config-if)# spanning-tree guard root
Switch(config-if)# end
Switch# show running-config interface FastEthernet 5/8
Building configuration...
Current configuration: 67 bytes
!
interface FastEthernet5/8
switchport mode access
spanning-tree guard root
end
!
Example 3-15 shows how to determine whether any interfaces are in root-inconsistent state.
Example 3-15: Displaying Root-Inconsistent Interfaces on Cisco IOS–Based Catalyst Switches
Switch# show spanning-tree inconsistentports
Name Interface Inconsistency
-------------------- ---------------------- ------------------
VLAN0001 FastEthernet3/1 Port Type Inconsistent
VLAN0001 FastEthernet3/2 Port Type Inconsistent
VLAN1002 FastEthernet3/1 Port Type Inconsistent
VLAN1002 FastEthernet3/2 Port Type Inconsistent
Number of inconsistent ports (segments) in the system :4
| Note | Ports in root inconsistent recover automatically with no human intervention after the port stop receiving superior BPDUs. The port goes through the listening state to the learning state, and eventually transitions to the forwarding state. |
Preventing Forwarding Loops and Black Holes
Prevention of forwarding loops and black holes in a network is a required aspect of network design. Black holes in the network are created when a device that receives frames has no forwarding information for that packet and thus essentially drops all such packets. Cisco Catalyst switches support two important features to address such conditions:
Loop Guard
Loop Guard provides additional protection against Layer 2 forwarding loops (STP loops). A bridging loop happens when an STP blocking port in a redundant topology erroneously transitions to the forwarding state. This usually occurs because one of the ports of a physically redundant topology (not necessarily the STP blocking port) has stopped receiving STP BPDUs. In STP, switches rely on continuous reception or transmission of BPDUs, depending on the port role. (A designated port transmits BPDUs, whereas a nondesignated port receives BPDUs.)
When one of the ports in a physically redundant topology stops receiving BPDUs, STP considers the topology loop-free. Eventually, the blocking port from the alternative or backup port transitions to a designated port and then moves to the STP forwarding state, creating a bridging loop.
With the Loop Guard feature, switches do an additional check before transitioning to the STP forwarding state. If switches stop receiving BPDUs on a nondesignated port with the Loop Guard feature enabled, the switch places the port into the STP loop-inconsistent blocking state instead of moving through the listening, learning, and forwarding states.
When the Loop Guard feature places a port into the loop-inconsistent blocking state, the switch logs the following message:
If a switch receives a BPDU on a port in the loop-inconsistent STP state, the port transitions through STP states according to the received BPDU. As a result, recovery is automatic, and no manual intervention is necessary. After the recovery, the switch logs the following message:
To illustrate Loop Guard behavior, consider the example in Figure 3-23. Switch A is the root switch. Due to unidirectional link failure on the link between Switch B and Switch C, Switch C is not receiving BPDUs from Switch B.
Without Loop Guard, the STP blocking port on Switch C transitions to the STP listening state after the max age timer expires, and ultimately to the forwarding state after two times the forward delay time. When the port moves into the forwarding state, a bridging loop occurs, as shown in Figure 3-24.
With the Loop Guard feature enabled, the blocking port on Switch C transitions into the STP loop-inconsistent state when the max age timer expires, as shown in Figure 3-25. A port in the STP loop-inconsistent state does not pass data traffic; hence, a bridging loop does not occur. The loop-inconsistent state is effectively equal to the blocking state.
You configure the Loop Guard feature on a per-port basis, although the feature blocks inconsistent ports on a per-VLAN basis. For example, on a trunk port, if BPDUs are not received for only one particular VLAN, the switch blocks only that VLAN (that is, moves the port for that VLAN to the loop-inconsistent STP state). In the case of an Ether
Channel interface, the channel status goes into the inconsistent state for all the ports belonging to the channel group for the particular VLAN not receiving BPDUs. (Recall that Catalyst switches consider EtherChannel as one logical port from the STP point of view.)
Enable the Loop Guard feature on all nondesignated ports, and not just for blocking ports. More precisely, Loop Guard should be enabled on root and alternative ports for all possible combinations of active topologies. Before enabling Loop Guard, however, consider all possible failover scenarios. Figure 3-26 shows a sample scenario and indicates the ports configured for Loop Guard.
Loop Guard is disabled by default on Catalyst switches. Use the following interface-level configuration command to enable Loop Guard on Cisco IOS–based Catalyst switches:
When you enable Loop Guard globally for application to all ports, the switch enables Loop Guard only on ports considered to be point-to-point links. Catalyst switches consider full-duplex ports as point-to-point links. It is still possible to configure, or override, the global configuration of Loop Guard on a per-port basis.
To enable Loop Guard globally on Cisco IOS–based Catalyst switches, use the following global configuration command:
To disable Loop Guard on any specific interface on Cisco IOS–based Catalyst switches, issue the following interface configuration command:
Disabling loop guard moves all loop-inconsistent ports to the listening state.
To verify the Loop Guard status on an interface, issue the following EXEC command on Cisco IOS–based Catalyst switches:
Example 3-16 illustrates a user verifying the status of Loop Guard on interface FastEthernet 3/42.
Example 3-16: Verifying the Status of Loop Guard on an Interface on Cisco IOS–Based Catalyst Switches
Switch# show spanning-tree interface FastEthernet 3/42 detail
Port 170 (FastEthernet3/42) of VLAN0001 is blocking
Port path cost 19, Port priority 128, Port Identifier 128.170.
Designated root has priority 8193, address 0009.e845.6480
Designated bridge has priority 8193, address 0009.e845.6480
Designated port id is 128.160, designated path cost 0
Timers: message age 1, forward delay 0, hold 0
Number of transitions to forwarding state: 0
Link type is point-to-point by default
Loop guard is enabled on the port
BPDU: sent 1, received 4501
UDLD
A unidirectional link occurs when traffic is transmitted between neighbors in one direction only. Unidirectional links can cause spanning-tree topology loops. Uni-Directional Link Detection (UDLD) enables devices to detect when a unidirectional link exists and also to shut down the affected interface. UDLD is useful on a fiber ports to prevent network issues resulting in miswiring at the patch panel causing the link to be in up/up status but the BPDUs are lost.
UDLD is a Layer 2 protocol that works with Layer 1 mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of the physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot, such as detecting the identities of neighbors and shutting down misconnected ports. When enabling both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.
With UDLD enabled, the switch periodically sends UDLD protocol packets to its neighbor and expects the packets to be echoed back before a predetermined timer expires. If the timer expires, the switch determines the link to be unidirectional and shuts down the port. The default interval for UDLD message is 15 seconds, which is configurable for faster detection.
UDLD is a Layer 2 protocol enabled between adjacent switches. It uses MAC 01-00-0c-cc-cc-cc with Subnetwork Access Protocol (SNAP) High-Level Data Link Control (HDLC) protocol type 0x0111. UDLD packets contain information about sending the port’s device ID and port ID and the neighbor’s device ID and port ID. Neighbor devices with UDLD enabled send the same hello message. The link is bidirectional if devices on both sides receive each other’s UDLD packets.
In Normal mode, UDLD simply changes the UDLD-enabled port to an undetermined state if it stops receiving UDLD messages from its directly connected neighbor. Aggressive mode UDLD is a variation of UDLD, and when a port stops receiving UDLD packets, UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port state changes to the err-disable state, which effectively disables the port.
Aggressive mode is the preferred method of configuring UDLD. By preventing this one-way communication, UDLD can be useful in spanning-tree networks. UDLD is used when a link should be shut down because of a hardware failure that is causing unidirectional communication. In an EtherChannel bundle, UDLD shuts down only the physical link that has failed.
To reenable the port after correcting the problem, use the following interface-level commands in Cisco Catalyst switches:
STP prevents loops in the network by detecting loops and blocking the redundant ports. This loop detection is based on BPDUs received on switch ports. If a switch receives the same root BPDU from more than one port, it chooses the best port to the root bridge and blocks the other, redundant ports. Because receiving BPDUs is a critical part of the loop-prevention process, it is important to detect unidirectional links by another method to ensure that BPDUs are sent in the appropriate direction on all links at all times. Otherwise, a unidirectional link ultimately leads to spanning-tree loops or black holes for routed traffic. For instance, if a Layer 3 or routed interface is experiencing a unidirectional link condition but the interface stays up, the switch continues to forward traffic to that interface, but the packet never reaches the far-end device. In this situation, a routing black hole exists. The solution to preventing these issues is to use aggressive mode UDLD.
To illustrate this concept, consider the three switches shown in Figure 3-27. Switch A is the root bridge, and the link between Switch B, and Switch C is in the blocking state because a physical loop is present in the network.
Now consider a situation where the link between Switches B and C becomes unidirectional, as shown in Figure 3-28. Switch B can receive traffic from Switch C, but Switch C cannot receive traffic from Switch B. On the segment between Switches B and C, Switch B is the designated bridge sending the root BPDUs, and Switch C expects to receive the BPDUs. Switch C waits until the max-age timer (20 seconds) expires before it takes action. When this timer expires, Switch C moves through the listening and learning states of STP and then eventually to the STP forwarding state on the port toward Switch B. At this moment, both Switch B and Switch C are forwarding to each other, and essentially, there is no blocking port in the network. This situation is a network loop where severe connectivity issues exist.
Aggressive mode UDLD running on Switches B and C in this scenario would detect the condition and would take corrective action before STP moves into the forwarding state.
UDLD works by exchanging UDLD protocol packets between connected switches. For UDLD to function correctly, it must be enabled on switches on both sides of the link. A UDLD-enabled switch sends UDLD protocol packets with its own device ID and port ID to the neighboring device. The UDLD is in determined status if the switch sees its own information in the packet sent by the neighbor. If the device does not see itself in the neighboring device’s UDLD protocol packets, the link is determined as unidirectional.
Table 3-10 describes the default status for the UDLD on a global and an interface basis.
Table 3-10: UDLD Default Configuration Status
Open table as spreadsheet | Feature | Default Status |
| UDLD global enable state | Globally disabled |
| UDLD per-interface enable state for fiber-optic media | Enabled on all Ethernet fiber-optic interfaces |
| UDLD per-interface enable state for twisted-pair (copper) media | Disabled on all Ethernet 10/100 and 1000BASE-TX interfaces |
UDLD can be enabled globally for all fiber interfaces or on a per-interface basis.
To enable UDLD on an interface, use this command:
To enable UDLD globally on all fiber-optic interfaces, use this command:
To disable UDLD on an individual nonfiber-optic interface, use this command:
To disable UDLD on an individual fiber-optic interface, use this command:
Example 3-17 shows a user configuring and verifying aggressive mode UDLD on interface GigabitEthernet 5/1 on a Cisco IOS-based Catalyst switch.
Example 3-17: Configuration and Verification of UDLD on Cisco Switches
SwitchA# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
SwitchA(config)# interface gigabitEthernet 5/1
SwitchA(config-if)# udld port aggressive
SwitchA(config-if)# end
SwitchA#
SwitchA#show udld gigabitEthernet 5/1
Interface Gi5/1
---
Port enable administrative configuration setting: Enabled / in aggressive mode
Port enable operational state: Enabled / in aggressive mode
Current bidirectional state: Bidirectional
Current operational state: Advertisement - Single neighbor detected
Message interval: 15
Time out interval: 5
Entry 1
---
Expiration time: 38
Device ID: 1
Current neighbor state: Bidirectional
Device name: FOX06310RW1
Port ID: Gi1/1
Neighbor echo 1 device: FOX0627A001
Neighbor echo 1 port: Gi5/1
Message interval: 15
Time out interval: 5
CDP Device name: SwitchB
To summarize, UDLD and aggressive mode UDLD are critical features recommended on all ports to prevent various issues that can potentially cause network outages.
Comparison Between Aggressive Mode UDLD and Loop Guard
Loop Guard and aggressive mode UDLD functionality overlap insofar as both protect against STP failures caused by unidirectional links. These two features are different, however, in their approach to the problem and in functionality. Table 3-11 compares and contrasts the Loop Guard and aggressive mode UDLD features.
Table 3-11: Comparison Between Loop Guard and Aggressive Mode UDLD
Open table as spreadsheet | | Loop Guard | Aggressive Mode UDLD |
| Configuration | Per port | Per port |
| Action granularity | Per VLAN | Per port |
| Auto-recovery | Yes | Yes, with err-disable timeout feature |
| Protection against STP failures caused by unidirectional links | Yes, when enabled on all root ports and alternative ports in redundant topology | Yes, when enabled on all links in redundant topology |
| Protection against STP failures caused by problem in software resulting in designated switch not sending BPDUs | Yes | No |
| Protection against miswiring | No | Yes |
The most noticeable difference between aggressive mode UDLD and Loop Guard is with regard to STP. Aggressive mode UDLD cannot detect failures caused by problems in software in the designated switch not sending the BPDU. Problems resulting from software failures are less common than failures caused by unidirectional links that result from hardware failures. Nevertheless, aggressive mode UDLD is more robust in its capability to detect unidirectional links on EtherChannel. Loop Guard blocks all interfaces of the EtherChannel in such a failure by putting the EtherChannel into the loop-inconsistent state for a VLAN or for all VLANs, whereas aggressive mode UDLD disables the single port exhibiting problems. In addition, aggressive mode UDLD is not dependent on STP, so it supports Layer 3 links as well.
In addition, Loop Guard does not support shared links or interfaces that are unidirectional on switch Bootup. If a port is unidirectional on switch Bootup, the port never receives BPDUs and becomes a designated port. Loop Guard does not support this scenario, because the behavior is not distinguishable from normal STP operation. Aggressive mode UDLD does provide protection against such a failure scenario.
Enabling both aggressive mode UDLD and Loop Guard provides the highest level of protection against bridging loops and black holes in multilayer switched networks.
Flex Links
Flex Links is a Layer 2 availability feature that provides an alternative solution to STP and allows users to turn off STP and still provide basic link redundancy. Flex Links can coexist with spanning tree turned in the distribution layer switches; however, the distribution layer is unaware of Flex Links feature. This enhancement enables a convergence time of less than 50 milliseconds. In addition, this convergence time remains consistent regardless of the number of VLANs or MAC addresses configured on switch uplink ports.
Flex Links is based on defining an active/standby link pair on a common access switch. Flex Links are a pair of Layer 2 interfaces, either switchports or port channels, that are configured to act as a backup to another Layer 2 interface, as shown in Figure 3-29.
Flex Links are configured on one Layer 2 interface (the active link) by assigning another Layer 2 interface as the Flex Links or backup link. The Flex Links can be on the same switch or on another switch in the stack. When one of the links is up and forwarding traffic, the other link is in standby mode, ready to begin forwarding traffic if the other link shuts down. At any given time, only one of the interfaces is in the linkup state and forwarding traffic. If the primary link shuts down, the standby link starts forwarding traffic. When the active link comes back up, it goes into standby mode and does not forward traffic. Flex Links are supported only on Layer 2 ports and port channels, not on VLANs or on Layer 3 ports.
Follow these guidelines to configure Flex Links:
-
You can configure only one Flex Links backup link for any active link, and it must be a different interface from the active interface.
-
An interface can belong to only one Flex Links pair. An interface can be a backup link for only one active link. An active link cannot belong to another Flex Links pair.
-
Neither of the links can be a port that belongs to an EtherChannel. However, you can configure two port channels (EtherChannel logical interfaces) as Flex Links, and you can configure a port channel and a physical interface as Flex Links, with either the port channel or the physical interface as the active link.
-
A backup link does not have to be the same type (Fast Ethernet, Gigabit Ethernet, or port channel) as the active link. However, you should configure both Flex Links with similar characteristics so that there are no loops or changes in behavior if the standby link begins to forward traffic.
-
STP is disabled on Flex Links ports. A Flex Links port does not participate in STP, even if the VLANs present on the port are configured for STP. When STP is not enabled, be sure that there are no loops in the configured topology.
Flex Links are configured at the interface level with the command:
Example 3-18 shows how to configure an interface with a backup interface and to verify the configuration.
Example 3-18: Configuration and Verification of Flex Links
Switch# configure terminal
Switch(conf)# interface fastethernet1/0/1
Switch(conf-if)# switchport backup interface fastethernet1/0/2
Switch(conf-if)# end
Switch# show interface switchport backup
Switch Backup Interface Pairs:
Active Interface Backup Interface State
--------------------------------------------------------------------------------
FastEthernet1/0/1 FastEthernet1/0/2 Active Up/Backup Standby
0 comments
Post a Comment