STP not entirerly disabled

[LRL]

This is a weird one that took me a while to track down.

Tonight after a couple of days of testing I decided to activate a new AF24 link. In doing so I was changing the vlan that the port AF24 we hanging on was untagged on.

I had AF24 attached to port2 untagged on vlan1 and needed to switch it to vlan2 to make the swap. As part of this I needed to take port8 out of vlan2 and move it to vlan1. I screwed up, when I did this and moved port1 into vlan2 and moved port8 to vlan1, unfortunately I left port2 in vlan1 which caused a bridge loop. I finally managed to turn one of the backhauls off at the other side, and restore connectivity. When i did I corrected my error and all should have been fine.

Since we're in transition to layer3 and ospf I noticed it first on the ospf routers. The peers kept dropping. We use BFD to aid in quick link failure detection. The ospf adjacenties kept dropping for no easily identified reason.

After further investigation our normal root bridge was no longer the root. The MAC given by the normal root was the MAC of the tower switch on vlan2. Further our normal root showed the priorety of the switch to be set at 0. I change the priority of our normal root to 0 and finally it was elected as root. I hoped the intermittent loss would stop here, but it didn't.

I attempted to reboot the switch to solve the issue, unfortunately the switch never came back up on it's own. After cycling the switch the sporadic loop issue went away.

[Dave]

lrl, thanks for feedback, we will look into this for you...dave

[Rory]

If possible, I would like to have the configs of the affected devices so I can look into this in a lab setup. However, I am fairly certain that after causing a loop condition the mac tables and other similar systems are likely to be somewhat off. I had actually seen something similar a few weeks back. I had intentionally caused a loop, and after resolving the loop there was some dodgy switching behavior until I power cycled the switch. In that specific scenario I had the ability to recreate the conditions exactly, so I did so quite a few times. Unfortunately I was not able to get the error condition to recur in a reasonable amount of time, or ever.

So this may just be resource depletion or other error condition that occurs when the switch is (almost literally) processing an infinite amount of packets. Please do not misunderstand, I do not mean to be dismissive, and I am very serious about getting some configuration backups for the purpose of testing this out. But if it is not easily reproducible, or reproducible at all, I will probably chalk it up to a memory leak. If we can reproduce this, we can fix it.

[mhoppes]

What firmware version were you running? Rebooting should have brought it back without a hard cycle.

[sirhc]

Well even that is debatable. When you mis-configure a switch and cause a loop "sometimes" it will just need power cycled.

As Rory said he has tested loops and the affects on the switch in the lab and where as "most" times it will just recover on it's own sometimes a reboot is needed.

The reboot "most" times could just be a warm UI reboot like you say which leaves the POE ports up and switch core up(preferred method) but sometimes depending on the positions of the moons of Jupiter it may require a hard power cycle because where as the switch core is a separate entity it too is a piece of computer equipment running a program and not every event can always be recovered from and we are talking about an infinit loop and packets.

Most managed switches will not recover from a loop 100% of the time and even some dumb switches need power cycled after a loop in the segment.

In my office at my WISP there is a small ASUS 8 port un-managed switch because of all the check printers (remember I own 5 companies so there are lots of check and deposit slips) and when a loop occurs in the office segment that switch always goes out to lunch and needs rebooted.

When Eric was down here last year developing this code and was purposely causing loops I was always having to reboot that ASUS un-managed 8 port switch after each loop test.

[mhoppes]

Is there a way to add a "cold reboot" option to the web UI? Remember, some of us have sites that are basically inaccessible for 3-4 months out of the year

[sirhc]

Is there a way to add a "cold reboot" option to the web UI? Remember, some of us have sites that are basically inaccessible for 3-4 months out of the year

We can look into this but the switch will recover under MOST circumstances and this was from being MIS-CONFIGURED and a LOOP occurring and can not be recreated all the time.

If you create a loop on a TOUGH or edgeMAX Switch they do not recover from a loop 100% of the time either, or any switch for that matter even Cisco and HP.

A power cycle is very HARD to recreate which is why it is called a POWER CYCLE!!!!

How do you power cycle any computer equipment....you turn it off or unplug it and count to 5 and plug it back in.

This is NOT a weak spot on our design but rather industry standard with electronics.

Now with our DC switches this would be easy as the power supply was designed by us and has it's own processor and the ability to CUT power to the switch same as power cycling it.

[mhoppes]

Another reason to go all DC ;)

[lligetfa]

A power cycle is very HARD to recreate...

IKWYM but I have also run into situations where I could soft boot some piece of kit but it would not fix what ailed it without a full hard boot. PITA when you have to go for a walk or drive but it is the nature of the beast. I have had to utilize remote controlled power to get a complete power toggle. Of course that gets downright tricky if'n/when your link to the site depends on the very power you want to cut.

[Dave]

now image how cool our dc-dc models will be, we can issue a power cycle command via the GUI, the on board micro on the dc-dc power supply will power down the actual dc supply, and 5 seconds later power it back up, ya won't have to mess with the power to your other devices in your tower at all..sounds cool to me!