GRE Tunnel Calculator
Calculate GRE tunnel encapsulation overhead and effective payload MTU.
Inputs
Used only to show the max inner packet size headroom relative to typical header sizes
Effective Payload MTU (after GRE header)
1,476bytes
GRE Encapsulation Overhead
24bytes
Max Inner IP Payload (after inner IP header)
1,456bytes
Overhead as % of Physical MTU
1.60%
Step by step
Values used
Physical (Underlay) MTU = 1,500 bytes; Inner IP Version = IPv4
Effective payload MTU
effective_payload = physical_mtu − 24
Effective Payload MTU (after GRE header)
= 1,476 bytes
GRE Encapsulation Overhead
= 24 bytes
Max Inner IP Payload (after inner IP header)
= 1,456 bytes
Overhead as % of Physical MTU
= 1.60
How it works
A GRE tunnel wraps each original packet with a 4-byte GRE header and a new 20-byte outer IPv4 header, adding 24 bytes of overhead per packet (more if GRE keepalive or checksum options are enabled, which this baseline calculation excludes). Because the tunneled packet must still fit within the physical network's MTU, the effective MTU available to traffic entering the tunnel is reduced by this overhead — commonly requiring either a lower MTU configured on tunnel interfaces or path MTU discovery/fragmentation handling to avoid black-holed traffic.
Formula
Effective payload MTU
effective_payload = physical_mtu − 24
- 24
- 4 bytes GRE header + 20 bytes outer IPv4 header
Frequently Asked Questions
Why is GRE overhead only 24 bytes when VXLAN is 50?
GRE is a simpler, Layer-3 tunneling protocol — it just adds a 4-byte GRE header and a 20-byte outer IP header. VXLAN adds a full UDP transport layer (8 bytes) and preserves the original Ethernet frame with its own outer Ethernet header (14 bytes) on top of similar IP encapsulation, since VXLAN is designed to tunnel Layer-2 (Ethernet) traffic across a Layer-3 network, which GRE in its basic form does not.
What happens if I don't adjust MTU on GRE tunnel interfaces?
Full-size packets entering the tunnel may exceed the underlay's MTU once the 24-byte GRE overhead is added, causing fragmentation (if the 'don't fragment' bit is clear) or silent packet drops with an ICMP 'fragmentation needed' message that's often blocked by firewalls — leading to intermittent connectivity issues that are notoriously hard to diagnose (the classic 'MTU black hole' problem).
Does using GRE with IPsec change the overhead?
Yes — GRE-over-IPsec (a common design for routable, encrypted tunnels supporting dynamic routing protocols) stacks GRE's 24 bytes with IPsec's own ESP/AH overhead, which can add 50+ bytes total depending on the cipher and mode, so effective MTU should be calculated for the combined stack, not GRE alone.