From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 96EE864007 for ; Fri, 28 Jan 2022 04:39:31 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 89E89282DF for ; Fri, 28 Jan 2022 04:39:31 +0100 (CET) Received: from office.oderland.com (office.oderland.com [91.201.60.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 5AEB9282D6 for ; Fri, 28 Jan 2022 04:39:30 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=oderland.se ; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References: To:From:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=HI2aqhSI8bXQ2o9QuwyJLec4SjqKUlIobpySrv3F+EU=; b=VZypr83G6IXFssxW0resUWQImn 7L8yZs6faZnb1c0DtQf8SyEQes7Oky5qPSitUwLqfu1Fh+PvDji9aFkiRpmwdjSecl6Kk7ifBxDD6 JYv+jbv+dCG75PurTNO+bH7iz6bjvqQXcVKUtu756iuXz3xD8Jnnd5eCwGUmnUaTqQa0tR+S9hUOI rBjjuVgP97o1kh8RsrwRo2UlmwTofR+MUBaxglLBuWG1C/FrY3Tla4IT/OQ0wY4+mwDRK9bzIVXxI AtIp0wB2pGx+kXyoj12QJjD3MooArasCKUX5NXmu1tOX8l/vr4yWKdVRUyyuyF9+hh98DwzebRIhL H1yadHog==; Received: from [193.180.18.160] (port=57754 helo=[10.137.0.14]) by office.oderland.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nDI6d-00Aw3E-UY; Fri, 28 Jan 2022 04:39:23 +0100 Message-ID: <72aee949-c0bc-03c7-181c-880f97c3d1f9@oderland.se> Date: Fri, 28 Jan 2022 04:39:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Thunderbird/97.0 Content-Language: en-US From: Josef Johansson To: pve-devel@lists.proxmox.com, Alexandre Derumier References: <20210914002606.1608165-1-aderumier@odiso.com> <4a34d44143f1c32f38988c478698c094badbc740.camel@odiso.com> <790dd453ab8b0fab53942c7dd4b536d5285a3c00.camel@odiso.com> <478a4600-48f4-3fe8-91ec-e2dbb27bd2c8@proxmox.com> <5e94541c69f65eb9859d6b9f036ed80acf8f113e.camel@odiso.com> <20220114105147.735ykiad3qva6rge@wobu-vie.proxmox.com> <6bc3b9db-a4f2-1172-c717-7802c971e54f@oderland.se> In-Reply-To: <6bc3b9db-a4f2-1172-c717-7802c971e54f@oderland.se> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - office.oderland.com X-AntiAbuse: Original Domain - lists.proxmox.com X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - oderland.se X-Get-Message-Sender-Via: office.oderland.com: authenticated_id: josjoh@oderland.se X-Authenticated-Sender: office.oderland.com: josjoh@oderland.se X-SPAM-LEVEL: Spam detection results: 0 AWL -0.135 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain NICE_REPLY_A -0.001 Looks like a legit reply (A) SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [oderland.se, vmware.com, network.pm, proxmox.com, pm.new] Subject: Re: [pve-devel] [PATCH pve-common] network: disable unicast flooding on tap|veth|fwln ports X-BeenThere: pve-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox VE development discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jan 2022 03:39:31 -0000 On 1/14/22 12:23, Josef Johansson wrote: > On 1/14/22 11:51, Wolfgang Bumiller wrote: >> On Thu, Sep 16, 2021 at 11:48:15PM +0200, alexandre derumier wrote: >>> Le mercredi 15 septembre 2021 à 19:09 +0200, Thomas Lamprecht a écrit : >>>> On 15.09.21 17:33, alexandre derumier wrote: >>>>> 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. >>>> As this would be on the VM tap devices it would sound somewhat >>>> reasonable to >>>> have it as per vNIC setting, but naturally it would then be a bit >>>> annoying to >>>> change for all; a tradeoff could be to allow setting the default >>>> value per >>>> bridge, node or datacenter (I'd do only one of those). >>>> >>>> What do you think? >>>> >>> I have done test, I think the best way is to enable it on the bridge >>>  or vnet for sdn. >>> because ovs don't support it for example, or its not needed for routed >>> setup or vxlan. >>> I don't known too much where add this option for classic vmbr ? in >>> /etc/network/interfaces ?. >>> I can't reuse bridge-unicast-flood off, bridge-learning off on vmbr >>> with ifupdown, because it's apply on all ports (ethX), and we don't >>> want that. >>> I could add a custom attribute, but I need to parse >>> /etc/network/interfaces in this case  for the tap_plug sub.  >> As far as I can tell, ifupdown2 only applies this to the ports it knows >> about, so in theory we *could* start to honor this for the interfaces we >> crate for VMs as a default, and have an on/off/auto value on VM network >> interfaces (override or use whatever /e/n/interfaces says). >> >> Or do you mean you typically want this to be on for VMs but off >> specifically for the physical port? Then /e/n/interfaces won't fit. >> >> Although it *does* allow listing ports and doesn't seem to mind if a >> port does not exist, so we *may* get away with saying we expect >> something like this: >> >> bridge-unicast-flood eth0=on _pve=off >> >> Either way, it's a port setting, so I wonder a by-vm-interface optional >> override probably makes sense, not sure (but would be easy enough to >> do). >> >> >> _______________________________________________ >> pve-devel mailing list >> pve-devel@lists.proxmox.com >> https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel >> > Maybe something along the lines of > > --- Network.pm 2021-05-25 16:35:27.000000000 +0200 > +++ Network.pm.new 2022-01-14 12:20:48.181632198 +0100 > @@ -309,6 +309,7 @@ sub veth_create { > disable_ipv6($vethpeer); > &$activate_interface($veth); > &$activate_interface($vethpeer); > + PVE::Tools::run_command(['/sbin/bridge', 'link', 'set', 'dev', $vethpeer, 'flood', 'off']); > } > > sub veth_delete { > > > This is basically what I do right to solve this problem. I leave everything else with unicast_flood on. > I do not use ovs yet, so basic bridging. > > If I enable it on fwln some ARP-functionality stops working. > > Regards > Josef > I'm landing on these commits, I've tested this one and it seems to work properly. --- a/usr/share/perl5/PVE/Network.pm    2022-01-28 04:20:22.704806437 +0100 +++ b/usr/share/perl5/PVE/Network.pm.new    2022-01-28 04:20:10.256959699 +0100 @@ -335,6 +335,13 @@ my $create_firewall_bridge_linux = sub {      &$bridge_add_interface($fwbr, $vethfw);      &$bridge_add_interface($bridge, $vethfwpeer, $tag, $trunks); +    # When the server does not know where to send traffic, it will broadcast +    # the traffic onto every port on a bridge. There's two cases where this is +    # not wanted. Servers can siphone traffic not intended for it but also +    # cause the first request (between correct servers) to fail. Leave $vethpeer +    # since otherwise ARP between HV and VM will not work. +    PVE::Tools::run_command(['/sbin/bridge', 'link', 'set', 'dev', $vethfwpeer, 'flood', 'off']); +      &$bridge_add_interface($fwbr, $iface);  }; This one is not tested, but should in theory be the same. One thing that can happen is that outbound traffic from this server is not working properly. I will do some testing with this soon. --- /usr/share/perl5/PVE/Network.pm    2022-01-28 04:21:10.524217677 +0100 +++ /usr/share/perl5/PVE/Network.pm.new    2022-01-28 04:35:23.921695488 +0100 @@ -411,6 +411,9 @@ sub tap_plug {          &$create_firewall_bridge_linux($iface, $bridge, $tag, $trunks);      } else {          &$bridge_add_interface($bridge, $iface, $tag, $trunks); + +        # Do not allow VMs to siphone traffic not destined for them +        PVE::Tools::run_command(['/sbin/bridge', 'link', 'set', 'dev', $iface, 'flood', 'off']);      }        } else { Let me know what you think! And I'll make proper patches. Regards - Josef