So let's go ahead and draw out a topology here. We have a triangle of three
switches
and we'll make that top switch our root in the network. And now up until this
video we've really just said, "All right, well, you know, one of these links is
probably gonna get blocked and so we'll just go ahead and block that." But the
question is, which one of these ports is going to go into a blocked state? And
for
that matter, could it actually be this link or this link? And the answer is yes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that matter, could it actually be this link or this link? And the answer is yes
.
Even though it's most likely going to end up down here, especially if all of
the
links are the same bandwidth, but at the same time we need to start to
understand what it is that we're looking for. One of the best ways to
understand this is to take a look at the fact that back when spanning tree
first
came out, there could have been a hub here. And this hub could have connected
to
hosts. And so in today's modern network, if we don't have this setup, we would WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
hosts. And so in today's modern network, if we don't have this setup, we would
say it doesn't matter whether it's this link or this link, just pick one. As
long
as there's no loop, we just need to block one of the ends of the links, of this
link.
But in the original era, these hosts would probably prefer to have the best
path. For example, if these two switches were maybe connected on some different
connection point, like maybe this is a hundred meg link, and this is a ten meg
link, well, we wouldn't want to just arbitrarily choose to block this side, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
link, well, we wouldn't want to just arbitrarily choose to block this side,
because now these hosts have to go through a much slower connection to get
out. Maybe in, if we think about it in modern terms, it would be like saying
this
is a gig link compared, well, I guess I got it. Yeah, no, that's right. A gig
on
this side and ten gig on that side. So we'd naturally not want to take the one
gig link compared to the ten gig link. And this was true back when we had ten
meg and one hundred meg links as well. And so this question of which one is
going to matter for a user experience perspective, and the answer of which one WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to matter for a user experience perspective, and the answer of which one
is going to be to say that we want to take the fastest path. So the only
question
is how do we go about calculating the fastest path? Well, fortunately, we have
a
way of advertising our costs. When we send out a BP to you, it's going to carry
a
lot of information, including the cost to the root. Now this cost is going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
lot of information, including the cost to the root. Now this cost is going to
be
tied to bandwidth. Again, we're looking for the fastest path, and that's
usually in
terms of megabits or gigabits per second. And so in our case, it's going to be
inversely proportional to the bandwidth, meaning that the higher the bandwidth,
the higher the speed, the lower the cost. And vice versa, if we have low
bandwidth
links, then that cost is going to be much higher. And so we want to find the
lowest
possible cost to the root. So since I'm advertising the cost to both sides, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
possible cost to the root. So since I'm advertising the cost to both sides, we
're
going to have a sense of who has the fastest path. Now the root is, well, it's
already the root. It has the best path of all. It's going to advertise a cost
of
zero down to these two switches. But when these switches receive the BP to you,
they're going to look at the speed of this link, and they're going to calculate
their own path to the root or the path cost. And so when we're looking at a
cost here, and we'll go into the details on this in a moment, a 10 meg
connection WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
connection
is going to have a cost of 100, and the 100 meg cost defaults to 19. So this
switch is going to see that, hey, I've got a cost of 19, I'm going to add these
two together, adding zero to anything, it's just itself. And so I've got a cost
of
19 on the left, and this switch has a cost of 100 to the root. So they're going
to advertise this to one another. And we're going to find that, okay, well, we
both
think that we've got a good path to the root, but I realized that I have the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
think that we've got a good path to the root, but I realized that I have the
worst
path. Since I have the worst path, I'm going to block, which means that you don
't
have to. And this means that our hosts now are going to hit up the switch that
does indeed have the best path to the root. Furthermore, let's say that we were
to add another switch all the way down here. And now we might find that we've
got, let's just say one gig links, we're starting to modernize our network and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
got, let's just say one gig links, we're starting to modernize our network and
we've upgraded the links to one gig. Well, one gig actually has a link cost of
four when it comes to spanning tree costs. And so what's going to happen here?
Well,
I'm going to receive my BPDUs down, and I'm going to look at the advertised
cost.
The advertised cost is 19. And so I'm going to view this as 23 cost. This
advertised cost is 100. So I'm going to view this as 104. And now I have two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
advertised cost is 100. So I'm going to view this as 104. And now I have two
choices. And as we might imagine, I'm going to favor the path going to the left
.
Because this forms a loop, I'm going to have to block one of these links. And I
'm
going to look at this and say, well, I far prefer the link on the left. Want to
go
through a 100 meg connection, even though it's not as fast as a gig, at least
it's
faster than 10 meg. And that's exactly how we figure this out. So cost of 23
beats a cost of 104. And so I block the link on the right. So here's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
beats a cost of 104. And so I block the link on the right. So here's the
important takeaway. Every switch is responsible for advertising its own cost
to the root. When a device receives that BPDU in order to figure out its cost,
it
has to add the link. So it's not the responsibility of the upstream device.
The root just says, hey, I've got a cost of zero. And I'm going to advertise
that
whether it's a on a 10 meg link or a 100 meg link or a 10 gigabit per second
link. I have a cost of zero because the root is me. And so when we advertise
down,
now that switch has to say, okay, that's great that you're telling me you have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
now that switch has to say, okay, that's great that you're telling me you have
a
cost of zero, but I received this on a 100 meg link, which means my cost is 19.
And if I have multiple BPDUs, I have to start comparing which one of those is
actually the best cost. So now the question is, how exactly are the cost and
the bandwidth tied together? I made a really weird claim, which is 100 meg is
equivalent to a spanning tree cost of 19. That seems rather random. Maybe the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
equivalent to a spanning tree cost of 19. That seems rather random. Maybe the
same thing down here that one gig is a spanning tree cost of four. I could
almost get on board with at least 10 meg being 100, they seem to be multiples
of
one another. But where do these numbers come from? Well, spanning tree has a
way
of calculating costs. In fact, it has two ways of calculating costs and we have
to understand both of them. We have short path costs and we have long path
costs.
Why are they called short and long? Well, we'll talk about that in a moment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Why are they called short and long? Well, we'll talk about that in a moment.
But for
right now, just understand that short path costs are not going to work very
well in
modern networks, because this really only handles speeds of up to 10 gigabit
per
second. Everything greater than 10 gig. 10 gig plus is all going to have the
exact same cost of one. So it doesn't matter if it's a 25 gig link, a 50 gig
link, 100 gig link, a terabit when that comes out. It's all going to have a
cost
of one, which is the problem with short path costs. But we do need to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of one, which is the problem with short path costs. But we do need to
understand
it as much as anything, because it's the default. And anything that's the
default
is oftentimes enabled in real world production networks. So let's go and talk
through this real quick. So a short path cost is going to not really have a
direct
correlation, like a mathematical operation we can run. Instead, we're just
going to
have values that match up to one another. So for example, we said a 10 meg
connection. This is a cost of 100. Now right away, we see a big problem here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
connection. This is a cost of 100. Now right away, we see a big problem here,
because the short path costs are going to use 16 bits to represent the total
cost
here. This is a 16 bit value. Well, if I do my binary math, 16 bits allows for
65,500 and, well, say zero to five 65, 535. So I have a lot of numbers here, a
lot of
numbers. And yet I look at this very slow link, and I've already gotten down to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
numbers. And yet I look at this very slow link, and I've already gotten down to
100.
So I've just scrapped 65,435 values that I could have used leading up to 10 meg
abits per second,
meaning that I'm possibly going to run out of values really quickly. I say,
well, no worries,
I've still got 100 values. So maybe a 100 meg could be 99, right? And then we
'll count down from there.
Well, unfortunately not, because we can still bundle 10 meg links together in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, unfortunately not, because we can still bundle 10 meg links together in
ether channels,
we have to have values that would represent a 20 meg connection and a 40 meg
connection.
And so a 100 meg connection actually gets the cost that we said earlier of 19.
Feels a little arbitrary, but what we're trying to do is find the balance here
of leaving values
in the middle while also giving us values underneath, we don't want to run out
of values.
And so we started to stretch this out a little bit. And so as we just kind of j
ot these out,
we've got one gig has a cost of four. At this point, we're basically out of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we've got one gig has a cost of four. At this point, we're basically out of
numbers,
10 gig has a cost of two, and anything, as we already said, 10 gig plus has a
cost of one.
And this is the big problem. If these links, let's just draw a quick topology
here.
So if all of these links, let's say we had 100 gig, whoops, that's 100 gig.
Let's write that one more time. 100 gig connections, 100 gig connection, 100
gig connection, 40 gig
connection. Yeah, this is a little bit of a weird network. But based on these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
connection. Yeah, this is a little bit of a weird network. But based on these
costs,
this is a problem. We might well block the link on the left, because as I
receive this,
we're going to say, Oh, I've got a cost of one to the root because 100 gig is
the same thing.
As say, like 40 gig or what have you, it's just a cost of one. And then they
advertise their
cost of one down. And this switch says, okay, well, this is a cost of one. And
this is a cost of one,
because 140, we can't tell the difference between the two. And so this is why
we might WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we might
arbitrarily end up blocking this link and using the 40 gig connection over the
100. Now, is this
a realistic topology? Not really, especially in a network with 100 gig links.
But at the same time,
we need to recognize that this is a flaw. And when we have data centers that
are built,
not just on 100 gig links, but 200 and 400 and even 800, as of the time of this
video,
we need spanning tree to be able to tell the difference among those links. So
that leads us
to the second way of performing path cost calculation. And it is known as long WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the second way of performing path cost calculation. And it is known as long
path costs.
It's called long path costs, because we're now going to use 32 bits. Now 32
bits has like
4.2 billion different values, which is great, except we kind of made sort of
the similar type
of deal here, where we very quickly start to use up all of those values. So for
example,
a 10 meg connection with long path costs already gets down to 2 million. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a 10 meg connection with long path costs already gets down to 2 million.
And say, okay, well, that's not too bad, but we just got rid of most of the 4.2
billion numbers
before we even got to 10 megabits per second. So a little surprising. But I
think the balance
here is trying to get down to human readable numbers as well, because something
like, you know,
3.2 billion as the value might not sit well with a lot of us. So either way, we
've got 10 meg
at 2 million. And here it does become a little bit nicer math. So 100 meg being
10 times better WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
10 times better
is going to be 10 times better from a numbers perspective. It's going to be 200
,000.
One gig is therefore going to be 20,000. And from here, we can keep going. 10
gig is going to be 20
or 2000 rather. And then 100 gig is going to be 200, one terabyte terabit per
second, I suppose,
is going to be 20. And yeah, maybe in the future, we'll realize that, you know, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is going to be 20. And yeah, maybe in the future, we'll realize that, you know,
maybe we should have
given ourselves more, more wiggle room. But by the time we get to 10 terabit
per second,
we have a cost of two, maybe we'll be done with spanning tree altogether by the
who knows.
But either way, we see that we're using more bits in a really just a different
way of counting.
Now, I might say, okay, well, what does this mean 16 bit versus 32 bit? The
interesting thing about
the BP DU is it actually carries 32 bits for the cost, no matter whether we're
using the short or
long path cost. It's not about the number of bits being carried by the BP DU, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
long path cost. It's not about the number of bits being carried by the BP DU,
it's just how many of
those bits are we actually using? So with the short path cost, we're only using
16 bits of those 32,
whereas with the long path cost, we're using all of them. And again, it's
really less of a, like,
where it's more of a representation of which of these values sets are we going
to use. Now, this is,
we might imagine, should be consistent throughout the whole network. And by
default, as we said,
Cisco devices, they use short path costs. So if I'm going to change to long WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Cisco devices, they use short path costs. So if I'm going to change to long
path costs, which I
absolutely should do the moment I see a link that's long faster than 10 gig, I
should absolutely
make sure my spanning tree long path cost is set to long. But as soon as I do
that on one switch,
I have to do that on all of the switches. Otherwise, we're going to be in a
disagreement about what
link costs are. They're compatible with one another, because the BP DU's can
still be read.
But they're going to interpret path costs very differently as they as these BP
DU's propagate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
DU's propagate
through the network. So always make sure we have the same setting throughout
the entire domain.
Now we do have one final option to be aware of with path costs. And that would
be the idea that
we can set them manually. We can set manual costs if we so desire. For example,
I could come over here
to the let's just say this link here. And I could just tell this switch, hey,
guess what? That's not
a cost of four. That's a cost of 40. For whatever reason, I really don't want WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a cost of four. That's a cost of 40. For whatever reason, I really don't want
that link to be used.
Maybe I know upstream is a 10 meg connection. I don't know. But I can override
that value,
say it's 40. Now it's going to see it as 140 as it comes in. So I do have that
capability. I can
set manual costs. It's generally not required and generally not a good idea.
But in the worst case
scenario, maybe one day I install a hundred terabit per second connection. I
have no idea.
But either way, maybe especially using short path costs, maybe until we migrate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But either way, maybe especially using short path costs, maybe until we migrate
to long path
costs, I could use manual costing to get around problems where we're blocking
the wrong links.
But this path costs coming back to the original conversation over here, it's
great that now we
understand how the path costs come together. What really matters most is
understanding how these
path costs get advertised, how we receive them and add our own link costs to
the path cost before
we advertise it. And importantly, that we're going to use that as the primary
criteria for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
criteria for
deciding which link we're going to block. We always want to block the slower
paths to the route.