WEBVTT

1
00:00.000 --> 00:05.640
Well, in the last skill, we just took a look at a situation where we had switch

2
00:05.640 --> 00:11.460
one as the root and then we saw this indirect failure concept and this is

3
00:11.460 --> 00:16.000
where the max age timer really came into play because switch three or rather

4
00:16.000 --> 00:19.680
switch two over here, switch three was on the right, switch two had a failure

5
00:19.680 --> 00:20.040
and

6
00:20.040 --> 00:25.080
it's uplink on here but switch three had lost that battle I suppose if you

7
00:25.080 --> 00:28.840
want to call it that with switch two and it placed its port into the blocking

8
00:28.840 --> 00:34.760
state and because switch two try sending now superior BPDUs having lost its
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:28.840 --> 00:34.760
state and because switch two try sending now superior BPDUs having lost its

9
00:34.760 --> 00:38.760
root port and now thinks it's the root switch three is just going to ignore

10
00:38.760 --> 00:44.200
these superior BPDUs until the max age timer has expired at which point it

11
00:44.200 --> 00:49.720
says hey that original BPDU has now timed out that takes 20 seconds at that

12
00:49.720 --> 00:56.640
point we transition from blocking to whoops listening to learning and this

13
00:56.640 --> 00:56.880
whole

14
00:56.880 --> 01:02.280
process takes 30 seconds so 20 seconds to detect plus 30 seconds means we're
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

14
00:56.880 --> 01:02.280
process takes 30 seconds so 20 seconds to detect plus 30 seconds means we're

15
01:02.280 --> 01:08.200
down for 50 seconds so that the end of the day the max age timer is going to

16
01:08.200 --> 01:12.720
help us out here but it does take some time for us to come back online and so

17
01:12.720 --> 01:17.360
what we transition to from a topology perspective looks like this where we have

18
01:17.360 --> 01:24.400
switch one connecting to switch three and then switch two over here now let's

19
01:24.400 --> 01:24.560
look

20
01:24.560 --> 01:29.440
at this scenario in a little bit greater detail because what we just said is

21
01:29.440 --> 01:29.880
that

22
01:29.880 --> 01:36.240
we have now failed over but we have a different aspect of layer two to keep in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

22
01:29.880 --> 01:36.240
we have now failed over but we have a different aspect of layer two to keep in

23
01:36.240 --> 01:43.120
mind me specifically what happens when we have hosts hanging off of switch two

24
01:43.120 --> 01:43.680
so

25
01:43.680 --> 01:48.440
they were up here in this situation as well and so we have MAC address A and

26
01:48.440 --> 01:54.520
MAC address B looking up here at the original topology if I got a path

27
01:54.520 --> 02:00.480
back it in before everything went down and it was destined for MAC address A
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

27
01:54.520 --> 02:00.480
back it in before everything went down and it was destined for MAC address A

28
02:00.480 --> 02:05.560
where would switch three send it well if switch three knows where MAC address A

29
02:05.560 --> 02:09.360
lives and eventually it will so let's just assume that it does know it's going

30
02:09.360 --> 02:14.480
to point out this way because this port here is blocked meaning that this path

31
02:14.480 --> 02:18.760
goes around like this which is perfectly fine we're not looking for

32
02:18.760 --> 02:22.800
efficiency here we're we're looking for loop prevention and we have prevented

33
02:22.800 --> 02:27.000
this loop and so yeah we go up through switch one down to switch two which

34
02:27.000 --> 02:27.240
means

35
02:27.240 --> 02:32.320
I have an entry in here that points towards let's just say this is gig zero
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
02:27.240 --> 02:32.320
I have an entry in here that points towards let's just say this is gig zero

36
02:32.320 --> 02:37.280
zero on this network so I point to gig zero zero which is going to take me to

37
02:37.280 --> 02:43.840
switch one well now that we have failed over what does the cam table look like

38
02:43.840 --> 02:49.460
here on switch three well it without any other mechanisms at play it's not

39
02:49.460 --> 02:49.560
going

40
02:49.560 --> 02:57.040
to change if I get a packet in here destined for MAC address A it's still

41
02:57.040 --> 03:02.200
going to see MAC address A living out gig zero zero so what's it going to do
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

41
02:57.040 --> 03:02.200
going to see MAC address A living out gig zero zero so what's it going to do

42
03:02.200 --> 03:06.320
it's going to send it up to switch one and switch one's going to say well wait

43
03:06.320 --> 03:06.360
a

44
03:06.360 --> 03:11.760
second I showed that it was out this port this port is down therefore I have no

45
03:11.760 --> 03:17.000
location for it so what does a switch do when it doesn't have an entry for a

46
03:17.000 --> 03:20.050
MAC address it's going to flood it out so it's going to flood it out all of

47
03:20.050 --> 03:20.200
these

48
03:20.200 --> 03:25.000
ports but the rule is I can't flood it back out the same port that I received

49
03:25.000 --> 03:29.560
it on which means it's never going to find it this traffic is just going to

50
03:29.560 --> 03:34.160
go to switch one yeah technically get flooded out but ultimately it's just
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
03:29.560 --> 03:34.160
go to switch one yeah technically get flooded out but ultimately it's just

51
03:34.160 --> 03:39.240
going to get dropped it's going to hit a dead end at switch one it will never

52
03:39.240 --> 03:45.800
get down here to where the host actually lives this right here this entry is a

53
03:45.800 --> 03:52.060
problem because that MAC address no longer lives out gig zero slash zero and

54
03:52.060 --> 03:52.200
the

55
03:52.200 --> 03:59.560
reason it no longer lives out there is because there was a topology change any

56
03:59.560 --> 04:05.160
time we have a topology change it's entirely possible that our cam table
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

56
03:59.560 --> 04:05.160
time we have a topology change it's entirely possible that our cam table

57
04:05.160 --> 04:09.560
entries our MAC address entries are out of date and therefore we need to do

58
04:09.560 --> 04:15.000
something about this because there is a scenario where host A here MAC address

59
04:15.000 --> 04:21.400
A is just listening so if it's just listening for traffic meaning it's not

60
04:21.400 --> 04:26.000
generating traffic well then we're going to be sitting here listening for and

61
04:26.000 --> 04:32.840
waiting for a long time a standard cam timeout by default at least on Cisco
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

61
04:26.000 --> 04:32.840
waiting for a long time a standard cam timeout by default at least on Cisco

62
04:32.840 --> 04:37.960
switches is 300 seconds which is five minutes so we're going to have to wait

63
04:37.960 --> 04:43.560
potentially all the way up to 300 seconds for me to time this entry out

64
04:43.560 --> 04:49.320
having not gotten a packet from MAC address A this entire time and then I

65
04:49.320 --> 04:53.880
can start to flood this out and eventually that traffic will be received

66
04:53.880 --> 04:59.410
again now just to get it out of the way yes if MAC address A is not just

67
04:59.410 --> 04:59.800
listening

68
04:59.800 --> 05:04.440
but also sending traffic then switch three will get this packet and update the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

68
04:59.800 --> 05:04.440
but also sending traffic then switch three will get this packet and update the

69
05:04.440 --> 05:08.920
entry and we won't have to wait but the reality is that yeah we waited 50

70
05:08.920 --> 05:13.080
seconds for this to come back online we might have to wait a whole lot longer

71
05:13.080 --> 05:17.760
for it to come online if that host is not generating traffic if I'm generating

72
05:17.760 --> 05:21.080
traffic towards that host and it doesn't even know somebody's trying to

73
05:21.080 --> 05:25.240
communicate and so it's not sending any traffic at all at that point we're

74
05:25.240 --> 05:25.400
going

75
05:25.400 --> 05:30.520
to be stuck in a really bad place so we need to do something about this
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
05:25.400 --> 05:30.520
to be stuck in a really bad place so we need to do something about this

76
05:30.520 --> 05:34.560
topology change and there are two specific situations that we're going to

77
05:34.560 --> 05:39.560
register something as a topology change the first situation is if a port

78
05:39.560 --> 05:45.640
transitions into the forwarding state and the other possibility is that a port

79
05:45.640 --> 05:52.040
transitioned from either learning or forwarding to blocking in either of

80
05:52.040 --> 05:57.760
these specific situations we might find that there is a scenario kind of like

81
05:57.760 --> 06:01.920
this happening where we end up black-holding traffic sending traffic off to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
05:57.760 --> 06:01.920
this happening where we end up black-holding traffic sending traffic off to

82
06:01.920 --> 06:06.560
get dropped so these two situations are going to lead us to declaring that

83
06:06.560 --> 06:11.760
there has been a topology change on the network so what we need to do now is we

84
06:11.760 --> 06:16.200
need to notify the network so we can take action and what better way to

85
06:16.200 --> 06:22.840
notify the network of a topology change then with a topology change

86
06:22.840 --> 06:34.400
notification which we typically abbreviate as a TCN TCN's are a mission
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

86
06:22.840 --> 06:34.400
notification which we typically abbreviate as a TCN TCN's are a mission

87
06:34.400 --> 06:39.080
critical part of spanning tree protocol operation and not just important with

88
06:39.080 --> 06:43.280
traditional spanning tree but also very important with rapid spanning tree so

89
06:43.280 --> 06:43.600
as

90
06:43.600 --> 06:46.920
with a lot of the other concepts that we've talked about we're going to really

91
06:46.920 --> 06:50.000
learn how it works with traditional spanning tree when we get to rapid

92
06:50.000 --> 06:53.640
spanning tree we'll learn that there are a few differences but foundationally

93
06:53.640 --> 06:53.800
the

94
06:53.800 --> 06:58.320
concept is the same we need to alert the network that there's been a change so

95
06:58.320 --> 07:02.960
that we can update MAC address entries in our cam tables otherwise we might end
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

95
06:58.320 --> 07:02.960
that we can update MAC address entries in our cam tables otherwise we might end

96
07:02.960 --> 07:07.720
up sending traffic the wrong direction so let's look at our situation we had

97
07:07.720 --> 07:15.520
switch 3 and switch 3 took a port and transitioned that port to forwarding this

98
07:15.520 --> 07:21.880
qualifies as a topology change and so switch 3 is going to be responsible for

99
07:21.880 --> 07:30.160
sending a TCN now what exactly is a TCN well this is a bridge protocol data
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
07:21.880 --> 07:30.160
sending a TCN now what exactly is a TCN well this is a bridge protocol data

100
07:30.160 --> 07:34.800
unit so we talk about BP to use being sent by the root and and they usually

101
07:34.800 --> 07:39.760
always flow downstream when we're talking about standard BP to use well

102
07:39.760 --> 07:48.600
this is a TCN BP to you and it's going to flow upstream the goal is to get to

103
07:48.600 --> 07:49.120
the

104
07:49.120 --> 07:54.360
root because in traditional spanning tree we need the root to be aware that

105
07:54.360 --> 07:58.480
there was a topology change so it can alert the rest of the network so it's

106
07:58.480 --> 08:03.440
going to look something like this we have our broken topology here where we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

106
07:58.480 --> 08:03.440
going to look something like this we have our broken topology here where we

107
08:03.440 --> 08:03.560
have

108
08:03.560 --> 08:12.800
switches 1 2 and 3 and switch 3 is going to send a TCN BP to out its root port

109
08:12.800 --> 08:19.320
the port that is the closest port to the root and if there were other switches

110
08:19.320 --> 08:19.560
in

111
08:19.560 --> 08:23.320
the path then it would continue to get forwarded upstream as well in our case

112
08:23.320 --> 08:28.800
it just needed to go one hop before it got to the root so next the root is

113
08:28.800 --> 08:29.080
going

114
08:29.080 --> 08:39.320
to be responsible for setting a TCN flag inside of the BP to you now we just
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

114
08:29.080 --> 08:39.320
to be responsible for setting a TCN flag inside of the BP to you now we just

115
08:39.320 --> 08:44.440
introduced the concept of a new BP to you we call it the TCN BP to you well the

116
08:44.440 --> 08:49.320
standard BP to you is known as a configuration BP to you and so we can

117
08:49.320 --> 08:53.240
start to distinguish between these usually if we just say hey we're sending

118
08:53.240 --> 08:57.200
BP to use we're talking about configuration BP to use but in this

119
08:57.200 --> 09:01.000
specific case we see that we have a TCN BP to you and so it's worth
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

119
08:57.200 --> 09:01.000
specific case we see that we have a TCN BP to you and so it's worth

120
09:01.000 --> 09:06.040
differentiating between the two so then what's going to happen is we're going

121
09:06.040 --> 09:06.280
to

122
09:06.280 --> 09:10.920
set again this flag so that the normal flow of BP to use which right now looks

123
09:10.920 --> 09:19.280
like this these would be our standard or our config BP to use this is a normal

124
09:19.280 --> 09:23.200
part of the process we just send these every two seconds or whatever the hello

125
09:23.200 --> 09:29.320
timer is and so the next BP to you that I send there's a flag just a single bit

126
09:29.320 --> 09:33.840
that's going to be set that says that hey there has been a topology change and
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

126
09:29.320 --> 09:33.840
that's going to be set that says that hey there has been a topology change and

127
09:33.840 --> 09:37.960
so I set that bit inside of the BP to you so when the normal BP to you is

128
09:37.960 --> 09:43.440
received and propagated down everybody's going to be aware that there was a

129
09:43.440 --> 09:51.240
change so what happens when we have a change detected well again we need to

130
09:51.240 --> 09:57.640
make sure that we're solving this problem with the timeout it's way too long

131
09:57.640 --> 09:57.960
and

132
09:57.960 --> 10:05.960
so what we're going to do is we're going to set our cam table timeouts equal to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
09:57.960 --> 10:05.960
so what we're going to do is we're going to set our cam table timeouts equal to

133
10:05.960 --> 10:14.720
the forward delay timer by default that is 15 seconds so we're going to change

134
10:14.720 --> 10:20.960
it from 300 and put it at 15 seconds and if our forward delay timer happens to

135
10:20.960 --> 10:24.280
be 10 seconds then it would set it to 10 seconds but for now we'll just assume

136
10:24.280 --> 10:29.880
that it's the default setting so we set it to 15 seconds which means that

137
10:29.880 --> 10:34.760
whether it's a 50 second failover process or simply 15 seconds of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
10:29.880 --> 10:34.760
whether it's a 50 second failover process or simply 15 seconds of

138
10:34.760 --> 10:39.600
transitioning from learning to forwarding either way in those situations the

139
10:39.600 --> 10:44.720
timeout has already happened if I haven't gotten a MAC address update from a

140
10:44.720 --> 10:50.640
particular entry then I'm going to time that out before the network even comes

141
10:50.640 --> 10:56.520
back online in its new state so that is the idea so once again our topology

142
10:56.520 --> 10:56.960
here

143
10:56.960 --> 11:02.800
we know that we have MAC address A living out switch to switch three thinks
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

143
10:56.960 --> 11:02.800
we know that we have MAC address A living out switch to switch three thinks

144
11:02.800 --> 11:08.480
that MAC address A lives out towards switch one like it used to and let's

145
11:08.480 --> 11:13.000
say that the timeout is you know maybe it's counting down it's at about 210

146
11:13.000 --> 11:20.400
seconds well as soon as I receive a TCN this timeout is going to go to 15

147
11:20.400 --> 11:25.360
seconds and start counting down meanwhile I'm transitioning from listening to

148
11:25.360 --> 11:31.320
learning on this port here and this is going to take 30 seconds so by the time
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

148
11:25.360 --> 11:31.320
learning on this port here and this is going to take 30 seconds so by the time

149
11:31.320 --> 11:36.400
this port comes online I have flushed this entry I've said I don't actually

150
11:36.400 --> 11:42.600
have a location for A anymore because 15 seconds have now passed now when I

151
11:42.600 --> 11:46.480
receive a packet on switch three destined for port A I'm going to flood it out

152
11:46.480 --> 11:51.480
both of these links which will eventually get to port A or MAC address A and

153
11:51.480 --> 11:57.120
ideally MAC address A responds and lets everybody know where it now lives now

154
11:57.120 --> 12:02.880
just to wrap up this conversation there is one big caveat to consider as we
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

154
11:57.120 --> 12:02.880
just to wrap up this conversation there is one big caveat to consider as we

155
12:02.880 --> 12:09.360
move forward and that is what about edge ports because this topology change

156
12:09.360 --> 12:15.000
notification is very important we absolutely have to have it and we have

157
12:15.000 --> 12:20.560
defined our topology changes like this but notice a port going into the

158
12:20.560 --> 12:24.640
forwarding state you know what else triggers a port going into the forwarding

159
12:24.640 --> 12:29.880
state connecting a laptop to a switch port at which point the port turns into

160
12:29.880 --> 12:33.800
a forwarding port now we know there's no topology change that is an end host
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

160
12:29.880 --> 12:33.800
a forwarding port now we know there's no topology change that is an end host

161
12:33.800 --> 12:39.200
that's at the very edge of the network and so these edge ports by default are

162
12:39.200 --> 12:46.400
going to create topology change notifications and this is not okay

163
12:46.400 --> 12:52.680
because if we think about a large network then we're going to see that we

164
12:52.680 --> 12:58.040
constantly have people turning on PCs and turning off PCs and plugging in

165
12:58.040 --> 13:03.160
laptops and unplugging laptops and so 802.1d spanning tree by default doesn't
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

165
12:58.040 --> 13:03.160
laptops and unplugging laptops and so 802.1d spanning tree by default doesn't

166
13:03.160 --> 13:07.000
account for edge ports meaning we're constantly going to be sending DC ends

167
13:07.000 --> 13:10.800
out which means we're constantly going to be operating with MAC timeouts in the

168
13:10.800 --> 13:14.840
entire network at 15 seconds which is going to create a whole lot more flooding

169
13:14.840 --> 13:20.800
because MAC addresses will time out far more often so this is a problem that

170
13:20.800 --> 13:26.120
needs to be resolved and we're going to resolve that problem in the next video