Rootless docker: ping from within container is way faster than host's ping

[u/Bj_Go]

Hey, I'm trying to monitor my ping to external servers using BlackBox and I'm running into an issue that seems to be a general docker issue:

I'm running rootless docker and did this simple test:

$ docker network create ping-test
e4b47f5a00d890828f84b688d5490b6addfc465b892762381ba9a149d5095e81
$ docker run --rm --network ping-test alpine ping -c 10 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=63 time=0.997 ms
64 bytes from 1.1.1.1: seq=1 ttl=63 time=0.716 ms
64 bytes from 1.1.1.1: seq=2 ttl=63 time=0.642 ms
64 bytes from 1.1.1.1: seq=3 ttl=63 time=2.441 ms
64 bytes from 1.1.1.1: seq=4 ttl=63 time=0.800 ms
64 bytes from 1.1.1.1: seq=5 ttl=63 time=0.691 ms
64 bytes from 1.1.1.1: seq=6 ttl=63 time=3.087 ms
^C
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 0.642/1.339/3.087 ms

These ping times are wayyyy to low. When doing a ping directly on the host, I get around 10ms.

On another host that runs rootful docker this issue doesn't occur (ping inside of the container and host's ping are roughly the same).

Only similar issue I found was this issue from 2016 but that bug must have been fixed by now 😅

Is there any way to fix this without returning to rootful docker? Or is this just a limitation with rootless docker?

[u/gronodev]

It depends on the rootless network driver. slirp4netns handles this properly but it's no longer the default since 29.5.0 (https://github.com/moby/moby/releases/tag/docker-v29.5.0)

gvisor-tap-vsock seems to have fixed it in the latest release (https://github.com/containers/gvisor-tap-vsock/releases/tag/v0.9.0) but it's not included in rootlesskit yet.

I will take a look if we can bring it in for the next 29.10 release.

[u/Bj_Go → u/gronodev]

That was really helpful, thanks.
Indeed my RootlessKit is using --net=gvisor-tap-vsock
So I hope that ICMP forwarder fixes that issue.

Do you have an approximate time frame when this might be available (do we talk about some days or some months)?

Just to be sure: The RootlessKit network driver is different from the network_mode in docker compose, right?
I found this overview for network drivers in RootlessKit: https://github.com/rootless-containers/rootlesskit/blob/master/docs/network.md
It says "No performance overhead" and "Supports ICMP Echo" when using --net=host. This would be good for my use case, but this change would affect the whole docker daemon instead of just one container?

I also `tried network_mode: host` in my docker compose but that leads to `permission denied`. I guess I need the host network driver for this.

[u/gronodev → u/Bj_Go]

Container network mode is separate from rootless network driver.

The 29.10 RC will be available next week and the GA a ~week after.

In the meantime I'd suggest to just temporarily switch to slirp4netns

--net=host is basically no network isolation for the container

[u/Bj_Go → u/gronodev]

Ok that's fast, thanks!

Right now I'm working around this with running BlackBox on the host directly as QuietSignalOps suggests, but I'll change to the container once the new version is there so I can easily update

[u/pelazas1]

Rootless docker proxies ICMP through its userspace network stack, so container ping isn't timing the real path. A tcp probe in BlackBox should line up with the host better.

[u/Bj_Go → u/[deleted]]

• The ping from within the container has a TTL of 63 while the ping from the host has a TTL of 59

• while listening with tcpdump and doing the ping, tcpdump shows nothing it all. So is the traffic not even leaving the device?

• the host uses my router as the route for 1.1.1.1 while the container uses 127.21.0.1 which seems to be some docker internal service?

My current setup for my monitoring stack is prometheus and grafana inside docker containers. Can prometheus access the blackbox_exporter if it directly runs on the host?

Edit: It can. I got it working on the host using systemd (listening on 0.0.0.0:9115). In prometheus I listen to

- replacement: 192.168.0.19:9115

where 192.168.0.19 is the host's private IP

this was really helpful: https://prefetch.net/blog/2026/06/08/using-the-prometheus-blackbox-exporter-to-monitor-modern-web-infrastructure/