WEBVTT

1
00:00.000 --> 00:05.280
As a quick review of how Spanning Tree makes its decisions, it's going to

2
00:05.280 --> 00:06.460
identify which

3
00:06.460 --> 00:11.420
interfaces are upstream and which interfaces are downstream.

4
00:11.420 --> 00:15.060
It's going to treat these very differently.

5
00:15.060 --> 00:19.350
Keeping in mind how we determine the difference, upstream means that we have

6
00:19.350 --> 00:20.660
superior BPDA

7
00:20.660 --> 00:24.090
use, maybe I should draw that arrow going the other way, because we have

8
00:24.090 --> 00:25.400
superior BPDA

9
00:25.400 --> 00:30.200
use coming in and therefore we're receiving BPDA use.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:25.400 --> 00:30.200
use coming in and therefore we're receiving BPDA use.

10
00:30.200 --> 00:32.480
We're not sending BPDA use upstream.

11
00:32.480 --> 00:35.360
Instead, we send our BPDA use downstream.

12
00:35.360 --> 00:41.480
So my BPDA use gets sent downstream because they're inferior BPDA use down here

13
00:41.480 --> 00:41.520
.

14
00:41.520 --> 00:46.210
Now the superior versus inferior, that's the whole conversation around path

15
00:46.210 --> 00:47.240
costs to root

16
00:47.240 --> 00:51.490
and then we have to use tiebreakers like bridge ID as well as port priorities

17
00:51.490 --> 00:52.960
and such.

18
00:52.960 --> 00:59.280
But the driving factor in determining whether it's superior versus inferior is

19
00:59.280 --> 00:59.920
first and

20
00:59.920 --> 01:03.360
foremost the cost to the root.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

20
00:59.920 --> 01:03.360
foremost the cost to the root.

21
01:03.360 --> 01:08.090
And so as we drill into this concept of cost, we need to keep in mind that this

22
01:08.090 --> 01:08.800
is the number

23
01:08.800 --> 01:10.440
one determining factor.

24
01:10.440 --> 01:16.000
We don't ever worry about tiebreakers if we have a better cost.

25
01:16.000 --> 01:19.970
And so when we're looking at this, downstream ports are always going to be

26
01:19.970 --> 01:21.200
designated ports.

27
01:21.200 --> 01:24.360
These are the port roles that we assign.

28
01:24.360 --> 01:29.500
And then with upstream, I get exactly one root port and this is supposed to be

29
01:29.500 --> 01:30.480
the best
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:29.500 --> 01:30.480
the best

30
01:30.480 --> 01:35.800
path, which again, ideally is determined by cost.

31
01:35.800 --> 01:40.620
But if I have multiple ties or multiple paths with the same cost, I should say,

32
01:40.620 --> 01:41.120
then at

33
01:41.120 --> 01:43.760
that point we have to use the tiebreaker method.

34
01:43.760 --> 01:49.200
So let's say I identify one of these interfaces as my root port.

35
01:49.200 --> 01:53.320
The other ports are going to go into a blocking state.

36
01:53.320 --> 01:58.120
And these are known as non-designated ports or NDPs.

37
01:58.120 --> 02:04.150
So again, I get one root port and the rest are going to be non-designated ports
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:58.120 --> 02:04.150
So again, I get one root port and the rest are going to be non-designated ports

38
02:04.150 --> 02:04.800
placed

39
02:04.800 --> 02:06.880
into the blocking state.

40
02:06.880 --> 02:10.920
So this is a basic breakdown of how spanning tree achieves a loop free topology

41
02:10.920 --> 02:11.200
.

42
02:11.200 --> 02:17.200
I can forward downstream on all of my ports as long as it truly is downstream.

43
02:17.200 --> 02:21.310
But upstream, I cannot loop traffic back around and send it back up towards the

44
02:21.310 --> 02:21.840
root.

45
02:21.840 --> 02:25.240
I have to keep just a single root port.

46
02:25.240 --> 02:30.140
And that is again, the primary method behind spanning tree making its decisions
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

46
02:25.240 --> 02:30.140
And that is again, the primary method behind spanning tree making its decisions

47
02:30.140 --> 02:30.200
.

48
02:30.200 --> 02:35.590
So again, as we've said here, now we've got to identify the best path and the

49
02:35.590 --> 02:36.600
best path

50
02:36.600 --> 02:40.360
first and foremost is going to be based on cost.

51
02:40.360 --> 02:44.360
And so if I want to change what's perceived to be the best path, then I might

52
02:44.360 --> 02:45.560
want to consider

53
02:45.560 --> 02:47.880
changing costs.

54
02:47.880 --> 02:50.040
Let's remember how this works as well.

55
02:50.040 --> 02:57.560
So we are likely going to have a string of switches in a network.

56
02:57.560 --> 03:00.540
So potentially several switches hanging off of each other.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
02:57.560 --> 03:00.540
So potentially several switches hanging off of each other.

57
03:00.540 --> 03:05.650
We start up here at the root because the root is going to send out the BP to

58
03:05.650 --> 03:06.360
use.

59
03:06.360 --> 03:10.680
So it sends a BP to you and says, hey, my cost to the root, guess what?

60
03:10.680 --> 03:12.600
It's zero because it's me.

61
03:12.600 --> 03:17.720
And so I start with this root cost concept saying that it's just zero from my

62
03:17.720 --> 03:19.000
perspective.

63
03:19.000 --> 03:22.680
Well this switch here in the middle is going to receive that and it has to

64
03:22.680 --> 03:23.520
determine its

65
03:23.520 --> 03:27.240
own cost to the root if it uses this path.

66
03:27.240 --> 03:36.040
Now we start with the advertised cost and we are going to add the link cost as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
03:27.240 --> 03:36.040
Now we start with the advertised cost and we are going to add the link cost as

67
03:36.040 --> 03:37.040
it comes

68
03:37.040 --> 03:38.040
in.

69
03:38.040 --> 03:40.360
So this is an inbound concept.

70
03:40.360 --> 03:44.750
This is very important for us to recognize the concept of an inbound versus out

71
03:44.750 --> 03:46.440
bound method.

72
03:46.440 --> 03:53.050
This is inbound, meaning I only add the link cost as it comes into my switch

73
03:53.050 --> 03:54.240
onto a link,

74
03:54.240 --> 03:59.520
which means that it's the local link cost as well.

75
03:59.520 --> 04:03.920
If I disagree on the link cost between two switches, it doesn't matter.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:59.520 --> 04:03.920
If I disagree on the link cost between two switches, it doesn't matter.

76
04:03.920 --> 04:06.360
The root could say this has a link cost of 100.

77
04:06.360 --> 04:11.490
I could say as a cost of four and I'm going to go by my own local cost because

78
04:11.490 --> 04:12.000
I have

79
04:12.000 --> 04:16.710
no idea what the root thinks it is and it doesn't matter because it doesn't

80
04:16.710 --> 04:17.520
advertise

81
04:17.520 --> 04:18.520
it.

82
04:18.520 --> 04:19.520
It's not an outbound concept.

83
04:19.520 --> 04:23.080
It's not telling me, hey, by the way, this link has a cost of 100.

84
04:23.080 --> 04:27.930
Instead as the BP to you comes into this port, I recognize that it has a link

85
04:27.930 --> 04:28.960
cost of four

86
04:28.960 --> 04:33.670
regardless of what the root thinks it is or whatever switches on the other side
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
04:28.960 --> 04:33.670
regardless of what the root thinks it is or whatever switches on the other side

87
04:33.670 --> 04:33.720
.

88
04:33.720 --> 04:40.970
So at this point, I can take the advertised cost and add my link cost and now

89
04:40.970 --> 04:41.760
my root

90
04:41.760 --> 04:49.800
cost or path cost is going to be zero plus four, which is four.

91
04:49.800 --> 04:53.000
So that is what this middle switch perceives.

92
04:53.000 --> 04:58.440
And as long as this port is decided to be my root port, that is going to stay.

93
04:58.440 --> 05:02.100
If I have another path that goes to the root, maybe eventually I swing over to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

93
04:58.440 --> 05:02.100
If I have another path that goes to the root, maybe eventually I swing over to

94
05:02.100 --> 05:02.800
a different

95
05:02.800 --> 05:07.240
link, but in this mini topology here, it has a path cost of four.

96
05:07.240 --> 05:14.440
Now next, we're going to also advertise a BP to you cost or send a BP to you

97
05:14.440 --> 05:15.040
with a

98
05:15.040 --> 05:17.400
cost and I'm going to advertise my cost.

99
05:17.400 --> 05:22.640
I'm going to say it's a cost of four and maybe this has a cost of 19 down here.

100
05:22.640 --> 05:26.800
That would be the default cost for a 100 meg link.

101
05:26.800 --> 05:31.830
And so I receive the BP to you and once again, I'm going to add the four, which
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
05:26.800 --> 05:31.830
And so I receive the BP to you and once again, I'm going to add the four, which

102
05:31.830 --> 05:32.880
is advertised

103
05:32.880 --> 05:38.680
to the 19, which is my local link cost from an inbound perspective.

104
05:38.680 --> 05:44.840
And I'm going to decide that my path cost to root is 23.

105
05:44.840 --> 05:49.530
Now if I were to advertise the BP to you further downstream, I would advertise

106
05:49.530 --> 05:49.880
a cost

107
05:49.880 --> 05:55.570
of 23 and the next switch downstream would be responsible for adding its own

108
05:55.570 --> 05:56.320
local link

109
05:56.320 --> 06:01.640
cost and determining what its cost to the root becomes.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:56.320 --> 06:01.640
cost and determining what its cost to the root becomes.

110
06:01.640 --> 06:06.740
So keep in mind, again, just what it means to have an inbound nature that I'm

111
06:06.740 --> 06:07.240
adding

112
06:07.240 --> 06:12.680
costs to the advertised cost as it comes into an interface.

113
06:12.680 --> 06:16.960
Now we talked earlier about how default costs are calculated.

114
06:16.960 --> 06:23.520
We have the short and long method and by default, iOS Xe uses the short method.

115
06:23.520 --> 06:29.750
The short method essentially assigns a 100 meg link to a cost of 19, a one gig

116
06:29.750 --> 06:30.400
to a cost
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

116
06:29.750 --> 06:30.400
to a cost

117
06:30.400 --> 06:31.560
of four.

118
06:31.560 --> 06:36.750
And then from here, a 10 gig link gets a cost of two and anything greater than

119
06:36.750 --> 06:37.600
10 gig gets

120
06:37.600 --> 06:41.220
a cost of one, which is a problem because our switches can't differentiate

121
06:41.220 --> 06:41.880
between a

122
06:41.880 --> 06:45.520
20 gig port channel and a 40 gig link or a 100 gig link.

123
06:45.520 --> 06:46.520
It's all the same.

124
06:46.520 --> 06:48.360
It's all a cost of one.

125
06:48.360 --> 06:53.280
And so this is why we want to potentially configure a change here to use the

126
06:53.280 --> 06:54.040
long path

127
06:54.040 --> 06:55.600
cost method.

128
06:55.600 --> 07:01.930
And the long path cost method gives us a cost here where one gig is going to be
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
06:55.600 --> 07:01.930
And the long path cost method gives us a cost here where one gig is going to be

129
07:01.930 --> 07:03.760
20,000.

130
07:03.760 --> 07:06.920
10 gig is going to be 2000.

131
07:06.920 --> 07:11.000
And we see we've got room to grow here for things that are over 10 gig.

132
07:11.000 --> 07:14.560
Now just keep in mind that we don't advertise costs again down here.

133
07:14.560 --> 07:18.240
The root didn't advertise its cost of 100 downstream.

134
07:18.240 --> 07:20.200
Instead, it's just a local value.

135
07:20.200 --> 07:23.040
It's how a switch determines its link costs.

136
07:23.040 --> 07:26.640
Now that said, we would ideally make this a global change in a real world

137
07:26.640 --> 07:27.320
network.

138
07:27.320 --> 07:29.440
We'd absolutely want this to be global.

139
07:29.440 --> 07:34.500
But if I connect a short calculating switch to a long calculating switch,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

139
07:29.440 --> 07:34.500
But if I connect a short calculating switch to a long calculating switch,

140
07:34.500 --> 07:35.480
nothing's going

141
07:35.480 --> 07:37.200
to break per se.

142
07:37.200 --> 07:40.640
It's just going to change the way that, you know, I advertise costs.

143
07:40.640 --> 07:47.410
If I have a switch up here and it's getting BPDUs on a link that, let's say

144
07:47.410 --> 07:48.120
this one

145
07:48.120 --> 07:53.440
is using long, maybe it's getting it on a link that's 20,000 cost.

146
07:53.440 --> 07:58.090
So at this point, I'm going to advertise my cost of 20,000, assuming I'm

147
07:58.090 --> 07:59.040
directly connected

148
07:59.040 --> 08:00.480
to the root.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
07:59.040 --> 08:00.480
to the root.

149
08:00.480 --> 08:04.400
And this switch down here has a short configuration.

150
08:04.400 --> 08:06.680
And it's going to receive that on a gig link.

151
08:06.680 --> 08:11.740
And so it's going to perceive that my cost is 20,000 and 4, which seems a

152
08:11.740 --> 08:12.600
little funny

153
08:12.600 --> 08:19.320
because I took my cost of 4 and added it to the advertised cost of 20,000.

154
08:19.320 --> 08:23.640
So it creates some weird numbers, but technically speaking, it will work.

155
08:23.640 --> 08:27.160
It just might not end up blocking the links that we expect to block.

156
08:27.160 --> 08:30.960
So again, in the real world, absolutely make this a global change.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
08:27.160 --> 08:30.960
So again, in the real world, absolutely make this a global change.

157
08:30.960 --> 08:35.040
All of our switches should be using the same setting there.

158
08:35.040 --> 08:39.240
So let's draw out a quick example of a larger topology here.

159
08:39.240 --> 08:42.240
So let's say we've got switch one as the root.

160
08:42.240 --> 08:46.850
And then we've got a pair of switches here, switch two and switch three, which

161
08:46.850 --> 08:47.400
connect

162
08:47.400 --> 08:52.940
in to the root and then switch four down here, which mutually hangs off switch

163
08:52.940 --> 08:53.280
two

164
08:53.280 --> 08:54.720
and switch three.

165
08:54.720 --> 08:59.120
So let's just assume all of these links are 10 gig.

166
08:59.120 --> 09:01.760
And we're also using long path cost method.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

166
08:59.120 --> 09:01.760
And we're also using long path cost method.

167
09:01.760 --> 09:04.840
So we're looking at cost of 2000 everywhere.

168
09:04.840 --> 09:09.240
So again, we're going to look at the cost to root and switch one sees a cost of

169
09:09.240 --> 09:09.640
zero to

170
09:09.640 --> 09:11.000
itself.

171
09:11.000 --> 09:15.760
And then it pushes BPDUs downstream, switch two and switch three, receive it on

172
09:15.760 --> 09:16.400
a 10 gig

173
09:16.400 --> 09:20.520
link and understand that, well, that's a cost of 2000.

174
09:20.520 --> 09:24.640
Therefore, my cost to the root is 2000.

175
09:24.640 --> 09:28.470
These switches both advertise downstream that, hey, I've got a cost of 2000 to

176
09:28.470 --> 09:29.440
the root.

177
09:29.440 --> 09:32.580
And this is where switch four, once the choose the best path, again, it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
09:29.440 --> 09:32.580
And this is where switch four, once the choose the best path, again, it

178
09:32.580 --> 09:34.040
recognizes their superior

179
09:34.040 --> 09:38.160
BPDUs, both of these are going to be considered upstream.

180
09:38.160 --> 09:43.520
I therefore have to block one of these and make the other one my root port.

181
09:43.520 --> 09:45.080
So which one do I make it?

182
09:45.080 --> 09:50.010
Well, again, if the cost is equal, this is going to result in these arbitrary

183
09:50.010 --> 09:52.840
tiebreakers.

184
09:52.840 --> 09:58.240
And I'm going to first and foremost base it on bridge ID.

185
09:58.240 --> 10:02.960
So the bridge ID is going to be compared with the upstream switches.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

185
09:58.240 --> 10:02.960
So the bridge ID is going to be compared with the upstream switches.

186
10:02.960 --> 10:07.550
So let's say this switch starts with a zero A and its MAC address, the switch

187
10:07.550 --> 10:08.240
over here

188
10:08.240 --> 10:13.920
starts with zero B, the lower MAC address will win and therefore switch for

189
10:13.920 --> 10:14.960
prefers the path

190
10:14.960 --> 10:19.000
to switch to and we end up blocking this link.

191
10:19.000 --> 10:22.330
Now us as the network admins, we might look at this and say, okay, that's well

192
10:22.330 --> 10:23.040
and good,

193
10:23.040 --> 10:27.040
except switch two is kind of old or we're going to replace it, something like

194
10:27.040 --> 10:27.600
that.

195
10:27.600 --> 10:28.640
We just don't trust it.

196
10:28.640 --> 10:34.750
I don't want to use this path, instead I really rather use the path to switch
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
10:28.640 --> 10:34.750
I don't want to use this path, instead I really rather use the path to switch

197
10:34.750 --> 10:35.640
three.

198
10:35.640 --> 10:40.600
The problem is I can't actually change these MAC addresses.

199
10:40.600 --> 10:46.320
And so therefore the switch two is going to continue to win the tiebreaker.

200
10:46.320 --> 10:49.240
So the idea here is I don't want to get to the tiebreakers.

201
10:49.240 --> 10:51.160
I want to change this reality.

202
10:51.160 --> 10:53.560
I don't want the costs to be equal.

203
10:53.560 --> 10:55.160
So what can I do here?

204
10:55.160 --> 10:59.570
Well what I could do is recognize that since switch four is also seeing these

205
10:59.570 --> 11:00.120
links as
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

205
10:59.570 --> 11:00.120
links as

206
11:00.120 --> 11:06.140
2000 and 2000, which by the way therefore it has a cost to the root of 4000

207
11:06.140 --> 11:06.960
regardless

208
11:06.960 --> 11:08.880
of which link we choose.

209
11:08.880 --> 11:14.680
Well what if I were to add a zero to this link over here?

210
11:14.680 --> 11:19.880
I can do a manual override of my link costs.

211
11:19.880 --> 11:24.040
I don't have to abide by the default that the system is using.

212
11:24.040 --> 11:29.900
So I could manually say hey you have a cost of 20,000 and now all of a sudden

213
11:29.900 --> 11:30.480
this is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

213
11:29.900 --> 11:30.480
this is

214
11:30.480 --> 11:32.240
the preferred path.

215
11:32.240 --> 11:36.400
So my cost this way is going to be 22,000.

216
11:36.400 --> 11:41.560
The 2000 that's advertised and then the 20,000 inbound on my own interface.

217
11:41.560 --> 11:46.210
But on this side over on the right it's still going to be 4000, 2000 advertised

218
11:46.210 --> 11:47.200
and 2000

219
11:47.200 --> 11:48.280
coming in.

220
11:48.280 --> 11:53.370
And therefore switch four will decide to block this link bringing this link

221
11:53.370 --> 11:54.200
online.

222
11:54.200 --> 11:58.290
So this is a way that we can change costs in the network to manipulate which

223
11:58.290 --> 11:58.800
ports are

224
11:58.800 --> 11:59.840
being blocked.

225
11:59.840 --> 12:04.840
We just always have to keep in mind that cost is an inbound feature.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

225
11:59.840 --> 12:04.840
We just always have to keep in mind that cost is an inbound feature.

226
12:04.840 --> 12:09.600
But the good news is cost is considered first before we get to the tiebreakers.

227
12:09.600 --> 12:14.270
And so it is a great method for manipulating the spanning tree topology in my

228
12:14.270 --> 12:15.080
network.