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 278DD6A55E for ; Thu, 16 Sep 2021 23:48:57 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 122C02976A for ; Thu, 16 Sep 2021 23:48:27 +0200 (CEST) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS id 07AB529754 for ; Thu, 16 Sep 2021 23:48:24 +0200 (CEST) Received: by mail-wm1-x333.google.com with SMTP id 140so5854205wma.0 for ; Thu, 16 Sep 2021 14:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=odiso-com.20210112.gappssmtp.com; s=20210112; h=message-id:subject:from:to:date:in-reply-to:references:user-agent :mime-version; bh=eKLBmLQgTeNgEpB9LAdHz19vulJ1e+mIfUA24urPEUk=; b=kF0DUq41OecCPWtk7vo6YRTyr1bwlUVtF2eEjJimsrQg+2o0qk4hR57NxU5vsg4FKj fDCzQXFwadDj+iGppDorHGTVwKOi7IvkLV8dwhM/t7QrfZUTIhUQ2TeM7XWI5D7XKaFo 6wAerTxHgASwXX26kDohnFP2jQwA++JTm9wUiAR0ngQ5eLacY9S5C+L2v8/vERbdMRqv 5SZO8k/PzfOhTgsIUaZ5K2IWKfFvxYKr+XsLqJFDEUFLxhifK3y9hO7f01NF9AXWSMJ4 oaKzwBH1aGbsDe9Ddv2ADjZo7hQeRtqQ0ZLBXx0hnGC6wEkUM53Bt9wcGaEgTIdoIoJg gT/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version; bh=eKLBmLQgTeNgEpB9LAdHz19vulJ1e+mIfUA24urPEUk=; b=ujGj4z3DWYz98Rcfj8SWwbpGPuwTc17iQ30j686XA5ELWt7FaH8Eu3Mv+4c3l6rdVu ssLRwcAeEdK/pyignkF/BRk2ZM2FooQdJtdZpe/RhPyY03sGItjp7YWRGlEWlkoFxlWi akDp+lREexbgJF0NlwA5QENf+dYNco66BvuREes39ak6DvF9dCrH/to9INuc7coHGNgR cmit3t+KSBbrTSeEN+B4W5EmY7uI7xugFCW8FEoQJDxKg3ZWnB45gmhiwd4ng3yjU04y DDEQa4WXOlcdcm7Ko4KMyILDFCyLcoDR4/gRIurzvvYUPwOd7Xti6kXznsHPWd40q4cL 03UA== X-Gm-Message-State: AOAM531qTkyfFliTkDCOBodM2RBzu9xNimSNo20iebwCZQTYaUjoUwG9 9xhFngfBXZyDiwxHWEYtXECM5K2IwHub8Zw5beg= X-Google-Smtp-Source: ABdhPJwu0iFdgPJaB2GQ5UZRWrzfN2rGUMoarV/iUbzT6KbvtDuJ9wgkPssBzupntlbnhZrw/t7gWQ== X-Received: by 2002:a7b:ce19:: with SMTP id m25mr6981214wmc.152.1631828897616; Thu, 16 Sep 2021 14:48:17 -0700 (PDT) Received: from ?IPv6:2a0a:1580:0:1::100c? (ovpn1.odiso.net. [2a0a:1580:2000::3f]) by smtp.gmail.com with ESMTPSA id o24sm8416427wmm.11.2021.09.16.14.48.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Sep 2021 14:48:17 -0700 (PDT) Message-ID: <5e94541c69f65eb9859d6b9f036ed80acf8f113e.camel@odiso.com> From: alexandre derumier To: Thomas Lamprecht , Proxmox VE development discussion Date: Thu, 16 Sep 2021 23:48:15 +0200 In-Reply-To: <478a4600-48f4-3fe8-91ec-e2dbb27bd2c8@proxmox.com> References: <20210914002606.1608165-1-aderumier@odiso.com> <4a34d44143f1c32f38988c478698c094badbc740.camel@odiso.com> <790dd453ab8b0fab53942c7dd4b536d5285a3c00.camel@odiso.com> <478a4600-48f4-3fe8-91ec-e2dbb27bd2c8@proxmox.com> User-Agent: Evolution 3.40.4 MIME-Version: 1.0 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.662 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 HTML_MESSAGE 0.001 HTML included in message RCVD_IN_DNSWL_NONE -0.0001 Sender listed at https://www.dnswl.org/, no trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Thu, 16 Sep 2021 21:48:57 -0000 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.  For vnet, it's easy. the worktlow is: 1) - plug veth/tap iface (+fwbr if firewall)    - disable unicast_flood + bridge_learning on the tap|veth + fwpr interfaces 2) then add static mac with "bridge fdb add dev master static. for 2), for live migration, we need to do it just before the resume of the target vm          for normal start, just after the start or after a nic hotplug. static mac is autoremoved if the interface is removed, so it should be auto handle by cleanup on vm crash too As bonus, the benefit to configure it at bridge level, is that if all egress ports (tap|veth|fwpb) have unicast_flood && learning disable, the only remaining port (physical ethX ingress), is auto set in non- promiscous, so bad traffic never go inside the server. (another requirement is that the bridge need to be vlan-aware, but I think it could work at herzner is default pvid 1 for untagged traffic) https://git.backbone.ws/kolan/backbone-sources/commit/2796d0c648c9 https://legacy.netdevconf.info/0.1/docs/netdev_tutorial_bridge_makita_150213.pdf I'ill try to send patches next week, I'm a bit busy at work this week. Alexandre > > > > I'm going to do tests, testing vlan aware && live migration too. > > great, thanks for your work on this! >