Victor Clark

Docker networking

When you want to make your application portable, but Docker needs help to finish packing.

In my spare time, I develop network tests and maintain the accompanying Dockerfile. If you’re interested in my Docker backstory (by way of virtual machines (VMs) and GNU/Linux), check it out here.

The point of these network tests is to be portable enough that people can run them on any variety of platforms. Obviously Docker was a natural choice. Since Docker is an abstraction, there are different ways to do networking, but the VM stand-by of bridged, where the VM talks to the outside world by its own IP from the gateway — not to be confused with Docker's unfortunately-name bridge network driver 😐  — isn’t yet an option. Ideally, having the container’s network interface exposed directly to the LAN is the best option. I decided to to go with the host network driver. On to developing a test for layerfourtrace (LFT). Or so I thought.

One major issue that immediately popped up for LFT was network tests on Docker would not return the same results as bare metal or virtual machines; every hop beyond the host's LAN gateway was dropped. I tested: 

• Docker on Linux native (RPi/ARM)
• Docker on Linux VM on Mac
• Docker (Machine) on OSX

When using "—net=host” other tests were working, so what was the deal with LFT on Docker? Docker-machine on Mac has some network short-comings, but that was nothing a VM couldn’t fix. After sniffing around in Wireshark, I discovered the problem: probe length needed to be great than zero! Screen caps of the difference below.

But the problem didn’t end there.

LFT 2.2 shipped with the Debian base image, which does not allow changing probe length. So the Dockerfile needed updating to install LFT3.77 from LFT2.2 during build time — those releases are over a decade apart!

Next, a tiny wrinkle from LFT’s homepage:

We're no longer linking to binaries or providing builds. Please use your package manager (or ports tree) or build LFT from source.

No problem, though… after some wrangling with curl and digging through the page source, I had the download link. Here’s the updated section of the Dockerfile:

After that, then we were good to go!

Docker is incredible technology that makes deploying quicker and easier, but there’s no getting around troubleshooting and bug hunting the application —that’s a part of every developer’s job. Many different ways towards a solution, but the best option always offers the cleanest flow and is the most user friendly.