Linux network namespaces - ping fails on specific veth

Question

I just started to exploring network namespaces. I try to implement the following simple setting following the article in http://www.opencloudblog.com/?p=42

   +--------+                      +-----------+                      +--------+
   |        |------+        +------+           |------+        +------|        |
   |nstest2 |veth-2++------++veth-b| Default   |veth-a++------++veth-1| nstest1|
   |        |------+        +------+ namespace |------+        +------|        |
   +--------+                      +-----------+                      +--------+

I execute the following commands:

#setup namespace nstest1
sudo ip netns add nstest1
sudo ip netns exec nstest1 ip link set dev lo up
sudo ip link add veth-a type veth peer name veth-1
sudo ip link set veth-1 netns nstest1
sudo ip netns exec nstest1 ip addr add 10.0.1.1/24 dev veth-1
sudo ip netns exec nstest1 ip link set dev veth-1 up

# setup namespace nstest2
sudo ip netns add nstest2
sudo ip netns exec nstest2 ip link set dev lo up
sudo ip link add veth-b type veth peer name veth-2
sudo ip link set veth-2 netns nstest2
sudo ip netns exec nstest2 ip addr add 10.0.2.1/24 dev veth-2
sudo ip netns exec nstest2 ip link set dev veth-2 up

# setup default namespace
sudo ip addr add 10.0.1.2/24 dev veth-a
sudo ip link set dev veth-a up
sudo ip addr add 10.0.2.2/24 dev veth-b
sudo ip link set dev veth-b up

When I ping nstest1 from the default namespace or vice-versa all pings are successful. When I try to ping nstest2 from the default namespace or vice-versa all pings fail. I cannot understand why that happens and how it can be fixed. Should I manually add the routes from/to default namespace to nstest2? If yes why I don't have to do it for nstest1? Any help with explanation will be greatly appreciated! I'm using ubuntu 12.10.

EDIT:
The route tables are the following for each namespace:


Default namespace

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    0      0        0 eth0
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth-a
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 veth-b
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

nstest1

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.1.0        0.0.0.0         255.255.255.0   U     0      0        0 veth-1

nstest2

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 veth-2

EDIT 2
It turns out that 10.0.2.2 is assigned to eth0 therefore there is a collision by assigning the same subnet to veth-b and veth-2. When I changed it to 10.0.3.1/24 and 10.0.3.2/24 ping worked for both nstest1 and nstest2. Doing an ifconfig -a is necessary before assigning those addresses.

Solution

Well, first of all, you have two "logically" seperate virtual ethernet networks.

on veth-b use 10.0.2.1/24 and use 10.0.2.4/24 on veth-2

on veth-a use 10.0.1.1/24 and use 10.0.1.3/24 on veth-1

veth-b and veth-2 are a different network to veth-a and veth-1, so you ought to give them seperate IP subnets.

You still won't be able to ping from 10.0.1.3 to 10.0.2.4 unless you do:

   $ echo 1 > /proc/sys/net/ipv4/ip_forward
   $ sudo ip netns exec nstest2 ip route add default via 10.0.2.1
   $ sudo ip netns exec nstest1 ip route add default via 10.0.1.1

Good Luck!

Comments

[etherfish]

Oh, the reason why pinging nstest2 wouldn't work is because you had two routes for the same subnet, 10.0.0.0/24 on two different devices, veth-a and veth-b. Since veth-a was the first match in the routing table for any IP address in 10.0.0.0/24 (meaning any ip from 10.0.0.0 to 10.0.0.255), it tried to reach it via veth-a and not veth-b. That's why you need two different subnets.

[Vasilis]

Thanks! +1 for correcting my sub-netting error, but I still cannot ping. I edited the question with different subnets for each pair of virtual interfaces and I added the routing tables for each namespace. The problem may be with my default gateway but I'm not sure.