MTU and the VXLAN tunnel
Pod traffic between nodes travels inside a VXLAN overlay, and that wrapping shrinks the MTU (maximum transmission unit), the largest packet a link will carry. You do not configure any of this. Knowing why the pod-network MTU is smaller than the link MTU keeps a class of symptoms from looking like random failures: when large transfers stall while small requests succeed, the overlay is the first thing to examine, and this page shows where.
Why there is an overlay#
Nodes run on the public internet with no private network between them, so Cilium builds its own network on top. It carries each pod packet inside a VXLAN packet, a UDP packet on port 8472, sent from node to node. The receiving node unwraps it and delivers the original packet to the pod. Cilium does this in the kernel with eBPF, and there is no kube-proxy; a node can reach any pod IP directly.
Overlay overhead and MTU#
Wrapping a packet adds bytes, so the space left for your pod's own data is smaller than the raw link MTU. Cilium accounts for this automatically: it detects the underlying MTU and sets the pod interfaces so packets fit after the VXLAN header is added. Because the platform manages the MTU, you do not set it, and you should not attempt to. A manually set MTU that ignores the overlay is what causes the problems below.
If you turn on WireGuard encryption for cross-node pod traffic , each packet also gets a WireGuard header, which takes a little more of the MTU. Cilium accounts for that too.
The VXLAN header adds 50 bytes to every packet: an outer Ethernet, IP, and UDP header plus the VXLAN header itself. On a 1500-byte link that leaves the pod interfaces at 1450. Enable WireGuard and each packet carries its encryption header too, so Cilium lowers the pod MTU further. You never perform this arithmetic yourself, since Cilium reads the link MTU and sets the pod side to match, but it explains why the number your pod sees is lower than the one on the node's own interface.
What an MTU mismatch looks like#
When something along the path cannot carry a full-size wrapped packet and the packet cannot be fragmented, large payloads silently fail while small ones succeed. Typical signs:
- A
curlof a small response works, but a large download or upload stalls and then times out. - A TLS handshake completes (small packets), but the first big response hangs.
- One app's bulk transfers fail between two specific nodes.
Because Cilium manages the MTU, a genuine mismatch usually points to something on the path between nodes, not to cluster configuration. Start with Debug node networking and a Cilium connectivity test .
A VPN to on-prem or another VPC is the other place this appears. That tunnel wraps traffic in its own header on top of the overlay, so its MTU must leave room for both. See Connect to on-prem or another VPC when you set one up.
Bandwidth shaping#
Cilium's bandwidth manager shapes pod egress with the BBR congestion-control algorithm, which sustains throughput better than the default across the kind of lossy, long-distance paths typical of the public internet. It is on by default and requires no change to your pods.
Configure pod and service subnets
Set the pod and service CIDRs before you create a cluster, because they are fixed at creation and cannot change afterward.
Connect to on-prem or another VPC
Reach a private network, on-prem site, or another cloud VPC from the cluster over a VPN, planning IP ranges so nothing overlaps.