Why fragmentation happens, and why avoiding it matters

Every link along a network path has its own MTU, and when a packet larger than that limit tries to cross it, the packet either gets fragmented (split into smaller pieces, with reassembly overhead and, for IPv6, no fragmentation in transit at all — the sender has to handle it) or dropped outright if the "don't fragment" bit is set and the router can't comply. Tunneling protocols make this worse by wrapping the original packet in extra headers, which eats into the usable payload size without the sending application necessarily knowing anything shrank. A VPN client, VXLAN overlay, or IPsec tunnel added between two hosts can silently drop the effective MTU below what either endpoint assumes, which shows up as mysteriously stalled large transfers while small pings work fine.

This calculates the theory — verify the practice

The numbers here are well-known per-protocol overhead figures, and adding them up tells you what the MTU should be given a known stack of encapsulation. It cannot tell you what the actual path MTU is, because that depends on every device along the real route, including ones you don't control. The standard way to confirm the real number is a "don't fragment" ping sweep (e.g. `ping -M do -s <size>` on Linux) from one endpoint to the other, stepping the payload size down until it stops failing — that empirical result is what should ultimately drive an interface's configured MTU, with this calculator used to sanity-check the arithmetic beforehand.