Connecting Docker Containers to VLANs and Load Balancing with Swarm

Introduction

Beyond simple single-host networking, Docker offers ways to integrate containers directly with existing physical networks, resolve service names automatically, and balance traffic across a cluster. This article covers the macvlan driver, built-in service discovery, and Swarm's ingress load balancing.

Connecting to Existing VLANs with Macvlan

The macvlan driver gives each container its own IP and MAC address directly on an external physical network, making it appear as a real device rather than something hidden behind port mapping. This is especially useful for partially containerized applications that need to communicate with non-containerized systems.

Macvlan offers strong performance since it avoids extra bridges or port mappings, but it requires the host's network interface to run in promiscuous mode — something often disallowed on corporate networks and almost universally blocked on public clouds.

A macvlan network tied to a specific VLAN can be created like this:

docker network create -d macvlan \
  --subnet=10.0.0.0/24 \
  --ip-range=10.0.0.0/25 \
  --gateway=10.0.0.1 \
  -o parent=eth0.100 \
  macvlan100

This creates a tagged sub-interface on the host and reserves an IP range exclusively for Docker, since macvlan has no built-in mechanism to detect address conflicts. A container attached to this network becomes a fully visible participant on VLAN 100:

docker run -d --name mactainer1 --network macvlan100 alpine sleep 1d

The macvlan driver also supports VLAN trunking, allowing multiple macvlan networks on the same host to connect containers to different VLANs simultaneously.

Troubleshooting Connectivity

When networking issues arise, both daemon logs and container logs are valuable. Daemon logging verbosity can be adjusted in /etc/docker/daemon.json by setting debug and log-level. Container logs are typically viewed with:

docker logs 

or docker service logs for Swarm services, assuming the container's application logs to STDOUT and STDERR as its main process.

Service Discovery

Docker provides built-in service discovery through an embedded DNS server, allowing containers on the same network to resolve each other by name. When a container issues a request like ping c2, its local resolver queries Docker's internal DNS server, which maintains name-to-IP mappings for every container started with a --name or --net-alias flag. This resolution only works between containers sharing the same network.

Custom DNS servers and search domains can be configured per container:

docker run -it --name custom-dns \
  --dns=8.8.8.8 \
  --dns-search=nigelpoulton.com \
  alpine sh

Ingress Load Balancing in Swarm

Swarm supports two ways of publishing services externally: ingress mode (the default) and host mode. Ingress mode allows a service to be reached through any node in the cluster, even ones not running a replica, thanks to a built-in layer 4 routing mesh. Host mode, by contrast, only allows access through nodes actually running a replica:

docker service create -d --name svc1 \
  --publish published=5005,target=80,mode=host \
  nginx

With ingress mode, Docker automatically creates a special ingress network connecting every swarm node, and routes any traffic hitting the published port on any node to an available replica — balancing requests automatically when multiple replicas exist.

Conclusion

Macvlan networking, built-in service discovery, and Swarm's ingress routing mesh round out Docker's networking capabilities beyond basic single-host setups. Together, they make it possible to integrate containers with physical infrastructure, let services find each other reliably by name, and distribute traffic seamlessly across a cluster.