STP and Loop Guard

[omarmontes]

Hi everyone, I've a question for you guys:

Please check this topology: http://www.cisco.com/warp/public/473/84d.gif

I've read that you must enable loop guard on every nondesignated port (root and alternate ports) to prevent unidirectional related loops. I understand the situation where switch C unblooks the AP port and cause a loop. But what if the link is not unidirectional, what if switch B has some problem and indeed switch C should forward traffic to the segment C-B? Is there a difference between the link going down (disconected)and just stop seeing BPDUs?

Also, why would anyone configure loop guard on a root port? If for example, SWC stops seeing BPDUs from SWA, what would loop guard do? put the port in a block state or it would recalculate its Root port (port to SWB) and put the port to SWA into a designated state (after not receiving BPDS from SWA)? I'm very confused, any help would be greatly apretiated.

Omar Montes

[Francois Tallet]

The assumption made by STP is that if a link is not able to transmit BPDU, it is down. So if there is bidirectional link failure, the case is natively handled by STP. If there is only unidirectional link failure, you could end up with a unidirectional loop (which is about as bad as a bidirectional loop;-))

Loopguard is relevant on each port that is supposed to continuously receive BPDU. If your root port stop receiving BPDU, STP will move it to designated and elect a new root port. This is ok if your old root port cannot receive and transmit traffic. However, if the link is unidirectional and the port does not get blocked by loopguard, you will have a loop through the old and the new root port (in one direction only, the old root port TX direction).

Configuring loopguard on a designated port will not cause any problem anyway, so in fact you can configure loopguard blindly on all the port.

The IEEE introduced a feature (the dispute mechanism) that works much better than loopguard in order to protect against unidirectional link failure. However, this mechanism requires an RSTP bpdu format. It is currently only implemented in MST on cisco switches (it will be soon available in rapid-pvst). No need to use loopguard with the latest MST code at least.

Regards,

Francois

[omarmontes]

Thanks for answering so soon :)

I have another question for you if I may.

I understand what you say about the root port causing a loop it the link problem is unidirectional. But how does the switch knows what kind of trouble it is? I mean, the only synmptom is the absense of BPDUs from the root bridge on SWC, if I configure Loop guard on the root port of SWC, what would happen if it stops getting the BPDUs?

thanks again for the time

[omarmontes]

I've found this on a page at cisco:

"Loop guard is only useful in switched networks where switches are connected by point-to-point links. Most modern campus and data center networks are these types of networks. On a point-to-point link, a designated bridge cannot disappear unless it sends an inferior BPDU or brings the link down"

Just to be sure, does this means that if the links goes down or the root send inferior BPDU then SPT its going to handle the issue like it would normally do (SWC electing a new root port), but if the link stays up and no BPDUs are seen for the max-age timer, then the root port at SWC its going to be handled by loop guard?

[Francois Tallet]

Hi Omar,

Yes, that's correct.

If you stop receiving BPDU on the root port, the normal behavior is to simply forget about the root on this port and to elect it as designated. If and only if you configure loopguard, the switch will put the port in err-disable instead until it start receiving BPDUs again. In case of a shared segment, it would be possible for the current designated bridge to disappear silently as a result of receiving a superior BPDU from a third bridge. That's why loopguard cannot be configured on shared segments. The IEEE dispute mechanism will work on shared segment. Also, a big weakness of loopguard is that it first needs to hear from the designated bridge. If the failure occurs at link up, loopguard will not help because the port would never have been root or alternate. The IEEE dispute mechanism does not suffer from these flaws;-)

Regards,

Francois