Hands-On Lab: Configuring Spanning Tree Protocol for Access Ports (PortFast)

This hands-on lab configures PortFast on an access port connecting to an end-user device, bypassing the normal listening and learning delay so the port forwards traffic immediately, and covers why PortFast should never be applied to a port connecting to another switch.

PortFast ConfigurationSTP Convergence DelayBPDU Guard

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Configure PortFast on an access port connecting to a PC, verify the port transitions directly to forwarding without the normal listening and learning delay, and enable BPDU Guard as a safety mechanism for that same port.

Lab Purpose

A normal access port takes 30-50 seconds to reach forwarding state, as observed in an earlier lab on STP port states — this delay is unnecessary and disruptive for end-user devices like PCs, which need immediate connectivity (for DHCP requests, for example) the moment they connect. PortFast eliminates this delay specifically for ports that will never connect to another switch.

Lab Topology

Switch1 ---- Gi1/0/8 ---- PC (end-user device only,
                          never a switch or hub)

Task 1: Observe Normal STP Delay Without PortFast

Shut down and re-enable Gi1/0/8 without PortFast configured, and time how long it takes to reach the forwarding state.

Task 2: Configure PortFast

Enable PortFast on Gi1/0/8.

Task 3: Verify Immediate Forwarding

Shut down and re-enable the port again, and confirm it now reaches forwarding state immediately.

Task 4: Enable BPDU Guard as a Safety Measure

Enable BPDU Guard on the same port to automatically disable it if a switch is ever mistakenly connected there instead of a PC.

Task 5: Verify BPDU Guard Triggers Appropriately

Simulate connecting a switch to this port (by connecting a device that sends BPDUs) and confirm the port is placed into err-disabled state.

Solution and Verification

Switch1(config)# interface gigabitethernet1/0/8
Switch1(config-if)# shutdown
Switch1(config-if)# no shutdown

Switch1# show spanning-tree interface gigabitethernet1/0/8
-- checked repeatedly: BLK -> LIS -> LRN -> FWD
-- taking the normal 30-50 second delay

Switch1(config)# interface gigabitethernet1/0/8
Switch1(config-if)# spanning-tree portfast

%Warning: portfast should only be enabled on ports
connected to a single host. Connecting hubs, concentrators,
switches, bridges, etc... to this interface when portfast
is enabled, can cause temporary bridging loops.

Switch1(config-if)# shutdown
Switch1(config-if)# no shutdown

Switch1# show spanning-tree interface gigabitethernet1/0/8

Interface        Role Sts Cost
Gi1/0/8          Desg FWD 4
-- Reaches Forwarding essentially instantly,
-- skipping Listening and Learning entirely

Switch1(config-if)# spanning-tree bpduguard enable

-- After connecting a device sending BPDUs
-- to this port:

Switch1# show interfaces gigabitethernet1/0/8 status

Gi1/0/8    err-disabled

Switch1# show spanning-tree interface gigabitethernet1/0/8 detail

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port
Gi1/0/8 with BPDU Guard enabled. Disabling port.

Key Takeaway

PortFast should only ever be configured on ports connecting exclusively to end-user devices — enabling it on a port that could receive a switch connection risks creating a temporary Layer 2 loop, discussed earlier in this series, before STP has a chance to detect it. Pairing PortFast with BPDU Guard closes this gap automatically: if a switch is ever mistakenly plugged into a PortFast port, the port shuts itself down the instant a BPDU is received, rather than allowing a loop to form.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه