Docker Networking

Docker Networking

Docker has several network types, and it’s important to choose the right one. Let’s go through each one properly.

Internal vs External Networks

Before we dig into specific network types, it’s worth clarifying two terms.

The internal network is the virtual network inside the Docker host. This is what allows containers to communicate with each other.

The external network is everything outside Docker. That is, your LAN, other servers, and the internet. This comes into play when containers need to be reachable from the outside world, or when they need to reach external resources themselves.

Docker network types are really just different methods for connecting a container’s internal network interface to the Docker host’s network card.

IP Addressing and DNS

When a container starts, Docker assigns it a private IP address automatically. You don’t choose this address — Docker manages it.

By default, Docker uses the `172.17.0.0/16` range for its internal networks. You can change that if you want to, but in many cases, it’s easier to leave it as it is.

Docker also runs a small internal DNS service. When containers have names, this DNS service resolves those names to their IP addresses. That means containers on the same network can reach each other by name, not just by IP.

Bridge Networks

Bridge is the default network type, and the one you’ll use most often.

A bridge network creates an isolated virtual network inside the Docker host. Containers get private IP addresses and can talk to each other directly.

To reach the outside world, traffic passes through the Docker host using a source NAT, meaning that external devices see traffic coming from the host’s IP, not the container’s.

There’s already a default bridge network inside Docker. Any container started without specific network config gets attached to it.

The caveat here is that when we start multiple containers on the default bridge, they can all communicate with each other. This might not be desirable, as we might want to keep our containers isolated, or in isolated groups.

The better practice is to create your own bridge networks:

docker network create myBridgeNetwork

To start a container on a specific network:

docker run -d --network myBridgeNetwork --name webserver nginx

To allow external access, you still need to map ports with -p. That maps a port on the host to a port inside the container.

Bridge networks are well-suited to most use cases. They work on both Docker Desktop and Docker Engine.

Host Network

The host network type is a built in network. Containers attached to this network will share the host’s network stack directly.

The container and the host share the same IP addresses, MAC address, and ports. There’s no isolation between them at the network level.

This gives the container the lowest possible network overhead. This might be useful for applications that need maximum network performance, or that need to bind a dynamic range of ports.

It’s also useful for applications such as DHCP, which need to use layer-2 traffic. Bridge mode does not allow the forwarding of ARP requests, DHCP broadcasts, and traffic like that.

The downside is that isolation is gone. Multiple containers connected to the host network can conflict with each other if they try to use the same ports. It also has security implications — a compromised container has more direct access to the host.

Also worth noting: the host network type doesn’t work on Docker Desktop, since Docker Desktop runs inside a Linux VM. It requires Docker Engine on Linux.

None

The none network type is another built in network. This gives a container no network access at all. Complete isolation.

This sounds odd, but it has its uses. If you’re running a batch job or a script that doesn’t need any network access, disconnecting it entirely is good security practice.

When a container is connected to the ‘none’ network, it only has a loopback interface. It has no other interfaces.

MACVLAN is where things get interesting. MACVLAN allows containers to appear as real devices on your external network. Each container gets its own unique MAC address and an IP address drawn from the same subnet as the Docker host.

From the perspective of your external switch and router, these containers look like physical machines plugged into the network.

Think of it as a virtual switch inside the Docker host, connecting containers directly to the upstream LAN.

The advantages are significant:

• No port forwarding needed — containers are directly addressable on the network
• No NAT overhead
• No port conflicts — multiple web servers can all use port 80, each with their own IP
• Granular external firewall policy is possible, since each container has its own IP

But MACVLAN has some important caveats.

Because each container has its own MAC address, your external switch sees multiple MACs on a single port. If port security is configured on that switch, it may shut down the port. This presents problem in enterprise environments.

Also, containers on a MACVLAN network cannot communicate with the Docker host directly. This is a known limitation of the MACVLAN design. This could be a problem if you’re monitoring servers from a container.

MACVLAN is also not available in all cases. Some cloud providers block MACVLAN entirely, and it’s not supported on Docker Desktop, only Docker Engine.

Creating a MACVLAN network:

docker network create -d macvlan \
  --subnet=192.168.200.0/24 \
  --gateway=192.168.200.254 \
  -o parent=eno1 \
  myMacvlan

• -d macvlan sets the driver
• --subnet and --gateway describe the external network
• -o parent identifies which network interface on the host connects to the LAN

You then assign a static IP when starting each container:

docker run -d --network myMacvlan --ip 192.168.200.100 --name myContainer ubuntu

IPVLAN

IPVLAN fixes most of MACVLAN’s problems. It’s the more flexible and scalable option.

The key difference is that containers share the host’s MAC address. Each container has a unique IP address, but only one MAC address is seen on the upstream port.

This solves the port security problem immediately. Your switch sees one MAC per port, which is exactly what it expects.

Layer 2 Mode

IPVLAN layer 2 behaves similarly to MACVLAN. Containers get IPs from the host’s subnet and are directly reachable on the LAN. The switch sees one MAC and multiple IPs.

Unlike MACVLAN, containers in IPVLAN L2 can communicate with the Docker host, depending on configuration. Cloud providers are also less likely to block it.

Creating an IPVLAN L2 network:

docker network create -d ipvlan \
  --subnet=192.168.200.0/24 \
  --gateway=192.168.200.254 \
  -o ipvlan_mode=l2 \
  -o parent=eno1 \
  ipvlanL2

Layer 3 Mode

IPVLAN layer 3 is a fully routed solution. Containers use entirely different subnets from the host.

Think of it as a small virtual router inside the Docker host. Containers connect to the router, and the router connects to the external network.

The benefits are the usual ones you’d expect from a layer 3 design: reduced broadcasts, reduced ARP traffic, and better scalability for large deployments.

The catch is that you’ll need to add routing configuration on your external router, pointing to the container subnets via the Docker host. Without that, external devices won’t know how to reach them.

Creating an IPVLAN L3 network:

docker network create -d ipvlan \
  --subnet=10.10.10.0/24 \
  -o ipvlan_mode=l3 \
  -o parent=eno1 \
  ipvlanL3

Note there’s no --gateway here. The Docker host itself acts as the default gateway for containers on an L3 network.

Comparison

Here’s a summary to help you choose:

Feature	Bridge	MACVLAN	IPVLAN
Unique MAC per container	No	Yes	No
Unique IP per container	Yes	Yes	Yes
Direct LAN access	No (NAT)	Yes	Yes
Host ↔ container comms	Yes	Broken	Works on L3 Mode
Port security issues	No	Yes	No
Docker Desktop support	Yes	No	No
Performance	NAT Overhead	Native	Native

In most cases, you’ll use bridge for simplicity, or IPVLAN when you need containers on your LAN.

MACVLAN is useful but carries extra caveats you need to plan for.

Mixing Network Types

You’re not limited to one network type at a time. It’s quite common to mix them.

As a practical example, think about some web servers behind a reverse proxy. The web servers communicate with the reverse proxy over a bridge network. This would be configured for internal use only, with no ports mapped to the Docker host.

The reverse proxy connects to the outside world via IPVLAN, giving it a proper LAN IP. It receives traffic on this network, and then proxies the traffic to the web services over the bridge network.

Both network types run simultaneously on the same Docker host.

The full course walks through all of these network types with live demonstrations and configuration examples:

Watch the free YouTube course → COMING SOON

Enrol in the full Udemy course → COMING SOON