For veth pair, ping does not recognize interface name and tc qdisc netem does not work

Question

I have Ubuntu 16.04 LTS with hwe kernel 4.13.0-39-generic. I configure the veth pair in the default network namespace as follows:

$ sudo ip link add h1-eth0 type veth peer name h2-eth0

$ sudo ip link set dev h1-eth0 up
$ sudo ip link set dev h2-eth0 up

$ sudo ip addr add 10.0.0.1/24 dev h1-eth0
$ sudo ip addr add 10.0.0.2/24 dev h2-eth0

Here is the settings which I get after the above configuration:

$ ifconfig
...
h1-eth0   Link encap:Ethernet  HWaddr ea:ee:1e:bb:66:55  
          inet addr:10.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          ...

h2-eth0   Link encap:Ethernet  HWaddr ba:aa:99:77:ff:78  
          inet addr:10.0.0.2  Bcast:0.0.0.0  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          ...

$ ip route show
10.0.0.0/24 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
10.0.0.0/24 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
...

Now I can ping one interface from another as following:

$ ping -I 10.0.0.1 -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.046 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.046/0.046/0.046/0.000 ms

But the first problem is that ping fails when I try to ping using the name of the interface, rather than the ip address:

$ ping -I h1-eth0 -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 h1-eth0: 56(84) bytes of data.
From 10.0.0.1 icmp_seq=1 Destination Host Unreachable

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

How can this be a problem if h1-eth0 has ip address 10.0.0.1?

The second problem is, I believe, related. I configure the interfaces as following:

$ sudo tc qdisc add dev h1-eth0 root netem delay 60ms
$ sudo tc qdisc add dev h2-eth0 root netem delay 60ms
$ tc qdisc show 
qdisc netem 8006: dev h2-eth0 root refcnt 2 limit 1000 delay 60.0ms
qdisc netem 8005: dev h1-eth0 root refcnt 2 limit 1000 delay 60.0ms

Now I ping again with the delay:

$ ping -I 10.0.0.1 -c4 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.033 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.034 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.059 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.027 ms

--- 10.0.0.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3063ms
rtt min/avg/max/mdev = 0.027/0.038/0.059/0.013 ms

And it can be seen that the rtt is not expected 60ms*2=120ms. So it looks like tc qdisc netem does not work for my interfaces.

So overall, I see that my configuration is somehow broken.

Answer 1

I answer my own question below.

The simplest circumvention (my approach): putting one of the veth pair to another network namespace. Let's call it test.

$ sudo ip netns add test
$ sudo ip link add h1-eth0 type veth peer name h2-eth0 netns test

$ sudo ip link set dev h1-eth0 up
$ sudo ip netns exec test ip link set dev h2-eth0 up

$ sudo ip addr add 10.0.0.1/24 dev h1-eth0
$ sudo ip netns exec test ip addr add 10.0.0.2/24 dev h2-eth0

$ sudo tc qdisc add dev h1-eth0 root netem delay 60ms
$ sudo ip netns exec test tc qdisc add dev h2-eth0 root netem delay 60ms

Now we check:

$ ping -I h1-eth0 -c1 10.0.0.2
PING 10.0.0.2 (10.0.0.2) from 10.0.0.1 h1-eth0: 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=120 ms

--- 10.0.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 120.056/120.056/120.056/0.000 ms

$ sudo ip netns exec test ping -I h2-eth0 -c1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) from 10.0.0.2 h2-eth0: 56(84) bytes of data.
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=120 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 120.146/120.146/120.146/0.000 ms

---

Other approaches

I discovered that my question was already asked but also was not answered: https://serverfault.com/questions/585246/network-level-of-veth-doesnt-respond-to-arp. From there we see that the problem is with ARP.

A question connected to this problem with ARP was asked here Linux does not reply to ARP request messages if requested IP address is associated with another (disabled) interface and the topic starter received some explanation but the problem was not still solved.

The problem is that addresses 10.0.0.1 and 10.0.0.2 are present not only in main route table but also in local route table and the local route table has higher priority than the main route table. Below there are these tables for the initial setup from my question, i.e. WITHOUT putting one end of the veth pair to another network namespace test:

$ ip route show table local
broadcast 10.0.0.0 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
broadcast 10.0.0.0 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
local 10.0.0.1 dev h1-eth0  proto kernel  scope host  src 10.0.0.1 
local 10.0.0.2 dev h2-eth0  proto kernel  scope host  src 10.0.0.2 
broadcast 10.0.0.255 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
broadcast 10.0.0.255 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
...

$ ip route show table main
10.0.0.0/24 dev h1-eth0  proto kernel  scope link  src 10.0.0.1 
10.0.0.0/24 dev h2-eth0  proto kernel  scope link  src 10.0.0.2 
...

When having one of the ends of the veth pair in another network namespace we do not have a situation when two of the addresses are placed in the local route table at the same time. So, probably, this is why we do not have such a problem. I tried to delete the addresses from the local route table (only one of them or both -- in different combinations) but it did not help. Overall, I do not fully understand the situation so I will just stick up with setting the ends of the veth pair into different network namespaces. All the more, this is how a veth pair is mostly used, as far as I know.