There are existing deployments where a vxlan or geneve interface is part
of a bridge.
In this case, MTU may look like this:
bridge mtu: 1450
vxlan (bridge port) mtu: 1450
other bridge ports: 1450
physical link (used by vxlan) mtu: 1500.
This makes sure that vxlan overhead (50 bytes) doesn't bring packets over the
1500 MTU of the physical link.
Unfortunately, in some cases, PMTU updates on the encap socket
can bring such setups into a non-working state: no traffic will pass
over the vxlan port (physical link) anymore.
Because of the bridge-based usage of the vxlan interface, the original
sender never learns of the change in path mtu and TCP clients will retransmit
the over-sized packets until timeout.
When this happens, a 'ip route flush cache' in the netns holding
the vxlan interface resolves the problem, i.e. the network is capable
of transporting the packets and the PMTU update is bogus.
Another workaround is to enable 'net.ipv4.tcp_mtu_probing'.
This patch series allows to configure vxlan and geneve interfaces
to ignore path mtu updates.
This is only useful in cases where the vxlan/geneve interface is
part of a bridge (which prevents clients from receiving pmtu updates)
and where all involved links are known to be able to handle link-mtu
sized packets.
Florian Westphal (3):
udp_tunnel: allow to turn off path mtu discovery on encap sockets
vxlan: allow to disable path mtu learning on encap socket
geneve: allow disabling of pmtu detection on encap sk
drivers/net/geneve.c | 59 ++++++++++++++++++++++++++++++++++++----
drivers/net/vxlan.c | 65 ++++++++++++++++++++++++++++++++++++++------
include/net/ipv6.h | 7 +++++
include/net/udp_tunnel.h | 2 ++
include/net/vxlan.h | 2 ++
include/uapi/linux/if_link.h | 2 ++
net/ipv4/udp_tunnel_core.c | 2 ++
net/ipv6/ip6_udp_tunnel.c | 7 +++++
8 files changed, 131 insertions(+), 15 deletions(-)
