RSTP bug

[LRL]

To start with I just received my switches and overall I love them!!!

However I found a bug in the RSTP implimentation. Setup is simple. Port 11 to office switch, port12 to 5port bench switch. The 5 port switch also has a link to the office switch. Both the 5port switch and office switch don't have (r)STP capabilities or they aren't enabled. Essentially we have two dumb switches.

I enabled RSTP with the following modifications from default. Switch Priority 57344, changed port12 priority to 144, and of coarse enabled RSTP on all ports.

I started by bring up port11 to the office switch, then I plugged port12 into the 5port switch. Port12 continued to stay in the discarding state. I then unplugged the 5port switch from our office switch. Port12 entered the learning state and finally the forwarding state. I then plugged the 5port switch back into our main office switch. Immediately we encountered a bridge loop and the WISP switch went unresponsive and never comes back until power cycle.

I wanted to test RSTP prior to installing it in our office. Our office is directly linked to our head-end with an AF5 and a NBM5. We run layer2 here for datacenter failover capabilities. My plan was to place this switch in place before our current office switch to power AF and the NB. I figured I'd use the WISP switch's RSTP to manage failover.

From this perspective the switch would failover fine, but when the failed link came back up it would kill all connectivity.

[sirhc]

Well Rory can lab this on Friday and see what is up, turkey day tomorrow so he is off.

I was pretty sure we beat the crap out of RSTP but maybe we missed something?

RSTP is written by Vitesse all we do is write the UI to configure it so I am pretty sure the RSTP is solid as this chipset/switch core is a mature product.

However Eric lives in Canada so maybe he can lab it tomorrow and see whats up.

[sirhc]

However try turning loop protection off when using RSTP

The switch should never need rebooted the way we wrote it.

It will actually reboot itself if needed but will leave the POE ports up during this reboot process.

If loop protection is not disabled it can disable ports which could look like the the switch is brain dead depending on which port you were accessing the UI from.

For instance if you were access the UI from the office switch and that port was disabled by loop protection then you can no longer get to the UI.

Loop protection sends packets out each port and if that packet comes back in another port those ports or one port can be disabled which is different than changed from forwarding state to discarding state.

After so many minutes it re-enables the port and starts over. Normally this period of time is configurable but I think we set it to 5 or 10 minutes. It is on the to do list to put a configurable value in to the UI.

By default we enable loop protection, I should disable it by default probably. Since I run a a routed network with OSPF fail over loop protection is on for me since I do not enable RSTP but people who use RSTP should disable it.

Loop protection is under the Device/Config Tab in the lower right cornor

[LRL]

I seen the loop protection setting, and wondered what exactly it did, but left it alone and on.

Both ports link LEDs go off for a few seconds and then come back on. I was indeed using the office switch to connect to management.

I will give this a try without the loop protection on. I assume this is implemented simularly to how Cisco does gateway loop protection?

I had another strange issue, but haven't had time to explorer it yet. At first glance it looked like broadcast traffic was making it separate vlans. I need to wireshark it and I'll get back to you on that one.

No need to work through the family time for me or this, it can certainly wait.

[sirhc]

Make sure your firmware is updated as there was some recent VLAN fixes in v1.0.5rc1

I know Rory was wire sharking to make sure broadcast traffic was not going across VLANs after the last VLAN firmware patch.

[LRL]

I'm running 1.0.6rc3, that's what was on the switch when it arrived and it appears to be the latest greatest.

I configured ports 1 and 2 to be untagged on vlan20 with no other vlans on those interfaces.

I configured ports 3 and 4 to be untagged on vlan30 with no other vlans on those interfaces.

This was to power a radio with port1 and 3 and bring those into our router's separate interfaces. As soon as we brought up the second link it seemed clear we were getting a loop. Unfortunately I didn't have RSTP running on this bridged segment and it turned ugly.

Normally I'd just use a trunk port for the router but I was just testing this temporarily. I didn't have time to do much more then unplug one radio, but I'll get a closer look.

[sirhc]

Pleases post a pic of your vlan tab

I am positive that our VLANs are working properly as have tested the crap out of them and worked with many people using them in service.

If you read down through this thread you will see several VLAN config we have in service.
viewtopic.php?f=17&t=237


We have some towers set up with vlans to create a mid-span POE injector and other towers we have static LAGs setup between the router and switch and VLAN off all radios including back hauls.

[LRL]

I had forgotten to turn RSTP off on those ports. Once I turned RSTP off the broadcast loop went away.

[LRL]

VLans.jpg (95.45 KiB) Viewed 9670 times

STP.jpg (159.75 KiB) Viewed 9670 times

Here's the screen pics.

[LRL]

I retested the initial problem with Loop Protection unchecked and the switch still acted the same. Removing the second cable doesn't bring the switch back. Moving one cable to a different port does bring the switch back *sometimes*. Other times I can't get the switch to come back without power cycling it.

This issue is reproducible on all three of the 12-250A's I've got.