v1.2.0rc10/11 bug reports and comments

[iggy05]

Added the firmware to a low priority 12 port switch and all seems to work well for the basic stuff I need for it. This is the first time looking at the new firmware and I like some of the changes.

[mike99]

Intentionnaly caused a loop, send several ping at a ERL connected to one of the switch and let it like this for 2 or 3 minutes. DS and STP was still working fine after without rebooting the switch unlike I saw yesterday with RC9. I know, the're loop protection + STP so no reason for loop to happen but still wanted to test it just in case.

One thing that I think it would be nice to eventually add is a way to indicate which ports are disabled by STP on the ports dashboard. It could be a X like for port disabled (manually or by loop protection) with yellow or green port background to indicate that thoses ports are still up and then, that STP that disabled those.

[mike99]

Find a bug that can crash STP on some ports and can even crash networking on the switch.

Have 2 WS-12-250A, 192.168.1.19 and 192.168.1.20, linked via both SFP ports. If a disable STP on the 2 SFP ports of the two switch, loop protection then disable port 14 on switch 2 (192.168.1.20). If I enable STP, again, something wrong happen to networking on 192.168.1.20.

After it's happen, I can't ping the switch anymore, even connected directly through. If I connect via serial, everything seem fine but I can't ping anything from it too. Also, STP on port 14 will stay at forwarding even if it's unplug.

From switch 20

Code: Select all

 Netonix Switch# show interface status
Port Link PoE Watts
---- -------- ---- -----
1 Down Off 0.0
2 Down Off 0.0
3 Down Off 0.0
4 Down Off 0.0
5 Down Off 0.0
6 Down Off 0.0
7 Down Off 0.0
8 Down Off 0.0
9 Down Off 0.0
10 Down Off 0.0
11 Down Off 0.0
12 Down Off 0.0
13 1G-SFP
14 Down
Netonix Switch# show st
 
 status Show temperatures, CPU usage, memory usage, etc
 stp Spanning Tree Protocol configuration/status
 
Netonix Switch# show stp
Port Status
---- ------
1 Discarding
2 Discarding
3 Discarding
4 Discarding
5 Discarding
6 Discarding
7 Discarding
8 Discarding
9 Discarding
10 Discarding
11 Discarding
12 Discarding
13 Forwarding
14 Forwarding
Netonix Switch# show vlans
ID Enable Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14
---- ------ ----------- -- -- -- -- -- -- -- -- -- -- -- -- -- --
1 true Management U U U U U U U U U U U U U U
100 true DSTest E E E E E E E E E E E E T T
 
Netonix Switch# show mac table
MAC Port VLAN Manufacturer Last IP
----------------- ---- ---- ------------ ---------------
ec-13-b3-21-05-bb 37 1 Netonix Unknown

From switch 19:

Code: Select all

 Netonix Switch# show interface status
Port Link PoE Watts
---- -------- ---- -----
1 Down Off 0.0
2 Down Off 0.0
3 1G-F Off 0.0
4 1G-F Off 0.0
5 Down Off 0.0
6 Down Off 0.0
7 Down Off 0.0
8 Down Off 0.0
9 1G-F Off 0.0
10 1G-F Off 0.0
11 1G-F Off 0.0
12 1G-F Off 0.0
13 1G-SFP
14 Down
Netonix Switch# show vlans
ID Enable Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14
---- ------ ----------- -- -- -- -- -- -- -- -- -- -- -- -- -- --
1 true Management U U U E U U U U U E U E U U
100 true dhcp test E E E U E E E E E U E U T T
200 true VLAN 200 T T T T U E U E E E E E T T

VLAN 200 IPv4 Address: 192.168.100.4/255.255.255.0
Netonix Switch# show stp
Port Status
---- ------
1 Discarding
2 Discarding
3 Forwarding
4 Forwarding
5 Discarding
6 Discarding
7 Discarding
8 Discarding
9 Forwarding
10 Forwarding
11 Forwarding
12 Forwarding
13 Discarding
14 Discarding
Netonix Switch# show mac table
MAC Port VLAN Manufacturer Last IP
----------------- ---- ---- ------------ ---------------
00-25-64-d4-5e-b3 9 1 Dell Inc. Unknown
04-18-d6-31-75-e5 9 1 Ubiquiti Networks Unknown
24-a4-3c-05-f9-fb 3 1 Ubiquiti Networks, INC Unknown
dc-9f-db-29-15-4e 9 1 Ubiquiti Networks, Inc. Unknown
dc-9f-db-29-cd-f6 11 1 Ubiquiti Networks, Inc. Unknown
dc-9f-db-29-cd-f7 10 100 Ubiquiti Networks, Inc. Unknown
dc-9f-db-29-cd-f8 12 100 Ubiquiti Networks, Inc. Unknown

I reproduce it 3 time with switch 192.168.1.20. Reboot it, can access it, disable STP on both SFP ports (port 14 disabled 2 time by loop protection on 1 time, it was port 13), enable SFP again and can access 192.168.1.20 anymore except via serial, even plugged directly to it. I also tryed to connect a ERL and ping it through switch when it happen and I also can't ping through it.

I also add 1 time that the port disabled was the 13th (if I rember well) on 192.168.1.19. I didn't loss access to it but I then have issue with STP. Port 14 was then stuck at forwarding even when it was not connected. It seem to affect only the switch that the port was disabled by loop protection.

Edit: Tryed to activate STP on a manually disabled port and it didn't happen so it only with loop protection.

[sirhc]

Intentionnaly caused a loop, send several ping at a ERL connected to one of the switch and let it like this for 2 or 3 minutes. DS and STP was still working fine after without rebooting the switch unlike I saw yesterday with RC9. I know, the're loop protection + STP so no reason for loop to happen but still wanted to test it just in case.

One thing that I think it would be nice to eventually add is a way to indicate which ports are disabled by STP on the ports dashboard. It could be a X like for port disabled (manually or by loop protection) with yellow or green port background to indicate that thoses ports are still up and then, that STP that disabled those.

I like your suggestion of the colored X to indicate if the user or loop protection disabled the port, we can implement this. I think we should also make an easy way to re-enable the port that Loop Protection Disables instead of disabling and then re-enabling the port. Maybe if the X is RED in the Christmas Tree which means Loop Protection Disabled it that the user can right click on the Red X which removes the timed disable from Loop Protection and re-enables the port.

I will talk to Eric about your other issue but loops cause nasty up-predictable issues with switch cores so for the masses that might be following this thread the best thing is to try and make sure loops do NOT happen via the use of Loop Protection and or RSTP. I have never seen a switch yet in all my years of IT that recovered 100% of the time from a hard loop even HP and Cisco sometimes needed a hard power cycle to get them back up and running CORRECTLY. When you are dealing with an infinit # of packets it tends to stress things to a breaking point and since we do not write the switch core internal software there may be little that we can do to guarantee that a loop rather intentional or unintentional will not sometimes require a power cycle.

[mike99]

I understand it can have stability issue after loop but it's happen without loop. I only disable STP on both SFP ports of both switch, loop protection disable a port. After, enable again STP on those ports and networking totally crash. What I still don't understand is why it don't do it on 192.168.1.19. On my test on this switch, only issue I add was STP beeing stuck at the same state on the port disabled by loop protection that I activated STP on it and it was not cosmetic, STP won't block loop after it's happen.

I aslo think the easy enabled port after loop detection disabled it would be a good idea.

[adairw]

Just upgraded a WS-9-250-AC to 1.2.0rc11 and enabled CDP and UDP (Ubnt discovery) and my mikrotik router finds it via CDP no problem but the ubnt discovery tool does not. Is there a trick?

THANK YOU FOR TURNING THE FANS DOWN! :)

I see the DHCP Snooping check box, but where do you go to see what it's found or whatever?

Will report back with more testing later

[sirhc]

I see the DHCP Snooping check box, but where do you go to see what it's found or whatever?

Currently it just blocks it, I suppose from a WISP standpoint knowing who is doing such a thing is valuable, I will see if that can be added to to the v1.3.0 run

I am not used to the need for this feature as I NEVER give customers of my WISP Layer 2 access to my net but I understand others do but that is why I did not think of it.

But I suppose even in an office environment the IT guy would want to know of a rogue dhcp server, on what port, mac address, and IP

Will talk to Eric on this for v1.3.0

[adairw]

Don't know if it's just something on my side but I was SSH'd in to the switch no problem looking around. Went under Device>Console and attempted to open the console that way and it locked up my browser window. Chrome finally popped up and asked if I wanted to kill it or wait. Hit wait a few times but finally killed it. When I reloaded it would only sort of load the main screen.. Finally closed the tab and opened a new one and entered the switches IP address. the login page opened right up logged in and everything seemed fine. Went to Devices>Console again and it locked up.

[adairw]

Currently it just blocks it, I suppose from a WISP standpoint knowing who is doing such a thing is valuable, I will see if that can be added to to the v1.3.0 run

I am not used to the need for this feature as I NEVER give customers of my WISP Layer 2 access to my net but I understand others do but that is why I did not think of it.

But I suppose even in an office environment the IT guy would want to know of a rogue dhcp server, on what port, mac address, and IP

Will talk to Eric on this for v1.3.0

So basically it just stops DHCP from working on the port?

[sirhc]

Must be your browser, works fine for me?

avatar.jpg (105.34 KiB) Viewed 8960 times

What browser and version?