similar feature to HP Loop Protection?

[christian.pinedo]

Do Cisco Catalyst (IOS) and specially Cisco SG300/500 support a similar feature to HP's Loop Protection or DLINK's Loopback Detection? This is an interesting feature to avoid loops caused by unmanaged switches.

Thanks,

Christian

[Peter Paluch]

Hi Christian,

Cisco IOS switches and presumably the SG switches as well support STP that is by itself sufficient to prevent loops. I do not believe that Cisco switches support the HP or DLink proprietary methods of preventing loops. As long as the switch supports STP, there is basically no reason to implement other anti-loop protections.

Best regards,

Peter

[christian.pinedo]

Yes I also consider that STP is the best solution to avoid loops but it's not valid for all purposes. For example, a user could connect an unmanaged switch in your switch port, do a loop in his unmanaged switch and all the STP network goes down.

Loop protection or loopback detection techniques are used (always with STP also enabled) to prevent this scene. In this case, If a switch sees that a frame returns by the same port he previously sent it, the switch disables the port. Simple but it works.

I would like to know if Cisco supports this feature (Catalyst and SG300/500 switches) or if it has a similar featura (storm control perhaps?). Thanks!

Christian

[christian.pinedo]

I have discovered the interface error Loopback. This could be the feteaure I'm looking for??

[Peter Paluch · Accepted solution]

Hi Christian,

Yes I also consider that STP is the best solution to avoid loops but  it's not valid for all purposes. For example, a user could connect an  unmanaged switch in your switch port, do a loop in his unmanaged switch  and all the STP network goes down.

This is only partially true. Cisco's implementation of STP is done in such a way that if a port receives a STP BPDU it has originated itself, the port will be automatically put into Blocking state. In other words, Cisco's STP implementation alone is capable of detecting and blocking even a self-looped port caused by attaching a looped unmanaged switch.

Surely, this detection is done within the BPDU Hello timeframe, i.e. 2 seconds by default. During these 2 seconds, the looping traffic may become so overwhelming that the Cisco switch will be unable to process the self-looped BPDU and block the port anymore. However, no protocol or protection is designed to cope with this - because this is a reactive protection, not a proactive protection, and reacting to a disastrous situation that is already well underway may itself be (nearly) impossible.

Loop protection or loopback detection techniques are used (always with  STP also enabled) to prevent this scene. In this case, If a switch sees  that a frame returns by the same port he previously sent it, the switch  disables the port. Simple but it works.

Yes, that is how Cisco's STP implementation already works. In addition, Cisco Catalyst switches emit so-called LOOP frames each 10 seconds on each their port. If a port receives a LOOP frame it has originated itself, the port will be automatically err-disabled. That is the loopback protection you've asked in your last post. However, note that these LOOP frames are sent by default 5 times less frequently than the STP BPDUs. Also, I have seen only Cisco switches actually use these LOOP frames to perform the detection of a self-looped port. I do not believe that this usage of the LOOP frames is compatibly used by the D-Link or HP switches... then again, these LOOP frames are actually intended to be processed only by their originating switch and they are not to be mutually exchanged between a pair of switches, so it does not matter if the neighboring switch understands them.

Does this answer your question at least partially? Please feel welcome to ask further!

Best regards,

Peter

[christian.pinedo]

A really great response Peter. That was what I was looking for. I'm going to test it in some SMB Swithces (SG300) where I found the problem and I will write again. Thanks!

[christian.pinedo]

I did the tests yesterday. The tests were done with two SG300 switches with the latest firmware.

The first test was to verify STP behavior. As you said Cisco's STP is also capable of detect a Loopback by a loop done in an unmanaged switch. Indeed, Cisco's STP blocks the port and inserts a line in the log indicating that a "STP Loopback" has been detected in that port.

The second test was done to discover what happens when the STP is disabled in the first switch (the second switch has already disabled STP and it has the loop).

The port of the first switch connected to the second switch wasn't disabled and the loop was propagated. So, the LOOP Frames are not checked in SG300 switches or perhaps the 10 seconds time is so big that the loop is propagated and then there is no solution.

I also enabled "Storm Control" in the port of the first switch that is connected to the second switch, but the port wasn't disabled and the loop was again propagated by the first switch.

So at least in SG300 switches I didn't get the desired behavior with LOOP frames and Storm Control and STP usage is critical.

[juantron]

But what happens if you use a hub instead of a unmanaged switch? No bpdus, so the loop is guaranteed. I think, in these cases the best option is to use stp loop guard along with storm control.