From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Cc: Ben Hutchings <bhutchings@solarflare.com>,
Jiri Bohac <jbohac@suse.cz>,
netdev@vger.kernel.org, Jay Vosburgh <fubar@us.ibm.com>,
Andy Gospodarek <andy@greyhouse.net>
Subject: Re: [PATCH] bonding: fix bridged bonds in 802.3ad mode
Date: Thu, 21 Apr 2011 14:08:17 -0700 [thread overview]
Message-ID: <20110421140817.1782b2a9@nehalam> (raw)
In-Reply-To: <4DB096E0.4010407@polymtl.ca>
On Thu, 21 Apr 2011 16:43:12 -0400
Benjamin Poirier <benjamin.poirier@polymtl.ca> wrote:
> On 21/04/11 03:08 PM, Ben Hutchings wrote:
> > On Thu, 2011-04-21 at 20:47 +0200, Jiri Bohac wrote:
> >> 802.3ad bonding inside a bridge is broken again. Originally fixed by
> >> 43aa1920117801fe9ae3d1fad886b62511e09bee, the bug was re-introduced by
> >> 1e253c3b8a1aeed51eef6fc366812f219b97de65.
> >>
> >> LACP frames must not have their skb->dev changed by the bridging hook.
> >>
> >> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
> >>
> >> --- a/drivers/net/bonding/bond_main.c
> >> +++ b/drivers/net/bonding/bond_main.c
> >> @@ -1514,6 +1514,11 @@ static rx_handler_result_t bond_handle_frame(struct sk_buff **pskb)
> >> memcpy(eth_hdr(skb)->h_dest, bond->dev->dev_addr, ETH_ALEN);
> >> }
> >>
> >> + /* prevent bridging code from mangling and forwarding LACP frames */
> >> + if (bond->params.mode == BOND_MODE_8023AD &&
> >> + skb->protocol == htons(ETH_P_SLOW))
> >> + return RX_HANDLER_PASS;
> >> +
> >> return RX_HANDLER_ANOTHER;
> >> }
> >>
> >
> > It seems to me that 1e253c3b8a1aeed51eef6fc366812f219b97de65 is bogus
>
> You bet, it's rubbish ;)
>
> Any thoughts on how we could support a transparent bridging
> configuration without repurposing br->stp_enabled or adding another
> option to bridge-utils?
>
> btw, the particular scenario I was trying to address is a virtual
> machine bridged to an ethernet interface connected to a switch port with
> 802.1x enabled.
>
> -Benjamin
>
> > and should be reverted, rather than worked around by other drivers. We
> > shouldn't enable non-conformant forwarding behaviour by default just
> > because some people find it useful. The administrator should have to
> > explicitly enable it.
> >
> > Ben.
> >
>
The IEEE standard says bridge's shouldn't forward link-local addresses.
The problem is that people expect it to.
--
next prev parent reply other threads:[~2011-04-21 21:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-21 18:47 [PATCH] bonding: fix bridged bonds in 802.3ad mode Jiri Bohac
2011-04-21 19:08 ` Ben Hutchings
2011-04-21 19:27 ` Jiri Bohac
2011-04-21 20:43 ` Benjamin Poirier
2011-04-21 21:08 ` Stephen Hemminger [this message]
2011-04-22 4:19 ` David Miller
2011-04-22 15:27 ` Stephen Hemminger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110421140817.1782b2a9@nehalam \
--to=shemminger@linux-foundation.org \
--cc=andy@greyhouse.net \
--cc=benjamin.poirier@polymtl.ca \
--cc=bhutchings@solarflare.com \
--cc=fubar@us.ibm.com \
--cc=jbohac@suse.cz \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.