[pve-devel] Port BR_GROUPFWD_RESTRICTED patch for Layer 1-esque Linux Bridge forwarding
klaus.mailinglists at pernau.at
Sat Sep 1 22:14:00 CEST 2018
Am 24.08.2018 um 11:10 schrieb Thomas Lamprecht:
> On 8/24/18 9:00 AM, Jesus Llorente wrote:
>> 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
>> they removed a hard-coded restriction so that the behavior of the bridge
>> can be then controlled from the OS with the variable
>> In this post, the author explains the different values this variable can
>> take, according to what we are trying to allow/restrict.
>> 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, 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
More information about the pve-devel