Technical guide

Linux Network Namespaces Explained: Build a Virtual Network on One Host

By Subnetica · Published August 18, 2026 · Updated August 18, 2026

A Linux network namespace is an independent network stack. Give several namespaces interfaces, addresses, routes, and virtual Ethernet connections, and one machine can behave like multiple hosts, switches, and routers without pretending they share one routing table.

What a namespace isolates

Each namespace gets its own interfaces, IP addresses, routing table, neighbor/ARP table, firewall state, and loopback interface. The host kernel still provides the machinery, but a process placed in namespace host-a sees a different network world from a process in namespace host-b.

The namespace starts with a loopback device that is normally down. Bring it up before relying on software that expects localhost to work. The namespace does not magically have a connection to the outside world; connectivity appears only when you create and connect interfaces.

veth pairs are virtual Ethernet cables

A veth pair always has two endpoints. A packet written to one endpoint appears at the other. Move one endpoint into host-a and the other into router, and you have a link between those namespaces. Repeat the operation for router and host-b.

sudo ip netns add host-a
sudo ip netns add router
sudo ip netns add host-b

sudo ip link add veth-a type veth peer name veth-r1
sudo ip link add veth-b type veth peer name veth-r2
sudo ip link set veth-a netns host-a
sudo ip link set veth-r1 netns router
sudo ip link set veth-b netns host-b
sudo ip link set veth-r2 netns router

These commands require root privileges and change the host’s live network configuration. Use an isolated test machine or a disposable VM, and keep a recovery path. The commands create only the links; they do not assign addresses, enable forwarding, or make the links operational.

Bring the links and loopbacks up

Configure each namespace from the outside with ip netns exec. The endpoint names are local to their namespace after the move.

sudo ip netns exec host-a ip link set lo up
sudo ip netns exec router ip link set lo up
sudo ip netns exec host-b ip link set lo up

sudo ip netns exec host-a ip link set veth-a up
sudo ip netns exec router ip link set veth-r1 up
sudo ip netns exec router ip link set veth-r2 up
sudo ip netns exec host-b ip link set veth-b up

sudo ip netns exec host-a ip addr add 192.0.2.2/24 dev veth-a
sudo ip netns exec router ip addr add 192.0.2.1/24 dev veth-r1
sudo ip netns exec router ip addr add 198.51.100.1/24 dev veth-r2
sudo ip netns exec host-b ip addr add 198.51.100.2/24 dev veth-b

At this point each directly connected subnet should be visible only in the namespace that owns the interface. Verify the separation:

sudo ip netns exec host-a ip -br addr
sudo ip netns exec host-a ip route
sudo ip netns exec router ip route
sudo ip netns exec host-b ip neigh

Make the router namespace route

Host A knows how to reach 192.0.2.0/24; Host B knows how to reach 198.51.100.0/24. Neither host knows the other network is behind the router. Add routes to the remote subnet and enable IPv4 forwarding in the router namespace.

sudo ip netns exec host-a ip route add 198.51.100.0/24 via 192.0.2.1
sudo ip netns exec host-b ip route add 192.0.2.0/24 via 198.51.100.1
sudo ip netns exec router sysctl -w net.ipv4.ip_forward=1

sudo ip netns exec host-a ping -c 3 198.51.100.2
sudo ip netns exec host-a ip route get 198.51.100.2

Forwarding is a router function, not a property of merely having two interfaces. If the ping fails, check link state, addresses, both return routes, neighbor entries, and the router’s forwarding setting. Network namespaces make this troubleshooting concrete because each command can be run from the exact node whose view matters.

Bridges act like virtual switches

A Linux bridge connects ports at Layer 2. Attach several namespace veth endpoints to the bridge and they share an Ethernet broadcast domain. The bridge learns MAC addresses and forwards frames between ports; it does not replace the IP routing table. A router namespace or the host itself can have an IP address on a bridge when it needs to participate at Layer 3.

sudo ip link add br-lan type bridge
sudo ip link set br-lan up

# Create a separate cable to the bridge for host-a.
# These names are different from the veth-a/veth-r1 pair above.
sudo ip link add veth-switch-a type veth peer name veth-bridge-a
sudo ip link set veth-switch-a netns host-a
sudo ip link set veth-bridge-a master br-lan
sudo ip netns exec host-a ip link set veth-switch-a up
sudo ip link set veth-bridge-a up

# Inspect bridge ports and learned MAC addresses
bridge link
bridge fdb show

In real setups, connect the bridge to a namespace endpoint or a host-facing interface deliberately. Avoid attaching production interfaces to an experimental bridge without understanding the impact.

From namespaces to a virtual router

A namespace can run a routing daemon such as FRRouting and behave like a router:

FRR’s protocol daemon learns routes, Zebra selects and coordinates them, and the Linux kernel forwards packets through R1’s namespace. That is the same FRRouting-to-Linux route pipeline described in the companion article, just with virtual links instead of physical interfaces.

Why this matters for containers and labs

Containers use namespaces to isolate process and network views. Kubernetes networking builds on related primitives, often combining namespaces, veth pairs, bridges or other virtual devices, routing, and policy. Network emulators use them to model hosts and routers cheaply. The concepts transfer: inspect the namespace’s own interfaces and routes, then follow the packet across each virtual link.

Subnetica’s virtual networking environments use Linux networking primitives and FRRouting to make routing behavior observable and practiceable without exposing private infrastructure details. See the Routing curriculum, the OSPF topic, and the OSPF single-area lab. The lab environment uses FRRouting and Linux networking with Cisco-like routing syntax; it is not Cisco IOS, so verify behavior with the Linux state as well as the CLI.

Clean up a disposable experiment

sudo ip netns del host-a
sudo ip netns del router
sudo ip netns del host-b
sudo ip link del br-lan  # only if you created it in the root namespace

Deleting a namespace removes its contained interfaces and routes. Treat cleanup as part of the experiment so the host does not accumulate stale virtual devices.