What an MTU measures
The maximum transmission unit, or MTU, is the largest network-layer packet a link can carry in one frame. On a conventional Ethernet link, the commonly used MTU is 1,500 bytes. That figure refers to the IP packet, not the entire Ethernet frame: the frame also has its own header and other link-layer overhead.
An IP packet contains headers as well as application data. For example, an IPv4 packet with a 20-byte IP header and a 20-byte TCP header has room for up to 1,460 bytes of TCP data within a 1,500-byte MTU, assuming no additional IP or TCP options. This TCP data limit is closely related to the maximum segment size, or MSS. Options, encryption, and encapsulation can reduce the space available for data, so 1,460 is an example rather than a universal setting.
Why a packet can fit one link but not another
A packet may cross several kinds of links between sender and receiver. Each link can have a different MTU, and the smallest usable MTU along the route constrains the size of a packet that can pass without being split or rejected. This limit is called the path MTU.
Tunnels make the distinction especially important. A VPN or another encapsulation method wraps an existing packet in extra headers. If the outer packet must still fit within a 1,500-byte link MTU, the inner packet has less than 1,500 bytes available. A configuration that works on an ordinary connection may therefore fail or perform poorly when traffic enters a tunnel.
Think of a parcel placed inside a second box. Even if the parcel fits through a doorway on its own, the larger box may not. Lowering the size of the inner packet leaves room for the wrapper; increasing the outer link’s MTU is another possibility only when the relevant network equipment supports it.
Fragmentation is different in IPv4 and IPv6
In IPv4, a router can fragment an oversized packet if fragmentation is permitted. It creates smaller fragments that travel onward and are reassembled at the destination. Fragmentation adds processing and header overhead. If any fragment is lost, the complete original packet cannot be reassembled, which may force higher-layer protocols to recover or cause the packet to be discarded.
IPv4 senders can set the Don’t Fragment (DF) flag. When a router encounters a packet that is too large for the next link and DF is set, it drops the packet and should return an ICMP message indicating that fragmentation is needed. This feedback can help the sender choose a smaller packet size.
IPv6 routers do not fragment packets in transit. Instead, a router that cannot forward an oversized IPv6 packet drops it and sends an ICMPv6 Packet Too Big message. The sender can then send smaller packets; IPv6 source hosts can also use a Fragment header when needed. In both protocols, avoiding unnecessary fragmentation is generally preferable to relying on it as the normal way to move traffic.
How senders learn the right size
Path MTU discovery uses network feedback to find a packet size that can traverse the route. A sender tries a size and adjusts when it receives an appropriate ICMP error about an oversized packet. Packetization Layer Path MTU Discovery, often shortened to PLPMTUD, can instead use feedback from the transport or application layer to test packet sizes, reducing dependence on ICMP messages.
Trouble arises when the sender keeps transmitting packets that are too large but does not receive, or cannot act on, the feedback. Some small exchanges may succeed while larger transfers stall. For instance, a connection might open and a short request might work, yet a larger response might hang. That pattern suggests an MTU issue, but it is not proof: congestion, filtering, and other faults can produce similar symptoms.
A practical way to investigate
Start by identifying where the failure occurs. Compare a working path with a failing one, particularly if the problem appears only over a VPN, tunnel, or particular connection. Check the configured MTU on each relevant interface and account for tunnel overhead. Remember that the size reported by a ping tool may describe its payload, not the complete IP packet; the tool’s options and protocol determine what its number means.
Where permitted, test several packet sizes with fragmentation disabled and observe which sizes receive replies. Interpret timeouts cautiously because a device may filter test traffic even when ordinary traffic works. Packet captures and interface counters can provide more useful evidence, including ICMP fragmentation-needed or Packet Too Big messages.
A fix should address the actual constraint rather than simply choosing a very small MTU everywhere. Depending on the network, options may include correcting a tunnel MTU, ensuring necessary ICMP feedback can pass, or adjusting TCP MSS so TCP connections send segments that fit the path. After any change, test both small and large transfers: the goal is reliable delivery without giving up more packet capacity than necessary.
