Mastering Docker Networking: From Custom Bridges to Swarm-Ready Architectures

Networking is a core concept of containerized applications. It enables seamless communication between all containers, host systems, and external services. Docker’s built-in networking features are essential for effectively isolating services, securing data flow, and orchestrating scalable microservices architectures.

One of the most powerful tools in this context is the Docker network create command, which allows DevOps engineers and developers to define custom networks tailored to their application needs.

This is why today I’ll walk you step by step on how to create and manage these Docker networks effectively. 

If you’re new to Docker, be sure to check out our skill track on Containerization and Virtualization with Docker and Kubernetes to get some hands-on experience. 

What is Docker Networking?

Building modern applications generally involves using several services in individual, isolated containers. Docker networking provides a flexible and powerful way to connect those containers together, with external systems, via whichever network model you choose, regardless of the underlying infrastructure.

This section will provide you with basic knowledge about Docker networking, which is a key component of Docker, and how to evaluate which network configuration will work for your application needs. But before getting started, if you’re totally new to Docker, I highly encourage you to check out Introduction to Docker to build a solid foundation before diving deeper into Docker networking.

Network drivers: the foundation of Docker networking

Docker employs network drivers to specify how containers connect and communicate. Each driver defines how it will handle container networking. As a result, there are varying levels of performance, isolation, and complexity for each of Docker's main network drivers.

Overview of core Docker network drivers

Here are the main built-in drivers Docker supports:

1. Bridge: The default driver for standalone containers. It creates an isolated internal network on the host, allowing containers to communicate with each other using IPs or container names. Ideal for development and testing on a single host.
2. Host: Removes isolation by sharing the host’s network stack. The container uses the host’s IP and ports directly. Useful for high-performance applications or compatibility with host-level services.
3. None: Disables all networking for the container. Only a loopback interface is available. Best for containers that don’t need external connectivity or require strict security isolation.
4. Overlay: Enables communication between containers on different Docker hosts. Commonly used in Docker Swarm and multi-host deployments. It creates a distributed network that abstracts the underlying physical infrastructure.
5. Macvlan: Assigns a unique MAC address to each container, making it appear as a physical device on the network. Suitable for legacy applications that require direct access to the physical network.
6. IPvlan: Similar to macvlan, but routes traffic at the IP layer instead of using MAC addresses. Offers better performance and control in high-density environments.

Each driver impacts how containers interact with each other, the host, and external networks. 

Curious how these network types work together? Our Intermediate Docker course covers Docker networking, volumes, and Compose in practical detail. Understanding these differences is key to designing secure and performant architectures.

Which network type should I use?

Choosing the right network driver depends on your application’s architecture and operational goals:

1. Bridge: Recommended for most local development scenarios and simple multi-container applications on a single host. Offers a balance of isolation and ease of use.
2. Host: Best when containers need to bind directly to the host’s network, such as when exposing services on standard ports (e.g., port 80 or 443). Be cautious with security and port conflicts.
3. None: Ideal for sandboxed workloads or security-critical tasks that should not have any network access. Common in automated workflows or testing.
4. Overlay: Essential in clustered environments like Docker Swarm or Kubernetes where containers span multiple hosts. Enables horizontal scaling and service discovery.
5. Macvlan: Preferred when containers must behave like physical devices on the LAN. Used in cases such as network sniffing, legacy system integration, or when bypassing Docker’s network stack.
6. IPvlan: Offers granular control and better performance than macvlan for environments with strict networking requirements, like telco or financial systems.

Consider factors like host topology, security needs, and scaling strategy when choosing a network driver. 

Still deciding which network suits your workload? Learn how Docker compares with Kubernetes in real deployments with this Kubernetes vs Docker guide.

Creating Custom Docker Networks

Custom Docker networks allow you to control how containers communicate internally with each other, as well as with external systems, which can help you better isolate services, give them predictable IPs, or design your architecture for performance or security. 

The section will walk you through the basics to the more advanced features in the process of creating custom Docker networks, including the commands and custom IP configurations.

Basic command sructure

To create a custom network, use the docker network create command. This lets you define the network driver, subnet, and other options for better control over container communication.

Here’s a simple example using the default bridge driver:

$ docker network create demo-network -d bridge

This command creates a bridge network named demo-network. Docker returns a unique network ID as confirmation. At this point, the network exists but doesn’t yet connect any containers.

You can view existing networks with:

$ docker network ls

To connect a container to your new network, use the --network flag:

$ docker run -it --rm --name container1 --network demo-network busybox:latest

To add an existing container to a network:

$ docker network connect demo-network container2

And to remove it:

$ docker network disconnect demo-network container2

Finally, when the network is no longer needed, you can remove it:

$ docker network rm demo-network

To clean up all unused networks:

$ docker network prune

Advanced IP address management

When working with larger systems or specific network policies, Docker lets you manually manage IP address ranges within custom networks.

You can define a subnet and gateway using the --subnet and --gateway flags:

$ docker network create \
  --driver bridge \
  --subnet 192.168.100.0/24 \
  --gateway 192.168.100.1 \
  custom-network

For even more control, use:

• --ip-range: Assign a pool of IPs that containers can dynamically draw from, separate from the full subnet range.
• --aux-address: Reserve specific IP addresses within the subnet for external systems or documentation purposes.

For instance: 

$ docker network create \
  --driver bridge \
  --subnet 192.168.200.0/24 \
  --ip-range 192.168.200.128/25 \
  --aux-address reserved=192.168.200.254 \
  advanced-network

This setup:

• Limits dynamic container IPs to the upper half of the subnet.
• Prevents collisions with a reserved IP.
• Ensures consistent networking behavior in complex environments.

In case you need more guided examples, you can explore advanced setup strategies in 10 Docker Project Ideas: From Beginner to Advanced.

Swarm Mode Networking

Docker Swarm mode enables the orchestrated deployment of services across a cluster of Docker hosts. A critical part of this orchestration is networking, ensuring services running on different nodes can seamlessly and securely communicate with one another.

Swarm-aware network architectures

Docker Swarm is Docker's native clustering solution that turns a pool of Docker hosts into a single virtual engine. It enables you to deploy and manage containers as distributed services. One of its major strengths is multi-host networking, allowing services on different machines to communicate as if they were on the same host.

Swarm networking supports two main types of traffic:

• Control plane traffic – encrypted management communication between Docker nodes.
• Data plane traffic – container-to-container communication and external service access.

Swarm uses overlay networks to support inter-node service communication and routing mesh to load-balance external traffic across service replicas.

Creating swarm networks

To support service discovery and secure multi-host communication, Docker Swarm uses overlay networks with a scope of swarm. These can be created manually or automatically when services are launched.

Here’s how to create a swarm-scoped overlay network:

$ docker network create \
  --driver overlay \
  --scope swarm \
  my-overlay

This network is not limited to a single host; any node participating in the swarm can connect containers to it. You can inspect it using:

$ docker network inspect my-overlay

Customizing Overlay Networks

Overlay networks support advanced configuration, such as:

$ docker network create \
  --driver overlay \
  --subnet 10.0.9.0/24 \
  --gateway 10.0.9.99 \
  --opt encrypted \
  my-secure-overlay

• --subnet and --gateway define the network topology.
• --opt encrypted enables IPSEC encryption for container traffic.
• --scope swarm is automatically applied with the overlay driver in swarm mode.

Understanding the --scope and --attachable Flags

• --scope swarm: Indicates that the network is available across all nodes in the swarm. Only swarm services (not standalone containers) can use this network unless --attachable is specified.
• --attachable: Allows standalone containers to join a swarm-scoped network. Useful for debugging or temporary container access.

For instance: 

$ docker network create \
  --driver overlay \
  --attachable \
  my-dev-overlay

This lets you attach regular containers to a swarm network, in addition to services.

Network Configuration and Validation

You need to make sure that your Docker networks are correctly configured in order to communicate properly between containers, provide the necessary security, and a performant services. Docker has several tools and commands to review, troubleshoot, and validate your network configurations.

Network configuration verification

To examine the configuration details of any Docker network, use the docker network inspect command.  You will receive detailed JSON output which includes:

• Network driver (bridge, overlay, etc.)
• Subnet and gateway configuration
• Scope (local, swarm)
• Connected containers and their IP addresses
• Internal or external access
• Driver-specific options (e.g., VXLAN IDs for overlay networks)

For instance, you could do something like:

$ docker network inspect my-network

Look for key fields like:

• "Driver": Ensures the intended network type was created.
• "IPAM": Confirms IP address management settings, including custom subnets or gateways.
• "Containers": Shows which containers are attached and their assigned IPs.
• "Options": Displays advanced configurations like encryption (encrypted: true) or MTU size.

Validation Techniques

To confirm your network is functioning as expected:

1. First you must verify IPAM configurationCheck the "IPAM" section in the Docker network inspect output. Ensure the subnet and gateway match your intended setup. Misconfigured subnets can lead to connectivity issues or IP conflicts.
2. Then you have to check for VXLAN identifiers (Overlay only)Overlay networks use VXLAN for encapsulating container traffic across multiple hosts. Inspect the "Options" section for keys like:

"com.docker.network.driver.overlay.vxlanid_list": "4097"

This confirms that the VXLAN tunnel is active and properly configured. If missing or incorrect, services may not be reachable across nodes.

3. Finally, test inter-container connectivityFrom one container, try pinging or accessing another by container name or IP. This confirms DNS resolution and internal routing are functioning:

$ docker exec -it container1 ping container2

Check DNS behavior

Containers connected to user-defined networks use Docker’s embedded DNS server. To confirm, inspect /etc/resolv.conf inside the container and test the resolution of service names.

Validate gateway routing

For containers on multiple networks, Docker selects the default gateway based on the highest gw-priority. To enforce correct routing, assign explicit priorities during container creation:

$ docker run --network name=public,gw-priority=1 --network private mycontainer

Use logs and diagnostic tools

Monitor container logs for connectivity errors, and use tools like curl, dig, and ip a inside containers for low-level debugging.

So, to sum it up, validating your Docker network configurations helps ensure seamless container communication and minimizes unexpected failures in multi-service applications. 

And this leads us to the following section.

Security and Performance Optimization

Real container networking consists of more than enabling methods of communication. In many cases, it provides necessary isolation while making sure that performance is maximized. When securing your architecture and providing a service, segmentation and throughput can help you do so.

Network segmentation strategies

Networking segmentation is a fundamental practice and security method for containerized applications. By assigning the containers to distinct Docker networks, you can separate cross-cutting concerns like segmentation for services with a frontend, a backend, and a database. This can allow proactive risk mitigation against exposure and potential attacks.

You can leverage user-defined networks to help manage communication boundaries. Containers in different networks cannot communicate with each other unless you explicitly connect them. For example, if you place your database container on an internal-only network, your public-facing services cannot directly access it.

Built-in firewall rules and controls

By default, Docker implements iptables rules to restrict communication endpoints between containers and the external world. 

Some ways to extend this segmentation include:

• Disabling inter-container communication on the default bridge network:

{
  "icc": false
}

• Add this to the Docker daemon’s daemon.json to prevent containers from communicating unless on the same user-defined network.
• Limiting capabilities and privileges using flags like --cap-drop, --read-only, and --no-new-privileges.
• Using overlay networks in Swarm mode for encrypted, scoped service communications across multiple hosts.

Performance Optimization Techniques

There are several ways you can improve performance through optimization with Docker. 

Improving network throughput

Choosing the right network driver has a direct impact on performance. For example:

• Use the host driver when low-latency, high-throughput communication is essential, and network isolation is not a priority.
• Prefer bridge for local, isolated environments.
• Deploy macvlan when containers need to behave like physical devices on your network.

Avoid overloading the default bridge network, and create separate networks for heavy services or logical grouping.

Performance profiling with iperf3 and metrics

To measure network performance, use profiling tools like iperf3:

# Start server in container1
docker run -it --rm --name server --network my-net networkstatic/iperf3 -s

# Run client in container2
docker run -it --rm --network my-net networkstatic/iperf3 -c server

You can also monitor network stats using:

• docker stats – Real-time CPU, memory, and network I/O.
• Prometheus + cAdvisor – For time-series metrics and long-term monitoring.
• Custom scripts or agents exporting /proc/net/dev metrics from within containers.

Regular profiling helps detect bottlenecks early and guide decisions around container placement, driver selection, or host network upgrades.

Troubleshooting Networking Issues

Even with best practices, network issues can arise. Diagnosing and resolving them quickly is key to maintaining service uptime. This section provides tools and techniques to identify and fix common Docker networking problems.

Diagnosing network problems

A minimal container might lack tools like ping, dig, or netstat, making it hard to troubleshoot. Instead of modifying the container, launch a new one sharing its network namespace:

docker run -it --network container:my-container alpine

Then install network tools:

apk add --no-cache iproute2 bind-tools net-tools

Alternatively, use nicolaka/netshoot, a purpose-built image packed with diagnostic tools:

docker run -it --rm --network container:my-container nicolaka/netshoot

Tools like ip, nslookup, netstat, and traceroute will help identify routing or DNS issues.

Resolving connectivity problems

Some common causes and their resolutions:

• DNS resolution failures: Ensure the container is on a user-defined network to benefit from Docker’s embedded DNS. Check /etc/resolv.conf and use dig or nslookup to test name resolution.
• MTU mismatches: Containers across different networks or hosts might experience packet drops due to mismatched MTUs. Reduce the MTU in overlay networks if tunneling is used:

docker network create --driver overlay --opt com.docker.network.driver.mtu=1200 my-overlay

Conflicting subnets

Avoid overlapping subnets across Docker networks or with your host's physical networks. Use --subnet to define non-conflicting ranges.

Blocked ports by host firewall

Ensure required Docker ports are open:

• 2377 (Swarm management)
• 7946 TCP/UDP (container discovery)
• 4789 UDP (overlay data)

Effective troubleshooting combines diagnostics with a solid understanding of how containers interact with their networks. With the right tools and approach, most problems can be isolated and resolved within minutes.

Conclusions

Docker Networking is a foundational component of containerized architectures, enabling secure, efficient, and scalable communication between services, whether they run on a single host or across a distributed cluster. 

With built-in support for various network drivers, customizable IP management, and Swarm-native overlay networks, Docker empowers developers and DevOps teams to isolate workloads, control data flow, and optimize performance in complex environments.

It isn’t a one-size-fits-all solution, but when used thoughtfully, it offers robust capabilities for building modern microservices, automation pipelines, and secure distributed systems.

Want to continue sharpening your Docker and containerization skills? 

Here are some highly recommended resources to continue your learning journey:

• Introduction to Docker: Get started with the fundamentals of containers and image management.
• Intermediate Docker: Dive deeper into networking, volumes, and multi-container orchestration with Docker Compose.
• Introduction to Kubernetes: Learn how to deploy and manage containers at scale with Kubernetes.
• Docker Compose vs Kubernetes: A Detailed Comparison: Understand the differences and decide which orchestration tool fits your needs.
• 10 Docker Project Ideas: From Beginner to Advanced: Apply your skills with real-world project inspiration.