Credit to @SpanningTreeDC on Twitter for the awesome STP logo!
Wanted to throw some notes on here on which STP features are global, interface level, how the global configs will impact interfaces that are configured and also how error-recovery can save the day when you don’t want to have to shut/no shut every err-disable interface that happens in the network.
On SW2 I just did a Cisco IOS help “?” under both global and interface config modes
First under global config
SW2(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
Lots. Of. Stuff.
UplinkFast to immediately transition PVST+ ports going directly into “Listening” mode from 15 seconds, Forward Delay for 5 seconds, then transitioning into FWD state.
During this transition, it will flood “Dummy Frames” of the contents of its CAM table with a destination of 0100.0ccd.cdcd (indicating they are dummy frames from Uplinkfast), and all neighbors get these Dummy Frames flooded to them until the dust settles and each switch knows which interfaces the previous switches CAM table now resides off.
This MAC Multicast address is not to be confused with CDP Multicast of 0100.0ccc.cccc which it Multicasts Hellos to every 60 seconds, and worth mentioning is LLDP which Multicasts its own frames every 30 seconds (not sure the MAC).
BackboneFast is for indirect failure, which triggers a switch to start sending superior BPDUs to neighbors if it loses its link to the Root Port, because it believes its the new Root Bridge. This then triggers the neighbors to send RLQ’s (Root Link Queries) to make sure the Root is still THEIR root, then once it ACKs back to them, they let the switch with the indirect Root Path failure know where its new Root Path is.
Portfast can be configured globally here, and will be configured on all Access Ports across the switch, meaning any other port type will not be effected by this global change.
Of course with Portfast global config comes a few options that might also be handy globally:
SW2(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
Mainly these two, bpdufilter turning off the interface from sending or receiving BPDU’s (will just discard them), whereas bpduguard will actually put the port into err-disable if a BPDU is received off that, something that error recovery is going to save us from later.
The “Etherchannel” option is where you actually enable “misconfig guard”:
SW2(config)#span etherchannel ?
guard Configure guard features for etherchannel
SW2(config)#span etherchannel guard ?
misconfig Enable guard to protect against etherchannel misconfiguration
SW2(config)#span etherchannel guard misconfig ?
<cr>
I believe it is actually already on by default, we can check with “show span summ” :
SW2(config)#do sh span summ
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 1 0 0 1 2
———————- ——– ——— ——– ———- ———-
1 vlan 1 0 0 1 2
SW2(config)#
It sure is one of the two STP features enabled by default, not sure what sys-ext-id is other than knowing it adds the VLAN # value to Bridge ID Priority values, however this is an excellent “show” command to know for exam day (along with “show vtp status”).
Few other quick things to touch on is “mode” to of course change from pvst / rapist / mst, and also “span mst …” to issue mst commands from the global config line, and finally “span vlan” to configure things like “span vlan # root primary / secondary” – All good things to do know for exam day and in your customers networks!
A look at the interface level STP commands, as they do override globally configured STP commands, so we better know them (both)!
As said its sometimes easier to just globally configure some things, rather than figure out interface ranges to input a command, and we have a few extra we didn’t in global config:
SW2(config-if)#span ?
bpdufilter Don’t send or receive BPDUs on this interface
bpduguard Don’t accept BPDUs on this interface
cost Change an interface’s spanning tree port path cost
guard Change an interface’s spanning tree guard mode
link-type Specify a link type for spanning tree protocol use
mst Multiple spanning tree
port-priority Change an interface’s spanning tree port priority
portfast Enable an interface to move directly to forwarding on link up
stack-port Enable stack port
vlan VLAN Switch Spanning Tree
In red I have highlighted the same interface-level commands, changing these will override what is configured globally, however in blue is what I will focus on here as this is the stuff not yet talked about which is very important for exam day.
First is off course cost, the driving force behind STP, the theoretical “link speed” to the Root Bridge can be set on a per interface basis to influence which interface on a Bridge is selected for the Root Path (but not the Root Bridge).
Port-Priority I believe will come in mostly with Etherchannel, as it is a driving factor behind which links will join a bundle, however it is also a deciding factor / tie breaker for if an interface is in FWD or BLK mode if you want to adjust the path to your Root Bridge by lowering that (as the lower the Port Priority the more preferred the link is).
Link-Type should never really be messed with as most links will be point-to-point, but there is an option to make it “shared” for an interface, which should only be used in very rare specialty situations if its plugging into a Hub, so just wanted to briefly mention that.
“span guard …” gives us our couple of options that couldn’t be much different / useful:
SW2(config-if)#span guard ?
loop Set guard mode to loop guard on interface
none Set guard mode to none
root Set guard mode to root guard on interface
It is set to “none” by default as there shouldn’t REALLY be a need for this unless your hardening your Root Bridge by applying “span guard root” to a Root Bridges interfaces, which essentially will put a FWD port into a “Root_Incosistent” state until that interface stops receiving superior BPDU’s (if a rogue switch where plugged into the network with a Priority of 0 and could reek momentary havoc on things).
It doesn’t require error-recovery or shut/no shut, it will just stop blocking BPDU’s once Superior BPDU’s stop bouncing off the interface configured with Root Guard.
Loop Guard is like UDLD for STP, in that if an interface configured with “span guard loop” it will put the interface into a “Loop_Inconsistent” mode until it stops receiving BPDUs all together. I’m not entirely sure a good use case for this, but I am sure it is useful for some situation I’m too tired to think up, this will also recover on its own once ALL BPDUs stop bouncing off that interface.
To have a little fun I enabled these on SW1 (The current Root Bridge) and messed with SW2 to see what kind of output can be seen here:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int fa1/0/11
SW1(config-if)#span guard loop
SW1(config-if)#int fa1/0/12
SW1(config-if)#span guard root
SW1(config-if)#
*Mar 1 01:02:09.306: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet1/0/12.
SW1(config-if)#
ASR#2
[Resuming connection 2 to sw2 … ]
SW2(config-if)#exit
SW2(config)#span vlan 1 root primary
SW2(config)#
ASR#1
[Resuming connection 1 to sw1 … ]
*Mar 1 01:02:31.125: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet1/0/12 on VLAN0001.
SW1(config-if)#do sh span
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 24577
Address 5897.1eab.c800
Cost 19
Port 13 (FastEthernet1/0/11)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 1ce6.c7c1.c800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/11 Root FWD 19 128.13 P2p
Fa1/0/12 Desg BKN*19 128.14 P2p *ROOT_Inc
So that is Root Guard, pretty straight forward and actually useful, whereas I’ve only been able to “setup” Loop Guard not to work by using BPDUFilter on a connected port to an interface with this configured.
This is because LoopGuard works by detect Unidirectional links, which will almost never happen unless you have fiber connections (and even then), so to make this work I need to do the following to demonstrate how worthless in my mind this command is:
SW2(config-if)#span bpdufilter enable
SW2(config-if)#
ASR#1
[Resuming connection 1 to sw1 … ]
SW1#
*Mar 1 01:15:12.987: %SPANTREE-2-LOOPGUARD_BLOCK: Loop guard blocking port FastEthernet1/0/11 on VLAN0001.
SW1#
*Mar 1 01:15:12.995: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan1, changed state to down
SW1#
I’d say that took about 6 seconds, so 3 missed BPDU’s and the port goes into “Loop_Inconsistent” state which we can see in the “sh span”:
SW1#sh span
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 1ce6.c7c1.c800
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 1ce6.c7c1.c800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/11 Desg BKN*19 128.13 P2p *LOOP_Inc
Fa1/0/12 Desg BKN*19 128.14 P2p *ROOT_Inc
Both these kids are in trouble! Or we can use the almost unknown show command:
SW1#sh span inconsistentports
Name Interface Inconsistency
——————– ———————— ——————
VLAN0001 FastEthernet1/0/11 Loop Inconsistent
VLAN0001 FastEthernet1/0/12 Root Inconsistent
Number of inconsistent ports (segments) in the system : 2
SW1#
Yes, it is actually a thing đŸ™‚
So these ports will stay in their state until we stop torturing them from SW2, however I feel we should take a look into some error-recovery here as well, I won’t lab this too much but it can be applied to so many things I figured its worth a quick review.
“Errdiable …” comes to save the day! (When we are unavailable to save it!)
This is a very powerful command depending on how it is used, it can save your butt if your not around to shut/no shut a mission critical interface, or it can accidentally let intruders in if applied to the wrong “cause” for a port to enter the err-disable state!
So lets take a look at the options of errdisable in general, of which there are three:
SW1(config)#errdisable ?
detect Error disable detection
flap-setting Error disable flap detection setting
recovery Error disable recovery
So detect from my understanding will create a syslog message when it detects an errdisable condition rather than take any action, “flap-setting” is an interesting one that is beyond the scope of the CCNP but essentially will allow you to configure a flapping link / etherchannel / etc to be put into an “err-disable” state for a certain amount of time before it resumes normal operation (but I will not delve further than just to mention it).
What we want is errdisable recover options shown here:
SW1(config)#errdisable recovery cause ?
all Enable timer to recover from all error causes
arp-inspection Enable timer to recover from arp inspection error
disable state
bpduguard Enable timer to recover from BPDU Guard error
channel-misconfig (STP) Enable timer to recover from channel misconfig error
dhcp-rate-limit Enable timer to recover from dhcp-rate-limit error
dtp-flap Enable timer to recover from dtp-flap error
gbic-invalid Enable timer to recover from invalid GBIC error
inline-power Enable timer to recover from inline-power error
l2ptguard Enable timer to recover from l2protocol-tunnel error
link-flap Enable timer to recover from link-flap error
loopback Enable timer to recover from loopback error
mac-limit Enable timer to recover from mac limit disable state
pagp-flap Enable timer to recover from pagp-flap error
port-mode-failure Enable timer to recover from port mode change
failure
pppoe-ia-rate-limit Enable timer to recover from PPPoE IA rate-limit
error
psecure-violation Enable timer to recover from psecure violation error
psp Enable timer to recover from psp
security-violation Enable timer to recover from 802.1x violation error
sfp-config-mismatch Enable timer to recover from SFP config mismatch
error
small-frame Enable timer to recover from small frame error
storm-control Enable timer to recover from storm-control error
udld Enable timer to recover from udld error
vmps Enable timer to recover from vmps shutdown error
SW1(config)#errdisable recovery cause
I found it funny that there is an “All” command at the top, for the network engineer that doesn’t quite know which problems his network might encounter, and he never wants to get that 2am call that something stopped working đŸ™‚ Love it.
However we DO know what we want to recover from, and that in this instance is storm-control once it remains under its lower threshold for two time intervals (remember it only has to go ABOVE its upper threshold for a single time interval but must remain below its lower threshold for two time intervals in a row to be considered resolved):
SO HOW DO I SEE WHAT ALL HAS ERROR-RECOVERY SET FOR IT? WHATS THE DEFAULT TIMER THAT RECOVERY WILL WAIT BEFORE BRINGING A PORT UP?
Excellent questions, you can issue the command to answer both:
SW1#sh errdisable recover
ErrDisable Reason Timer Status
—————– ————–
arp-inspection Disabled
bpduguard Disabled
channel-misconfig (STP) Disabled
dhcp-rate-limit Disabled
dtp-flap Disabled
gbic-invalid Disabled
inline-power Disabled
l2ptguard Disabled
link-flap Disabled
mac-limit Disabled
loopback Disabled
pagp-flap Disabled
port-mode-failure Disabled
pppoe-ia-rate-limit Disabled
psecure-violation Disabled
security-violation Disabled
sfp-config-mismatch Disabled
small-frame Disabled
storm-control Enabled
udld Disabled
vmps Disabled
psp Disabled
Timer interval: 300 seconds
Interfaces that will be enabled at the next timeout:
SW1#
The default is 300 seconds, and as can be seen nothing is in errdisable recovery mode by default, however 300 seconds is a bit too long (5 minutes of downtime is unacceptable), so lets make that 30 seconds:
SW1(config)#errdisable recovery ?
cause Enable error disable recovery for application
interval Error disable recovery timer value
SW1(config)#errdisable recovery interval ?
<30-86400> timer-interval(sec)
SW1(config)#errdisable recovery interval 30 ?
<cr>
SW1(config)#errdisable recovery interval 30
SW1(config)#
So instead of going the “cause” route to configure it for a feature, you go the “interval” route, which will change it for ALL error recovery configs – The timer is for all error recovery so be sure to have that nailed down for exam day. Just like all information.
And that is about it, I suppose I did do a little labbing to demonstrate output there
My posts will be fewer and further between until exam day as I study and lab my finger tips off right up until I hit the exam room, so this may be one of my last posts until I am hopefully reporting back that I pass.
Take care fellow Cisco Geeks, I will see you on the other side! đŸ™‚
The DEVNET GRIND! 