This article aims to assist with Spanning-Tree Protocol (STP) troubleshooting in EX Series Ethernet switches that are configured as Layer 2 switches by detailing a step-by-step approach.
Note: Spanning-Tree Protocol was introduced as 802.1D to enable a loop-free network.
Symptoms
A loop has formed in the network.
Topology changes have increased.
Layer 2 traffic is disrupted.
Interface goes into BLOCK state, causing traffic to be dropped.
Traffic is flooding.
Perform the following steps to troubleshoot:Before implementing xSTP, please make sure that redundant links exist on your network since STP will block redundant links to avoid a broadcast storm; otherwise, xSTP will consume CPU without help in your network.Example of no redundant links:SRX <------> EX <------> MXExample of redundant links:
[Map out the network topology.]
Map out the network topology and identify the following components. For an example topology with definitions, refer to KB22832 - Sample Spanning Tree Network Topology [juniper.net].
Identify all the Layer 2 devices/switches. Identify the Root Bridge. To do this, run the command: show spanning-tree bridge. If the values of "Root ID" and "Bridge ID" are equal, then the switch is the Root Bridge or the Root Switch. For more information, refer to KB22777 - Identify the Root Bridge in a Spanning Tree (STP) network [juniper.net]. Identify the non-edge interfaces. For more information, refer to KB22777 - Identify the Root Bridge in a Spanning Tree (STP) network [juniper.net].
Identify all the Layer 2 devices/switches.
Identify the Root Bridge.
To do this, run the command: show spanning-tree bridge.
show spanning-tree bridge
If the values of "Root ID" and "Bridge ID" are equal, then the switch is the Root Bridge or the Root Switch. For more information, refer to KB22777 - Identify the Root Bridge in a Spanning Tree (STP) network [juniper.net].
Identify the non-edge interfaces.
For more information, refer to KB22777 - Identify the Root Bridge in a Spanning Tree (STP) network [juniper.net].
[Check the Spanning-Tree Protocol Flavor.]
Verify that all the switches that are connected in the network are running the same Spanning-Tree Protocol flavor (that is, RSTP, MSTP, STP, or VSTP).
To do this, run the command: show spanning-tree bridge. The Spanning-Tree Protocol flavor can be found under "Enabled protocol." For more information, refer to KB22775 - Verify the flavor of the Spanning Tree Protocol running on the EX switch [juniper.net].
The Spanning-Tree Protocol flavor can be found under "Enabled protocol." For more information, refer to KB22775 - Verify the flavor of the Spanning Tree Protocol running on the EX switch [juniper.net].
Are all the switches that are connected in the network running the same Spanning-Tree Protocol flavor?
Yes - Continue to Step 3.
No - Correct the configuration. Refer to KB22775 - Verify the flavor of the Spanning Tree Protocol running on the EX switch [juniper.net] for an example of how to enable the same protocol.
[Check the Root Bridge Interface.]
Starting on the Root Bridge in your network, are all the interfaces on this Root switch in the Forwarding (FWD) state?
To verify, run the command: show spanning-tree interface. In STP, all connected ports on a Root Bridge should be in FWD state. For more information about the output of the above command, refer to show spanning-tree interface.
To verify, run the command: show spanning-tree interface.
show spanning-tree interface
In STP, all connected ports on a Root Bridge should be in FWD state.
For more information about the output of the above command, refer to show spanning-tree interface.
Yes - Continue to Step 4.
No - Contact Support. This is a basic requirement.
[Check the Topology Change.]
On this switch, do you see the "Number of topology changes" value increasing?
To verify, run the command: show spanning-tree bridge detail. When the "Number of topology changes" value increases, it typically means that the physical state of a port on the switch has changed (like a non-edge port coming up). For more information, refer to KB22776 - Identify if a topology change has taken place in a spanning-tree network [juniper.net].
To verify, run the command: show spanning-tree bridge detail.
show spanning-tree bridge detail
When the "Number of topology changes" value increases, it typically means that the physical state of a port on the switch has changed (like a non-edge port coming up). For more information, refer to KB22776 - Identify if a topology change has taken place in a spanning-tree network [juniper.net].
Yes - Continue to Step 5.
No - Jump to Step 7 (to do Basic Loop Check).
On this switch, verify if the non-edge interfaces have changed state.
Run the following commands and analyze the output to verify if an interface has changed state. For a definition of non-edge interfaces and how to tell if an interface has flapped, refer to KB22803 - [EX] How to identify an interface that has flapped [juniper.net].
show log messages show interfaces <interface-name> extensive
Do you see that a non-edge interface has changed state? No - Continue to Step 6. Yes - Troubleshoot the interface that has flapped, and the STP should stabilize: Check for any loose cables. Check for any outage. Check if any configuration change has been made.
No - Continue to Step 6.
Yes - Troubleshoot the interface that has flapped, and the STP should stabilize:
Check for any loose cables.
Check for any outage.
Check if any configuration change has been made.
Since the cause of the topology change was not identified in Step 5 on the current switch, you need to move to the next node in the Spanning Tree to trace the source of the topology change.
For Legacy devices, the next node in the Spanning Tree can be determined from the value of the "Topology change Initiator" field under " show spanning-tree bridge detail "; it is the node from which the current switch received the topology change. On ELS platforms, you can find this in the logs with the command " show log messages | match TOPO_CH ". Run the command: show spanning-tree bridge detail . root@Switch> show spanning-tree bridge detail STP bridge parameters Routing instance name : GLOBAL Context ID : 0 Enabled protocol : RSTP Root ID : 4096.54:4b:8c:47:84:00 Root cost : 20000 Root port : ge-0/0/1 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 1 Number of topology changes : 27 Time since last topology change : 5 seconds Local parameters Bridge ID : 32768.10:0e:7e:a1:0a:40 Extended system ID : 0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Path cost method : 32 bit root@Switch> show log messages | match TOPO_CH Dec 27 08:32:10 Switch l2cpd[38315]: TOPO_CH: for Instance 0 in routing-instance default received on port ge-0/0/1.0 root@Switch> show spanning-tree statistics bridge STP Context : default STP Instance : 0 Number of Root Bridge Changes: 1 Last Changed: Thu Dec 30 13:19:56 2021 Number of Root Port Changes: 2 Last Changed: Thu Dec 30 13:19:57 2021 Recent TC Received: ge-0/0/1.0 <<<<< Received : Thu Dec 30 13:37:33 2021
For Legacy devices, the next node in the Spanning Tree can be determined from the value of the "Topology change Initiator" field under " show spanning-tree bridge detail "; it is the node from which the current switch received the topology change. On ELS platforms, you can find this in the logs with the command " show log messages | match TOPO_CH ".
show log messages | match TOPO_CH
Run the command: show spanning-tree bridge detail .
root@Switch> show spanning-tree bridge detail STP bridge parameters Routing instance name : GLOBAL Context ID : 0 Enabled protocol : RSTP Root ID : 4096.54:4b:8c:47:84:00 Root cost : 20000 Root port : ge-0/0/1 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Message age : 1 Number of topology changes : 27 Time since last topology change : 5 seconds Local parameters Bridge ID : 32768.10:0e:7e:a1:0a:40 Extended system ID : 0 Hello time : 2 seconds Maximum age : 20 seconds Forward delay : 15 seconds Path cost method : 32 bit root@Switch> show log messages | match TOPO_CH Dec 27 08:32:10 Switch l2cpd[38315]: TOPO_CH: for Instance 0 in routing-instance default received on port ge-0/0/1.0 root@Switch> show spanning-tree statistics bridge STP Context : default STP Instance : 0 Number of Root Bridge Changes: 1 Last Changed: Thu Dec 30 13:19:56 2021 Number of Root Port Changes: 2 Last Changed: Thu Dec 30 13:19:57 2021 Recent TC Received: ge-0/0/1.0 <<<<< Received : Thu Dec 30 13:37:33 2021
Connect to the switch off of the interface identified in the "Topology Change initiator" output.
Go to Step 4 and repeat Steps 4-5 . (Repeat Steps 4-5 on the switch from which the topology change was received.)
[Perform a Basic Loop Check.]
Analyze the traffic interface activity for unusually heavy traffic.
To do this, run the following command, and compare the output with the baseline output when traffic is normal. Switch-A> monitor interface traffic
To do this, run the following command, and compare the output with the baseline output when traffic is normal.
Switch-A> monitor interface traffic
For example, below is the output of Switch-A with normal network activity: Interface Link Input packets (pps) Output packets (pps) ge-0/0/0 Down 0 (0) 0 (0) ge-0/0/1 Down 0 (0) 0 (0) ge-0/0/2 Down 0 (0) 0 (0) ge-0/0/3 Down 0 (0) 0 (0) ge-0/0/4 Down 0 (0) 0 (0) ge-0/0/5 Down 0 (0) 0 (0) ge-0/0/6 Down 0 (0) 0 (0) ge-0/0/7 Down 0 (0) 0 (0) ge-0/0/8 Down 0 (0) 0 (0) ge-0/0/9 Down 0 (0) 0 (0) ge-0/0/10 Up 37 (0) 5570 (0) ge-0/0/11 Down 0 (0) 0 (0) ge-0/0/12 Down 0 (0) 0 (0) ge-0/0/13 Down 0 (0) 0 (0) ge-0/0/14 Down 0 (0) 0 (0) ge-0/0/15 Down 0 (0) 0 (0) ge-0/0/16 Down 0 (0) 0 (0) ge-0/0/17 Down 0 (0) 0 (0) ge-0/0/18 Down 0 (0) 0 (0) ge-0/0/19 Down 0 (0) 0 (0) ge-0/0/20 Up 88 (0) 1646 (0) ge-0/0/21 Down 0 (0) 0 (0) ge-0/0/22 Down 0 (0) 0 (0) ge-0/0/23 Up 122 (0) 1639 (0) vcp-0 Down 0 0 vcp-1 Down 0 0 ae0 Up 125 (0) 7216 (0) ae1 Down 0 (0) 0 (0) ae2 Down 0 (0) 0 (0) ae3 Down 0 (0) 0 (0) ae4 Down 0 (0) 0 (0) ae5 Down 0 (0) 0 (0) Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D
For example, below is the output of Switch-A with normal network activity:
Interface Link Input packets (pps) Output packets (pps) ge-0/0/0 Down 0 (0) 0 (0) ge-0/0/1 Down 0 (0) 0 (0) ge-0/0/2 Down 0 (0) 0 (0) ge-0/0/3 Down 0 (0) 0 (0) ge-0/0/4 Down 0 (0) 0 (0) ge-0/0/5 Down 0 (0) 0 (0) ge-0/0/6 Down 0 (0) 0 (0) ge-0/0/7 Down 0 (0) 0 (0) ge-0/0/8 Down 0 (0) 0 (0) ge-0/0/9 Down 0 (0) 0 (0) ge-0/0/10 Up 37 (0) 5570 (0) ge-0/0/11 Down 0 (0) 0 (0) ge-0/0/12 Down 0 (0) 0 (0) ge-0/0/13 Down 0 (0) 0 (0) ge-0/0/14 Down 0 (0) 0 (0) ge-0/0/15 Down 0 (0) 0 (0) ge-0/0/16 Down 0 (0) 0 (0) ge-0/0/17 Down 0 (0) 0 (0) ge-0/0/18 Down 0 (0) 0 (0) ge-0/0/19 Down 0 (0) 0 (0) ge-0/0/20 Up 88 (0) 1646 (0) ge-0/0/21 Down 0 (0) 0 (0) ge-0/0/22 Down 0 (0) 0 (0) ge-0/0/23 Up 122 (0) 1639 (0) vcp-0 Down 0 0 vcp-1 Down 0 0 ae0 Up 125 (0) 7216 (0) ae1 Down 0 (0) 0 (0) ae2 Down 0 (0) 0 (0) ae3 Down 0 (0) 0 (0) ae4 Down 0 (0) 0 (0) ae5 Down 0 (0) 0 (0) Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D
Below is the example output of Switch-A when it is experiencing abnormal activity: ( Note: The packet rates below may be normal for another switch. The key is to create a baseline and capture the packet rates during normal periods, so that you can compare packet rates when problems are being experienced.) Interface Link Input packets (pps) Output packets (pps) ge-0/0/0 Down 0 (0) 0 (0) ge-0/0/1 Down 0 (0) 0 (0) ge-0/0/2 Down 0 (0) 0 (0) ge-0/0/3 Down 0 (0) 0 (0) ge-0/0/4 Down 0 (0) 0 (0) ge-0/0/5 Down 0 (0) 0 (0) ge-0/0/6 Down 0 (0) 0 (0) ge-0/0/7 Down 0 (0) 0 (0) ge-0/0/8 Down 0 (0) 0 (0) ge-0/0/9 Down 0 (0) 0 (0) ge-0/0/10 Up 37 (0) 5593 (1) ge-0/0/11 Down 0 (0) 0 (0) ge-0/0/12 Down 0 (0) 0 (0) ge-0/0/13 Down 0 (0) 0 (0) ge-0/0/14 Down 0 (0) 0 (0) ge-0/0/15 Down 0 (0) 0 (0) ge-0/0/16 Down 0 (0) 0 (0) ge-0/0/17 Down 0 (0) 0 (0) ge-0/0/18 Down 0 (0) 0 (0) ge-0/0/19 Down 0 (0) 0 (0) ge-0/0/20 Up 88 (0) 35162079 (1116047) ge-0/0/21 Down 0 (0) 0 (0) ge-0/0/22 Down 0 (0) 0 (0) ge-0/0/23 Up 35160729 (1116048) 1640 (0) vcp-0 Down 0 0 vcp-1 Down 0 0 ae0 Up 125 (0) 35167672 (1116048) ae1 Down 0 (0) 0 (0) ae2 Down 0 (0) 0 (0) ae3 Down 0 (0) 0 (0) ae4 Down 0 (0) 0 (0) ae5 Down 0 (0) 0 (0) Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D
Below is the example output of Switch-A when it is experiencing abnormal activity:
( Note: The packet rates below may be normal for another switch. The key is to create a baseline and capture the packet rates during normal periods, so that you can compare packet rates when problems are being experienced.)
Interface Link Input packets (pps) Output packets (pps) ge-0/0/0 Down 0 (0) 0 (0) ge-0/0/1 Down 0 (0) 0 (0) ge-0/0/2 Down 0 (0) 0 (0) ge-0/0/3 Down 0 (0) 0 (0) ge-0/0/4 Down 0 (0) 0 (0) ge-0/0/5 Down 0 (0) 0 (0) ge-0/0/6 Down 0 (0) 0 (0) ge-0/0/7 Down 0 (0) 0 (0) ge-0/0/8 Down 0 (0) 0 (0) ge-0/0/9 Down 0 (0) 0 (0) ge-0/0/10 Up 37 (0) 5593 (1) ge-0/0/11 Down 0 (0) 0 (0) ge-0/0/12 Down 0 (0) 0 (0) ge-0/0/13 Down 0 (0) 0 (0) ge-0/0/14 Down 0 (0) 0 (0) ge-0/0/15 Down 0 (0) 0 (0) ge-0/0/16 Down 0 (0) 0 (0) ge-0/0/17 Down 0 (0) 0 (0) ge-0/0/18 Down 0 (0) 0 (0) ge-0/0/19 Down 0 (0) 0 (0) ge-0/0/20 Up 88 (0) 35162079 (1116047) ge-0/0/21 Down 0 (0) 0 (0) ge-0/0/22 Down 0 (0) 0 (0) ge-0/0/23 Up 35160729 (1116048) 1640 (0) vcp-0 Down 0 0 vcp-1 Down 0 0 ae0 Up 125 (0) 35167672 (1116048) ae1 Down 0 (0) 0 (0) ae2 Down 0 (0) 0 (0) ae3 Down 0 (0) 0 (0) ae4 Down 0 (0) 0 (0) ae5 Down 0 (0) 0 (0) Bytes=b, Clear=c, Delta=d, Packets=p, Quit=q or ESC, Rate=r, Up=^U, Down=^D
Is this switch encountering unusually heavy traffic activity on the interfaces? Yes - Continue to Step 8. No - End of workflow. The basic STP checks (a Topology Change Check and a Basic Loop Check) are good . If you are still encountering a Spanning-Tree Protocol issue, jump to Step 9.
Yes - Continue to Step 8.
No - End of workflow. The basic STP checks (a Topology Change Check and a Basic Loop Check) are good . If you are still encountering a Spanning-Tree Protocol issue, jump to Step 9.
Is Spanning-Tree Protocol enabled? For more information on how to check, refer to KB22775 - Verify the flavor of the Spanning Tree Protocol running on the EX switch [juniper.net] .
No - Enabling Spanning-Tree Protocol will mitigate loops, so, if possible, enable Spanning-Tree Protocol on the devices in the network segment where a loop is observed. For more information on how to do this, refer to KB22775 - Verify the flavor of the Spanning Tree Protocol running on the EX switch [juniper.net] .
Yes - Run the following commands to help troubleshoot this switch during abnormal traffic flow. Review if there is a MAC that is constantly flapping on the device with high traffic. You can also do a " monitor traffic interface <interface-name> " or disable the port and verify if the traffic load reduces to a normal level. If the cause cannot be identified, continue to Step 9.
monitor traffic interface <interface-name>
show system processes show interfaces <interface-name> extensive show log messages show ethernet-switching mac-learning-log
[Collect data for further troubleshooting.]
If the above steps do not resolve the problem, collect the following information and open a case with your technical support representative:
Network Topology/Diagram labeling spanning-tree roles of each device
1. Enable and Collect Trace options
Note: Enable the trace options first before runnig the rest of the comands[edit protocols]user@switch# set protocols stp traceoptions file STP.truser@switch# set protocols stp traceoptions file size 5muser@switch# set protocols stp traceoptions file files 5user@switch# set protocols stp traceoptions flag all
user@switch# set protocols stp traceoptions file STP.tr
user@switch# set protocols stp traceoptions file size 5m
user@switch# set protocols stp traceoptions file files 5
user@switch# set protocols stp traceoptions flag all
2. Basic Command OutputsPlease copy the following command outputs into a notepad text file and attach it to the case:
user@switch> set cli timestampuser@switch> show spanning-tree bridge brief user@switch> show spanning-tree bridge detailuser@switch> show spanning-tree statisticsuser@switch> show spanning-tree interfaceuser@switch> show ethernet-switching mac-learning-log
user@switch> set cli timestamp
user@switch> show spanning-tree bridge brief
user@switch> show spanning-tree bridge detail
user@switch> show spanning-tree statistics
user@switch> show spanning-tree interface
user@switch> show ethernet-switching mac-learning-log
3. Support Information Files# Generate RSI (Request Support Information)user@switch> request support information all-members | no-more | save /var/tmp/RSI-MM-DD-YYYY.txt
user@switch> request support information all-members | no-more | save /var/tmp/RSI-MM-DD-YYYY.txt
# Collect System Logsuser@switch> file archive compress source /var/log destination /var/tmp/logs-MM-DD-YYYY
user@switch> file archive compress source /var/log destination /var/tmp/logs-MM-DD-YYYY
Important Notes:- If you have a Virtual Chassis or multiple members, collect the logs from all members- If the issue is intermittent, enable trace options before the issue occurs if possible- Include any relevant topology diagrams or recent network changes in your case
Additional Recommendations:1. Document any error messages seen during the issue2. Note the date and time when issues occurred for the first and last time you are aware of3. Include any attempted troubleshooting steps and their results4. Specify if this is a new installation or an existing configuration that stopped working
2026-06-05: Added more details when opening a new case
2020-02-20: Article reviewed for accuracy; no changes required
2022-03-12: Article updated to add ELS outputs and other information