From: Daniel Axtens <d...@axtens.net> Date: Tue, 14 Nov 2017 21:32:51 +1100
> If a macvlan device which is not in bridge mode receives a packet, > it is sent straight to the lowerdev without checking against the > device's MTU. This also happens for multicast traffic. > > Add an is_skb_forwardable() check against the lowerdev before > sending the packet out through it. I think this is the simplest > and best way to do it, and is consistent with the use of > dev_forward_skb() in the bridge path. > > This is easy to replicate: > - create a VM with a macvtap connection in private mode > - set the lowerdev MTU to something low in the host (e.g. 1480) > - do not set the MTU lower in the guest (e.g. keep at 1500) > - netperf to a different host with the same high MTU > - observe that currently, the driver will forward too-big packets > - observe that with this patch the packets are dropped > > Cc: Shannon Nelson <shannon.nel...@oracle.com> > Signed-off-by: Daniel Axtens <d...@axtens.net> This is an area where we really haven't set down some clear rules for behavior. If an interface has a particular MTU, it must be able to successfully send MTU sized packets on that link be it virtual or physical. Only a "next hop" can have a different MTU and thus drop packets. This requirement is absolutely necessary in order for proper signalling (path MTU messages) to make their way back to the sending host. In this VM-->macvlan case it's more like a point to point connection and there lacks a "next hop" to serve and the provider of proper signalling. This whole situation seems to be handled quite poorly in virtualized setups. Allowing one end of the virtual networking "link" into the guest have a different MTU from the other end is a HUGE mistake. There needs to be control path signalling between the guest and the provider of the virtual link so that they can synchronize their MTU settings. Yes this is hard, but what is happening now doesn't fly in the long term.
