↓Skip to main content
it’s-a me

Docker Without Limits: Real Networking with Open vSwitch & DHCP

·3 mins
Container Docker Openvswitch
Ali Nasrolahi
Author
Ali Nasrolahi
I do some C stuff :)
Table of Contents

Introduction
#

While Docker’s built-in networking provides convenience for container communication, its default bridge networking model can be limiting for advanced use cases. When integrating containers into existing network infrastructure—particularly in environments using Open vSwitch (OVS) or requiring external DHCP services—greater control over network configuration becomes essential.

This guide demonstrates how to:

  • Decouple containers from Docker’s default networking
  • Integrate container interfaces directly with Open vSwitch
  • Delegate IP assignment to an external DHCP server

This approach enables containers to participate in your network as first-class citizens, compatible with existing VLAN configurations, network policies, and monitoring systems.

Prerequisites
#

To follow this guide effectively, you should understand:

  • Linux network namespaces
    Containers leverage kernel namespaces to maintain isolated network stacks, including interfaces, routing tables, and firewall rules.

  • Docker networking fundamentals
    Familiarity with Docker’s bridge networks, overlay networks, and the docker network command family.

  • Open vSwitch (OVS) architecture
    Understanding of OVS bridges, ports, and flow tables is recommended for production implementations.

  • DHCP protocol operation
    Knowledge of DHCP discovery, offer, request, and acknowledgment (DORA) process.

For reference materials, see the References section.

Container Networking Fundamentals
#

Containers rely on several Linux kernel features for network isolation:

  1. Network namespaces - Provide isolated network stacks
  2. veth pairs - Virtual Ethernet devices that connect namespaces
  3. Control groups (cgroups) - Manage resource allocation

When Docker creates a container with --network=none, it establishes:

  • A new network namespace
  • Only the loopback interface (lo)
  • No default route or external connectivity

This blank slate allows for custom network configuration while maintaining other container isolation properties.

Solution Architecture
#

Our approach involves:

  1. Container initialization without Docker networking
  2. Manual veth pair creation
  3. OVS bridge integration
  4. External DHCP assignment

Step 0: Environment Verification
#

Confirm your environment meets these requirements:

  • Docker Engine installed (v20.10+ recommended)
  • Open vSwitch installed (ovs-vsctl available)
  • Pre-configured OVS bridge with uplink connectivity
  • DHCP server reachable from bridge network
  • Administrative privileges (sudo/root access)

Step 1: Launch Container Without Network
#

Start a disposable Alpine Linux container with no network stack:

docker run --rm --network=none -dit --name ovs-dhcp-test alpine ash

Step 2: Establish veth Connectivity
#

  1. Identify the container’s process ID:
CONTAINER_PID=$(docker inspect -f '{{.State.Pid}}' ovs-dhcp-test)
  1. Create the veth pair:
ip link add veth-host type veth peer name veth-cont
ip link set veth-cont netns $CONTAINER_PID
  1. Verify interface in container namespace:
nsenter -t $CONTAINER_PID -n ip link show

Step 3: Integrate with Open vSwitch
#

  1. Add host interface to OVS bridge:
ovs-vsctl add-port br0 veth-host
ip link set veth-host up
  1. Activate container interface:
nsenter -t $CONTAINER_PID -n ip link set veth-cont up

Step 4: DHCP Configuration
#

For Alpine containers (using udhcpc):

nsenter -t $CONTAINER_PID -m -n -- udhcpc -i veth-cont -f -q

For Debian/Ubuntu containers (using dhclient):

nsenter -t $CONTAINER_PID -m -n -- dhclient -v veth-cont

Security Note: Prefer nsenter over --privileged containers for network configuration to maintain principle of least privilege.

Verification
#

Confirm network functionality:

docker exec ovs-dhcp-test ping -c 3 8.8.8.8
docker exec ovs-dhcp-test ip addr show veth-cont

Conclusion
#

This integration pattern provides several advantages:

  • Network Consistency - Containers behave like traditional hosts
  • Infrastructure Integration - Leverages existing DHCP and switching infrastructure
  • Policy Enforcement - Enables OVS flow rules and QoS policies
  • Visibility - Container traffic appears in standard network monitoring

While more complex than Docker’s default networking, this approach is invaluable when containers must participate in broader network architectures.

References
#