From owner-freebsd-net@freebsd.org Wed May 24 10:30:22 2017 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B0ADD7B9B6 for ; Wed, 24 May 2017 10:30:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5AE5613C6 for ; Wed, 24 May 2017 10:30:21 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id F35EB25D3892; Wed, 24 May 2017 10:30:12 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2087DD1F7EE; Wed, 24 May 2017 10:30:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id dGaZHven2vmI; Wed, 24 May 2017 10:30:10 +0000 (UTC) Received: from [10.249.122.211] (unknown [IPv6:fde9:577b:c1a9:f001::2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 615B9D1F7EA; Wed, 24 May 2017 10:30:10 +0000 (UTC) From: "Bjoern A. Zeeb" To: "William Gathoye" Cc: freebsd-net@freebsd.org Subject: Re: Public IPv6s fail on KVM bridge with "No buffer space available" Date: Wed, 24 May 2017 10:30:07 +0000 Message-ID: In-Reply-To: <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> References: <84cecdc7-e331-d3bc-3fb3-e35507e231d6@yandex.ru> <20170522121318.2pzqt5ryisrl44rn@mew.swordarmor.fr> <19651499-409c-297f-9d53-fa0eeb9cdd25@gathoye.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Mailer: MailMate (2.0BETAr6082) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 May 2017 10:30:22 -0000 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