[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFLxGvzVbWvQ5YA8NS-zcESguNNvJAbE_99SdFcAjbftCXzsdQ@mail.gmail.com>
Date: Mon, 1 Oct 2018 16:28:44 +0200
From: Richard Weinberger <richard.weinberger@...il.com>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: bernhard.thaler@...et.at, "David S. Miller" <davem@...emloft.net>,
bridge@...ts.linux-foundation.org, netdev@...r.kernel.org,
David Gstir <david@...ma-star.at>
Subject: Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary
forwarding of reserved addresses
Stephen, Bernhard,
On Tue, Jan 6, 2015 at 7:18 AM Stephen Hemminger
<stephen@...workplumber.org> wrote:
>
> On Tue, 6 Jan 2015 01:56:15 +0100
> Bernhard Thaler <bernhard.thaler@...et.at> wrote:
>
> > BR_GROUPFWD_RESTRICTED bitmask restricts users from setting values to
> > /sys/class/net/brX/bridge/group_fwd_mask that allow forwarding of
> > some IEEE 802.1D Table 7-10 Reserved addresses:
> > (MAC Control) 802.3 01-80-C2-00-00-01
> > (Link Aggregation) 802.3 01-80-C2-00-00-02
> > 802.1AB LLDP 01-80-C2-00-00-0E
> > BR_GROUPFWD_RESTRICTED may have been set as an extra protection against
> > forwarding these control frames as forwarding 802.1X PAE (01-80-C2-00-00-03)
> > in 802.1X setups satisfies most common use-cases.
> > Other situations, such as placing a software based bridge as a "TAP" between two
> > devices may require to forward e.g. LLDP frames while debugging network problems
> > or actively changing/filtering traffic with ebtables.
> >
> > This patch allows to set e.g.:
> > echo 65535 > /sys/class/net/brX/bridge/group_fwd_mask
> > which sets no restrictions on the forwardable reserved addresses.
> >
> > - the default value 0 will still comply with 802.1D and not forward any
> > reserved addresses
> > - values such as 8 for forwarding 802.1X related frames will behave the
> > same way as with BR_GROUPFWD_RESTRICTED currently in place, so backward
> > compatibility to current scripts using group_fwd_masks shoudl be possible
> >
> > Administrators and network engineers however will be able to arbitrarily
> > forward any reserved addresses without BR_GROUPFWD_RESTRICTED. This will
> > be non-standard compliant behavior, but forwarding of any reserved address
> > right from the beginning is. Users should be aware of this anyway and
> > know what/why they are doing when setting values such as 65535, 32768, 16384,
> > 4, 2 for group_fwd_mask
> >
> > This patch was tested on a bridge with two interfaces created with bridge-utils.
> >
> > Signed-off-by: Bernhard Thaler <bernhard.thaler@...et.at>
>
> I am ok with forwarding LLDP because some people need it.
> But allowing forwarding STP or PAUSE frames is bad.
>
> We don't let people do things that break networks. Other examples
> already exist like set all 0 ethernet addresses, or the restrictions
> on allowing net 127 in IP addresses.
Sorry for unearthing this old thread, while preparing our in-house
patch I found it.
This patch does exactly what we need and already do in our network. We
have Linux bridges that
forward anything. With one restriction, the bridge has always just two slaves.
In other works, it acts like a cable. Therefore I see no problem in
forwarding STP or PAUSE frames.
Since Linux allows these days also to use 127/8 IP addresses, would
you accept a patch which allows
forwarding STP and PAUSE if the number of slaves is restricted to 2? :-)
--
Thanks,
//richard
Powered by blists - more mailing lists