Unix & Linux
networking veth
Updated Wed, 17 Aug 2022 21:34:06 GMT

No ICMP response for veth devices in same namespace

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 dev veth1
$ sudo ip address add 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
PING ( from veth1: 56(84) bytes of data.
From icmp_seq=1 Destination Host Unreachable
From icmp_seq=2 Destination Host Unreachable
From 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 Tell

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
 PING ( from : 56(84) bytes of data.
 64 bytes from icmp_seq=1 ttl=64 time=0.016 ms
 64 bytes from icmp_seq=2 ttl=64 time=0.022 ms

Can someone explain the difference in result for the two ping tests ?


Partial answer:

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

External links referenced by this document: