1

“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

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
2

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

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
3

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:
4

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:
5

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!