WEBVTT

1
00:00.000 --> 00:04.120
Everything we're going to talk about in this skill has to do with one

2
00:04.120 --> 00:05.720
fundamental flaw

3
00:05.720 --> 00:07.040
of spanning tree protocol.

4
00:07.040 --> 00:12.360
And it has to do with the fact that spanning tree protocol must support hubs.

5
00:12.360 --> 00:15.890
We look at this and say, well, okay, that's great, but we don't want to support

6
00:15.890 --> 00:16.200
hubs

7
00:16.200 --> 00:17.200
anymore.

8
00:17.200 --> 00:20.580
And that's cool and all except spanning tree still has to be able to support

9
00:20.580 --> 00:21.120
them even

10
00:21.120 --> 00:22.120
today.

11
00:22.120 --> 00:24.080
We need this backwards compatibility.

12
00:24.080 --> 00:28.440
And so here's the situation that's going to drive most of our conversations.

13
00:28.440 --> 00:31.960
Let's say we have a stable spanning tree topology.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:28.440 --> 00:31.960
Let's say we have a stable spanning tree topology.

14
00:31.960 --> 00:36.750
And we know that somewhere up here is the root of the network and we're sending

15
00:36.750 --> 00:37.080
our

16
00:37.080 --> 00:39.520
BP to use downstream.

17
00:39.520 --> 00:41.760
Those BP to use land on some switch like this.

18
00:41.760 --> 00:47.160
We'll call this switch three and downstream of switch three is switch four.

19
00:47.160 --> 00:51.120
And let's say that switch four has another path to the root.

20
00:51.120 --> 00:54.800
In fact, this is switch four's root port.

21
00:54.800 --> 00:58.520
And here we have a connection to switch three, so we've decided, you know, that

22
00:58.520 --> 00:59.000
's another

23
00:59.000 --> 01:03.120
upstream port, but we're going to place this into the non designated port or
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:59.000 --> 01:03.120
upstream port, but we're going to place this into the non designated port or

24
01:03.120 --> 01:05.200
blocking status.

25
01:05.200 --> 01:07.240
And so this prevents our loop.

26
01:07.240 --> 01:10.350
We see that there's kind of a loop all the way around like this, but the fact

27
01:10.350 --> 01:10.920
that we're

28
01:10.920 --> 01:14.760
blocking that port means that there is no loop and life is good.

29
01:14.760 --> 01:16.920
But notice the BP to you flow here.

30
01:16.920 --> 01:20.640
We're receiving BP to use this way.

31
01:20.640 --> 01:24.360
And we're receiving BP to use this way.

32
01:24.360 --> 01:30.280
The BP to use are sort of like the lifeblood of the spanning tree topology.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

32
01:24.360 --> 01:30.280
The BP to use are sort of like the lifeblood of the spanning tree topology.

33
01:30.280 --> 01:36.270
Those BP to use must be maintained because they're maintaining the topology

34
01:36.270 --> 01:36.920
switch four

35
01:36.920 --> 01:41.980
knows to continue to block that port because it continues to receive superior

36
01:41.980 --> 01:42.760
BP to use.

37
01:42.760 --> 01:49.400
And remember, a superior BP to you tells us that that is an upstream port

38
01:49.400 --> 01:50.720
because that

39
01:50.720 --> 01:57.320
is a better path to the root than anything that I would claim to have myself.

40
01:57.320 --> 02:01.000
And so therefore, if I send packets that direction, it'll get to the root.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:57.320 --> 02:01.000
And so therefore, if I send packets that direction, it'll get to the root.

41
02:01.000 --> 02:03.920
But remember, I can only have one upstream port, which is why I have to block

42
02:03.920 --> 02:04.520
one of those.

43
02:04.520 --> 02:07.840
So the best upstream port becomes my root port.

44
02:07.840 --> 02:11.500
As soon as I'm receiving superior BP to use on other ports, and it's not as

45
02:11.500 --> 02:12.120
good as that

46
02:12.120 --> 02:14.000
one, they're going to be blocked.

47
02:14.000 --> 02:21.920
Meanwhile, inferior BP to use or for that matter, no BP to use.

48
02:21.920 --> 02:26.000
This means that it's downstream.

49
02:26.000 --> 02:30.500
And while I block all of my upstream ports besides one, downstream ports are
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

49
02:26.000 --> 02:30.500
And while I block all of my upstream ports besides one, downstream ports are

50
02:30.500 --> 02:31.160
always going

51
02:31.160 --> 02:35.430
to be forwarding because there's no risk of a loop in theory when I'm

52
02:35.430 --> 02:36.760
forwarding packets

53
02:36.760 --> 02:38.760
downstream.

54
02:38.760 --> 02:44.930
So what happens here is that life is good until what happens, and this is the

55
02:44.930 --> 02:46.120
big scenario

56
02:46.120 --> 02:57.160
that we need to address, what happens if the superior BP to you stops?

57
02:57.160 --> 03:02.160
Specifically in our diagram here, these BP to use stop showing up for some
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

57
02:57.160 --> 03:02.160
Specifically in our diagram here, these BP to use stop showing up for some

58
03:02.160 --> 03:03.000
reason.

59
03:03.000 --> 03:06.270
Now if this link is down, that's not a problem because now that link is no

60
03:06.270 --> 03:06.920
longer a part

61
03:06.920 --> 03:07.920
of our topology.

62
03:07.920 --> 03:11.120
But what if the link is up?

63
03:11.120 --> 03:16.640
The link remains up and the BP to you stops.

64
03:16.640 --> 03:23.120
Well this is a problem because now this gets classified here was saying that

65
03:23.120 --> 03:23.920
there's no

66
03:23.920 --> 03:28.320
BP to use, which means it's now considered to be a downstream port, which means

67
03:28.320 --> 03:28.680
we're

68
03:28.680 --> 03:31.880
going to transition into the forwarding state.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
03:28.680 --> 03:31.880
going to transition into the forwarding state.

69
03:31.880 --> 03:34.800
So this is the problem.

70
03:34.800 --> 03:40.100
This non-designated port actually gets changed over to being considered a

71
03:40.100 --> 03:41.360
designated port

72
03:41.360 --> 03:43.600
and it goes into the forwarding state.

73
03:43.600 --> 03:46.820
Now yeah, we're going to have to go through our timers or have to wait for max

74
03:46.820 --> 03:47.240
age.

75
03:47.240 --> 03:48.760
That's 20 seconds by default.

76
03:48.760 --> 03:51.750
And then we're going to have to wait for listening and learning, which is 15

77
03:51.750 --> 03:52.160
seconds

78
03:52.160 --> 03:53.160
each.

79
03:53.160 --> 03:59.360
But after 50 seconds, we have transitioned that port into the forwarding state.

80
03:59.360 --> 04:04.760
And now we have this large loop, which is a problem.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:59.360 --> 04:04.760
And now we have this large loop, which is a problem.

81
04:04.760 --> 04:08.320
Now we might look at this scenario and say, okay, that's interesting.

82
04:08.320 --> 04:10.640
Why did those BP to you stop?

83
04:10.640 --> 04:16.600
Well the why is going to drive a couple of our conversations because there are

84
04:16.600 --> 04:17.340
a couple

85
04:17.340 --> 04:20.040
of different reasons why this might happen.

86
04:20.040 --> 04:23.670
And the solution is either going to involve a technology known as UDLD, unid

87
04:23.670 --> 04:24.360
irectional

88
04:24.360 --> 04:25.360
link detection.

89
04:25.360 --> 04:28.160
And that's what we're going to talk about here.

90
04:28.160 --> 04:33.300
Or we could possibly prevent this using another technique that we call loop
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

90
04:28.160 --> 04:33.300
Or we could possibly prevent this using another technique that we call loop

91
04:33.300 --> 04:34.280
guard.

92
04:34.280 --> 04:38.650
And so depending on the scenario, we're going to address that scenario with one

93
04:38.650 --> 04:39.200
of these

94
04:39.200 --> 04:40.560
techniques.

95
04:40.560 --> 04:44.360
Now we're going to go into those details, but we do have to pause for a moment

96
04:44.360 --> 04:44.780
and make

97
04:44.780 --> 04:48.720
sure we understand that this is problematic.

98
04:48.720 --> 04:55.210
Now real quick, we might say, okay, so if this is our scenario and the link

99
04:55.210 --> 04:56.160
stays up and

100
04:56.160 --> 05:00.660
yet I stop receiving BP to use, why wouldn't we just recognize this and put
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

100
04:56.160 --> 05:00.660
yet I stop receiving BP to use, why wouldn't we just recognize this and put

101
05:00.660 --> 05:01.440
this into the

102
05:01.440 --> 05:04.840
blocking state from a spanning tree perspective?

103
05:04.840 --> 05:11.040
Well the reason for that is because again, there could be a hub in here.

104
05:11.040 --> 05:15.440
And so if there's a hub in the middle and there's all kinds of hosts hanging

105
05:15.440 --> 05:16.040
off that

106
05:16.040 --> 05:22.620
hub and all of a sudden this link goes down upstream of the hub, well now this

107
05:22.620 --> 05:23.560
link down

108
05:23.560 --> 05:27.320
here stays online and I stopped receiving BP to use.

109
05:27.320 --> 05:31.870
If I immediately block that port using standard spanning tree, well then all of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

109
05:27.320 --> 05:31.870
If I immediately block that port using standard spanning tree, well then all of

110
05:31.870 --> 05:32.680
these hosts

111
05:32.680 --> 05:35.200
are going to lose their network connectivity.

112
05:35.200 --> 05:39.120
There goes the redundancy of having a link to two different switches.

113
05:39.120 --> 05:42.920
And so this is why spanning tree can't do anything about this.

114
05:42.920 --> 05:48.240
It's going to require us to be proactive with one of these two techniques to

115
05:48.240 --> 05:48.600
say, okay,

116
05:48.600 --> 05:51.650
yeah, it's great that spanning tree can't do anything about it because of the

117
05:51.650 --> 05:52.000
whole

118
05:52.000 --> 05:57.130
hub situation but I in the modern network, I can do something about it and I

119
05:57.130 --> 05:58.240
can recognize

120
05:58.240 --> 06:01.570
that, okay, assuming there's no hubs here and it doesn't have to be an
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

120
05:58.240 --> 06:01.570
that, okay, assuming there's no hubs here and it doesn't have to be an

121
06:01.570 --> 06:02.720
assumption and

122
06:02.720 --> 06:06.370
we'd confirm that there's no hubs there which again in the modern network is a

123
06:06.370 --> 06:06.880
given in

124
06:06.880 --> 06:08.880
most cases hopefully.

125
06:08.880 --> 06:12.910
But once we confirm there's no hubs in the network then we can go and deploy

126
06:12.910 --> 06:13.680
these different

127
06:13.680 --> 06:19.400
techniques and that will make sure that we don't cause a loop in that scenario.

128
06:19.400 --> 06:25.680
So let's talk about this why and specifically this conversation around UDLD.

129
06:25.680 --> 06:30.850
So one of the why's the ways that this could actually create a situation where
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

129
06:25.680 --> 06:30.850
So one of the why's the ways that this could actually create a situation where

130
06:30.850 --> 06:31.440
we stop

131
06:31.440 --> 06:36.680
BP views is known as a unidirectional link.

132
06:36.680 --> 06:41.120
A unidirectional link means that we can only speak in one direction.

133
06:41.120 --> 06:46.560
Hence una which means one there and directional is saying one direction.

134
06:46.560 --> 06:52.000
So the idea here is that we have two devices and let's say that this is the

135
06:52.000 --> 06:53.440
upstream switch

136
06:53.440 --> 06:59.510
and this is the downstream switch and we always are going to have two streams

137
06:59.510 --> 07:01.080
of communication.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
06:59.510 --> 07:01.080
of communication.

138
07:01.080 --> 07:05.020
I need to be able to send to the switch this way and the switch needs to be

139
07:05.020 --> 07:05.760
able to send

140
07:05.760 --> 07:07.480
back to me this way.

141
07:07.480 --> 07:10.000
Now usually this happens on a single connection.

142
07:10.000 --> 07:14.110
If that's a copper connection, we use different pairs in the copper in order to

143
07:14.110 --> 07:14.920
transmit and

144
07:14.920 --> 07:15.920
receive.

145
07:15.920 --> 07:19.560
However, what if this is fiber?

146
07:19.560 --> 07:22.440
Well fiber works with two strands in most cases.

147
07:22.440 --> 07:27.100
We've got a strand here, a strand here and one of those is going to support one

148
07:27.100 --> 07:27.880
direction

149
07:27.880 --> 07:30.720
and the other one is going to support the other direction.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

149
07:27.880 --> 07:30.720
and the other one is going to support the other direction.

150
07:30.720 --> 07:38.440
So if this is the upstream switch and I need to send a BP DU, it's going to go

151
07:38.440 --> 07:39.520
out here

152
07:39.520 --> 07:43.680
out the one fiber strand that I transmit on.

153
07:43.680 --> 07:47.880
And so the BP DU's get carried here on the top strand.

154
07:47.880 --> 07:53.110
So you can probably tell where we're going with this what happens if this top

155
07:53.110 --> 07:53.960
strand goes

156
07:53.960 --> 07:58.080
down but the bottom strand is A-OK.

157
07:58.080 --> 08:02.230
Well at this point we have a problem because this switch is trying to send BP
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

157
07:58.080 --> 08:02.230
Well at this point we have a problem because this switch is trying to send BP

158
08:02.230 --> 08:02.800
DU's but

159
08:02.800 --> 08:05.520
the downstream switch has stopped receiving them.

160
08:05.520 --> 08:10.700
Furthermore, this link is considered to be up simply because it can continue to

161
08:10.700 --> 08:11.920
send traffic

162
08:11.920 --> 08:13.840
if it so desires.

163
08:13.840 --> 08:16.960
This will indeed result in a loop.

164
08:16.960 --> 08:20.440
And so what could cause a unidirectional link?

165
08:20.440 --> 08:22.320
Well a lot of things.

166
08:22.320 --> 08:28.570
Certainly crimping fiber could actually cause that if we pull our fiber around

167
08:28.570 --> 08:29.480
a corner too

168
08:29.480 --> 08:33.360
hard or we're up in the ceiling and we tug on it too hard.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

168
08:29.480 --> 08:33.360
hard or we're up in the ceiling and we tug on it too hard.

169
08:33.360 --> 08:39.360
Maybe one of them gets crimped, maybe one of them actually gets snapped.

170
08:39.360 --> 08:41.920
And so there's lots of different options here.

171
08:41.920 --> 08:47.930
And so the concern is that these two switches have no awareness of the fact

172
08:47.930 --> 08:48.960
that this strand

173
08:48.960 --> 08:49.960
broke.

174
08:49.960 --> 08:53.220
And because all we did was we stopped receiving traffic but for all we know the

175
08:53.220 --> 08:53.760
upstream

176
08:53.760 --> 08:57.240
switch just stopped sending any traffic.

177
08:57.240 --> 09:03.720
So we need the ability to detect a unidirectional link.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

177
08:57.240 --> 09:03.720
So we need the ability to detect a unidirectional link.

178
09:03.720 --> 09:13.540
And that is going to lead us to unidirectional link detection which is a very

179
09:13.540 --> 09:14.240
appropriate

180
09:14.240 --> 09:16.120
name for what we're trying to do.

181
09:16.120 --> 09:20.640
We're trying to detect unidirectional links.

182
09:20.640 --> 09:24.960
And this is usually abbreviated as UDLD.

183
09:24.960 --> 09:31.440
Now by the way, this is a Cisco technique, a Cisco technology.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
09:24.960 --> 09:31.440
Now by the way, this is a Cisco technique, a Cisco technology.

184
09:31.440 --> 09:34.200
We're not going to find this on non-Cisco devices.

185
09:34.200 --> 09:39.360
So we're talking about UDLD as well as LoopGuard down here.

186
09:39.360 --> 09:43.400
Just like with BPU Guard and RootGuard, these are Cisco technologies.

187
09:43.400 --> 09:47.870
And so we're really focusing on this from the perspective that we are working

188
09:47.870 --> 09:48.280
on all

189
09:48.280 --> 09:50.240
Cisco devices.

190
09:50.240 --> 09:52.960
So what exactly does UDLD do?

191
09:52.960 --> 09:59.600
Well UDLD forces communication across a link by using KeepaLives.

192
09:59.600 --> 10:04.330
So now if we draw this back out and we've got our two different strands, yeah
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

192
09:59.600 --> 10:04.330
So now if we draw this back out and we've got our two different strands, yeah

193
10:04.330 --> 10:04.960
we're trying

194
10:04.960 --> 10:10.480
to send BPDUs out this way, but we're also sending KeepaLives.

195
10:10.480 --> 10:15.580
And so even if the BPDUs were to stop, let's say this whole thing breaks again,

196
10:15.580 --> 10:16.120
well yeah

197
10:16.120 --> 10:20.490
I stopped receiving BPDUs but that doesn't mean the link is down, but hey, I

198
10:20.490 --> 10:21.640
stopped receiving

199
10:21.640 --> 10:22.880
KeepaLives.

200
10:22.880 --> 10:26.360
If I stopped receiving KeepaLives then I know the link is down.

201
10:26.360 --> 10:30.670
We're forcing a constant stream of communication that tells us if that stream
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

201
10:26.360 --> 10:30.670
We're forcing a constant stream of communication that tells us if that stream

202
10:30.670 --> 10:31.680
of communication

203
10:31.680 --> 10:35.280
stops, that means that the link is unidirectional.

204
10:35.280 --> 10:39.380
Now here's a question, how does this switch on the left know that this one

205
10:39.380 --> 10:41.120
strand is down?

206
10:41.120 --> 10:43.870
Because if we're just sending KeepaLives on this link then we're going to think

207
10:43.870 --> 10:44.400
everything

208
10:44.400 --> 10:45.400
is fine.

209
10:45.400 --> 10:49.150
Well the reason why we can detect that the other strand is down is because we

210
10:49.150 --> 10:49.640
actually

211
10:49.640 --> 10:52.520
use the concept of echoing.

212
10:52.520 --> 10:56.860
Meaning that when I send a KeepaLive, this switch is responsible for bringing

213
10:56.860 --> 10:57.440
it in and

214
10:57.440 --> 10:59.560
looping it back around.

215
10:59.560 --> 11:04.800
And so this KeepaLive actually shows back up, thereby it allows each individual
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

215
10:59.560 --> 11:04.800
And so this KeepaLive actually shows back up, thereby it allows each individual

216
11:04.800 --> 11:05.360
switch

217
11:05.360 --> 11:08.440
to test both strands at the same time.

218
11:08.440 --> 11:12.440
So if this strand is down, these KeepaLives won't be showing up and therefore

219
11:12.440 --> 11:13.160
this switch

220
11:13.160 --> 11:16.360
also recognizes that there's a problem.

221
11:16.360 --> 11:20.000
So here's the question, what do these switches do when there's a problem?

222
11:20.000 --> 11:23.800
Well they are going to place the port into AirDisable.

223
11:23.800 --> 11:27.830
Just like with our BP-DU guard, it's going to shut these ports down and it's

224
11:27.830 --> 11:28.200
going to

225
11:28.200 --> 11:31.620
either require manual intervention or we're going to rely on automatic
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

225
11:28.200 --> 11:31.620
either require manual intervention or we're going to rely on automatic

226
11:31.620 --> 11:32.680
attempted recovery

227
11:32.680 --> 11:35.600
at least using AirDisable Recovery.

228
11:35.600 --> 11:39.230
But we can tell that this is treated very seriously because we are shutting the

229
11:39.230 --> 11:39.520
link

230
11:39.520 --> 11:40.840
down.

231
11:40.840 --> 11:45.830
Now one last interesting point here is that these Echoes, these KeepaLives,

232
11:45.830 --> 11:46.680
they're going

233
11:46.680 --> 11:48.960
to use a specific MAC address.

234
11:48.960 --> 11:54.760
And that MAC address is 0100 and then lots of Cs.

235
11:54.760 --> 11:58.000
C, C, C, C, C, C, C.

236
11:58.000 --> 12:00.480
Now why am I spelling out the MAC address here?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

236
11:58.000 --> 12:00.480
Now why am I spelling out the MAC address here?

237
12:00.480 --> 12:02.560
It's not so much that we want to memorize it.

238
12:02.560 --> 12:06.920
I don't expect this goes wanting us to be able to recognize the MAC address

239
12:06.920 --> 12:07.640
that's used

240
12:07.640 --> 12:08.640
by UDLD.

241
12:08.640 --> 12:14.020
However, the reason why I pointed out is because we can actually filter this

242
12:14.020 --> 12:15.800
MAC address using

243
12:15.800 --> 12:22.200
a MAC address access control list and that will allow us to test UDLD.

244
12:22.200 --> 12:25.790
It can be difficult to test something like UDLD because I don't really have a

245
12:25.790 --> 12:26.200
great

246
12:26.200 --> 12:30.410
way of going out even if I have physical devices and try to shut down one of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

246
12:26.200 --> 12:30.410
way of going out even if I have physical devices and try to shut down one of

247
12:30.410 --> 12:31.800
the strands.

248
12:31.800 --> 12:35.080
Maybe literally cut a fiber cable or something like that.

249
12:35.080 --> 12:39.520
I certainly know of people who have done that in the past to test UDLD.

250
12:39.520 --> 12:40.920
Well we don't actually have to do that.

251
12:40.920 --> 12:45.240
We can simply filter out the MAC address for the testing and that will allow us

252
12:45.240 --> 12:45.720
to see

253
12:45.720 --> 12:50.200
the unidirectional link's failure detection in action.

254
12:50.200 --> 12:54.060
But at the end of this whole conversation, again, let's make sure we understand

255
12:54.060 --> 12:54.920
the scenario

256
12:54.920 --> 13:02.100
that causes loops specifically are superior BPDUs stop coming in and therefore
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

256
12:54.920 --> 13:02.100
that causes loops specifically are superior BPDUs stop coming in and therefore

257
13:02.100 --> 13:02.880
we need

258
13:02.880 --> 13:07.310
to go against the native spanning tree behavior of saying, "Hey, let's just put

259
13:07.310 --> 13:07.680
that into

260
13:07.680 --> 13:08.680
forwarding state."

261
13:08.680 --> 13:12.200
Instead, we want to shut that link down to prevent a loop from occurring.

262
13:12.200 --> 13:22.200
[BLANK_AUDIO]