On Tue, May 13, 2008 at 10:29 PM, Dylan Hall <dylan@xxxxxxxxxxxxxx> 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@xxxxxxxxx" <richardvoigt@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/bridge > > > _______________________________________________ > Bridge mailing list > Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx > https://lists.linux-foundation.org/mailman/listinfo/bridge > _______________________________________________ Bridge mailing list Bridge@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/bridge
