Netonix Forums

I have 70 Netonix swithces in a wireless network.

If theres is a problem with the rapid spanning tree, many of the netonix swithces reboot at the same time.

The probleme here is the link, that is powered by the netonix switch lost the power on the switch when Netonix Reboot.

It means that the network will loop and the probleme gets bigger with more units down.

If I shut down the power in Netonix and use a poe adapter I will get a smaller probleme. Less switches will reboot.

Is there a way to change Netonix, so it will stop rebooting or at least hold power on the ports when it reboot?

My firmware is 1.4.9 on all switch.

And all the switch will not work correct If i dont reboot the switch.

I have prtg installed and can see what is going on my network.

Your using 1 year old firmware, please try v1.5.1rc8

viewtopic.php?f=6&t=4712&p=27252&hilit=+loop+reboot#p27252

A 70 switchs flat network ???

What do you mean by problem with spanning tree ? You see bug with spanning tree or you mean a configuration error ?

Do you also enable loop protection in case of bad spanning-tree configuration ?

Software 1.5.2, WS-12-250-AC Rev F

I'm having a similar issue. I have a 36 Netonix network in a fiber ring at an apartment complex ( 6 rings of 6 WS-12-250-AC ) attached to a Mikrotik CRS317-1G-16S+RM. All of the ethernet ports are trunks and are powering Mikrotik hapAC. RSTP is configured with the Mikrotik CRS317 switch as the root bridge with a rigged priority.

The issue seems to occur like this:
1) Technician is configuring the Device settings on a new switch / configuring a port for PoE
2) Rollback timer expires before Technician gets back in to confirm (usually because of lost wireless coverage)
3) All Netonix on property reboot. Log doesn't appear to record any panics, etc.
4) Any mikrotik that stays up because of local power adapter shows a loop message ("bridge port received packet with own address as source address (74:4d:28:3d:99:bd), probably loop") - MAC Address varies by which unit I pull the log from.
5) Network recovers following the reboot - normally about 1-2 minutes

My guess is that there is something in the rollback procedure that is stopping/re-starting the RSTP process without disabling bridging, first. I don't have any issues breaking / making the ring during normal operation. A switch losing power or rebooting one through the GUI also doesn't trigger it. I'm imagining that the CPU gets overwhelmed with the looped packets and has an unrecorded panic.

BTW, I'm loving the fan test!

A bit of a necro thread, however I see occasional reboots of all Netonix switches on a segment on occasion. It is typically occurring when there is an issue with a redundant link, or a ring somewhere. It seems like the switches get overwhelmed as soon as a loop starts, and they just reboot. None of the Edgeswitches on the same network segment have the issue.

Not sure where to begin on troubleshooting.

what is your firmware version?

Yes, it may be a necro thread, but my issue still persists. I have been forced to open the rings at the Mikrotik RSTP root switch and rely on a manual ring close if there is a fault. There appears to be some sort of race condition between the spanning tree process and the beginning of bridging when a netonix switch applies a configuration change.

My network has been running 1.5.2. I'm hesitant to upgrade code, because the network has been stable since disabling spanning tree on the netonix switches.

up to you..you are on an old firmware revision..lots of issues have been fixed since 1.5.2

I have found this old thread and I am facing to the same issue even on 1.5.12. I agree that the issue is very probaly related to the process of changing/applying the configuration on the switch where you have:

* redundant link configured with RSTP or
* i.e. using a untaged VLAN to divide switch ...

...simply all cases where unconfigured switch (reseted to defalts) with it's connected cables could cause a loop in the network. I believe it could be related to mentioned "re-starting the RSTP process without disabling bridging first". In some cases doing config changes on switches with mentioned configurations is very dangerous and "sometimes" it causes a loop and when the loop occure on one Netonix only - ALL Netonix swiches within the whole network reboot at the same moment (with power off on ports)!

So two questions:
* is it expected behaviour that ALL Netonix switches reboot when loop is occured (while other brands like Ubiquiti Edgeswitches stay up)? (very simple way to reproduce the loop and see what happen with all Netonix)
* could Netonix team investigate the process of appliyng config changes - there is probbably some bug (wrong order?) that causes a loop at least in such configs mentioned above

I think this is related to my issue, as we do rely on RSTP on the affected branch (redundant bridge links). See https://forum.netonix.com/viewtopic.php?f=17&t=7391

IntL-Daniel wrote:I have found this old thread and I am facing to the same issue even on 1.5.12. I agree that the issue is very probably related to the process of changing/applying the configuration on the switch where you have:

* redundant link configured with RSTP or
* i.e. using a untaged VLAN to divide switch ...

...simply all cases where unconfigured switch (reseted to defalts) with it's connected cables could cause a loop in the network. I believe it could be related to mentioned "re-starting the RSTP process without disabling bridging first". In some cases doing config changes on switches with mentioned configurations is very dangerous and "sometimes" it causes a loop and when the loop occure on one Netonix only - ALL Netonix swiches within the whole network reboot at the same moment (with power off on ports)!

So two questions:
* is it expected behaviour that ALL Netonix switches reboot when loop is occured (while other brands like Ubiquiti Edgeswitches stay up)? (very simple way to reproduce the loop and see what happen with all Netonix)
* could Netonix team investigate the process of appliyng config changes - there is probbably some bug (wrong order?) that causes a loop at least in such configs mentioned above