Spanning Tree Protocol Path Selection
“Spanning Tree Protocol” – Just the mere mention of such a massive topic in light of CCIE studies feels a little intimidating. I’m sure I don’t have to tell you, this is a very core concept. A VERY solid understanding of STP is needed for even junior-level network admins, let alone CCIE candidates. It’s easy to think of STP as something that “just works.” Indeed, it usually does, especially when left alone. But when we’re looking to design or engineer our STP environment, it’s absolutely crucial to understand how it works. So, as Jimmy Ray would say, “Let’s get to the meat and taters of this thing.” Here’s our exam blueprint topic for today:
2.1.f Implement and troubleshoot spanning-tree
2.1.f (ii) Switch priority, port priority, path cost, STP timers
I’ve skipped to the second listed topic in STP, as I feel that covering Switch priority, port priority, path cost and STP timers is a better place to start than to dive right into PVST+/RSTP/MST. I’ll come back to covering the differences and interoperability of the three main “flavors” of STP in our next topic.
Let’s go over those timers first. The MaxAge timer, which is 20 seconds by default, is essentially the amount of time that a switch will hold onto a BPDU before it assumes that the BPDU is no longer valid. The HelloTime is the frequency with which BPDUs are sent, and is 2 seconds by default. The ForwardDelay timer is the amount of time that the switch waits in each of its states before moving onto its next state as it goes from blocking to listening to learning to forwarding, and is 15 seconds by default. Also remember that these STP timers are decided by the Root Bridge. If these settings are configured on other switches in the STP domain, those values are ignored unless the switch becomes the root bridge for the VLAN. If you’re interested in a great writeup about these timers and how to optimize them in your STP environment, please do yourself a favor and read this article: http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/19120-122.html#tune To discover the what those values are, we can simply use the show spanning-tree command.
Understanding the process of deciding which ports will forward and which ones will block is a concept that needs to be mastered before we go any further. Most documentation sources will present this as a three-step process, and each of these three steps has a selection criteria. (That process being “Determine the root bridge, then determine the root ports, then determine designated ports on each segment) I understand why it’s taught that way. It’s absolutely true, and probably a little easier to present the information by treating each of those as an individual step. For myself, I’ve found that it’s easier to remember and understand this process as I’ve outlined below. I’ve written this a little differently than I’ve ever seen the process described anywhere else. So, to put it simply: Read it the way I’ve presented it, and if it helps you understand the concept better, than I’m glad to have shared some enlightenment. If not, you can hardly be faulted for not learning the same way that I do… and trust that there are a billion different write-ups out there that can help you. Google “Spanning-Tree” and you’ll be presented with an embarrassment of riches in learning opportunities. I won’t be offended if you find one of them an easier path to understanding.
Most documentation sources present that 3-step criteria, then ask you to memorize a somewhat unique process for how each of those three things is determined. To be fair, that’s probably the easier way of learning about how the process works. However, once you get familiar with the process, you see that the selection criteria is very similar for all three of these steps – the order in which different values are compared is mostly the same, there are just a few times where we have to remember some small exceptions. These exceptions are pretty obvious in most cases though. So, while it might be easier to learn STP path selection in these smaller chunks, I’ve found it easier to remember how it works by simply keeping in mind one single criteria set, and keeping in mind the ways in which this single criterion are applied at each step of the process.
Below, I’ll list the order of values that are compared to determine both root bridge election and path selection. Lower values are always better.
For starters, remember that “cost is king.” When determining the root bridge however, we really can’t use cost as a selection criteria, because the cost to the root bridge can’t be determined until the root bridge itself is determined. It’s also not used in determining the designated port on a LAN segment. Again, this makes sense, because otherwise, if cost were taken into account, the designated port would always be the port closest to the root bridge, and you would lost the ability to configure the DP. So, for me, it’s easier to remember the selection criteria, and just apply this same process to each of those three steps, keeping in mind the times when each rule does and does not apply. So, while the most important of these metrics, cost is only used while determining the root ports that each switch will use.
1) Cost (ignored for Root Bridge election, and for selecting designated ports)
Next, the “Bridge ID” is compared. The Bridge ID is simply three different values that are combined into one. To further complicate things, two of those three things are combined into one in modern switches. We’ll cover these in more depth later.
2) Extended System ID, which is made up of two values
a) 4-bit bridge priority, in multiples of 4096
b) VLAN Number
3) MAC Address of the switch
At this point, a root bridge will be selected, so the following rules only apply to the election of root ports and designated ports, but since the order still applies, I’m keeping this as a single ordered list.
4) Port priority
5) Advertised Port ID
By this point, you’ll normally have elected all designated ports. One exception to that rule though, is if you have multiple ports on your switch that receive the same BPDUs. This would be rare. Likely, it means that you have two different switch ports plugged into a hub or a switch that does not speak STP. In these cases, the locally numbered port # is used at the tiebreaker.
6) Local port ID (rarely used)
For port priority and Port ID, remember that it is the advertised values that are taken into consideration. Lowering the port priority on a switch will cause the switch to ADVERTISE a lower value to its neighbor. This, in turn will make the NEIGHBORING switch more likely to select a particular link as a designated port. Also, remember that steps 2 and 3 in the above process will consider different values at different times. When the root bridge is being elected, those steps compare the values of the “Root Bridge” that is being advertised. After the root bridge is elected, when switches start to decide which ports become root and designated ports, they compare the neighbor’s bridge ID, rather than the root’s bridge ID.
Remember that when you configure the spanning-tree cost on a link, you are not telling the switch “advertise this as your cost to reach the root.” Rather, you are telling the switch “add this value to the INCOMING advertsed cost of received BPDUs.” Again, this is a point that is easily confused, as one might think that they can manipulate a link’s cost, then check the neighboring switch, only to discover that the cost that the neighbor sees has been unchanged. The changes would only be seen on switches that are further downstream, not an upstream neighbor toward the root.
Each port stores a copy of the most superior BPDU, whether it is its own or one that it has received, and the port will constantly monitor the BPDU’s expiration time, which is MaxAge-MessageAge. The MessageAge value is not a configured setting. Rather, it is a hop count that is incremented by 1 by each successive bridge. While in PVST mode, only designated ports continue sending BPDUs, as any other port would be sending an inferior BPDU. However, should thate BPDU expire, those non-designated ports will again begin sending, and going through the election process. Spanning-tree goes through this process with every single received BPDU.
Let’s also make sure we understand that “system ID extension” concept. Originally, BPDUs had a 2-Byte Priority field and a 6-byte System ID (MAC Address). Later, the standard was revised so that the priority field is now only 4 bits of that same 2-byte field, and the standard allowed the remaining 12 bits of the original priority field to be used for the system ID extension. This shrinking of the priority field into a 4-bit field is the reason that STP priority values are displayed in multiples of 4096, as it allows the same priority values in the domain, while maintaining backward-compatibility with legacy spanning-tree. The system ID extension reflects the VLAN number, and is used to identity the VLAN that the BPDU is being advertised for.
A few show commands to keep in mind for Spanning-Tree verification are the show spanning-tree root command:
show spanning-tree vlan # command:
and show spanning-tree interface # commands.
These are likely the three that you will use the most in your troubleshooting. We’ll briefly cover two more though. First, the show spanning-tree summary command is a great place to start, especially if you suspect layer 2 issues on a switch, but don’t know anything about how spanning-tree is configured:
Finally, when you need to see most everything there is to know about the spanning-tree process, use the show spanning-tree detail command.
For configuration – set the bridge priority with the global config spanning-tree vlan # priority # command, and set interface cost with the interface spanning-tree cost value command, and set interface priority with the spanning-tree port-priority value command.
With that, we have a great foundation for Spanning-Tree. Thanks again for stopping by! Stay tuned for the rest of our deep dive into Spanning-Tree Protocol!