Table of Contents
Introduction
Container networking connects containers to each other, to the host, and to external networks. It is conceptually similar to virtual machine networking but uses lightweight primitives like network namespaces, virtual Ethernet interfaces, and software bridges. In this chapter you will focus on how containers talk over the network, what common network modes exist, and which key components are involved when using tools like Docker or Podman.
Network Namespaces and veth Pairs
Linux containers rely on network namespaces to isolate network stacks. Each container typically runs in its own network namespace, which has its own interfaces, routing table, and firewall rules. The host remains in the root network namespace and can create and manage additional namespaces.
To connect a container to the host, Linux uses virtual Ethernet pairs, often called veth pairs. A veth pair behaves like a virtual cable. One end of the cable is placed in the host network namespace and the other end is moved into the container network namespace. Each end gets its own name and IP configuration. Traffic entering one end of a veth interface exits the other end, which lets the host and container exchange packets or lets the container access other networks through the host.
Bridges and Default Container Networks
Container runtimes usually create a bridge interface on the host. A bridge acts like a virtual switch that forwards frames between its connected interfaces. When you start a container in the default bridged mode, the runtime creates a veth pair, attaches the host side of the pair to the bridge, and places the other side in the container namespace.
The bridge assigns the container an IP address from a private subnet that belongs to the bridge. Other containers that are attached to that bridge can reach each other by IP directly, because traffic between them stays on the same virtual switch. The host can also reach containers by their bridge IP addresses.
A typical layout is that the bridge has an IP such as 172.17.0.1 and containers receive addresses from 172.17.0.0/16. The host routing table points this subnet through the bridge interface, so any packet to that subnet is delivered into the virtual switch and then to the proper veth peer.
In default bridge networking, containers receive IP addresses from private subnets that are only reachable from the host and from other containers on the same bridge. External access usually requires port mapping or additional routing.
Port Mapping and NAT
Containers often provide services that should be reachable from outside the host. Since containers typically live in private address spaces, the container runtime sets up network address translation, or NAT, to let external clients connect.
Port mapping associates a host IP and port with a container IP and port. For example, mapping 0.0.0.0:8080 on the host to 172.17.0.2:80 inside the container allows an external client to connect to the container web server by using the host address and port.
On Linux, iptables or its successor nftables usually enforces NAT rules. For incoming connections, a destination NAT (DNAT) rule rewrites packets bound for the host port so that they are delivered to the container IP and port. For outgoing connections, a source NAT (SNAT) or masquerade rule translates the container source IP to the host IP so that replies return correctly from external servers.
The full path of a connection from an outside client to a container behind NAT is therefore: client to host public address, host to bridge interface by DNAT, bridge to container veth, and then into the container network namespace. Responses follow the reverse route and are retranslated along the way.
Host Networking Mode
In host networking mode, a container does not get its own isolated network namespace. Instead, it shares the network namespace of the host. All container processes see the same network interfaces, the same IP addresses, and the same routing table as the host system.
This mode has several consequences. A service listening on port 80 inside the container actually binds to port 80 directly on the host. Since there is no isolation, you cannot have a second container using host networking that binds to the same port if the first one is already using it.
Host networking removes the overhead of passing packets through bridges and NAT. It is often used in scenarios where you want the least possible latency or where the container must interact directly with host network devices, for example for routing daemons or network monitoring tools.
The tradeoff is reduced isolation and a higher risk that configuration inside the container might interfere with host networking, for example by opening ports or changing firewall rules, depending on the capabilities granted to the container.
None Networking Mode
In the none networking mode, a container receives a network namespace but no interfaces other than the loopback interface. There is no veth pair and no connection to the host or external networks.
This mode is useful for completely isolated workloads or for advanced setups where you want to configure the container networking yourself using lower level tools. You can later attach custom interfaces or join custom networks without relying on the automatic configuration of the runtime.
Because the loopback interface is still present, processes inside the container can still talk to each other using 127.0.0.1, but no network traffic enters or leaves the namespace until you attach additional interfaces.
User Defined Bridges and Service Naming
The default bridge usually provides only basic connectivity. Container engines also support user defined bridges which add features such as automatic DNS based service discovery between containers.
On a user defined bridge, containers can resolve each other by name instead of by IP address. The runtime maintains a small DNS service that maps container names or assigned aliases to their IP addresses on that bridge. This makes it easier to build application stacks, because one container can connect to another simply by using the other container name as a hostname.
User defined bridges also isolate groups of containers from each other at the L2 level. Containers on one user defined bridge cannot connect to containers on another bridge unless the host routes or proxies the traffic. This allows you to create separate application networks on the same host, for example separating a frontend network from a backend database network.
Overlay Networks and Multi Host Connectivity
When containers on different hosts must talk to each other directly, a local bridge is no longer sufficient. Overlay networks provide a virtual L2 or L3 network that runs on top of an existing underlay IP network, such as an ordinary routed LAN.
Overlay networks encapsulate container packets inside outer packets that travel between hosts. When a packet enters the overlay, the software records which host runs the destination container and forwards the packet there. The receiving host decapsulates the packet and delivers it as if both containers were on the same local network.
This technique allows containers on different machines to share the same overlay subnet and to keep static IP addresses within that subnet, even as the containers move between hosts. Systems like Docker Swarm and many Kubernetes networking plugins use overlays to implement cross host pod or container communication.
Overlay networks introduce some additional overhead due to encapsulation and may require attention to maximum transmission unit sizes inside and outside the overlay. They are however a central mechanism for building distributed container applications.
Container DNS and Service Discovery
Within container environments, DNS is commonly used for service discovery, not only for mapping external domain names but also for resolving container and service names. The container runtime or orchestrator usually provides a small DNS resolver that runs inside the container network.
When a container makes a DNS query to look up the name of another container or a virtual service, the query is intercepted by this internal DNS component. The answer can then refer to the container IP address, to a virtual IP used for load balancing, or to a set of IPs for replica services.
This design allows application code to remain simple. Instead of embedding IP addresses, the code can use stable names such as db or api. Behind the scenes, the orchestrator can move containers, restart them on new nodes, or scale them up and down, while the DNS records are updated transparently.
Security and Isolation in Container Networks
Container networking must balance reachability with isolation. While containers should be able to talk to each other where necessary, you often want to restrict which containers can initiate connections and which can be reached from outside the host.
On Linux, iptables or nftables reappear at the container network layer. Default rules often allow all traffic between containers on the same bridge and rely on port mapping to expose services. More advanced setups restrict inter container communication by applying firewall rules to bridge interfaces, veth devices, or specific container IP ranges.
Some platforms add a policy layer on top of low level firewalls. These systems describe allowed connections in terms of labels or selectors instead of direct IP rules. Underneath, the system converts the policies into iptables or eBPF programs that enforce the desired behavior. While those details belong to container orchestration, it is important to recognize that container networking can be made strongly isolated when required.
At the host boundary, you can also apply ordinary firewall rules to control which external clients may reach which container ports. Since external access usually passes through host ports or through overlay nodes, classic perimeter firewalling remains relevant for containerized services.
Performance Considerations
Each networking mode has performance implications. Bridged networking with NAT introduces some processing overhead due to bridge forwarding and translation rules. Host networking avoids those steps, which can reduce latency and CPU usage for high throughput workloads.
Overlay networks add encapsulation over the underlay network, which consumes extra bytes per packet. If the resulting packet size exceeds the physical network MTU, fragmentation can occur, which may degrade performance. Some solutions adjust the inner MTU or use techniques such as path MTU discovery to mitigate this.
The choice of networking mode and topology therefore depends on the requirements of your application. If you need simple local isolation and basic connectivity, the default bridge is usually adequate. If you require minimal overhead, host networking may be attractive. For distributed applications that span multiple hosts, overlay networks or similar techniques are essential.
Conclusion
Container networking in Linux is built from a few fundamental pieces. Network namespaces isolate stacks, veth pairs connect host and container, bridges create local virtual switches, and NAT or overlay encapsulation extend reach beyond the host. By choosing appropriate network modes and understanding how traffic flows between containers, hosts, and external clients, you can design containerized applications that are both reachable and well isolated.