W dużym skrócie namespace'y są dla stosu sieciowego tym czym chroot dla systemu plików. Pozwalają bez "wirtualizacji" stworzyć wirtualne środowiska sieciowe - każde z oddzielną tablicą routingu, kolejkowaniem, a także Firewallem. Następnie można w takim dedykowanym środowisku sieciowym uruchamiać dowolne programy z systemu, a następnie dowolnie zmieniam im warunki pracy, nie zmieniając reszty działającego systemu.

Przykładowe użycie:

root@uml:~# ip netns list # listujemy netns
root@uml:~# ip netns add test # dodajemy nowy netns
root@uml:~# ip netns exec test ip link set dev lo up # podnosimy w nim loopback
root@uml:~# ip link add veth-1-2 type veth peer name veth-2-1 # dodajemy połączeniówkę
root@uml:~# ip link set veth-1-2 netns test up # podnosimy jedną część połączeniówki w netns
root@uml:~# ip link set veth-2-1 up # podnosimy lokalną połączenówkę
root@uml:~# ip a a 192.168.123.1/31 dev veth-2-1 # dodajemy adres ip dla lokalnej połączeniówki
root@uml:~# ip netns exec test ip a a 192.168.123.0/31 dev veth-1-2 # i to samo dla połączeniówki w netns
root@uml:~# ip a s dev veth-2-1 #wyświetlamy interfejs lokalny
31: veth-2-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 5e:ce:2d:b0:46:23 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.1/31 scope global veth-2-1
       valid_lft forever preferred_lft forever
    inet6 fe80::5cce:2dff:feb0:4623/64 scope link 
       valid_lft forever preferred_lft forever
root@uml:~# ip a s dev veth-1-2 # sprawdzamy że drugi nie jest widoczny - bo jest w netns
Device "veth-1-2" does not exist.
root@uml:~# ip netns exec test ip a # wyświetlamy adresację w netns
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default 
    link/sit 0.0.0.0 brd 0.0.0.0
32: veth-1-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether a6:66:c4:fb:7d:14 brd ff:ff:ff:ff:ff:ff
    inet 192.168.123.0/31 scope global veth-1-2
       valid_lft forever preferred_lft forever
    inet6 fe80::a466:c4ff:fefb:7d14/64 scope link 
       valid_lft forever preferred_lft forever
root@uml:~# ip netns list # wyświetlamy listę ns
test
root@uml:~# ip r get 192.168.123.0 # pobieramy trasę na 192.168.123.0 (ip w netns)
192.168.123.0 dev veth-2-1  src 192.168.123.1 
    cache 
root@uml:~# ping 192.168.123.0 # i sprawdzamy czy się pinguje
PING 192.168.123.0 (192.168.123.0) 56(84) bytes of data.
64 bytes from 192.168.123.0: icmp_seq=1 ttl=64 time=0.080 ms
64 bytes from 192.168.123.0: icmp_seq=2 ttl=64 time=0.075 ms
^C
--- 192.168.123.0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.075/0.077/0.080/0.009 ms

Z zastosowań - można w netns uruchomić np jakieś proxy tudzież VPNa - co spowoduje, że uruchomione w nim aplikacje wyjdą na świat poprzez inną sieć - a nie będzie to dotykać naszej lokalnej sieci. Można również za pomocą tc limitować wewnątrz netns-ów ruch sieciowy - tudzież "psuć" go - tak, by móc przetestować poszczególne aplikacje w warunkach popsutej sieci.