Juniper EX BPDU Error: Why the Port Is Disabled and How to Recover It Without a Repeat

A Juniper EX BPDU error means a port protected by bpdu-block-on-edge or layer2-control bpdu-block received a spanning tree BPDU. Junos shut the port down to stop a possible loop. On ELS switches, clear it with clear error bpdu interface ge-0/0/10. Remove the device that sent the BPDU first, or the port will go down again straight away.

Unplugging and re-plugging the cable does not help. The error is a software state, not a link state, and it stays until you clear it or a configured timeout expires. By default no timeout is configured, so the port stays disabled indefinitely.

This guide is written against the Junos OS 23.4 train on ELS switches such as the EX2300, EX3400 and EX4300. We also note the older non-ELS commands used on EX2200 and EX4200-class switches. We have not lab-tested every command on every platform and release. Confirm each statement with ? completion on your version before you use it in production.

Why Junos Shuts the Port Instead of Blocking It

An edge port skips the normal spanning tree listening and learning states and forwards immediately. That is what makes a desktop get DHCP quickly. It is also dangerous. If a switch or a loop appears behind an edge port, frames flow before spanning tree has a chance to block anything.

BPDU protection closes that gap. An edge port should never hear a BPDU, so a BPDU arriving there is treated as proof that something bridges back into the network. Junos chooses the blunt response: it disables the whole port rather than just blocking it in spanning tree. According to the Juniper BPDU protection documentation, edge ports do not support the gentler drop action, so shutdown is the only outcome.

The default of no automatic recovery is a deliberate trade-off. A person has to look at the port, which means a user-created loop gets noticed and fixed. The cost is helpdesk tickets and dead desk ports at the start of every working day. In our experience, most teams live with the default until the ticket count hurts, then add a timeout without thinking through what that timeout does to a real loop.

Confirm It Is Really a BPDU Error

Several port-security features shut ports down, and each one needs a different clear command. Check the interface first. The BPDU Error field is the deciding line.

user@ex-access> show interfaces ge-0/0/10
Physical interface: ge-0/0/10, Enabled, Physical link is Down
  Interface index: 660, SNMP ifIndex: 527
  Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto,
  BPDU Error: Detected, Loop Detect PDU Error: None, MAC-REWRITE Error: None,
  Loopback: Disabled, Source filtering: Disabled, Flow control: Enabled

Two details confirm the diagnosis. The interface is administratively Enabled but the physical link shows Down, and BPDU Error: Detected is set. The exact field list varies by platform and release, but the BPDU Error field has been present for many years.

To find every affected port on a switch at once, filter the output. The Junos match filter is case-insensitive.

user@ex-access> show interfaces | match "^Physical|BPDU Error: Detected"
user@ex-access> show log messages | match bpdu
user@ex-access> show spanning-tree interface
user@ex-access> show lldp neighbors interface ge-0/0/10
user@ex-access> show ethernet-switching table interface ge-0/0/10

A disabled port drops out of show spanning-tree interface completely, as the Juniper KB on recovering an interface moved down by BPDU error shows. On older non-ELS software, the log line is ESWD_BPDU_BLOCK_ERROR_DISABLED, and show ethernet-switching interfaces reports the port as Disabled by bpdu-control. ELS output uses different wording and layout, so match on bpdu rather than on a fixed string.

What each shutdown looks like

Juniper documents the storm-control and MAC-limit recovery separately in Configuring Autorecovery for Port Security Events. Running the BPDU clear command on a storm-control shutdown does nothing, which is a common source of confusion.

Juniper EX BPDU Error: Ordered Diagnostic

Work through these steps in order. The early ones are read-only and take seconds. Clearing the error comes last, because clearing a port that still hears BPDUs only resets the clock.

1. Confirm the cause. Run show interfaces ge-0/0/10 and check that BPDU Error shows Detected.
2. Get the timestamp. Run show log messages | match bpdu to find when it happened. Compare it with change windows, moves and desk bookings.
3. Check whether the port should be an edge port. Run show configuration protocols rstp and look for wildcard ranges or templates that swept up an uplink.
4. Identify what is connected. Run show lldp neighbors interface ge-0/0/10. A switch or bridge that runs LLDP often names itself here.
5. Look at the far end. Trace the cable. A desk switch, a looped patch lead or a second wall port is found here far more often than on the switch.
6. Remove the source, then clear. Run clear error bpdu interface ge-0/0/10 and watch the port for a few minutes.
7. If it trips again, investigate the host. Once the port is back up, run show ethernet-switching table interface ge-0/0/10. Many MAC addresses behind one desk port means a bridge.

Root Causes Ranked by Frequency

This ranking is from our own field experience and from what keeps coming up on r/Juniper, the Juniper community forum and Stack Exchange. It is not a Juniper statistic.

1. A loop or a second switch at the desk

The classic case is a user patching two wall ports together, or connecting a small switch to two ports. The access switch sends its own BPDU out of one edge port, the BPDU comes back in on another, and Junos disables the port. Small managed switches and home routers that run spanning tree trigger the same thing on their own.

The fix is physical. Remove the loop or the extra switch, then clear the port. If the business needs more ports at that desk, give the device an uplink port without the edge setting, or add a properly managed switch.

2. An uplink or switch-facing port configured as edge

This is the case that causes outages rather than tickets. A wildcard range line or a template marks every port as edge, including the uplink or a port facing a downstream switch. The moment spanning tree runs across that link, the uplink shuts down.

Review the RSTP configuration after any bulk change. Uplinks and switch-to-switch links should never be edge ports. If an aggregated uplink goes down as a result, check the member links as well, and use our guide to Junos LACP ae interfaces stuck in Defaulted or Detached once the BPDU error is cleared.

3. Hosts that bridge in software

Some servers and appliances run a software bridge with spanning tree enabled. Examples include a Linux bridge with STP turned on, or a virtual firewall in transparent or bridge mode. They send BPDUs like any switch would. In our experience this shows up after a new server or appliance is racked on a port that was templated as an access port.

Either disable spanning tree on the host bridge, or treat the port as a switch-facing link. For a firewall cluster whose control and fabric links cross your switches, remember that the switches carry cluster traffic too. Our guide to an SRX chassis cluster node stuck in disabled lists the Layer 2 requirements for that path.

4. A different vendor switch on a port you thought was an endpoint

Another vendor switch on a port you assumed was an endpoint will trip the protection straight away. Different spanning tree variants still send BPDUs that trip it. This is protection working as designed, but it often gets reported as a Juniper interop problem.

5. It was never a BPDU error

Storm-control and MAC-limit shutdowns look identical from the helpdesk. If BPDU Error reads None, you are in the wrong guide. Use clear ethernet-switching recovery-timeout on EX, which clears ports disabled by those features.

Clearing the Error

Clearing the error changes forwarding on a live port. If the port is an uplink, make sure you have console or out-of-band access before you clear it. If the loop is still there, the switch can briefly forward looped traffic before the next BPDU trips the port again.

user@ex-access> clear error bpdu interface ge-0/0/10

# Older non-ELS EX software:
user@ex-legacy> clear ethernet-switching bpdu-error interface ge-0/0/10

# Ports disabled by storm-control or MAC limiting (a different feature):
user@ex-access> clear ethernet-switching recovery-timeout

The clear error bpdu interface command reference confirms the ELS form. Clearing re-enables the port but leaves the BPDU protection configuration in place, which is what you want. On a Mist-managed switch, the Mist portal also offers a clear BPDU error action for the port.

The recovery-timeout clear command in the example above has no interface argument, so it may re-enable every port disabled by storm control or MAC limiting. Check ? on your release for an interface option before running it on a busy access switch.

Copy-Ready Edge Protection Configuration

This baseline marks access ports as edge, enables BPDU protection on them, and adds a recovery timer. It assumes ge-0/0/0 to ge-0/0/43 face users and ge-0/0/44 to ge-0/0/47 are uplinks. Adjust the ranges before you paste. Use commit confirmed 5 and keep console access, because a range that catches an uplink will cut you off.

set protocols rstp interface ge-0/0/0 edge
set protocols rstp interface ge-0/0/1 edge
set protocols rstp interface ge-0/0/2 edge
set protocols rstp bpdu-block-on-edge
set protocols layer2-control bpdu-block disable-timeout 300
commit confirmed 5

For a full access block, a wildcard range saves typing. Keep the uplinks out of the range explicitly.

wildcard range set protocols rstp interface ge-0/0/[0-43] edge
show | compare
commit confirmed 5

Always read the show | compare output before the commit. It is the only point where you will see an uplink that got swept into the range. On most ELS releases the RSTP interface statement takes the physical port name without a unit, but confirm with ? on yours.

Choosing a disable-timeout

The disable-timeout accepts 10 to 3600 seconds, according to the Juniper disable-timeout statement reference. With no timeout configured, a disabled port stays down until it is cleared by hand. On non-ELS switches the equivalent lives under ethernet-switching-options bpdu-block.

Think about what a short timeout does to a real loop. Every time the timer expires, the edge port comes back and forwards at once. It keeps forwarding until the next BPDU arrives, normally within one hello interval of about two seconds. With a 10-second timeout, a physical loop becomes a short burst of looped traffic every few seconds, and that is harder to diagnose than a dead port.

Our view is to use a timeout of several minutes on user-facing access ports, and to send the BPDU log messages to your syslog or monitoring platform. Leave server, uplink and infrastructure ports with no timeout, so that a person has to look. Whatever you choose, an alert matters more than the timer.

Drop mode for ports that must stay up

Some ports face devices that emit BPDUs you cannot turn off, but that must keep forwarding. Drop mode throws away the BPDUs and leaves the port up. Juniper only supports it on interfaces that do not run spanning tree.

set protocols rstp interface ge-0/0/20 disable
set protocols layer2-control bpdu-block interface ge-0/0/20 drop
commit confirmed 5

Drop mode removes loop detection from that port. The BPDUs that would have revealed a loop are discarded, so spanning tree never learns about it. Pair drop mode with storm control on the same port, and use it only where you understand what the device on the other end does.

Cisco to Junos Command Mapping

Engineers moving from IOS often search for the Cisco terms. The mapping below is conceptual, and the behaviour does not match exactly in every case.

Verification After Recovery

After you clear the port, it moves through down to forwarding. A healthy edge port reappears in the spanning tree interface list as a designated forwarding port. The output below is illustrative and uses documentation MAC addresses.

user@ex-access> show spanning-tree interface ge-0/0/10

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
ge-0/0/10    128:523      128:523   32768.00005e005301    20000    FWD    DESG

user@ex-access> show interfaces ge-0/0/10 | match "Physical link|BPDU Error"
Physical interface: ge-0/0/10, Enabled, Physical link is Up
  Link-level type: Ethernet, MTU: 1514, Speed: 1000mbps, BPDU Error: None,

The broken states are easy to recognise. If the port is missing from the spanning tree list and BPDU Error reads Detected again within a few seconds of clearing, the source is still connected. If an edge port ever shows the ROOT role, a switch is sending superior BPDUs through it, so find that device before you do anything else.

Check the log after a full working day. No new BPDU messages for the port means the cause has really gone. For other symptom-led guides, see the Troubleshooting hub, and for spanning tree design, see Routing and Switching.

Juniper, Junos, MX, SRX, EX and QFX are trademarks of Juniper Networks, Inc., now part of HPE. Cisco and IOS are trademarks of Cisco Systems, Inc. juniperclient.com is independent and unaffiliated.

Frequently Asked Questions

How to clear BPDU error on EX-4300?

On ELS software, which the EX4300 runs, use clear error bpdu interface ge-0/0/10 in operational mode. The older clear ethernet-switching bpdu-error interface form only exists on non-ELS switches. Remove the BPDU source first, or the port will be disabled again. This exact confusion is discussed in a Juniper community thread about clearing BPDU errors on the EX4300.

How do I configure the timeout value for a BPDU guard disabled interface to bring itself up?

On ELS switches use set protocols layer2-control bpdu-block disable-timeout 300, with a value from 10 to 3600 seconds. On non-ELS switches the equivalent sits under ethernet-switching-options bpdu-block. Without it, the port stays disabled until it is cleared by hand.

How do you configure spanning tree BPDU guard on a Juniper EX switch?

Mark access ports as edge with set protocols rstp interface ge-0/0/10 edge, then enable protection on every edge port with set protocols rstp bpdu-block-on-edge. For a port that is not an edge port, use set protocols layer2-control bpdu-block interface ge-0/0/10. Keep uplinks out of any wildcard range you use.

Why is my interface down due to BPDU error even after I unplugged the device?

The BPDU error is a latched software state, so unplugging or re-plugging the cable does not clear it. Run clear error bpdu interface, or wait for a configured disable-timeout to expire. Check show interfaces afterwards to confirm that BPDU Error reads None.

How do I stop BPDUs being sent on an interface on EX series switches?

Disable spanning tree on that interface with set protocols rstp interface ge-0/0/20 disable. If you also need to discard BPDUs arriving there, add set protocols layer2-control bpdu-block interface ge-0/0/20 drop. That port then has no spanning tree loop protection, so add storm control to it.