Hello,
what you wrote is almost correct. Network topology loops (these which can't be evaded by STP itself) may have different causes.
Described two mechanisms can be used for prevention of loops caused by specific failures (as malfunctioning network switch, or malfunctioning cable). Their principles are different and use cases may be different as well. Proper understanding before implementation is needed.
Loop Guard is mechanism which works on logical ports (from perspective of STP). You turn it on on port, but it is effective per VLAN (in case of PVST+/Rapid) . You can't turn it on per VLAN, but when it acts (blocks port) it affects only particular VLAN.
UDLD is mechanism, which is independent and works on particular physical ports.
Special care is needed when you use ether-channels, which is quite often:
In that case the behaviour of Loop Guard will be like this: If your device will not receive BPDUs (for example as a result of malfunctioning cable/port/switch) in particular VLAN (in usual cases in all VLANs) on one of ports in Etherchannel(STP chooses only one port for BPDU traffic) it will move logical port (Etherchannel !) in loop-inconsistent state for this VLAN(s). Let me stress it - the whole Etherchannel is out of order(for that VLAN).
When you use UDLD in the same scenario, and you met conditions for UDLD to act (you stop receiving UDLD frames), you end up with particular physical port blocked.
As I often implement Etherchannels for link redundancy, my personal best practice is to not use Loop Guard and to use UDLD wherever it is relevant. UDLD may be used in normal or aggressive mode. Note that aggressive mode is not recommended for VSS.
During my carrier I definitely encountered a lot of cases, when UDLD was or would be helpful. I also encountered few cases, when UDLD erroneously errdisabled ports because of stressed device CPU. You should implement errdisable recovery for that case and you shouldn't use aggressive mode.
I encountered only one case when the network could be saved only by Loop Guard and it was caused by malfunctioning Supervisor, which was working well, except for it didn't send BPDUs :-)
Described features definitely help to protect the network, but more configuration and operation (and design) steps are needed to evade other common causes of loops.
Regards
Stepan
