WEBVTT

0:00:02.640000 --> 0:00:05.940000
 Welcome to this video in which I'm going
 to do a quick refresher of the

0:00:05.940000 --> 0:00:09.180000
 rapid spanning tree timers.

0:00:09.180000 --> 0:00:15.360000
 Now the hello timer in rapid spanning
 tree is exactly the same as the

0:00:15.360000 --> 0:00:18.660000
 hello timer in its precursor
 of classic spanning tree.

0:00:18.660000 --> 0:00:24.580000
 This dictates how frequently BPDUs are
 generated and it has not changed.

0:00:24.580000 --> 0:00:26.260000
 It is every two seconds
 by default.

0:00:26.260000 --> 0:00:29.680000
 This is something that you can configure
 and you can see right here.

0:00:29.680000 --> 0:00:31.660000
 Here is the configuration command.


0:00:31.660000 --> 0:00:35.780000
 Should you want to
 modify this timer?

0:00:35.780000 --> 0:00:43.240000
 Folding delay. Okay, now the folding
 delay timer is only used for non

0:00:43.240000 --> 0:00:46.400000
 edge host port to control
 their transition delays.

0:00:46.400000 --> 0:00:49.380000
 Now what is a non edge host port?

0:00:49.380000 --> 0:00:54.360000
 Remember, what is that edge port in
 rapid spanning terminology when you

0:00:54.360000 --> 0:00:57.500000
 enable port fast on an interface?

0:00:57.500000 --> 0:01:01.300000
 Rapid spanning tree sees
 that as an edge port.

0:01:01.300000 --> 0:01:05.120000
 So what we're talking about is a port
 that does not have port fast turned

0:01:05.120000 --> 0:01:08.960000
 on it. So basically a port typically
 leading to another switch.

0:01:08.960000 --> 0:01:12.220000
 So an inter switch connection
 would not have port fast.

0:01:12.220000 --> 0:01:15.340000
 We consider that a non edge port.

0:01:15.340000 --> 0:01:22.720000
 Now typically switch to switch connections
 would be full duplex.

0:01:22.720000 --> 0:01:25.060000
 That would be their duplex.

0:01:25.060000 --> 0:01:28.340000
 They don't rely on the
 folding delay timer.

0:01:28.340000 --> 0:01:31.680000
 Rapid spanning tree actually has some
 flags, some control flags called

0:01:31.680000 --> 0:01:34.240000
 the proposal and agreement flags.

0:01:34.240000 --> 0:01:39.800000
 And by utilizing those flags which can
 only be used on full duplex links,

0:01:39.800000 --> 0:01:43.240000
 it can actually transition to the folding
 state in a matter of a second

0:01:43.240000 --> 0:01:47.980000
 or two. So it doesn't even listen to
 any timers to determine how quickly

0:01:47.980000 --> 0:01:51.700000
 that interface is going to come up and
 go into the folding state or possibly

0:01:51.700000 --> 0:01:54.600000
 go into folding blocking
 as a case may be.

0:01:54.600000 --> 0:01:57.920000
 Only if we have a non
 edge connection.

0:01:57.920000 --> 0:02:03.580000
 So a switch to switch connection
 that is half duplex.

0:02:03.580000 --> 0:02:07.020000
 That would be considered a shared links
 that would show up not as point

0:02:07.020000 --> 0:02:10.560000
 to point, but as shared in
 a shared link environment.

0:02:10.560000 --> 0:02:14.340000
 Then rapid spanning tree has to fall
 back to using the same old timers,

0:02:14.340000 --> 0:02:17.960000
 the classic spanning tree used, which
 in this case would use the folding

0:02:17.960000 --> 0:02:22.420000
 delay. This is configurable
 by default.

0:02:22.420000 --> 0:02:25.820000
 It's 15 seconds.

0:02:25.820000 --> 0:02:32.420000
 The max age timer once again, not
 used in rapid spanning tree.

0:02:32.420000 --> 0:02:35.100000
 This is a carryover from 802.1 D.

0:02:35.100000 --> 0:02:42.080000
 20 seconds by default only used once
 again in a shared duplex environment.

0:02:42.080000 --> 0:02:46.480000
 But typically you will
 not see that used.

0:02:46.480000 --> 0:02:48.700000
 And message age.

0:02:48.700000 --> 0:02:52.280000
 So this is the last timer
 I want to talk about.

0:02:52.280000 --> 0:02:56.220000
 This is used as a basic hop count for
 rapid spanning tree, a sort of a

0:02:56.220000 --> 0:03:03.580000
 delimiter as far as how far can Bp'd use
 go once they leave the root bridge.

0:03:03.580000 --> 0:03:06.900000
 So message age starts at zero
 from the root bridge.

0:03:06.900000 --> 0:03:10.280000
 So when the root bridge is creating
 fresh new Bp'd use and popping them

0:03:10.280000 --> 0:03:15.100000
 out, the message age is zero and then
 is incremented by one as we go through

0:03:15.100000 --> 0:03:19.260000
 each switch. So you could sort of think
 of this as like a reverse time

0:03:19.260000 --> 0:03:23.280000
 to live, right? With time to live,
 the original starts out with a time

0:03:23.280000 --> 0:03:27.080000
 to live in the IP header of some nonzero
 number that decreases by one

0:03:27.080000 --> 0:03:29.380000
 as it goes from router to router.

0:03:29.380000 --> 0:03:31.300000
 Well, here it's just the opposite.


0:03:31.300000 --> 0:03:33.020000
 Starts out as zero and goes up.

0:03:33.020000 --> 0:03:40.180000
 Now, if a Bp'd is received by a switch
 and the max age is the same as

0:03:40.180000 --> 0:03:41.200000
 the message age.

0:03:41.200000 --> 0:03:48.060000
 So if the message age is equal to
 zero, then that Bp'd is discarded.

0:03:48.060000 --> 0:03:52.280000
 So that's it. Those are the timers
 you need to be familiar with as far

0:03:52.280000 --> 0:03:55.960000
 as rapid spanning tree are concerned,
 how they're utilized and what their

0:03:55.960000 --> 0:03:56.960000
 default values are.