From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73FE1.74B620A7" Date: Wed, 24 Jan 2007 09:59:56 -0800 Message-ID: <8764B2C538F2C44B845C4B608D4515D31A48C2@EXVBE012-5.exch012.intermedia.net> From: "Jake Farrell" Subject: [Bridge] STP Loop not blocking List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: bridge@lists.osdl.org This is a multi-part message in MIME format... ------_=_NextPart_001_01C73FE1.74B620A7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Recently ran into a problem with the 2.6.18 kernel on Xscale arch when a br= idge, with multiple interfaces on it, is configured with a redundant loop. = All interfaces are left on forwarding and nexer switch to block when the lo= op is introduced. This was tested against a 2.6.16 kernel and the problem d= id not occur, interfaces forwared and blocked correctly. Any help would be = appreciated. ------_=_NextPart_001_01C73FE1.74B620A7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline STP Loop not blocking

Recently ran into a problem with the 2.6.18 kernel on Xsc= ale 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.

------_=_NextPart_001_01C73FE1.74B620A7-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <45B7A3ED.4080607@schaus.ca> Date: Wed, 24 Jan 2007 13:22:37 -0500 From: Cameron Schaus MIME-Version: 1.0 References: <8764B2C538F2C44B845C4B608D4515D31A48C2@EXVBE012-5.exch012.intermedia.net> In-Reply-To: <8764B2C538F2C44B845C4B608D4515D31A48C2@EXVBE012-5.exch012.intermedia.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] STP Loop not blocking List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jake Farrell , bridge@lists.osdl.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73FE8.3B70F380" Date: Wed, 24 Jan 2007 10:46:48 -0800 Message-ID: <8764B2C538F2C44B845C4B608D4515D31A48C6@EXVBE012-5.exch012.intermedia.net> References: <8764B2C538F2C44B845C4B608D4515D31A48C2@EXVBE012-5.exch012.intermedia.net> <45B7A3ED.4080607@schaus.ca> From: "Jake Farrell" Subject: Re: [Bridge] STP Loop not blocking List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cameron Schaus , bridge@lists.osdl.org This is a multi-part message in MIME format... ------_=_NextPart_001_01C73FE8.3B70F380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 > a bridge, with multiple interfaces on it, is configured with a=20 > redundant loop. All interfaces are left on forwarding and nexer switch=20 > to block when the loop is introduced. This was tested against a 2.6.16=20 > kernel and the problem did not occur, interfaces forwared and blocked=20 > correctly. Any help would be appreciated. > Since you haven't give much detail on your setup (is stp enabled on both=20 bridges, for example), I'm not 100% clear what may be happening. But it=20 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 ------_=_NextPart_001_01C73FE8.3B70F380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline RE: [Bridge] STP Loop not blocking

The setup is as follows

ixp4xx #1:  br0 (eth0, eth1, ath0, ath1) STP enabled
            &nb= sp;     |       &nbs= p;         |
            &nb= sp;     |       &nbs= p;         |
            &nb= sp;     |       &nbs= p;         |
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<= BR> > 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

------_=_NextPart_001_01C73FE8.3B70F380-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 24 Jan 2007 11:19:12 -0800 From: Stephen Hemminger Message-ID: <20070124111912.7c72de7f@freekitty> In-Reply-To: <8764B2C538F2C44B845C4B608D4515D31A48C6@EXVBE012-5.exch012.intermedia.net> References: <8764B2C538F2C44B845C4B608D4515D31A48C2@EXVBE012-5.exch012.intermedia.net> <45B7A3ED.4080607@schaus.ca> <8764B2C538F2C44B845C4B608D4515D31A48C6@EXVBE012-5.exch012.intermedia.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Bridge] STP Loop not blocking List-Id: Linux Ethernet Bridging List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jake Farrell Cc: bridge@lists.osdl.org On Wed, 24 Jan 2007 10:46:48 -0800 "Jake Farrell" 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