Posting this because I could not find the same case anywhere on the forum or via search, and the symptoms are easy to misread as something else.
TL;DR — If you run a PVE instance whose uplink sits on a network with an MTU below 1500 (an SDN VXLAN vnet gives you 1450), you have to set the MTU manually on both the NIC and the bridge. Setting it on only one of them fixes only half of the symptoms.
Setup
Nothing custom in
Symptoms
1. SSH and the Web UI stall part-way through
Output stops mid-stream.
The Web UI does the same thing — panels render halfway and then hang. No error, no timeout, it just stops. This is intermittent: short outputs are fine, so it looks like a flaky connection rather than a configuration problem.
2.
From the Web UI (Apply Configuration):
From the shell, the same thing may show up as a warning instead:
How to confirm it's this
Check for an MTU mismatch between the NIC and the bridge:
The NIC is 1450 (virtio picks this up from the vnet automatically), the bridge is 1500. Nothing in
Then test the path with DF set — from the PVE in question, to its gateway:
Note that the large one just disappears. No ICMP unreachable comes back, so Path MTU Discovery never kicks in and TCP keeps retransmitting the same oversized segment. That is why the terminal hangs instead of erroring out.
Fix
Set the MTU explicitly on both the NIC and the bridge, from the Web UI of the affected PVE:
1450 is the value for a standard VXLAN zone. Use whatever your underlay actually gives you.
To verify,
and
Two things that tripped me up
Fixing only one of the two looks like it worked. I tested these separately:
If you stop at the first one because the error message disappeared, you still have the stalling. Set both.
The GUI shows 1500 when nothing is set. The MTU field displays a greyed-out 1500 as a placeholder, not the current value. My NIC was actually running at 1450 the whole time while the GUI said 1500 for both interfaces, so
Scope
What I confirmed is the nested-PVE-on-a-VXLAN-vnet case, reproduced on a clean install from the installer ISO, so it is not tied to any particular update.
Nothing about it looks specific to nesting or to VXLAN, though. The trigger is simply that the uplink runs at an MTU below 1500 while the bridge sits at 1500, so I would expect the same thing on any PVE installed onto a sub-1500 path — a physical NIC on a link with a reduced MTU, a tunnelled uplink, and so on. I have not tested those, so treat it as something worth checking rather than a confirmed report.
One difference is worth flagging if you are on a non-virtio NIC: with virtio the NIC advertises its 1450 limit, so the attempt to raise it to 1500 fails loudly and you get the
Where I ran into this
I hit this while bringing up a VXLAN-based isolated tenant with MSL Setup v2.x — a multi-tenant enablement tool for Proxmox that I maintain. It configures Proxmox SDN and firewall rules to build L2-isolated per-project environments, with a dedicated VPN attached to each tenant; since v2.0 those isolated networks span cluster nodes through VXLAN zones and vnets.
So if you use it and then run a nested PVE inside one of those tenants, the MTU settings above are what you need — the tenant vnet is a VXLAN zone, which is exactly the 1450 case described here.
To be clear about the cause, though: this is not an MSL Setup issue. It comes from how a stock PVE network config behaves on a sub-1500 MTU uplink, and you get identical behaviour on a VXLAN zone you configure by hand in the Proxmox SDN GUI, or on any EVPN overlay you build yourself. The tool is simply one way to end up with a VXLAN tenant in the first place. That is also why I posted this on the forum rather than in the project's issue tracker — the fix belongs in the nested PVE's own network config, not in whatever created the overlay underneath it.
TL;DR — If you run a PVE instance whose uplink sits on a network with an MTU below 1500 (an SDN VXLAN vnet gives you 1450), you have to set the MTU manually on both the NIC and the bridge. Setting it on only one of them fixes only half of the symptoms.
Setup
- Host: PVE 9.2.6, SDN VXLAN zone, vnet MTU 1450
- Guest: a nested PVE, NIC attached to the vnet, no MTU set anywhere (the GUI showed "same as bridge"). Seen on 9.1.9, then reproduced from scratch on a clean 9.0.3 install.
Code:
net0: virtio=BC:24:11:69:3B:06,bridge=vnetpj02,firewall=1Nothing custom in
/etc/network/interfaces — a stock install:
Code:
iface ens18 inet manual
auto vmbr0
iface vmbr0 inet static
address 172.16.17.1/24
gateway 172.16.17.254
bridge-ports ens18
bridge-stp off
bridge-fd 0Symptoms
1. SSH and the Web UI stall part-way through
Output stops mid-stream.
cat on a longer file is a reliable trigger:
Code:
cat /var/log/dpkg.logThe Web UI does the same thing — panels render halfway and then hang. No error, no timeout, it just stops. This is intermittent: short outputs are fine, so it looks like a flaky connection rather than a configuration problem.
2.
ifreload -a failsFrom the Web UI (Apply Configuration):
Code:
ens18 : error: ens18: netlink: failed to set mtu to 1500:
operation failed with 'Invalid argument' (22)
TASK ERROR: command 'ifreload -a' failed: exit code 1From the shell, the same thing may show up as a warning instead:
Code:
warning: error while writing to file /sys/class/net/ens18/mtu: [Errno 22] Invalid argumentHow to confirm it's this
Check for an MTU mismatch between the NIC and the bridge:
Code:
# ip link show
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 ... master vmbr0
3: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...The NIC is 1450 (virtio picks this up from the vnet automatically), the bridge is 1500. Nothing in
/etc/network/interfaces asked for either value.Then test the path with DF set — from the PVE in question, to its gateway:
Code:
ping -M do -s 1422 -c 3 <gateway> # succeeds
ping -M do -s 1472 -c 3 <gateway> # 100% loss, silentlyNote that the large one just disappears. No ICMP unreachable comes back, so Path MTU Discovery never kicks in and TCP keeps retransmitting the same oversized segment. That is why the terminal hangs instead of erroring out.
Fix
Set the MTU explicitly on both the NIC and the bridge, from the Web UI of the affected PVE:
- Go to
<node> > System > Network - Select the NIC (e.g.
ens18), clickEdit, tickAdvanced, setMTUto 1450, clickOK - Select
vmbr0, same thing —Edit→Advanced→MTU1450 →OK - Click
Apply Configuration
1450 is the value for a standard VXLAN zone. Use whatever your underlay actually gives you.
To verify,
/etc/network/interfaces should now carry both entries:
Code:
iface ens18 inet manual
mtu 1450
auto vmbr0
iface vmbr0 inet static
address 172.16.17.1/24
gateway 172.16.17.254
bridge-ports ens18
bridge-stp off
bridge-fd 0
mtu 1450and
ip link show should report 1450 on both.Two things that tripped me up
Fixing only one of the two looks like it worked. I tested these separately:
- NIC only → the
ifreloaderror goes away, but the terminal still stalls (reproduced on the 2ndcat) - Bridge only → the stalls go away (10/10 clean), but the
ifreloaderror stays
If you stop at the first one because the error message disappeared, you still have the stalling. Set both.
The GUI shows 1500 when nothing is set. The MTU field displays a greyed-out 1500 as a placeholder, not the current value. My NIC was actually running at 1450 the whole time while the GUI said 1500 for both interfaces, so
ip link show is the reliable check.Scope
What I confirmed is the nested-PVE-on-a-VXLAN-vnet case, reproduced on a clean install from the installer ISO, so it is not tied to any particular update.
Nothing about it looks specific to nesting or to VXLAN, though. The trigger is simply that the uplink runs at an MTU below 1500 while the bridge sits at 1500, so I would expect the same thing on any PVE installed onto a sub-1500 path — a physical NIC on a link with a reduced MTU, a tunnelled uplink, and so on. I have not tested those, so treat it as something worth checking rather than a confirmed report.
One difference is worth flagging if you are on a non-virtio NIC: with virtio the NIC advertises its 1450 limit, so the attempt to raise it to 1500 fails loudly and you get the
ifreload error above. That error is the only reason I looked at MTU at all — without it I would have kept chasing a "flaky SSH" ghost. If your NIC accepts 1500 without complaint, you would get the stalling with no error to go on. I have not verified this, but it is the case I would watch for.Where I ran into this
I hit this while bringing up a VXLAN-based isolated tenant with MSL Setup v2.x — a multi-tenant enablement tool for Proxmox that I maintain. It configures Proxmox SDN and firewall rules to build L2-isolated per-project environments, with a dedicated VPN attached to each tenant; since v2.0 those isolated networks span cluster nodes through VXLAN zones and vnets.
So if you use it and then run a nested PVE inside one of those tenants, the MTU settings above are what you need — the tenant vnet is a VXLAN zone, which is exactly the 1450 case described here.
To be clear about the cause, though: this is not an MSL Setup issue. It comes from how a stock PVE network config behaves on a sub-1500 MTU uplink, and you get identical behaviour on a VXLAN zone you configure by hand in the Proxmox SDN GUI, or on any EVPN overlay you build yourself. The tool is simply one way to end up with a VXLAN tenant in the first place. That is also why I posted this on the forum rather than in the project's issue tracker — the fix belongs in the nested PVE's own network config, not in whatever created the overlay underneath it.
Last edited:
