In this article, we explain a scenario where a third‑party device—intended only to forward RSTP BPDUs transparently —disrupted the RSTP topology between two switches. This caused root bridge changes, topology changes across the entire RSTP domain, and a Layer 2 loop. We also outlined how to identify the issue.

Symptoms

• Root bridge changes occurring on the device connected to the transit device, with topology changes propagated across the rest of the RSTP domain.
• A third‑party device positioned between RSTP‑participating switches—intended only to forward RSTP BPDUs transparently—is instead disrupting the topology.
• Agreement BPDUs are not being transmitted and received bewteen the devices.
• Devices across the RSTP domain are experiencing increased CPU utilization, packet loss, and performance degradation.

Following logs observed on the peer device connected to the 3rd party transit node which is disrupting the exchange of RSTP BPDUS:

Apr 3 14:59:21 Switch2 l2cpd[17675]: Root bridge in routing-instance 'default' changed from 4096:aa:bb:cc:dd:ee:01 to 61440:aa:bb:cc:dd:ee:10

Apr 3 14:59:21 Switch2 l2cpd[17675]: Root bridge in routing-instance 'default' changed from 61440:aa:bb:cc:dd:ee:10 to 4096:aa:bb:cc:dd:ee:01

Following logs observed on the rest of the devices on the RSTP domain and the device intended to be the root bridge:

Apr  3 14:18:48 Core l2cpd[17638]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/0.0
Apr  3 14:19:01 Core l2cpd[17638]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/0.0

In this scenario, a new device (Switch2) was introduced into the RSTP topology. It connects through an Ubiquiti device, which is expected to transparently forward the RSTP BPDUs upstream to the rest of the devices participating in the RSTP domain. The topology looks like this:

Topology 

Switch2 <> Ubiquiti <> Switch1 <> Core (Root Bridge) <> Remaining RSTP devices

The issue arises when Switch2 is connected to the network via the Ubiquiti device. At that point, we begin to observe high CPU utilization, packet loss, instability, and frequent topology change notifications across all devices interconnected through trunk ports.

Upon reviewing the logs, we found that the newly added device was incorrectly identifying itself as the root bridge. This led to repeated root bridge election conflicts with the Core, despite the Core having a lower bridge priority. The evidence points to the connection between the Ubiquiti device and Switch2 as the source of the instability. Below are the topology change events recieved from Switch2 on Switch1 and the Core:

Switch1

Apr  3 14:18:49  Switch1 l2cpd[17636]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/1.0
Apr  3 14:19:01  Switch1 l2cpd[17636]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/1.0
Apr  3 14:20:36  Switch1 l2cpd[17636]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/1.0
Apr  3 14:20:38  Switch1 l2cpd[17636]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/1.0

Core

Apr  3 14:19:27  Core l2cpd[17638]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/0.0
Apr  3 14:23:53  Core l2cpd[17638]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/0.0
Apr  3 14:24:04  Core l2cpd[17638]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/0.0
Apr  3 14:27:43  Core l2cpd[17638]: TOPO_CH: for Instance 0 in  routing-instance default received on port ge-0/0/0.0

When reviewing the logs on Switch2, We can see that it was repeatedly attempting to assume the root bridge role, competing with the Core, which holds the root bridge priority of 4K. Despite the Core’s lower priority, Switch2 was advertising itself with a much higher priority value of 60K, leading to unnecessary root bridge election changes and instability in the topology:

Switch2

Apr 3 14:59:21 Switch2 l2cpd[17675]: Root bridge in routing-instance 'default' changed from 4096:aa:bb:cc:dd:ee:01 to 61440:aa:bb:cc:dd:ee:10
Apr 3 14:59:21 Switch2 l2cpd[17675]: TOPO_CH: for Instance 0 in routing-instance default received on port ge-0/0/0.0
Apr 3 14:59:21 Switch2 l2cpd[17675]: Root bridge in routing-instance 'default' changed from 61440:aa:bb:cc:dd:ee:10 to 4096:aa:bb:cc:dd:ee:01
Apr 3 14:59:21 Switch2 l2cpd[17675]: ROOT_PORT: for Instance 0 in routing-instance default Interface ge-0/0/0.0
Apr 3 14:59:27 Switch2 l2cpd[17675]: Root bridge in routing-instance 'default' changed from 4096:aa:bb:cc:dd:ee:01 to 61440:aa:bb:cc:dd:ee:10

The device is incorrectly identifying itself as the root bridge:

root@Switch2> show spanning-tree bridge detail

STP bridge parameters
Routing instance name               : GLOBAL
Context ID                          : 0
Enabled protocol                    : RSTP
  Root ID                           : 61440.aa:bb:cc:dd:ee:10
  Hello time                        : 2 seconds
  Maximum age                       : 20 seconds
  Forward delay                     : 15 seconds
  Message age                       : 0
  Number of topology changes        : 256
  Time since last topology change   : 95248 seconds
  Local parameters
    Bridge ID                       : 61440.aa:bb:cc:dd:ee:10
    Extended system ID              : 0
    Hello time                      : 2 seconds
    Maximum age                     : 20 seconds
    Forward delay                   : 15 seconds
    Path cost method                : 32 bit

When reviewing the interfaces on Switch2 and Switch1, we can see that both are forwarding RSTP BPDUs. However, the balance between transmitted and received BPDUs is noticeably impaired. Specifically, Switch2 is sending a large number of "Agreement BPDUs", but none are being received by the upstream device, Switch1.

Conversely, on the Switch1 side, no "Agreement BPDUs" are being transmitted or received at all. This asymmetry suggests that the handshake process required for RSTP convergence is breaking down between the two devices, preventing proper synchronization and stable forwarding state transitions:

root@Switch2> show spanning-tree statistics interface ge-0/0/0

Interface     BPDUs       BPDUs        Next BPDU       TCs        Proposal    Agreement
              Sent        Received     Transmission    Tx/Rx      Tx/Rx       Tx/Rx    
ge-0/0/0   1085924        2706             0      1248/2479        0/0    1084102/0 

root@Switch1> show spanning-tree statistics interface ge-0/0/1

Interface     BPDUs       BPDUs        Next BPDU       TCs        Proposal    Agreement
              Sent        Received     Transmission    Tx/Rx      Tx/Rx       Tx/Rx    
ge-0/0/1    60578        5019             0        0/5013         0/0         0/0

When a switch receives a proposal BPDU from a neighbor (indicating a potential port role change), it evaluates whether it can safely accept it. If the switch can synchronize its other ports to prevent loops, it responds with an agreement BPDU. Once the agreement is exchanged, both ends immediately transition the port into the forwarding state. This handshake enables rapid convergence.

Agreement BPDUs act as the “yes” in RSTP’s handshake, confirming that a port can safely move to forwarding without waiting for timers. This mechanism is what makes RSTP significantly faster and more reliable than traditional STP.

In this case, we need to confirm whether the 3rd party device is transparently forwarding these RSTP BPDUs, or if it is dropping, altering, or absorbing the multicast frames. If the device is not passing them correctly—or if it is filtering, modifying, or even participating in the STP domain (when it should only be transparently forwarding frames)—it could disrupt the topology between the connected switches.

After further investigation of the Ubiquiti device, we discovered that STP was enabled. Once STP was disabled across the Ubiquiti device, the issue was resolved: no additional topology change events were observed. This allowed the multicast RSTP BPDU frames to flow transparently between Switch2 and Switch1, enabling them to properly synchronize.

For additional troubleshooting and guidance on STP, please refer to the following resource:

 https://supportportal.juniper.net/s/article/Resolution-Guide-EX-Troubleshoot-Spanning-Tree-Protocol-STP