MTU & MSS
Most important commands to remember
ip link show— inspect configured interface MTUs.ss -tin state established— inspect TCP transport sizing for existing connections.
Commands and flags
| Command or option | Meaning |
|---|---|
ip link show |
Display link configuration, including mtu in bytes. |
ss -tin state established |
Select TCP (-t), internal details (-i), numeric endpoints (-n), and established state. |
These commands inspect existing links and sockets without changing packet-size limits.
The concepts that matter
1. MTU limits the packet carried by a link
The Maximum Transmission Unit (MTU) is a link’s upper limit for the network-layer packet it carries. For a common Ethernet MTU of 1500, the 1500 bytes include the IP header and payload, not the Ethernet header.
MTU is a size, not speed or bandwidth. A larger value can reduce per-byte overhead for suitable traffic, but every relevant part of the path must support the resulting packets.
2. The path is limited by its smallest usable link
Path MTU is the largest packet size that can traverse the current path without IP fragmentation. Tunnels add outer headers, reducing the room available for an inner packet even when physical links keep the same MTU.
Classic discovery uses network feedback: IPv4 can report fragmentation needed when a packet has Don’t Fragment set; IPv6 routers report Packet Too Big rather than fragmenting forwarded packets. A path can change, so the usable size is not permanently fixed.
3. MSS concerns TCP payload, not the whole packet
TCP’s Maximum Segment Size (MSS) expresses how much TCP data a peer is willing to receive in a segment. Each side advertises its own receive MSS during connection setup. The sender also accounts for path constraints.
With MTU 1500 and no extra headers, 20 bytes of IPv4 header plus 20 bytes of TCP header leave 1460 data bytes. IPv6’s base header is 40 bytes, leaving 1440. These are explanatory calculations, not universal settings; options and encapsulation affect the usable space.
4. A successful small exchange can hide a size problem
A handshake or tiny request can fit while later data packets exceed the usable path size. If necessary feedback is lost and the sender cannot adapt, the transfer may stall. Packetization-layer discovery can probe usable sizes without relying only on ICMP feedback.
MSS adjustment can help TCP across some tunnels, but it does not fix oversized UDP traffic or every path problem. Diagnose where overhead and limits arise rather than assuming that lowering every interface MTU is the right remedy.
One small example
Optional: run these read-only commands in a Linux terminal. An existing SSH connection may provide a TCP socket to inspect.
ip link show
ss -tin state established
In the link output, compare mtu values with interface names. A large loopback MTU is local configuration, not evidence that your external network supports packets that large.
In TCP details, look for fields such as pmtu, mss, or advmss when available. These are byte-sized transport or path values; rtt is time and cwnd is expressed in segments. Different connections can have different values.
An empty established list or missing fields is valid. This example does not change MTU, generate large packets, or demonstrate a failure. No cleanup is needed.
Keep this idea: MTU sizes the IP packet, MSS sizes TCP data, and the path plus encapsulation decides what fits.