DEV Community: Alhousseïni Mohamed

Understanding Linux Network Namespaces: How Containers Isolate and Connect Networks

Alhousseïni Mohamed — Tue, 24 Mar 2026 07:49:29 +0000

Modern container technologies like Docker and Kubernetes rely heavily on Linux kernel features to provide isolation and security. One of the most fundamental, yet often misunderstood of these features is the network namespace.

Network namespaces are what give containers the illusion of having their own network stack: their own interfaces, IP addresses, routing tables, and ARP tables; completely isolated from the host and from other containers.

In this article, we’ll break down how network namespaces work, why they are essential for container networking, and how Linux connects isolated namespaces together using virtual Ethernet (veth) interfaces. Through concrete commands and examples, you’ll see how containers are isolated from the host and how they can still communicate with each other when needed.

By the end, you’ll have a clear mental model of what happens under the hood when a container gets network access.

1. How does networking work in case of containers

Routing and ARP table inside a namespace

By default, a host wich is connected to a LAN has it owns routing table and ARP table and we would like to seals them all from the container. When we create a container, we create it’s own Network Namespace. So, it gets it’s own virtual interface, routing and ARP table.

To create a new Network Namespace on a Linux host we run this command :

ip netns add <new namespace name>

For example, let’s say you wanted to create a namespace called “blue”. You’d use this command:

ip netns add blue

To verify that the network namespace has been created, use this command:

ip netns list

You should see your network namespace listed there, ready for you to use.

To be sure that your virtual network can be seen by the host, but inside the namespace your container can’t see the host virtual network run those commands :

First on the host ( Your should see your host virtual interface and the one sed by your container ) :

ip link

Then from inside the Network Namespace ( You should only see your container interface, not your host one. ) :

ip netns exec blue ip link

NB : The same goes for the ARP table and Route table.

2. The tricky part

Connecting two networks namespaces virtual interfaces

Let say we create two Network Namespaces, but then how do we make so that they are connected ?
Creating the network namespace is only the beginning; the next part is to assign interfaces to the namespaces, and then configure those interfaces for network connectivity.
Virtual Ethernet interfaces are an interesting construct; they always come in pairs, and they are connected like a tube — whatever comes in one veth interface will come out the other peer veth interface. As a result, you can use veth interfaces to connect a network namespace to the outside world via the “default” or “global” namespace where physical interfaces exist.

Let’s see how that’s done. First, you’d create the veth pair:

ip link add veth0 type veth peer name veth1

I found a few sites that repeated this command to create veth1 and link it to veth0, but my tests showed that both interfaces were created and linked automatically using this command listed above. Naturally, you could substitute other names for veth0 and veth1, if you wanted.

You can verify that the veth pair was created using this command:

ip link list

You should see a pair of veth interfaces (using the names you assigned in the command above) listed there. Right now, they both belong to the “default” or “global” namespace, along with the physical interfaces.

Let’s say that you want to attach the veth1 interface to the blue namespace. To do that, you’ll need to use this command:

ip link set veth1 netns blue

PS : You do the same for the veth0 interface to attach it to your second namespace.

You then assign an ip to each namespace using this command :

ip -n blue addr add 192.168.10.1 dev veth1

  The same goes for tyour second namespace :

ip -n second_namespace addr add 192.168.10.2 dev veth0

This command assign the ip 192.168.10.1, to the namespace blue using the veth1 interface.

To finish, you then bring up the interface using the IP link command, on each one of the respective namespace:

ip -n blue link set veth1 up

Your namespace can now reach each other !

You can check this, by looking at one of your network namespace :

ip netns exec blue arp

This command will show the second namespace ARP table, that is connected to the blue namespace.

Conclusion

Network namespaces are a core building block of Linux containerization. They provide strong isolation by giving each container its own network stack — including interfaces, routing tables, and ARP tables — while still allowing the host full visibility and control.

On their own, namespaces are completely isolated. The real magic happens when we connect them using veth pairs, which act like virtual network cables. By attaching each end of a veth pair to different namespaces and assigning IP addresses, we can enable controlled communication between containers while preserving isolation.

Understanding Linux Network Namespaces: How Containers Isolate and Connect Networks

Alhousseïni Mohamed — Tue, 24 Mar 2026 07:49:29 +0000

By the end, you’ll have a clear mental model of what happens under the hood when a container gets network access.

1. How does networking work in case of containers

Routing and ARP table inside a namespace

To create a new Network Namespace on a Linux host we run this command :

ip netns add <new namespace name>

For example, let’s say you wanted to create a namespace called “blue”. You’d use this command:

ip netns add blue

To verify that the network namespace has been created, use this command:

ip netns list

You should see your network namespace listed there, ready for you to use.

To be sure that your virtual network can be seen by the host, but inside the namespace your container can’t see the host virtual network run those commands :

First on the host ( Your should see your host virtual interface and the one sed by your container ) :

ip link

Then from inside the Network Namespace ( You should only see your container interface, not your host one. ) :

ip netns exec blue ip link

NB : The same goes for the ARP table and Route table.

2. The tricky part

Connecting two networks namespaces virtual interfaces

Let’s see how that’s done. First, you’d create the veth pair:

ip link add veth0 type veth peer name veth1

You can verify that the veth pair was created using this command:

ip link list

Let’s say that you want to attach the veth1 interface to the blue namespace. To do that, you’ll need to use this command:

ip link set veth1 netns blue

PS : You do the same for the veth0 interface to attach it to your second namespace.

You then assign an ip to each namespace using this command :

ip -n blue addr add 192.168.10.1 dev veth1

  The same goes for tyour second namespace :

ip -n second_namespace addr add 192.168.10.2 dev veth0

This command assign the ip 192.168.10.1, to the namespace blue using the veth1 interface.

To finish, you then bring up the interface using the IP link command, on each one of the respective namespace:

ip -n blue link set veth1 up

Your namespace can now reach each other !

You can check this, by looking at one of your network namespace :

ip netns exec blue arp

This command will show the second namespace ARP table, that is connected to the blue namespace.

Conclusion

Why AI Might Be the WORST Thing That Could Have Happened to Us

Alhousseïni Mohamed — Thu, 05 Mar 2026 16:08:04 +0000

Before we dive into this topic, let me ask you two simple questions:

When was the last time you did an addition, subtraction, or multiplication with two-digit numbers… in your head — without reaching for a calculator?
And when was the last time you wrote a full paragraph without your autocorrect saving you from spelling mistakes?

Don’t worry, I’m not judging you.

I’m asking because I asked myself the same questions, and I didn’t like the answers.

Actually, even writing this article is a perfect example of the problem: I’m using AI to help me write in English, because it’s not my first language. And yes, I know I’ll make mistakes. AI fixes them instantly.

Convenient? Absolutely, but also… kind of scary.

AI doesn’t just help us. It slowly replaces our brain habits.

Let’s be honest: AI is amazing.

It writes emails, fixes grammar, summarizes long documents, generates code, explains concepts, and gives you “the perfect answer” in seconds.

But here’s the thing:

The more AI helps us think, the less we actually practice thinking. And like a muscle… if you don’t use it, you lose it.
At first, you use AI to save time. Then you use AI because it’s faster.
Then you use AI because you can’t be bothered.
And one day, you realize you’re not really learning anymore.

You’re just… prompting.

Everything is moving too fast now. And humans are not built for that.

Let me give you my context.

I’m currently a student, in my last year of an IT Expert / DevOps degree.
Which means I’m still learning, still growing, still building experience.

Before AI, I already knew what Docker was used for…
but I didn’t fully understand how it relies on Linux networking concepts behind the scenes.

I learned about CI/CD pipelines…
but writing complex bash scripts from scratch? Still difficult.
Then I discovered Kubernetes. Kubernetes is wonderful. It’s powerful. It’s the future. But it’s also… a foggy mountain of concepts.

I understand why it exists. I’ve used containers. I’ve used Docker Compose. So I clearly see the value. But mastering Kubernetes takes time.

And time is exactly what we don’t have anymore. Because now, people look at you like: “Oh you don’t know Kubernetes? Just ask ChatGPT.

AWS? Great. Also… WHY ARE THERE 500 SERVICES?

Then I started learning AWS. And my God… there are so many services.
Do I really need to know them all? I mean yes, I need a VM, some networking and security with IAM.
But then you open the AWS console and it feels like walking into a supermarket where every aisle is a different universe.

Honestly, respect to AWS engineers…they really thought about everything 😅.

But still, learning it takes time. And now the expectation is: “AI can explain AWS in 10 minutes, so you should be productive by tomorrow.”

Then comes Infrastructure as Code… and suddenly I’m the Dev AND the Ops team

Now here comes IaC.

Terraform. Ansible. Kubernetes manifests. Helm charts. GitOps. Secrets management. Monitoring. Logging.
It’s interesting. It’s powerful. But I’m thinking: Why do I have to do the Ops team’s job too?
I already have a lot to learn. And now the world wants developers who can:

code
deploy
secure
monitor
automate
document
scale
optimize costs
and still deliver fast

Meanwhile AI can generate half of it instantly…

So the new standard becomes: “If AI can do it fast, you should too.”

The real problem isn’t AI. It’s what people expect because of AI.

AI isn’t the enemy, the real problem is what happens next:

learning becomes optional
understanding becomes “too slow”
effort becomes “inefficient”
and speed becomes more valuable than mastery

We’re turning into a generation of people who can produce results, without fully knowing how they were produced. And that’s dangerous.

Because when something breaks at 3AM in production :

AI won’t feel stress.
AI won’t panic.
AI won’t be accountable.

> You will.

AI is a cheat code. But life still has a skill tree.

I love AI. I use it every day. But I’m also trying to remember this:
AI can accelerate your learning, but it can also replace it.
So maybe the real challenge today is not “learning faster”.
It’s learning deeply, while the world is screaming “faster”.

Because the future won’t belong to the people who use AI to avoid thinking.
It will belong to the people who use AI to think better.