Overview
WIth the fundamentals of STP nailed down, we'll dive into more advanced STP features and versions. You won't use all of these in every network you do admin work on, but you will see them out in the field - and on
Portfast and the switchport host command
Uplinkfast
Backbonefast
Root Guard
BPDU Guard
UDLD
Loop Guard
BPDU Skew Detection
Rapid Spanning Tree Protocol
PVST And PVST+
CTP and MST
Etherchannels
Flex Links
your CCNP SWITCH exam.
Portfast
Suitable only for switch ports connected directly to a single host, Portfast allows a port running STP to go directly from blocking to forwarding mode.
If you have an issue with a host acquiring an IP address via DHCP, configuring Portfast on the switch port in question just might solve the issue. Going through the normal STP stages on that port as the host finishes booting can cause a bit of havoc with the overall DHCP process.
A Cisco router will give you an interesting warning when you configure Portfast:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on FastEthernet0/5 but will only have effect when the interface is in a non-trunking mode.
SW1(config-if)#
That is one long warning.
Not only will the switch warn you about the proper usage of Portfast, but you must put the port into access mode ("non-trunking") before Portfast will take effect.
An excellent real-world usage of Portfast is to allow users to get their IP addresses from a DHCP server. If a switchport has a workstation connected to a port, that workstation will still have to wait 30 seconds for the listening and learning stages of STP to run before it can communicate successfully with the DHCP server.
We all know that 30 seconds seems like 30 minutes to end users, especially first thing in the morning! Running Portfast on the appropriate switch ports did speed up their initial network connectivity.
Portfast can also be enabled globally, but we'll get another warning when we do so:
SW2(config)#spanning portfast default
%Warning: this command enables portfast by default on all interfaces. You should now disable portfast explicitly on switched ports leading to hubs, switches and bridges as they may create temporary bridging loops.
Personally, I like to configure it on a per-port basis, but make sure you know both ways to configure Portfast. It never hurts to know more than one way to do things on a Cisco exam. And remember, a Portfast-enabled port will not send TCP BPDUs when the port goes into Blocking mode.
There's a command related to portfast that I want to share with you - note the three effects of this command as explained by IOS Help:
SW1(config-if)#switchport host ? <cr>
SW1(config-if)#switchport host
switchport mode will be set to access spanning-tree portfast will be enabled channel group will be disabled
Good stuff to know!
Uplinkfast
When a port goes through the transition from blocking to forwarding, you're looking at a 50-second delay before that port can actually begin forwarding frames. Configuring a port with Portfast is one way to get around that, but again, you can only use it when a single host device is found off the port. What if the device connected to a port is another switch?
SW3 has two paths to the root switch. STP will only allow one path to be available, but if the open path between SW3 and SW1 goes down, there will be approximately a 50-second delay before the currently blocked path will be available.
The delay is there to prevent switching loops, and we can't use Portfast to shorten the delay since these are switches, not host devices. What we can use is Uplinkfast.
The ports that SW3 could potentially use to reach the root switch are collectively referred to as an uplink group. The uplink group includes the ports in forwarding and blocking mode. If the forwarding port in the uplink group sees that the link has gone down, another port in the uplink group will be transitioned from blocking to forwarding immediately.
Uplinkfast is pretty much Portfast for wiring closets. Cisco recommends that Uplinkfast not be used on switches in the distribution and core layers.
Some additional details regarding Uplinkfast:
The actual transition from blocking to forwarding isn't really
"immediate" - it actually takes 1 - 3 seconds. Next to a 50-second delay, that certainly seems immediate!
Uplinkfast cannot be configured on a root switch.
When Uplinkfast is enabled, it's enabled globally and for all VLANs residing on the switch. You can't run Uplinkfast on some ports or on a per-VLAN basis - it's all or nothing.
The original root port will become the root port again when it detects that
its link to the root switch has come back up. This does not take place immediately. The switch uses the following formula to determine how long to wait before transitioning the original root port back to the
forwarding state:
( 2 x FwdDelay) + 5 seconds
Uplinkfast will take immediate action to ensure that a switch cannot become the root switch -- actually, two immediate actions!
First, the switch priority will be set to 49,152, which means that if all other switches are still at their default priority, they'd all have to go down before this switch can possibly become the root switch.
Additionally, the STP Port Cost will be increased by 3000, making it highly unlikely that this switch will be used to reach the root switch by any downstream switches.
And you just know there's got to be at least one option with this command, right? Let's run IOS Help and see.
SW2(config)#spanning-tree uplinkfast ?
max-update-rate Rate at which station address updates are sent
When there is a direct link failure, dummy multicast frames are sent to the MAC destination address 01-00-0c-cd-cd-cd. The max-update-rate value determines how many of these frames will be sent in a 100-millisecond time period.
Where To Apply Uplinkfast
As with all the topics in this section, it's not enough to know the definition of Uplinkfast and what it does - you've got to know where to configure it for best results.
Uplinkfast is a wiring-closet switch feature - it's not recommended for core and distribution-layer switches. Uplinkfast should be configured only on access-layer switches. It's a safe bet that the root switches are going to be found in the core layer, and the switches that are farthest away from the root switches will be the access switches. The access switches will be the ones closest to the end users.
Backbonefast
Uplinkfast and Portfast are great, but they've got limitations on when they can and should be run. You definitely can't run either one in a network backbone, but the Cisco-proprietary feature Backbonefast can be used to help recover from indirect link failures.
The key word there is indirect. If a core switch detects an indirect link failure - a failure of a link that is not directly connected to the core switch in question - Backbonefast goes into action.
This indirect link failure is detected when an inferior BPDU is received.
Now, you may be asking, "What is an inferior BPDU?" Glad you asked!
Let's take a look at a three-switch setup where all links are working and STP is running as expected, paying particular attention to the STP states on SW3. All links are assumed to be running at the same speed.
SW1 has been elected the root bridge, and sends BPDUs every two seconds to SW2 and SW3 telling them this. In turn, SW2 takes the BPDU it's receiving from SW1 and relays it to SW3. All is well, until SW2 loses its connection to SW1, as shown below - which means that SW2 will start announcing itself as the root switch. SW3 will now be receiving two separate BPDUs from two separate switches, both claiming to be the root switch.
SW3 looks at the priority of the BPDU coming in from SW2, and compares it to the BDPUs it's getting from SW1. SW3 quickly realizes the BPDU from SW2 is an inferior BPDU, and simply ignores it. Once SW3's MaxAge timer on the port leading to SW2 hits zero, that port will transition to the listening state and will start relaying the information contained in the superior BPDU, the BPDU coming in from SW1.
The key phrase here is "once SW3's MaxAge timer on the port leading to SW2 hits zero". We really don't want to wait that long, and with Backbonefast, we don't have to!
When BackboneFast is configured, this process skips the MaxAge stage.
While this does not eliminate delays as efficiently as PortFast and UplinkFast, but the delay is cut from 50 seconds to 30. (MaxAge's default value is 20 seconds, but the 15-second Listening and Learning stages still have to run.)
BackboneFast uses the Root Link Query (RLQ) protocol. RLQ uses a series of requests and responses to detect indirect link outages.
RLQ requests are transmitted via the ports that would normally be receiving BPDUs. The purpose of these RLQ requests is to ensure that the local switch still has connectivity to the root switch. The RLQ request identifies the bridge that is considered the root bridge, and the RLQ response will identify the root bridge that can be accessed via that port. If they're one and the same, everything's fine.
Upon receiving a RLQ request, a switch will answer immediately under one of two conditions:
The receiving switch is indeed the root bridge named in the RLQ request
The receiving switch has no connectivity to the root bridge named in the RLQ request, because it considers another switch to be the root bridge
The third possibility is that the receiving switch is not the root, but considers the root switch named in the RLQ request to indeed be the root switch. In that case, the RLQ request is relayed toward the root switch by sending it out the root port.
To put BackboneFast into action in our network, we have to know more than the command! We've got to know where to configure it as well. Since all switches in the network have to be able to send, relay, and respond to RLQ requests, and RLQ is enabled by enabling BackboneFast, every switch in the network should be configured for BackboneFast when using this feature.
This feature is enabled globally, and it's simple to configure - and believe it or not, there are no additional timers or options with this command. A true Cisco rarity! The command to verify BackboneFast is just as simple and is shown below.
SW1#show spanning-tree backbonefast BackboneFast is disabled
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#spanning-tree backbonefast
SW1#show spanning-tree backbonefast BackboneFast is enabled
Root Guard
You know that the root switch is the switch with the lowest BID, and that a secondary root is also elected - that's the switch with the next-lowest BID.
You also know that you can use the spanning-tree vlan root command to make sure that a given switch becomes the root or the secondary root.
SW1(config)#spanning-tree vlan 23 root ?
primary Configure this switch as primary root for this spanning tree secondary Configure switch as secondary root
We've used that command to name the root and secondary root switches in the following network. For clarity's sake, the full BID is not shown - just the switch priority.
Nothing wrong here, everything's fine... until another switch is added to the mix.
The problem here is that SW4 is going to become the root switch, and SW1 is going to become the secondary root. If SW4 is allowed to
become the root bridge, here's what the new STP topology will look like.
Depending on the design of your network, this change in root switches can have a negative effect on traffic flow. There's also a delay involved while the switches converge on the new STP topology. Worse yet, there's always the possibility that R4 isn't even under your administrative control - it belongs to another network!
STP has no default behavior to prevent this from happening; the
spanning-tree vlan root command helps you determine which switches become the root and secondary root, but does nothing to disqualify a switch from becoming the root. To prevent SW4 from becoming the root in this network, Root Guard must be configured.
Root Guard is configured at the port level, and disqualifies any switch that is downstream from that port from becoming the root or secondary root.
To prevent SW4 from becoming the root or secondary root, SW3's port that will receive BPDUs from SW4 should be configured with Root Guard.
When the BPDU comes in from SW4, SW3 will recognize this as a
superior BPDU, one that would result in a new root switch being elected.
Root Guard will actually block that superior BPDU, discard it, and put the port into root-inconsistent state. When those superior BPDUs stop
coming, SW3 will allow that port to transition normally through the STP port states.
Configuring Root Guard is simple:
SW3(config)#int fast 0/24
SW3(config-if)#spanning guard root SW3(config-if)#
00:10:35: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/24.
There is no interface reset or reload necessary, but note that Root Guard-enabled ports act as designated ports (until a superior BPDU is received, of course).
SW4 now comes online and sends a superior BPDU for VLAN 23 to SW3, which receives the BPDU on port 0/24 - the port running Root Guard.
Here's the console message we receive as a result on R3:
00:26:46: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/24 on VLAN0023.
Additionally, there's a spanning-tree command that will show you a list of ports that have been put into root-inconsistent state, but it's not as
obvious as some of the other show spanning-tree commands we've seen:
SW3#show spanning-tree ?
active Report on active interfaces only
backbonefast Show spanning tree backbonefast status blockedports Show blocked ports
bridge Status and configuration of this bridge detail Detailed information
inconsistentports Show inconsistent ports
interface Spanning Tree interface status and configuration
Those of you who do not like to type can just enter "inc" for that last word!
This is the resulting topology:
BPDU Guard
Remember that warning that we got from the router when configuring PortFast?
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on FastEthernet0/5 but will only have effect when the interface is in a non-trunking mode.
Now, you'd think that would be enough of a warning, right? But there is a chance - just a chance - that someone is going to manage to connect a switch to a port running Portfast, which in turn creates the possibility of a switching loop.
BPDU Guard protects against this possibility. If any BPDU, superior or inferior, comes in on a port that's running BPDU Guard, the port will be shut down and placed into error disabled state, shown on the switch as err-disabled.
To configure BPDU Guard on a specific port only:
SW1(config)#int fast 0/5
SW1(config-if)#spanning-tree bpduguard
% Incomplete command.
SW1(config-if)#spanning-tree bpduguard ?
disable Disable BPDU guard for this interface enable Enable BPDU guard for this interface SW1(config-if)#spanning-tree bpduguard enable
To configure BPDU Guard on all ports on the switch:
SW1(config)#spanning-tree portfast bpduguard default
Note that this command is a variation of the portfast command.
Naturally, BPDU Guard can only be configured on ports already running Portfast. The same goes for the next feature, BPDU Filtering.
PortFast BPDU Filtering
What if you don't want the port to be put into err-disabled state when it receives a BPDU? You can use BPDU Filtering, but you have to be careful how you configure it - this feature works differently when it's configured globally as opposed to configuring it on a per-interface level.
Globally enabling BPDU Filtering will enable this feature on all
switchports running portfast, and any such port will stop running PortFast if the port receives a BPDU.
Enabling BPDU Filtering on a specific port or ports, rather than enabling it globally, will result in received BPDUs being quietly ignored. Those incoming BPDUs will be dropped, and the port will not send any BPDUs in return.
To enable BPDU Filtering globally on all Portfast-enabled ports:
SW1(config)#spanning portfast bpdufilter ?
default Enable bdpu filter by default on all portfast ports SW1(config)#spanning portfast bpdufilter default
To enable BPDU Filtering on a specific port:
SW1(config)#int fast 0/5 PortFast BPDU Guard Default is disabled Portfast BPDU Filter Default is enabled Loopguard Default is disabled
To verify configuration of BPDU Filtering on a specific port:
SW2#show spanning-tree interface fast0/5 detail Port 5 (FastEthernet0/5) of VLAN0001 is forwarding
Port path cost 19, Port priority 128, Port Identifier 128.5.
Designated root has priority 32769, address 000e.381f.ee80 Designated bridge has priority 32769, address 000e.381f.ee80 Designated port id is 128.5, 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
Link type is point-to-point by default Bpdu filter is enabled by default BPDU: sent 6837, received 0
I know what you Bulldogs are thinking out there - "So what if you run both BPDU Guard and Filtering on the same port?" In that rare case, the port will only act under the Filtering rules we've gone over here.
Unidirectional Link Detection (UDLD)
Most problems involving the physical link will make data transfer in either direction impossible. Particularly with fiber optic, there are situations where a physical layer issue disables data transfer in one direction, but not the other.
UDLD detects these unidirectional links by transmitting a UDLD frame across the link. If a UDLD frame is received in return, that indicates a bidirectional link, and all is well.
If a UDLD frame is not received in return, the link is considered
unidirectional. It's really like a Layer 2 ping. If the UDLD "echo" is seen, there's bidirectional communication; if the "echo" is not seen, there isn't!
UDLD has two modes of operation, normal and aggressive. When a unidirectional link is detected in normal mode, UDLD generates a syslog
UDLD has two modes of operation, normal and aggressive. When a unidirectional link is detected in normal mode, UDLD generates a syslog