Alan,
You are correct. Cisco recommends that loopguard not be enabled on Designated Ports. Root Bridges, by definition, have nothing but DPs. Therefore, loopguard should not be enabled on it.
Specifically, Cisco says: Loop guard must be enabled on the non-designated ports (more precisely, on root and alternate ports) for all possible combinations of active topologies
Hello Rene,
Could you please let me know your suggestion (your recommendation steps) on what to look for to troubleshoot the UDLD when the port goes into Err-disable mode.
I have a fiber link that always goes in error disable mode (UDLD) and it works fine when I enabled it for about a 4 hours and then goes in err-disable mode again?
Thanks in advance.
Take a look at this very comprehensive Cisco documentation that describes troubleshooting UDLD. Although it is for Nexus switches, the logic is the same concerning IOS devices as well. Take a look, try to apply the troubleshooting principles to your situation and let us know what the results are so that we can help you out in more detail.
In general, such problems are at the physical layer, so changing patch cords, SFP modules or even ports on either end are good tests to determine where the problem exists.
This is no problem. Without loop guard, if a non-designated port stops receiving BPDUs then it goes through the listening > learning > forwarding state.
When you enable loop guard then a non-designated port that receives no BPDUs goes into a inconsistent state instead of going through the listening > learning > forwarding state. It does not affect designated ports.
I think the statement is misleading in your article about UDLD Aggressive mode
Your article states:
Aggressive is a better solution. When it loses connectivity to a neighbor it will send a UDLD frame 8 times in a second. If the neighbor does not respond the interface will be put in err-disable mode.
However, Cisco Switch Textbook states: UDLD messages are sent out once a second for 8 seconds.
âWhen a switch is sending but not receiving BPDUs on the interface, LoopGuard will place the interface in the loop-inconsistent state and block all trafficâ
A few question to clarify, correct me if Iâm wrong:
Interfaces that are in the ALTERNATE role will not send BPDUs but only receive, so how this rule apply here?
âBoth uplink fast and backbone fast are transparent to the loop guard. When max_age is skipped by backbone fast at the time of reconvergence, it does not trigger the loop guard.â Cisco documentation.
Can you explain please?
Regarding UDLD:
Figured out how UDLD actually works from Cisco documentation, but I canât understand how UDLD timers work.
Message interval specifies how often UDLD probes are sent
Timeout interval specifies how long the entry will remain in the udld cache of the switch.
The thing that I donât get here is that the âmessage intervalâ is 15 secs by default and âtimeoutâ interval is 5 seconds by default. So if the entries are removed after 5 seconds, it means that the switch will get a new probe 10 seconds after the cache was cleared, Why wonât it trigger the echo mechanism?
Cisco in their documentation says that whenever a new neighbor is detected or an out-of-sync message comes in: â,it restarts the detection window on its side of the connection and sends echo messages in replyâ.
Yes you are correct. The statement should more readily read âWhen a port stops receiving BPDUs, then LoopGuard will place the interface in the loop-inconsistent state and block all trafficâ This prevents the port form subsequently transitioning to a designated role and a forwarding state that can potentially create a loop. (Iâll let Rene know).
Essentially what is being said here is that loopguard does not affect the functionality of uplinkfast or backbonefast. In the case of backbonefast, the max_age is disregarded. The max_age is the time the port will wait before going to the forwarding state (without loopguard) or the time the port will wait before going to the loop-inconsistent state (with loopguard). With backbonefast, this max_age timer is set to 0 and loopguard is not enabled at all.
According to Cisco (see documentation below), the default message interval is 15 seconds while the detection time, hold time or timeout interval, whatever you want to call it, is three times that value which is 45 seconds. If three message intervals elapse, only then will the ageing of the cached UDLD information occur.
You can find out more about this at the following Cisco documentation:
Hi,
When an intergace in in blocking sate, does it send bpdus? What if its a real cut on the entire link between sw2 and sw3? IS it going to get into the loop-inconsistent state?
During the blocking state, the port will be able to receive BPDUs and process them. However, if there is a disconnection of the entire link, such that the cable is cut or a cable is removed, then the ports on either end will be down completely, so they wonât be in any STP state. STP states exist only on ports that are active, that is, that have an active connection to them.
How is possible one Designated port linked with an alternate/blocked port work with UDLD, once the alternate port doesn`t send frames? How are the UDLDs frames exchanged between these ports? Is there any implicit policy that permits only UDLD frames and block other else?