Docker Swarm Networking

Updated June 2026 14 min read Advanced

Docker Swarm networking enables secure, multi-host container communication. This guide covers overlay networks for connecting services across nodes, the ingress routing mesh for external access, and service discovery patterns.

Overlay Networks Ingress Mesh Service Discovery Network Encryption

Swarm Networking Overview

Docker Swarm provides a sophisticated networking model that allows containers on different nodes to communicate securely and efficiently. The key components are overlay networks (for multi-host container communication) and the ingress routing mesh (for external access to services).

When you deploy a Swarm, Docker automatically creates several networks. The ingress network is a special overlay network that handles external traffic routing. The docker_gwbridge connects containers to the host's physical network. You can also create custom overlay networks for better isolation and security.


    External Client
          │
          ▼
    ┌─────────────────────────────────────────────┐
    │              Ingress Routing Mesh            │
    │  (Load balances traffic across all nodes)    │
    └─────────────────────────────────────────────┘
          │
          ▼
    ┌─────────────────────────────────────────────┐
    │              Overlay Network                 │
    │  (Secure multi-host container communication) │
    └─────────────────────────────────────────────┘
          │
    ┌─────┴─────┐         ┌─────┴─────┐
    │  Node 1   │         │  Node 2   │
    │ ┌───────┐ │         │ ┌───────┐ │
    │ │Task 1 │ │◄───────►│ │Task 2 │ │
    │ └───────┘ │         │ └───────┘ │
    └───────────┘         └───────────┘

Check Swarm networks with `docker network ls`. You'll see `ingress`, `docker_gwbridge`, and any custom overlay networks.

Overlay Networks: Multi-Host Communication

Overlay networks are distributed networks that span all Swarm nodes. They use VXLAN (Virtual Extensible LAN) tunneling to encapsulate container traffic, allowing containers on different hosts to communicate as if they're on the same network. Overlay networks can be encrypted for additional security.

When you create a service without specifying a network, it connects to the default `ingress` network. For better isolation, create custom overlay networks and attach services to them. Services on the same overlay network can communicate by service name.

                # Create an overlay network
docker network create -d overlay --attachable myapp-net

# Create encrypted overlay network
docker network create -d overlay --opt encrypted --attachable secure-net

# Create overlay network with custom subnet
docker network create -d overlay \
  --subnet=10.0.10.0/24 \
  --gateway=10.0.10.1 \
  --attachable \
  custom-net

# Deploy service on overlay network
docker service create --name web --network myapp-net --replicas 3 nginx

# Deploy another service on same network
docker service create --name api --network myapp-net --replicas 2 myapi

# Attach existing service to network
docker service update --network-add myapp-net web

# List networks
docker network ls

# Inspect overlay network
docker network inspect myapp-net
            

Ingress Routing Mesh: External Access

The ingress routing mesh is Docker Swarm's built-in load balancer. When you publish a port on a service (e.g., `-p 80:80`), Swarm makes that port available on every node in the cluster. If a request arrives on node A but the service task runs on node B, the ingress network routes the request to the correct node.

This provides high availability and load balancing. If a node fails, traffic automatically routes to healthy nodes with running tasks. The routing mesh operates at layer 4 (TCP/UDP) and uses IPVS (IP Virtual Server) for efficient packet forwarding.

                # Publish port on all nodes (routing mesh)
docker service create --name web --replicas 3 -p 80:80 nginx

# Publish port on specific node only (host mode)
docker service create --name web --replicas 3 -p 80:80 --publish mode=host,target=80,published=80 nginx

# Publish multiple ports
docker service create --name app \
  -p 80:80 \
  -p 443:443 \
  -p 8080:8080 \
  myapp

# Publish UDP port
docker service create --name dns -p 53:53/udp dnsmasq

# Check published ports
docker service inspect web --pretty | grep -A 10 Ports

# Test routing mesh (access any node IP)
curl http://node1-ip:80
curl http://node2-ip:80
curl http://node3-ip:80  # All work, even if tasks not on that node
            

The routing mesh is transparent to clients. You can put any node's IP address in your load balancer or DNS, and traffic will reach a healthy service task regardless of which node it runs on.

Service Discovery and Internal DNS

Swarm provides built-in service discovery through its internal DNS. Every service gets a DNS entry resolvable to its virtual IP address. The DNS load balances requests across all healthy tasks using round-robin.

Within an overlay network, services can reach each other using just the service name. For example, a web service can connect to `redis:6379` or `database:5432`. This works across nodes and handles task restarts and rescheduling automatically.

                # Create overlay network
docker network create -d overlay app-net

# Deploy redis service
docker service create --name redis --network app-net --replicas 1 redis:alpine

# Deploy web service that connects to redis by name
docker service create --name web --network app-net -p 80:80 myapp

# Test DNS resolution from inside a task
docker service exec web nslookup redis
docker service exec web ping redis

# Check service VIP
docker service inspect redis --format '{{.Endpoint.VirtualIPs}}'

# Access by service name (internal load balancing)
docker service exec web curl redis:6379/ping
            

Network Encryption for Security

Swarm can encrypt overlay network traffic between nodes. When you create an encrypted overlay network, all traffic between containers on that network is encrypted using IPSec (ESP in tunnel mode). This is essential for compliance and security in multi-tenant environments.

Encryption has a small performance overhead (typically 5-10%). Use it for sensitive data or when running across untrusted networks. Enable encryption at network creation time; it cannot be added later.

                # Create encrypted overlay network
docker network create -d overlay --opt encrypted --attachable secure-net

# Deploy services on encrypted network
docker service create --name db --network secure-net postgres
docker service create --name app --network secure-net -p 80:3000 myapp

# Verify encryption is enabled
docker network inspect secure-net | grep -A 5 Encrypted

# Check IPSec status on nodes
docker run --rm --privileged --pid=host alpine ip -s xfrm state

# Important: Encryption cannot be added after network creation
# Create a new network with encryption and migrate services
            

Encrypted overlay networks use IPSec between nodes. The encryption keys are automatically managed by Swarm and rotated regularly for security.

Host Mode vs Routing Mesh: Publishing Ports

Feature	Routing Mesh (Default)	Host Mode
Availability	Port available on all nodesPort available only on node where task runs
Load balancing	Built-in across all nodes	No (client must know node IP)
High availability	Yes (any node works)	No (node failure breaks access)
Performance	Slight overhead (NAT)	Native performance
Use case	Most production services	High-performance, monitoring agents

                # Routing mesh mode (default) - port on all nodes
docker service create --name web -p 80:80 nginx

# Host mode - port only on node where task runs
docker service create --name web -p 80:80 --publish mode=host,target=80,published=80 nginx

# Example: Monitoring agent that should run on every node
docker service create --name node-exporter \
  --mode global \
  --publish mode=host,target=9100,published=9100 \
  prom/node-exporter
            

Network Troubleshooting

                # Check network connectivity between services
docker service exec web ping redis

# Test DNS resolution
docker service exec web nslookup redis
docker service exec web getent hosts redis

# Check service VIP and endpoints
docker service inspect redis --pretty | grep -A 15 Endpoint

# View network details
docker network inspect myapp-net

# Check ingress network
docker network inspect ingress

# Debug routing mesh
docker service logs web

# Verify ports are published
docker service ps web
docker service ps web --format "table {{.Node}}\t{{.Ports}}"

# Check iptables rules (on Linux node)
sudo iptables -L -n | grep -i 80
            

Swarm Networking Best Practices

Create custom overlay networks - Don't rely on the default ingress network for application traffic. Create isolated networks per application or environment.
Use network encryption for sensitive data - Enable `--opt encrypted` for networks carrying personal or financial information.
Prefer routing mesh for public endpoints - It provides high availability and load balancing out of the box.
Use host mode for node-local services - Monitoring agents, log collectors, and sidecars that need to see host network traffic.
Never publish database ports externally - Keep databases on internal overlay networks only, never exposed via `-p`.
Use service discovery over hardcoded IPs - Rely on Swarm's DNS instead of connecting to specific node IPs.
Monitor network performance - Overlay networks add some latency. For high-throughput workloads, consider host networking or performance tuning.
Plan your IP address ranges - Avoid overlap with existing network infrastructure, especially when using custom subnets.

Frequently Asked Questions

What's the difference between overlay and bridge networks?

Bridge networks work on a single Docker host. Overlay networks span multiple Swarm nodes, enabling containers on different hosts to communicate. Use bridge for single-host, overlay for multi-host.

How does the ingress routing mesh handle traffic?

When you publish a port, every Swarm node listens on that port. Incoming traffic is accepted by any node, then forwarded (via the ingress network) to a healthy task. This provides load balancing and high availability.

Can I use my own load balancer with Swarm?

Yes! Many organizations put HAProxy, NGINX, or cloud load balancers in front of Swarm. Point your load balancer to all Swarm node IPs, and the routing mesh will route traffic to the correct tasks.

Does overlay network encryption affect performance?

Yes, typically 5-10% overhead due to encryption/decryption. For most applications this is acceptable. For high-throughput workloads, consider whether encryption is required or use host networking for performance-critical services.

Can containers on different overlay networks communicate?

No, containers on different overlay networks are isolated by default. To enable communication, either attach a container to multiple networks or use a proxy service that bridges networks.

What ports need to be open between Swarm nodes?

TCP port 2377 (cluster management), TCP/UDP port 7946 (node discovery), and UDP port 4789 (overlay network traffic/VXLAN). Ensure these are open on all nodes.

How do I scale the ingress network?

The ingress network uses the routing mesh which runs on all manager nodes. For high-traffic scenarios, add more manager nodes or use an external load balancer in front of the cluster.

Why can't I ping a service by name from outside Swarm?

Swarm's internal DNS is only accessible from within the overlay network. External clients cannot resolve service names. They must use published ports (routing mesh) or an external load balancer.

Previous: Swarm Services & Tasks Next: Swarm vs Kubernetes

Mastering Swarm networking is essential for building secure, scalable container applications. Use overlay networks for service communication, the routing mesh for external access, and encryption for sensitive workloads.