From owner-freebsd-net@freebsd.org Fri Mar 16 09:38:25 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12E90F5F554 for ; Fri, 16 Mar 2018 09:38:25 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from forward101o.mail.yandex.net (forward101o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::601]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8586C75688 for ; Fri, 16 Mar 2018 09:38:23 +0000 (UTC) (envelope-from melifaro@ipfw.ru) Received: from mxback3o.mail.yandex.net (mxback3o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::1d]) by forward101o.mail.yandex.net (Yandex) with ESMTP id 085521345590; Fri, 16 Mar 2018 12:38:21 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback3o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id F2tUv9j5wY-cIbuLvdX; Fri, 16 Mar 2018 12:38:19 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfw.ru; s=mail; t=1521193099; bh=dQPpcvZPMGTZI2L935SoLHzxtCRy9UDcabwN35IZjv8=; h=From:To:In-Reply-To:References:Subject:Message-Id:Date; b=R9/NqJpocq1iSlcK0bCABBzEpdMYtbIX7xIQb8cFEPtO5faFqADvgUsvHrpb8qaYJ h8T0TQfPNyK3QGhLWOz5mfqBBoqumjWhzbpW9VDxZtpc8euqlL/A75vhB8L1pmhOm7 rwid9fEq4xpBW7kw9Ycr1ZSCTuL1IA10XV5EJlEQ= Authentication-Results: mxback3o.mail.yandex.net; dkim=pass header.i=@ipfw.ru Received: by web19g.yandex.ru with HTTP; Fri, 16 Mar 2018 12:38:18 +0300 From: Alexander V. Chernikov To: "sthaug@nethelp.no" , "freebsd-net@FreeBSD.org" In-Reply-To: <20180315.210552.74686746.sthaug@nethelp.no> References: <20180315.210552.74686746.sthaug@nethelp.no> Subject: Re: Does FreeBSD do proactive ARP refresh? MIME-Version: 1.0 Message-Id: <8530131521193098@web19g.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Fri, 16 Mar 2018 12:38:18 +0300 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2018 09:38:25 -0000 15.03.2018, 23:08, "sthaug@nethelp.no" : > I have a reproducible problem on 11.1-STABLE where, during a longterm > iperf3 session, some packets are lost every time ARP is refreshed (every > net.link.ether.inet.max_age seconds). Checking with tcpdump, I can > indeed see that the packet loss is happening as the hosts are doing > ARP request/reply. I'll take a look. Indeed, the intended behaviour is to proactively refresh the record. Is the situation the same with forwarding and locally-originated traffic? With local TCP socket inpcb route caching might come into play. > > How to reproduce the problem: > > - pkg install iperf3-3.5 > - Decrease ARP aging timer to 120 (net.link.ether.inet.max_age=120) > - Run receiver as "iperf3 -s -i10" > - Run sender as "iperf3 -c -u -b4m -l100 -i10 -t3600" > - Observe packet loss of a few packets every 120 seconds on the > receiver > > I've tried this on several different hosts, with different Ethernet cards. > Same result. Also, reducing net.link.ether.inet.max_age isn't *needed* for > the problem to occur - it simply makes the problem visible faster. The > loss interval is clearly correlated with the net.link.ether.inet.max_age > value. > > Extract of typical iperf3 output on the receiver end showing loss: > > [ 5] 1810.00-1820.00 sec 4.77 MBytes 4.00 Mbits/sec 0.036 ms 0/50000 (0%) > [ 5] 1820.00-1830.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1830.00-1840.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 4/50000 (0.008%) > [ 5] 1840.00-1850.00 sec 4.77 MBytes 4.00 Mbits/sec 0.029 ms 0/49997 (0%) > [ 5] 1850.00-1860.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49998 (0%) > [ 5] 1860.00-1870.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/50000 (0%) > [ 5] 1870.00-1880.00 sec 4.77 MBytes 4.00 Mbits/sec 0.030 ms 0/50000 (0%) > [ 5] 1880.00-1890.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1890.00-1900.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1900.00-1910.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/49999 (0%) > [ 5] 1910.00-1920.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 0/49996 (0%) > [ 5] 1920.00-1930.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1930.00-1940.00 sec 4.77 MBytes 4.00 Mbits/sec 0.013 ms 0/50000 (0%) > [ 5] 1940.00-1950.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/50000 (0%) > [ 5] 1950.00-1960.00 sec 4.77 MBytes 4.00 Mbits/sec 0.006 ms 4/50000 (0.008%) > [ 5] 1960.00-1970.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49999 (0%) > [ 5] 1970.00-1980.00 sec 4.77 MBytes 4.00 Mbits/sec 0.007 ms 0/49996 (0%) > > I've tried to read some of the code in /sys/netinet/if_ether.c, and I > get impression that FreeBSD is supposed to (proactively) refresh an ARP > entry *before* it expires - specifically the arptimer() routine which > has the comment > >                  * Expiration time is approaching. >                  * Let's try to refresh entry if it is still >                  * in use. > > However, I'm uncertain of whether my reading here is correct. Can > somebody tell me if FreeBSD is supposed to proactively refresh an ARP > entry? > > My idea here is that as long as you have a valid ARP entry, it should > be possible to refresh the ARP entry *and* continue sending traffic > (with no packet drops) - i.e. the goal is to completely avoid the > drops I'm currently seeing on every ARP refresh. > > Steinar Haug, Nethelp consulting, sthaug@nethelp.no > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"