FW 1.3.2 static LAG weird behavior

[tma]

It's been a while and I haven't had the time to dig into this issue further. I'd like to mention, though, that I observed this particular phenomenon again while I was investigating for my posting on RSTP-and-LAG-loops. At that point I was having two switches with 1.3.7 firmware connected together with a 2 cable LAG and I saw the typical 7-8 Mbps traffic ... it remained even after I unplugged the last remaining port where I was connected for managing the switch.

Obviously I this is not enough to proof the point, although I believe there is at least one other post in the forum which may describe the same effect with other words so that the similarity only appears to me ;-). It's only that this one refuses to be reproduced on command but nevertheless happens when you almost forgot about it. Next time I'll take a picture if everything else fails.

There is more to LAGs, static and LACP'ed, though, which I'll put in a separate thread.

[sirhc]

Please work off the current firmware which is v1.3.8, we only investigate issues on the current revision.

IAt that point I was having two switches with 1.3.7 firmware connected together with a 2 cable LAG and I saw the typical 7-8 Mbps traffic ... it remained even after I unplugged the last remaining port where I was connected for managing the switch.

Not sure what you mean by "typical" 7-8 Mbps?

I run LAGs at my office and do not see this behavior?

Do you have RSTP enabled on the ports in the LAG?

RSTP should be enable on the ports with our switches if you are using LAGs.

[tma]

I'm quite sure RSTP was enabled at that point, although I was after something else (mentioned in another post) when this one occurred again to me. Remember I was setting up with four switches and a loop across them, so it was clear that RSTP would be required and would have been turned on in preparation of that lab.

By "typical 7-8 Mbps" I mean that, unlike really heavy storms observedin this issue, the in-LAG-looping is only 7-8 Mbps. And if it ever occurs to me again (and unless I'm hunting down something else at that time) I will take a screenshot.

[tma]

There are two ideologies to handling ports in a defined LAGs, one would be not to allow any traffic to pass across the LAG unless the LAG is complete and functioning which some manufacturers do. The other way is to allow the ports to pass traffic as a standalone ports in the event the LAG is not yet functional for some reason which is what we do.

I could go on and on about the pros and cons with this behavior but we felt in the event a LAG fails down to a single port between our switches we would prefer traffic to flow across the ports as a standard port thus with our switches you are required to use RSTP if using LAGs between two of our switches.

I have to quote you from the other thread because this is the thread where this belongs.

I understand the reasons for the two ideologies, but (since this is not religion) I wonder why neither league wants to give users a switch and let them decide. But just ignore this comment - I would set that switch the way you implemented it :-)

I can't follow you on your conclusions, though. Firstly because LAGs do work without RSTP on your switches 99,9% of time. We have started to use them that way actually: 2 Netonix interconnected with LAG (2 cables), no RSTP. I can plug cables in an out and it just works as it should, no looping. It's only that very rarely, when I do something - like unplugging/plugging cables, possibly even on another port - I would suddenly see that loop-within-a-LAG thing. It also happened once after a firmware upgrade, and once during a deployment when all cables were plugged in and the switches were turned on for the first time. These switches didn't show it since, BTW.

Secondly, a LAG is not a miracle. On a single port, a switch would have to take care not to send a packet back out on the port it was received on. On a LAG, that logic extends to never sending a packet back out on any port of a LAG that was received from one of the LAG ports. If that rule is followed, a loop cannot occur. From observation I can say that your switch follows this rule almost always but very rarely the LAG ports get into a state where the rule isn't followed anymore.

Thirdly, if RSTP was required (all the time) to prevent a loop, what could RSTP do? It could only put one of the four ports into the blocking (NDP) state, i.e. the LAG would have 2 gig one way and one gig in the other direction.

My conclusion from this: If RSTP helps, then only to prevent a rare race condition. It can do that because, when the switch has just been booted or a cable on a LAG port has been plugged/unplugged, this means a topology change to RSTP. RSTP will have to immediately block these ports until the topology has settled - and while they are blocked by RSTP, the LAG ports are being initialized to become members of the LAG.