Docker Networking modes­🐳

In this blog, we are going to go through every docker networking mode and what it represents for us.

🚀For whom ?

This blog is presented to every person that shares with me an interest in cloud native industry and wants to get ready to deep dive inside of it.

Why we need to know these concepts ?

Mastering the art of network can be challenging for many people, so gaining deep knowledge about how cloud native networking works and how containers can communicate with each other is an asset to get a job in the new modern world. So let’s get started 😄

Docker provides many modes to gain network access to containers as well as communcation between containers:

Bridge network

Docker Bridge network is the default networking method to start containers, it handles 90% of use cases for containers. The docker engine acutally creates a virtual network for containers that is isolated from the local network and can be accessed through port mapping or port translation.

A virutal network interface wil sit between the actual NIC of the docker host and the container which will provide the port translation for each one.

💡 DNS name resolution won’t be working with this mode, which means you can’t access the container directly with its name within the outside.

docker network create network-name

In Docker’s bridge mode, containers can communicate with each other using their container names as hostnames. Docker automatically sets up a DNS server within the network, allowing containers to resolve each other’s names to their respective IP addresses. This makes it easy for containers to communicate by name without needing to know each other’s IP addresses directly.

Host network

The host network mpde doesn’t have a virtual interface between the local network and the docker network, it simply launches the container on the host which means the container is running directly on the machine network and the container doesn’t get its own IP-address allocated. So we can access it by getting the IP address of the machine and the port of the container (the application running inside the container).

Image from https://www.geeksforgeeks.org/what-is-docker-network-host/

docker run --rm -d --name nginx --network host nginx

It will appear as you can run a normal application, you canÔÇÖt bind multiple containers to the same port.

­ƒÆí Containers running in host mode cannot communicate with each other using their container names as hostnames.

None network

This mode provides no network access to containers, thereby it is used for limited time workloads like batch jobs and data processing pipelines.

IPvlan

The container will get a separate IP address from the host network and it is represented as a separate virtual machine. We need though to specify the CIDR block and the gateway when creating this type of networks.

docker network create -d ipvlan --subnet=10.0.0.0/24 --gateway=10.0.0.4 -o parent=eth0 ipvlan

The default mode for IPvlan is l2. If -o ipvlan_mode= is left unspecified, the default mode will be used.

IPVLAN L2 lets the traffic to be routed between containers without the need for additionnal routing :

Container c2 can ping Container c1

We can also see that the both host and container share the same MAC address :

MAC Address for host

MAC Address fo rcontainer c1

Advantages :

Removing the bridge that traditionally resides in between the Docker host NIC and container interface leaves a simple setup consisting of container interfaces, attached directly to the Docker host interface. This mode is easy to access for external facing services as there is no need for port mappings in these scenarios.

­ƒÆí Two different subnets can communicate with each other if they share the same parent network interface

In IPVLAN L3 mode, container networking is handled as layer 3 connections. This means that virtual devices process only L3 traffic and above. Virtual devices do not respond to ARP request and users must configure the neighbour entries for the IPVLAN IP addresses on the relevant peers manually.

Summary of differences :

Summary of differences

Macvlan

Using macvlan network, each container is accessible from external network (host network), it assigns a mac address to each container interface as long as its own IP address. A MacVLAN network requires you to enable promiscuous mode on the parent interface of the Docker host, which is not required with IPvlan.

Each container will have its own mac address within the same docker host network interface so it will appear as a physical machine on the network. This mode is generally used for applications that require direct connection between the docker container and the external network without getting the NAT overhead.

Though they can ping each other, both containers have their unique MAC Addresses :

MAC Address for each container

Image from https://code4projects.altervista.org/how-docker-networking-works/

When setting up a Macvlan network, you can choose between bridge mode and 802.1Q trunk bridge mode.

• In bridge mode, Macvlan traffic is routed through a physical network interface on the host.

• In 802.1Q trunk bridge mode, the traffic is handled by an 802.1Q sub-interface that Docker dynamically creates, enabling more precise control over routing and filtering.

Cons:

• no DHCP (you need to just specify the IP address for each container)

• random MAC address assignment

• Promiscuous mode: you canÔÇÖt have more than one or two MAC addresses on same physical interface

Use Cases:

Some applications, especially legacy applications or applications which monitor network traffic, expect to be directly connected to the physical network. In this type of situation, you can use the macvlan network driver to assign a MAC address to each container’s virtual network interface.

Overlay

The overlay network creates a private secure network between docker containers that are running in different docker hosts.

docker swarm init
docker network create -d overlay --attachable my-network

It is used in large scale architectures where communcation between different docker hosts is required. It is now being less used since we use other containerization tools that facilitates the job like Kubernetes.

References:

[**Macvlan network driver** *All about using Macvlan to make your containers appear like physical machines on the network*docs.docker.com](https://docs.docker.com/engine/network/drivers/macvlan/#8021q-trunk-bridge-mode) [**IPvlan network driver** *All about using IPvlan to make your containers appear like physical machines on the network*docs.docker.com](https://docs.docker.com/engine/network/drivers/ipvlan/)