Hands-On Lab: Configuring BPDU Guard and BPDU Filter

This hands-on lab configures BPDU Guard globally for PortFast-enabled ports and demonstrates the distinct, riskier behavior of BPDU Filter, comparing how each responds when a switch is connected to an access port that should only ever see end-user devices.

BPDU Guard ConfigurationBPDU Filter BehaviorPortFast Default Protection

~4 min read · Updated Sep 23, 2026

Lab Objective

Enable BPDU Guard globally so it automatically applies to every PortFast-enabled port, verify a connected switch triggers err-disable exactly as in the earlier PortFast lab, then separately configure BPDU Filter on a different port and observe its distinctly different, less protective behavior.

Lab Purpose

An earlier lab configured BPDU Guard per-interface. This lab shows the global configuration shortcut that automatically applies it to every PortFast port, and critically distinguishes BPDU Guard from BPDU Filter — two commands that sound similar but behave very differently, with the second carrying real risk if misunderstood.

Lab Topology

Switch1
  Gi1/0/5 ---- PortFast enabled, end-user only
  Gi1/0/6 ---- PortFast enabled, end-user only
               (will get BPDU Filter instead)

Task 1: Enable BPDU Guard Globally

Configure BPDU Guard to automatically apply to every PortFast-enabled interface, rather than configuring it individually per port.

Task 2: Enable PortFast on Both Ports

Configure PortFast on Gi1/0/5 and Gi1/0/6.

Task 3: Verify BPDU Guard Triggers on Gi1/0/5

Simulate a switch connecting to Gi1/0/5 and confirm the port becomes err-disabled, consistent with the earlier PortFast lab's behavior.

Task 4: Configure BPDU Filter on Gi1/0/6 Instead

Remove any BPDU Guard influence on Gi1/0/6 and configure BPDU Filter there instead.

Task 5: Simulate a Switch Connecting to Gi1/0/6

Connect a switch to Gi1/0/6 and observe the resulting behavior, comparing it against BPDU Guard's response.

Solution and Verification

Switch1(config)# spanning-tree portfast bpduguard default

-- Applies BPDU Guard automatically to every
-- interface with PortFast enabled, rather
-- than requiring the per-interface
-- "spanning-tree bpduguard enable" command
-- used in the earlier PortFast lab

Switch1(config)# interface gigabitethernet1/0/5
Switch1(config-if)# spanning-tree portfast
Switch1(config-if)# exit
Switch1(config)# interface gigabitethernet1/0/6
Switch1(config-if)# spanning-tree portfast

-- Simulated switch connects to Gi1/0/5,
-- sending BPDUs:

Switch1# show interfaces gigabitethernet1/0/5 status

Gi1/0/5    err-disabled

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

%SPANTREE-2-BLOCK_BPDUGUARD: Received BPDU on port
Gi1/0/5 with BPDU Guard enabled. Disabling port.
-- Identical protective behavior to the
-- earlier per-interface configuration --
-- the global command simply saved having
-- to type it on every PortFast port
-- individually

Switch1(config)# interface gigabitethernet1/0/6
Switch1(config-if)# spanning-tree bpdufilter enable

-- If BPDU Guard's global default was
-- somehow also affecting this port, this
-- explicit filter command takes precedence
-- on this specific interface

-- Simulated switch connects to Gi1/0/6,
-- sending BPDUs:

Switch1# show interfaces gigabitethernet1/0/6 status

Gi1/0/6    connected
-- The port remains UP and forwarding,
-- despite a switch (capable of causing
-- a loop) now being connected

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

Interface        Role Sts Cost
Gi1/0/6          Desg FWD 4
-- BPDU Filter does not shut the port down
-- at all -- it simply stops the switch
-- itself from sending OR processing BPDUs
-- on this port, silently ignoring the
-- rogue switch's BPDUs rather than reacting
-- to them protectively

Key Takeaway

BPDU Guard and BPDU Filter sound similar but behave in opposite spirit: BPDU Guard actively protects the network by disabling a port the instant it detects a switch was connected where only an end device was expected, while BPDU Filter simply stops participating in BPDU exchange on that port entirely — silently disabling loop protection rather than enforcing it, which can allow an actual Layer 2 loop to form completely undetected if a switch is genuinely connected there. BPDU Filter should be used with extreme caution and only when its specific behavior is fully understood.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring UDLD

This hands-on lab configures UDLD in aggressive mode on a fiber link between two switches, simulating a unidirectional fiber failure and verifying UDLD detects the mismatch and shuts down the affected port before a Layer 2 loop can form.

Continue

Hands-On Lab: Configuring Loop Guard

This hands-on lab configures Loop Guard on a switch's non-designated ports to prevent a unidirectional link failure from causing a Layer 2 loop, simulating a one-way BPDU loss and verifying the affected port enters a loop-inconsistent blocking state rather than incorrectly transitioning to forwarding.

Continue

Hands-On Lab: Configuring Root Guard

This hands-on lab configures Root Guard on switch ports facing access-layer switches to prevent an unauthorized or misconfigured switch from becoming the Spanning Tree root, verifying the port enters a root-inconsistent state when a superior BPDU is received.

Continue

Hands-On Lab: Comprehensive Troubleshooting Challenge

This hands-on lab presents a multi-layer connectivity failure across VLANs, trunking, routing, and NAT simultaneously, requiring systematic bottom-up troubleshooting to identify and correct three independent faults before full connectivity is restored.

Continue

Hands-On Lab: Configuring Enhanced Object Tracking with HSRP

This hands-on lab configures IP SLA-based object tracking on an HSRP-enabled router, automatically lowering its priority when its WAN uplink fails, forcing failover to the standby router without requiring a full interface shutdown.

Continue

Hands-On Lab: Configuring Basic DMVPN (mGRE with NHRP)

This hands-on lab configures a basic single-hub DMVPN topology using a multipoint GRE tunnel and NHRP, demonstrating how a spoke dynamically registers its physical address with the hub without requiring a separate point-to-point tunnel per spoke.

Continue