NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
The root port randomly disabled and enabled time to time.
Hi,
I have 3 Netgear GS728TPV2 switches in three different locations in my company. One of them, let's say Switch 1, has a LAG setup with STP disabled for the VxRail connection.
The root port for Switch 1 is Port 25, the SFP port, which has been going down and up intermittently.
The remaining ports are not affected.
Port 25 on Switch 1 is connected to Port 25 on Switch 2, which is also affected and goes down and up.
Would like to ask the community for help to identify the issue and its resolution.
Log
<181>1 2026-02-02T16:08:11.982-04:00 <IP>-1 TRAPMGR-5-STP_NEW_ROOT ksi_snmp.c(484) %% This bridge has changed to be the root bridge.
<182>1 2026-02-02T16:08:11.492-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Forwarding to Disabled
<181>1 2026-02-02T16:08:11.372-04:00 <IP>-1 TRAPMGR-5-PORT_LINK_DOWN ksi_snmp.c(230) %% Interface GigabitEthernet25 link down
<181>1 2026-02-02T16:08:07.002-04:00 <IP>-1 TRAPMGR-5-STP_TC ksi_snmp.c(486) %% Bridge topology change.
<182>1 2026-02-02T16:08:07.992-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Blocking to Forwarding
<182>1 2026-02-02T16:08:07.742-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Disabled to Blocking
<181>1 2026-02-02T16:08:07.702-04:00 <IP>-1 TRAPMGR-5-PORT_LINK_UP ksi_snmp.c(232) %% Interface GigabitEthernet25 link up
<182>1 2026-02-02T16:08:07.482-04:00 <IP>-1 LLDP-6-NEIGHBOR_DEL proto_lldp.c(4321) %% Neighbor deleted on port GigabitEthernet25: Chassis ID <MAC>, Port ID g25
<182>1 2026-02-02T16:08:06.992-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Forwarding to Disabled
<181>1 2026-02-02T16:08:06.782-04:00 <IP>-1 TRAPMGR-5-PORT_LINK_DOWN ksi_snmp.c(230) %% Interface GigabitEthernet25 link down
<181>1 2026-02-02T16:05:39.982-04:00 <IP>-1 TRAPMGR-5-STP_TC ksi_snmp.c(486) %% Bridge topology change.
<182>1 2026-02-02T16:05:37.492-04:00 <IP>-1 LLDP-6-NEIGHBOR_DISCOVER proto_lldp.c(4579) %% New neighbor on port GigabitEthernet25: Chassis ID <MAC>, Port ID g25
<182>1 2026-02-02T16:05:36.452-04:00 <IP>-1 LLDP-6-NEIGHBOR_DEL proto_lldp.c(4321) %% Neighbor deleted on port GigabitEthernet25: Chassis ID <MAC>, Port ID g25
<182>1 2026-02-02T16:05:36.232-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Blocking to Forwarding
<182>1 2026-02-02T16:05:36.982-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Forwarding to Blocking
<181>1 2026-02-02T16:05:36.942-04:00 <IP>-1 TRAPMGR-5-PORT_LINK_UP ksi_snmp.c(232) %% Interface GigabitEthernet25 link up
<181>1 2026-02-02T16:05:36.782-04:00 <IP>-1 TRAPMGR-5-PORT_LINK_DOWN ksi_snmp.c(230) %% Interface GigabitEthernet25 link down
<182>1 2026-02-02T16:05:32.982-04:00 <IP>-1 LLDP-6-NEIGHBOR_DISCOVER proto_lldp.c(4579) %% New neighbor on port GigabitEthernet25: Chassis ID <MAC>, Port ID g25
<181>1 2026-02-02T16:05:31.982-04:00 <IP>-1 TRAPMGR-5-STP_TC ksi_snmp.c(486) %% Bridge topology change.
<182>1 2026-02-02T16:05:28.452-04:00 <IP>-1 LLDP-6-NEIGHBOR_DEL proto_lldp.c(4321) %% Neighbor deleted on port GigabitEthernet25: Chassis ID <MAC>, Port ID g25
<182>1 2026-02-02T16:05:28.232-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Blocking to Forwarding
<182>1 2026-02-02T16:05:28.982-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Forwarding to Blocking
<181>1 2026-02-02T16:05:28.922-04:00 <IP>-1 TRAPMGR-5-PORT_LINK_UP ksi_snmp.c(232) %% Interface GigabitEthernet25 link up
<181>1 2026-02-02T16:05:28.842-04:00 <IP>-1 TRAPMGR-5-PORT_LINK_DOWN ksi_snmp.c(230) %% Interface GigabitEthernet25 link down
<182>1 2026-02-02T16:05:24.492-04:00 <IP>-1 LLDP-6-NEIGHBOR_DISCOVER proto_lldp.c(4579) %% New neighbor on port GigabitEthernet25: Chassis ID <MAC>, Port ID g25
<181>1 2026-02-02T16:05:23.972-04:00 <IP>-1 TRAPMGR-5-STP_TC ksi_snmp.c(486) %% Bridge topology change.
<182>1 2026-02-02T16:05:21.982-04:00 <IP>-1 STP-6-PORT_STATE proto_stp.c(820) %% Port GigabitEthernet25 moving from Blocking to Forwarding
Spanning Tree Protocol (STP) provides network recovery by automatically recalculating paths and enabling standby links when an active link fails, ensuring a loop-free, redundant topology.
STP is used to prevent Layer 2 loops, commonly known as broadcast storms, from disrupting local area networks. STP virtually disconnects redundant links to prevent loops from occurring.
By default, these (== virtually any smart managed or managed switch make and model) switches have all the same STP neutral Spanning Tree priority 32768 configured - so the behaviour you see in your network switch logs is absolutely predictable.
While traditional 802.1D STP takes 30–50 seconds to converge, faster solutions like Rapid Spanning Tree Protocol (RSTP, 802.1w) reduce recovery time to about 6 seconds.
Newer switches are often defaulting to RSTP, allowing faster recovery.
To avoid random SRT topology change messages (with the possible short traffic interruption), actively configure STP/RSTP priorities and take over control of the root election.
The lower the priority, the more likely the switch is to become the root bridge.
Normally have to do STP in increments of 4096 so you would not be able to allocate a priority of 1 to a switch.
By rule of thumb, a good start would be using lower numbers (== higher priority) on the switch nearer to the router, and higher numbers (== lower priority) on switches in intermediate and edge positions on the network.
A modest proposal for STP priorities, easy to remember, for a small network:
Router (assuming the router has multiple network "LAN" ports and allows the configuration of the STP priority) 0 <-> Core Switch 4096 <-> 8192 <-> Aggregation Switch 16384 <-> 20480 <-> 24567 <-> 28672 <-> Edge Switch 32768 <-> 36864 <-> 40960 <-> 45056 <-> <-> 49152 <-> 53284 <-> 57344 <-> 61440
Hope wally brain has the simple math right 8 -) )
If you can live without any STP based loop protection, disable STP/RSTP on all switches, accepting the risk of network loops - this brings down your smart managed switches network to about the level of a classic network, built on unmanaged devices however.
Some unmanaged and few smart managed switches optionally offer some alternate loop detection prevention method by transmitting certain specially crafted frames, where the switch can detect if the same frame does become visible on multiple ports.
Enjoy, and welcome to the wonderful world of networking!
3 Replies
Thank you very much for the thorough insight and explanation! As you recommended, I'll start by making Switch 1 the root bridge by adjusting its priority. After I checked, all switches have a priority of 32768. I will set Switch 1 to 4096, Switch 2 to 16384, and Switch 3 to 32768, and keep monitoring. Once again, thanks very much!
Spanning Tree Protocol (STP) provides network recovery by automatically recalculating paths and enabling standby links when an active link fails, ensuring a loop-free, redundant topology.
STP is used to prevent Layer 2 loops, commonly known as broadcast storms, from disrupting local area networks. STP virtually disconnects redundant links to prevent loops from occurring.
By default, these (== virtually any smart managed or managed switch make and model) switches have all the same STP neutral Spanning Tree priority 32768 configured - so the behaviour you see in your network switch logs is absolutely predictable.
While traditional 802.1D STP takes 30–50 seconds to converge, faster solutions like Rapid Spanning Tree Protocol (RSTP, 802.1w) reduce recovery time to about 6 seconds.
Newer switches are often defaulting to RSTP, allowing faster recovery.
To avoid random SRT topology change messages (with the possible short traffic interruption), actively configure STP/RSTP priorities and take over control of the root election.
The lower the priority, the more likely the switch is to become the root bridge.
Normally have to do STP in increments of 4096 so you would not be able to allocate a priority of 1 to a switch.
By rule of thumb, a good start would be using lower numbers (== higher priority) on the switch nearer to the router, and higher numbers (== lower priority) on switches in intermediate and edge positions on the network.
A modest proposal for STP priorities, easy to remember, for a small network:
Router (assuming the router has multiple network "LAN" ports and allows the configuration of the STP priority) 0 <-> Core Switch 4096 <-> 8192 <-> Aggregation Switch 16384 <-> 20480 <-> 24567 <-> 28672 <-> Edge Switch 32768 <-> 36864 <-> 40960 <-> 45056 <-> <-> 49152 <-> 53284 <-> 57344 <-> 61440
Hope wally brain has the simple math right 8 -) )
If you can live without any STP based loop protection, disable STP/RSTP on all switches, accepting the risk of network loops - this brings down your smart managed switches network to about the level of a classic network, built on unmanaged devices however.
Some unmanaged and few smart managed switches optionally offer some alternate loop detection prevention method by transmitting certain specially crafted frames, where the switch can detect if the same frame does become visible on multiple ports.
Enjoy, and welcome to the wonderful world of networking!
Unfortunately, even after I made changes based on your suggestion, the issue still persists..
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
