LFCE 25 🐧 Network Namespaces — Concepts - KandZ

⏱️ Estimated read: 13 min | |

A network namespace is a logical copy of the kernel’s network stack. It has its own network interfaces, its own routing table, its own firewall rules, and its own set of sockets . Processes inside one network namespace cannot see or communicate with the network resources of another namespace unless a virtual link explicitly connects them. This is the mechanism that underlies containers, VPN isolation, and network testing environments. For the LFCE candidate, network namespaces are the foundation for understanding how Linux provides network isolation without virtual machines, and how virtual Ethernet devices (veth pairs) connect those isolated stacks back together.

The previous chapters covered bridges, VLANs, and bonding—all mechanisms for connecting or segmenting traffic within a single network stack. A network namespace is different: it creates an entirely separate stack. A process in one namespace can have the same IP address as a process in another namespace without conflict, because the two stacks are independent. The only way to connect them is through a veth pair, a virtual cable with one end in each namespace .

Key point: A network namespace is not a container and not a virtual machine. It is a kernel-level isolation of the network stack. By default, every process inherits the network namespace of its parent, and all processes on a normal Linux system share the same default namespace. Creating a new namespace gives a process a blank network stack with only a loopback interface, and connecting it to the outside world requires creating and assigning interfaces manually.

Why network namespaces exist

The isolation problem.

A VPN client needs to route only specific traffic through the tunnel while leaving the rest of the system on the normal path. The traditional approach uses policy routing, covered in earlier chapters. But policy routing operates within a single network stack, and the VPN process can still see and potentially interfere with the host’s interfaces, routes, and firewall rules. A network namespace provides stronger isolation: the VPN process runs in its own stack, with only the tunnel interface and a veth pair connecting it to the host. The host’s routing table is invisible to the process, and the process cannot accidentally send traffic outside the tunnel .

The container networking problem.

A container needs its own network identity—its own IP address, its own routing table, and its own set of open ports—without conflicting with the host or with other containers. A network namespace provides exactly this. The container runtime creates a namespace, places a veth pair with one end in the namespace and the other on a host bridge, and assigns the container an address. The container sees only its own interface; the host sees the other end of the veth pair as a normal interface attached to the bridge . This is the architecture that Docker and Kubernetes use for pod networking.

The testing problem.

Simulating a multi-router topology traditionally requires multiple physical machines or virtual machines. A network namespace can simulate a router: it has its own interfaces, its own routing table, and its own forwarding behavior. A single Linux host can create several namespaces, connect them with veth pairs, and run routing protocols or static routes inside each one. The namespaces are isolated from each other and from the host, but they share the same kernel. This makes it possible to test complex topologies on a single machine .

a. The default namespace and the anatomy of a new one

Every Linux system starts with a single network namespace, the default namespace, which is inherited by the init process and every process that does not explicitly request a different one . When you run ip addr show on a normal system, you are looking at the default namespace.

# Show the current network namespace's interfaces
ip addr show
# Output includes lo, eth0, and any other configured interfaces

# List all named network namespaces
ip netns list
# Output is empty if no namespaces have been created

Creating a new namespace with ip netns add produces a blank stack. It contains only a loopback interface, and that interface is down.

# Create a namespace named "test"
ip netns add test

# List namespaces to confirm creation
ip netns list
# Output: test

# Show interfaces inside the namespace
ip netns exec test ip addr show
# Output: 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN
# No other interfaces exist

The namespace persists as long as it exists in /run/netns/NAME and has at least one process or open file descriptor referencing it. ip netns delete removes the name and, if no processes remain, the namespace itself .

b. Connecting namespaces with veth pairs

A veth pair is a virtual Ethernet cable. It is created as two interconnected interfaces: a packet transmitted on one end is immediately received on the other . By placing one end in one namespace and the other end in another namespace, the two isolated stacks can communicate.

# Create a veth pair
ip link add veth-red type veth peer name veth-blue

# Move one end into the "red" namespace
ip link set veth-red netns red

# Move the other end into the "blue" namespace
ip link set veth-blue netns blue

# Assign addresses inside each namespace
ip netns exec red ip addr add 192.168.15.1/24 dev veth-red
ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue

# Bring up the interfaces and the loopback inside each namespace
ip netns exec red ip link set veth-red up
ip netns exec red ip link set lo up
ip netns exec blue ip link set veth-blue up
ip netns exec blue ip link set lo up

# Test connectivity
ip netns exec red ping -c 2 192.168.15.2
# The ping succeeds because the veth pair connects the two namespaces

The /24 prefix on the address is not optional. Without it, the kernel does not know which destinations are reachable through the interface, and the ping fails with “Network is unreachable” . The loopback interface must also be brought up inside each namespace for local communication to work correctly.

The veth pair is a point-to-point link. If more than two namespaces need to communicate, a bridge is required. One end of each veth pair is attached to a bridge in the host namespace, and the other end is placed in the target namespace. The bridge acts as a virtual switch, forwarding frames between the namespaces .

c. Executing commands and managing lifecycle

The ip netns exec command runs a command inside a named namespace. This is how interfaces are configured, how processes are started, and how connectivity is tested .

# Run a shell inside the namespace
ip netns exec test bash

# Or run a single command
ip netns exec test ip route show
ip netns exec test ss -tlnp

A process can also be moved into an existing namespace with nsenter, or a namespace can be attached to an existing process with ip netns attach. These are useful for debugging and for integrating with container runtimes .

Deleting a namespace does not automatically move its physical interfaces back to the default namespace. If a physical interface was moved into a namespace and the namespace is deleted while a process is still running inside it, the interface remains trapped until the process exits . The correct procedure is to kill the processes first, then delete the namespace.

# Kill processes in the namespace before deletion
ip netns pids test | xargs -r kill

# Delete the namespace
ip netns delete test

Complete Example Session

# ============================================
# PART 1: CREATE TWO NAMESPACES
# ============================================
ip netns add red
ip netns add blue
ip netns list
# Output: red
#         blue

# ============================================
# PART 2: CREATE A VETH PAIR
# ============================================
ip link add veth-red type veth peer name veth-blue
ip link show type veth
# Output: veth-blue@veth-red and veth-red@veth-blue
# Both ends are in the default namespace initially

# ============================================
# PART 3: MOVE EACH END INTO ITS NAMESPACE
# ============================================
ip link set veth-red netns red
ip link set veth-blue netns blue

# Verify the interfaces are gone from the default namespace
ip link show type veth
# Output is empty

# ============================================
# PART 4: CONFIGURE ADDRESSES INSIDE NAMESPACES
# ============================================
ip netns exec red ip addr add 192.168.15.1/24 dev veth-red
ip netns exec blue ip addr add 192.168.15.2/24 dev veth-blue

# ============================================
# PART 5: BRING UP INTERFACES AND LOOPBACK
# ============================================
ip netns exec red ip link set lo up
ip netns exec red ip link set veth-red up
ip netns exec blue ip link set lo up
ip netns exec blue ip link set veth-blue up

# ============================================
# PART 6: VERIFY CONNECTIVITY
# ============================================
ip netns exec red ping -c 2 192.168.15.2
# Output: 2 packets transmitted, 2 received

# ============================================
# PART 7: INSPECT EACH NAMESPACE'S STACK
# ============================================
ip netns exec red ip addr show
# Output: lo (up) and veth-red (192.168.15.1/24, up)

ip netns exec red ip route show
# Output: 192.168.15.0/24 dev veth-red proto kernel scope link src 192.168.15.1

# ============================================
# PART 8: CREATE A THIRD NAMESPACE AND CONNECT VIA BRIDGE
# ============================================
ip netns add green
ip link add br0 type bridge
ip link set br0 up

ip link add veth-green type veth peer name veth-green-br
ip link set veth-green netns green
ip link set veth-green-br master br0
ip link set veth-green-br up

ip netns exec green ip addr add 192.168.15.3/24 dev veth-green
ip netns exec green ip link set lo up
ip netns exec green ip link set veth-green up

# ============================================
# PART 9: VERIFY BRIDGE CONNECTIVITY
# ============================================
# The red and blue namespaces are connected by a direct veth pair.
# To connect green to red, red's veth would also need to be on a bridge.
# For a multi-namespace topology, all namespaces connect to the bridge.

# ============================================
# PART 10: CLEAN UP
# ============================================
ip netns pids red | xargs -r kill
ip netns pids blue | xargs -r kill
ip netns pids green | xargs -r kill
ip netns delete red
ip netns delete blue
ip netns delete green
ip link delete br0

The ten parts demonstrate the complete namespace lifecycle: creation, veth pair creation, interface migration, address assignment, connectivity testing, and cleanup. The critical verification is ip netns exec red ip addr show, which confirms the interface exists inside the namespace with the correct address.

Quick Reference

Namespace Commands

Task	Command
Create namespace	`ip netns add <name>`
List namespaces	`ip netns list`
Execute command	`ip netns exec <name> <cmd>`
Show processes	`ip netns pids <name>`
Delete namespace	`ip netns delete <name>`
Attach to process	`ip netns attach <name> <pid>`

Veth Commands

Task	Command
Create pair	`ip link add <p1> type veth peer name <p2>`
Move to namespace	`ip link set <if> netns <name>`
Show veth peers	`ip link show type veth`

Inside-Namespace Configuration

Task	Command (prefixed by `ip netns exec <name>`)
Show interfaces	`ip addr show`
Assign address	`ip addr add <addr>/<prefix> dev <if>`
Bring up	`ip link set <if> up`
Show routes	`ip route show`
Test connectivity	`ping <addr>`

Best Practices

✅ Do This:

# Always bring up loopback inside the namespace
ip netns exec red ip link set lo up                          # ✅

# Use a prefix on the address (/24 or /30)
ip netns exec red ip addr add 192.168.15.1/24 dev veth-red   # ✅

# Kill processes before deleting a namespace
ip netns pids red | xargs -r kill                            # ✅

# Use a bridge for more than two namespaces
ip link set veth-br master br0                               # ✅

# Verify the interface is inside the namespace
ip netns exec red ip addr show                               # ✅

❌ Don’t Do This:

# Assign an address without a prefix
ip netns exec red ip addr add 192.168.15.1 dev veth-red      # ❌ No route

# Forget to bring up lo
ip netns exec red ping 127.0.0.1                             # ❌ Fails if lo is down

# Delete a namespace with running processes
ip netns delete red    # Interface may be trapped               # ❌

# Expect veth pairs to work like a switch
# A veth pair connects exactly two endpoints                  # ❌

# Assume physical interfaces return automatically
# They remain in the namespace until processes exit           # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Ping fails with “Network is unreachable”	Address assigned without prefix	Use `/24` or appropriate prefix
Loopback unreachable	`lo` interface is down by default	`ip netns exec <ns> ip link set lo up`
Interface not visible in namespace	Not moved with `ip link set ... netns`	Move the interface before configuring
Cannot delete namespace	Processes still running inside	`ip netns pids <ns> \| xargs kill`
Physical interface trapped	Namespace deleted with running process	Kill processes first

Real-World Examples

1. Create a namespace

ip netns add test

2. Create a veth pair

ip link add veth0 type veth peer name veth1

3. Move an interface into a namespace

ip link set veth0 netns test

4. Configure an address inside a namespace

ip netns exec test ip addr add 10.0.0.1/24 dev veth0

5. Bring up interfaces inside a namespace

ip netns exec test ip link set veth0 up
ip netns exec test ip link set lo up

6. Test connectivity

ip netns exec test ping 10.0.0.2

7. Run a shell inside a namespace

ip netns exec test bash

8. List processes in a namespace

ip netns pids test

9. Delete a namespace

ip netns delete test

10. Show all namespaces

ip netns list

Visual

Network Namespace Isolation

┌──────────────────────────────────────────────────────────────┐
│  EACH NAMESPACE HAS ITS OWN COMPLETE NETWORK STACK           │
│                                                              │
│  ┌─────────────────────┐    ┌─────────────────────┐          │
│  │ NAMESPACE: red      │    │ NAMESPACE: blue     │          │
│  │                     │    │                     │          │
│  │ ┌─────────────────┐ │    │ ┌─────────────────┐ │          │
│  │ │ Routing Table   │ │    │ │ Routing Table   │ │          │
│  │ │ 192.168.15.0/24 │ │    │ │ 192.168.15.0/24 │ │          │
│  │ └─────────────────┘ │    │ └─────────────────┘ │          │
│  │ ┌─────────────────┐ │    │ ┌─────────────────┐ │          │
│  │ │ Firewall Rules  │ │    │ │ Firewall Rules  │ │          │
│  │ └─────────────────┘ │    │ └─────────────────┘ │          │
│  │ ┌─────────────────┐ │    │ ┌─────────────────┐ │          │
│  │ │ veth-red        │ │    │ │ veth-blue       │ │          │
│  │ │ 192.168.15.1/24 │ │    │ │ 192.168.15.2/24 │ │          │
│  │ └────────┬────────┘ │    │ └────────┬────────┘ │          │
│  └──────────┼──────────┘    └──────────┼──────────┘          │
│             │                          │                     │
│             └──────────┬───────────────┘                     │
│                        │                                     │
│                   veth pair                                  │
│              (virtual Ethernet cable)                        │
│                                                              │
│  The two namespaces are isolated.                            │
│  The veth pair is the only connection between them.          │
└──────────────────────────────────────────────────────────────┘

Multi-Namespace Topology with a Bridge

┌──────────────────────────────────────────────────────────────┐
│  BRIDGE CONNECTS MORE THAN TWO NAMESPACES                    │
│                                                              │
│  ┌─────────┐    ┌─────────┐    ┌─────────┐                   │
│  │ red     │    │ blue    │    │ green   │                   │
│  │ veth-r  │    │ veth-b  │    │ veth-g  │                   │
│  └────┬────┘    └────┬────┘    └────┬────┘                   │
│       │              │              │                        │
│       ▼              ▼              ▼                        │
│  ┌─────────────────────────────────────────────┐             │
│  │              br0 (bridge)                   │             │
│  │         (virtual switch in host)            │             │
│  └─────────────────────────────────────────────┘             │
│                                                              │
│  Each namespace has one end of a veth pair.                  │
│  The other end is attached to the bridge.                    │
│  All namespaces can communicate through the bridge.          │
└──────────────────────────────────────────────────────────────┘

The Default Namespace and Process Inheritance

┌──────────────────────────────────────────────────────────────┐
│  PROCESSES INHERIT THEIR PARENT'S NETWORK NAMESPACE          │
│                                                              │
│  init (PID 1)                                                │
│  └── default namespace                                       │
│       ├── sshd                                               │
│       ├── bash                                               │
│       └── your_process                                       │
│                                                              │
│  All share the same interfaces, routes, and firewall rules.  │
│                                                              │
│  When a process calls unshare(CLONE_NEWNET):                 │
│  ┌────────────────────────────────────────────────────────┐  │
│  │ New process gets a blank namespace                     │  │
│  │ Only lo exists, and it is down                         │  │
│  │ No routes, no firewall rules, no interfaces            │  │
│  └────────────────────────────────────────────────────────┘  │
│                                                              │
│  The process is now isolated from the host network.          │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Definition	Logical copy of the kernel network stack
Contents	Interfaces, routes, firewall rules, sockets
Default state	All processes share the default namespace
New namespace	Only `lo` interface, down
Connection mechanism	veth pair (virtual Ethernet cable)
Bridge use	Connect more than two namespaces
Command execution	`ip netns exec <name> <cmd>`
Persistence	Named namespace at `/run/netns/NAME`
Cleanup	Kill processes, then delete namespace

Key takeaways:

A network namespace is a complete, isolated network stack. It has its own interfaces, routing table, and firewall rules. Processes inside it cannot see the host’s network resources unless a veth pair connects them .
A new namespace contains only a down loopback interface. Nothing works until the administrator creates or moves interfaces into the namespace and brings them up. The loopback must be brought up explicitly.
A veth pair is the virtual cable between namespaces. Packets transmitted on one end are received on the other. One end is placed in each namespace to connect them .
Addresses inside a namespace require a prefix. Without /24 or /30, the kernel has no route for the subnet, and ping fails with “Network is unreachable” .
A bridge extends connectivity beyond two namespaces. Each namespace gets one end of a veth pair; the other end is attached to a bridge in the host. The bridge forwards frames between all attached namespaces .
Deleting a namespace with running processes can trap interfaces. The physical interface remains in the namespace until the process exits. Kill the processes before deleting the namespace .

Remember: A network namespace is the kernel’s mechanism for giving a process its own private network. It is the foundation of container networking and VPN isolation. The namespace starts empty, with only a down loopback. A veth pair is the cable that connects it to another namespace or to a bridge. The ip netns command family creates, configures, and destroys these isolated stacks. Configure the interface, bring up loopback, assign an address with a prefix, and test with ping. The namespace is invisible to the host until a veth pair makes the connection.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!