Loop guard

Dear Experts,

Got a question about STP loop guard here. In the following setup, what will happen if loop guard is configured on interface f0/0 on both SW1 and SW2? Will SW1 put f0/0 into loop inconsistent state because it's not receiving BPDUs on this interface?

SW1 (root) f0/0 <---> f0/0 SW2

Thanks in advance for your insights.


  • hi HS268,

    My understanding is that Loopguard only works on interfaces that are in the following STP states:

    1. Root

    2. Alternate

    Your root switch will have all interfaces (all 1 of them) in the designated state.

    This is because we always expect BPDU's on Root and alternate interfaces. If the interface is Designated, Edge or Backup it wont block the interface as we dont expect BPDUs on these. having said that, in a different topology to yours, interface states can change so it might be wise to apply universally across the network.

  • Thanks mcewin. That's very clear. It's the dynamic nature of port roles in STP which caused some confusion in my mind initially. I went through the Cisco docs one more time, and was convinced that at anytime STP knows exactly which role a port plays, including the distinction between Alternate and Backup port. [:)]

    Below is another way to understand how Loop Guard works:

    1. Loop guard only applies to ports in blocking state.

    2. A port must keep on receiving BPDUs in order stay on blocking state.

    3. A blocking port will transition to forwarding state when it stops receiving BPDUs, unless loop guard is configured in which case the port will be put in loop inconsistent state.

  • 1. Loop guard only applies to ports in blocking state.

    What was I thinking? Loop guard works on root port too which is certainly not blocking. On the other hand does it work on backup port? If not, I may have managed to make two mistakes in one short sentence. LOL

  • The backup interface had me thinking for a while to before I understood why Backup ports do NOT participate in LoopGuard. Here is my understanding but I am open to correction  :-)

    Firstly, loopguard is mainly about noticing when BPDU's stop being received from OTHER switches. When you are connected to another switch you assume a certain STP role. Depending on your role, a lack of BPDU's sometimes doesnt make sense. For example, if I am a root/backup/alternate port I should always receive BPDU's.

    OK cool, but then why dont backup ports participate in Loopguard?

    Loopguard says, BPDU's can trigger changes to the topology on Root ports and Alternate ports, but a lack of BPDU's can not. In the case of no BPDU's, something is wrong and we should block. These are the only ports that loopguard is required on.

    I have summarised below my understanding.

    1. Root ports expect BPDU's and therefore if we dont see any we go to forwarding state. If that port is connected to a switch, there is no reason to expect that BPDU's will ever stop being recieved on a Root port. (without filters etc) Loopguard protects you against a one way connection in this case.

    2. Designated ports send BPDU's, they dont receive them (once converged). Loopguard is not required on these ports or at least not when the port is in this state.

    3. Alternate (Blocking) ports are only alternate because they receive a better BPDU from ANOTHER switch. If your topology shows that you are connected to a switch on this interface, there should never be a reason that you stop receiving BPDU's on an alternate port. Loopguard protects you against loops and one way connections in this case.

    In a topology change situation you may receive a worse BPDU and then you will start forwarding. Loopguard is OK with this but a lack of BPDU's doesnt make sense.

    3. Backup (Blocking) ports are only backup because they see a BPDU from YOURSELF. Maybe you plugged into yourself or you are on a hub. Either way, This one had me confused until I realised that if I stop sending the BPDU's out one of my own ports and another one of my own ports stops receieving them, I probably already know about it as I am the sender and receiever. Loopguard is not required for this state as the switch knows what its sending.

    NOTE: Loopguard does not work on shared links. 

    Its a bunch of subtle concepts and Im sure there are others who can explain it better but hopefully that explanation is correct and  helps. 

  • rmcewin. Great stuff. Much appreciated. Just one minor note if I may. Loop guard is mainly used to protect against UDLD kind of situation. In other words it's not a matter of the senders no longer sending the BPDUs, but rather that the BPDUs got lost without the senders realizing it. I tend to agree with your position on the backup port. It'd be great if someone could lab it up and see how the switch behaves. Unfortunately Dynamips doesn't support loop guard.

  • Your welcome. You have helped me out in the past so its nice to be able to return the favour. IEOC is a great resource.

    One thing though, some of the Doco mentions that loopguard does not perform detection of unidirectional cables like UDLD but it does support the situation where the software has malfunctioned and the switch stops sending BPDUs for some reaon. This is the link I found very helpful.


    I will lab it up next time I get a switch and report back. (only need one) Probably on the w/e.


  • HI,

    What I understood about loopguard is, if a switch stop receiving BPDU's on loopguard enabled port switch will move the port into STP loop inconsistant state. If loopguard is enabled on NDP and if  BPDU's are not received, instead of putting the port into forwarding state switch makes the port as root inconstance.

    Correct me if I was wrong 

  • Thats correct at a high level. The configuration can be applied on all ports but it only stops the port forwarding after a lack of BPDU's when the port is in the Root or Alternate state. The spanning-tree port states are dynamic so it pays to configure on all ports that can become root or alternate ports.

Sign In or Register to comment.