Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automated cherry pick of #5880: Fix incorrect MTU configurations (#5880) #5926: Ensure MTU is set correctly when WireGuard interface already #5997: Use 65000 MTU upper bound for interfaces in encap mode #6145

Conversation

tnqn
Copy link
Member

@tnqn tnqn commented Mar 25, 2024

Cherry pick of #5880 #5926 #5997 on release-1.13.

#5880: Fix incorrect MTU configurations (#5880)
#5926: Ensure MTU is set correctly when WireGuard interface already
#5997: Use 65000 MTU upper bound for interfaces in encap mode

For details on the cherry pick process, see the cherry pick requests page.

hjiajing and others added 2 commits March 25, 2024 18:32
The commit fixes 3 incorrect MTU configurations:

1. When using the WireGuard encryption mode, the Pod eth0's MTU was not
correct. The MTU deducted Geneve overhead because the default tunnel
type is Geneve while it should deduct the WireGuard overhead as traffic
will be encrypted instead of encapsulated.

2. When using the GRE tunnel type, the Pod eth0's MTU was not correct.
The actual overhead is 14 outer MAC, 20 outer IP, and 8 GRE header
(4 standard header + 4 key field), summing up to 42 bytes.

3. When enabling Wireguard for Multicluster, the MTU of all Pod
interfaces and wireguard interface were reduced 130 bytes (50 for
geneve + 80 for wireguard), however, cross-cluster traffic sent from
Pods were not forwarded by wireguard interface. This is because traffic
originated from Pods will be encapsulated on gateway Node, and it's the
encapsulated packet which will be encrypted. If the wireguard interface
is set with the same MTU as the Pod interface, the encapsulated packet
will exceed wireguard interface's MTU.

Signed-off-by: Jiajing Hu <hjiajing@vmware.com>
Signed-off-by: Quan Tian <qtian@vmware.com>
Co-authored-by: Quan Tian <qtian@vmware.com>
…ntrea-io#5926)

In ce46eb1 ("Fix incorrect MTU configurations"), we changed
WireGuard interface's MTU in IPv4 case. However, if a cluster already
enables WireGuard, the WireGuard interface's MTU would remain unchanged
while new Pod would use a higher MTU, causing problems.

Signed-off-by: Quan Tian <qtian@vmware.com>
@tnqn tnqn added the kind/cherry-pick Categorizes issue or PR as related to the cherry-pick of a bug fix from the main branch to a release label Mar 25, 2024
OVS configures the MTU for tunnel ports to 65000.
In some cases (e.g., Kind clusters), the MTU of the transport interface
can be larger than that, and so can be the calculated MTU of antrea-gw0
and of Pod interfaces. When this happens, packets can be dropped.
To handle this edge case (real clusters are unlikely to use that kind of
MTU), we set an upper bound of 65000 for the calculated MTU.

Note that setting the tunnel port's MTU to 65535, or even to the
calculated MTU, is not an option, as it may not work on all systems.

An alternative would be to find the MTU for the tunnel interface
dynamically and use that as an upper bound, rather than rely on this
hardcoded constant (65000). However, that constant has remained
unchanged for 7 years, and finding the MTU dynamically would require
re-organizing the Agent initialization code, as we currently caclulate
the MTU before creating the OVS tunnel port. So the current solution
seems lower risk. Even if the constant is changed in OVS, it should not
have any real impact on Antrea.

Fixes antrea-io#5940

Signed-off-by: Antonin Bas <antonin.bas@broadcom.com>
@tnqn tnqn force-pushed the automated-cherry-pick-of-#5880-#5926-#5997-upstream-release-1.13 branch from f0fbff7 to 728aa36 Compare March 25, 2024 13:25
@tnqn
Copy link
Member Author

tnqn commented Mar 25, 2024

/test-all

@tnqn tnqn merged commit f423a4b into antrea-io:release-1.13 Mar 26, 2024
47 of 50 checks passed
@tnqn tnqn deleted the automated-cherry-pick-of-#5880-#5926-#5997-upstream-release-1.13 branch March 26, 2024 03:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/cherry-pick Categorizes issue or PR as related to the cherry-pick of a bug fix from the main branch to a release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants