skip to content

Why should a spanning-tree edge port, which one vendor calls PortFast, be paired with BPDU Guard on access ports?

level: middleimportance: must knowfreq 45%

answer

  1. a promise the switch does not check
  2. forwarding before anything is heard
  3. a foreign bridge joins the tree
  4. first BPDU, port shut

basics

~20 s

An edge port forwards at once on an unchecked promise that no bridge is attached. BPDU Guard enforces the promise by shutting the port on the first BPDU, so a user's switch or a looped cable costs one port, not the tree.

solid answer

~50 s

An **edge port** (the IEEE term; one vendor calls it PortFast) skips spanning tree's waiting phases because the administrator promised that only hosts sit behind it. The promise is not checked. Spanning tree keeps running on the port, so when a BPDU arrives the port drops its edge status and joins the tree as an ordinary bridge port. By then a looped cable has had forwarding from the first instant, and a user's switch can take part in the tree: it can trigger topology changes and, with a low enough bridge priority, even become root and pull traffic through a desk. **BPDU Guard**, an implementation feature, turns the promise into policy: any BPDU on that port shuts it down until an operator, or a recovery timer, re-enables it. A disruption to the tree becomes one dead access port.

go deeper

for a junior

Recall that an edge port (one vendor's PortFast) lets a host port forward immediately and that BPDU Guard shuts that port if a switch is plugged into it.

for a middle

Explain why the pair exists: an edge port forwards before hearing anything and still processes BPDUs, so a foreign switch can join the tree unless BPDU Guard shuts the port.

for a senior

Separate the edge-port features clearly. BPDU Guard shuts the port, BPDU Filter hides BPDUs, and Root Guard reacts only to superior BPDUs. Know the blind spot: devices that drop BPDUs.

for a principal

Decide how access-port policy is enforced and recovered across thousands of ports: templates, automatic recovery versus manual review, and how guard trips feed monitoring.

## What an edge port gives up Spanning tree makes a new port wait, or under RSTP handshake, before forwarding so that it can discover a bridge on the other end before any loop can form. An **edge port** gives that up. It is the IEEE's name for a port facing only end stations; RFC 4318, the RSTP MIB, carries its administrative and operational values. One vendor calls the feature **PortFast**, and the name is widely used for it. An edge port forwards the moment the link comes up. That is right for a laptop and wrong for anything that bridges. The edge port is therefore an **assertion** by the administrator: "nothing here speaks spanning tree". ## What happens when the assertion is false Spanning tree does not stop running on an edge port. It still sends BPDUs, and RFC 4318 says the operational edge value "will also be changed to false on reception of a BPDU". What follows depends on what was plugged in: | Plugged in | Without BPDU Guard | With BPDU Guard | |---|---|---| | A cable looped between two access ports | Both forward at once; frames circulate until a BPDU arrives and one port stops being an edge port and blocks | The first BPDU shuts the port | | A user's own switch | It joins the tree, its ports can signal topology changes, and it is part of the network's failure domain | The port shuts and the switch never joins | | A switch with a low bridge priority | It can win root election and become the centre of the tree | The port shuts before anything changes | | A device that bridges but drops BPDUs | A loop that spanning tree cannot see | The same: BPDU Guard cannot see it either | The last row matters. Neither spanning tree nor BPDU Guard detects a loop through something that swallows BPDUs. That case needs broadcast rate limiting or a similar safeguard. ## What BPDU Guard does **BPDU Guard** is an implementation feature, not part of the IEEE standard, but nearly every managed switch has an equivalent. On a port where it is enabled: 1. the port runs normally and forwards immediately as an edge port; 2. on receiving **any** BPDU, superior or inferior, the switch disables the port; 3. the port stays down until an operator re-enables it or an optional recovery timer reopens it. If the device is still there, the port shuts again. The effect is that "no bridges on this port" stops being an expectation and becomes an enforced policy. A disruption that could have moved the root, flushed MAC tables across the VLAN and pulled traffic through a desk becomes one dead port and a log entry. ## BPDU Guard is not BPDU Filter The names are similar and the effects are opposite. - **BPDU Guard** reacts to a BPDU by shutting the port. It is a protection. - **BPDU Filter** suppresses BPDUs. Implementations differ: in one form it applies only to edge ports and stops filtering when a BPDU arrives; applied directly to a port, it neither sends nor processes BPDUs, which means spanning tree is off on that port. A loop through such a port is invisible to the protocol. - In common implementations a port with both configured never sees a BPDU, so the guard never fires and the port is unprotected. ## Why not Root Guard on a desk port? **Root Guard**, another implementation feature, blocks a port only when it receives a **superior** BPDU, one that would move the root. A user's switch at the default priority, facing a root whose priority was lowered by design, advertises an inferior BPDU, so Root Guard lets it join the tree. On a host port, any bridge at all violates the design, which is why BPDU Guard is the right tool there and Root Guard belongs on ports facing switches you do allow. ## Where the pair goes - **Edge port + BPDU Guard:** every access port that faces hosts, phones, printers or single-homed servers. - **Neither:** links between switches, which need the tree's full protection. - **Hypervisor hosts:** an edge port is common, but confirm that the virtual switch does not bridge two uplinks. If it does and drops BPDUs, BPDU Guard cannot see the loop.

  • Under RSTP an edge port already drops its edge status on its first BPDU. Isn't BPDU Guard redundant?
    No. Dropping edge status makes the port a normal bridge port, so the foreign switch joins the tree: it can signal topology changes and flush MAC tables, and with a low bridge priority it can become root. BPDU Guard keeps the device out entirely. RSTP's behaviour limits the damage; BPDU Guard enforces the design.
  • BPDU Guard has shut a port. What do you do?
    Find out what is attached before re-enabling it: a desk switch, a looped cable, or a host bridging two interfaces. Remove the cause, then bring the port back. A recovery timer is convenient, but if the device is still there the port flaps between shut and open, so repeated trips deserve a person, not a timer.

An edge port is a side door left unlocked because only staff are supposed to use it. BPDU Guard is the alarm that seals the door the moment anyone who is not staff walks through, instead of letting the stranger wander the building.

saying these in an interview costs you the question

  • BPDU Guard is needed because an edge port stops sending BPDUs
  • Without BPDU Guard an edge port ignores BPDUs entirely
  • BPDU Guard and BPDU Filter are two names for the same protection
  • BPDU Guard belongs on uplinks between switches
  • BPDU Guard only reacts to BPDUs that would change the root