[16.0] Enable automatic TCP MSS clamping for forwarded app traffic#5386
Merged
Conversation
TCP MSS clamping is now applied automatically to forwarded application traffic in EVE. This ensures that TCP connections adjust their Maximum Segment Size (MSS) to match the actual path MTU and avoid packet fragmentation. -> Why this is needed In EVE, application workloads often run inside VMs (or containers within VMs). In these environments, it is not always possible to propagate the underlying interface MTU to the application: - The app must request MTU via DHCP, or use a recent virtio driver that supports MTU propagation. - When the network instance is rerouted to a different uplink, the new MTU only takes effect after the app’s DHCP lease expires. - Containers running inside VMs may ignore the propagated MTU altogether. As a result, applications might continue sending packets larger than the real path MTU, causing fragmentation or even dropped packets if Don’t Fragment (DF) flag is set. If ICMP “Fragmentation Needed” messages are filtered, the sender cannot detect the issue, leading to retransmissions and connection stalls. -> How it works The kernel’s Netfilter subsystem automatically adjusts (clamps) the TCP MSS in SYN and SYN-ACK packets to fit the path MTU. The path MTU is determined from the output interface MTU and cached ICMP feedback (if available). Even if ICMPs are blocked, the interface MTU still provides a safe upper bound (especially when device is running at the network edge). The MSS is determined by taking the minimum of the path MTUs in both directions of the flow, ensuring packets in either direction fit the path. The MSS in the packet is only ever reduced, never increased. The calculated MSS is written into the TCP options of the packet, and the TCP checksum is automatically recalculated to reflect the change. The rule is implemented in the mangle table (FORWARD chain) using iptables: - One rule for IPv4 (iptables) - One rule for IPv6 (ip6tables) -> Configuration By default, MSS clamping is enabled for all forwarded application traffic. If necessary, it can be disabled via the global configuration property: `app.enable.tcp.mss.clamping` This allows to disable clamping in case it causes some undesired behaviour. Signed-off-by: Milan Lenco <[email protected]> (cherry picked from commit 10e402f)
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Backport of #5319
How to test and validate this PR
Reproducing a scenario where TCP MSS clamping is required to prevent dropped or fragmented packets can be tricky.
The following procedure provides one possible way to validate the fix:
ip link set mtu 1400 <port>or through the network configuration.If the application virtio driver or DHCP client automatically adopted the 1400 MTU advertised by EVE, change it back manually to 1500.
This simulates a case where MTU propagation does not occur properly.
For example, on Linux:
sudo ip route flush cacheOn another device reachable from the EVE node, start an iperf3 server:
iperf3 -sThen, on the application side, run the client:
iperf3 -c <the-server-IP>To check that EVE is not fragmenting any packets, SSH into EVE (or use the console) and run:
The packet capture during the iperf3 run should show no fragmented packets (i.e., output should be empty).
After running the test, check that the iptables rule counter has incremented:
Example output:
A non-zero counter indicates that the MSS clamping rule was triggered as expected.
Changelog notes
Enable automatic TCP MSS clamping for forwarded app traffic using the path MTU to prevent fragmentation and dropped packets; can be disabled via the configuration property
app.enable.tcp.mss.clamping.Checklist