From: alexandre derumier <aderumier@odiso.com>
To: pve-devel@lists.proxmox.com
Subject: Re: [pve-devel] [PATCH pve-common] network: disable unicast flooding on tap|veth|fwln ports
Date: Wed, 15 Sep 2021 17:33:35 +0200 [thread overview]
Message-ID: <790dd453ab8b0fab53942c7dd4b536d5285a3c00.camel@odiso.com> (raw)
In-Reply-To: <4a34d44143f1c32f38988c478698c094badbc740.camel@odiso.com>
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@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
>
next prev parent reply other threads:[~2021-09-15 15:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 0:26 Alexandre Derumier
2021-09-14 6:32 ` alexandre derumier
2021-09-15 15:33 ` alexandre derumier [this message]
2021-09-15 17:09 ` Thomas Lamprecht
2021-09-16 21:48 ` alexandre derumier
2022-01-14 10:51 ` Wolfgang Bumiller
2022-01-14 11:23 ` Josef Johansson
2022-01-28 3:39 ` Josef Johansson
2022-01-14 16:50 ` DERUMIER, Alexandre
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=790dd453ab8b0fab53942c7dd4b536d5285a3c00.camel@odiso.com \
--to=aderumier@odiso.com \
--cc=pve-devel@lists.proxmox.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox