No matter how secured or precise the configurations are, there are some problems you can’t almost avoid, particularly L2 loops. The looped frames have no TTL to decrement and nothing else to lose. It unleashes at a perfect time, a critical production hour or perhaps Friday nights!
A common approach is to tighten STP configuration and enable BPDU guard, root guard, loop guard, Unidirectional Link Detection [UDLD], storm-control or disable unused ports, where ever applicable.
Even with the right configurations in place, incorrect STP port transitions, hardware issues, misplaced root bridge etc., can still cause loops. And not to forget the mysterious unmanaged switches that occasionally show up on the network.
The STP loopguard will only react if a root or Alternate port stops receiving BPDUs. But nothing that explicitly detects and stops an ongoing loop.
One such feature is the Loop Detection Guard on the catalyst 9000 switches. The function is simple, send a frame out of one port and see if it returns on another. The feature is introduced on 17.2.x & later releases and supported on all Catalyst 9000 platforms.
So how does the Loop Detection Guard work?
A port enabled with Loop Detection Guard sends out a loopback frame and checks if it returns to the switch. If it does, the switch error disables source port or destination port, whichever is the configured action. The loop detect frames are L2 frames with Ethertype loopback. The loopback frames have the source interface mac as the source mac and switch base mac address as the destination mac.
A recipient device typically drops these frames as the destination MAC address is different. If the frame is forwarded back to the originating switch, the loop detect guard will kick in.
The loopback frames are untagged, it doesn’t matter what VLAN the frame is sent on, it just shouldn’t return to the originating switch.
Configuration & Implementation Flexibility
The configuration guide for Loop Detection guard provides the CLI and options. The loop detection guard feature needs to be defined explicitly per port. Unlike STP, there’s no global configuration line for this feature and there is a good reason why; you will know as you read on.
Strictly speaking STP should prevent loops at the first place; but if STP fails for any reason and causes a network loop, the loop detect guard [if enabled] can kick in to stop.
On detecting a loop, option to disable either the source or the destination port provides implementation flexibility. What that means is the feature can be enabled on only key ports of a switch and let the feature take action on rest of the other ports.
Let’s say there is a loop in the network between the uplink and one of the downlink ports. The Loop Detect Guard can be enabled only on the uplink ports. And if the actionable port is set to destination port, it will err-disable the downlink port that is participating in a loop with the uplink. The downlink ports need not have this feature explicitly enabled.
The loop detection guard can be configured on all ports as well, but the configuration is simpler if it is enabled only on the uplink or any other key ports and let the feature take action on the downlinks. I recommend it to be tested before it is implemented in production.
STP Loopguard vs Loop Detection Guard
Here’s a quick comparison of feature names and its functions:
If a port configured with STP loopguard stops receiving BPDU’s, the blocked port will transition to loop-inconsistent state only after max age expires. At this point ports stop processing user traffic until BPDUs arrive.
Loop detection guard has default timer value at 5 seconds and configurable maximum of 10 seconds. The loop detect feature reacts to a loop more quickly than STP loop guard and provides option to shut down only ports in question.
Conclusion
Loop detection guard is a new way to prevent loops with both STP and non-STP enabled ports or unmanaged switches. While legacy solutions can continue to be used in the way it is used today, the new loop guard feature complements it. The feature provides better a better way to handle network loops when traditional method fails. I recommend testing the intended configuration in a lab before it is deployed in production.
Check out our Cisco Networking video channel
Subscribe to the Cisco Networking blog
Share: