From: Stephen Hemminger <shemminger@vyatta.com>
To: Ben Hutchings <bhutchings@solarflare.com>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH 2/2] bridge: allow forwarding some link local frames
Date: Wed, 5 Oct 2011 13:50:59 -0700 [thread overview]
Message-ID: <20111005135059.4fbb2912@nehalam.linuxnetplumber.net> (raw)
In-Reply-To: <1317843619.2802.32.camel@bwh-desktop>
On Wed, 05 Oct 2011 20:40:19 +0100
Ben Hutchings <bhutchings@solarflare.com> wrote:
> On Mon, 2011-10-03 at 21:14 -0700, Stephen Hemminger wrote:
> > plain text document attachment (bridge-multicast-filter.patch)
> > This is based on an earlier patch by Nick Carter with comments
> > by David Lamparter but with some refinements. Thanks for their patience
> > this is a confusing area with overlap of standards, user requirements,
> > and compatibility with earlier releases.
> >
> > It adds a new sysfs attribute
> > /sys/class/net/brX/bridge/group_fwd_mask
> > that controls forwarding of frames with address of: 01-80-C2-00-00-0X
> > The default setting has no forwarding to retain compatibility.
> >
> > One change from earlier releases is that forwarding of group
> > addresses is not dependent on STP being enabled or disabled. This
> > choice was made based on interpretation of tie 802.1 standards.
> > I expect complaints will arise because of this, but better to follow
> > the standard than continue acting incorrectly by default.
> >
> > The filtering mask is writeable, but only values that don't forward
> > known control frames are allowed. It intentionally blocks attempts
> > to filter control protocols. For example: writing a 8 allows
> > forwarding 802.1X PAE addresses which is the most common request.
> [...]
>
> I wonder why you don't forbid forwarding frames sent to reserved
> destination addresses? The standards seem pretty clear that this should
> not be allowed.
Future proofing. Since addresses are unassigned there is no certainty of the
assigned semantics when they are used.
next prev parent reply other threads:[~2011-10-05 20:51 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20111004041444.793960297@vyatta.com>
2011-10-04 4:14 ` [PATCH 1/2] bridge: leave carrier on for empty bridge Stephen Hemminger
2011-10-06 19:28 ` David Miller
2011-10-04 4:14 ` [PATCH 2/2] bridge: allow forwarding some link local frames Stephen Hemminger
2011-10-04 19:11 ` Benjamin Poirier
2011-10-05 19:40 ` Ben Hutchings
2011-10-05 20:50 ` Stephen Hemminger [this message]
2011-10-06 19:28 ` David Miller
2011-10-17 14:35 ` Ed Swierk
2011-10-17 15:18 ` Stephen Hemminger
2011-10-17 20:53 ` Ross Brattain
2011-10-17 21:09 ` Ed Swierk
2011-10-17 23:07 ` Ross Brattain
2011-10-17 23:36 ` Ed Swierk
2011-10-18 0:00 ` John Fastabend
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=20111005135059.4fbb2912@nehalam.linuxnetplumber.net \
--to=shemminger@vyatta.com \
--cc=bhutchings@solarflare.com \
--cc=davem@davemloft.net \
--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.