Topic 05: Virtual Networking, veth Pairs & Network Namespaces

Target Duration: 2–4 minutes (~300–450 spoken words)
Focus: Pointwise verbal delivery covering anonymous network namespace linking, veth pair plumbing, dynamic subnet allocation, and resolving the kernel IPv6 DAD race condition.

🎙️ Pointwise Spoken Speech (Word-for-Word Delivery)

• Opening & Scope:
  "For container networking, I built a virtual networking subsystem that bridges isolated container network namespaces to the host using virtual Ethernet pairs, dedicated subnets, and routing."

• Step 1: Solving the Anonymous Network Namespace Discovery Issue:
  "First, when a container is created with an isolated network namespace, the kernel leaves it anonymous—meaning standard host network tools cannot discover it because it lacks a named reference in /var/run/netns. To solve this, I located the container supervisor's PID and created a symlink from /proc/<pid>/ns/net into /var/run/netns/<name>. This immediately made the container's private network stack manageable from the host using standard ip netns commands."

• Step 2: Plumbing Virtual Ethernet (veth) Pairs:
  "Next, to establish a communication link across the namespace boundary, I created a virtual Ethernet (veth) pair. A veth pair behaves like a virtual patch cable: packets pushed into one end instantly emerge on the other. I kept one endpoint on the host and moved the peer endpoint directly into the container's network namespace."

• Step 3: Allocating Subnets and Assigning IP Addresses:
  "Then, I dynamically allocated a private /24 subnet for each container—such as 192.168.1.0/24 for container A and 192.168.2.0/24 for container B. I assigned .1 to the host endpoint and .2 to the container endpoint, giving each container a unique, collision-free IP space."

• Step 4: Activating Links and Resolving the IPv6 DAD Race Condition:
  "After assigning IPs, I explicitly brought up both the container's virtual interface and its loopback interface, because in a new network namespace, lo starts in the DOWN state by default. Here, I hit a tricky kernel race condition: on interface activation, IPv6 triggers Duplicate Address Detection (DAD), marking the IP as tentative. If you immediately try to assign routes, the kernel fails with a route assignment error. To fix this, I wrote a polling retry loop that checks the interface state and waits for the tentative flag to clear before applying routing rules."

• Step 5: Configuring the Default Gateway:
  "Finally, I added a default route inside the container's routing table pointing all non-local traffic to the host's veth IP address (.1). This directs all outgoing packets across the virtual cable to the host kernel, ready for internet egress or inter-container routing."

📋 Step-by-Step Summary (What, How & Why)

❓ Anticipated Interview Questions & Crisp Answers

Q1: Why use a veth pair instead of macvlan or ipvlan?

Answer: macvlan and ipvlan bind virtual interfaces directly to the host's physical network adapter, bypassing the host's Netfilter and routing stack. A veth pair terminates in the host network namespace, allowing the host kernel to act as a full router and firewall where we can inspect, filter, NAT, and peer traffic between containers using standard routing and iptables rules.

Q2: What happens to the container's virtual interface when the container dies?

Answer: Network namespaces in Linux are destroyed by the kernel when all referencing processes terminate. When the container namespace is destroyed, the kernel automatically removes all interfaces inside it and tears down the paired host-side veth endpoint cleanly.

Q3: Why is manual /var/run/netns symlinking needed when using unshare --net?

Answer: unshare creates a network namespace attached only to the process's file descriptors. iproute2 management commands (ip netns) require a filesystem mount point or symlink in /var/run/netns to locate and reference the namespace descriptor.