Kubernetes MTU: Configuration, Issues & Best Practices

Key Takeaways

• MTU mismatches can silently cause dropped packets, slow applications, and unreliable networking in Kubernetes.
• Set pod MTU based on your network's encapsulation overhead instead of relying on automatic detection.
• Test MTU with real traffic, as issues often only appear with larger packets and production workloads.
• Monitor network performance continuously to catch MTU-related problems before they affect users.

Kubernetes networking is deceptively complex. Pods spin up, services resolve, and traffic flows, until it doesn't. Among the most frustrating and hardest-to-diagnose root causes is a misconfigured Maximum Transmission Unit (MTU). According to Red Hat's State of Kubernetes Security Report 2024, 27% of respondents identified misconfigurations as their top concern for container and Kubernetes environments.

MTU sits at the intersection of your physical infrastructure, your overlay network, and your CNI plugin. Get it wrong by even 50 bytes, and you're looking at intermittent packet drops, TCP stalls, and throughput that looks fine on small pings but collapses on real workloads. This guide walks through what Kubernetes MTU is, how it works, how to check and configure it, and what best practices keep clusters healthy in production.

What Is Kubernetes MTU and Why It Matters

MTU is the largest packet a network interface can send in one frame without fragmentation, defaulting to 1500 bytes on Ethernet. In Kubernetes, MTU matters because traffic crosses multiple layers (node NICs, virtual interfaces, CNI tunnels, cloud VPCs), each with its own limit, and if any link can't handle a packet's size, it either fragments or drops it.

• Fragmentation: The packet is broken into smaller pieces, reassembled at the destination, adding CPU overhead and latency.
• Silent Drop: If the "Don't Fragment" (DF) bit is set (which TCP does by default), the packet is simply discarded without notification, causing connections to stall or silently fail.

How Kubernetes MTU Works Across Nodes, Pods, and Networks

Every layer of the Kubernetes network stack has an MTU context. Here's how they relate:

• Node-level MTU: The MTU of the node's physical/virtual NIC (e.g., eth0), typically 1500 bytes on Ethernet or up to 9001 bytes with jumbo frames.
  
  
• Pod-level MTU: The MTU the CNI assigns to each pod's virtual interface, which must be ≤ node MTU to avoid fragmentation.
  
  
• Overlay network MTU: The effective pod MTU after subtracting encapsulation overhead (50–100 bytes for VXLAN/Geneve), reducing usable payload size.

The core rule is:

Pod MTU ≤ Node MTU − Encapsulation Overhead

For example, with a node MTU of 1500 and VXLAN encapsulation (50-byte overhead):

Pod MTU = 1500 − 50 = 1450

If you set the pod MTU to 1500 on a VXLAN network, every large packet from a pod will exceed the physical network's capacity, leading to fragmentation or silent drops.

Overlay Networks and Their Impact on Kubernetes MTU

Different overlay and encapsulation protocols consume different amounts of header space. The table below summarizes the overhead for the most common encapsulation types used by Kubernetes CNI plugins.

Path MTU Discovery and Its Role in Kubernetes Networking

Path MTU Discovery (PMTUD) allows hosts to automatically determine the largest packet size supported across the network path. However, in Kubernetes environments, it is often unreliable because it depends on ICMP "Fragmentation Needed" messages, which are frequently blocked, filtered, or dropped by network devices and security controls.

• Firewalls and security groups often block ICMP Type 3 messages, which silently kills PMTUD.
• Overlay tunnels can break PMTUD by hiding the actual packet size from intermediate routers.
• NAT and load balancers may interfere with ICMP responses reaching the correct source.

When PMTUD fails, an MTU black hole can occur - small packets continue to work, but larger TCP transfers stall because endpoints never learn to reduce packet size. This is why explicitly configuring MTU in your CNI plugin is usually more reliable than relying on automatic detection or ICMP-based path discovery. Setting the correct MTU upfront helps prevent hard-to-diagnose connectivity and performance issues.

‍

Common Kubernetes MTU Values Across CNIs and Cloud Environments

The right MTU value depends on your underlying infrastructure and CNI. As a quick reference: bare-metal clusters without an overlay use the standard 1500 bytes; VXLAN-based CNIs default to 1450; Geneve/Cilium targets 1440; WireGuard-encrypted overlays drop to 1420; and OpenShift/OVN-Kubernetes uses a conservative 1400. On the cloud side, AWS EKS with VPC CNI supports jumbo frames at 9001 bytes within a single VPC, GKE Dataplane V2 sits at 1460, and Azure AKS with Azure CNI uses 1500.

How to Check MTU in Kubernetes

Before tuning anything, you need to understand the current MTU state across your cluster. Here's how to inspect it at each layer.

1. Checking Node MTU

Log into a cluster node and inspect the network interface MTU:

# Check MTU on the primary network interface
ip link show eth0

# Example output:
# 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc...

Or to see all interfaces at once:

ip link show | grep mtu

For jumbo-frame environments:

cat /sys/class/net/eth0/mtu

2. Checking Pod MTU

Exec into a running pod and check its interface:

kubectl exec -it <pod-name> -n <namespace> -- ip link show eth0

# Or if ip isn't available:
kubectl exec -it <pod-name> -n <namespace> -- cat /sys/class/net/eth0/mtu

You can also run this across multiple pods using a DaemonSet or a quick loop:

for pod in $(kubectl get pods -o name); do
  echo "=== $pod ==="
  kubectl exec $pod -- ip link show eth0 2>/dev/null | grep mtu
done

3. Using kubectl and Network Tools

For a more systematic check, deploy a debug pod with network tools:

kubectl run mtu-debug --image=nicolaka/netshoot --restart=Never -- sleep 3600
kubectl exec -it mtu-debug -- bash

Inside the debug pod, test the effective path MTU using ping with the DF bit set:

# Test path MTU to another pod IP (replace with actual target IP)
ping -M do -s 1400 <target-pod-ip>

# Increase size until packets start dropping
ping -M do -s 1450 <target-pod-ip>
ping -M do -s 1500 <target-pod-ip>

The largest packet size that gets through without the "Message too long" error is your effective path MTU (add 28 bytes for IP + ICMP headers to get the true MTU).

You can also use tracepath to see the path MTU discovery in action:

tracepath <target-pod-ip>

Symptoms of Kubernetes MTU Misconfiguration in Production

MTU issues rarely announce themselves clearly. The following table maps common symptoms to their likely MTU-related causes to help you triage faster.

How to Configure Kubernetes MTU for Different CNI Plugins

Configuring the correct MTU involves three steps: identifying your node MTU, calculating the appropriate pod MTU, and updating the CNI configuration to enforce it.

Identifying Node MTU

Always start by verifying the physical network interface MTU on your nodes:

ip link show | grep -E "^[0-9]+:" | grep -v lo | grep mtu

In cloud environments, cross-reference with your provider's documentation. AWS EC2 instances use 9001 bytes within a VPC; standard VMs on GCP and Azure typically use 1460 or 1500 bytes.

Updating CNI Configuration

Most CNI plugins read their configuration from a JSON file in /etc/cni/net.d/. The MTU field is typically found there:

# View current CNI config
cat /etc/cni/net.d/10-flannel.conflist

# Update MTU field
sudo jq '.plugins[0].mtu = 1450' /etc/cni/net.d/10-flannel.conflist > /tmp/new.conflist
sudo mv /tmp/new.conflist /etc/cni/net.d/10-flannel.conflist

After updating, restart the CNI DaemonSet and verify pod interfaces pick up the new value.

CNI-Specific MTU Settings (Calico, Cilium, AWS VPC CNI)

Calico

Calico supports automatic MTU detection by default since v3.x, but you can set it explicitly via the FelixConfiguration resource:

apiVersion: projectcalico.org/v3
kind: FelixConfiguration
metadata:
  name: default
spec:
  vxlanMTU: 1450        # For VXLAN mode
  wireguardMTU: 1420    # For WireGuard encrypted mode
  ipipMTU: 1480         # For IPIP mode

Apply with:

kubectl apply -f felixconfig.yaml

You can also patch it directly:

kubectl patch felixconfiguration default \
  --type merge \
  --patch '{"spec":{"vxlanMTU":1450}}'

Cilium

Cilium reads MTU configuration from its ConfigMap. To set a custom MTU:

kubectl edit configmap cilium-config -n kube-system

Add or update:

data:
  mtu: "1440"

Then restart the Cilium DaemonSet:

kubectl rollout restart daemonset cilium -n kube-system

Alternatively, configure it at install time with Helm:

helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --set MTU=1440

AWS VPC CNI

AWS VPC CNI operates in native routing mode (no overlay), so pods use the full VPC MTU. For standard instances within a single VPC, this is 9001 bytes (jumbo frames):

# Check the current MTU setting on the aws-node DaemonSet
kubectl describe daemonset aws-node -n kube-system | grep MTU

# Set the MTU via environment variable
kubectl set env daemonset aws-node \
  -n kube-system \
  AWS_VPC_K8S_CNI_MTU="9001"

Note: If your traffic crosses VPC peering, Direct Connect, or a VPN, the jumbo frame path may not be supported end-to-end. Verify before setting 9001.

Troubleshooting Kubernetes MTU Issues and Packet Loss

When you suspect an MTU problem, work through the following sequence:

1. Confirm the Symptom Pattern

Run a quick size-escalating ping from inside a pod, small packet success followed by large packet failure is the tell-tale MTU sign:

kubectl exec -it mtu-debug -- ping -M do -s 100 <target-ip>   # Should work
kubectl exec -it mtu-debug -- ping -M do -s 1400 <target-ip>  # Should work
kubectl exec -it mtu-debug -- ping -M do -s 1500 <target-ip>  # May fail

2. Check Fragmentation Counters and Capture ICMP Signals

On the node, inspect kernel counters for fragment-related activity, high values in IpFragFails are a clear red flag:

nstat -az | grep -i frag

Then use tcpdump to look for ICMP type 3, code 4 ("Fragmentation Needed") messages. Seeing them confirms PMTUD is active; not seeing them when traffic is failing means PMTUD is being silently blocked:

bash
tcpdump -i eth0 -n 'icmp[icmptype] == icmp-unreach and icmp[icmpcode] == 4'

3. Validate CNI Config and Test Throughput End-To-End

Confirm the CNI is actually using the MTU you set, then benchmark with iperf3 between pods on different nodes:

# Verify CNI MTU
kubectl get configmap cilium-config -n kube-system -o yaml | grep mtu
kubectl exec -it <pod> -- cat /sys/class/net/eth0/mtu

# Throughput test
iperf3 -s                          # pod A
iperf3 -c <pod-a-ip> -t 30        # pod B

A correctly configured MTU should show consistent throughput scaling with payload size. Drops or stalls at larger sizes point back to an encapsulation mismatch.

Performance and Reliability Trade-Offs in Kubernetes MTU Tuning

More data means less per-packet overhead (headers, interrupts, context switches). That's why jumbo frames matter for analytics or storage-heavy workloads. But higher MTU also increases tail latency, since a single large frame takes longer to serialize than a small one. And a wrong MTU is the worst outcome: fragmentation raises CPU usage, fragment loss triggers full TCP retransmissions, and throughput collapses precisely when the system is under the most load.

The safe default for most clusters is pod MTU = node MTU minus encapsulation overhead, with an additional 10–20 byte safety buffer to absorb headers that proxies or service meshes may add dynamically. For throughput-critical workloads, test jumbo frames end-to-end before enabling them; never assume the full path supports them.

Best Practices for Managing Kubernetes MTU in Cluster Networking

The following table summarizes the key best practices, their rationale, and when to apply them.

Real-Time Visibility Into Kubernetes MTU Issues with groundcover

Diagnosing MTU problems reactively, after users report degraded performance, is expensive and disruptive. The far better approach is continuous observability that surfaces network anomalies as they emerge.

groundcover is a Kubernetes-native observability platform built on eBPF, giving you deep network visibility without the instrumentation overhead of traditional APM tools. It deploys as a lightweight DaemonSet and automatically captures network-level telemetry across every pod and service in your cluster. groundcover's BYOC (Bring Your Own Cloud) architecture means all of this telemetry, including MTU-related network data, stays inside your own cloud environment rather than being routed through a third-party SaaS backend.

For MTU-related issues specifically, groundcover helps in several ways:

• Automatic Network Performance Baselines: groundcover tracks throughput, latency, and error rates for every service-to-service connection. When a misconfigured MTU starts causing retransmissions or drops, you see it as a deviation from baseline before it escalates into an incident.
  
  
• eBPF-Based Packet-Level Visibility: Because groundcover is powered by eBPF, it can observe network events that application-level monitoring entirely misses, all without code changes or sidecar injection. Fragment-related drops, TCP retransmissions caused by oversized packets, and ICMP unreachable messages are all visible in the platform's network performance dashboards.
  
  
• Cross-Node Correlation: MTU mismatches often manifest only on certain node-to-node paths (e.g., when pods on different availability zones communicate). groundcover's topology maps make it easy to identify which specific paths are degraded, narrowing the investigation from "something is wrong with the network" to "traffic between node group A and node group B is dropping large packets."
  
  
• Alerting Without Manual Instrumentation: You don't need to pre-instrument services or add sidecar proxies. groundcover's auto-instrumentation approach means new workloads are covered automatically, including during rolling deployments or CNI upgrades when MTU misconfiguration risk is highest.

Conclusion

Kubernetes MTU seems like a minor setting until it causes problems. Even a small mismatch between pod MTU and overlay network capacity can silently degrade performance, disrupt traffic, and create hard-to-diagnose issues. A stable cluster starts with understanding your CNI’s encapsulation overhead, configuring MTU values correctly instead of relying solely on PMTUD, and validating with real traffic. Ongoing network monitoring then helps detect regressions caused by CNI upgrades, service mesh changes, or infrastructure updates.

Get the MTU right from the start, monitor continuously, and it becomes a solved configuration item rather than a source of production incidents.