Home › Networking › MTU Calculator

MTU & Encapsulation Calculator

Stack up what the packet is wrapped in. It totals the overhead, says what payload survives, and tells you the underlay MTU a full-sized inner packet actually needs.

Local toolYour network plan stays in your browser. Nothing you enter is uploaded, logged, or sent to any server.

Encapsulation

Where the numbers come from

Every figure is a named profile rather than a magic constant, and the table shows which profile contributed what. An MPLS label is four bytes. An IPv4 header is twenty. A VLAN tag is four, and QinQ adds another four.

The IPsec figure is approximate and is marked as such. ESP overhead varies with the cipher, the key size, the padding needed to reach a block boundary, and whether NAT traversal wraps it in UDP. A single number cannot be exact, and a tool implying otherwise is the reason people size tunnels wrongly. Use it as a planning figure and confirm against the devices involved.

Ethernet framing is separate from MTU. The 1500-byte figure is the payload an Ethernet frame carries, not the frame size. Whether to count the 14-byte header depends on what your equipment means by MTU, which differs between platforms — so it is listed as its own line and you can include or exclude it deliberately.

What actually goes wrong. A path that cannot carry a full-sized packet relies on fragmentation or on path MTU discovery. Fragmentation is a performance problem; path MTU discovery relies on ICMP messages that many networks filter, and when they are filtered the result is a connection that completes its handshake and then hangs on the first large transfer. That symptom — small things work, large things do not — is nearly always MTU.

Why an MTU problem never looks like an MTU problem

The characteristic symptom is a connection that establishes perfectly and then hangs. A session opens, the greeting arrives, a small command works — and then the first large response stops dead. A web page returns headers and no body. A file transfer negotiates and transfers nothing.

The reason is that everything small enough to fit gets through, and only oversized packets are lost. Handshakes are small; payloads are not. So the connection appears healthy right up to the moment it needs to carry something, which points suspicion at the application rather than the path. Any fault where size predicts success is worth treating as an MTU question first.

The blackhole is usually filtered ICMP

The mechanism that is supposed to prevent this is Path MTU Discovery: the sender marks packets not to be fragmented, and any router that cannot forward one returns an ICMP message saying so, along with the size that would fit. The sender adjusts and the connection continues.

That depends entirely on the ICMP message arriving. Where a firewall drops ICMP wholesale — still a common default, on the theory that ICMP is a security risk — the sender is never told, so it retransmits the same oversized packet indefinitely and the connection simply stalls. This is the classic PMTUD blackhole, and it is why "we block ICMP" and "large downloads hang for some customers" are so often the same finding. Permitting ICMP type 3 code 4 is the specific exception that fixes it without opening anything else.

Related tools

Label Stack Visualizer shows where those labels come from. Subnet Calculator for the addressing.