Date: Wed, 24 May 2017 10:30:07 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: "William Gathoye" <william@gathoye.be> Cc: freebsd-net@freebsd.org Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" Message-ID: <CD1D940F-62A9-4297-A65A-BA733FE55A48@lists.zabbadoz.net> In-Reply-To: <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> References: <fbfe1ff2-bd66-9a98-d56b-6d75265936bd@gathoye.be> <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> <a44fa8c5-d48f-25eb-51d2-16d100ba5f53@gathoye.be> <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CD1D940F-62A9-4297-A65A-BA733FE55A48>