A Reproducible Namespace Routing Lab

Start with a bounded question

The question is deliberately small: can a process in a separate network namespace reach one address on its host through a virtual Ethernet pair? This procedure follows the namespace model described at Fig. It does not configure Internet access, a default route, address translation or a bridge. Keeping those features out makes the boundary easier to inspect.

The commands below describe a proposed lab, not a measurement from a live deployment. Use a disposable Linux environment with iproute2 and ping installed. Creating namespaces and links requires administrative privileges. A container without the relevant capabilities may correctly reject these operations. Do not grant a production application broad privileges just to run this exercise.

Before starting, inspect existing namespace and interface names. The example uses cloudthe-ns, ct-host and ct-peer. If any already exist, choose different names throughout the procedure. Also check that the example subnet does not overlap a route your environment already uses. Interface names must remain short enough for the Linux interface-name limit.

ip netns list
ip link show
ip route show

Create the boundary before the connection

Create the namespace first and inspect its interfaces. Bringing up its loopback interface makes local loopback communication possible; it does not connect the namespace to the host or the Internet.

sudo ip netns add cloudthe-ns
sudo ip -n cloudthe-ns link set lo up
sudo ip -n cloudthe-ns address show
sudo ip -n cloudthe-ns route show

The expected starting condition is a loopback interface and no route for the example host address. Record the actual output. If the environment has additional configuration, stop and explain it before continuing. An experiment that begins with an unexplained route table cannot establish which step created connectivity.

Connect one pair of interfaces

A veth pair provides two connected virtual interfaces. Leave one end in the host namespace and move the other into the lab namespace. Assign the two example addresses and bring up both ends.

sudo ip link add ct-host type veth peer name ct-peer
sudo ip link set ct-peer netns cloudthe-ns
sudo ip address add 198.18.42.1/30 dev ct-host
sudo ip link set ct-host up
sudo ip -n cloudthe-ns address add 198.18.42.2/30 dev ct-peer
sudo ip -n cloudthe-ns link set ct-peer up

These addresses are examples from an address range reserved for benchmarking. Their use here is local and contained; the procedure does not advertise or forward the subnet. Address assignment normally creates a connected route for the small subnet. Inspect both route tables rather than assuming that the route appeared.

ip route show dev ct-host
sudo ip -n cloudthe-ns route show
sudo ip -n cloudthe-ns route get 198.18.42.1

The route lookup should select ct-peer with the namespace address as the source. A route lookup describes the selected path. It does not establish that a firewall will permit the packet or that the peer will answer.

Check the path and a contained failure

Try a short ping from the namespace to the host-side address. Avoid an unbounded command: three probes are enough for this particular reachability check.

sudo ip netns exec cloudthe-ns ping -c 3 198.18.42.1
ip -s link show ct-host
sudo ip -n cloudthe-ns -s link show ct-peer

Successful replies establish that this path carried these probes under the current rules. They do not establish application readiness, throughput, Internet access or the behavior of a different protocol. If replies fail, compare route selection and interface counters. Host firewall policy may reject ICMP even when routing is correct. Inspect the relevant rules without disabling the host firewall.

For one controlled failure, bring down the host-side lab interface, repeat the bounded check, then restore it. The operation affects only the interface created for this lab. Record whether the failure appears as a timeout, an unreachable response or another local error; the exact symptom can depend on the environment.

sudo ip link set ct-host down
sudo ip netns exec cloudthe-ns ping -c 3 -W 1 198.18.42.1
sudo ip link set ct-host up

Remove what the procedure created

Check for processes still using the namespace. The short inspection commands should have exited. Do not delete a namespace that belongs to an unrelated service, and do not indiscriminately kill every process on the host.

sudo ip netns pids cloudthe-ns
sudo ip link delete ct-host
sudo ip netns delete cloudthe-ns
ip netns list
ip link show

Deleting one end of the veth pair removes the pair. A namespace name can be removed while a process still holds the namespace alive, which is why the process check matters. Compare the final names with the starting inventory and record any resources that remain.

Write the result as a narrow claim

A useful record includes the kernel and iproute2 versions, initial routes, commands, interface counters, the bounded probes and final cleanup. Keep expected observations separate from actual observations. The strongest conclusion supported by this procedure concerns one namespace boundary and one local path. Additional forwarding, DNS or application behavior needs its own question and setup.

For the underlying semantics, consult network_namespaces(7), veth(4) and ip-netns(8).