[Bridge] STP Loop not blocking

[Bridge] STP Loop not blocking

[Jake Farrell]

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

Recently ran into a problem with the 2.6.18 kernel on Xscale arch when a bridge, with multiple interfaces on it, is configured with a redundant loop. All interfaces are left on forwarding and nexer switch to block when the loop is introduced. This was tested against a 2.6.16 kernel and the problem did not occur, interfaces forwared and blocked correctly. Any help would be appreciated.

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

Re: [Bridge] STP Loop not blocking

[Cameron Schaus]

Jake Farrell wrote:
>
> Recently ran into a problem with the 2.6.18 kernel on Xscale arch when 
> a bridge, with multiple interfaces on it, is configured with a 
> redundant loop. All interfaces are left on forwarding and nexer switch 
> to block when the loop is introduced. This was tested against a 2.6.16 
> kernel and the problem did not occur, interfaces forwared and blocked 
> correctly. Any help would be appreciated.
>
Since you haven't give much detail on your setup (is stp enabled on both 
bridges, for example), I'm not 100% clear what may be happening.  But it 
does sound like something I ran into before.

See my post, and Stephen's reply:
http://lists.osdl.org/pipermail/bridge/2006-December/001573.html

Cam

Re: [Bridge] STP Loop not blocking

[Jake Farrell]

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

The setup is as follows

ixp4xx #1:  br0 (eth0, eth1, ath0, ath1) STP enabled
                  |                 |
                  |                 |
                  |                 |
ixp4xx #2:  br0 (eth0, eth1, ath0, ath1) STP enabled

with 2.6.16 one of the interfaces goes to blocking and the other is left to forward. In 2.6.18 the interfaces always stay forwarding.

Jake


>
> Recently ran into a problem with the 2.6.18 kernel on Xscale arch when 
> a bridge, with multiple interfaces on it, is configured with a 
> redundant loop. All interfaces are left on forwarding and nexer switch 
> to block when the loop is introduced. This was tested against a 2.6.16 
> kernel and the problem did not occur, interfaces forwared and blocked 
> correctly. Any help would be appreciated.
>
Since you haven't give much detail on your setup (is stp enabled on both 
bridges, for example), I'm not 100% clear what may be happening.  But it 
does sound like something I ran into before.

See my post, and Stephen's reply:
http://lists.osdl.org/pipermail/bridge/2006-December/001573.html

Cam



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

Re: [Bridge] STP Loop not blocking

[Stephen Hemminger]

On Wed, 24 Jan 2007 10:46:48 -0800
"Jake Farrell" <jake@amperion.com> wrote:

> The setup is as follows
> 
> ixp4xx #1:  br0 (eth0, eth1, ath0, ath1) STP enabled
>                   |                 |
>                   |                 |
>                   |                 |
> ixp4xx #2:  br0 (eth0, eth1, ath0, ath1) STP enabled
> 
> with 2.6.16 one of the interfaces goes to blocking and the other is left to forward. In 2.6.18 the interfaces always stay forwarding.
> 
> Jake
> 
> 
> >
> > Recently ran into a problem with the 2.6.18 kernel on Xscale arch when 
> > a bridge, with multiple interfaces on it, is configured with a 
> > redundant loop. All interfaces are left on forwarding and nexer switch 
> > to block when the loop is introduced. This was tested against a 2.6.16 
> > kernel and the problem did not occur, interfaces forwared and blocked 
> > correctly. Any help would be appreciated.
> >
> Since you haven't give much detail on your setup (is stp enabled on both 
> bridges, for example), I'm not 100% clear what may be happening.  But it 
> does sound like something I ran into before.
> 
> See my post, and Stephen's reply:
> http://lists.osdl.org/pipermail/bridge/2006-December/001573.html
> 
> Cam

There haven't been a huge number of bridge changes, perhaps
STP got broken. Git bisect to a particular changeset would help

-- 
Stephen Hemminger <shemminger@linux-foundation.org>