MTU Not being correctly set between host and LXC

T

Tmanok

Renowned Member
May 21, 2019
309
76
68
Victoria, British Columbia, Canada
lightyearlabs.ca
Hi Everyone,

I think I may have come across a bug? When configuring MTU on PVE, whether the GUI or CLI is synonymous, I checked both and MTU was setup to 1450, it doesn't actually apply to an LXC in the latest PVE- actually I am moments from rebooting this host to determine whether 7.0.14-14 & 9.2.11 fixes it. I had to manually hand edit /etc/network/interfaces in the LXC to resolve it. This is not sustainable given many containers.

Environment:
Code: 
proxmox-ve: 9.2.0 (kernel 7.0.14-12-pve)
  pve-manager: 9.2.10
  pve-container: 6.1.13
  lxc-pve: 7.0.0-2
  libpve-network-perl: 1.6.7


Unprivileged CT, Debian 13 template, attached to an SDN EVPN VNet with MTU 1450.

What I see:

Code: 
# pct config 102
  net0: name=eth0,bridge=services,firewall=0,gw=10.0.11.1,hwaddr=BC:24:11:07:82:63,ip=10.0.11.2/24,mtu=1450,type=veth


  # grep -i mtu /var/lib/lxc/102/config
  lxc.net.0.mtu = 1450


  # ip -br link show veth102i0
  veth102i0@if2  UP  fe:69:3c:14:96:ae <BROADCAST,MULTICAST,UP,LOWER_UP>
  (host side is 1450)


  # pct exec 102 -- ip link show eth0
  2: eth0@if31: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ...

So the guest config, the LXC config and the host-side veth all agree on 1450, but the interface inside the container is 1500. This survived pct reboot and a full pct stop / pct start, and a new veth was created each time.

The container's /etc/network/interfaces had no mtu line:


Code: 
auto eth0
  iface eth0 inet static
          address 10.0.11.2/24
          gateway 10.0.11.1

Adding "mtu 1450" to that stanza and running ifdown eth0 && ifup eth0 fixed it, and it now persists across restarts.

My guess is that pve-container renders the guest's /etc/network/interfaces at creation time from the NIC config, and that changing mtu on an existing container updates lxc.net.0.mtu but does not rewrite the file inside the guest. ifupdown then brings eth0 up at the default 1500, overriding whatever LXC set on the peer.

Questions:
  1. Is the guest's /etc/network/interfaces expected to be rewritten when the NIC MTU changes on an existing container, or is it only rendered at creation?
  2. If it is only rendered at creation, should lxc.net.0.mtu still apply to the container-side interface independently of what ifupdown does inside the guest? The host-side peer does get 1450, so the setting is reaching LXC.
  3. Is the documented expectation that MTU on an SDN VNet is set per guest by hand, or that the NIC setting is authoritative?
This matters for SDN EVPN/VXLAN zones, where every guest needs 1450 and there is no DHCP on EVPN zones to hand out option 26 as I came to realize thanks to Ggoller https://forum.proxmox.com/threads/ipam-dhcp-features-tmanok.185823/#post-866586. When a silently-1500 guest passes ping and DNS and then hangs on HTTPS, which is an unpleasant thing to debug, and it sorta defeats the whole single-pane-of-glass management we all love and appreciate with PVE.

Thanks,


Tmanok
 
Last edited:
This may be helpful:

N

Thread 'Debian 13 LXC MTU always set to 1500'

Hi all,

I have a PVE box in an environment with an MTU of 1400. It works absolutely fine. Any VMs created with an MTU of 1400 work absolutely fine. Debian 11 and 12 LXCs configured to use the bridge MTU also work fine.

The problem comes with the Debian 13 LXC (debian-13-standard_13.1-2_amd64.tar.zst) which, when configured to use the bridge MTU (or even explicitly setting the MTU to 1400), comes up with an MTU of 1500.

Am I missing something - any help would be appreciated.

N.
 
You must log in or register to reply here.
Top Bottom
Back