STP's LoopGuard?

hey,

The loop guard is intended to provide additional protection against L2 forwarding loops (STP loops). An STP loop is created when an STP blocking port in a redundant topology erroneously transitions to forwarding state. This usually happens because one of the ports of a physically redundant topology (not necessarily the STP blocking port) stopped receiving STP BPDUs. In its operation, STP relies on continuous reception or transmission of BPDUs, depending on the port role (designated port transmits, non-designated port receives BPDUs).

taken from www.cisco.com/warp/public/473/84.html#feature

:oops: How is it possible that a blocking port won't get bpdus and still, the other side keeps sending them?

It should be very simple to understand though very hard to experience.
The document highlights UDLF(Uni-Directional Link Failure) to explain the problem cause. Meaning, first side assumes that there is no problem with the link, while to the second side, link has failed. In this case, first will keep expecting the BPDU since no issues with the link is observed but how will the second side send the BPDU when link has failed as per his observation.

This usually happens during interoperability and when the L2 parameteres (Speed/duplex/autoneg) do not match.
I have experienced this when trying to connect 2 vendors using fiber cable. One was strict on the standard conformance while second was not due to which I faced almost similar issue.
This can happen anytime, when the switches are running fine or when trying to bring the link up from scratch.

Another possible cause could be that when the switch is constructing the frame, the FCS calculation done is wrong due to some issue and so the BPDU is never re-constructed at the receiver. Something like the output error counter keeps incrementing at the sender side along with the input error counter at the other side.

hope this provides you better understanding.