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

推荐订阅源

S
SegmentFault 最新的问题
J
Java Code Geeks
V
V2EX
Blog — PlanetScale
Blog — PlanetScale
博客园 - 司徒正美
Hugging Face - Blog
Hugging Face - Blog
F
Fortinet All Blogs
aimingoo的专栏
aimingoo的专栏
B
Blog
A
About on SuperTechFans
有赞技术团队
有赞技术团队
月光博客
月光博客
Microsoft Azure Blog
Microsoft Azure Blog
阮一峰的网络日志
阮一峰的网络日志
腾讯CDC
美团技术团队
大猫的无限游戏
大猫的无限游戏
爱范儿
爱范儿
N
Netflix TechBlog - Medium
C
Check Point Blog
Recent Announcements
Recent Announcements
博客园 - Franky
博客园 - 叶小钗
T
Tailwind CSS Blog

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?