[Bridge] STP bug, loop not detetcted

[Dylan Hall]

If you're going in implement some kind of userland (or I suppose kernel)
daemon that is interested in detecting either the one special case
described previously, or the more general case "my layer 2 network has
melted, protect yourself" it shouldn't matter.  You can implement any
criteria you like for detecting and preventing loops. 

The key here is that these special cases are handled by another process
so your STP can remain standards compliant. 

Dylan


On Tue, 2008-05-13 at 23:09 +0000, richardvoigt at gmail.com wrote:

> On Tue, May 13, 2008 at 10:29 PM, Dylan Hall <dylan at citylink.co.nz> wrote:
> >
> >  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
> 
> That's the difference, in the case described in this thread the packet
> comes back to the same interface, not another one.
> 
> 
> > 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
> >
> >
> > _______________________________________________
> >  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/f4b2a026/attachment.htm