[pve-devel] Port BR_GROUPFWD_RESTRICTED patch for Layer 1-esque Linux Bridge forwarding

[Klaus Darilion]

Am 24.08.2018 um 11:10 schrieb Thomas Lamprecht:
> Hi,
>
> On 8/24/18 9:00 AM, Jesus Llorente wrote:
>> Hello,
>>
>> I am working on a scenario that uses virtual machines to run a switch
>> appliance. The aim of my test is not performance, but to test different
>> configurations and network models. However, I have stumbled upon something
>> that depends on the kernel which is making Linux bridges consume link local
>> multicast packets (LLDP, LACP, etc) in compliance with 802.3ad
>>
>> In this patch
>> https://lists.linuxfoundation.org/pipermail/bridge/2015-January/009291.html
>> they removed a hard-coded restriction so that the behavior of the bridge
>> can be then controlled from the OS with the variable
>> /sys/class/net/$brname/bridge/group_fwd_mask
>>
>> In this post, the author explains the different values this variable can
>> take, according to what we are trying to allow/restrict.
>> https://interestingtraffic.nl/2017/11/21/an-oddly-specific-post-about-group_fwd_mask
>>
>> I would like to suggest porting this patch to the pve kernel to remove all
>> the restrictions and enable full transparent bridging (point-to-point like
>> links) across devices, in a Layer 1 fashion.
>>
> In general I have nothing against this but share the same objections as the
> response to the proposed patch[0], i.e., LLDP and LACP would be OK but ethernet
> flow control or STP frames not and the patch is an all or nothing approach.

What is the problem with STP? The objection regarding STP is wrong. 
Actually with the Linux bridge, if STP on the bridge is turned off, STP 
is forwarded through the bridge (since I remember). I use 
STP-transparent bridges on a plenty of VPN servers to have total 
transparent L2-tunneling and it is very useful. (eg I have networks with 
Junipers vstp connected by Linux-VPNs. As neither the Linux bridge nor 
OVS support vstp I need to have the tunnel STP transparent to have VSTP 
working over the VPN connection).

Also forwarding PAUSE frames may be a useful feature for debugging 
purposes. Any maybe having PAUSE not hop-by-hop but skipping transparent 
bridges may be useful too.

And I am with Jesus - Linux should not artifically set limitations on 
bridging scenarios just because somebody might be afraid of breaking 
network. I think, people fiddling around with such special features do 
not break networks - and networks can be broken much more easily without 
this patch.

regards
Klaus