Network Namespaces and Virtual Networking

Linux can give processes separate network stacks with network namespaces. Each namespace has its own interfaces, routes, addresses, neighbor table, firewall rules, sockets, and /proc/net view. Containers, Kubernetes pods, test labs, and service meshes all build on this idea.

Virtual networking connects those isolated stacks with veth pairs, bridges, routing, NAT, overlays, and policy.

Command Examples

ip netns list
lsns -t net
readlink /proc/<pid>/ns/net
nsenter --target <pid> --net -- ip addr
nsenter --target <pid> --net -- ip route

Example output and meaning:

Always confirm which namespace owns the socket or interface before debugging routes or captures.

Core Building Blocks

These are composable. A container may have eth0 in its namespace, backed by a veth peer on the host, attached to a bridge, then NATed out of the node.

Minimal Namespace Lab

Create two namespaces connected through veth:

sudo ip netns add left
sudo ip netns add right
sudo ip link add veth-left type veth peer name veth-right
sudo ip link set veth-left netns left
sudo ip link set veth-right netns right
sudo ip -n left addr add 10.10.0.1/24 dev veth-left
sudo ip -n right addr add 10.10.0.2/24 dev veth-right
sudo ip -n left link set veth-left up
sudo ip -n right link set veth-right up
sudo ip -n left ping -c 3 10.10.0.2

Delete when done:

sudo ip netns del left
sudo ip netns del right

This lab teaches the core container pattern without Docker or Kubernetes.

Bridges and NAT

A common host-container shape:

container netns eth0
  -> veth peer on host
  -> Linux bridge
  -> host route / NAT
  -> physical NIC

Useful checks:

ip link show type bridge
bridge link
bridge fdb show
nft list ruleset
conntrack -L 2>/dev/null | head

If the bridge learns no MAC address, L2 is broken. If bridge forwarding works but external traffic fails, check routing, NAT, firewall policy, and return path.

macvlan, ipvlan, and Host Reachability

macvlan and ipvlan attach virtual interfaces directly to a parent interface model. They are useful when workloads need first-class addresses on the physical network, but host-to-child reachability can surprise people.

Cloud networks and hypervisors often restrict unknown MACs, making macvlan a poor fit.

VXLAN and Overlays

VXLAN wraps L2 frames in UDP, commonly port 4789, so workloads can share an overlay network across routed underlays.

Key troubleshooting points:

• Underlay IP routing must work first.
• Effective MTU is smaller because encapsulation adds headers.
• Firewalls must allow overlay UDP traffic.
• Control plane must distribute endpoint and VNI information.
• Packet captures may need both overlay and underlay vantage points.

CNI-Style Packet Paths

Kubernetes CNI plugins combine these primitives differently:

The first debugging step is identifying the plugin and datapath mode. Do not assume every cluster uses a Linux bridge.

Runbook

1. Find the process PID and network namespace.
2. Run ip addr, ip route, and ss inside that namespace.
3. Map namespace interfaces to host veth peers with ip link.
4. Check bridge membership, FDB entries, routes, NAT, and firewall counters.
5. Capture inside the namespace and on the host peer when possible.
6. For overlays, check underlay reachability, UDP encapsulation, and MTU.
7. For Kubernetes, identify the CNI plugin before applying generic fixes.

Study Cards

References

• network_namespaces(7)
• veth(4)
• ip-netns(8)
• Linux bridge documentation
• VXLAN Linux kernel documentation