All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Ido Schimmel <idosch@idosch.org>
Cc: David Gstir <david@sigma-star.at>,
	Florian Fainelli <f.fainelli@gmail.com>,
	nikolay@cumulusnetworks.com, netdev@vger.kernel.org,
	roopa@cumulusnetworks.com, bridge@lists.linux-foundation.org,
	bernhard.thaler@wvnet.at, "David S. Miller" <davem@davemloft.net>
Subject: Re: [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
Date: Mon, 01 Oct 2018 21:10:49 +0200	[thread overview]
Message-ID: <16029249.TkoLblyBmC@blindfold> (raw)
In-Reply-To: <20181001190433.GA29874@splinter>

Am Montag, 1. Oktober 2018, 21:04:33 CEST schrieb Ido Schimmel:
> On Mon, Oct 01, 2018 at 08:54:08PM +0200, Richard Weinberger wrote:
> > So the only option is having a bridge and transport STP via tc-mirred
> > or patching the bridge code (what we do right now).
> 
> And I vote for the first option. I understand it involves more typing,

hehe, it is not about typing. The setup is done by a script.
And we both know that getting a patch upstream is much more work than
typing a few lines of hacky bash scripts.
Since I want a decent solution and feedback I'm bringing this up here.

I could also just go with my in-house patch and don't tell anyone...

> but I see no reason to push more complexity into the kernel - and break
> standards - when you can relatively easily accomplish the same thing in
> other ways.

If having a bridge plus u32+mirred for STP bypass is the preferred solution,
I'm fine with it.
So far we use the kernel patch and didn't test the mirred-bypass a lot.
My fear was that mirred rules from eth0 to eth1 and back might cause a
loop or confuse the bridge...

> Adding Nik and Roopa who now maintain the bridge code and should
> eventually decide about this.

Thanks,
//richard 





WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Ido Schimmel <idosch@idosch.org>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	bernhard.thaler@wvnet.at, "David S. Miller" <davem@davemloft.net>,
	bridge@lists.linux-foundation.org, netdev@vger.kernel.org,
	David Gstir <david@sigma-star.at>,
	nikolay@cumulusnetworks.com, roopa@cumulusnetworks.com
Subject: Re: [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses
Date: Mon, 01 Oct 2018 21:10:49 +0200	[thread overview]
Message-ID: <16029249.TkoLblyBmC@blindfold> (raw)
In-Reply-To: <20181001190433.GA29874@splinter>

Am Montag, 1. Oktober 2018, 21:04:33 CEST schrieb Ido Schimmel:
> On Mon, Oct 01, 2018 at 08:54:08PM +0200, Richard Weinberger wrote:
> > So the only option is having a bridge and transport STP via tc-mirred
> > or patching the bridge code (what we do right now).
> 
> And I vote for the first option. I understand it involves more typing,

hehe, it is not about typing. The setup is done by a script.
And we both know that getting a patch upstream is much more work than
typing a few lines of hacky bash scripts.
Since I want a decent solution and feedback I'm bringing this up here.

I could also just go with my in-house patch and don't tell anyone...

> but I see no reason to push more complexity into the kernel - and break
> standards - when you can relatively easily accomplish the same thing in
> other ways.

If having a bridge plus u32+mirred for STP bypass is the preferred solution,
I'm fine with it.
So far we use the kernel patch and didn't test the mirred-bypass a lot.
My fear was that mirred rules from eth0 to eth1 and back might cause a
loop or confuse the bridge...

> Adding Nik and Roopa who now maintain the bridge code and should
> eventually decide about this.

Thanks,
//richard 

  reply	other threads:[~2018-10-01 19:10 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-06  0:56 [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses Bernhard Thaler
2015-01-06  0:56 ` Bernhard Thaler
2015-01-06  6:10 ` [Bridge] " Stephen Hemminger
2015-01-06  6:10   ` Stephen Hemminger
2018-10-01 14:28   ` Richard Weinberger
2018-10-01 16:24     ` Florian Fainelli
2018-10-01 18:16       ` [Bridge] " Richard Weinberger
2018-10-01 18:16         ` Richard Weinberger
2018-10-01 18:25         ` [Bridge] " Ido Schimmel
2018-10-01 18:25           ` Ido Schimmel
2018-10-01 18:32           ` [Bridge] " Richard Weinberger
2018-10-01 18:32             ` Richard Weinberger
2018-10-01 18:48             ` [Bridge] " Ido Schimmel
2018-10-01 18:48               ` Ido Schimmel
2018-10-01 18:54               ` [Bridge] " Richard Weinberger
2018-10-01 18:54                 ` Richard Weinberger
2018-10-01 19:04                 ` [Bridge] " Ido Schimmel
2018-10-01 19:04                   ` Ido Schimmel
2018-10-01 19:10                   ` Richard Weinberger [this message]
2018-10-01 19:10                     ` Richard Weinberger
2018-10-02 14:59                     ` [Bridge] " Nikolay Aleksandrov
2018-10-02 14:59                       ` Nikolay Aleksandrov
2018-10-02 15:56                       ` [Bridge] " Richard Weinberger
2018-10-02 15:56                         ` Richard Weinberger
2018-10-02 16:10                         ` [Bridge] " Nikolay Aleksandrov
2018-10-02 16:10                           ` Nikolay Aleksandrov
2018-10-02 19:30                           ` [Bridge] " Richard Weinberger
2018-10-02 19:30                             ` Richard Weinberger

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=16029249.TkoLblyBmC@blindfold \
    --to=richard@nod.at \
    --cc=bernhard.thaler@wvnet.at \
    --cc=bridge@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=david@sigma-star.at \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@idosch.org \
    --cc=netdev@vger.kernel.org \
    --cc=nikolay@cumulusnetworks.com \
    --cc=roopa@cumulusnetworks.com \
    /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.