The following problem exists on an out of the box install with latest 3.4 ISO installer (pve-kernel-2.6.32-39-pve) and also following a dist-upgrade which installs pve-kernel-2.6.32-40-pve. Manually installing pve-kernel-3.10.0-11-pve seems to fix the problem. I know the 2.6 series is on its way out, but as long as it's the default kernel, I think this deserves some attention. Maybe it's only with this specific hardware. Can't check with anything else right now.
Basically the MTU on a vmbr bridged interface over a bond does not inherit a large MTU like 9000. It retains the default 1500.
The following is an example config:
vmbr1 should inherit the mtu of the underlying bond0, but with (the last two) 2.6 kernels, it stays at 1500 even though the physical eth1-3 and bond0 interfaces all show MTU:9000 in ifconfig output.
With the 3.10.0-11 kernel, vmbr1 shows the expected MTU:9000.
As an aside, I tried to boot back into the original 2.6.32-39 kernel after the manual install of 3.10.0-11. This resulted in a kernel panic on boot. I didn't bother looking at it more, so not sure if it was the dist-upgrade or the 3.10 kernel install that caused that. Had no problems booting back into the 3.10 kernel (and also 2.6.32-40 I think).
Confirmed this mtu behavior with a new install on a second system with identical hardware (didn't try to reproduce the kernel panic) by checking the mtu at each step, post install, post upgrade, and post 3.10 kernel install.
Hardware is a Supermicro X10SLM+-LN4F which has four NICs. Product page says they are (Intel) i210AT controllers.
Basically the MTU on a vmbr bridged interface over a bond does not inherit a large MTU like 9000. It retains the default 1500.
The following is an example config:
Code:
auto bond0
iface bond0 inet manual
slaves eth1,eth2,eth3
bond_miimon 100
bond_mode 802.3ad
bond_xmit_hash_policy layer3+4
pre-up ifconfig eth1 mtu 9000
pre-up ifconfig eth2 mtu 9000
pre-up ifconfig eth3 mtu 9000
post-up ifconfig bond0 mtu 9000
auto vmbr1
iface vmbr1 inet manual
bridge_ports bond0
bridge_stp off
bridge_fd 0vmbr1 should inherit the mtu of the underlying bond0, but with (the last two) 2.6 kernels, it stays at 1500 even though the physical eth1-3 and bond0 interfaces all show MTU:9000 in ifconfig output.
With the 3.10.0-11 kernel, vmbr1 shows the expected MTU:9000.
As an aside, I tried to boot back into the original 2.6.32-39 kernel after the manual install of 3.10.0-11. This resulted in a kernel panic on boot. I didn't bother looking at it more, so not sure if it was the dist-upgrade or the 3.10 kernel install that caused that. Had no problems booting back into the 3.10 kernel (and also 2.6.32-40 I think).
Confirmed this mtu behavior with a new install on a second system with identical hardware (didn't try to reproduce the kernel panic) by checking the mtu at each step, post install, post upgrade, and post 3.10 kernel install.
Hardware is a Supermicro X10SLM+-LN4F which has four NICs. Product page says they are (Intel) i210AT controllers.