Above is a simple STP topology from earlier SWITCH labbing, however this will cover all STP flavors (PVST+ / RSTP / MSTP), features that go with them, and EtherChannels.
STP issues, how to identify and resolve them, and feature behaviors
- In relation to the TSHOOT exam, the most important thing to note is that the three things that must match for switches to be part of the same “MST Region” is Region Name, Region Config Revision # (manually entered), and VLAN mapping instance #
- “sh span mst config” to verify these 3 required fields match on all switches
- MAC Address Table corruption is caused by broadcast storms of frames when switches are connected on shared media, and frames are continuously flooded back onto the shared media that the switches are connected to, constantly flapping which port a source MAC is found off of, this can be identified by a network slowdown or interface flapping observed in syslog
- When a port is configured with STP Portfast, it skips any STP delay states, however if a Portfast interface receeives a BPDU it reverts back to a regular STP interface with FWD delay timers (LIS / LRN / ETC)
- “sh span vlan #” for root bridge / local bridge details, timers, and STP interface states on local bridge
- “sh span interface (int) detail” to get interface specific details such as cost, STP state, port priority #, and STP features enabled on interface!
- “sh span summary” to show all STP features that are enabled (BPDU Guard, BPDU Filter, Etc)
- “sh int status” will show interfaces status including err-disabled interfaces
- “errdisable recovery cause (stp feature)” to set automatic recovery of err-disbaled interfaces, or can shut / not shut interface to manually bring back up
- BPDU Guard will put interface into err-disable if it receives a BPDU
- BPDU Filter suppresses sending / receiving BPDU’s on an interface
- Root Guard is configured on interfaces to prevent a rogue switch being introduced to the network and sending out Superior BIDs to become the Root Bridge, any ports that receive a Superior BPDU on a port configured with Root Guard will go into a “root inconsistent” state
- Loop Guard places an interface into a “loop inconsistent” state when it stops receiving BPDUs to prevent it from transition into FWD state and creating a loop in the layer 2 topology
- “sh spanning inconsistent ports” to see ports in both root and loop inconsistent states due to Root Guard and Loop Guard, these states cannot just be remedied by bringing them back up like err-disable ports, as there is a larger underlying issue that needs to be addressed somewhere in the Layer 2 Topology!
In terms of troubleshooting, you will want to be familiar with all the features / how to correct issues / how to make certain switches the root bridge for a vlan which most of the info can be found in this overview of STP post.
One thing I don’t believe is on there is actually making the switches primary or secondary, which is done with the command “span vlan # priority #” where the VLAN is whichever VLAN you need to adjust and the priority # is 0-64,000 something, and it can be increased or decreased in increments of 4096.
Also “sh cdp nei” and “sh cdp nei det” is a very useful tool when taking a “Follow the Data Path” approach to get a logical Topology that you will want to draw out on your dry erase board during the exam to reference as the topology will not have detailed STP info on the diagram itself.
Another potential misconfig with STP is manual cost configuration on an interface, this can be seen in either the “sh run int (int)” or with “sh span vlan #” under the interfaces, and can be changed on the interface config with “span vlan # cost #” or negated by typing a “no” in front of the current static config to allow dynamic cost calculation to occur – This is a potential gotcha so be aware of this for exam day!
Yet another possibility when troubleshooting layer 1 and layer 2 issues, is seeing a 169.254.x.x address and immediately jumping to DHCP as the issue, however you will need to resist the urge to jump to this conclusion.
^In this situation, first you would want to confirm on the switchport interface that it is showing Up/Up on the Access switch, check the MAC table with “sh mac address-table dyn” to see if the switch is receiving frames, and at this point its easy to think this is a layer 1 cable issue but lets not jump there yet! At this point you will want to check for port to be in an STP error state, by issuing a “sh span inconsistent ports” as for any number of reasons the interface may have received a BPDU from an application on the PC and the interface it plugs into has an STP “Guard” configuration that puts the mode into a non-FWD state.
From using Bosons TSHOOT exam simulator, there is a lot of these “easy to jump to conclusions” that seem obvious, only to check the answer and find the solution is extremely more complex than you had answered.
Troubleshooting Layer 2 EtherChannels
Here is a list of possible issues that will be found on Layer 2 EtherChannels:
- Mismatched Port Configurations – All interfaces in the bundle / Port-Channel must match basically all settings (speed, duplex, trunk mode, native vlan, allowed vlans, port type, this goes for both Layer 2 and Layer 3 EtherChannels
- Mismatched EtherChannel Configuration – Refer to the below matrix for which modes will result in an EtherChannel forming:
- Inappropriate EtherChannel load-balancing algorithm – This can be an issue if the load-balancing or load distribution is configured to be dst-ip and all users are trying to hit a single server, as it will always choose one link in the bundle based on that configured distribution algorithm. Looking at it from the other way, if the load distribution on the server side is “src-ip” or “src-mac” it will take one link in that direction as well. So you will want to determine from which view point the traffic will be initiated from, and how best to set it load-balancing to evenly use all links in the bundle, the command “sh ether load-balance” will show the current config
EtherChannel troubleshooting commands
- “sh ether summary” – This will show the Po# (Port-Channel#) and all associated links with it, if they are operational, and codes to observe why they aren’t if not
- “sh int po#” – This will show the Port-Channel interface information just like a physical interface, however it will include information about which links are bundled and additional information pertaining to the EtherChannel
- “sh run int (int)” – To view details for a specific physical interface, or you can just do “sh run” and scroll down to view all configured interfaces for the EtherChannel to spot any mismatched configs
And that does it for STP and Layer 2 EtherChannel for TSHOOT exam day!
There are several things that can go wrong at Layer 2 with STP as you can see here, whereas Layer 2 EtherChannel is pretty straight forward with not much that can be really “hidden” outside of load distribution, so be careful before declaring DHCP or physical cabling the issue on exam day!