Tools: Exploring Linux Network Namespaces and Virtual Ethernet - Complete Guide

Tools: Exploring Linux Network Namespaces and Virtual Ethernet - Complete Guide

Understanding the Linux Network Stack

The Loopback Interface

Understanding Routes

Checking Firewall Rules

Creating an Isolated Network Namespace

Entering the Namespace

Creating a Virtual Ethernet Pair

Moving One Interface into the Namespace

Assigning IP Addresses

Why We Need to Add a Route

Testing Connectivity

Why This Matters in Real Systems

Final Thoughts When people first start learning container networking, terms like network namespaces, veth pairs, and routing tables can sound complicated. But under the hood, the idea is surprisingly simple. Recently, I spent some time experimenting with Linux networking directly from the terminal to better understand how containers communicate internally. In this post, I’ll walk through the process step by step and explain what each command actually does instead of only showing commands to copy and paste. Linux networking is built around network interfaces. A network interface is simply a communication point between your machine and a network. To see all available interfaces: You will usually notice interfaces like: The ip command comes from the iproute2 package and is one of the most important networking tools in Linux. The loopback interface (lo) is a special internal interface that allows a machine to communicate with itself. You will notice it usually has the IP address: This is commonly called localhost. Applications use the loopback interface for internal communication without sending traffic outside the machine. Whenever Linux sends a packet, it first checks the routing table to decide where the packet should go. You can inspect the routing table using: Typical output looks something like: Without routes, Linux would not know where to send packets. Linux provides packet filtering through iptables. iptables is commonly used for: Container technologies also use iptables extensively behind the scenes. A network namespace creates a completely isolated networking environment. Each namespace has its own: This is one of the core technologies used by containers. Now list available namespaces: At this point, the namespace exists, but it is isolated and cannot communicate with anything yet. Run a shell inside the namespace: Now any networking command you run operates inside the isolated namespace instead of the host machine. You will mostly see only the loopback interface because no external network connection exists yet. To connect the namespace with the host machine, we need a communication channel. Linux provides this using a virtual Ethernet pair (veth). This creates two linked virtual interfaces: Think of them like two ends of a physical Ethernet cable. Anything entering one side instantly appears on the other side. Initially, both interfaces exist inside the host namespace. Now move one side into the red namespace: Now the namespace has one end of the virtual cable. Network interfaces need IP addresses to communicate. Configure the namespace side: Now enable the interface: Interfaces are disabled by default after creation, so bringing them "up" is necessary. Now configure the host side: Both devices are now connected through the virtual Ethernet pair. This is one of the most important parts of the setup. But why is this necessary? When Linux sends packets, it checks the routing table first. Without this route, Linux has no idea where 192.168.1.1 exists. Even though the interface physically exists, the kernel still needs routing information. By adding the route, we are telling Linux: "To reach 192.168.1.1, send packets through veth-host." Routing tables are essentially maps for packet delivery. Now test communication from the host: You should receive replies successfully. Now enter the namespace: At this point, both sides can communicate through the virtual Ethernet cable. This exact concept is heavily used in: When a container gets its own IP address, Linux namespaces and veth pairs are often involved behind the scenes. Understanding this manually makes container networking much easier to understand later. Before learning this, container networking felt almost magical to me. But once you experiment directly with namespaces, routes, and veth devices, the whole system starts making much more sense. Linux networking is incredibly modular and powerful, and understanding these building blocks gives a much deeper understanding of how modern infrastructure actually works. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Code Block

Copy

ip link show ip link show ip link show ifconfig lo ifconfig lo ifconfig lo ip route show ip route show ip route show default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link default via 192.168.1.1 dev eth0 192.168.1.0/24 dev eth0 proto kernel scope link iptables -L iptables -L iptables -L sudo ip netns add red sudo ip netns add red sudo ip netns add red sudo ip netns list sudo ip netns list sudo ip netns list sudo ip netns exec red bash sudo ip netns exec red bash sudo ip netns exec red bash ip link show ip link show ip link show sudo ip link add veth-red type veth peer name veth-host sudo ip link add veth-red type veth peer name veth-host sudo ip link add veth-red type veth peer name veth-host sudo ip link set veth-red netns red sudo ip link set veth-red netns red sudo ip link set veth-red netns red sudo ip netns exec red ip addr add 192.168.1.1/24 dev veth-red sudo ip netns exec red ip addr add 192.168.1.1/24 dev veth-red sudo ip netns exec red ip addr add 192.168.1.1/24 dev veth-red 192.168.1.1 192.168.1.1 192.168.1.1 sudo ip netns exec red ip link set veth-red up sudo ip netns exec red ip link set veth-red up sudo ip netns exec red ip link set veth-red up sudo ip addr add 192.168.1.2/24 dev veth-host sudo ip link set veth-host up sudo ip addr add 192.168.1.2/24 dev veth-host sudo ip link set veth-host up sudo ip addr add 192.168.1.2/24 dev veth-host sudo ip link set veth-host up sudo ip route add 192.168.1.1 dev veth-host sudo ip route add 192.168.1.1 dev veth-host sudo ip route add 192.168.1.1 dev veth-host ping 192.168.1.1 -c 3 ping 192.168.1.1 -c 3 ping 192.168.1.1 -c 3 sudo ip netns exec red bash sudo ip netns exec red bash sudo ip netns exec red bash ping 192.168.1.2 -c 3 ping 192.168.1.2 -c 3 ping 192.168.1.2 -c 3 - lo → Loopback interface - eth0 → Main Ethernet interface - Traffic for the local network should go through eth0 - Everything else should go to the default gateway (192.168.1.1) - Traffic filtering - Port forwarding - Routing table - Firewall rules - veth-red lives inside the namespace - veth-host remains on the host - Host side → 192.168.1.2 - Namespace side → 192.168.1.1 - Ping would fail - Packets would never leave correctly - Linux would not know which interface to use - Linux containers - Cloud infrastructure