From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <josef@oderland.se>
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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <pve-devel@lists.proxmox.com>; 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 <josef@oderland.se>)
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 <josef@oderland.se>
To: pve-devel@lists.proxmox.com, Alexandre Derumier <aderumier@odiso.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>
<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 <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>,
<mailto:pve-devel-request@lists.proxmox.com?subject=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