From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 25F2D1FF0B3 for ; Thu, 10 Sep 2026 06:41:59 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id 6CB04215D3; Thu, 10 Sep 2026 06:41:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=glanzmann.de; s=infra26101010; t=1789015302; bh=4l292oOFYn5mJlAPGNL88QaI4I4tK4FqiFegSKfRdjA=; h=Date:From:To:Cc:Subject:In-Reply-To:From; b=NaFKb1GbIlIHAWw7N1F+mPtEgh6D7wY2kQzSOWEORv/UAIq+GGzjrYFKPu3Rp6boS qCUnp8sWtfrDjjei9tOrRoRwARwXsj3m+4oRLQaOhe97zkDk7qBY1zdDaCYllrYzX2 koDDZYNdDPeC9ZweTlgQ32JstM5n8bKDOUDimetERjAA439MxW5XQy+4aOE7PMXnWw Po7W+TYVaZpUknPQ3szdayh3pMdx4djQb+g/cx8oyVq3wFf9cGYAglAO8FGJydUFFv ykjPzAta5aVPRLJc1GUQ3AfOntUTcFLRMoHjEfIoNtvb26DotNvt51SERMon7AM11L eYbbpbgmUh9koilrwDZHzQMOITtaKbpurL5MKxJCmD8tDA5UtQN+oz9vN5wAkZamKR vXhY1AHr6BCiEr0dUcif0/gUfi42/1elEP9SUJ05lHbaw4IyC+hXYn6UUjgvXionyx ve3yA5SaKOFUBklTTtf3dpySvfXDlrmRsVYsf8hDBZrN58BbzgS4h44t/l0y9bV5p/ TqNhDjZ4wME+LD2tYe03EZbOkFaEHyylv+I/lKfZS2sKtLhKlIsLci8FNlA0dY+CXU ljDiTtDQktpShRcTKo5650mM78aK5GVdQ+R4ceiZkWYhNJDh2BBk1GF4THcCC7POfj pLn11ID+UU9TNJK3aMEQvvJ8= Date: Thu, 10 Sep 2026 06:41:42 +0200 From: Thomas Glanzmann To: pve-devel@lists.proxmox.com Subject: Re: [PATCH] sdn: qinq: apply zone MTU to the notag vnet veth pair Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SPAM-LEVEL: Spam detection results: 0 AWL -0.113 Adjusted score from AWL reputation of From: address 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 DMARC_PASS -0.1 DMARC pass policy POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 55LB676MFWHWGXYGPJA3WUUHZZS6HYTJ X-Message-ID-Hash: 55LB676MFWHWGXYGPJA3WUUHZZS6HYTJ X-MailFrom: thomas@glanzmann.de X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Hi, this is a reproducer for the bug fixed by the patch I sent on 2026-09-04 ("sdn: qinq: apply zone MTU to the notag vnet veth pair"), which has not been picked up yet. The fix is a two-line change and the bug it fixes is obvious and user-visible, so I would like to ping again and provide a complete, tested reproduction. Summary ------- A QinQ zone with an explicit MTU applies that MTU to the zone bridge (z_) and to the vnet bridge, but *not* to the ln_/pr_ veth pair it creates as the uplink for a vnet without a tag. Both veth ends stay at the kernel default of 1500. For a tagless vnet, pr_ is a port of the vnet bridge itself, so that veth sits directly in the guest data path. Every other interface in the chain reports the configured MTU, but the veth silently caps the zone at 1500 and drops larger frames with no error and no counter. Tagged vnets are unaffected because they attach through z_. and never traverse the veth. That is why the bug is easy to miss. Environment ----------- pve-manager/9.2.11/f6997e698c7933ea kernel 7.0.14-15-pve * uplink bridge: vmbr0, VLAN-aware, MTU 9214 * QinQ zone: qz, bridge vmbr0, tag 10, mtu 9000 * vnet: qv1, zone qz, no tag (this is what triggers the bug) * guest: VM 101 attached to qv1 Reproduction ------------ 1) Create the QinQ zone and a *tagless* vnet, then apply the SDN config: pvesh create /cluster/sdn/zones --type qinq --zone qz \ --bridge vmbr0 --tag 10 --mtu 9000 --nodes host-08 pvesh create /cluster/sdn/vnets --vnet qv1 --zone qz pvesh set /cluster/sdn 2) Inspect the MTU of the interfaces created for the zone: # for i in z_qz ln_qz pr_qz qv1; do \ printf "%-6s %s\n" "$i" "$(cat /sys/class/net/$i/mtu)"; done z_qz 9000 ln_qz 1500 <-- kernel default, should be 9000 pr_qz 1500 <-- kernel default, should be 9000 qv1 9000 Both ends of the ln_qz/pr_qz veth pair are stuck at 1500 while the zone and vnet bridges correctly report 9000. 3) Confirm pr_qz is directly in the guest data path: # bridge link | grep -E 'pr_qz|ln_qz|qv1' 25: ln_qz@pr_qz ... mtu 1500 master z_qz state forwarding ... 26: pr_qz@ln_qz ... mtu 1500 master qv1 state forwarding ... The vnet bridge qv1 has pr_qz as its port because qv1 has no tag. 4) Attach a guest to qv1 and ping a peer across the veth (any peer that is reachable through z_qz / vmbr0.10). With DF set, frames larger than the veth MTU are silently dropped: # guest: ping -M do -s payload 1472 -> reply payload 1476 -> reply payload 1477 -> no reply, 100% loss, no ICMP error, no counter payload 2000 -> no reply, 100% loss The ceiling is exactly at ping -M do -s 1476, consistent with br_forward() allowing mtu + hard_header_len + VLAN_HLEN bytes of frame, and matches the behaviour described in the patch. After the patch --------------- Applying the two-line fix from the original patch to src/PVE/Network/SDN/Zones/QinQPlugin.pm and re-applying the SDN config gives: z_qz 9000 ln_qz 9000 pr_qz 9000 qv1 9000 and the same ping across the veth now succeeds at every size: payload 1472 -> reply payload 1476 -> reply payload 1477 -> reply payload 2000 -> reply payload 8000 -> reply payload 8972 -> reply So the fix is correct and complete: it makes the veth pair honour the configured zone MTU and removes the silent 1500 cap from the tagless vnet data path. Zones without an explicit MTU are byte-for-byte unaffected, since the added lines are guarded with `if $mtu`. Please consider picking up the patch. I am happy to re-send it in a thread or as a new submission if that is easier. If our shared customer who I developed this patch for should open a case with you in order to address this, please let me know. This issue showed up during integration testing from VMware vSphere to Proxmox. Cheers, Thomas