I was playing around with the good old ping command in an alpine Docker container today. I wanted to perform a little load test for another service so I experimented with different package sizes (ping -s <size in byte>), which caused me quite a bit of MTU-related frustration (but that’s a different story).
Upon googling about pings from docker, I stumbled across this forum post.
I will let you read the post yourself instead of copying everything in here, but the essence is: ping packets may return to you even if you send the pings to a non-existing host.
And it’s true. I took a random IP and made sure it’s not actually ping-able from my desktop.
$ ping 11.12.13.14 -c 5PING 11.12.13.14 (11.12.13.14): 56 data bytesRequest timeout for icmp_seq 0Request timeout for icmp_seq 1Request timeout for icmp_seq 2Request timeout for icmp_seq 3^C--- 11.12.13.14 ping statistics ---5 packets transmitted, 0 packets received, 100.0% packet loss
Then ran it from inside a Docker container.
$ docker run alpine ping 11.12.13.14 -c 5PING 11.12.13.14 (11.12.13.14): 56 data bytes64 bytes from 11.12.13.14: seq=0 ttl=37 time=0.447 ms64 bytes from 11.12.13.14: seq=1 ttl=37 time=0.469 ms64 bytes from 11.12.13.14: seq=2 ttl=37 time=0.524 ms64 bytes from 11.12.13.14: seq=3 ttl=37 time=0.476 ms64 bytes from 11.12.13.14: seq=4 ttl=37 time=0.461 ms
--- 11.12.13.14 ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max = 0.447/0.475/0.524 ms
This is bad news, because it means you can’t really trust ping anymore. You might have a health-check that tests connectivity to one of your production services through pings and keeps reporting green even though the service is down.
To make matters worse, it doesn’t happen for all fake IPs and the forum post was created over a year ago.
The good news is, this only happens for Docker on MAC (maybe Windows as well), but not Linux.
Screenshot of the “ghost ping”.