A CPU is an electronic circuitry in a computer for processing instructions. So at least in SG300 switches I didn't get the desired behavior with LOOP frames and Storm Control and STP usage is critical.You are here: Home > Device Configuration and Network Management > Aruba Switches > Configuring Loop Protection on Aruba Switch Ports Configuring Loop Protection on Aruba Switch PortsĮnabling Loop Protection consumes CPU Central Processing Unit.
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, 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. The port of the first switch connected to the second switch wasn't disabled and the loop was propagated. 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). 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. As you said Cisco's STP is also capable of detect a Loopback by a loop done in an unmanaged switch.
The first test was to verify STP behavior. The tests were done with two SG300 switches with the latest firmware. 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.ĭoes this answer your question at least partially? Please feel welcome to ask further! I do not believe that this usage of the LOOP frames is compatibly used by the D-Link or HP switches. Also, I have seen only Cisco switches actually use these LOOP frames to perform the detection of a self-looped port. However, note that these LOOP frames are sent by default 5 times less frequently than the STP BPDUs. That is the loopback protection you've asked in your last post. If a port receives a LOOP frame it has originated itself, the port will be automatically err-disabled. In addition, Cisco Catalyst switches emit so-called LOOP frames each 10 seconds on each their port. Yes, that is how Cisco's STP implementation already works. In this case, If a switch sees that a frame returns by the same port he previously sent it, the switch disables the port. Loop protection or loopback detection techniques are used (always with STP also enabled) to prevent this scene. 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. 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. Surely, this detection is done within the BPDU Hello timeframe, i.e. 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. 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. 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. Yes I also consider that STP is the best solution to avoid loops but it's not valid for all purposes.
0 kommentar(er)
