[Bridge] STP bug, loop not detetcted

[Dylan Hall]

I've only been half following this thread, but is sounds a lot like
you're discussing a problem that has already been solved by Cisco (and I
assume others).

Most Cisco switches will generate a loopback packet (ethertype 0x9000)
at fairly regular intervals.  Both the src and dst mac addresses are set
to the interface mac of the port emitting the packets.  In the event a
loop exists in the network that hasn't been dealt with by (R)STP the
switch will receive the packet back on another of it's interfaces.  In
the event one of the loopback packets does make it back to the switch
the port is error-disabled (I can't remember if it's the sending or
receiving port that is disabled).  This mechanism is independent of
STP. 

UDLD also seems to have a mechanism to detect a port that is looped back
on itself.  Again, independent of STP.

Rather than modifying STP would it not be better to implement something
like the above as a standalone daemon? 

Dylan


On Tue, 2008-05-13 at 10:41 +0200, Benny Amorsen wrote:

> "richardvoigt at gmail.com" <richardvoigt at gmail.com> writes:
> 
> > For example, this topology:
> >
> > br0 - br1 - br2 - br3 - br1
> >
> > There is a loop in br1-br2-br3-br1, so br0 sees its packet come back
> > on the same interface.  If br0 shuts down the interface, it breaks
> > connectivity.  The br0-br1 link is part of a minimal spanning tree so
> > STP cannot shut it down.
> 
> Since the alternative is to melt due to traffic overload, the switch
> sure can shut it down. That breaks connectivity, but only for the
> broken segment. Not shutting the interface means everyone gets hurt.
> 
> 
> /Benny
> 
> 
> _______________________________________________
> Bridge mailing list
> Bridge at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/bridge/attachments/20080514/8387da34/attachment.htm