WEBVTT

1
00:00.000 --> 00:02.640
Well, here we finally are.

2
00:02.640 --> 00:08.570
We are ready to talk about rapid spanning tree and find out what exactly it is

3
00:08.570 --> 00:09.120
that makes

4
00:09.120 --> 00:12.280
it so much better than traditional spanning tree.

5
00:12.280 --> 00:18.250
So traditional spanning tree we often refer to as 802.1d, it's the IEEE's

6
00:18.250 --> 00:19.760
standard specification

7
00:19.760 --> 00:23.920
for how exactly spanning tree should be deployed into environments.

8
00:23.920 --> 00:30.930
Well, they updated this to this rapid spanning tree via a specification which
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:23.920 --> 00:30.930
Well, they updated this to this rapid spanning tree via a specification which

9
00:30.930 --> 00:33.360
is 802.1w, the

10
00:33.360 --> 00:35.480
w is lowercase there.

11
00:35.480 --> 00:41.920
And yes, as the name implies, it is going to greatly speed up our convergence.

12
00:41.920 --> 00:47.800
The challenge is understanding how exactly it accomplishes this goal.

13
00:47.800 --> 00:51.970
Because we might make the bad assumption that this has something to do with

14
00:51.970 --> 00:52.640
timers.

15
00:52.640 --> 00:55.520
We have these long timers in traditional spanning tree.

16
00:55.520 --> 00:58.700
We have forward delay and we have to wait two of those to bring a port online

17
00:58.700 --> 00:59.200
so it takes

18
00:59.200 --> 01:00.920
30 seconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

18
00:59.200 --> 01:00.920
30 seconds.

19
01:00.920 --> 01:04.560
And so maybe we're going to drastically decrease the timers or something along

20
01:04.560 --> 01:05.360
those lines.

21
01:05.360 --> 01:07.800
But that's not how it works.

22
01:07.800 --> 01:12.520
In fact, it uses the exact same timers as our traditional spanning tree.

23
01:12.520 --> 01:17.650
Instead, we're going to accomplish this by allowing our switches to perform

24
01:17.650 --> 01:18.920
negotiations.

25
01:18.920 --> 01:21.960
We're going to allow our switches to talk to one another.

26
01:21.960 --> 01:25.750
So that if one side decides it's blocking, the other side becomes aware of that

27
01:25.750 --> 01:26.080
.

28
01:26.080 --> 01:29.550
And at that point, they understand what the other side is doing and they can

29
01:29.550 --> 01:30.360
make decisions
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

29
01:29.550 --> 01:30.360
make decisions

30
01:30.360 --> 01:32.600
faster.

31
01:32.600 --> 01:36.510
Now before we get into the differences between traditional and rapid spanning

32
01:36.510 --> 01:37.160
tree, what

33
01:37.160 --> 01:44.320
exactly is the same as our 802.1d traditional spanning tree?

34
01:44.320 --> 01:47.800
There's a reason why we spent so much time on 802.1d.

35
01:47.800 --> 01:51.660
Just because rapid spanning tree uses a lot of the same principles as

36
01:51.660 --> 01:52.640
traditional spanning

37
01:52.640 --> 01:53.640
tree.

38
01:53.640 --> 01:57.280
For example, as we already mentioned, the timers are going to be the same.

39
01:57.280 --> 01:59.680
Our root election is going to be the same.

40
01:59.680 --> 02:05.010
Our decision making around who has the best priority or ultimately the best
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:59.680 --> 02:05.010
Our decision making around who has the best priority or ultimately the best

41
02:05.010 --> 02:05.760
bridge ID

42
02:05.760 --> 02:09.570
because it's always going to go by lower MAC address if priorities are tied,

43
02:09.570 --> 02:10.000
that all

44
02:10.000 --> 02:11.560
remains the same.

45
02:11.560 --> 02:16.200
We're going to see that our BPDU flow is mostly the same.

46
02:16.200 --> 02:21.320
But at least is going to continue to flow downstream from the root.

47
02:21.320 --> 02:25.840
But at the same time, when we say from the root, we just mean directionally.

48
02:25.840 --> 02:29.050
There is a difference with how BPDUs are generated and we'll talk about that

49
02:29.050 --> 02:29.560
later.

50
02:29.560 --> 02:34.720
So put a little, maybe more of an asterisk on the BPDU flow for now.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:29.560 --> 02:34.720
So put a little, maybe more of an asterisk on the BPDU flow for now.

51
02:34.720 --> 02:38.710
But again, the focus here being that it flows away from the root remains the

52
02:38.710 --> 02:39.260
same.

53
02:39.260 --> 02:42.320
We also have concepts like our priorities.

54
02:42.320 --> 02:46.380
I suppose we just mentioned as part of root election, but we also look at

55
02:46.380 --> 02:47.280
spanning tree

56
02:47.280 --> 02:53.310
costs, our port priorities, all of these decisions that are made around these

57
02:53.310 --> 02:54.480
concepts, they

58
02:54.480 --> 02:57.720
are going to be made the exact same way.

59
02:57.720 --> 03:03.810
And then for that matter, when we look at our iOS XE commands, once rapid is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:57.720 --> 03:03.810
And then for that matter, when we look at our iOS XE commands, once rapid is

60
03:03.810 --> 03:04.760
enabled,

61
03:04.760 --> 03:09.140
which takes its own command, well, then all of our iOS XE commands are going to

62
03:09.140 --> 03:10.000
feel very

63
03:10.000 --> 03:11.000
similar.

64
03:11.000 --> 03:15.830
And identical, we're using the same show commands, the same debug commands

65
03:15.830 --> 03:16.880
regardless.

66
03:16.880 --> 03:20.780
And finally, those protection mechanisms that we just got done talking about,

67
03:20.780 --> 03:21.320
if you're

68
03:21.320 --> 03:26.630
working way through this course sequentially, we talked about Cisco creating

69
03:26.630 --> 03:27.480
mechanisms

70
03:27.480 --> 03:31.320
such as BPDU guard and root guard.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

70
03:27.480 --> 03:31.320
such as BPDU guard and root guard.

71
03:31.320 --> 03:33.720
And then we have UDLD and such.

72
03:33.720 --> 03:37.400
So we'll just say it said right here because all of those loop guard included

73
03:37.400 --> 03:37.780
are going

74
03:37.780 --> 03:42.110
to remain the same and yes, we should absolutely be deploying these into

75
03:42.110 --> 03:43.820
production as we emphasize

76
03:43.820 --> 03:45.560
when we covered the topics.

77
03:45.560 --> 03:50.140
That doesn't change when we talk about rapid spanning tree.

78
03:50.140 --> 03:52.100
Finally, this is a big one.

79
03:52.100 --> 03:54.820
Per VLAN spanning tree is back.

80
03:54.820 --> 04:00.400
When we talk about rapid spanning tree on a Cisco switch, it's going to use
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:54.820 --> 04:00.400
When we talk about rapid spanning tree on a Cisco switch, it's going to use

81
04:00.400 --> 04:01.860
rapid PVST

82
04:01.860 --> 04:02.860
plus.

83
04:02.860 --> 04:05.960
This just means that we're doing the exact same thing that Cisco does with

84
04:05.960 --> 04:06.620
traditional

85
04:06.620 --> 04:10.970
spanning tree in that we get a topology per VLAN, whether we want that or not,

86
04:10.970 --> 04:11.620
doesn't

87
04:11.620 --> 04:17.940
matter because we cannot disable the per VLAN nature of rapid PVST plus.

88
04:17.940 --> 04:23.940
So we're either running our traditional PVST plus or running rapid PVST plus.

89
04:23.940 --> 04:29.850
Those are only two choices outside of MST, which we'll be talking about coming

90
04:29.850 --> 04:30.340
up.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
04:29.850 --> 04:30.340
up.

91
04:30.340 --> 04:34.560
So then we have to say, if we know what is the same, we have to ask the

92
04:34.560 --> 04:35.940
question of what's

93
04:35.940 --> 04:37.540
new.

94
04:37.540 --> 04:42.740
And this, the negotiation concept is the biggest concept here.

95
04:42.740 --> 04:46.790
We are going to see that our switches, again, are going to send messages to one

96
04:46.790 --> 04:47.500
another that

97
04:47.500 --> 04:49.940
allow them to make faster decisions.

98
04:49.940 --> 04:53.500
This happens out of band relative to the timers.

99
04:53.500 --> 04:56.180
The timers will still run in the background.

100
04:56.180 --> 04:58.220
I mentioned that it's the same, right?

101
04:58.220 --> 05:03.030
But they are going to be more of a fail safe when we can't use rapid mechanisms
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:58.220 --> 05:03.030
But they are going to be more of a fail safe when we can't use rapid mechanisms

102
05:03.030 --> 05:03.060
.

103
05:03.060 --> 05:07.660
But it's important to understand when we can use rapid mechanisms.

104
05:07.660 --> 05:13.500
Rapid mechanisms is going to require an underlying assumption to be proven true

105
05:13.500 --> 05:14.740
, which is that

106
05:14.740 --> 05:20.300
we have point to point links between switches.

107
05:20.300 --> 05:24.100
In other words, no hubs.

108
05:24.100 --> 05:26.860
Always remember that spanning tree was designed to handle hubs.

109
05:26.860 --> 05:31.590
We had the capability of having a hub here in the middle and our two switches
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:26.860 --> 05:31.590
We had the capability of having a hub here in the middle and our two switches

110
05:31.590 --> 05:32.580
could connect

111
05:32.580 --> 05:36.900
into the hub and then we could have a bunch of hosts hanging off of this hub.

112
05:36.900 --> 05:40.880
And we've talked about how some of these Cisco mechanisms, these protection

113
05:40.880 --> 05:41.900
mechanisms,

114
05:41.900 --> 05:46.960
work around some of the problems that that can cause especially in modern

115
05:46.960 --> 05:47.980
networks.

116
05:47.980 --> 05:51.680
Well, rapid is going to say we're no longer going to support hubs, at least on

117
05:51.680 --> 05:52.220
links where

118
05:52.220 --> 05:54.500
rapid mechanisms exist.

119
05:54.500 --> 05:57.420
So we're going to define two link types.

120
05:57.420 --> 06:02.260
We're going to call one point to point spelled like this on Cisco iOS XE.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
05:57.420 --> 06:02.260
We're going to call one point to point spelled like this on Cisco iOS XE.

121
06:02.260 --> 06:10.270
So capital P number two lowercase P, which again simply means point to point,

122
06:10.270 --> 06:10.500
which has

123
06:10.500 --> 06:12.140
a couple other implications.

124
06:12.140 --> 06:15.180
First of all, it means we're connecting switch to switch directly.

125
06:15.180 --> 06:20.420
And second of all, it must be running full duplex.

126
06:20.420 --> 06:24.320
Because if we're running half duplex, that means there might be a hub between

127
06:24.320 --> 06:25.180
the switches.

128
06:25.180 --> 06:29.940
So then we have another link type that we call shared.

129
06:29.940 --> 06:32.980
Shared is simply saying that it's half duplex.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
06:29.940 --> 06:32.980
Shared is simply saying that it's half duplex.

130
06:32.980 --> 06:36.300
It's not necessarily saying that there's a hub there.

131
06:36.300 --> 06:40.390
It's saying, or what it is saying is that we don't know whether there's a hub

132
06:40.390 --> 06:41.100
there.

133
06:41.100 --> 06:43.900
Now we can configure a link to run in either one of these modes.

134
06:43.900 --> 06:47.470
However, by default, it's going to rely on the half and full duplex

135
06:47.470 --> 06:48.540
configuration to

136
06:48.540 --> 06:50.620
decide which mode it's running on.

137
06:50.620 --> 06:55.230
And as we might imagine in modern networks running gigabit and 10 gigabit

138
06:55.230 --> 06:55.820
speeds, most

139
06:55.820 --> 06:59.630
if not all of our ports will default to point to point, which means that rapid

140
06:59.630 --> 07:00.260
mechanisms
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

140
06:59.630 --> 07:00.260
mechanisms

141
07:00.260 --> 07:02.240
are going to work on all of those.

142
07:02.240 --> 07:06.560
But it is worth noting that the speed of rapid spanning tree can only be

143
07:06.560 --> 07:07.380
achieved on

144
07:07.380 --> 07:10.500
these point to point full duplex connections.

145
07:10.500 --> 07:13.980
So the question then is, do we need timers?

146
07:13.980 --> 07:16.300
Are they required at this point?

147
07:16.300 --> 07:18.060
And the answer is still yes.

148
07:18.060 --> 07:23.640
However, the primary purpose of timers is going to serve as a backup to our

149
07:23.640 --> 07:25.420
rapid mechanisms.

150
07:25.420 --> 07:30.350
In other words, if one of two situations is true, either we have no BPDUs
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

150
07:25.420 --> 07:30.350
In other words, if one of two situations is true, either we have no BPDUs

151
07:30.350 --> 07:32.580
coming in,

152
07:32.580 --> 07:36.180
meaning I can't negotiate with the switch on the other side because I don't

153
07:36.180 --> 07:36.620
sense that

154
07:36.620 --> 07:38.420
there's a switch on the other side.

155
07:38.420 --> 07:43.070
And maybe there's not one, or if it's running in half duplex and either one of

156
07:43.070 --> 07:44.460
these scenarios,

157
07:44.460 --> 07:48.660
we are going to have to use timers.

158
07:48.660 --> 07:54.890
And as I mentioned, all the timer values share the default settings from

159
07:54.890 --> 07:55.980
previous the traditional

160
07:55.980 --> 07:57.820
802.1d values.

161
07:57.820 --> 08:01.980
However, there is one caveat to that, which has to do with max age.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
07:57.820 --> 08:01.980
However, there is one caveat to that, which has to do with max age.

162
08:01.980 --> 08:05.260
Now max age still has the same value of 20 seconds.

163
08:05.260 --> 08:06.980
That part doesn't change.

164
08:06.980 --> 08:11.590
But the question has to do not with our backup mechanisms, but actually how

165
08:11.590 --> 08:12.500
exactly does

166
08:12.500 --> 08:15.540
rapid PBS D plus in our case?

167
08:15.540 --> 08:20.100
How does rapid handle timing out of BPDUs?

168
08:20.100 --> 08:26.250
Because the BPDU timeout concept is that I haven't received a BPDU in a while,

169
08:26.250 --> 08:26.740
and therefore

170
08:26.740 --> 08:28.700
we need to time it out.

171
08:28.700 --> 08:33.130
And so we normally use max age for that, but 20 seconds is a very long time in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
08:28.700 --> 08:33.130
And so we normally use max age for that, but 20 seconds is a very long time in

172
08:33.130 --> 08:33.740
the rapid

173
08:33.740 --> 08:35.380
spanning tree world.

174
08:35.380 --> 08:41.190
So when we're running with rapid mechanisms, we don't actually use max age

175
08:41.190 --> 08:42.220
anymore.

176
08:42.220 --> 08:46.180
Instead, we simply use a calculation based on hello timer.

177
08:46.180 --> 08:49.180
We say it's three hello timers.

178
08:49.180 --> 08:54.060
Now if hello time is set to two seconds, that would be six seconds by default.

179
08:54.060 --> 08:57.620
And so if we change hello timer, then that value would change as well.

180
08:57.620 --> 09:01.220
So just understand max age still is set to 20 seconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

180
08:57.620 --> 09:01.220
So just understand max age still is set to 20 seconds.

181
09:01.220 --> 09:06.750
It's still used as a backup mechanism, but the BPDU timeout element of max age

182
09:06.750 --> 09:07.340
when we're

183
09:07.340 --> 09:10.880
running rapid spanning tree is not going to actually be based on the max age

184
09:10.880 --> 09:11.300
timer.

185
09:11.300 --> 09:15.410
It's going to be based on the hello timer and specifically three of the hello

186
09:15.410 --> 09:16.060
timers.

187
09:16.060 --> 09:20.610
So once again, rapid spanning tree achieves its speed when possible, requiring

188
09:20.610 --> 09:21.300
these point

189
09:21.300 --> 09:22.780
to point links.

190
09:22.780 --> 09:26.500
And it does that using these negotiations between switches rather than relying

191
09:26.500 --> 09:27.020
on faster

192
09:27.020 --> 09:28.580
timers or any other mechanism.