惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Microsoft Azure Blog
Microsoft Azure Blog
宝玉的分享
宝玉的分享
博客园 - 【当耐特】
有赞技术团队
有赞技术团队
G
Google Developers Blog
Microsoft Security Blog
Microsoft Security Blog
Apple Machine Learning Research
Apple Machine Learning Research
The Cloudflare Blog
Blog — PlanetScale
Blog — PlanetScale
博客园_首页
L
LangChain Blog
Stack Overflow Blog
Stack Overflow Blog
Last Week in AI
Last Week in AI
Y
Y Combinator Blog
罗磊的独立博客
T
Tailwind CSS Blog
博客园 - 叶小钗
T
The Blog of Author Tim Ferriss
Engineering at Meta
Engineering at Meta
博客园 - 聂微东
博客园 - Franky
B
Blog
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
F
Fortinet All Blogs

Proxmox Support Forum

[SOLVED] - Github Auth for Mirrors-Kernel Repo? [Automation] Mass migration tool for MS Win11/Server Proxmox GUI hang - not response is it possible to reject or quarantine spam based on conditions I set ? The PVENode task list in PVE9 is partially obscured due to the terminal font being too large. About 100% error reporting due to pveproxy.service hooks Kubernetes overlay networking breaks when upgrading from PVE 9.1 to PVE 9.2.3 Zentraler Speicher No space left on device Combine datastore and direct file archival to tape Kernel panic VFS: Unable to mount root fs on unknown-block (0,0) sobald ein 7.x Kernel verwendet wird. How to migrate disk of a VM from one ZFS to another Windows Server 2025 fails to boot after PVE 9.2 / Linux 7.0 Kernel upgrade Cannot Install Proxmox on T610 Poweredge with H700 PERC card sdn Config. gateway not reachable How to safely change domain/FQDN? Welche Filterquote erreicht ihr? NFS Share status unknown on 2 of 5 nodes Can't connect to PVE9 consoles [solved] Can't connect to PVE9 consoles [solved] [SOLVED] - Use secondary network for PVE commands Created cluster, one node storage gone BUG: proxmox mail gateway FROM = null bypass spam filtering Moving existing PBS from VMWare workstation to PVE cluster Does eBGP SDN fabric support external peering? Bug: PDM 1.1 not recognizing valid license status Proxmox GUI hang - not response PVE crashes unexpectedly Proxmox Backup Server 4.2 released! Advice
Wireguard fabric interface MTU in PVE 9.2
invalid@exam · 2026-06-15 · via Proxmox Support Forum

Hello!

I tried using the new SDN WireGuard Fabric in Proxmox VE 9.2.3. My setup consists of three PVE 9.2.3 nodes in a cluster with a shared SDN WireGuard Fabric (these nodes are not connected via L2). On top of that, I configured a VXLAN network with MTU 1370 (1500 base interface - 80WG - 50VXLAN).

The issue is that the WireGuard interfaces created by the Fabric are configured with the default MTU of 1500. With this configuration, traffic between nodes is unstable and I experience packet loss in the range of 20–30%.

As soon as I manually set the MTU of the WireGuard interfaces to 1420 (the commonly recommended value for WireGuard), the SDN VXLAN network becomes completely stable: no packet loss, no excessive latency, and no noticeable jitter. However, the PVE Fabric configuration currently does not seem to provide any way to specify the MTU for the underlying WireGuard interfaces. There is an MTU setting for VXLAN, but not for WG itself. I have tried setting the MTU manually and also adding it to /etc/network/interfaces.d/sdn. Both approaches work only until Proxmox regenerates or reapplies the configuration. This appears to happen at runtime, as the MTU eventually reverts to 1500 on its own.

Has anyone managed to run a WireGuard Fabric with VXLAN on top of it in a stable way? Or perhaps uses another simple and reliable setup using the new WireGuard Fabric?

Default base interface (with packet loss)

Bash:

16: wg1sdn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none

And after manual MTU adjustment (no packet loss)

Bash:

# ip link show wg1sdn
16: wg1sdn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

Last edited:

Agree that this should be implemented, could you open a bugzilla entry at https://bugzilla.proxmox.com ?

I have tried setting the MTU manually and also adding it to /etc/network/interfaces.d/sdn. Both approaches work only until Proxmox regenerates or reapplies the configuration. This appears to happen at runtime, as the MTU eventually reverts to 1500 on its own.

As a workaround, in the meanwhile you can set it in /etc/network/interfaces directly:

Code:

iface wg0 inet manual
    mtu 1420

This should not get overwritten by the SDN stack.

On top of that, I configured a VXLAN network with MTU 1370 (1500 base interface - 80WG - 50VXLAN).

The issue is that the WireGuard interfaces created by the Fabric are configured with the default MTU of 1500. With this configuration, traffic between nodes is unstable and I experience packet loss in the range of 20–30%.

That seems odd, I've tested this locally with a VXLAN zone that has 1370 MTU and I did not experience any packet loss. Are you sending packets from inside a guest, I suppose? Did you double-check that the MTU of the network interface inside the guest is set to 1370?