Docker Networking Basics: A Quick Guide

Network administrators no longer have the luxury of staying in their comfort zone of configuring physical routers, switches, and other LAN/WAN components. We now live in a virtualized world where administrators must dig into network components found in virtualization platforms from VMware, Microsoft, Red Hat, and others.

Today, enterprise IT is becoming increasingly interested in containers, which require strong networking skills in order to properly configure a container architecture. In this article, I'll focus on the network basics of Docker, easily the most popular container platform. I'll explore default Docker network settings and explain how Docker's user-defined configuration options provide expanded networking capabilities.

Default Docker networks

When you initially install Docker, the platform automatically configures three different networks that are named none, host, and bridge. The none and host networks cannot be removed; they're part of the network stack in Docker, but not useful to network administrators since they have no external interfaces to configure. Admins can configure the bridge network, also known as the docker0 network. This network automatically creates an IP subnet and gateway. All containers that belong to this network are part of the same subnet, so communication between containers in this network can occur via IP addressing.

A drawback of the default bridge network, however, is that automatic service discovery of containers using DNS is not supported. Therefore, if you want containers that belong to the default network to be able to talk to each other, you must use the --link option to statically allow communications to occur. Additionally, communication requires port forwarding between containers.

Many administrators find that these limitations severely constrain the network usability and scalability of Docker. That's why it's better to create user-defined networks; they make it easier to manage containers that need to communicate with one another.

Types of user-defined networks

Beyond the default networks that are created automatically in Docker, administrators can configure multiple user-defined networks and add containers to one or more of these networks. It's important to note that containers can communicate with others when they belong to the same network, but communication between networks is not allowed. There may be situations where a container needs to communicate with others in more than one network. To solve this problem, you simply add that container to multiple networks. The container can then communicate with containers in all networks it’s associated with.

There are three primary types of user-defined networks that serve different communications purposes:

Bridge network -- Like the default bridge network, a user-defined bridge network is a self-contained IP subnet and gateway. But unlike the default bridge, all containers within the user-defined bridge can communicate directly to one another without the need for port forwarding. Additionally, automatic discovery using DNS is fully supported on this network. If you want other devices in other networks to communicate with resources in your user-defined bridge network, you simply publish the TCP/UDP ports you need and Docker will expose the network addresses and ports to outside networks.

Overlay network – If you’re planning to run Docker in a distributed network, and need containers on different hosts to be able to communicate directly with one another, the overlay network is the right choice. To do this, your Docker servers must enable swarm mode and join the same swarm. Swarm mode is Docker’s method of allowing for the management of a cluster of Docker engines, known as a “swarm.” Once completed, you can create a layer 2 overlay network within the swarm, using the VXLAN encapsulation scheme. When containers are added to the overlay network, they can communicate directly with all other containers as if they were residing on the same node. Allowing communication from outside networks into overlay networks operates similarly to user-defined bridge networks.

Docker.png

Macvlan network – This user-defined network type attempts to simplify and streamline container communication by eliminating the bridge that resides between the container and host when using bridge and overlay networks. The main benefit here is that it automatically exposes external-facing container resources to outside networks without having to deal with port forwarding. A Macvlan network  accomplishes this by using layer 2 MAC addresses as opposed to layer 3 IP addressing.

There are three different ways to setup a Macvlan network. The first is Macvlan bridge mode. In this mode, each container is assigned its own unique MAC address. Docker then manages the MAC-address-to-port mappings. Communication between containers inside the same Macvlan bridge network is switched at layer 2. Communications outside the Macvlan bridge network is routed at layer 3.

The Macvlan 802.1q trunk bridge mode allows for the tagging of different layer 2 VLANs for separation of containers using the IEEE 802.1q standard trunking specification. The Docker host can be configured as an 802.1q trunk to external routers and switches. It then segments containers by VLANs, which represent separate network subnets.

If you are running Docker containers inside a network that utilizes both IPv4 and IPv6 addressing, you can take advantage of the dual-stack Macvlan bridge mode. By default, Docker operates only in IPv4 mode. Using the dual-stack Macvlan bridge, you can simultaneously route containers using both versions of the IP protocol.