Container Networking: Bridge, macvlan, and Overlay Compared

1. How the default bridge network works

The bridge driver is the default in both Docker and Podman and is built on a Linux bridge, a virtual layer 2 switch inside the kernel that every container attaches to through a virtual ethernet pair (veth). One side of that veth pair sits inside the container's network namespace as eth0, while the other side hangs off the bridge on the host as a port, typically docker0 or a user defined bridge per network.

Containers on the same bridge get private IP addresses from an internally managed subnet and reach each other directly over layer 2, while outbound access runs through NAT: the host translates outgoing traffic to its own IP via an iptables MASQUERADE rule, and inbound traffic has to be explicitly forwarded through port publishing (-p 8080:80). This is simple to set up and works practically everywhere, but it costs an extra NAT translation per packet and hides the actual container IP from the rest of the network.

# Create a custom bridge network and attach a container
docker network create --driver bridge --subnet 172.20.0.0/24 shop-net
docker run -d --name shop-php --network shop-net -p 127.0.0.1:9000:9000 php-fpm:8.4

# Inspect the bridge and veth pairs on the host
ip link show type bridge
bridge link show

2. macvlan: its own MAC address and its own IP on the physical network

The macvlan driver skips NAT and the internal bridge entirely: every container gets its own, kernel generated MAC address and attaches directly to the host's physical network interface, as if it were a standalone device on the same subnet. That means a container can be assigned a regular IP address from the production network, visible and reachable by every other host on the same layer 2 segment, with no port publishing or NAT translation involved.

That eliminates NAT overhead entirely and makes containers just as visible in network monitoring as physical servers, which regulated environments with strict per IP firewall rules often require explicitly. The cost is reduced flexibility: in most default configurations, macvlan containers cannot talk directly to the host itself, because the kernel blocks traffic between the physical interface and its own macvlan children by default, a behavior known as macvlan bridge isolation that can only be worked around with an additional macvlan interface on the host.

# Create a macvlan network directly on the physical interface eth0
docker network create -d macvlan \
  --subnet=192.168.10.0/24 --gateway=192.168.10.1 \
  -o parent=eth0 shop-macvlan

# Start a container with a fixed IP from the production subnet
docker run -d --name shop-web --network shop-macvlan \
  --ip=192.168.10.50 nginx:1.27-alpine

3. The macvlan host communication pitfall and its fix

Because the host cannot talk directly to its own macvlan children by kernel design, a naive ping from the host to a macvlan container fails regularly, which causes confusion in practice since that same container is reachable without any issue from every other host on the network. The standard fix is to create an additional macvlan interface on the host itself, sitting on the same subnet but treated as a separate layer 2 device.

That additional interface gets its own IP outside the container range and then correctly communicates both with the host and with all macvlan containers, since traffic in that case actually travels over the physical network instead of being short circuited internally in the kernel. For monitoring systems that need to run health checks against container IPs from the same host, this workaround is practically indispensable.

# Additional macvlan interface on the host for host-to-container communication
sudo ip link add macvlan-shim link eth0 type macvlan mode bridge
sudo ip addr add 192.168.10.9/24 dev macvlan-shim
sudo ip link set macvlan-shim up

# Now reachable from the host
ping -c1 192.168.10.50

4. Overlay networks for multi host communication

Both bridge and macvlan are fundamentally limited to a single host: containers on different machines cannot reach each other directly through these drivers, unless the host itself explicitly forwards traffic. Overlay networks solve this problem by spanning a virtual layer 2 network across multiple physical hosts, implemented technically via VXLAN encapsulation, where every layer 2 frame gets wrapped inside a UDP packet and carried over the underlying physical network to the destination host.

In Docker Swarm or Kubernetes, the overlay driver handles this encapsulation transparently: containers on host A and host B that belong to the same overlay network see each other as if they were on the same local subnet, regardless of how many physical network segments the actual traffic crosses. This additionally requires a key value store or a built in gossip mechanism to synchronize network state between the participating hosts.

# Create an overlay network inside a Docker Swarm cluster
docker network create -d overlay --attachable shop-overlay

# Deploy a service across multiple nodes on the same overlay network
docker service create --name shop-api \
  --network shop-overlay --replicas 3 shop-api:latest

5. VXLAN encapsulation in detail and its cost

Every packet leaving an overlay network gets wrapped by the sending host in a VXLAN header carrying a 24 bit network identifier (VNI) along with source and destination information for the tunnel, before being sent as a regular UDP packet over port 4789 to the destination host. The receiving host unwraps the packet again and hands the original layer 2 frame off to the local container it was meant for.

This encapsulation costs roughly 50 bytes of extra overhead per packet and forces a smaller effective MTU than a direct bridge connection, which on misconfigured networks can lead to fragmentation and noticeable performance loss. In practice, it is advisable to explicitly set the MTU on participating interfaces to a value like 1450 instead of the default 1500, to avoid fragmentation from the start.

# Compensate for VXLAN overhead with a reduced MTU on the overlay interface
ip link set dev docker_gwbridge mtu 1450

# Capture VXLAN traffic on the host for troubleshooting
sudo tcpdump -i eth0 udp port 4789 -nn

6. Performance differences across the three models

In latency and throughput measurements, macvlan consistently comes closest to native host network performance, since neither NAT translation nor tunnel encapsulation applies: packets leave the container practically unobstructed through the physical interface. The default bridge network loses measurable throughput because of the extra NAT translation and iptables processing overhead per packet, especially at very high packet rates with many small packets, as typically seen with Redis or Memcached workloads.

Overlay networks show the largest overhead, since VXLAN encapsulation and decapsulation on both ends stack on top of NAT like processing. For workloads with high network throughput between hosts, such as database replication or large file transfers between services, this extra latency should be planned for explicitly whenever no dedicated hardware acceleration like VXLAN offloading is available on the network card.

7. Security considerations across the three network models

With the bridge model, containers implicitly benefit from NAT isolation: inbound traffic from the external network only reaches a container through explicitly published ports, everything else gets dropped by the host before it ever reaches a container. That built in security boundary disappears entirely with macvlan, since every container shows up as a standalone device on the network and therefore needs to be protected by external firewall rules or network segmentation, just like a physical server.

For overlay networks, encryption of tunnel traffic is a frequently overlooked point: Docker Swarm offers optional IPsec encryption for overlay networks via the --opt encrypted flag, which is disabled by default. Anyone running overlay networks over a physical network that is not fully trusted, for example between data centers over a leased connection, should enable this encryption explicitly, since VXLAN traffic otherwise travels unencrypted over the underlying infrastructure.

# Encrypted overlay network for traffic between data centers
docker network create -d overlay --opt encrypted --attachable secure-overlay

8. DNS and service discovery per network model

On the default bridge network, containers resolve each other's names through a built in DNS server that Docker and Podman expose on an internal address within the given network, so one service can reach another simply by its container name instead of a hardcoded IP. This name resolution works automatically for every container on the same user defined bridge network, but not on the legacy default bridge network without its own name, where only explicit links still work for connecting containers.

With macvlan, this built in name resolution disappears, since containers show up as standalone devices on the physical network and therefore need the same DNS infrastructure as any other server on that network, for example a central internal DNS service or static hosts entries. Overlay networks in turn bring their own cluster wide name resolution that resolves services consistently across multiple hosts, which is a decisive advantage over plain macvlan for multi host setups with dynamically scaling services.

# Test internal DNS resolution on the bridge network
docker exec shop-php getent hosts shop-db

# Reach an overlay service by name from another container
docker exec shop-api getent hosts shop-cache

9. Practical recommendation for Magento hosting environments

For a classic single host Magento stack made of PHP FPM, Nginx, MySQL, and Redis, the default bridge network is almost always the right choice: internal communication between services stays entirely within the host, NAT overhead barely matters at these packet rates, and the built in isolation reduces external attack surface down to explicitly published ports like 443.

macvlan pays off specifically for individual services that need to be visible on the internal network with their own fixed IP, for example a dedicated monitoring interface or a legacy system that requires IP based access control instead of port based rules. Overlay networks only become relevant once the stack is spread across multiple physical or virtual hosts, for example a cluster with separate database and application nodes, where multi host transparency generally justifies the extra VXLAN overhead.

10. Summary

11. FAQ: Container Networking