How to Change a Docker Container’s MTU

1. Overview

Docker is a platform that packages applications and their dependencies into lightweight containers. These containers use virtual Ethernet interfaces to communicate over networks, inheriting their MTU (Maximum Transmission Unit) settings from the underlying Docker network or host system. When MTU values are inconsistent, whether between containers, hosts, or external infrastructure, it can lead to issues like dropped packets, failed connections, or degraded performance.

In this tutorial, we’ll look at how to change MTU settings in a Docker container. We’ll cover how to apply global changes through the Docker daemon, set MTU values for custom bridge networks, and adjust them manually for specific containers.

2. Understanding MTU and Docker Networking

3. Changing Docker MTU

3.1. Configuring MTU via the Docker Daemon

{
  "mtu": 1400
}

After updating the file, let’s restart the Docker service:

$ sudo systemctl restart docker

New containers launched after this point will use the specified MTU. Existing containers will continue using the MTU they were created with and should be recreated to reflect the update.

This method ensures consistency of the MTU value across all containers connected to the default bridge on the host.

3.2. Setting MTU on a Custom Docker Network

For finer control, Docker allows creating custom bridge networks with specific MTU settings using the –opt flag:

$ docker network create \
  --driver=bridge \
  --opt com.docker.network.driver.mtu=1400 \
  custom-net

Let’s verify the MTU in a container attached to this network:

$ docker run --rm --net custom-net alpine ip link show eth0
3: eth0@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP mode DEFAULT group default

This output confirms the MTU setting for eth0, reflecting the custom configuration.

3.3. Changing MTU at Container Runtime

$ docker run -it --rm --cap-add=NET_ADMIN alpine /bin/sh

Then, we run the following command inside the container:

$ ip link set dev eth0 mtu 1400

It’s important to note that this MTU change applies only to the current session and will reset when the container stops. This approach is best suited for temporary adjustments or when troubleshooting connectivity issues in one-off cases.

4. Verifying MTU Settings

Regardless of whether the MTU is set through the Docker daemon or a custom network, confirming that the configuration is in effect remains essential. Verifying MTU settings ensures that containers communicate using the expected packet size, which helps avoid fragmentation or connection issues.

One reliable way to check this is by inspecting the container’s network interface using the ip link command. This approach provides a direct view of the MTU applied inside the container and helps catch discrepancies early.

We can check this, for example, in an Alpine container:

$ docker run --rm alpine ip link show eth0
3: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP mode DEFAULT group default

In this output, the mtu 1400 part shows the actual MTU in use for the container’s eth0 interface. This value should match the one configured earlier. If it doesn’t, it could indicate a misconfiguration or an override from a different Docker network setting. Regularly checking this helps catch such issues early, especially when working across varying environments like local setups, VPNs, or cloud platforms.

5. Detecting MTU Mismatches Between Host and Container

MTU mismatches between a container and its host or surrounding network can cause subtle issues like slow HTTP responses, TLS failures, or timeouts, especially over tunnels or overlay networks.

To test for these problems, we can use the ping command with the Don’t Fragment flag (-M do), which tells the network to drop packets that exceed the path MTU instead of fragmenting them:

$ ping -c 4 -s 1472 -M do <destination-ip>

The -s 1472 option sets the payload size, and when combined with 28 bytes of IP and ICMP overhead, the total packet size reaches 1500 bytes, the default Ethernet MTU. If the ping fails, the path likely supports a lower MTU. Reducing the size gradually helps identify the maximum allowed MTU.

For deeper inspection, tools like tcpdump, iftop, or ethtool can help spot dropped packets and retransmissions caused by mismatched values.

6. Best Practices

• Set MTU at the Docker daemon level for consistency: Defining the MTU in the Docker daemon config ensures all containers using the default bridge network start with the correct value. This avoids mismatches and reduces issues like packet drops, especially when working with VPNs or overlay networks
• Use custom networks for segmented MTU control: When containers need different MTU settings, for instance, internal traffic versus external endpoints, creating custom Docker networks with specific MTU values gives better control. This keeps each container operating with the right settings without affecting the host or other networks
• Avoid one-off runtime changes in production: Manually changing MTU inside a running container might help for testing, but the setting won’t persist after a restart. Using this in production makes the setup harder to manage and less predictable. It’s best reserved for quick debugging or temporary use
• Verify MTU values regularly: After configuring MTU, it’s important to confirm that it’s applied. Tools like ip link show, ping -M do, and tcpdump help check the MTU on container interfaces and spot mismatches early. This is especially useful across environments like on-premises, cloud, or VPNs, where network setups can differ.
• Align container MTU with host and infrastructure limits: MTU mismatches between containers, hosts, or network paths can cause hard-to-diagnose issues. Docker’s MTU should not exceed the host’s interface limits. In setups involving tunnels or overlays, always match MTU to the lowest size across the path to avoid packet loss and maintain performance.

7. Conclusion