This challenge is designed to bring everything together. We need to think about
which switch becomes a root, how we handle the path costs.
To the root, we need to think about tie-breakers, bridge IDs, port IDs, all of
these things.
So the primary question we have to answer here is which links get blocked.
We do have a bonus question as well, and we'll get to that.
But for the most part, the primary takeaway here is can we find which links
would be blocked in this topology?
So the first thing we always have to start with is the root. Which of these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the first thing we always have to start with is the root. Which of these
bridges will be the root?
We see several of the switches have the default value of 32K for their
priorities, and we do see a couple up here that have the same value.
4,000 is a great priority value. It's not the best. We could have assigned 0 to
one of these, but 4,000 is the next best value.
Since there's a tie, we now need to go to the MAC address. So the total bridge
ID consists of 4K plus 0,0A is the MAC address.
And then over here, 4K and 0,0B. So which one of these MAC addresses is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then over here, 4K and 0,0B. So which one of these MAC addresses is
actually lower than the other?
Well, A is lower than B. It's a hexadecimal perspective. A is a decimal of 10.
B is a decimal of 11.
And so A has the better bridge ID. 4,000 plus 0.0.A is the MAC address. So we
found our root, and this is going to be mission critical for figuring
everything else out from here.
Now, we can probably immediately go one of two different directions. Try to
figure out which of these will be blocked, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
figure out which of these will be blocked,
or we could look at each one of these and try to figure this one out. So let's
just go ahead and go to these middle links here.
We're going to need to figure out which ones should be blocked, because we have
to evaluate which one is also the root port.
And that's going to impact this decision down here. So let's look over here on
the left and figure out which one of these links will end up being blocked.
We're given some port IDs of 1 and 2 and 1 and 2. And so we have to think about
which one of these is going to end up mattering,
because the path cost is going to be the same. If I'm advertising a BPDU down WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because the path cost is going to be the same. If I'm advertising a BPDU down
each one, we are going to see that the path cost is 0.
I mean, I'm the root. I advertise that my path cost is 0. And so I see equal
cost because it's coming in on a gig link here,
which is a cost of 4, gig link here, which is a cost of 4. So no matter what,
if I pick one of these links, I'm going to have a path cost of 4, and that's a
tie.
So I have to go with a tiebreaker. Normally I'd look at the bridge ID, but WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I have to go with a tiebreaker. Normally I'd look at the bridge ID, but
since it's connected to the same switch, I'm going to have to go to the port ID
.
Remember, the port ID is a push concept. I'm pushing. I'm advertising the port
ID down. And as long as there's no priority value configured,
it's using the default of 128, I'm going to go with the lower port ID. This is
our port number, I suppose.
So the port number here being 1 is going to be preferred. And so I'm going to
block this link on the right.
Notice, I am blocking my lower ID, but my port ID doesn't matter. It's an e WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Notice, I am blocking my lower ID, but my port ID doesn't matter. It's an e
gress concept. It's pushing down.
I'm receiving this ingress on this port, and therefore the port ID does not
matter from this perspective.
Now, looking over here on the other side, we could say the same thing. Okay, I
see a port ID of 1, so I'm probably going to favor this link, right?
Well, be careful because we don't hit port ID until the very end. We want to
look at the bridge ID first. So think about these tiebreakers.
I look at the bridge ID as part of this, and then I go to port ID. But what's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I look at the bridge ID as part of this, and then I go to port ID. But what's
the one that matters the absolute most?
These are both arbitrary. What matters the absolute most is the path cost. This
will always be the determining factor first and foremost.
Only if there's a tie in the path cost, do we turn around or do we have to look
at one of those arbitrary values?
So once again, I am advertising a cost of zero this way from the root. And
therefore, I'm going to see this is a one gig connection, so I use a cost of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
therefore, I'm going to see this is a one gig connection, so I use a cost of
four here.
I say I have a cost of four, and I advertise that down. I say, "Hey, I've got a
cost of four out this link, and I've got a cost of four out that link."
Notice that we have a hundred meg and a one gig connection, and this didn't
impact me sending a path cost. I advertise my cost regardless of what I'm
sending on.
It's up to you to take that into account. So when I receive this, I see the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's up to you to take that into account. So when I receive this, I see the
four is advertised, and I see the four is advertised.
Now, depending on whether you went short or long, it doesn't matter. I'm using
short path costs here. 100 meg link is 19, a gig is four.
If you went long path costs, that's perfectly fine. It won't change this
scenario. It only changes it if we're talking about 40 gig links and 100 gig
links.
In this scenario, regardless of whether you went short or long, it doesn't
matter if you went long, perfectly fine, probably more appropriate to go long, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
matter if you went long, perfectly fine, probably more appropriate to go long,
especially in modern networks,
but just understand that the result is going to be the same. So I'm going to
keep using short path costs here. I see that I'm advertised for.
I'm going to add the link that it came in on. So I'm going to say, "Okay, so
this way is four plus four, because it's another gig link. This way is four
plus 19."
So I'm going to see a path cost of 23 one way. I'm going to see a path cost of
eight another way. And before I even get down into these tie breakers, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
eight another way. And before I even get down into these tie breakers,
I'm going to establish that one of these path costs is better than the other,
and therefore I don't even need to look at the port IDs. I'm going to block the
worst path cost.
Yeah, this is the lower port ID, but that doesn't matter because we never got
to that point. So I have now blocked two links, and I've also, by the way,
established importantly, that I have my root port.
I know which port to expect BPDUs on. It's always going to be receiving BPDUs
on my root port. I'm never going to take those BPDUs and establish that I've WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on my root port. I'm never going to take those BPDUs and establish that I've
got path costs here.
I've got a cost of four to the root on the left. Over here on the right, I've
got a cost of eight to the root. And I'm going to advertise that down.
So which link is switch E down here going to block? Well, they're both coming
in on one gig, and we could start to say, hey, I should compare the bridge IDs,
but the bridge IDs don't matter. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
but the bridge IDs don't matter.
We don't need to worry about the bridge ID because the costs are different. Now
, be careful because if one of these was like a hundred meg link, then we'd
still need to consider that.
However, one gig and one gig, these are the same. I'm going to add four. I'm
going to see a cost of eight going this way. I'm going to add four. I'm going
to see a cost of twelve going this way, and I will block the longer path cost,
or the worse off path cost. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or the worse off path cost.
So this is how this network is going to shake out. We see the loop free top
ology as I highlight these links. Maybe I'll highlight them in a different color
.
So we've got a link here that's active, a link here that's active, a link here,
and a link down here.
That looks loop free to me. I'm blocking on those other three links that I didn
't color in. And so that would be the answer to our big question of which links
in the network get blocked. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in the network get blocked.
Now, our bonus question, which is kind of fun, is saying, "Hey, over here,
switch C, how would I configure switch C to change this?"
Now, remember, it's very easy to immediately go to port IDs when we're talking
about two connections to the same switch.
But I have to configure switch A port IDs in order to push down and advertise
down different port IDs and change the blocking. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
down different port IDs and change the blocking.
So what could I do? Well, instead of changing port IDs down here, which wouldn
't matter because it's ingress, what is ingress is path cost.
So I can get in here and I can change my path cost. So remember, one gig is
four, one gig is four. I'm currently blocking this side on the right.
I either need to make this more attractive by lowering the number so I could
set a manual cost of two here, something like that, or even three would work. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
set a manual cost of two here, something like that, or even three would work.
That'd be fine. And then we'd block the other side because four is worse than
two.
Or I could come over here and say this is a cost of five or above. At that
point, I would say that, okay, well, even though you have a lower port ID, I
don't even look at the port ID, I don't look at any of these, I stay here at
path cost.
And so a four or a two is going to be preferred to anything five or higher.
So always remember, path cost always wins the day. It's very easy for us to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So always remember, path cost always wins the day. It's very easy for us to
immediately jump into tiebreaker scenarios, look at bridge IDs, look at port
IDs.
Path cost is what matters the most. So as we go through it, topologies like
this, what I'd encourage you to do is draw out your own topologies, give
yourself some priorities and MAC addresses and link bandwidths, and figure out,
calculate out for yourself, which of the links would be blocking.
If you have an actual lab environment, you can lab it up and compare the two
and make sure that the links that are blocking are the links that you expected WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and make sure that the links that are blocking are the links that you expected
to block.
Otherwise, just going through the examples over and over again are what's
really going to help drive home these points.
So feel free to maybe mark this skill and come back to it later and make sure
that you can still go through this exact topology and get the right answer,
remembering how all of this comes together.
I hope this has been informative for you and I'd like to thank you for viewing.