Photo by Tri Eptaroka Mardiana on Unsplash

Linux Namespaces (part 4/5)

Namespace: Network (net)

Network NS is quality itself :) It may be the only NS (maybe except for mnt) the independent use of which could be not only “demonstrative”, but also completely practical. A great example of this is the Mininet project!

To present you a part of possibilities that give us net namespace, we must first get to know the veth driver:

$ ip link add ve0 type veth peer name ve1

The command above will let us create two new network interfaces in our GNU/Linux system — ve0 and ve1. Those interfaces are already connected to each other, which we can imagine as a connection of two network cards - in the same machine - with a network cable (that can look weird, but in this case, it makes/will make sense).

By default our new interfaces are neither configured nor turned on, so to use them we must set them up (additionally, I will assign the IP address for one of them):

$ ip address add 10.10.10.10/24 dev ve0 
$ ip link set ve0 up 
$ sudo ip l s ve1 up

Now we can test if it works. By checking a current routing table (ip r) we should already see a route to the network "10.10.10.0/24":

(console 1)$ ping 10.10.10.100

And in another terminal/console:

(console 2)$ tcpdump -i ve1 -n -e arp

ping command will report errors because the address 10.10.10.100 does not exist (so we will not have received the correct answer on the icmp protocol level). But tcpdump (which monitors ve1) will indicate the movement in layer 2, more precisely an enquiry ARP sent from ve0: who has 10.10.10.100? – so the connection works!

Why not to assign the address 10.10.10.100 to ve1? Well… try it if you want to :-D. But carefully - it's going to cause some network issue!

Now the trick — let’s move one of the interfaces to a separate NS (for now they exist in the same one). Create a new net NS thanks to the unshare command, and then check pid of the shell process started in that NS (it will be substituted in the next command under $NETPID)

(console 1)$ unshare -n && echo $$

We can check the list of interfaces in a newly created namespace (ip l) – it should have only the loopback interface. Now let’s move one of the interfaces created before to a recently created namespace:

(console 2)$ sudo ip link set ve1 netns ${NETPID}

The command ip l in each of the terminals should confirm the change – the interface ve1 vanished from the default namespace (console 2) and showed up in a newly created namespace attributed to the $NETPID process (console 1). The moved interface has been however reset, so we must set it up again (and, this time, let's assign ip address to it - it shouldn’t cause any issues now ;) ):

(console 1)$ ip a a 10.10.10.100/24 dev ve1 
(console 1)$ ip l s ve1 up

And the final test:

(console 1)$ tcpdump -i ve1 -n -e arp 
(console 2)$ ping 10.10.10.100

Now ping works – there’s power in it! :)

Namespace: Control group (cgroup)

Somewhere I came across a statement that the containers built on two pillars — Namespaces and Control Groups (cgroups) where NS responds to what the process sees, and cgroups for what the process can do. It is probably true, but sounds a bit weird if we notice that cgroups are also one of the namespaces (what is more, it seems that if we use SELinux, the cgroups lose significance — see Centos the distributional kernel of which doesn’t have a compiled cgroups’ NS at all). There is probably a lot to explain/check — personally I (for now) give up on the topic of cgroups… maybe I will return to it another time.

<< Linux Namespaces (part 3/5) | Linux Namespaces (part 5/5) >>