WEBVTT

1
00:00.000 --> 00:04.440
This challenge is designed to bring everything together. We need to think about

2
00:04.440 --> 00:08.000
which switch becomes a root, how we handle the path costs.

3
00:08.000 --> 00:12.980
To the root, we need to think about tie-breakers, bridge IDs, port IDs, all of

4
00:12.980 --> 00:14.000
these things.

5
00:14.000 --> 00:18.000
So the primary question we have to answer here is which links get blocked.

6
00:18.000 --> 00:21.000
We do have a bonus question as well, and we'll get to that.

7
00:21.000 --> 00:25.120
But for the most part, the primary takeaway here is can we find which links

8
00:25.120 --> 00:27.000
would be blocked in this topology?

9
00:27.000 --> 00:31.330
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

9
00:27.000 --> 00:31.330
So the first thing we always have to start with is the root. Which of these

10
00:31.330 --> 00:32.000
bridges will be the root?

11
00:32.000 --> 00:36.880
We see several of the switches have the default value of 32K for their

12
00:36.880 --> 00:40.000
priorities, and we do see a couple up here that have the same value.

13
00:40.000 --> 00:45.310
4,000 is a great priority value. It's not the best. We could have assigned 0 to

14
00:45.310 --> 00:48.000
one of these, but 4,000 is the next best value.

15
00:48.000 --> 00:52.830
Since there's a tie, we now need to go to the MAC address. So the total bridge

16
00:52.830 --> 00:56.000
ID consists of 4K plus 0,0A is the MAC address.

17
00:56.000 --> 01:01.100
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

17
00:56.000 --> 01:01.100
And then over here, 4K and 0,0B. So which one of these MAC addresses is

18
01:01.100 --> 01:03.000
actually lower than the other?

19
01:03.000 --> 01:08.450
Well, A is lower than B. It's a hexadecimal perspective. A is a decimal of 10.

20
01:08.450 --> 01:10.000
B is a decimal of 11.

21
01:10.000 --> 01:17.500
And so A has the better bridge ID. 4,000 plus 0.0.A is the MAC address. So we

22
01:17.500 --> 01:21.560
found our root, and this is going to be mission critical for figuring

23
01:21.560 --> 01:23.000
everything else out from here.

24
01:23.000 --> 01:28.250
Now, we can probably immediately go one of two different directions. Try to

25
01:28.250 --> 01:30.000
figure out which of these will be blocked,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:28.250 --> 01:30.000
figure out which of these will be blocked,

26
01:30.000 --> 01:34.420
or we could look at each one of these and try to figure this one out. So let's

27
01:34.420 --> 01:37.000
just go ahead and go to these middle links here.

28
01:37.000 --> 01:40.780
We're going to need to figure out which ones should be blocked, because we have

29
01:40.780 --> 01:43.000
to evaluate which one is also the root port.

30
01:43.000 --> 01:46.730
And that's going to impact this decision down here. So let's look over here on

31
01:46.730 --> 01:50.000
the left and figure out which one of these links will end up being blocked.

32
01:50.000 --> 01:55.000
We're given some port IDs of 1 and 2 and 1 and 2. And so we have to think about

33
01:55.000 --> 01:57.000
which one of these is going to end up mattering,

34
01:57.000 --> 02:02.890
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

34
01:57.000 --> 02:02.890
because the path cost is going to be the same. If I'm advertising a BPDU down

35
02:02.890 --> 02:06.000
each one, we are going to see that the path cost is 0.

36
02:06.000 --> 02:12.030
I mean, I'm the root. I advertise that my path cost is 0. And so I see equal

37
02:12.030 --> 02:15.000
cost because it's coming in on a gig link here,

38
02:15.000 --> 02:20.000
which is a cost of 4, gig link here, which is a cost of 4. So no matter what,

39
02:20.000 --> 02:23.650
if I pick one of these links, I'm going to have a path cost of 4, and that's a

40
02:23.650 --> 02:24.000
tie.

41
02:24.000 --> 02:30.070
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

41
02:24.000 --> 02:30.070
So I have to go with a tiebreaker. Normally I'd look at the bridge ID, but

42
02:30.070 --> 02:32.760
since it's connected to the same switch, I'm going to have to go to the port ID

43
02:32.760 --> 02:33.000
.

44
02:33.000 --> 02:38.240
Remember, the port ID is a push concept. I'm pushing. I'm advertising the port

45
02:38.240 --> 02:42.000
ID down. And as long as there's no priority value configured,

46
02:42.000 --> 02:46.370
it's using the default of 128, I'm going to go with the lower port ID. This is

47
02:46.370 --> 02:48.000
our port number, I suppose.

48
02:48.000 --> 02:53.550
So the port number here being 1 is going to be preferred. And so I'm going to

49
02:53.550 --> 02:56.000
block this link on the right.

50
02:56.000 --> 03:01.650
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

50
02:56.000 --> 03:01.650
Notice, I am blocking my lower ID, but my port ID doesn't matter. It's an e

51
03:01.650 --> 03:04.000
gress concept. It's pushing down.

52
03:04.000 --> 03:09.480
I'm receiving this ingress on this port, and therefore the port ID does not

53
03:09.480 --> 03:12.000
matter from this perspective.

54
03:12.000 --> 03:14.610
Now, looking over here on the other side, we could say the same thing. Okay, I

55
03:14.610 --> 03:19.000
see a port ID of 1, so I'm probably going to favor this link, right?

56
03:19.000 --> 03:24.480
Well, be careful because we don't hit port ID until the very end. We want to

57
03:24.480 --> 03:28.000
look at the bridge ID first. So think about these tiebreakers.

58
03:28.000 --> 03:33.600
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

58
03:28.000 --> 03:33.600
I look at the bridge ID as part of this, and then I go to port ID. But what's

59
03:33.600 --> 03:36.000
the one that matters the absolute most?

60
03:36.000 --> 03:42.450
These are both arbitrary. What matters the absolute most is the path cost. This

61
03:42.450 --> 03:47.000
will always be the determining factor first and foremost.

62
03:47.000 --> 03:51.640
Only if there's a tie in the path cost, do we turn around or do we have to look

63
03:51.640 --> 03:54.000
at one of those arbitrary values?

64
03:54.000 --> 03:59.740
So once again, I am advertising a cost of zero this way from the root. And

65
03:59.740 --> 04:04.040
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

65
03:59.740 --> 04:04.040
therefore, I'm going to see this is a one gig connection, so I use a cost of

66
04:04.040 --> 04:05.000
four here.

67
04:05.000 --> 04:12.420
I say I have a cost of four, and I advertise that down. I say, "Hey, I've got a

68
04:12.420 --> 04:15.000
cost of four out this link, and I've got a cost of four out that link."

69
04:15.000 --> 04:21.200
Notice that we have a hundred meg and a one gig connection, and this didn't

70
04:21.200 --> 04:26.250
impact me sending a path cost. I advertise my cost regardless of what I'm

71
04:26.250 --> 04:27.000
sending on.

72
04:27.000 --> 04:32.430
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

72
04:27.000 --> 04:32.430
It's up to you to take that into account. So when I receive this, I see the

73
04:32.430 --> 04:37.000
four is advertised, and I see the four is advertised.

74
04:37.000 --> 04:42.260
Now, depending on whether you went short or long, it doesn't matter. I'm using

75
04:42.260 --> 04:47.000
short path costs here. 100 meg link is 19, a gig is four.

76
04:47.000 --> 04:50.310
If you went long path costs, that's perfectly fine. It won't change this

77
04:50.310 --> 04:54.470
scenario. It only changes it if we're talking about 40 gig links and 100 gig

78
04:54.470 --> 04:55.000
links.

79
04:55.000 --> 04:58.380
In this scenario, regardless of whether you went short or long, it doesn't

80
04:58.380 --> 05:02.020
matter if you went long, perfectly fine, probably more appropriate to go long,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
04:58.380 --> 05:02.020
matter if you went long, perfectly fine, probably more appropriate to go long,

81
05:02.020 --> 05:04.000
especially in modern networks,

82
05:04.000 --> 05:07.540
but just understand that the result is going to be the same. So I'm going to

83
05:07.540 --> 05:13.000
keep using short path costs here. I see that I'm advertised for.

84
05:13.000 --> 05:17.570
I'm going to add the link that it came in on. So I'm going to say, "Okay, so

85
05:17.570 --> 05:21.980
this way is four plus four, because it's another gig link. This way is four

86
05:21.980 --> 05:23.000
plus 19."

87
05:23.000 --> 05:27.120
So I'm going to see a path cost of 23 one way. I'm going to see a path cost of

88
05:27.120 --> 05:32.000
eight another way. And before I even get down into these tie breakers,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
05:27.120 --> 05:32.000
eight another way. And before I even get down into these tie breakers,

89
05:32.000 --> 05:36.000
I'm going to establish that one of these path costs is better than the other,

90
05:36.000 --> 05:40.020
and therefore I don't even need to look at the port IDs. I'm going to block the

91
05:40.020 --> 05:41.000
worst path cost.

92
05:41.000 --> 05:45.850
Yeah, this is the lower port ID, but that doesn't matter because we never got

93
05:45.850 --> 05:50.470
to that point. So I have now blocked two links, and I've also, by the way,

94
05:50.470 --> 05:53.000
established importantly, that I have my root port.

95
05:53.000 --> 05:57.770
I know which port to expect BPDUs on. It's always going to be receiving BPDUs

96
05:57.770 --> 06:03.270
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

96
05:57.770 --> 06:03.270
on my root port. I'm never going to take those BPDUs and establish that I've

97
06:03.270 --> 06:04.000
got path costs here.

98
06:04.000 --> 06:08.090
I've got a cost of four to the root on the left. Over here on the right, I've

99
06:08.090 --> 06:13.000
got a cost of eight to the root. And I'm going to advertise that down.

100
06:13.000 --> 06:25.610
So which link is switch E down here going to block? Well, they're both coming

101
06:25.610 --> 06:29.000
in on one gig, and we could start to say, hey, I should compare the bridge IDs,

102
06:29.000 --> 06:32.000
but the bridge IDs don't matter.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

102
06:29.000 --> 06:32.000
but the bridge IDs don't matter.

103
06:32.000 --> 06:39.230
We don't need to worry about the bridge ID because the costs are different. Now

104
06:39.230 --> 06:42.470
, be careful because if one of these was like a hundred meg link, then we'd

105
06:42.470 --> 06:44.000
still need to consider that.

106
06:44.000 --> 06:48.140
However, one gig and one gig, these are the same. I'm going to add four. I'm

107
06:48.140 --> 06:52.480
going to see a cost of eight going this way. I'm going to add four. I'm going

108
06:52.480 --> 06:59.100
to see a cost of twelve going this way, and I will block the longer path cost,

109
06:59.100 --> 07:01.000
or the worse off path cost.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
06:59.100 --> 07:01.000
or the worse off path cost.

110
07:01.000 --> 07:06.110
So this is how this network is going to shake out. We see the loop free top

111
07:06.110 --> 07:09.730
ology as I highlight these links. Maybe I'll highlight them in a different color

112
07:09.730 --> 07:10.000
.

113
07:10.000 --> 07:16.830
So we've got a link here that's active, a link here that's active, a link here,

114
07:16.830 --> 07:19.000
and a link down here.

115
07:19.000 --> 07:23.330
That looks loop free to me. I'm blocking on those other three links that I didn

116
07:23.330 --> 07:28.030
't color in. And so that would be the answer to our big question of which links

117
07:28.030 --> 07:30.000
in the network get blocked.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
07:28.030 --> 07:30.000
in the network get blocked.

118
07:30.000 --> 07:37.370
Now, our bonus question, which is kind of fun, is saying, "Hey, over here,

119
07:37.370 --> 07:43.000
switch C, how would I configure switch C to change this?"

120
07:43.000 --> 07:48.070
Now, remember, it's very easy to immediately go to port IDs when we're talking

121
07:48.070 --> 07:51.000
about two connections to the same switch.

122
07:51.000 --> 07:56.250
But I have to configure switch A port IDs in order to push down and advertise

123
07:56.250 --> 08:00.000
down different port IDs and change the blocking.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

123
07:56.250 --> 08:00.000
down different port IDs and change the blocking.

124
08:00.000 --> 08:05.820
So what could I do? Well, instead of changing port IDs down here, which wouldn

125
08:05.820 --> 08:10.000
't matter because it's ingress, what is ingress is path cost.

126
08:10.000 --> 08:16.610
So I can get in here and I can change my path cost. So remember, one gig is

127
08:16.610 --> 08:22.000
four, one gig is four. I'm currently blocking this side on the right.

128
08:22.000 --> 08:26.960
I either need to make this more attractive by lowering the number so I could

129
08:26.960 --> 08:31.000
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

129
08:26.960 --> 08:31.000
set a manual cost of two here, something like that, or even three would work.

130
08:31.000 --> 08:35.500
That'd be fine. And then we'd block the other side because four is worse than

131
08:35.500 --> 08:36.000
two.

132
08:36.000 --> 08:41.130
Or I could come over here and say this is a cost of five or above. At that

133
08:41.130 --> 08:47.070
point, I would say that, okay, well, even though you have a lower port ID, I

134
08:47.070 --> 08:52.150
don't even look at the port ID, I don't look at any of these, I stay here at

135
08:52.150 --> 08:53.000
path cost.

136
08:53.000 --> 08:58.000
And so a four or a two is going to be preferred to anything five or higher.

137
08:58.000 --> 09:02.620
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

137
08:58.000 --> 09:02.620
So always remember, path cost always wins the day. It's very easy for us to

138
09:02.620 --> 09:07.380
immediately jump into tiebreaker scenarios, look at bridge IDs, look at port

139
09:07.380 --> 09:08.000
IDs.

140
09:08.000 --> 09:12.650
Path cost is what matters the most. So as we go through it, topologies like

141
09:12.650 --> 09:17.190
this, what I'd encourage you to do is draw out your own topologies, give

142
09:17.190 --> 09:21.540
yourself some priorities and MAC addresses and link bandwidths, and figure out,

143
09:21.540 --> 09:24.000
calculate out for yourself, which of the links would be blocking.

144
09:24.000 --> 09:28.000
If you have an actual lab environment, you can lab it up and compare the two

145
09:28.000 --> 09:32.140
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

145
09:28.000 --> 09:32.140
and make sure that the links that are blocking are the links that you expected

146
09:32.140 --> 09:33.000
to block.

147
09:33.000 --> 09:36.670
Otherwise, just going through the examples over and over again are what's

148
09:36.670 --> 09:39.000
really going to help drive home these points.

149
09:39.000 --> 09:43.710
So feel free to maybe mark this skill and come back to it later and make sure

150
09:43.710 --> 09:48.420
that you can still go through this exact topology and get the right answer,

151
09:48.420 --> 09:51.000
remembering how all of this comes together.

152
09:51.000 --> 09:53.900
I hope this has been informative for you and I'd like to thank you for viewing.