Public IPv6s fail on KVM bridge with "No buffer space available"

[Bjoern A. Zeeb]

On 24 May 2017, at 10:17, William Gathoye wrote:

> In this use case, you make the assumption that my gateway is actually
> the first one to respond, this is why you select only the first answer
> using -c1. But as you can see below, if I remove that argument, 
> several
> routers are answering to me (seems sensible to me), how can I be sure 
> my
> gateway is actually the first device that answers?

You cannot.  It’s all about latency and where your time goes.  Switch 
buffers, distance, NICs, input paths, CPU loads, .. lots of things can 
change the timing of a packet.

> PING6(56=40+8+8 bytes) fe80::ff:fec2:e61d%vtnet0 --> ff02::2%vtnet0
> 16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=0 hlim=64
> time=0.292 ms
> 16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=0 hlim=64
> time=0.355 ms(DUP!)
> 16 bytes from fe80::2ff:ffff:feff:fffd%vtnet0, icmp_seq=0 hlim=64
> time=2.970 ms(DUP!)
> 16 bytes from fe80::2ff:ffff:feff:fffe%vtnet0, icmp_seq=0 hlim=64
> time=5.964 ms(DUP!)
> 16 bytes from fe80::268a:7ff:fe91:e970%vtnet0, icmp_seq=1 hlim=64
> time=0.314 ms
> 16 bytes from fe80::268a:7ff:fe91:ea98%vtnet0, icmp_seq=1 hlim=64
> time=0.389 ms(DUP!)
> 16 bytes from fe80::2ff:ffff:feff:fffd%vtnet0, icmp_seq=1 hlim=64
> time=3.222 ms(DUP!)
> 16 bytes from fe80::2ff:ffff:feff:fffe%vtnet0, icmp_seq=1 hlim=64
> time=6.382 ms(DUP!)
>
> How can I understand the "DUP!" statement here? I assume these are due
> because we are using multicast here end the ICMP reply are echoes to
> each others? Right?

The DUP! here in case is indeed as you get 4 replies for each request 
you are sending out.  It’s not “each other”, it’s one request to 
the multicast address, 4 unicast replies to you.

/bz