×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Disadvantage of loop guard in STP

Unanswered Question
Jul 1st, 2013
User Badges:

     I want to know what is the effect after configured a loop guard ?



When we use loop guard and what troubleshooting step we need before configure a loop guard....?



Which type of problem dicrease after configure loop guard.


If we configured loop guard and port put into port incosistsnce state. How port will up is it did manualy or any other function to up automatically ?





Clear all function of loop guard in simple language.....

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Peter Paluch Mon, 07/01/2013 - 10:12
User Badges:
  • Cisco Employee,

Hello Naitik,


To my best knowledge, there are no ill or adverse effect to using the STP Loop Guard if used on point-to-point links without any repeaters or media converters.


The primary logic behind the Loop Guard is that on a point-to-point link between two switches, it is not normal to simply stop receiving BPDUs after they have been arriving, without any other change such as port going down or a re-root event. Normally, an entire link goes down, or if BPDUs stop arriving, another topology change in the network takes place that causes the switch to re-elect its root port or perhaps even to change its knowledge of who the root bridge is. Once again: after BPDUs have been arriving, it is an abnormal event to simply stop receiving them without any other accompanying event. However, BPDUs ceasing to arrive without any other event in the network is quite distinctively indicating towards a uni-directional link condition.


This is where the Loop Guard comes in. A port that would stop receiving BPDUs would normally proceed from whatever state and role it is currently to the Designated Forwarding state and role. This could cause an additional port to become forwarding in the topology, possibly causing a switching loop. The Loop Guard prevents this. On Root and Alternate ports, the Loop Guard prevents these ports from transitioning into Designated Forwarding state as a result of loss of received BPDUs. The ports will be put into loop-inconsistent state and kept in the Discarding state until one of the following events occurs:


  • BPDUs start arriving again, in which case the state and role of the port will be dictated by normal STP rules based on the content of receiving BPDUs
  • The port goes down, in which case its entire state is forgotten and reinitialized the next time the port comes up
  • Another topology event takes place that causes the switch to reevaluate who the root bridge is and/or what the root port is, in which case the state and role of the port will again be dictated by normal STP rules


If any of these events occurs, the port will be taken out of the loop-inconsistent state automatically.


The Loop Guard is appropriately configured on all root and alternate ports. Ideally, the Loop Guard shall be activated globally using the spanning-tree loopguard default global config command.


You may want to read more about the feature here:


http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094640.shtml#loop_guard


Feel welcome to ask further!


Best regards,

Peter

benvyates Tue, 07/18/2017 - 16:27
User Badges:

Hi Peter,

I have one follow up question pertaining to something you mentioned in your post; this point in particular: 

  • The port goes down, in which case its entire state is forgotten and reinitialized the next time the port comes up

When you say reinitialized, does this mean the loop inconsistent role is sustained after the port is bounced? Or does the port take on a designated role after the bounce as it is not receiving BPDUs?

In general, if loop guard is enabled on a port that later comes up, does the port go into the loop inconsistent role if it does not receive BPDUs? I would imagine globally enabling loop guard would then cause serious issues, as any port which should rightfully be designated would become loop inconsistent after it comes up.

I think that when you note that the loop inconsistent state is forgotten after a bounce, that means the state is not sustained. This would mean bouncing an LI port or rebooting the switch causes a loop to arise, as the link failure will still be present.

Could you clarify as to which behavior should occur on a loop guarded port after a bounce or switch reboot?

Actions

This Discussion

Related Content