WEBVTT

1
00:00.000 --> 00:05.260
Well, Portfast has been around for quite a while. In fact, a lot of us as

2
00:05.260 --> 00:06.120
network engineers,

3
00:06.120 --> 00:09.480
even if we haven't been around for very long, we're probably familiar with the

4
00:09.480 --> 00:09.940
concept of

5
00:09.940 --> 00:14.650
Portfast. We typically are going to apply this to our edge ports, and the

6
00:14.650 --> 00:15.560
reason for that

7
00:15.560 --> 00:22.890
is primarily because it speeds up our ability to connect. Now, how exactly does

8
00:22.890 --> 00:23.640
it do that?

9
00:23.640 --> 00:28.150
Well, we have to think back exactly to how Spanning Tree operates with any of

10
00:28.150 --> 00:29.000
its ports.

11
00:29.000 --> 00:35.200
So we're looking at a traditional Spanning Tree 802.1D environment. Well, I've
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

11
00:29.000 --> 00:35.200
So we're looking at a traditional Spanning Tree 802.1D environment. Well, I've

12
00:35.200 --> 00:35.520
got my

13
00:35.520 --> 00:40.620
switch, I've got my laptop or my PC or my access point or anything I'm trying

14
00:40.620 --> 00:41.440
to connect

15
00:41.440 --> 00:48.390
in, and I connect it in and I get to go through the listening and learning

16
00:48.390 --> 00:49.640
states. Now each

17
00:49.640 --> 00:54.840
one of these lasts for the four delay timer, which by default is 15 seconds, so

18
00:54.840 --> 00:55.360
a total

19
00:55.360 --> 01:01.060
of 30 seconds of wait time. Now, this is great when I've got another switch,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

19
00:55.360 --> 01:01.060
of 30 seconds of wait time. Now, this is great when I've got another switch,

20
01:01.060 --> 01:01.480
and there's

21
01:01.480 --> 01:06.000
a potential for loops. And I'm going to connect this and we're going to go

22
01:06.000 --> 01:07.240
through the listening

23
01:07.240 --> 01:11.760
and learning phases just to make sure that there are no loops before we bring

24
01:11.760 --> 01:12.320
this into

25
01:12.320 --> 01:16.780
a forwarding state. It makes a lot of sense over here. This is very good. But

26
01:16.780 --> 01:17.360
down here,

27
01:17.360 --> 01:21.000
we have to ask, why are we doing this? We even know that there's no loops.

28
01:21.000 --> 01:22.040
There can't be

29
01:22.040 --> 01:26.910
a loop through a laptop or through a PC, at least not unless somebody's doing

30
01:26.910 --> 01:27.720
something

31
01:27.720 --> 01:34.460
extremely malicious. And so at this point, why are we waiting 30 seconds? Now
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

31
01:27.720 --> 01:34.460
extremely malicious. And so at this point, why are we waiting 30 seconds? Now

32
01:34.460 --> 01:34.960
back when

33
01:34.960 --> 01:40.100
802.1D came out, waiting 30 seconds for a PC to fully come online or anything

34
01:40.100 --> 01:40.440
like

35
01:40.440 --> 01:44.320
that, it's not that big of a deal. But we have mobile devices and we're moving

36
01:44.320 --> 01:44.800
around

37
01:44.800 --> 01:49.410
and we might sit down in a conference room with a laptop and plug in and we're

38
01:49.410 --> 01:50.480
on immediately

39
01:50.480 --> 01:55.440
faced with the fact that, hey, I'm wired in now. So I was on the Wi-Fi. So the

40
01:55.440 --> 01:56.080
PC shuts

41
01:56.080 --> 02:01.250
off the Wi-Fi, tries to use the connection and we lose everything. So maybe I
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
01:56.080 --> 02:01.250
off the Wi-Fi, tries to use the connection and we lose everything. So maybe I

42
02:01.250 --> 02:01.560
was on a

43
02:01.560 --> 02:06.550
video call and I just lost it for 30 seconds while I wait for spanning tree to

44
02:06.550 --> 02:07.240
come back

45
02:07.240 --> 02:12.860
online. All that to say in the modern network, 30 seconds is far too long. And

46
02:12.860 --> 02:13.720
guess what?

47
02:13.720 --> 02:18.340
It was far too long a long time ago as well to the point that during the

48
02:18.340 --> 02:19.400
primary use of

49
02:19.400 --> 02:29.310
802.1D, Cisco once again said we need a better solution. So they created port

50
02:29.310 --> 02:29.960
fast.

51
02:29.960 --> 02:34.580
And incidentally, they created portfast along with two other enhancements for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

51
02:29.960 --> 02:34.580
And incidentally, they created portfast along with two other enhancements for

52
02:34.580 --> 02:36.000
spanning tree.

53
02:36.000 --> 02:42.310
One is called uplink fast and the other is backbone fast. So perhaps you've

54
02:42.310 --> 02:42.640
heard of

55
02:42.640 --> 02:47.820
these techniques and perhaps not because they are pretty legacy at this point.

56
02:47.820 --> 02:47.880
But

57
02:47.880 --> 02:51.030
we noticed that there's that fast at the end of all of them. It sort of binds

58
02:51.030 --> 02:51.760
them together

59
02:51.760 --> 02:56.930
from a naming scheme perspective. So generally speaking, uplink fast and

60
02:56.930 --> 02:57.920
backbone fast and

61
02:57.920 --> 03:03.590
for that matter port fast, all of this gets wrapped up into the new industry
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
02:57.920 --> 03:03.590
for that matter port fast, all of this gets wrapped up into the new industry

62
03:03.590 --> 03:04.560
standard,

63
03:04.560 --> 03:11.560
which was rapid spanning tree. And so we don't have to configure uplink fast.

64
03:11.560 --> 03:11.800
We don't have

65
03:11.800 --> 03:16.080
to configure backbone fast anymore. Uplink fast was about quickly failing over

66
03:16.080 --> 03:16.600
between

67
03:16.600 --> 03:20.820
multiple uplinks in the event of a direct failure. Backbone fast was a little

68
03:20.820 --> 03:21.240
bit more

69
03:21.240 --> 03:26.730
of an indirect failure concept to help us detect remote changes and spin that

70
03:26.730 --> 03:27.080
up a

71
03:27.080 --> 03:31.420
whole lot quicker. But all of this is baked into rapid spanning tree, including
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
03:27.080 --> 03:31.420
whole lot quicker. But all of this is baked into rapid spanning tree, including

72
03:31.420 --> 03:31.960
the concept

73
03:31.960 --> 03:41.780
of port fast. And yet, because we have to define which ports get port fast

74
03:41.780 --> 03:43.640
configuration, we

75
03:43.640 --> 03:48.610
still have to do this in iOS XE. And so I'm still getting on to my edge ports

76
03:48.610 --> 03:49.520
and saying,

77
03:49.520 --> 03:55.420
Hey, we're going to place this port into spanning tree port fast operation. And

78
03:55.420 --> 03:55.760
because

79
03:55.760 --> 04:01.430
it's in port fast operation, now we're going to see a speed up in terms of our
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

79
03:55.760 --> 04:01.430
it's in port fast operation, now we're going to see a speed up in terms of our

80
04:01.430 --> 04:02.680
connectivity.

81
04:02.680 --> 04:07.520
We're trying to eliminate this 30 seconds that we all have to wait. So because

82
04:07.520 --> 04:07.760
we still

83
04:07.760 --> 04:11.440
have to configure port fast, a lot of us are familiar with it. Whereas we don't

84
04:11.440 --> 04:12.200
really,

85
04:12.200 --> 04:15.420
we don't have to configure these in the modern network. And so we're not as

86
04:15.420 --> 04:16.440
familiar. But

87
04:16.440 --> 04:21.730
you know, for our intents and purposes here, we're going to focus in on port

88
04:21.730 --> 04:22.600
fast, the

89
04:22.600 --> 04:26.620
uplink fast and backbone fast is really not within scope of our conversation or

90
04:26.620 --> 04:27.080
what this

91
04:27.080 --> 04:31.670
exam is going to be testing us on. So what exactly does port fast do? Well,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

91
04:27.080 --> 04:31.670
exam is going to be testing us on. So what exactly does port fast do? Well,

92
04:31.670 --> 04:32.200
port fast

93
04:32.200 --> 04:38.550
is going to bypass the listening and learning states, which is pretty

94
04:38.550 --> 04:40.040
phenomenal. This is

95
04:40.040 --> 04:47.280
going to save us 30 seconds of uptime. But listening and learning is kind of

96
04:47.280 --> 04:48.600
important.

97
04:48.600 --> 04:52.970
We were doing it for a reason, right? So are there any downsides to this? So in

98
04:52.970 --> 04:53.520
order to

99
04:53.520 --> 04:56.290
understand that we really need to just kind of think through the process of

100
04:56.290 --> 04:56.720
what we're

101
04:56.720 --> 05:01.060
doing here. So remember, we're trying to prevent loops. Listening and learning
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:56.720 --> 05:01.060
doing here. So remember, we're trying to prevent loops. Listening and learning

102
05:01.060 --> 05:02.080
is very important

103
05:02.080 --> 05:07.450
so that we have time to exchange BPDUs. And there might even be a propagation

104
05:07.450 --> 05:07.960
sort of

105
05:07.960 --> 05:12.560
a ripple effect, if you will, if this is now in the forwarding state, maybe a

106
05:12.560 --> 05:13.040
different

107
05:13.040 --> 05:16.600
port that was in the forwarding state now needs to move to the blocking state,

108
05:16.600 --> 05:16.800
and so

109
05:16.800 --> 05:20.060
on and so forth. I mean, a lot of things can happen during that listening and

110
05:20.060 --> 05:20.560
learning

111
05:20.560 --> 05:25.740
conversation. But it really only needs to happen with switches. So if I know

112
05:25.740 --> 05:26.040
that a

113
05:26.040 --> 05:33.530
port here is going to connect into our access layer devices like a PC or laptop
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

113
05:26.040 --> 05:33.530
port here is going to connect into our access layer devices like a PC or laptop

114
05:33.530 --> 05:34.480
again, at

115
05:34.480 --> 05:39.190
that point, I know that there can't be a loop. And so there's no reason for me

116
05:39.190 --> 05:39.840
to have to

117
05:39.840 --> 05:43.480
go through listening and learning unless I accidentally connect a switch to

118
05:43.480 --> 05:43.960
that. So

119
05:43.960 --> 05:48.840
we'll talk about that scenario in a moment. But in the event that I do just

120
05:48.840 --> 05:49.480
connect a

121
05:49.480 --> 05:54.880
laptop into a port fast enabled port, at that point, we are going to

122
05:54.880 --> 05:56.960
immediately transition

123
05:56.960 --> 06:06.090
into the forwarding state. And we are making an assumption here, we're going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

123
05:56.960 --> 06:06.090
into the forwarding state. And we are making an assumption here, we're going to

124
06:06.090 --> 06:06.720
assume

125
06:06.720 --> 06:12.250
that there are no loops. Now assuming can be a very bad thing. It can't really

126
06:12.250 --> 06:12.680
get us

127
06:12.680 --> 06:17.770
into a lot of trouble. But in this case, we are probably going to be good in

128
06:17.770 --> 06:18.840
most situations.

129
06:18.840 --> 06:24.080
And when we're not, we're going to have a little bit of a fail safe in mind.

130
06:24.080 --> 06:24.680
But a couple

131
06:24.680 --> 06:30.030
of quick things about this before we move on. First of all, spanning tree
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

131
06:24.680 --> 06:30.030
of quick things about this before we move on. First of all, spanning tree

132
06:30.030 --> 06:30.560
continues to

133
06:30.560 --> 06:37.710
run. In fact, it runs just like any other port and it's going to send BP to use

134
06:37.710 --> 06:38.320
. So

135
06:38.320 --> 06:42.790
because we're sending BP to use, it's a downstream port, that means that we're

136
06:42.790 --> 06:44.320
going to maintain

137
06:44.320 --> 06:48.630
that this topology. That's how we maintain the topologies to send BP to use. So

138
06:48.630 --> 06:48.800
I am

139
06:48.800 --> 06:54.000
still sending BP to use and spanning tree is still running. And this is going

140
06:54.000 --> 06:55.360
to be exactly

141
06:55.360 --> 07:01.120
why we're still fine if I do connect a switch. So let's say that I've got this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

141
06:55.360 --> 07:01.120
why we're still fine if I do connect a switch. So let's say that I've got this

142
07:01.120 --> 07:01.880
port fast

143
07:01.880 --> 07:07.940
enabled port and I mistakenly connect a switch that already has a connection,

144
07:07.940 --> 07:08.640
maybe to the

145
07:08.640 --> 07:14.270
rest of the network. Did I just create a loop? We can see the loop in here. But

146
07:14.270 --> 07:14.640
did

147
07:14.640 --> 07:19.850
I just create a problem for spanning tree? Unfortunately, I did not create a

148
07:19.850 --> 07:20.960
big problem.

149
07:20.960 --> 07:27.890
Because what happens here is if a BP to you is received, then we're going to

150
07:27.890 --> 07:29.120
revert back

151
07:29.120 --> 07:34.990
to normal operation. We don't want to keep running import fast at that point,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

151
07:29.120 --> 07:34.990
to normal operation. We don't want to keep running import fast at that point,

152
07:34.990 --> 07:35.320
because

153
07:35.320 --> 07:40.340
our assumption has been proven false. We received a BP to you, which means we

154
07:40.340 --> 07:40.820
can't

155
07:40.820 --> 07:45.450
assume that there's no loops anymore. Therefore, I'm going to immediately

156
07:45.450 --> 07:47.180
transition to the

157
07:47.180 --> 07:51.950
listening state and go through listening and learning before I make any

158
07:51.950 --> 07:53.480
decisions. So this

159
07:53.480 --> 07:58.230
is a good fail safe. Now what's interesting here is that Cisco actually says if

160
07:58.230 --> 07:58.840
we enable

161
07:58.840 --> 08:02.620
port fast on a port that we have to be careful because this can create
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

161
07:58.840 --> 08:02.620
port fast on a port that we have to be careful because this can create

162
08:02.620 --> 08:03.940
temporary loops. And

163
08:03.940 --> 08:07.730
they're technically correct. Why does it create a temporary loop? And how long

164
08:07.730 --> 08:08.320
is that loop

165
08:08.320 --> 08:13.690
in place? Well, think about this. What I just said is that we need to receive a

166
08:13.690 --> 08:14.200
BP view

167
08:14.200 --> 08:20.450
on the port, which means this switch here needs to send a BP to upstream. How

168
08:20.450 --> 08:20.760
often

169
08:20.760 --> 08:24.700
does it send BP to use? By default, every two seconds, but it could be

170
08:24.700 --> 08:25.920
configured for

171
08:25.920 --> 08:30.610
four seconds or five seconds. The reality is that we can't react to there being
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

171
08:25.920 --> 08:30.610
four seconds or five seconds. The reality is that we can't react to there being

172
08:30.610 --> 08:31.160
a potential

173
08:31.160 --> 08:36.070
loop until we receive a BP to you. And until that BP to you is received, we

174
08:36.070 --> 08:36.820
will have a

175
08:36.820 --> 08:41.510
loop and we will be flooding traffic and sending broadcast traffic through that

176
08:41.510 --> 08:41.820
loop

177
08:41.820 --> 08:47.290
and it will create a broadcast storm. So it is temporary and it is very, very

178
08:47.290 --> 08:47.980
brief,

179
08:47.980 --> 08:52.080
but we do technically have that risk. And it's a good reason. I would say it's

180
08:52.080 --> 08:52.400
a good

181
08:52.400 --> 08:55.890
reason to keep our hello timers at two seconds. But the question is, what's the

182
08:55.890 --> 08:56.520
switch? Is

183
08:56.520 --> 09:01.430
this a rogue switch? Is it a, is it a switch that came off out of our stock and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
08:56.520 --> 09:01.430
this a rogue switch? Is it a, is it a switch that came off out of our stock and

184
09:01.430 --> 09:03.580
our inventory?

185
09:03.580 --> 09:06.780
And if that's the case, maybe it will be still configured for whatever we're

186
09:06.780 --> 09:07.760
using two seconds,

187
09:07.760 --> 09:11.490
hopefully. But if it is configured for five seconds, it doesn't matter what the

188
09:11.490 --> 09:11.800
rest of

189
09:11.800 --> 09:16.690
my network timers are set to, that's going to be what determines when I form a

190
09:16.690 --> 09:17.320
loop.

191
09:17.320 --> 09:21.660
So what do we do in real life in the real world? We absolutely use port fast.

192
09:21.660 --> 09:22.120
We use

193
09:22.120 --> 09:26.380
it everywhere that we consider to be an edge port. A lot of our front facing

194
09:26.380 --> 09:27.280
access layer

195
09:27.280 --> 09:32.850
ports have port fast enabled. And it is considered good practice. Now, one last
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

195
09:27.280 --> 09:32.850
ports have port fast enabled. And it is considered good practice. Now, one last

196
09:32.850 --> 09:33.480
consideration

197
09:33.480 --> 09:37.830
in all this comes back to the end of the last video, where we had said that we

198
09:37.830 --> 09:39.260
had a problem

199
09:39.260 --> 09:46.480
with our TCNs. Remember, TCNs are triggered for a couple of situations, but

200
09:46.480 --> 09:47.300
especially

201
09:47.300 --> 09:55.430
when a port transitions to forwarding, which is going to apply to my edge ports

202
09:55.430 --> 09:55.800
, at least

203
09:55.800 --> 10:04.820
from a standard 802.1d perspective, meaning that if I do plug in this laptop,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

203
09:55.800 --> 10:04.820
from a standard 802.1d perspective, meaning that if I do plug in this laptop,

204
10:04.820 --> 10:05.800
it is going

205
10:05.800 --> 10:13.010
to trigger a TCN. So we can say that we're going to bypass the listening and

206
10:13.010 --> 10:13.320
learning

207
10:13.320 --> 10:18.010
state up here. We bypass listening and learning, and it speeds us up. And that

208
10:18.010 --> 10:18.600
's usually what

209
10:18.600 --> 10:22.830
we think about when we think about spanning tree port fast. And yet, there's

210
10:22.830 --> 10:23.240
another

211
10:23.240 --> 10:33.420
huge part of port fast. With port fast, we do not trigger TCNs. This is
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

211
10:23.240 --> 10:33.420
huge part of port fast. With port fast, we do not trigger TCNs. This is

212
10:33.420 --> 10:34.680
arguably a bigger

213
10:34.680 --> 10:39.660
deal than the fact that we're bypassing our listening and learning states. Yes,

214
10:39.660 --> 10:39.880
it is

215
10:39.880 --> 10:44.320
extremely noticeable to wait for 30 seconds. And there is no doubt that our

216
10:44.320 --> 10:45.200
users will complain

217
10:45.200 --> 10:49.480
like crazy if they have to wait for that. But the fact that we don't send TCNs

218
10:49.480 --> 10:50.000
means

219
10:50.000 --> 10:55.670
that our network stays stable. It keeps our Mac address timer for our cam

220
10:55.670 --> 10:57.360
tables at 300

221
10:57.360 --> 11:02.470
seconds. We absolutely want to keep it at 300 seconds. If at all possible, we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

221
10:57.360 --> 11:02.470
seconds. We absolutely want to keep it at 300 seconds. If at all possible, we

222
11:02.470 --> 11:02.920
don't want

223
11:02.920 --> 11:08.500
to be running at the 15 seconds, which is where we run if we are under a top

224
11:08.500 --> 11:09.920
ology change.

225
11:09.920 --> 11:14.080
So let's always keep in mind that port fast is responsible for actually two

226
11:14.080 --> 11:15.240
major benefits,

227
11:15.240 --> 11:19.170
not only connecting us faster, but also keeping our spanning tree topology more

228
11:19.170 --> 11:19.800
stable.