Linux Network Namespaces and veth Pairs in Practice - 夜莺博客

Linux Network Namespaces and veth Pairs in Practice

Network namespaces are the kernel feature underneath containers, VPN clients and lab topologies. Each namespace gets its own interfaces, routing table, ARP table and firewall rules; a veth pair is a virtual cable with one end in each namespace. Once you can wire that by hand, container networking stops being magic and becomes debuggable. This guide builds a working two-namespace lab step by step.

Create Namespaces and a Cable

ip netns add blue
ip netns add red
ip link add veth-blue type veth peer name veth-red
ip link set veth-blue netns blue
ip link set veth-red netns red
ip netns list

A veth pair is bidirectional: whatever enters one side leaves the other, including broadcast traffic. Namespaces are visible under /var/run/netns/, and ip netns exec runs any command inside one.

Address and Bring Up

ip netns exec blue ip addr add 10.200.1.1/24 dev veth-blue
ip netns exec red  ip addr add 10.200.1.2/24 dev veth-red
ip netns exec blue ip link set veth-blue up
ip netns exec red  ip link set veth-red up
ip netns exec blue ip link set lo up
ip netns exec red  ip link set lo up
ip netns exec blue ping -c2 10.200.1.2

Loopback must be raised separately in every namespace - a surprisingly common cause of "the service is running but nothing can reach it" when a container's health check hits 127.0.0.1.

Reach the Outside World

ip netns exec blue ip route add default via 10.200.1.254
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 10.200.1.0/24 -o eth0 -j MASQUERADE

Give each namespace a default route and NAT the whole subnet on the host. To reach a service inside a namespace from the host, either publish a port with DNAT or give the namespace a bridge instead of a point-to-point veth - the same two models containers expose with host networking and bridged networking.

Debugging Inside a Namespace

ip netns exec blue ss -lntp
ip netns exec blue ip neigh show
ip netns exec blue tcpdump -ni veth-blue
ip netns pids blue
nsenter -t $(ip netns pids blue | head -1) -n ss -lntp

Because each namespace has its own tables, ss, ip route and iptables -L on the host tell you nothing about what a namespace sees. Always scope the command with ip netns exec before concluding "there is nothing listening". The host-side equivalents for ARP and neighbour state are covered in Linux ip neigh and ARP table commands.

Where This Shows Up in Production

  • Container runtimes create exactly this pair for every pod, then plug the host end into a bridge or VXLAN - see Linux VXLAN VTEP configuration.
  • Multi-vendor network labs use namespace-backed containers as routers, described in Containerlab for multi-vendor labs.
  • Bonding and LACP behaviour at the host level interacts with namespace design; the modes are explained in Linux bonding modes with LACP.
  • Keep a naming convention (veth-<ns>) and delete stale namespaces - a host with hundreds of orphaned namespaces and veth pairs is a slow, confusing failure.

原文链接:https://man7.org/linux/man-pages/man8/ip-netns.8.html