In order to understand how a network starts to figure out which links should be
blocked
and who's the root of the network and all of these things, well, we're going to
need
a flow of information among the switches.
And this flow of information is going to come in the form of bridge protocol
data units or BPDUs.
The BPDUs are what's going to share the information.
And a lot of that information is going to have to do with my priority value. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And a lot of that information is going to have to do with my priority value.
It's going to have to do with my MAC address.
Once we know who the root is, it's going to be the cost to the root.
And I can share all of this information by encapsulating it into a bridge
protocol data unit and sending it out.
Now what's interesting about this is that at first we might find that we send
each other BPDUs,
but we're going to very quickly realize that one of these two BPDUs is better
than the other.
And so let's say that the root of the network is up here.
This would be called our root bridge. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This would be called our root bridge.
And as a result, the BPDU flowing downstream here, that would be known as the
superior BPDU.
We can have superior BPDUs, which imply usually a better priority or a better
cost to root or even a better MAC address in the case of ties.
Either way it's evaluated to be superior, and then the other one's going to be
known as inferior.
So the superior BPDU is going to take precedence over the inferior BPDU to the
point that the inferior BPDU doesn't continue to get sent. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
point that the inferior BPDU doesn't continue to get sent.
This means that our BPDUs are all one way.
We're going to send BPDUs down, and they're going to flow as if they're flowing
down a waterfall.
All right, BPDUs get sent downstream only.
And it's only going to happen in one direction, so they are unidirectional.
This is a very important part about the flow of information through the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is a very important part about the flow of information through the
spanning tree network.
And although this changes just a little bit later on with Rapid Spanning Tree,
Rapid Spanning Tree is still built on these fundamental principles,
which is that the BPDUs start with the root and they get propagated down to the
rest of the network.
Now what happens on this link down here?
Well, both of these switches, or bridges, depending on what we want to call
them, are going to receive a BPDU,
and they're going to want to send that BPDU further downstream. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and they're going to want to send that BPDU further downstream.
The question is, which direction is downstream?
Well, that is where we're going to land with this whole conversation, because
we see that there's a loop here,
and one of these ports must be placed into the blocking state.
Let's say it's this one here.
If that's in the blocking state, then we've prevented our loop, which is good.
But that also says, is that this BPDU that was getting sent upstream, this is
the inferior BPDU, and therefore we're not going to send it anymore. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the inferior BPDU, and therefore we're not going to send it anymore.
Even as I continue to get BPDUs from the root, I would not forward them this
direction.
Instead, the BPDUs are going to flow this way, continuously.
And so as I continue to get my BPDUs flowing through the network, we see how
exactly they end up flowing, again, from a downstream perspective.
Starting at the root, getting sent down to a switch, which then further sends
its own BPDU downstream, which has a lot of the same information, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
its own BPDU downstream, which has a lot of the same information,
but also has its own information like its own MAC address.
So it's not an exact copy of the BPDU that was received, but at the same time
we use this as a triggering mechanism.
To say, "Okay, now it's time for me to send my BPDU further downstream," which
will include the information about the root, but it's also going to include my
own MAC address, and so on and so forth.
Now the first question we have to ask in a spanning tree network is, "How do we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now the first question we have to ask in a spanning tree network is, "How do we
determine the root?"
This is going to come down to an election process.
Any switch in the network can become the root, and so we have to figure out
which one has the best configuration, essentially, to decide which one becomes
the root.
In order to do this, what we're going to do is we're going to compare what we
call bridge IDs.
The bridge ID consists of two values that are concatenated or essentially WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The bridge ID consists of two values that are concatenated or essentially
smashed together.
So we've got the priority value, and then we might put a colon here and say we
're also going to add our system MAC address.
Now the system MAC address is going to be determined by the operating system.
For example, Cisco might decide that this is a MAC address that is virtual and
they use it on their SBIs. It might be a reserved MAC address that's only used
as the system MAC, but every piece of hardware, even within Cisco's portfolio, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as the system MAC, but every piece of hardware, even within Cisco's portfolio,
and different operating systems will all have different ways of deciding what
their system MAC address is.
The best way to find that out is just to get on to a switch and run some show
commands and figure out what exactly that MAC address is.
So what's interesting about this is that we have the ability to also configure,
so this is configurable, a priority value.
This priority value ranges from 0 to 65, 535, and on Cisco devices for reasons WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This priority value ranges from 0 to 65, 535, and on Cisco devices for reasons
we'll see later must be in increments of 4096.
But zero is a value that we are able to use, so we could actually say zero, and
it's important to realize as part of this conversation, is that the lowest
value wins.
Now I said this is part of our LACP conversation, and I like to say it a lot WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now I said this is part of our LACP conversation, and I like to say it a lot
because it comes up a lot, but when we're trying to remember whether it's the
highest or the lowest wins for the vast majority of time,
this is not a hard rule that works every single time, but as a way to help us
remember, usually if we have a layer two protocol, it's the lower priority that
wins.
If we have a layer three protocol, for example, like OSPF or HSRP, then that's
usually going to be that the higher priority value wins. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
usually going to be that the higher priority value wins.
It's kind of interesting how that came together, I don't know how intentional
that was, but when we look at layer two protocols like LACP as well as spanning
tree, it happens to be that the lowest value wins, whereas all routing
protocols that I can think of off the top of my head,
as well as again, first-topper redundancy protocols and layer three protocols,
those all seem to like higher values.
Keep that in mind, and just when you're learning about a protocol, if you find
one that doesn't fit that model, then be sure to flag that otherwise if it
comes down to trying to remember which is which, this can be our rule of thumb, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
comes down to trying to remember which is which, this can be our rule of thumb,
understanding that there might be some exceptions out there.
So let's look at some examples here. When we look at Cisco's iOS default
configuration, the default priority value is going to be $32,768.
Now, when we're talking about these different priority values, usually we use a
shorthand shortcut, whatever we call it here, I'd say this is 32K, where K
stands for 1000, and so we see that it's about 32,000. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
stands for 1000, and so we see that it's about 32,000.
So we might say zero as a priority, we might say 4K for 4096, might say 8K and
12K and 16K, those are all estimates, but it does tie back to specific values
since they must be done or chosen on Cisco devices increments of 4096.
So either way, we say that all the default priority values on iOS are 32K. So
if I have two switches and I connect them together, the interesting thing when WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if I have two switches and I connect them together, the interesting thing when
we first tie two switches together is that first, we all think I am the root.
So I think I'm the root on the left, I think I'm the root on the right, and as
a result, we're both going to try to start sending BPDUs.
Now, one of these BPDUs is going to be superior, the other one's going to be
inferior, but what's interesting about this is they both have the same priority
value.
So how do we end up deciding which one is going to win as root? Well, that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So how do we end up deciding which one is going to win as root? Well, that
comes down to the second half of the priority or the bridge ID, rather, which
is the system MAC address, because MAC addresses must be unique in the
environment.
One of these is going to win, because one of them is going to be lower than the
other. So if they have basically the same MAC address except at the very end of
the MAC address, we have a 01 on the left and we have a 05 on the right. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the MAC address, we have a 01 on the left and we have a 05 on the right.
Well, 01 is lower than 05 and as a result, that's going to end up winning. So
we send the superior BPDU, which means once again the other switch, stop
sending BPDUs altogether, because we do not send BPDUs upstream.
Incidentally, if these BPDUs happen to cross at the same time, or if there's
one switch that's just kind of not doing what it's supposed to do and it keeps
sending BPDUs upstream, at that point the upstream device, knowing it has the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sending BPDUs upstream, at that point the upstream device, knowing it has the
superior BPDU, it's just going to completely ignore those.
So that switch on the left that first fires up, it says, "I'm the root, I think
I'm the root." And so I'm just going to start sending BPDUs. And again, if they
happen to cross at the same time and I receive the other BPDU, I'm going to
look at it and say, "No, I'm still good.
So I just keep sending them and I ignore inferior BPDUs." So inferior BPDUs, if
they are received on a link, where they're not expected to and they truly are
inferior, they will just be ignored.
Meanwhile, the switch on the right, which receives the superior BPDU here, is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Meanwhile, the switch on the right, which receives the superior BPDU here, is
going to ideally, in a proper scenario, realize that it's wrong, that this
device has a better bridge ID and therefore it's going to become the root.
Now, what if I wanted to change this? What if I want the device on the right to
be the root? Well, I can't change the MAC address. The MAC address is unique
and it's not configurable, whereas the priority is the configurable field.
And it matters more because it's in more significant, the more significant WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it matters more because it's in more significant, the more significant
digits, so to speak. It's in the, if we want to think about it, like this is
the ones in the tens column and this is the hundreds in the thousands column,
even one change in priority here is going to completely overrule
anything that happens down here. And so this is where I as the admin can get on
here and say, "Okay, you're not 32K anymore. Now you're 28K or you're 24K or
whatever value I want."
As long as it's a multiple of 4096. And the idea here is that I'm making it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As long as it's a multiple of 4096. And the idea here is that I'm making it
lower so that it's going to become the root.
At that point, this becomes the superior BPDU because it doesn't matter that I
have a higher MAC address anymore. What matters the most is I have a lower
priority value.
So that is how I control which device in the network is the root and I should
absolutely 100% be intentional about which switch on my network is the root
bridge.
Now, incidentally, what if we have a real world network that's established and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now, incidentally, what if we have a real world network that's established and
I've got a root switch, maybe it's in my distribution layer and I've got my
backup other distribution switch here, but ultimately I've got a bunch of
access layer switches.
And again, even in this scenario, I would only still have one root at a time
when we're running Cisco. It's on a Pervy Land basis, but either way I have a
single root in my spanning tree topology.
So I'm probably going to be blocking a lot of links like this to make sure that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm probably going to be blocking a lot of links like this to make sure that
the network stays loop free.
So that's well and good, but what happens if I bring a switch out and it's mis
configured? So maybe this root has an 8K priority value.
The switch on the right has 12K and all these other ones are using 32K, which
is the default setting on Cisco switches.
So if this root bridge goes down, this switch will take over as the root
because it's in better shape than any of these switches down here, and that's
exactly what we want.
In fact, it's what we want, but notice it does require for me to now say, "Hey, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In fact, it's what we want, but notice it does require for me to now say, "Hey,
guess what? I am the root because things have changed."
Something on the network is different and now I have the lowest ID and that's
because this root switch went down.
But what happens if this switch is configured with a priority of 4K and I
connect it up to, maybe I even connected it up to this switch over here?
What happens in this scenario? Well, I send my superior BPDU and this switch
says, "Oh, you're my upstream." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
says, "Oh, you're my upstream."
And therefore, I've got to completely change the way I view the network.
So this superior BPDU ends up getting propagated throughout the rest of the
network and now this switch does indeed become the root.
I'm no longer the root here because 8K loses to 4K.
This means that, yes, in a real-world environment, if we're not careful, I
could plug in a switch that's misconfigured and this could actually cause major
downtime on my network as the network converges over to the new root. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
downtime on my network as the network converges over to the new root.
Fortunately, we do have a way to protect against this. We have protection
mechanisms that we can deploy but we have to make sure that we do deploy them.
And this is why we're all sitting here learning about spanning tree because we
need to be able to apply this to the real-world networks that we manage and
understand that there's going to be configurable mechanisms that would go on to
our network and would make it so much more resilient, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
our network and would make it so much more resilient,
not just the intentional configuration of our priority values but also these
protection mechanisms we're going to end up talking about.
And when we fully tune our networks to be this way, then they can be very
stable and if we don't do it,
well then we run the risk of causing major outages by making misconfigurations.