In short

I'm trying to configure bpdu-timeout-action block on trunk interfaces to other switches, but it doesn't go into blocking mode when there are no BPDU's received (eg, when connecting my laptop to the interface). No matter what I try, it always remains in forwarding state. Do I misunderstand this feature? To my understanding, this feature should disable the interface when no BPDU packets are received on that interface.

Relevant information: https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/bpdu-timeout-action-spanning-trees-ex-series.html


In an effort to setup an minimal lab environment for this (to rule out conflicting config in my production setup), I'm trying this on a EX2200-C, junos version 12.3R12-S15, starting from the default configuration (with only the mandatory root password set).


I've configured the following on protocols rstp:

root# run show configuration protocols rstp 
interface ge-0/0/0.0 {
    bpdu-timeout-action {

ge-0/0/0 has a default config:

root# run show configuration interfaces ge-0/0/0 
unit 0 {
    family ethernet-switching;

I've then connected my laptop to ge-0/0/0, but it doesn't disable the interface:

root# run show ethernet-switching interfaces ge-0/0/0 
Interface    State  VLAN members        Tag   Tagging  Blocking 
ge-0/0/0.0   up     default                   untagged unblocked
root# run show spanning-tree interface                   

Spanning tree interface parameters for instance 0

Interface    Port ID    Designated      Designated         Port    State  Role
                         port ID        bridge ID          Cost
ge-0/0/0.0     128:513      128:513  32768.f4b52f9b7601     20000  FWD    DESG 

This shows that there are not BPDU's received:

root# run show spanning-tree statistics interface ge-0/0/0 

Interface   BPDUs sent   BPDUs received      Next BPDU
ge-0/0/0.0        1012             0                1
root# run show interfaces ge-0/0/0   
Physical interface: ge-0/0/0, Enabled, Physical link is Up
  Interface index: 129, SNMP ifIndex: 502
  Link-level type: Ethernet, MTU: 1514, Speed: Auto, Duplex: Auto,
  BPDU Error: None, MAC-REWRITE Error: None, Loopback: Disabled,
  Source filtering: Disabled, Flow control: Enabled, Auto-negotiation: Enabled,
  Remote fault: Online, Media type: Copper,
  IEEE 802.3az Energy Efficient Ethernet: Disabled
  Device flags   : Present Running
  Interface flags: SNMP-Traps Internal: 0x4000
  Link flags     : None
  CoS queues     : 8 supported, 8 maximum usable queues
  Current address: f4:b5:2f:9b:76:03, Hardware address: f4:b5:2f:9b:76:03
  Last flapped   : 2020-02-13 17:12:47 UTC (00:33:24 ago)
  Input rate     : 0 bps (0 pps)
  Output rate    : 544 bps (1 pps)
  Active alarms  : None
  Active defects : None
  Interface transmit statistics: Disabled

  Logical interface ge-0/0/0.0 (Index 67) (SNMP ifIndex 514)
    Flags: Up SNMP-Traps 0x4000 Encapsulation: ENET2
    Input packets : 192
    Output packets: 1620
    Protocol eth-switch                 
      Flags: Is-Primary

Does anyone has a clue what I'm missing here?

2 Answers 2


The BPDU-timeout action only takes effect when BPDUs have been received on a port and THEN they time out - so the port will need to be root or backup/alternate for it to work.

I don't think you'll be able to simulate it on a single switch with a laptop.

  • Thanks, spot on! I can confirm this actually is correct. The setup with a single switch may have been too simple after all (but it was an attempt for the most minimal setup), but I can confirm it actually works as you describe. While it still have it's uses, it's unclear to me why it only blocks an interface when it stops receiving bpdu's, not just if there are none at all to begin with. I've tested this on an link between switches and turned of stp at one end. The other switch shows: DIS (Loop-Incon) on show spanning-tree interface.
    – Hugo
    Commented Jul 22, 2023 at 9:25

The JunOS example page

That example implementation page is MUCH more helpful and complete compared to the basic command documentation. Take a look at that to see if you missed anything.

The main parts that stand out to me are to check that you are using RSTP for the switch (it seems you must configure it for each Spanning Tree implementation separately) and that the port in question is a potential Alt path for Spanning Tree to start with, otherwise it might not ever qualify for loop prevention in the first place.

  • Thanks for that link. I did came across earlier in my search attempts. I've re-read it, but unfortunately didn't gave me new ideas. I've connected a link to another switch, which made the new connected interface the root port. And rstp is enabled according to run show spanning-tree bridge. I think I basically give up at this point. Maybe it will become clear at some point in the future.
    – Hugo
    Commented Jul 18, 2023 at 18:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.