understanding unidirectional links

hi.622823 · ‎10-04-2007

hey all.

haveing trouble understanding unidirectional links and its impact on spanning tree. consider the diagram attached. link B-C is unidirectional --- B can transmit to C, but not vice-versa.

i understand that B transitions to forwarding, but i don't see how a loop forms. that is, frames obviously can take path A-C. but can frames take path A-B-C? i thought because of unidirectionality, path A-B-C is not possible, and so switch B's designated port acts like it's blocking. where is the flaw in this arguement?

also, in what real-life scenoris does a unidirectional links occur? is it one of those 1 in 1000 situations?

finally, what is the difference between UDLD and loop guard? i read, for example, loop guard protects against software problems that cause STP failure, but i don't know what it means. your thoughts are appreciated.

thanks in advance.

Kevin Dorrell · ‎10-04-2007

Unidirectional links are very very rare. I have seen one once. They are rare because, for a unidirectional link to occur, the layer-1 must be up (light on the fiber, carrier on the copper etc.), but the layer-2 down. In other words a broken receiver.

This can cause loops in two situations. The first is the more esoteric one: where you have redundant links in the Spanning Tree. Spanning Tree works by detecting BPDUs (i.e. receiving them) and then blocking certain ports to stop the loops. However, if you have a unidirectional link, it could be that you don't receive the BPDUs when you should. So you unblock the port, and start forwarding on it. Thus you have a loop going one way round the loop, but not the other.

The other situation is more common if you are careless about your cables. Suppose you are cabling two fiber links, of the type that have seperately plugged transmit and receive fibers. And you mismatch them ... you pair the transmit line for A with the receive line for port B, and vice versa. Unless you have UDLD to protect you, each link seems to be up. But who knows what topological knot you have got yourself in .. either a lockout or a loop.

Does that make sense?

Kevin Dorrell

Luxembourg

Francois Tallet · ‎10-04-2007

In your diagram, the fun scenario comes if the link B-C is unidirectional but C can transmit to B and not vice-versa. In that case, there is no blocked port on C (because it does not receive the BPDUs from B). B receives the BPDUs from C, but they are inferior and thus ignored.

Here, the traffic cannot loop clockwise (because there is no communication from B to C), but it can definitely loop endlessly in the counter-clockwise direction because there is no blocked port.

UDLD will detect this.

Loopguard will detect the problem if it does not happen at link up. For instance, initially, B could send BPDUs to C. C is blocked and suddenly stops receiving its BPDUs because of the failure -> here, loopguard keeps the link in blocking state. The problem is that, if the failure is occurring at link up (C never received any BPDU), the problem will not be detected.

Eventually, the dispute mechanism implemented by MST will work fine here. When B receives the inferior BPDUs from C, it notice that the role of the remote port is designated. B can conclude that the remote port does not receive the superior information that B sends, and that there is a unidirectional link failure. In that case, B will block and prevent the loop. This mechanism will work even if the failure occurs at link up. It is in the IEEE standard (but we only implemented it in MST mode).

Regards,

Francois

hi.622823 · ‎10-04-2007

hmmm...need to check my stp fundamentals...

okay, assume the situation depicted as in my original diagram. and for the sake of argument, let's say all cables are working normally (no unidirectional links).

lets say a user on switch A generates a broadcast frame (eg arp request). so the frame goes via A-C and is not forwarded at C's blocking port(yes/no?). the frame also goes from A-B-C and is again dropped at C's blocking port (yes/no?).

Francois Tallet · ‎10-04-2007

Yes. But to come back to the unidirectional link failure scenario, when B cannot send traffic to C, C does not get the BPDUs from B and thus C is not blocking. So traffic can go from C to B then to A and back to C... that's the (unidirectional) loop.

Regards,

Francois

hi.622823 · ‎10-04-2007

i see. so normally you have loops going in both directions, but with a unidirection link the loop goes one way.

Kevin Dorrell · ‎10-05-2007

Not exactly. Loops are bad - they make packets go round in circles forever (in both directions) and cause broadcast storms. But redundancy is good, and redundancy means multiple paths and therefore loops.

Normally, you do design multiple paths into your network, but Spanning Tree cuts the loops automatically to stop them causing prioblems. Then if you have a link failure somewhere else, Spanning Tree repairs the cut it had made to restore the connectivity.

But if you have a unidirectional link, Spanning Tree might interpret that as a link failure, even if it is only half a link failure. So Spanning Tree repairs the cut it had made. But in effect, the link still exists, albeit in one direction only. So you get packets going round in circles forever and broadcast storms.

Kevin Dorrell

Luxembourg

hi.622823 · ‎10-04-2007

correction: in the diagram, C can trasmit to B, but not vice-versa. i got it backwards in the post. (and oddly i am not able to edit my first post).

hi.622823 · ‎10-04-2007

thanks everyone for your responses

kjbarrass · ‎10-05-2007

on a network we have using adva FSP200 DWDM kit I have seen uni-directional links occur, I presumme due to a problem on the adva kit. As we run MST udld's timers unfortunatly couldnt disable the link quick enough so caused a short spanning tree loop due to spanning tree not seeing BPDUs from the other side assuming the link is down so re-converging then 10 seconds later UDLD blocking the interface as it realises it is udld.