Linux Ethernet Bridging - Oct 2018 - [Bridge] [PATCH 1/1] bridge: remove BR_GROUPFWD_RESTRICTED for arbitrary forwarding of reserved addresses

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

On 01/10/2018 22:10, Richard Weinberger wrote:
> 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 
> 
> 
> 
> 
Richard please check commit:
commit 5af48b59f35c
Author: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
Date:   Wed Sep 27 16:12:44 2017 +0300

    net: bridge: add per-port group_fwd_mask with less restrictions
    
    We need to be able to transparently forward most link-local frames via
    tunnels (e.g. vxlan, qinq). Currently the bridge's group_fwd_mask has a
    mask which restricts the forwarding of STP and LACP, but we need to be able
    to forward these over tunnels and control that forwarding on a per-port
    basis thus add a new per-port group_fwd_mask option which only disallows
    mac pause frames to be forwarded (they're always dropped anyway).
    The patch does not change the current default situation - all of the others
    are still restricted unless configured for forwarding.
    We have successfully tested this patch with LACP and STP forwarding over
    VxLAN and qinq tunnels.
    
    Signed-off-by: Nikolay Aleksandrov <nikolay at cumulusnetworks.com>
    Signed-off-by: David S. Miller <davem at davemloft.net>


Will this work for you ?
It's in the bridge since v4.15.

Thanks,
 Nik