[Bridge] STP bug, loop not detetcted

[Bridge] STP bug, loop not detetcted

[Joakim Tjernlund]

Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
eth1.4, attached and the builtin STP enabled. eth1 is connected to
a "switch" with 4 real interfaces, each real interface maps to one of
the above mentioned VLANs.  

If I loop two or more interfaces by connecting each interface's output
to its own input, I get a loop that STP doesn't detect.
Looping by connecting an output from one interface to another interface
input works fine.

Bug or limitation in STP? If limitation, would RSTP help here?

Kernel 2.6.25

 Jocke  

Re: [Bridge] STP bug, loop not detetcted

[Jaime Nebrera]

  Hi Joakim,

  I'm not aware if Linux bridge is aware of this. I can tell you that in
general, STP has problems when mixed with VLANs.

  To solve this some extensions have arised: PVST by Cisco, MSTP, an
improvement more or less estandarized and PVST+, a new update only
available in Cisco environments.

  In general they run multiple "STP" instances per VLAN or VLAN group.

  Regards

El mié, 07-05-2008 a las 11:22 +0200, Joakim Tjernlund escribió:
> Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
> eth1.4, attached and the builtin STP enabled. eth1 is connected to
> a "switch" with 4 real interfaces, each real interface maps to one of
> the above mentioned VLANs.  
> 
> If I loop two or more interfaces by connecting each interface's output
> to its own input, I get a loop that STP doesn't detect.
> Looping by connecting an output from one interface to another interface
> input works fine.
> 
> Bug or limitation in STP? If limitation, would RSTP help here?
> 
> Kernel 2.6.25
> 
>  Jocke  
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge
-- 
Jaime Nebrera - jnebrera@eneotecnologia.com
Consultor TI - ENEO Tecnologia SL
Pol. PISA - C/ Manufactura 6, P1, 3B
Mairena del Aljarafe - 41927 - Sevilla
Telf.- 955 60 11 60 / 619 04 55 18

Re: [Bridge] STP bug, loop not detetcted

[Benny Amorsen]

Jaime Nebrera <jnebrera@eneotecnologia.com> writes:

>   Hi Joakim,
>
>   I'm not aware if Linux bridge is aware of this. I can tell you that in
> general, STP has problems when mixed with VLANs.
>
>   To solve this some extensions have arised: PVST by Cisco, MSTP, an
> improvement more or less estandarized and PVST+, a new update only
> available in Cisco environments.
>
>   In general they run multiple "STP" instances per VLAN or VLAN group.

PVST+ simply tags the STP packets. It's the obvious, stupid, and
correct solution. It's the same thing Linux does when you bridge
eth0.1 with eth0.2. Of course Cisco had to change the STP packets just
enough that Linux doesn't interoperate by default.


/Benny

Re: [Bridge] STP bug, loop not detetcted

[Benny Amorsen]

Joakim Tjernlund <joakim.tjernlund@transmode.se> writes:

> If I loop two or more interfaces by connecting each interface's output
> to its own input, I get a loop that STP doesn't detect.
> Looping by connecting an output from one interface to another interface
> input works fine.

Do you see BPDU packets come back when you do the loops? tcpdump can
probably help. It sounds like the switch is eating your BPDU's.


/Benny

Re: [Bridge] STP bug, loop not detetcted

[richardvoigt]

On Wed, May 7, 2008 at 9:22 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
> Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
>  eth1.4, attached and the builtin STP enabled. eth1 is connected to
>  a "switch" with 4 real interfaces, each real interface maps to one of
>  the above mentioned VLANs.
>
>  If I loop two or more interfaces by connecting each interface's output
>  to its own input, I get a loop that STP doesn't detect.
>  Looping by connecting an output from one interface to another interface
>  input works fine.
>
>  Bug or limitation in STP? If limitation, would RSTP help here?

Limitation in STP.

If a bridge receives one of its own STP packets on the same interface
from which it was sent, that indicates a loop elsewhere in the network
that disabling an interface locally will not fix, therefore STP takes
no action.

>
>  Kernel 2.6.25
>
>   Jocke
>  _______________________________________________
>  Bridge mailing list
>  Bridge@lists.linux-foundation.org
>  https://lists.linux-foundation.org/mailman/listinfo/bridge
>

Re: [Bridge] STP bug, loop not detetcted

[Joakim Tjernlund]

On Thu, 2008-05-08 at 02:16 +0000, richardvoigt@gmail.com wrote:
> On Wed, May 7, 2008 at 9:22 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> > Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
> >  eth1.4, attached and the builtin STP enabled. eth1 is connected to
> >  a "switch" with 4 real interfaces, each real interface maps to one of
> >  the above mentioned VLANs.
> >
> >  If I loop two or more interfaces by connecting each interface's output
> >  to its own input, I get a loop that STP doesn't detect.
> >  Looping by connecting an output from one interface to another interface
> >  input works fine.
> >
> >  Bug or limitation in STP? If limitation, would RSTP help here?
> 
> Limitation in STP.
> 
> If a bridge receives one of its own STP packets on the same interface
> from which it was sent, that indicates a loop elsewhere in the network
> that disabling an interface locally will not fix, therefore STP takes
> no action.

I see, would it hurt something else if STP did turn off it interface in
this case? Optical i/f's is getting more common so these types of loops
will increase so I think this needs to be addressed.

Any chance Rapid STP will fix my problem?

 Jocke

> 
> >
> >  Kernel 2.6.25
> >
> >   Jocke

Re: [Bridge] STP bug, loop not detetcted

[Francesco Dolcini]

Joakim Tjernlund wrote:
> On Thu, 2008-05-08 at 02:16 +0000, richardvoigt@gmail.com wrote:
>> If a bridge receives one of its own STP packets on the same interface
>> from which it was sent, that indicates a loop elsewhere in the network
>> that disabling an interface locally will not fix, therefore STP takes
>> no action.
> 
> I see, would it hurt something else if STP did turn off it interface in
> this case? Optical i/f's is getting more common so these types of loops
> will increase so I think this needs to be addressed.
> 
cisco and others solved this kind of problem using proprietary 
unidirectional link detection protocols (see cisco informational rfc 
5171 for example). No standard exists as far as I know (BFD rfc does not 
consider the layer 2 case).

I am working on an custom udld protocol implementation at the moment ...

> Any chance Rapid STP will fix my problem?
no

Re: [Bridge] STP bug, loop not detetcted

[Joakim Tjernlund]

On Thu, 2008-05-08 at 11:04 +0200, Francesco Dolcini wrote:
> Joakim Tjernlund wrote:
> > On Thu, 2008-05-08 at 02:16 +0000, richardvoigt@gmail.com wrote:
> >> If a bridge receives one of its own STP packets on the same interface
> >> from which it was sent, that indicates a loop elsewhere in the network
> >> that disabling an interface locally will not fix, therefore STP takes
> >> no action.
> > 
> > I see, would it hurt something else if STP did turn off it interface in
> > this case? Optical i/f's is getting more common so these types of loops
> > will increase so I think this needs to be addressed.
> > 
> cisco and others solved this kind of problem using proprietary 
> unidirectional link detection protocols (see cisco informational rfc 
> 5171 for example). No standard exists as far as I know (BFD rfc does not 
> consider the layer 2 case).

Are these proprietary unidirectional link detection protocols the only
way to solve the problem?

Would STP break if the interface was set to "non forwarding" in this
case until the bridge stops seeing its own STP messages?
Seems like the right thing to do.

 Jocke

> 
> I am working on an custom udld protocol implementation at the moment ...
> 
> > Any chance Rapid STP will fix my problem?
> no
> 

Re: [Bridge] STP bug, loop not detetcted

[Francesco Dolcini]

Joakim Tjernlund wrote:
> On Thu, 2008-05-08 at 11:04 +0200, Francesco Dolcini wrote:
>> cisco and others solved this kind of problem using proprietary 
>> unidirectional link detection protocols (see cisco informational rfc 
>> 5171 for example). No standard exists as far as I know (BFD rfc does not 
>> consider the layer 2 case).
> 
> Are these proprietary unidirectional link detection protocols the only
> way to solve the problem?
spanning tree protocol, in the various IEEE incarnation (802.1D, 802.1Q) 
and cisco (PVSTP) does not handle this problem, so an external mechanism 
is needed.

> Would STP break if the interface was set to "non forwarding" in this
> case until the bridge stops seeing its own STP messages?
At least this will not solve the more general problem of a 
unidirectional link (rx working and tx broken).

Re: [Bridge] STP bug, loop not detetcted

[Joakim Tjernlund]

On Thu, 2008-05-08 at 14:13 +0200, Francesco Dolcini wrote:
> Joakim Tjernlund wrote:
> > On Thu, 2008-05-08 at 11:04 +0200, Francesco Dolcini wrote:
> >> cisco and others solved this kind of problem using proprietary 
> >> unidirectional link detection protocols (see cisco informational rfc 
> >> 5171 for example). No standard exists as far as I know (BFD rfc does not 
> >> consider the layer 2 case).
> > 
> > Are these proprietary unidirectional link detection protocols the only
> > way to solve the problem?
> spanning tree protocol, in the various IEEE incarnation (802.1D, 802.1Q) 
> and cisco (PVSTP) does not handle this problem, so an external mechanism 
> is needed.

Do they explicitly ban it? Otherwise I don't see why not the kernel STP
can be enchanted. You could even view it as an external mechanism.

> 
> > Would STP break if the interface was set to "non forwarding" in this
> > case until the bridge stops seeing its own STP messages?
> At least this will not solve the more general problem of a 
> unidirectional link (rx working and tx broken).

hmm, if TX is broken there won't be a loop anyway?

Anyhow, even if my proposed change doesn't solve all cases it seems like
a useful, very simple, ad don to STP. I am just concerned that it can
break some other aspect of STP. So far it seems OK.

What is the bridge maintainers view on this?

 Jocke

Re: [Bridge] STP bug, loop not detetcted

[Joakim Tjernlund]

On Thu, 2008-05-08 at 14:58 +0200, Joakim Tjernlund wrote:
> On Thu, 2008-05-08 at 14:13 +0200, Francesco Dolcini wrote:
> > Joakim Tjernlund wrote:
> > > On Thu, 2008-05-08 at 11:04 +0200, Francesco Dolcini wrote:
> > >> cisco and others solved this kind of problem using proprietary 
> > >> unidirectional link detection protocols (see cisco informational rfc 
> > >> 5171 for example). No standard exists as far as I know (BFD rfc does not 
> > >> consider the layer 2 case).
> > > 
> > > Are these proprietary unidirectional link detection protocols the only
> > > way to solve the problem?
> > spanning tree protocol, in the various IEEE incarnation (802.1D, 802.1Q) 
> > and cisco (PVSTP) does not handle this problem, so an external mechanism 
> > is needed.
> 
> Do they explicitly ban it? Otherwise I don't see why not the kernel STP
> can be enchanted. You could even view it as an external mechanism.
> 
> > 
> > > Would STP break if the interface was set to "non forwarding" in this
> > > case until the bridge stops seeing its own STP messages?
> > At least this will not solve the more general problem of a 
> > unidirectional link (rx working and tx broken).
> 
> hmm, if TX is broken there won't be a loop anyway?
> 
> Anyhow, even if my proposed change doesn't solve all cases it seems like
> a useful, very simple, ad don to STP. I am just concerned that it can
> break some other aspect of STP. So far it seems OK.
> 
> What is the bridge maintainers view on this?

Stephen, whats is your view about extending the bridge code according to
above? Also, after looking at the bride code I don't see where this
should be added, I must be getting old :(

        Jocke

Re: [Bridge] STP bug, loop not detetcted

[Stephen Hemminger]

On Mon, 12 May 2008 11:37:45 +0200
Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:

> 
> On Thu, 2008-05-08 at 14:58 +0200, Joakim Tjernlund wrote:
> > On Thu, 2008-05-08 at 14:13 +0200, Francesco Dolcini wrote:
> > > Joakim Tjernlund wrote:
> > > > On Thu, 2008-05-08 at 11:04 +0200, Francesco Dolcini wrote:
> > > >> cisco and others solved this kind of problem using proprietary 
> > > >> unidirectional link detection protocols (see cisco informational rfc 
> > > >> 5171 for example). No standard exists as far as I know (BFD rfc does not 
> > > >> consider the layer 2 case).
> > > > 
> > > > Are these proprietary unidirectional link detection protocols the only
> > > > way to solve the problem?
> > > spanning tree protocol, in the various IEEE incarnation (802.1D, 802.1Q) 
> > > and cisco (PVSTP) does not handle this problem, so an external mechanism 
> > > is needed.
> > 
> > Do they explicitly ban it? Otherwise I don't see why not the kernel STP
> > can be enchanted. You could even view it as an external mechanism.
> > 
> > > 
> > > > Would STP break if the interface was set to "non forwarding" in this
> > > > case until the bridge stops seeing its own STP messages?
> > > At least this will not solve the more general problem of a 
> > > unidirectional link (rx working and tx broken).
> > 
> > hmm, if TX is broken there won't be a loop anyway?
> > 
> > Anyhow, even if my proposed change doesn't solve all cases it seems like
> > a useful, very simple, ad don to STP. I am just concerned that it can
> > break some other aspect of STP. So far it seems OK.
> > 
> > What is the bridge maintainers view on this?
> 
> Stephen, whats is your view about extending the bridge code according to
> above? Also, after looking at the bride code I don't see where this
> should be added, I must be getting old :(
> 
>         Jocke

If you want to make STP vlan aware, then fine, a good place to start
is getting a version of new RSTP and making it vlan aware.

Re: [Bridge] STP bug, loop not detetcted

[Joakim Tjernlund]

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: den 12 maj 2008 19:50
> To: joakim.tjernlund@transmode.se
> Cc: bridge@lists.linux-foundation.org; Francesco Dolcini
> Subject: Re: [Bridge] STP bug, loop not detetcted
> 
> On Mon, 12 May 2008 11:37:45 +0200
> Joakim Tjernlund <joakim.tjernlund@transmode.se> wrote:
> 
> >
> > On Thu, 2008-05-08 at 14:58 +0200, Joakim Tjernlund wrote:
> > > On Thu, 2008-05-08 at 14:13 +0200, Francesco Dolcini wrote:
> > > > Joakim Tjernlund wrote:
> > > > > On Thu, 2008-05-08 at 11:04 +0200, Francesco Dolcini wrote:
> > > > >> cisco and others solved this kind of problem using proprietary
> > > > >> unidirectional link detection protocols (see cisco informational rfc
> > > > >> 5171 for example). No standard exists as far as I know (BFD rfc does not
> > > > >> consider the layer 2 case).
> > > > >
> > > > > Are these proprietary unidirectional link detection protocols the only
> > > > > way to solve the problem?
> > > > spanning tree protocol, in the various IEEE incarnation (802.1D, 802.1Q)
> > > > and cisco (PVSTP) does not handle this problem, so an external mechanism
> > > > is needed.
> > >
> > > Do they explicitly ban it? Otherwise I don't see why not the kernel STP
> > > can be enchanted. You could even view it as an external mechanism.
> > >
> > > >
> > > > > Would STP break if the interface was set to "non forwarding" in this
> > > > > case until the bridge stops seeing its own STP messages?
> > > > At least this will not solve the more general problem of a
> > > > unidirectional link (rx working and tx broken).
> > >
> > > hmm, if TX is broken there won't be a loop anyway?
> > >
> > > Anyhow, even if my proposed change doesn't solve all cases it seems like
> > > a useful, very simple, ad don to STP. I am just concerned that it can
> > > break some other aspect of STP. So far it seems OK.
> > >
> > > What is the bridge maintainers view on this?
> >
> > Stephen, whats is your view about extending the bridge code according to
> > above? Also, after looking at the bride code I don't see where this
> > should be added, I must be getting old :(
> >
> >         Jocke
> 
> If you want to make STP vlan aware, then fine, a good place to start
> is getting a version of new RSTP and making it vlan aware.

No, that is not what I meant, forget about VLAN just consider what
happens if you loop 2 or more interfaces which is connected to the
same bridge. The loop is such that each TX is connected to its own
RX.

      Jocke

Re: [Bridge] STP bug, loop not detetcted

[richardvoigt]

On Thu, May 8, 2008 at 8:01 AM, Joakim Tjernlund
<joakim.tjernlund@transmode.se> wrote:
>
>  On Thu, 2008-05-08 at 02:16 +0000, richardvoigt@gmail.com wrote:
>  > On Wed, May 7, 2008 at 9:22 AM, Joakim Tjernlund
>  > <joakim.tjernlund@transmode.se> wrote:
>  > > Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
>  > >  eth1.4, attached and the builtin STP enabled. eth1 is connected to
>  > >  a "switch" with 4 real interfaces, each real interface maps to one of
>  > >  the above mentioned VLANs.
>  > >
>  > >  If I loop two or more interfaces by connecting each interface's output
>  > >  to its own input, I get a loop that STP doesn't detect.
>  > >  Looping by connecting an output from one interface to another interface
>  > >  input works fine.
>  > >
>  > >  Bug or limitation in STP? If limitation, would RSTP help here?
>  >
>  > Limitation in STP.
>  >
>  > If a bridge receives one of its own STP packets on the same interface
>  > from which it was sent, that indicates a loop elsewhere in the network
>  > that disabling an interface locally will not fix, therefore STP takes
>  > no action.
>
>  I see, would it hurt something else if STP did turn off it interface in
>  this case? Optical i/f's is getting more common so these types of loops
>  will increase so I think this needs to be addressed.

Yes, it would hurt.

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.  There is no way for STP to distinguish your
case, which is misconfigured, from this example, which is a valid use
of redundant links.

Re: [Bridge] STP bug, loop not detetcted

[Joakim Tjernlund]

On Tue, 2008-05-13 at 03:10 +0000, richardvoigt@gmail.com wrote:
> On Thu, May 8, 2008 at 8:01 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> >  On Thu, 2008-05-08 at 02:16 +0000, richardvoigt@gmail.com wrote:
> >  > On Wed, May 7, 2008 at 9:22 AM, Joakim Tjernlund
> >  > <joakim.tjernlund@transmode.se> wrote:
> >  > > Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
> >  > >  eth1.4, attached and the builtin STP enabled. eth1 is connected to
> >  > >  a "switch" with 4 real interfaces, each real interface maps to one of
> >  > >  the above mentioned VLANs.
> >  > >
> >  > >  If I loop two or more interfaces by connecting each interface's output
> >  > >  to its own input, I get a loop that STP doesn't detect.
> >  > >  Looping by connecting an output from one interface to another interface
> >  > >  input works fine.
> >  > >
> >  > >  Bug or limitation in STP? If limitation, would RSTP help here?
> >  >
> >  > Limitation in STP.
> >  >
> >  > If a bridge receives one of its own STP packets on the same interface
> >  > from which it was sent, that indicates a loop elsewhere in the network
> >  > that disabling an interface locally will not fix, therefore STP takes
> >  > no action.
> >
> >  I see, would it hurt something else if STP did turn off it interface in
> >  this case? Optical i/f's is getting more common so these types of loops
> >  will increase so I think this needs to be addressed.
> 
> Yes, it would hurt.
> 
> 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.  There is no way for STP to distinguish your
> case, which is misconfigured, from this example, which is a valid use
> of redundant links.

Once STP has dealt with the loop in br1-br2-br3-br1 and disabled one
of the br1 interfaces, br0 won't see its own pkgs and start
forwarding again, right?

My use case is a common one in optical transmisson equipment. This
is what you do to test connectivity, troubleshoot etc. and it would
be nice if STP could deal with it.

 Jocke

Re: [Bridge] STP bug, loop not detetcted

[Benny Amorsen]

"richardvoigt@gmail.com" <richardvoigt@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

Re: [Bridge] STP bug, loop not detetcted

[Dylan Hall]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

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@gmail.com" <richardvoigt@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@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge

[-- Attachment #2: Type: text/html, Size: 2852 bytes --]

Re: [Bridge] STP bug, loop not detetcted

[richardvoigt]

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

Re: [Bridge] STP bug, loop not detetcted

[Dylan Hall]

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

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@gmail.com wrote:

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

[-- Attachment #2: Type: text/html, Size: 5382 bytes --]

Re: [Bridge] STP bug, loop not detetcted

[Brad Dameron]

[-- Attachment #1: Type: text/plain, Size: 3353 bytes --]

We run very large layer 2 networks and have had a broadcast storm loop take out our network in seconds. Mainly due to someone stopping the firewall rules on the box. IPTables is the best cure for this. We stop broadcasts out one interface. 
 
Brad

________________________________

From: bridge-bounces@lists.linux-foundation.org on behalf of Dylan Hall
Sent: Tue 5/13/2008 4:56 PM
To: bridge@osdl.org
Subject: Re: [Bridge] STP bug, loop not detetcted


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@gmail.com wrote: 

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


[-- Attachment #2: Type: text/html, Size: 6012 bytes --]

Re: [Bridge] STP bug, loop not detetcted

[Francesco Dolcini]

Dylan Hall wrote:
> 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.
> 
you can also add cisco loop guard to the list, but this is an 
improvement to standard STP, not a different protocol

> Rather than modifying STP would it not be better to implement something
> like the above as a standalone daemon? 
I agree, but it is also true that if we can improve STP without breaking 
compatibility there is no reason to not do it.

Re: [Bridge] STP bug, loop not detetcted

[Stephen Hemminger]

On Tue, 13 May 2008 03:10:09 +0000
"richardvoigt@gmail.com" <richardvoigt@gmail.com> wrote:

> On Thu, May 8, 2008 at 8:01 AM, Joakim Tjernlund
> <joakim.tjernlund@transmode.se> wrote:
> >
> >  On Thu, 2008-05-08 at 02:16 +0000, richardvoigt@gmail.com wrote:
> >  > On Wed, May 7, 2008 at 9:22 AM, Joakim Tjernlund
> >  > <joakim.tjernlund@transmode.se> wrote:
> >  > > Got a bridge with 4 optical VLAN interfaces, eth1.1, eth1.2, eth1.3 and
> >  > >  eth1.4, attached and the builtin STP enabled. eth1 is connected to
> >  > >  a "switch" with 4 real interfaces, each real interface maps to one of
> >  > >  the above mentioned VLANs.
> >  > >
> >  > >  If I loop two or more interfaces by connecting each interface's output
> >  > >  to its own input, I get a loop that STP doesn't detect.
> >  > >  Looping by connecting an output from one interface to another interface
> >  > >  input works fine.
> >  > >
> >  > >  Bug or limitation in STP? If limitation, would RSTP help here?
> >  >
> >  > Limitation in STP.
> >  >
> >  > If a bridge receives one of its own STP packets on the same interface
> >  > from which it was sent, that indicates a loop elsewhere in the network
> >  > that disabling an interface locally will not fix, therefore STP takes
> >  > no action.
> >
> >  I see, would it hurt something else if STP did turn off it interface in
> >  this case? Optical i/f's is getting more common so these types of loops
> >  will increase so I think this needs to be addressed.
> 
> Yes, it would hurt.
> 
> 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.  There is no way for STP to distinguish your
> case, which is misconfigured, from this example, which is a valid use
> of redundant links.

Spanning Tree absolutely has to follow the standard. What ever the standard
says, that is what it should do. No special cases, no changes. Get the standard
for free from IEEE (get 802) and read it.

That said, we really need to get the STP updated to RSTP. There are currently
four options:

1) Existing userlevel RSTP daemon based on rstplib.  
2) New RSTP code (from EMC) as daemon
3) Update of old STP kernel code to RSTP, this was done on ancient 2.4
   for embedded system
4) Port EMC RSTP code to kernel

There doesn't appear to be lots of advantages to user space RSTP long term
and the conversion process would be more painful.

EMC code is slightly uglier (sorry) but has advantage of being recently
interop tested.

I don't have an easy answer, otherwise I would have just chosen one and gone
with it.

[Bridge] RSTP implementation choice

[Benoit PAPILLAULT]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Stephen Hemminger a écrit :

| That said, we really need to get the STP updated to RSTP. There are
currently
| four options:

I agree since RSTP is now part of 802.1D-2004 and is backward compatible
with STP (with some limitations of course).

|
| 1) Existing userlevel RSTP daemon based on rstplib.
| 2) New RSTP code (from EMC) as daemon
| 3) Update of old STP kernel code to RSTP, this was done on ancient 2.4
|    for embedded system
| 4) Port EMC RSTP code to kernel
|
| There doesn't appear to be lots of advantages to user space RSTP long term
| and the conversion process would be more painful.
|
| EMC code is slightly uglier (sorry) but has advantage of being recently
| interop tested.
|
| I don't have an easy answer, otherwise I would have just chosen one
and gone
| with it.

I like the userspace implementation (I intend to dig into it a bit
more). RSTP does not handle lots of traffic so it's fine to have it in
user mode. It would avoid to have the kernel bloated a bit more.

Moreover, I'm trying to design a new bridge protocol and it would help
to implement it in userspace with a clean rtnetlink API.

After all, routing protocols are not implemented into the kernel. Only
routing tables are.

My 2 cents,
Benoit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKerSOR6EySwP7oIRAhjPAKCT0z70+0GMtScLoMWECSlDQgzpAwCgpY/a
xvYeDb9xFHulOz8SuecEE5M=
=9D00
-----END PGP SIGNATURE-----

Re: [Bridge] STP bug, loop not detetcted

[Francesco Dolcini]

Stephen Hemminger wrote:
> Spanning Tree absolutely has to follow the standard. What ever the standard
> says, that is what it should do. No special cases, no changes. Get the standard
> for free from IEEE (get 802) and read it.
I do not agree, I absolutely think that linux STP must be 100% 
compatible with IEEE standard, but if we can improve it, adding 
additional functions without breaking 100% compatibility, why not do it?

> That said, we really need to get the STP updated to RSTP. There are currently
> four options:
> 
> 1) Existing userlevel RSTP daemon based on rstplib.  
> 2) New RSTP code (from EMC) as daemon
> 3) Update of old STP kernel code to RSTP, this was done on ancient 2.4
>    for embedded system
> 4) Port EMC RSTP code to kernel
>

> There doesn't appear to be lots of advantages to user space RSTP long term
> and the conversion process would be more painful.
I think that having user space STP can make easier to have different 
implementation of STP algorithms available:
- plain old 802.1D legacy slow STP
- 802.1D-2004 RSTP
- 802.1Q-2005 MSTP
- Cisco proprietary PVSTP
- Cisco proprietary PVRSTP

Or we just need "one protocol to rule them all"?

What I think that is really missing at the moment, apart from RSTP, is a 
vlan aware forwarding engine in the bridge code.

> EMC code is slightly uglier (sorry) but has advantage of being recently
> interop tested.
The original rstplib is outdated, it implement the old 802.1w standard. 
We have a working implementation updated to the latest standard (802.1D 
2004) of rstplib, if it can be usefull we can think about releasing it.

Francesco