[pve-devel] [PATCH pve-common] network: disable unicast flooding on tap|veth|fwln ports
alexandre derumier
aderumier at odiso.com
Wed Sep 15 17:33:35 CEST 2021
I have looked at other hypervisors implementations (as it don't see to
have problem with hetzner),
https://listman.redhat.com/archives/libvir-list/2014-December/msg00173.html
https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.1/administration/GUID-C5752084-A582-4AEA-BD5D-03FE5DBC746E.html
Both vmware && libvirt have a mode to manually manage fdb entries in
bridge mac table.
This will work if only 1mac is behind 1 nic, so it should be an option
(nested hypervisor for examples).
but for classic vm , it could allow to disable unicast_flood &&
learning for the tap interface, but also promisc mode on tap interface!
I was think about add an option on vmbrX or vnetX directly to
enable/disable.
I'm going to do tests, testing vlan aware && live migration too.
Le mardi 14 septembre 2021 à 08:32 +0200, alexandre derumier a écrit :
> Thinking a little bit more about this,
> I think we should add an option in vm/ct nic options, to enable it.
>
> It could break some network where arp timeout is bigger than default
> brige ageing-time (5min by default), or with special asymetric
> networks.
>
>
> Le mardi 14 septembre 2021 à 02:26 +0200, Alexandre Derumier a écrit :
> > Currently, if bridge receive an unknown dest mac (network
> > bug/attack/..),
> > we are flooding packets to all bridge ports.
> >
> > This can waste cpu time, even more with firewall enabled.
> > Also, if firewall is used with reject action, the src mac of RST
> > packet is the original unknown dest mac.
> > (This can block the server at Hetzner for example)
> >
> > So, we can disable unicast_flood on tap|veth|fwln port interface.
> > bridge will learn mac address of the vm|ct, when it send traffic
> > or when It'll reply to arp requests coming from outside.
> >
> > Signed-off-by: Alexandre Derumier <aderumier at odiso.com>
> > ---
> > src/PVE/Network.pm | 9 +++++++++
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/src/PVE/Network.pm b/src/PVE/Network.pm
> > index 15838a0..119340f 100644
> > --- a/src/PVE/Network.pm
> > +++ b/src/PVE/Network.pm
> > @@ -207,6 +207,12 @@ sub disable_ipv6 {
> > close($fh);
> > }
> >
> > +my $bridge_disable_interface_flooding = sub {
> > + my ($iface) = @_;
> > +
> > +
> > PVE::ProcFSTools::write_proc_entry("/sys/class/net/$iface/brport/unic
> > ast_flood", "0");
> > +};
> > +
> > my $bridge_add_interface = sub {
> > my ($bridge, $iface, $tag, $trunks) = @_;
> >
> > @@ -334,6 +340,7 @@ my $create_firewall_bridge_linux = sub {
> > veth_create($vethfw, $vethfwpeer, $bridge);
> >
> > &$bridge_add_interface($fwbr, $vethfw);
> > + &$bridge_disable_interface_flooding($vethfw);
> > &$bridge_add_interface($bridge, $vethfwpeer, $tag, $trunks);
> >
> > &$bridge_add_interface($fwbr, $iface);
> > @@ -359,6 +366,7 @@ my $create_firewall_bridge_ovs = sub {
> > PVE::Tools::run_command(['/sbin/ip', 'link', 'set', $ovsintport,
> > 'mtu', $bridgemtu]);
> >
> > &$bridge_add_interface($fwbr, $ovsintport);
> > + &$bridge_disable_interface_flooding($ovsintport);
> > };
> >
> > my $cleanup_firewall_bridge = sub {
> > @@ -406,6 +414,7 @@ sub tap_plug {
> > } else {
> > &$bridge_add_interface($bridge, $iface, $tag, $trunks);
> > }
> > + &$bridge_disable_interface_flooding($iface);
> >
> > } else {
> > &$cleanup_firewall_bridge($iface); # remove stale devices
>
More information about the pve-devel
mailing list