BPDU guard: shutting edge ports that hear spanning tree

BPDU guard shuts down a switch port the moment it receives a spanning tree BPDU, on the reasoning that a port facing a single PC, phone or server should never hear one. If it does, something that speaks spanning tree, or a loop back to the switch itself, has appeared where only a host belongs, and disabling the port is safer than letting the topology change.

It is a per-port protection that sits on top of spanning tree and its edge ports. This page explains what it reacts to, how it differs from BPDU filter, root guard and loop guard, how to enable it globally or per interface, how ports come back, and the mistakes that turn it into an outage. Syntax follows Cisco IOS from the Catalyst optional spanning-tree features guide, which is still the clearest description of the behaviour.

01 /Why do edge ports need BPDU guard?

Spanning tree lets a host port skip the slow listening and learning states. Classic Cisco calls this PortFast; the IEEE term, now in IEEE 802.1Q-2022 alongside RSTP and MSTP, is an edge port. An edge port goes straight to forwarding when the link comes up, so a PC gets its DHCP lease without waiting 30 seconds, and it does not trigger a topology change when the PC reboots.

That speed assumes the port leads to an end station. Under the standard, an edge port that receives a BPDU simply stops being an edge port and joins the spanning tree negotiation. That is correct protocol behaviour, but in an access closet it means a user can plug in a switch and take part in your topology: if the new switch has a lower bridge priority, it can become the root, and traffic for the whole Layer 2 domain re-converges around a device under a desk.

BPDU guard is the stricter answer. It is a vendor feature rather than an IEEE mechanism: instead of letting the port join the tree, the switch error-disables it. The Cisco guide describes it as a secure response to invalid configurations, because someone must put the port back in service manually.

02 /What actually triggers BPDU guard?

• A managed or smart switch plugged into a desk port. These run spanning tree by default and send BPDUs as soon as their link comes up.
• A loop through a hub or unmanaged switch. Many unmanaged switches do not run spanning tree, so they send no BPDUs of their own. But if a user patches two wall ports into the same unmanaged switch, your switch's own BPDUs leave one port and arrive on the other. BPDU guard fires and breaks the loop, which is one of its most useful jobs.
• A server or hypervisor bridging two NICs with spanning tree enabled, or a virtual switch configured to forward BPDUs between physical uplinks.
• An access point or IP phone with a bridging bug or an unusual configuration. Rare, but worth checking before you blame the user.

BPDU guard does not see an unmanaged switch with no loop behind it, because that switch sends no BPDUs. Limiting how many MAC addresses a port may learn, covered by port security, or authenticating the port with 802.1X on access ports, catches those.

03 /How is BPDU guard different from BPDU filter, root guard and loop guard?

The Cisco guide carries a caution worth repeating: enabling BPDU filtering on an interface is the same as disabling spanning tree on it and can result in loops. An interface-level filter also stops the port processing BPDUs at all, which means BPDU guard on the same port never sees one. Choose one.

04 /How to enable BPDU guard

There are two ways to switch it on, and they behave differently. Globally, spanning-tree portfast bpduguard default applies BPDU guard to every port that is operating as PortFast. Per interface, spanning-tree bpduguard enable applies it to that port whether or not PortFast is on, and the Cisco guide notes it overrides the global setting. Both are disabled by default.

1. Identify host-facing ports. Exclude anything that leads to another switch, a router running bridging, a port-channel or LACP bundle, or a hypervisor uplink that you have not checked.
2. Make those ports explicit access ports with PortFast. Template them so new ports inherit the setting.
3. Enable BPDU guard globally for all PortFast ports, which covers the template automatically.
4. Optionally enable error-disable recovery so a tripped port retries on a timer instead of waiting for a ticket.
5. Save the configuration and record the change, including the recovery interval you chose.

! host ports: access mode, edge behaviour
interface range GigabitEthernet1/0/1 - 46
 switchport mode access
 switchport access vlan 20
 spanning-tree portfast
!
! guard every PortFast port
spanning-tree portfast bpduguard default
!
! or per interface, independent of PortFast
interface GigabitEthernet1/0/47
 spanning-tree bpduguard enable
!
! optional: bring tripped ports back automatically
errdisable recovery cause bpduguard
errdisable recovery interval 300

Newer Catalyst releases spell the edge commands as spanning-tree portfast edge and spanning-tree portfast edge bpduguard default; the behaviour is the same. Other vendors put the same idea under the edge port setting. On Foundry IronWare, RSTP host ports were marked with spanning-tree 802-1w admin-edge-port, as the IronWare example on the spanning tree page shows.

05 /Does BPDU guard behave differently with RSTP, MSTP or per-VLAN spanning tree?

Not in any way that changes the design. The Cisco guide states that PortFast, BPDU guard, BPDU filtering, root guard and loop guard can be configured whether the switch runs PVST+, rapid PVST+ or MSTP. The guard watches for any BPDU on the port, whatever version or instance it belongs to, so a desk switch running classic 802.1D trips it as reliably as one running MSTP.

Two details do vary with the spanning tree mode. First, the port being guarded is a single physical port, but in per-VLAN modes that port may carry a data VLAN and a voice VLAN, each with its own instance. That is where the per-VLAN shutdown option earns its place: the offending VLAN stops and the other keeps working. Second, the edge setting itself differs by mode and vendor. Under RSTP and MSTP the edge flag is part of the protocol, and some platforms detect edge ports automatically when no BPDUs arrive for a while. Automatic detection is convenient but it is not a guard: a port that later receives BPDUs just stops being an edge port and joins the tree. If you want the port shut, configure BPDU guard explicitly rather than relying on edge detection.

Region boundaries in MSTP add no special case. An access port should never be on a region boundary, and if a BPDU from another region arrives on a guarded host port, the guard fires like any other.

06 /What happens when it trips, and how do you recover?

The switch logs a message naming BPDU guard as the cause and puts the whole port into the error-disabled state: link down, no traffic, LED off or amber depending on the model. The Cisco guide offers a narrower option, errdisable detect cause bpduguard shutdown vlan, which shuts down only the offending VLAN on the port. That is useful on a port carrying a voice VLAN and a data VLAN where you would rather keep the phone up.

Recovery is manual by default:

1. Find tripped ports with show interfaces status err-disabled, which lists each port and the reason.
2. Find out what is plugged in before you re-enable it. The MAC address table and the neighbour tables (CDP or LLDP) for that port usually identify the device.
3. Remove the cause: the extra switch, the loop, or the bridging setting on the host.
4. Bounce the port with shutdown then no shutdown.

Automatic recovery with errdisable recovery cause bpduguard is convenient in a large campus, but if the cause is still there the port will flap on every interval. Watch the logs for the same port tripping repeatedly; that is a loop someone needs to remove by hand.

07 /Common BPDU guard mistakes

• Applying it to uplinks. The neighbour switch sends BPDUs every two seconds, and the uplink goes down immediately. Never apply it to switch-to-switch links or bundles.
• Using global PortFast on trunks without checking. PortFast on 802.1Q trunk ports needs spanning-tree portfast trunk on Cisco; enabling it toward a hypervisor that forwards BPDUs will then trip the guard.
• Pairing it with interface BPDU filter. The filter hides the BPDUs and the guard never fires, leaving the port with spanning tree effectively disabled.
• Auto-recovery with no alerting. A looped port flaps forever and nobody notices until users complain.
• Treating it as access control. It reacts only to BPDUs. Unauthorised hosts and silent unmanaged switches need port security or 802.1X.

08 /How to check that BPDU guard works

1. show spanning-tree summary shows whether PortFast BPDU guard is enabled by default on the switch.
2. show spanning-tree interface GigabitEthernet1/0/5 detail shows the port's PortFast state and whether BPDU guard is enabled on it.
3. In a maintenance window, patch a spare managed switch with spanning tree enabled into a test access port. The port should go error-disabled within a couple of seconds and appear in show interfaces status err-disabled.
4. Patch a cable between two test access ports in the same VLAN. Both ends should trip, proving the guard also catches loops through passive devices.
5. Re-enable the ports and confirm normal forwarding returns.

09 /Where BPDU guard fits in an access-port template

A good access-port template combines several independent protections, each answering a different question. BPDU guard answers "can this port join spanning tree?"; DHCP snooping on client VLANs answers "can this port hand out addresses?"; 802.1X answers "who is this?". None of them replaces the others. Apply them together to every host-facing port, keep uplinks on root guard or loop guard instead, and review the template whenever a new kind of device, such as a desk hub with its own switch chip, appears on the floor. More access-layer topics are collected in the switching guide list.