v1.5.5 Bug Reports and Comments

[bipbaep]

Stephen, have you checked log/config?

[cbl]

I just updated one WS-12-250-AC from 1.5.4 to 1.5.5 on the roof of our building.
It finished, but would never respond to pings. I bounced the "inside" fiber SFP interface facing the roof Netonix and cleared ARP, and that seemed to kick it into business.

I gave it a good 13 minutes before I bounced the port according to the logs.

Not sure what's up with that though.

[Ludvik]

I have similar error. But I don't remember version from which I upgraded (I think 1.5.2 or 1.5.0, the switch is in my homelab without central management).

After upgrade SFP module (GigaLight RJ-SFP GE-GB-P3RC-C) doesn't worked. In log file is:

SFP: I2C communication down to SFP 1, attempting to establish communications
SFP: I2C communications up to SFP 1

After physical reboot everything working fine ... And the second attempt did not repeat the error.

[LRL]

There appears to be some issues with STP since 1.5.0. We've had several switches 1.5.2 - 1.5.5 move several AP ports into discarding even though there is no way there is a loop or even any other device with stp enabled on these ports. I've also seen various issues where STP on the switch fails to identify the root port until the switch is rebooted. This seems to be persistent from 1.5.2 to 1.5.5 with 1.5.5 being a little better. It appears as if the STP process locks up and then stops making changes to any of the STP states of ports. If the port was previously in a discarding state it won't change to a forwarding state and vise versa.

Causing a loop tends to create this more frequently than anything else, but I've also found that connecting the switch to a bridge with STP on and then re-configuring the bridge and turning off stp and then back on can cause this as well. It's not completely clear if this might be related to glc-t SFP's thrown in the mix. I'm having a hard time consistently reproducing this, but reverting to 1.5.0 solves it completely.

[Stephen]

bipbaep,
Please check your PM. When you can.

cbl, Ludvick,
I've never seen this one before. If you see it again, could you try to acquire the logs of the event and post here?

LRL,
I tried replicating this by creating a loop with a few different switches and then I changed the root device, priorities, etc. I am unable to replicate the scenario.

Can you give me a network diagram that might make it easier to bring this issue out?
Or, are there any other devices that are using STP on the network that the switch is talking to that might be unique? Something I could potentially acquire so I can see this result?

[LRL]

There are two 12 port dc switches with an rb4011 that sits between them all the devices are running rstp. Off of one switch we have 3 lbe120 sectors and 6 rocket r5 ac.frewuently the switch will show mstp 0 move all the ricket ports t the discarding even though they dont have any clients anf the lbes wilk stay forwarding. No matter what we do we can not get the rockets to return to forwarding and the pirt labeled as root will not change even if we change the port that the root bridge is on. The 4011 is configured correctly to be labeled as the root bridge.

The only way to restore connectivtiy has been to reboot the switch disabling rstp on the switches solves the problem altogether.

[Stephen]

So you're saying this is not a one-off scenario. This is happening consistently and interfering with your ability to use the switch's.

OK, if possible I need the log files from all switches involved from a boot-up with RSTP enabled. This should help me see the state transitions of the STP SM that are taking place on the network.

[Omniflux]

I think I've seen the STP issue on 1.5.4 a couple times as well. 95% sure there was not a loop when the port switched to discarding and stayed there. My solution was to disable STP on the Netonix since I am buried and don't have time to investigate. Certainly no signs of a loop after doing this.

Port could have switched to discarding because the other device rebooted - no idea really.

[quantumx]

It seems that there may be a race condition on boot when spanning tree is enabled on SFP ports.

Network Status:

-Currently we have a WS-26-500-DC connected with 2x WS-12-250-DC switches via SFP in ring using spanning tree.
-SFP modules used: FTL8519P2BNL-AO
-All three switches are running v1.5.5
-Spanning tree is only active on the SFP Ports.
-All copper cables certified, link up at 1Gbps, reporting good on cable tests & reporting 29-30dB SNR from equipment
-Total loading WS-26-500-DC ~ 150W
-Input voltage: 27.4V
-If all switches are booted when network loop is introduced (ie. module plugged in or fiber plugged into module), spanning tree works properly
-Spanning tree blocks/enables ports as required when fiber connectivity on any link is interrupted.

-Currently operate ~50 other netonix switches, with no issue (spanning tree is not used)

Symptom:

-On cold bootup, the WS-26-500DC SFP links come up, followed by copper data links, followed by a reboot loop. Management UI is never reachable. This can occur 10-20 times before the switch boots properly. Power to devices is sometimes affected (ie. cycled) on switch reboot.

-Rarely, switch enters reboot loop after a configuration change.

-Problem seems worse as switch is exposed to more traffic from incoming trunks (copper).

Troubleshooting:

Test #1: Swap WS-26-500DC switch with a cold spare (must have bad hardware).
Result: Same behaviour - reboot loop - not bad hardware.

Test #2: Power switch directly from 200Ah 24V battery pack, no fusing, fully charged, #8 cabling (must have bad power).
Result: Same behaviour - reboot loop - not bad power.

Test #3: Unplug -most- of the powered switch copper ports (must have shorted PoE - these ports feed the switch group with connectivity).
Result: Switch sometimes boots normally, allowing cables to be plugged in again after successful boot - This is how operation was resumed after a site power failure - maybe bad cabling. This lead to re-certifying / re-terminating / re-certifying all site copper data cabling - no problems found.

Test #4: Remove 1 SFP module from WS-26-500-DC switch (doesn't matter which one) and cold boot switch (maybe a bad module?).
Result: Switch always boots normally - tested several times. Also swapped out modules with spares - not a bad module.

Test #5: Remove link (fiber) from (one or both) SFP modules (maybe a loop problem?).
Result: Switch always boots normally - tested several times.

Test #6: Disable spanning tree on one of the ports, remove all VLANs from this port with the exception of a bogus VLAN going nowhere (so port link is kept active, but with no loop) (maybe a software problem?).
Result: Switch always boots normally - tested several times.


Suggestions welcome - over 20 hours spent testing in early morning hours with the only working solution being to disable or otherwise defeat spanning tree.

[FuzzyDice]

I'm getting an error setting QinQ tags on the management vlan.

To reproduce:
1) Top-most VLAN (the one used by the switch for Management) is set to 1351
2) Port 1 is set to option T, port 3 is set to option Q
3) Click Save/Apply
4) Interface shows popup message about applying changes and reverting in 60 seconds if communication is lost
5) 30 seconds into this process another pop-up says "Error applying configuration!" The switch GUI is not accessible at this point but the switch is still moving traffic normally.
6) 60 seconds into the process the changes revert and the switch GUI becomes accessible again.

I only get this problem when setting the Q option - all other vlan options seem to save without issue.

I also only get this problem when setting the Q option on the top-most management vlan. I can set the Q option to any port on any other vlan defined below the management vlan without issue.