Linux Network Namespaces and VRFs: A Hands-On Lab

A single Linux host frequently has to behave like several routers: separate tenants with overlapping address space, a management plane isolated from production, or a lab that must not leak traffic into the host's default route table. Linux offers two mechanisms that look similar and are frequently confused — network namespaces and VRF devices. Namespaces give complete device-level isolation: interfaces, routes, firewall rules and even the port space are separate. VRF devices keep everything in one namespace but attach interfaces to separate FIB tables. This lab builds both, so the difference is obvious in the command output rather than in the documentation.

Namespaces: complete isolation

The ip netns command manages named namespaces stored under /var/run/netns. Devices, routing tables, ARP tables, iptables rules and /proc/sys/net settings all live inside, and a per-namespace configuration file convention (/etc/netns/NAME/) lets unaware applications see different resolver settings.

# create two namespaces and a virtual cable between them
ip netns add red
ip netns add blue

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

ip netns exec red  ip addr add 10.0.1.1/24 dev veth-red
ip netns exec blue ip addr add 10.0.1.2/24 dev veth-blue

ip netns exec red  ip link set veth-red up
ip netns exec blue ip link set veth-blue up
ip netns exec red  ip link set lo up
ip netns exec blue ip link set lo up

ip netns exec red ping -c 2 10.0.1.2
ip netns exec red ip route

Note that lo is down by default inside a new namespace, which breaks anything that expects a loopback address. The second point worth internalising: a physical device can live in exactly one namespace, and when a namespace is destroyed its veth devices are destroyed with it — unlike physical interfaces, which return to the initial namespace.

To connect a namespace to the outside world, attach one end of a veth pair to a bridge in the host namespace, or create a bridge inside the namespace and connect physical ports into it. The same veth plumbing used for VXLAN tunnels described in Linux VXLAN with ip link applies here.

VRF devices: isolated tables in one namespace

A VRF device is created with an associated routing table; interfaces are enslaved to it, and a single l3mdev FIB rule sends lookups for those interfaces to that table. This is the Linux equivalent of VRF-lite.

ip link add vrf-blue type vrf table 10
ip link set vrf-blue up

# create an interface and put it in the VRF
ip link add veth0 type veth peer name veth1
ip link set veth0 master vrf-blue
ip addr add 10.10.10.1/24 dev veth0
ip link set veth0 up

ip route show table 10
ip -6 route get 2002:1::32 vrf blue

# policy routing takes precedence over the VRF rule
ip rule add pref 100 from 10.10.10.55 lookup 20

# remove the interface from the VRF
ip link set dev veth0 nomaster

When an interface is enslaved, connected and local routes move automatically into the VRF's table. The default preference for the automatically inserted l3mdev rule is 1000, so any rule with a lower (higher priority) preference — for example a PBR rule matching a specific source — is evaluated first.

Which one to reach for

The practical guidance: use VRFs when the host is acting as a router and you simply need separate routing domains; use namespaces when you need process-level isolation or when two tenants genuinely cannot share the same TCP port range. The two compose — namespaces provide device-layer separation, VLANs inside a namespace provide Layer 2 separation, and VRFs provide Layer 3 separation.

Troubleshooting habits

ip netns list
ip netns identify PID
ip netns pids red
ip -all netns exec ip addr
ip netns monitor

Most confusion comes from running a command in the wrong namespace. If ss -lntp does not show a listening socket that the service insists exists, run the same command with ip netns exec before restarting anything. For production services, a namespace can also be used to pin a VPN client away from the host's default route, as described in hardened OpenVPN server setup on Linux, and container runtimes build directly on this primitive — the failure signatures in Kubernetes node NotReady troubleshooting frequently trace back to a namespace whose veth never came up.

原文链接：https://www.kernel.org/doc/html/v6.3/networking/vrf.html