On a VPP interface the real MTU limit is set by the NIC in the dataplane, and it depends on the driver. Only VPP knows it; the kernel side is a linux-cp tap that reports a much larger, meaningless maximum. So the kernel and the dataplane can silently end up with different MTUs, on the interface itself and on its VLAN sub-interfaces.
- Enforce the NIC's MTU limit (at commit). An MTU larger than the NIC can handle must be rejected during verification, not accepted while the dataplane quietly runs at the NIC maximum. VyOS reads the limit from VPP — a companion patch adds max mtu and driver frame overhead to show hardware-interfaces — and checks the configured MTU against it at commit, so the config always matches the dataplane. Interfaces with no physical NIC, or drivers that don't report a limit, are left unrestricted.
- Propagate MTU to VLAN sub-interfaces. An MTU set on a VLAN sub-interface must reach both its VPP dataplane sub-interface and the matching linux-cp tap (linux-cp creates the tap with MTU 0). Today only the parent is updated, so the sub-interface's control-plane side keeps the wrong MTU. A sub-interface with no MTU of its own inherits the parent's. This applies to:
- Physical (ethernet) interfaces.
- VPP logical interfaces (bond, loopback)