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 B9FDE60E5B for ; Fri, 14 Jan 2022 12:24:01 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id AC9412913B for ; Fri, 14 Jan 2022 12:24:01 +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 AE77D29130 for ; Fri, 14 Jan 2022 12:24:00 +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:From: References:To: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=eRTC6vygeh2V+3rToLp45VPRY+hdCvcd/dbQpuSkf8E=; b=LSp6JKx+tnDfuHRNYcK0zpkARq 4MK4M/3y6J5cCDfrz98P0pjnjMuY7s9HsajvlZBnu6VwYTL8mVwZiXhzW/659F1jsVy9FZgnERjG6 2ijSLJomNEf4O4JvLgY3K9jcqY8XsiK0MZQE6Rf2zK2V0DfICAvKZP7t1WasJ0NTLKKNO3SZrCaaT 4nKyLSMZ+ksRyuOJFbUiJRX6RUAWUaAdOVwbvjWv7+Yc14eBTOHhnawTyzvPwAnJtosY0PadCm5l4 w/M5KRDkcl1Pux93HsZ4EzKr3PyGSFIZ2wD0P4yi1FN+kFrEzn7k0JclDndQipTJ+cQdM9CzGDkpG tNSB2mXQ==; Received: from [193.180.18.160] (port=44906 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 1n8KgU-008iRl-C2 for pve-devel@lists.proxmox.com; Fri, 14 Jan 2022 12:23:54 +0100 Message-ID: <6bc3b9db-a4f2-1172-c717-7802c971e54f@oderland.se> Date: Fri, 14 Jan 2022 12:23:53 +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 To: pve-devel@lists.proxmox.com 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> From: Josef Johansson In-Reply-To: <20220114105147.735ykiad3qva6rge@wobu-vie.proxmox.com> 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.168 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 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, 14 Jan 2022 11:24:01 -0000 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