I have created a veth device pair as follows in Ubuntu 16.04:
$ sudo ip link add veth1 type veth peer name veth2 $ sudo ip link set dev veth1 up $ sudo ip link set dev veth2 up $ sudo ip address add 10.0.10.50/24 dev veth1 $ sudo ip address add 10.0.10.51/24 dev veth2
The veth device pair is in the same namespace. I am trying to test ping from one veth device to the other. So I try the ping as follows:
$ ping -I veth1 10.0.10.51 PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 veth1: 56(84) bytes of data. From 10.0.10.50 icmp_seq=1 Destination Host Unreachable From 10.0.10.50 icmp_seq=2 Destination Host Unreachable From 10.0.10.50 icmp_seq=3 Destination Host Unreachable
When I check in wireshark trace for veth2, the ARP request does not get any response (similar trace is also observed for veth1):
Broadcast ARP 42 Who has 10.0.10.51? Tell 10.0.10.50
I want to ask why can't veth2 respond to the ICMP request when it is in the same namespace as veth1 ?
Update: If I try the ping as follows, then I get ICMP response, but wireshark shows no trace for veth1 and veth2 devices.
$ ping -I 10.0.10.50 10.0.10.51 PING 10.0.10.51 (10.0.10.51) from 10.0.10.50 : 56(84) bytes of data. 64 bytes from 10.0.10.51: icmp_seq=1 ttl=64 time=0.016 ms 64 bytes from 10.0.10.51: icmp_seq=2 ttl=64 time=0.022 ms
Can someone explain the difference in result for the two ping tests ?
For the second variant, do a
tcpdump -ni lo (or use Wireshark), and you'll see that the communication happens on the loopback interface. That's because the kernel notices that both address are local addresses, and therefore uses the loopback interface, no matter which interface those addresses are assigned to.
For the first variant, I am not exactly sure why the broadcast doesn't get answered, but in general, the kernel considers communication that goes out from one interface and appears on another interface as a routing error, and suppresses it. The broadcast may go through because it is a broadcast.
With considerable effort, you can tweak that to allow a boomerang ping, but this isn't particularly useful normally.
Virtual eth-pairs really only make sense if you use them to connect different network namespaces. The way you set them up, they are about as useless as having two different physical Ethernet cards on the same LAN segment.
External links referenced by this document: