This topic is to discuss the following lesson:
great, tnx for this topic
question, do them work together?
or Cisco doesnt approve to enable them together?
also does them proprietary?
Because there is overlap I personally wouldnt use them togeather. Generally I have seen UDLD used more in the real world but as always…mileage may vary.
I agree, best not to run both of them at the same time…
How “Bridge assurance” differ from these loop preventive mechanism?
Bridge assurance only works on the 6500 and nexus 7000 (and maybe some other high end platforms). It’s enabled globally and detect things like link aggregation errors, port misconfigurationd, etc. It helps to keep STP working properly.
Does UDLD will work from cisco 4500 to a 3rd party switch (IBM g8264)
-I configured the cisco 4500 on a normal mode and on the other side, the port is also on the normal mode
-tried to filter the mac address for udld but the port is still operational.
Do you think that when udld is deployed on cisco with a non cisco equipment, will they still use the udld mac address you mentioned or it is cisco proprietary?
Good question…officially UDLD is a Cisco proprietary standard but there is a RFC for it:
The MAC address should be the same, it’s in the RFC.
Hello Rene, I filter the mac address on the cisco side just like what you did, but the port on the cisco and port on the IBM is still on udld neighbor state. When we remove the transmit strands on one of the fiber cable on cisco, both links are down. Is there any connection with the FEFI on this kind of situation?
Thanks a lot Rene.
It’s possible, some hardware has something like FEFI to detect a link failure so it can take both links down.
Hi. Four questions to help clear my mind when you have a moment.
Is there any benefit to configuring UDLD on links between switches that are copper based?
If configuring loopguard within an environment on what ports is it recommended to be configured on?
Can you elaborate why loopguard doesn’t protect against miswiring?
What are the ramifications of the following - Protection against STP failures because no BPDUs are sent - where you mention that it is not fixed with UDLD, is it then just relying on normal spanning-tree convergence measures (in otherwords a loop would not form)?
- Nope, once something happens on either side…the link will go down. There’s no separate transmit or receive connect with copper links. One topic that is related that you might like is BFD:
You should use it on the blocking (alternate) ports but also on root ports, basically any port that could be in blocking mode if the topology changes. You can enable it globally like I did.
Loopguard works based on BPDUs (L2 information). If a loopguard enabled non-designated interface doesn’t receive BPDUs anymore then the interface will be in a blocking state. Loopguard doesn’t know why or how BPDUs went missing, it just acts upon missing BPDUs. Protocols like UDLD are used as a “keepalive” to ensure that L1 is working (a working physical interface that can transmit and receive).loop-inconsistent blocking state instead of moving through the listening, learning, and forwarding states.
UDLD only helps to have a working link between two switches, that’s it. When something is wrong with the link, UDLD will bring it down. When it does, STP can do its job to create a loop-free topology. It’s also possible that there is no loop in the topology anymore one one of the physical links fails.
Thank you for the detailed replies Rene. One thing I am a little stuck on - for item #2, why in the example do we need to enable loop guard globally on switch A, the root switch which only has designated ports? I guess it doesn’t hurt anything, but please confirm it is not really technically needed?
No problem. Technically, we would only have to enable it on the switches that have blocked ports, you could skip Switch A. Just in case, it’s not a bad idea to enable it globally on all switches with fiber links (in case another switch becomes root or if port roles change).
Cisco does encourage the use of UDLD and loop guard together (because each has gaps the other protects against).
Additionally, loop guard does not work on shared links or in situations where the link has been unidirectional since the link-up. In the last case, the port never receives BPDU and becomes designated. Because this behaviour could be normal, this particular case is not covered by loop guard. UDLD provides protection against such a scenario.
As described, the highest level of protection is provided when you enable UDLD and loop guard.
This is about 2/3 of the way down this page:
Hello Rene, my confusion regarding Loopguard, is when a switch is not receiving bpdus anymore on a alternate/blocking port. I understand that a blocking port does not receive bpdu until moves to forwarding state.
Can you please clarify this statement:" switch C is not receiving anymore bpdus in its alternate port" scnd paragraph below third picture.
" When a switch is sending but not receiving BPDUs on the interface "
Correct me if i am wrong, DP on root bridge only send BPDUs but seldom receive BPDUs -
if we configure loopguard on the root bridge, by the theory above - won’t all DPs on root bridge become inconsistent ?