we use loop guard with RSTP and it is recommended because UDLD is too slow for RSTP.
I may be wrong but the two commands cannot be used together on the same port.
change the partner word in customer if you cannot access it
I see that CCO has changed so sorry if you cannot open it.
Hope to help
UDLD is not too slow for RSTP. RSTP is only fast on links by bi-directional connectivity, where the proposal/agreement mechanism can take place. Else, it just falls back to regular STP timers.
The dispute mechanism is much better than loopguard at detecting unidirectional linke failures. We also have bridge assurance, that can introduce an additional level of safety.
I think it still makes sense to use UDLD along with STP feature because UDLD operates at the link level. For instance, UDLD is able to single out a bad fiber in a channel (sure, LACP should also). STP cannot do this because it is only running on the logical link and can only disable the whole channel should it encounter a problem.
Rapid STP is declared able to converge in 100 msec and UDLD timers (at least last time I checked them) are in the range of seconds: so my idea was that UDLD can be too slow.
However, I admit that handshake cannot happen in a unidirectional link one side sends its proposal but cannot receive the answer from the other side.
If I correctly understand your answer RSTP implementation fall backs to regular STP timers in a unidirectional scenario because no agreement can be received.
I didn't know this.
May you provide a link to the bridge assurance feature?
Thanks for your correction.
Instead of pointing you to the documentation, that is generally not very readable;-) here is a link to a Data Center design guide we recently published and that has an L2 overview. You'll find an overview of Bridge Assurance there.
Loopguard is an option that operates with Spanning-Tree to prevent an alternate port or a root port from assuming a designated role due to the absence of BPDUs. When Loopguard does not receive BPDUs from a root port or a blocking port, it puts or keeps the port in a blocking state and marks the port as Loop-inconsistent
Loopguard has the following key benefits for a Layer 2 network:
â¢ It protects against Layer 2 loops that Spanning-Tree cannot handle
â¢ It works together with Spanning-Tree, so there is no additional protocol traffic on the link
â¢ Loopguard takes care of Layer 2 loops even when Spanning-Tree aggressive timers are used
Hello Carl ,
Root guard are generally enabled on the port other than Root port where we are expecting that some user might plug in another switch ..
Loop guard is generally enabled on ports going to the root bridge (Root port , backup/alternate ) ..
Rootguard and Loopguard are mutually exclusive, the reason being that a âRootguardedâ port is forced to be a designated port all of the time. A Loopguarded port is either a root port or a blocking port.
Loop guard can be enabled globally or per interface ..
Under interface :
spanning-tree guard loop
Global config :
spanning-tree loopguard default