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 D794494802 for ; Fri, 24 Feb 2023 12:06:22 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id B98B17FE1 for ; Fri, 24 Feb 2023 12:06:22 +0100 (CET) Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com [94.136.29.106]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Fri, 24 Feb 2023 12:06:22 +0100 (CET) Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1]) by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DB495483D2 for ; Fri, 24 Feb 2023 12:06:21 +0100 (CET) From: Dominik Csapak To: pve-devel@lists.proxmox.com Date: Fri, 24 Feb 2023 12:06:21 +0100 Message-Id: <20230224110621.765001-1-d.csapak@proxmox.com> X-Mailer: git-send-email 2.30.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-SPAM-LEVEL: Spam detection results: 0 AWL 0.061 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: [pve-devel] [PATCH common] fix #4547: set MTU on dynamically created vlan bridges 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, 24 Feb 2023 11:06:22 -0000 Otherwise the created vlan bridge has the default MTU, which is unexpected when the original bridge has some other MTU configured. We already do this for the firewall bridges, so we should do so too for the vlan bridges. Signed-off-by: Dominik Csapak --- technically this is a breaking change i think, since someone might depend on the fact that the vlan bridges always have the default mtu, but there is no way to configure that besides from manually modifying the /etc/network/interfaces file, so not completely sure if we want to do that now, or with the next major release src/PVE/Network.pm | 3 +++ 1 file changed, 3 insertions(+) diff --git a/src/PVE/Network.pm b/src/PVE/Network.pm index 355637b..22ca5b3 100644 --- a/src/PVE/Network.pm +++ b/src/PVE/Network.pm @@ -620,6 +620,9 @@ sub activate_bridge_vlan { iface_create($bridgevlan, 'bridge'); } + my $bridgemtu = read_bridge_mtu($bridge); + eval { run_command(['/sbin/ip', 'link', 'set', $bridgevlan, 'mtu', $bridgemtu]) }; + # for each physical interface (eth or bridge) bind them to bridge vlan foreach my $iface (@ifaces) { activate_bridge_vlan_slave($bridgevlan, $iface, $tag); -- 2.30.2