Merge branch 'Support-PMTU-discovery-with-bridged-UDP-tunnels'
authorDavid S. Miller <davem@davemloft.net>
Tue, 4 Aug 2020 20:01:46 +0000 (13:01 -0700)
committerDavid S. Miller <davem@davemloft.net>
Tue, 4 Aug 2020 20:01:46 +0000 (13:01 -0700)
commit2ac24d6d685cb1c0e0fbb189dc607b05720fb5d1
tree49b6306abbc5fbf8d4a25b42b46ef263fbdde33d
parentcabf06e5a275dde2a336c71536465b30ccf2ae4d
parent7b53682c94032a7a7adec400400c65d0af7fea5a
Merge branch 'Support-PMTU-discovery-with-bridged-UDP-tunnels'

Stefano Brivio says:

====================
Support PMTU discovery with bridged UDP tunnels

Currently, PMTU discovery for UDP tunnels only works if packets are
routed to the encapsulating interfaces, not bridged.

This results from the fact that we generally don't have valid routes
to the senders we can use to relay ICMP and ICMPv6 errors, and makes
PMTU discovery completely non-functional for VXLAN and GENEVE ports of
both regular bridges and Open vSwitch instances.

If the sender is local, and packets are forwarded to the port by a
regular bridge, all it takes is to generate a corresponding route
exception on the encapsulating device. The bridge then finds the route
exception carrying the PMTU value estimate as it forwards frames, and
relays ICMP messages back to the socket of the local sender. Patch 1/6
fixes this case.

If the sender resides on another node, we actually need to reply to
IP and IPv6 packets ourselves and send these ICMP or ICMPv6 errors
back, using the same encapsulating device. Patch 2/6, based on an
original idea by Florian Westphal, adds the needed functionality,
while patches 3/6 and 4/6 add matching support for VXLAN and GENEVE.

Finally, 5/6 and 6/6 introduce selftests for all combinations of
inner and outer IP versions, covering both VXLAN and GENEVE, with
both regular bridges and Open vSwitch instances.

v2: Add helper to check for any bridge port, skip oif check for PMTU
    routes for bridge ports only, split IPv4 and IPv6 helpers and
    functions (all suggested by David Ahern)
====================

Signed-off-by: David S. Miller <davem@davemloft.net>