Note that SW4 is the 3560 that survived the purge of old switches in my lab, and its interfaces do show as Fa0/X instead of Fa1/0/X, so be aware of that with output.
Spanning-Tree Portfast
STP Portfast configuration allows an STP Port to go straight from Blocking Mode to Forwarding mode, skipping the Forward Delay timer for the STP Listening and Learning states, allowing it to go immediately into action.
STP Portfast should only be configured on Access Ports that hosts connect to, as the CLI will yell at me momentarily here, because of this immediate transition that can cause switching loops if it leads back to the switched network instead of out to a host.
If a phone is having trouble booting / getting its config file from the TFTP Server, or a PC is unable to reach the DHCP server, it may be because Portfast is not configured in one form or another.
I say one form or another, because it can be configured in two very different ways, as shown just below.
The first mode I’ll configure will be for Host A, SW1 interface Fa1/0/12, then plug the cable in with the debug running:
SW1(config)#int fa1/0/12
SW1(config-if)#span portfast ?
disable Disable portfast for this interface
trunk Enable portfast on the interface even in trunk mode
<cr>
SW1(config-if)#span 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 FastEthernet1/0/12 but will only
have effect when the interface is in a non-trunking mode.
SW1(config-if)#
Highlighted in red is the STP command being issued, highlighted in blue is the error it kicks out (yelling DO NOT CONFIGURE ON A TRUNK PORT!!), and highlighted in green are some sub-commands I will check out as well.
First however, I will run a debug and plug Host A back in, to witness Portfast in action:
SW1#debug span events
Spanning Tree event debugging is on
SW1#
*Mar 1 01:02:06.647: set portid: VLAN0010 Fa1/0/12: new port id 800E
*Mar 1 01:02:06.647: STP: VLAN0010 Fa1/0/12 ->jump to forwarding from blocking
SW1#
*Mar 1 01:02:08.643: %LINK-3-UPDOWN: Interface FastEthernet1/0/12, changed state to up
*Mar 1 01:02:09.650: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/12, changed state to up
SW1#
Kapow!
I thought that was an interesting STP debug output line, its very straight forward, and a good idea to keep in mind that this line means Portfast is enabled on the interface for exam day!
Now with the CLI output when configuring Portfast screaming about not using it on a Trunk connecting to another switch, I thought it was very odd that a trunk option existed, so I wanted to try it quick to see what happens when configured:
SW1(config)#int fa1/0/1
SW1(config-if)#span portfast trunk ?
<cr>
SW1(config-if)#span portfast trunk
%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
SW1(config-if)#
So no further sub-commands, and it takes the configuration just fine while still issuing the warning about bridging loops, the only difference is it does not give the output “will only work on non-Trunk ports” in the warning.
So lets run a debug and see what happens when I plug a trunk cable back into Fa1/0/1:
SW1#debug span events
Spanning Tree event debugging is on
SW1#
*Mar 1 01:07:52.123: %LINK-3-UPDOWN: Interface FastEthernet1/0/1, changed state to up
*Mar 1 01:07:53.147: set portid: VLAN0010 Fa1/0/1: new port id 8003
*Mar 1 01:07:53.147: STP: VLAN0010 Fa1/0/1 ->jump to forwarding from blocking
*Mar 1 01:07:53.147: set portid: VLAN0020 Fa1/0/1: new port id 8003
*Mar 1 01:07:53.147: STP: VLAN0020 Fa1/0/1 ->jump to forwarding from blocking
*Mar 1 01:07:53.147: set portid: VLAN0030 Fa1/0/1: new port id 8003
*Mar 1 01:07:53.147: STP: VLAN0030 Fa1/0/1 ->jump to forwarding from blocking
SW1#
*Mar 1 01:07:53.155: set portid: VLAN0001 Fa1/0/1: new port id 8003
*Mar 1 01:07:53.155: STP: VLAN0001 Fa1/0/1 ->jump to forwarding from blocking
*Mar 1 01:07:54.170: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/1, changed state to up
SW1#
So it jumps right into action, pun intended, just as Fa1/0/12 did with Host A.
Before configuring this globally, I’ve removed the command from Trunk Fa1/0/1 by putting a “no” in front of it on the interface, however you can also use the command “span portfast disable” to both remove it and ensure it does not become enabled.
Now let me configure global configuration, which as it sounds, globally turns on Portfast for the switch, but includes an interesting wording contradiction:
SW1(config)#span ?
backbonefast Enable BackboneFast Feature
etherchannel Spanning tree etherchannel specific configuration
extend Spanning Tree 802.1t extensions
logging Enable Spanning tree logging
loopguard Spanning tree loopguard options
mode Spanning tree operating mode
mst Multiple spanning tree configuration
pathcost Spanning tree pathcost options
portfast Spanning tree portfast options
transmit STP transmit parameters
uplinkfast Enable UplinkFast Feature
vlan VLAN Switch Spanning Tree
SW1(config)#span portfast ?
bpdufilter Enable portfast bpdu filter on this switch
bpduguard Enable portfast bpdu guard on this switch
default Enable portfast by default on all access ports
SW1(config)#span portfast default ?
<cr>
SW1(config)#span 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.
SW1(config)#
This command enables Portfast on all… wait a minute…
The contradictory wording is highlighted in an ugly shade of green and underlined to contrast where it is in this output, and despite the warning highlighted in blue, this actually WILL NOT enable Portfast on ALL interfaces – Only on Access Ports as indicated by the sub-command description!
To verify this does not impact Trunk interfaces, there is no “sh span …” command to verify, its kind of an odd command with important structure to note for exam day!
Here is a step by step through sub-commands:
SW1#sh span int ?
FastEthernet FastEthernet IEEE 802.3
GigabitEthernet GigabitEthernet IEEE 802.3z
Port-channel Ethernet Channel of interfaces
SW1#sh span int fa1/0/1 ?
active Report on active instances only
cost Port path cost
detail Detailed information
inconsistency Port inconsistency state
portfast PortFast configuration
priority Port priority
rootcost Path cost to root
state Port spanning tree state
| Output modifiers
<cr>
SW1#sh span int fa1/0/1 portfast ?
| Output modifiers
<cr>
SW1#sh span int fa1/0/1 portfast
VLAN0001 disabled
VLAN0010 disabled
VLAN0020 disabled
VLAN0030 disabled
SW1#
So one thing to note, you cannot look at multiple interfaces at once with “sh span int range …” or separated by commas, so that is one important note for exam day.
Also, it shows if Portfast is enabled for every VLAN that the interface is associated with which I highlighted in blue, this shows it is a member of all VLANs (being a trunk of course) and that it is not enabled on the Trunk despite it being enabled globally.
To drive this point home, I removed the interface level command from Host A’s interface and verified that the global configuration is still enabling Portfast on the interface:
SW1(config)#int fa1/0/12
SW1(config-if)#no span portfast
SW1(config-if)#do sh span int fa1/0/12 portfast
VLAN0010 enabled
SW1(config-if)#
I re-enabled it here to drive one more point home on Portfast before I am done with that, which is that you can have both showing up in the running configuration as shown here in just the pertinent snips of the “sh run”:
Spanning-Tree section of running config
!
!
spanning-tree mode pvst
spanning-tree portfast default
spanning-tree extend system-id
spanning-tree vlan 1,10,20,30 priority 24576
!
Interface section with Spanning-Tree info
!
interface FastEthernet1/0/11
!
interface FastEthernet1/0/12
switchport access vlan 10
switchport mode access
spanning-tree portfast
!
interface FastEthernet1/0/13
!
So even after it is configured globally it can still be present on a per port basis, so removing it globally may not fully remove Portfast from a switch on exam day.
Direct vs Indirect link failure illustrated
Being its such an important concept to grasp that I wrestled with for a long time, well into my CCNP studies, I wanted to illustrate the difference on the topic of these STP features, as Uplinkfast will address Direct link failure whereas Backbonefast will address Indirect link failure – So we better be crystal clear on the difference!
A Direct link failure in the switched network, is from the vantage point of which switch is being referred to, for example this Topology I will use going forward will consist of only SW1 / SW2 / SW3 for less colors and more clarity.
Direct link failure is a link directly connected to the “local” switch failing, so to illustrate this, these are all the points of Direct link failure in the Topology for SW3 specifically:
If any of these interfaces were to go down, the switch would immediately begin the transition into a Forwarding state, so it would have a total of 30 seconds delay until it begins Forwarding frames – Not as bad as it gets but could be faster!
Indirect link failure is as bad as it gets (outside of a switching loop!), with the Bridge having to wait for 10 missed Hellos (max-age timer expiring) before it will even begin the transition to Forwarding, and even then it still has to go through Listening and Learning for 15 seconds each before it moves into Forwarding state.
This is an illustration of Indirect link failures from the perspective of SW3:
I’ll show the before and after transitions times with each of these, but I wanted to compact the lab a bit more to demonstrate these differences in link failure types, and our solutions to them as mentioned just below!
Spanning-Tree UplinkFast
STP Uplinkfast is the Portfast equivalent for near immediate STP convergence between switches, as the CLI yells at us every time we want to configure Portfast on a Trunk interface, so we have Uplinkfast to provide a similar port transition experience between our switches.
This is configured globally only, no per interface or per VLAN configuration possible, so if you see anything about that on exam day it is incorrect right out of the gate.
Uplinkfast works by determining all ports (including the Root Port) that are possible paths back to the Root Bridge, putting them all into a group called an “Uplink Group”, and if the Root Port becomes unavailable it can immediately pull the next lowest Cost link out of this Uplink Group to put immediately into Forwarding state.
There is no command like “show uplink group” outside of viewing interfaces with the “sh span” command.
Cisco best practice recommendations, recommends this not be configured on Core or Distribution layer switches in the 3-Layer switching model, but rather on switches that have STP Ports that will be placed into Alternate / Blocking state such as Access Layer switches (which will generally have more redundancy in the 3-Layer switching model).
For this demonstration, I will be causing the Direct link failure shown here:
Debug output prior to configuring Uplinkfast, pulling cable from SW2 Fa1/0/2
SW3#debug span events
Spanning Tree event debugging is on
SW3#
*Mar 1 01:09:15.615: STP: VLAN0001 new root port Fa1/0/3, cost 100
*Mar 1 01:09:15.615: STP: VLAN0001 Fa1/0/3 -> listening
*Mar 1 01:09:15.615: STP[1]: Generating TC trap for port FastEthernet1/0/2
*Mar 1 01:09:16.605: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to down
*Mar 1 01:09:17.620: STP: VLAN0001 sent Topology Change Notice on Fa1/0/3
*Mar 1 01:09:17.620: %LINK-3-UPDOWN: Interface FastEthernet1/0/2, changed state to down
*Mar 1 01:09:30.622: STP: VLAN0001 Fa1/0/3 -> learning
*Mar 1 01:09:45.630: STP[1]: Generating TC trap for port FastEthernet1/0/3
*Mar 1 01:09:45.630: STP: VLAN0001 Fa1/0/3 -> forwarding
SW3#
The Alternate Port goes immediately into Listening state, Learning, and eventually to Forwarding within 30 seconds of the Direct link failure as we’d expect.
Configuration of Uplinkfast on the Bridge
SW3(config)#span ?
backbonefast Enable BackboneFast Feature
etherchannel Spanning tree etherchannel specific configuration
extend Spanning Tree 802.1t extensions
logging Enable Spanning tree logging
loopguard Spanning tree loopguard options
mode Spanning tree operating mode
mst Multiple spanning tree configuration
pathcost Spanning tree pathcost options
portfast Spanning tree portfast options
transmit STP transmit parameters
uplinkfast Enable UplinkFast Feature
vlan VLAN Switch Spanning Tree
SW3(config)#span uplinkfast ?
max-update-rate Rate at which station address updates are sent
<cr>
SW3(config)#span uplinkfast
SW3(config)#
*Mar 1 01:14:07.010: setting bridge id (which=1) prio 49153 prio cfg 49152 sysid 1 (on) id C001.5897.1eab.ce00
SW3(config)#
Got a little preview there of some configuration changes happening in the debug output, got a new priority and priority cfg value in there, lets verify some things!
STP Uplinkfast dynamic changes to Bridge
SW3(config)#do sh span
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 1ce6.c7c1.c800
Cost 3038
Port 4 (FastEthernet1/0/2)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 49153 (priority 49152 sys-id-ext 1)
Address 5897.1eab.ce00
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Uplinkfast enabled
Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Root FWD 3019 128.4 P2p
Fa1/0/3 Altn BLK 3100 128.5 P2p
There are a few things going on here:
- Uplinkfast dynamically changed the Bridge Priority to 49152, making the Bridge ID Priority 49153 due to the sys-id-ext 1 (VLAN #), to ensure this Bridge will not be elected Root Bridge unless basically all other Bridges in the network go down.
- The local Bridge ID Priority now shows “Uplinkfast Enabled” below its timers
- A value of 3000 has been dynamically to all interfaces Path Cost, making sure no downstream switches use this path to the Root Bridge if it can be avoided
So Uplinkfast goes pretty far out of its way to not be the Root Bridge, or even be used as a Path to the Root Bridge, which is why Cisco recommends only using it on Access Layer switches from our 3-Layer switching model – The inner core of a switched network should not be left up to dynamic behaviors determining the work load and traffic path.
All that finger wagging have been said, lets see what Uplinkfast does get very right:
Debug output after configuring Uplinkfast, pulling cable from SW2 Fa1/0/2
SW3#
*Mar 1 01:29:00.699: STP: VLAN0001 new root port Fa1/0/3, cost 3100
*Mar 1 01:29:00.699: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 FastEthernet1/0/3 moved to Forwarding (UplinkFast).
*Mar 1 01:29:00.699: STP[1]: Generating TC trap for port FastEthernet1/0/3
*Mar 1 01:29:00.699: STP[1]: Generating TC trap for port FastEthernet1/0/2
*Mar 1 01:29:01.689: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to down
*Mar 1 01:29:02.704: STP: VLAN0001 sent Topology Change Notice on Fa1/0/3
*Mar 1 01:29:02.704: %LINK-3-UPDOWN: Interface FastEthernet1/0/2, changed state to down
SW3#
Uplinkfast had the Alternate Port from Blocking to Forwarding almost a full second before the Line Protocol went down on the interface of Fa1/0/2, no 30 second delay of Listening and Learning.
If the original Root Path link becomes available again (or a better Root Path) it will be placed almost immediately into Listening state, and 2 x Forward Delay timers (2 x 15 seconds) will elapse before it is put directly into Forwarding (skipping Learning).
Here is a debug of plugging Fa1/0/2 on SW2 back in
SW3(config)#
*Mar 1 01:48:57.401: %LINK-3-UPDOWN: Interface FastEthernet1/0/2, changed state to up
*Mar 1 01:48:58.424: set portid: VLAN0001 Fa1/0/2: new port id 8004
*Mar 1 01:48:58.424: STP: VLAN0001 Fa1/0/2 -> listening
*Mar 1 01:48:59.423: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to up
*Mar 1 01:49:00.085: STP: VLAN0001 Fa1/0/2: root port delay timer active
*Mar 1 01:49:00.085: STP: VLAN0001 Fa1/0/2 -> blocking
*Mar 1 01:49:35.091: STP: VLAN0001 new root port Fa1/0/2, cost 3038
*Mar 1 01:49:35.091: STP: VLAN0001 Fa1/0/3 -> blocking (uplinkfast)
*Mar 1 01:49:35.091: STP[1]: Generating TC trap for port FastEthernet1/0/3
*Mar 1 01:49:35.091: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0001 FastEthernet1/0/2 moved to Forwarding (UplinkFast).
*Mar 1 01:49:35.091: STP[1]: Generating TC trap for port FastEthernet1/0/2
*Mar 1 01:49:35.091: STP: VLAN0001 sent Topology Change Notice on Fa1/0/2
SW3(config)#
So it doesn’t actually going into a Learning state, so its said that it just elapses 2 x Forward Delay timer + 5 seconds as demonstrated above.
One last very important Uplinkfast concept, is its “max-update-rate” sub-command
When a frame Forwarding path is abruptly changed, this can of course lead to CAM or MAC Address tables for hosts now being suddenly incorrect, so a mechanism is needed to work with Uplinkfast to immediately update CAM tables in the switched network as well.
This is addressed via Multicast dummy frames being sent out by the Bridge that just went through an Uplinkfast transition, it will use the MAC Addresses from its CAM table, and flood them via Multicast frames to other Bridges with the Destination MAC of:
0100.0CCD.CDCD – I remember this by the last hextet of CDCD
The “max-update-rate” command allows changing of the default value of 150 packets per second to the following values:
SW3(config)#span uplinkfast ?
max-update-rate Rate at which station address updates are sent
<cr>
SW3(config)#span uplinkfast max-update-rate ?
<0-32000> Maximum number of update packets per second
Enter 0 as the value to disable the dummy frame flooding behavior, and configure up to 32,000 packets per second if needed, if the Bridges CAM table contains more than 150 entries it may be advised to raise this default value so all MAC Addresses can be flooded within the first second of the change.
Spanning-Tree BackboneFast
STP Backbonefast is Cisco Proprietary, and is a mechanism for Bridges to converge quickly after an Indirect link failure, which DOES use the STP Max-Age timer of 20 seconds or 10 missed Hellos before it begins transition Port states into FWD.
This will be the Indirect link failure, again from the perspective of SW3:
During this time SW3 will be getting BPDUs from both SW2 and SW1, but it will listen on that Root Port Fa1/0/2 for Hellos until it misses 10 (20 second max-age timer expires), and then it will put Fa1/0/3 into Lis / Ler / Fwd – A total of 50 seconds.
Backbonefast configuration cuts out the Max-Age timer / waiting to miss 10 Hellos, which drops the Forward delay from 50 seconds to 30 seconds so it is not IMMEDIATE, however it does cut 20 seconds off recovery time from an Indirect link failure.
It does this by sending an RLQ (Root Link Query) message out of its Root Port, which is a constant exchange of sending and receiving responses off the Bridges Root Port, containing information on who it believes the Root Bridge is, and either receiving a confirmation response or receiving a response telling it the Root Bridge info is incorrect.
This RLQ traffic has to be enabled on the entire switched network, or Backbonefast does not work, it is all or nothing both on the Bridge and on the switched network!
The configuration of Backbonefast
SW3(config)#span backbonefast ?
<cr>
SW3(config)#span backbonefast
SW3(config)#
Yep.
Verifying RLQ statistics for the Bridge network
SW3(config)#do sh span backbonefast
BackboneFast is enabled
BackboneFast statistics
———————–
Number of transition via backboneFast (all VLANs) : 0
Number of inferior BPDUs received (all VLANs) : 0
Number of RLQ request PDUs received (all VLANs) : 0
Number of RLQ response PDUs received (all VLANs) : 0
Number of RLQ request PDUs sent (all VLANs) : 0
Number of RLQ response PDUs sent (all VLANs) : 0
SW3(config)#
Causing an Indirect link failure
SW3(config)#
*Mar 1 02:35:44.665: STP: VLAN0001 heard root 32769-5897.1eab.c800 on Fa1/0/2
*Mar 1 02:35:44.707: STP: VLAN0001 new root port Fa1/0/3, cost 100
*Mar 1 02:35:44.707: STP: VLAN0001 Fa1/0/3 -> listening
*Mar 1 02:35:45.127: STP: VLAN0001 Topology Change rcvd on Fa1/0/2
*Mar 1 02:35:45.127: STP: VLAN0001 sent Topology Change Notice on Fa1/0/3
SW3(config)#
*Mar 1 02:35:59.714: STP: VLAN0001 Fa1/0/3 -> learning
SW3(config)#
*Mar 1 02:36:14.722: STP[1]: Generating TC trap for port FastEthernet1/0/3
*Mar 1 02:36:14.722: STP: VLAN0001 sent Topology Change Notice on Fa1/0/3
*Mar 1 02:36:14.722: STP: VLAN0001 Fa1/0/3 -> forwarding
SW3(config)#
Checking Backbonefast statistics once more
SW3(config)#do sh span backbonefast
BackboneFast is enabled
BackboneFast statistics
———————–
Number of transition via backboneFast (all VLANs) : 1
Number of inferior BPDUs received (all VLANs) : 1
Number of RLQ request PDUs received (all VLANs) : 0
Number of RLQ response PDUs received (all VLANs) : 1
Number of RLQ request PDUs sent (all VLANs) : 1
Number of RLQ response PDUs sent (all VLANs) : 0
SW3(config)#
Increased is the number of these RLQ PDUs sent, inferior BPDU’s (higher values than local Bridge), and transitions expedited via Backbonefast.
That is it for those three topics!
Next up to finish STP is Guard options, and a quick discussion on UDLD!
The DEVNET GRIND! 