WEBVTT

0:00:03.160000 --> 0:00:09.100000
 In this video, I'd like to do a quick
 recap of port fast and edge ports.

0:00:09.100000 --> 0:00:15.980000
 So access ports, you know, you go onto
 a switch, you can type switch port

0:00:15.980000 --> 0:00:19.360000
 mode access. Well you typically do that
 when that port is connecting to

0:00:19.360000 --> 0:00:25.940000
 a host, like a laptop, a server,
 maybe even a router.

0:00:25.940000 --> 0:00:33.620000
 So the problem with a normal access
 port is that that port is trying to

0:00:33.620000 --> 0:00:38.060000
 do spanning tree, it's sending out BPDUs,
 it's trying to listen for BPDUs,

0:00:38.060000 --> 0:00:42.320000
 but the device connected to that access
 port isn't doing spanning tree,

0:00:42.320000 --> 0:00:45.200000
 your laptop, your PC, your server.


0:00:45.200000 --> 0:00:48.580000
 They don't do spanning tree, so they're
 never going to respond back with

0:00:48.580000 --> 0:00:53.340000
 a BPDU. So that access port is going
 to go through the forwarding delay

0:00:53.340000 --> 0:00:58.060000
 a couple of times go through listening
 and learning before it can finally

0:00:58.060000 --> 0:01:00.240000
 go into the forwarding state.

0:01:00.240000 --> 0:01:05.340000
 Well end users, your laptop, your PC,
 you don't want to wait that 30 plus

0:01:05.340000 --> 0:01:09.060000
 seconds for the switch port to go into
 the forwarding state before you

0:01:09.060000 --> 0:01:13.600000
 can proceed on with doing DHCP and
 everything else that you do.

0:01:13.600000 --> 0:01:16.260000
 So port fast was designed
 to speed up this process.

0:01:16.260000 --> 0:01:20.420000
 When you enable the port fast feature
 on your interface, it will instantly

0:01:20.420000 --> 0:01:22.340000
 go into the forwarding state.

0:01:22.340000 --> 0:01:26.600000
 It won't wait around to see
 if a BPDU is received.

0:01:26.600000 --> 0:01:30.420000
 Like it says, port fast should not
 be used on trunk interfaces unless

0:01:30.420000 --> 0:01:35.100000
 you're certain that the device on the
 other side of that trunk is not

0:01:35.100000 --> 0:01:36.860000
 going to cause a bridging loop.

0:01:36.860000 --> 0:01:40.860000
 Like if you're trunking from a switch
 to a router, that type of trunk,

0:01:40.860000 --> 0:01:44.700000
 yes, you could do port fast on it.


0:01:44.700000 --> 0:01:49.080000
 Now rapid spanning tree sees ports
 that have been configured with port

0:01:49.080000 --> 0:01:52.180000
 fast as what's called edge ports.

0:01:52.180000 --> 0:01:55.700000
 And these ports are not affected by rapid
 spanning tree topology changes.

0:01:55.700000 --> 0:01:59.620000
 So you can see right here in the output,
 rapid spanning tree sees that

0:01:59.620000 --> 0:02:03.760000
 we have an interface right here,
 which has port fast configured.

0:02:03.760000 --> 0:02:06.680000
 So that's seen as an edge port.

0:02:06.680000 --> 0:02:12.000000
 So when an if a topology change occurs,
 it will not, it'll be treated

0:02:12.000000 --> 0:02:14.280000
 differently on that edge port.

0:02:14.280000 --> 0:02:19.360000
 So how do we configure port fast?

0:02:19.360000 --> 0:02:23.040000
 Well, the classic way is to go into
 the interface and just say spanning

0:02:23.040000 --> 0:02:24.740000
 dash tree port fast.

0:02:24.740000 --> 0:02:27.860000
 Alternatively, at the global configuration
 level, you could say spanning

0:02:27.860000 --> 0:02:31.960000
 tree port fast default and any port
 which is currently operational as

0:02:31.960000 --> 0:02:35.600000
 an access port will have
 port fast applied.

0:02:35.600000 --> 0:02:37.920000
 How do you verify it?

0:02:37.920000 --> 0:02:42.180000
 Show spanning dash tree interface
 followed by the word port fast.

0:02:42.180000 --> 0:02:47.460000
 So that concludes this refresher and
 review of what port fast is and how

0:02:47.460000 --> 0:02:50.980000
 rapid spanning tree classifies
 it as an edge port.