I noticed downloads being particular slow when building and running containers that pull in relatively big artifacts from the internet.
As an experiment I tried running speedtest-cli (apt install speedtest-cli):
From my local machine (Ubuntu 20.04.6 LTS):
❯ speedtest-cli
Retrieving speedtest.net configuration...
Testing from Telenet (84.195.66.19)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by NewsXS B.V. (Amsterdam) [162.03 km]: 24.149 ms
Testing download speed................................................................................
Download: 255.20 Mbit/s
Testing upload speed......................................................................................................
Upload: 28.52 Mbit/s
From a docker container (ubuntu:22.04) running on the same local machine
❯ docker run -it ubuntu:22.04 /bin/bash
root@6e877f0efff1:/# apt update && apt install --yes speedtest-cli
...
root@6e877f0efff1:/# speedtest-cli
Retrieving speedtest.net configuration...
Testing from Telenet (84.195.66.19)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Claranet Benelux B.V. (Amsterdam) [162.03 km]: 2532.721 ms
Testing download speed................................................................................
Download: 2.25 Mbit/s
Testing upload speed......................................................................................................
Upload: 2.94 Mbit/s
Has anyone run into a similar issue before? And how did you resolve it?
I ran into this potential MTU Issue but I don’t think it’s it, the MTU of my default network interface is the same as the MTU of the docker interface:
❯ ip link | grep mtu
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DORMANT group default qlen 1000
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default
I run docker-ce 26.1.0 and have a 1000/200 fiber connection. I use speedtest-tracker - LinuxServer.io to measure the bandwidth. It measures roughly ~940 Mbps down and ~220 Mbps up. The download bandwidth was slightly better before I switched to an OpenWRT based router.
It’s safe to say that it’s not a general docker problem
Thanks for testing, although it doesn’t fully rule out it’s not a docker issue.
There is definitely an issue on my side, and it’s related to docker, so I suspect it might be a configuration problem
I went back to speedtest-cli and got the same results (docker container having much slower internet) as before. I run each of them a few times and the results both (speedtest being ok and speedtest-cli being slow in the container but not on my local machine seem to be consistently replicable)
This is caused by the dns setting of your host. While containers attached to the default bridge network will mount the host’s /etc/resolv.conf, containers attached to a user defined bridge network will use docker’s internal dns server, which uses the configuration from the host’s /etc/resolv.conf as upstream.
The setting you made just bypasses the default behavior, which shouldn’t be necessary if the host’s configuration is okay.
Personally, I would investigate what dns resolver was configured and fix the problem at the source. For instance, on Ubuntu I use systemd-resolved without the stub resolver, so that my /etc/resolv.conf actually points to a dns resolver available in my network. The stub resolver can be deactivated in the responsible config file in /etc/systemd/resolved.conf.d/ and then requires a restart of the service systemctl restart systemd-resolved.service.
It seems like the MTU (Maximum Transmission Unit) of both your default network interface and the Docker interface is set to 1500, which suggests that an MTU issue might not be the cause of your problem. The MTU defines the maximum size of a data packet that can be transmitted over a network interface without fragmentation.
In your case, the MTU values for both interfaces are the same:
The default network interface (wlp0s20f3) has an MTU of 1500.
The Docker interface (docker0) also has an MTU of 1500.
Since the MTU values match and are within the typical range for Ethernet networks, it’s less likely that an MTU-related issue is causing your problem.
If you’re experiencing network-related issues, it might be worth exploring other potential causes or troubleshooting steps to diagnose and resolve the issue.
Let me know if you need further assistance or if there’s anything else I can help you with!
.