A Linux network namespace gives processes a separate view of network devices, IP stacks, routing tables, firewall rules, and socket ports. A veth pair joins two endpoints so packets sent through one arrive at the other. The pair supplies a link; it does not automatically assign addresses, install routes, enable forwarding, or create a complete path to another network.

Concept diagram of two isolated Linux network stacks linked by a veth pair, with routing configured separately

What a network namespace separates

A network namespace scopes the networking resources visible to the processes that use it. Interfaces, addresses, IPv4 and IPv6 stacks, routes, firewall state, and port space are maintained in that context. Two namespaces can therefore use the same interface name or port number without referring to the same network object. A route change made in one namespace does not rewrite another namespace’s routing table.

That boundary changes how troubleshooting commands should be read. A route listing describes the namespace in which the command ran. Looking only at the host’s table can miss the route selected by a container or another isolated process. Firewall inspection has the same context requirement: identify which namespace owns the rules before interpreting a drop or an apparent allow.

A veth pair behaves like a connected cable

Virtual Ethernet devices are created as a pair. A frame sent through one endpoint is received at its peer. If the endpoints are placed in different network namespaces, the pair forms a virtual link between those spaces. Red Hat’s hands-on example creates two namespaces, assigns one veth endpoint to each, and configures addresses so the directly connected endpoints can communicate.

The distinction between link and network matters. A veth pair is not a complete tunnel architecture or a router. The interfaces must be brought up, and addresses must be assigned consistently for the endpoints to exchange traffic at the IP layer. If one endpoint goes down, the peer’s link state goes down as well, so inspect both ends when a connection disappears.

Link connectivity does not create a route

Two addresses on the same connected subnet can usually reach each other once the interfaces are up and the neighbor-resolution exchange succeeds. Sending a packet to a different subnet requires a route that selects a next hop. If the path crosses several namespaces or a host, each forwarding boundary needs a valid next step. The route table inside one namespace cannot stand in for the table in another.

A common container setup adds a bridge or connects a host-side veth to another network device. That adds topology; it still does not mean every packet will be forwarded automatically. Reaching an external network may also require IP forwarding, firewall rules, and sometimes address translation. Those settings are operational choices made by the network configuration or container runtime.

So when a veth pair is present but an application cannot reach its destination, separate the checks: Are both interfaces up? Do the addresses and prefixes match the intended link? Which route does the source namespace select? Does the peer receive the packet? If the packet must continue through a host or router, is forwarding allowed there, and do firewall rules permit the flow? This sequence localizes the failure without treating the virtual cable as the entire network.

Follow the packet across each boundary

Start from the process’s actual network namespace, not from the machine name shown in a shell prompt. Identify its interface and route, then check whether the frame arrives at the peer endpoint. Continue from the peer’s namespace and inspect the next route only if the packet must travel farther. A capture or counter at each side of the veth can help show which boundary the packet crossed, but the observation must be made in the correct namespace.

Network namespaces isolate networking resources within the shared Linux kernel; they are not complete virtual machines. A veth pair also does not, by itself, guarantee security or end-to-end isolation. Reachability and isolation depend on interface placement, permissions, routes, forwarding settings, and firewall policy.

Sources