WEBVTT

1
00:00.000 --> 00:05.440
All right, so we are going to look at a topology here and apply what we've

2
00:05.440 --> 00:06.280
learned, not only

3
00:06.280 --> 00:10.100
about PBST+ but also as we see in the challenge, we're going to hit up some

4
00:10.100 --> 00:11.720
timer conversations.

5
00:11.720 --> 00:14.980
And the way the challenge was worded made it so we have to do a little bit of

6
00:14.980 --> 00:15.480
math on

7
00:15.480 --> 00:19.620
some of these timers as well as rely on a good understanding of what the timers

8
00:19.620 --> 00:19.840
are

9
00:19.840 --> 00:22.400
present in order to figure it all out.

10
00:22.400 --> 00:24.600
So let's go and start with the PBST+ element.

11
00:24.600 --> 00:30.050
This is a huge part of not just legacy PBST+ but even in the modern network
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:24.600 --> 00:30.050
This is a huge part of not just legacy PBST+ but even in the modern network

12
00:30.050 --> 00:30.840
with rapid

13
00:30.840 --> 00:32.600
PBST+.

14
00:32.600 --> 00:37.640
Most of our Cisco networks in the real world still rely on rapid PBST+ and all

15
00:37.640 --> 00:38.560
of the principles

16
00:38.560 --> 00:39.560
are the same.

17
00:39.560 --> 00:43.420
As we've said several times, we're learning the original PBST+ because for the

18
00:43.420 --> 00:44.640
most part,

19
00:44.640 --> 00:47.200
a lot of the same principles still apply to rapid.

20
00:47.200 --> 00:50.360
And so at that point, we just need to understand what the differences are.

21
00:50.360 --> 00:55.270
The splitting of the VLANs, the creating a topology per VLAN, that is all

22
00:55.270 --> 00:55.800
exactly the

23
00:55.800 --> 01:01.800
same in rapid PBST+ and so it still continues to apply in modern networks today
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:55.800 --> 01:01.800
same in rapid PBST+ and so it still continues to apply in modern networks today

24
01:01.800 --> 01:01.840
.

25
01:01.840 --> 01:05.830
So we say in the challenge that the switches have been configured with PBST+

26
01:05.830 --> 01:06.400
and we're

27
01:06.400 --> 01:11.760
to optimize leak efficiency by assigning root priorities for each VLAN.

28
01:11.760 --> 01:15.320
So we're given a list of active VLANs and we do some math there.

29
01:15.320 --> 01:17.920
We say, okay, so there's seven VLANs.

30
01:17.920 --> 01:24.270
So I might decide to split it up so that odds go on one side and the evens go

31
01:24.270 --> 01:25.160
on the other.

32
01:25.160 --> 01:29.650
In fact, let's go ahead and write that in a different color so we can kind of

33
01:29.650 --> 01:30.320
track the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

33
01:29.650 --> 01:30.320
track the

34
01:30.320 --> 01:32.200
different topologies.

35
01:32.200 --> 01:41.200
So the odds are going to be VLANs 11, 13, 15 and 17 and the evens are 12, 14

36
01:41.200 --> 01:42.560
and 16.

37
01:42.560 --> 01:45.520
Now right away, we might notice a little bit of a nuance here.

38
01:45.520 --> 01:50.560
We see that we've got four VLANs for the odds and only three for the evens.

39
01:50.560 --> 01:54.490
Does that mean that the odds are going to, that we've got more traffic across

40
01:54.490 --> 01:55.200
the different

41
01:55.200 --> 01:59.140
VLANs and if every VLAN has the exact same amount of traffic, that's what it

42
01:59.140 --> 02:00.040
means.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

42
01:59.140 --> 02:00.040
means.

43
02:00.040 --> 02:03.270
And the reality is that we have to deal with the number of VLANs that we

44
02:03.270 --> 02:04.320
actually have.

45
02:04.320 --> 02:08.080
We can only build topologies based on VLANs, nothing else.

46
02:08.080 --> 02:13.110
Now if we run a traffic analysis and we realize that all of these VLANs have

47
02:13.110 --> 02:14.120
less traffic

48
02:14.120 --> 02:19.720
on them than the evens, and maybe this is actually 80% of what's happening over

49
02:19.720 --> 02:20.040
on the

50
02:20.040 --> 02:23.280
even side relative to that.

51
02:23.280 --> 02:26.690
So just because we're looking at it from the perspective of having a different

52
02:26.690 --> 02:27.080
number

53
02:27.080 --> 02:32.000
of VLANs doesn't necessarily mean that we actually have more traffic, although
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:27.080 --> 02:32.000
of VLANs doesn't necessarily mean that we actually have more traffic, although

54
02:32.000 --> 02:32.760
certainly

55
02:32.760 --> 02:37.200
it could mean that we have more traffic again if all of the VLANs have about

56
02:37.200 --> 02:38.480
the same amount.

57
02:38.480 --> 02:41.980
The reality is that in most of our modern networks, we're dealing with a whole

58
02:41.980 --> 02:42.480
lot more

59
02:42.480 --> 02:44.280
than seven VLANs.

60
02:44.280 --> 02:47.280
We might have 50 or 60 something like that.

61
02:47.280 --> 02:50.810
And at that point, if we're off by one or two, it's probably not that big of a

62
02:50.810 --> 02:51.320
deal.

63
02:51.320 --> 02:55.890
Furthermore, this conversation of odds versus evens, that is how a lot of

64
02:55.890 --> 02:56.960
organizations

65
02:56.960 --> 03:01.780
do it, but we should keep an eye on whether the traffic flows are about the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

65
02:56.960 --> 03:01.780
do it, but we should keep an eye on whether the traffic flows are about the

66
03:01.780 --> 03:02.400
same.

67
03:02.400 --> 03:05.680
If they're within 20 or 30% of each other, that's probably fine.

68
03:05.680 --> 03:09.460
I mean, we're trying to activate all of these links and not necessarily make it

69
03:09.460 --> 03:09.880
so that

70
03:09.880 --> 03:12.880
they have the exact same load on them.

71
03:12.880 --> 03:17.150
But at the same time, if we find out that let's say there's two VLANs on the

72
03:17.150 --> 03:18.800
even side that

73
03:18.800 --> 03:22.970
are an enormous amount of traffic, well, maybe we should move one of those over

74
03:22.970 --> 03:23.600
to the other

75
03:23.600 --> 03:26.240
side and not just stick with even an odds.

76
03:26.240 --> 03:29.000
Again, that's a little bit of a real world conversation.

77
03:29.000 --> 03:34.480
In our example here, however, you chose to split these up is perfectly fine.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

77
03:29.000 --> 03:34.480
In our example here, however, you chose to split these up is perfectly fine.

78
03:34.480 --> 03:37.680
And given that we don't know traffic flows, I would say that the right answer

79
03:37.680 --> 03:38.200
would just

80
03:38.200 --> 03:42.160
involve having four on one side and three on the other.

81
03:42.160 --> 03:43.840
So let's just roll with that.

82
03:43.840 --> 03:48.480
So the idea here is that we are splitting these up.

83
03:48.480 --> 03:50.480
Now, what does that mean we're splitting them up?

84
03:50.480 --> 03:53.760
What it means is that we're going to assign root priorities.

85
03:53.760 --> 03:59.360
So I'm going to say let's just choose 40, 96, something lower than the default.

86
03:59.360 --> 04:03.560
Remember the default is 32K for Cisco switches.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
03:59.360 --> 04:03.560
Remember the default is 32K for Cisco switches.

87
04:03.560 --> 04:07.800
And we want to leave switch three sitting there at 32K.

88
04:07.800 --> 04:12.470
So maybe I'm going to say 4096 as the priority, but keep in mind with Cisco,

89
04:12.470 --> 04:13.360
everything's

90
04:13.360 --> 04:14.920
a per VLAN configuration.

91
04:14.920 --> 04:21.820
So I have to configure 4096 as the root priority for VLAN 11, but also VLAN 13

92
04:21.820 --> 04:24.600
and 15 and 17.

93
04:24.600 --> 04:28.680
And then over on the even side, I'd probably also do 40, 96, but this time it's

94
04:28.680 --> 04:29.240
for VLANs

95
04:29.240 --> 04:32.760
12 and 14 and 16.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
04:29.240 --> 04:32.760
12 and 14 and 16.

96
04:32.760 --> 04:34.400
So here's a question.

97
04:34.400 --> 04:39.500
Even that VLAN 12, let's just say does exist here on switch one, what would the

98
04:39.500 --> 04:40.200
priority

99
04:40.200 --> 04:42.760
be for VLAN 12?

100
04:42.760 --> 04:46.920
Well we might just say, well, let's leave it at the default of 32K.

101
04:46.920 --> 04:51.930
But keep in mind that switch three is already defaulting the 32K for everything

102
04:51.930 --> 04:52.120
.

103
04:52.120 --> 04:55.270
Instead you state operation, it doesn't matter because switch two is going to

104
04:55.270 --> 04:55.800
be the root.

105
04:55.800 --> 04:59.360
But what happens if switch two is lost for some reason?

106
04:59.360 --> 05:02.720
And what happens if switch three has a better MAC address?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
04:59.360 --> 05:02.720
And what happens if switch three has a better MAC address?

107
05:02.720 --> 05:06.880
Then it would win the election and it would become the root for VLAN 12.

108
05:06.880 --> 05:10.630
In a lot of our, again, real world topologies, we'd look at that and say, okay,

109
05:10.630 --> 05:11.080
I've got

110
05:11.080 --> 05:12.880
two distributions switches for a reason.

111
05:12.880 --> 05:16.330
I really want switch one to take over as root, which means that rather than

112
05:16.330 --> 05:17.400
leaving it as

113
05:17.400 --> 05:24.400
32K here, I'd probably want to make it something like 8K, which is 8192.

114
05:24.400 --> 05:29.430
So at that point, if switch two goes down, now switch one is going to win out

115
05:29.430 --> 05:30.240
over switch
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

115
05:29.430 --> 05:30.240
over switch

116
05:30.240 --> 05:33.040
three even if the MAC address is worse.

117
05:33.040 --> 05:37.250
And so that's usually how we do it again in a real world scenario is I would

118
05:37.250 --> 05:37.720
look at

119
05:37.720 --> 05:44.450
this and in general, just say that the evens are going to be 8K on switch one,

120
05:44.450 --> 05:45.360
making it,

121
05:45.360 --> 05:47.600
if you want to call it the backup root, that's fine.

122
05:47.600 --> 05:49.760
That's not an official technical term.

123
05:49.760 --> 05:52.860
But logically that would make sense because it will take over as root in the

124
05:52.860 --> 05:53.280
event of

125
05:53.280 --> 05:54.520
a failure.

126
05:54.520 --> 06:00.480
And then same thing over here, the odds would also be 8K on switch two.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
05:54.520 --> 06:00.480
And then same thing over here, the odds would also be 8K on switch two.

127
06:00.480 --> 06:03.560
So that way switch one and switch two will back each other up.

128
06:03.560 --> 06:07.200
And again, that's another real world conversation as far as how we configure

129
06:07.200 --> 06:08.480
distribution layers

130
06:08.480 --> 06:12.240
when we have two distinct logical switches.

131
06:12.240 --> 06:17.440
Now lastly, this will result in blocked links that are different on a per VLAN

132
06:17.440 --> 06:18.120
basis.

133
06:18.120 --> 06:23.760
So 11, 13, 15 and 17, because the roots over on this side and with all links

134
06:23.760 --> 06:24.960
being equal,

135
06:24.960 --> 06:30.330
one of these sides will block probably switch three, especially if we have this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

135
06:24.960 --> 06:30.330
one of these sides will block probably switch three, especially if we have this

136
06:30.330 --> 06:30.920
priority

137
06:30.920 --> 06:32.640
here, that would be the case.

138
06:32.640 --> 06:37.120
So we block here for our odds.

139
06:37.120 --> 06:40.880
And then we're going to block this link over here for our evens.

140
06:40.880 --> 06:45.370
And we'll get into calculation of which links get blocked or which ports get

141
06:45.370 --> 06:46.320
blocked coming

142
06:46.320 --> 06:47.920
up here real soon.

143
06:47.920 --> 06:50.840
So for now, we can just sort of make an assumption.

144
06:50.840 --> 06:53.520
One of these links is going to be blocked for each VLAN.

145
06:53.520 --> 06:57.520
And because the evens are aggregated together, it should be the same port.

146
06:57.520 --> 07:01.280
Same thing with the odds being all blocked on the same port as well.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

146
06:57.520 --> 07:01.280
Same thing with the odds being all blocked on the same port as well.

147
07:01.280 --> 07:02.800
So now we see we have two topologies.

148
07:02.800 --> 07:06.640
Again, the evens can fully use these two links.

149
07:06.640 --> 07:10.790
The odds can still fully use this link between the switches, but it can also

150
07:10.790 --> 07:11.600
use this link

151
07:11.600 --> 07:12.960
over here.

152
07:12.960 --> 07:17.300
And this is what allows us to make sure that none of these links is idle in the

153
07:17.300 --> 07:18.400
environment.

154
07:18.400 --> 07:22.740
But now things start to get a little bit more concerning or not concerning, but

155
07:22.740 --> 07:23.400
something

156
07:23.400 --> 07:28.130
we have to recognize is challenge question number two asks about the number of

157
07:28.130 --> 07:28.800
spanning

158
07:28.800 --> 07:30.160
true protocol instances.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

158
07:28.800 --> 07:30.160
true protocol instances.

159
07:30.160 --> 07:37.400
Well, we have seven total VLANs, which means we have seven total STP instances.

160
07:37.400 --> 07:41.320
It is a one to one mapping with per VLAN spanning tree.

161
07:41.320 --> 07:44.000
Again, it's right there in the name per VLAN.

162
07:44.000 --> 07:49.100
Every single VLAN gets its own instance and therefore switch one has to send

163
07:49.100 --> 07:49.680
out four

164
07:49.680 --> 07:52.640
BPDUs every hello timer.

165
07:52.640 --> 07:57.150
It's going to send one out for VLAN 11, 13, 15, and 17, and switch three is

166
07:57.150 --> 07:58.120
going to replicate

167
07:58.120 --> 08:03.700
that on its side with three different BPDUs every hello timer for VLANs 12, 14,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
07:58.120 --> 08:03.700
that on its side with three different BPDUs every hello timer for VLANs 12, 14,

168
08:03.700 --> 08:04.720
and 16.

169
08:04.720 --> 08:08.400
Now, again, you might have divided your VLANs up differently, but the reality

170
08:08.400 --> 08:08.960
is that it's

171
08:08.960 --> 08:13.100
seven total instances with seven total BPDUs getting sent out across the

172
08:13.100 --> 08:14.120
switches every

173
08:14.120 --> 08:15.600
hello timer.

174
08:15.600 --> 08:19.200
Now lastly, we get into the timer conversation management.

175
08:19.200 --> 08:21.800
Don't you love when management gets involved?

176
08:21.800 --> 08:25.640
They are suggesting that 50 seconds is too long to wait for indirect failures.

177
08:25.640 --> 08:31.790
Anytime I see this keyword indirect for indirect failure, we should be thinking
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
08:25.640 --> 08:31.790
Anytime I see this keyword indirect for indirect failure, we should be thinking

178
08:31.790 --> 08:32.680
about that

179
08:32.680 --> 08:34.680
max age timer.

180
08:34.680 --> 08:39.240
And by default, max age is 20 seconds.

181
08:39.240 --> 08:43.480
So when they say that we really want to make it 40 seconds, that would be

182
08:43.480 --> 08:44.240
better.

183
08:44.240 --> 08:46.320
Okay, management, thanks for your input.

184
08:46.320 --> 08:48.320
Now what timer can be adjusted?

185
08:48.320 --> 08:52.410
Probably max age, but let's read the rest of it without affecting the failover

186
08:52.410 --> 08:52.960
of direct

187
08:52.960 --> 08:55.800
failures and what value should it be set at.

188
08:55.800 --> 08:59.400
So again, indirect failures, that's what max age is for.

189
08:59.400 --> 09:05.870
Direct failures are going to skip max age, and so we're going to rely totally
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

189
08:59.400 --> 09:05.870
Direct failures are going to skip max age, and so we're going to rely totally

190
09:05.870 --> 09:06.480
on the

191
09:06.480 --> 09:13.000
forward delay timer, which by default is 15 seconds.

192
09:13.000 --> 09:17.450
So for example, if this link were to go down and switch through recognizes that

193
09:17.450 --> 09:17.680
it would

194
09:17.680 --> 09:22.130
start the forward delay timer here on this link, meaning it would progress

195
09:22.130 --> 09:23.040
through listening

196
09:23.040 --> 09:25.000
and learning.

197
09:25.000 --> 09:28.540
And each one of those would take 15 seconds and therefore it would take 30

198
09:28.540 --> 09:29.160
seconds.

199
09:29.160 --> 09:34.410
So if we still want this to take 30 seconds, then we cannot change the forward
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

199
09:29.160 --> 09:34.410
So if we still want this to take 30 seconds, then we cannot change the forward

200
09:34.410 --> 09:35.120
delay, which

201
09:35.120 --> 09:40.600
is where we eventually land back at changing max age.

202
09:40.600 --> 09:45.050
So if we want to take this from 50 seconds down to 40 seconds, well, our 50

203
09:45.050 --> 09:45.720
comes from

204
09:45.720 --> 09:49.560
the max age of 20 plus two times the forward delay.

205
09:49.560 --> 09:55.510
So this stays put at 30, which means this must become 10 if we want it to be a

206
09:55.510 --> 09:56.040
total

207
09:56.040 --> 09:57.600
of 40 seconds.

208
09:57.600 --> 10:01.480
So that'd be the answer to number three, adjust max age to 10 seconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

208
09:57.600 --> 10:01.480
So that'd be the answer to number three, adjust max age to 10 seconds.

209
10:01.480 --> 10:05.400
I will say this, be very careful about changing these timers in a real world

210
10:05.400 --> 10:06.280
environment.

211
10:06.280 --> 10:08.840
For the most part, that's not advised.

212
10:08.840 --> 10:11.120
And there's very specific rules around doing it.

213
10:11.120 --> 10:15.570
But this example is really not here for real world like advice, like this is

214
10:15.570 --> 10:16.760
what we do.

215
10:16.760 --> 10:21.720
Instead, it's here to help us to cement our understanding of the timers.

216
10:21.720 --> 10:24.080
So just a little caveat there.

217
10:24.080 --> 10:28.240
Now lastly, we're back to talking about another timer here.

218
10:28.240 --> 10:31.200
Now management is getting involved again.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

218
10:28.240 --> 10:31.200
Now management is getting involved again.

219
10:31.200 --> 10:34.500
And they're saying that 30 seconds is too long to wait for a new device is to

220
10:34.500 --> 10:35.240
come online.

221
10:35.240 --> 10:39.570
So as we've said, if we have a laptop show up and plug in, it's going to have

222
10:39.570 --> 10:40.080
to wait

223
10:40.080 --> 10:47.200
that two times forward delay, which is a total of 30 seconds.

224
10:47.200 --> 10:51.480
And we will learn pretty quickly that we have other ways of bypassing this.

225
10:51.480 --> 10:54.320
But for right now, we're suggesting that's too long.

226
10:54.320 --> 10:59.240
So how can we adjust the timer so that 24 seconds, they say would be better?

227
10:59.240 --> 11:02.360
Well, we can't just say, oh, well, 30 minus 24 is six.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

227
10:59.240 --> 11:02.360
Well, we can't just say, oh, well, 30 minus 24 is six.

228
11:02.360 --> 11:05.520
So let's just drop forward delay by six seconds.

229
11:05.520 --> 11:08.440
If we did that, for delay would be nine seconds.

230
11:08.440 --> 11:10.720
And then we multiply that by two and it's 18.

231
11:10.720 --> 11:13.200
Well, we're trying to get this to 24.

232
11:13.200 --> 11:18.160
So if we're trying to get it to 24, we actually need to drop this three seconds

233
11:18.160 --> 11:18.520
because we

234
11:18.520 --> 11:21.080
wait two times that delay.

235
11:21.080 --> 11:25.920
So now this becomes 12 seconds and 12 times two gets us our 24.

236
11:25.920 --> 11:30.600
So the answer to the last one is going to be adjust the forward delay timer and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

236
11:25.920 --> 11:30.600
So the answer to the last one is going to be adjust the forward delay timer and

237
11:30.600 --> 11:31.120
shrink

238
11:31.120 --> 11:34.920
it by three seconds in order to hit 24 seconds total.

239
11:34.920 --> 11:39.180
So this example is series of challenges was intended to help us solidify our

240
11:39.180 --> 11:40.200
understanding

241
11:40.200 --> 11:44.370
of Pervieland spanning tree, the different topologies we can create as well as

242
11:44.370 --> 11:44.800
how we

243
11:44.800 --> 11:48.450
can adjust the timers, making sure we understand what the timers do and how to

244
11:48.450 --> 11:49.080
adjust them

245
11:49.080 --> 11:50.080
to achieve certain goals.

246
11:50.080 --> 11:53.200
I hope this has been informative for you and I'd like to thank you for viewing.