Change Details

VPP supports a maximum MTU of 9000 on regular (ethernet-type) interfaces — physical ports, loopback, bridge, bond, and L2 VXLAN. Tunnel interfaces (GRE, IPIP, L3 VXLAN) default to 9000 as well; their effective MTU is limited by the underlying transport. - Enforce the 9000 MTU limit. Setting an MTU above 9000 on a VPP interface should be reported clearly at commit time, instead of being accepted while the dataplane runs at 9000. This means limiting the MTU range in the CLI to 9000 for VPP interface types and validating it during commit, so the configuration always matches the running dataplane. - Propagate MTU to VLAN sub-interfaces. When an MTU is set on a VLAN sub-interface (vif / vif-s), it should be applied to the matching Linux control-plane interface as well. Today the MTU is applied to the parent interface only, so a sub-interface's control-plane side can be left with an incorrect MTU. (Q-in-Q vif-c is excluded — it is not supported under VPP.)

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)

On a VPP supports a maximuminterface the real MTU of 9000 on regular (ethernet-type) interfaces — physical ports, loopback, bridgelimit is set by the NIC in the dataplane, bond,and it depends on the driver. and L2 VXLAN.Only VPP knows it; Tunnel interfaces (GREthe kernel side is a linux-cp tap that reports a much larger, IPIP,meaningless maximum. L3 VXLAN) default to 9000 as well;So the kernel and the dataplane can silently end up with different MTUs, their effective MTU is limited by the underlying transporton the interface itself and on its VLAN sub-interfaces. - Enforce the 9000 MTU limit. Setting an MTU above 9000 on a VPP interface should be reported clearly at commit time, instead of being accepted while the dataplane runs at 9000. This means limiting the MTU range in the CLI to 9000 for VPP interface types and validating it during commit, so the configuration always matches the running dataplane# **Enforce the NIC's MTU limit** (at commit). - Propagate MTU to VLAN sub-interfacesAn 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). When an MTU is set on a VLAN sub-interface (vif / vif-s)Today only the parent is updated, it should be applied to the matching Linuxso the sub-interface's control-plane interface as wellside keeps the wrong MTU. Today theA sub-interface with no MTU is applied toof its own inherits the parent interface only,nt's. so a sub-interface's control-plane side can be left with an incorrect MTU.This applies to: - Physical (ethernet) interfaces. - VPP logical interfaces (bond, (Q-in-Q vif-c is excluded — it is not supported under VPP.)loopback)