From owner-freebsd-bugs@FreeBSD.ORG Fri Jun 19 12:36:58 2015 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 532251F2 for ; Fri, 19 Jun 2015 12:36:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D890BD2 for ; Fri, 19 Jun 2015 12:36:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t5JCawrt081451 for ; Fri, 19 Jun 2015 12:36:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 200971] ARP table not being updated Date: Fri, 19 Jun 2015 12:36:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: n+freebsd@nirf.de X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 12:36:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200971 Bug ID: 200971 Summary: ARP table not being updated Product: Base System Version: 10.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: n+freebsd@nirf.de Hello, I've got a FreeBSD router which, when receiving an ARP response, sometimes doesn't add the received MAC address to its ARP table. When I add the address manually everything works as expected. The network interface is a NVIDIA nForce MCP55 Networking Adapter but I've seen the same problem on a QLogic NetXtreme II BCM5709 1000Base-T (C0). There are no recent dmesg lines when the problem occurs. Sometimes the problem persists for some MAC adresses for longer periods of time but can be temporarily fixed by rebooting. This is the network interface's configuration: root@fw0:~ # ifconfig nfe0 nfe0: flags=8943 metric 0 mtu 1500 options=c219b ether 00:1b:24:e0:56:cb inet 10.182.0.2 netmask 0xfffe0000 broadcast 10.183.255.255 inet 10.182.0.1 netmask 0xfffe0000 broadcast 10.183.255.255 vhid 2 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active carp: MASTER vhid 2 advbase 1 advskew 150 There are a few hundred devices on this LAN: root@fw0:~ # arp -a -n | wc -l 299 root@fw0:~ # netstat -m 1033/3272/4305 mbufs in use (current/cache/total) 1032/1764/2796/2040374 mbuf clusters in use (current/cache/total/max) 1032/1751 mbuf+clusters out of packet secondary zone in use (current/cache) 0/8/8/1020186 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/302277 9k jumbo clusters in use (current/cache/total/max) 0/0/0/170031 16k jumbo clusters in use (current/cache/total/max) 2322K/4378K/6700K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for mbufs delayed (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters delayed (4k/9k/16k) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 10.182.31.204 is the address I'm pinging the router from: root@fw0:~ # tcpdump -i nfe0 -n arp or icmp | grep 10.182.31.204 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on nfe0, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 00:26:38.873053 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 0, length 64 00:26:38.873076 ARP, Request who-has 10.182.31.204 tell 10.182.0.2, length 28 00:26:38.878488 ARP, Reply 10.182.31.204 is-at 00:19:99:59:8f:7a, length 46 00:26:39.874292 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 1, length 64 00:26:39.874309 ARP, Request who-has 10.182.31.204 tell 10.182.0.2, length 28 00:26:39.879737 ARP, Reply 10.182.31.204 is-at 00:19:99:59:8f:7a, length 46 00:26:40.875381 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 2, length 64 00:26:40.875396 ARP, Request who-has 10.182.31.204 tell 10.182.0.2, length 28 00:26:40.877751 ARP, Reply 10.182.31.204 is-at 00:19:99:59:8f:7a, length 46 00:26:41.878761 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 3, length 64 00:26:41.878775 ARP, Request who-has 10.182.31.204 tell 10.182.0.2, length 28 00:26:41.880701 ARP, Reply 10.182.31.204 is-at 00:19:99:59:8f:7a, length 46 00:26:42.880428 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 4, length 64 00:26:42.880442 ARP, Request who-has 10.182.31.204 tell 10.182.0.2, length 28 00:26:42.881555 ARP, Reply 10.182.31.204 is-at 00:19:99:59:8f:7a, length 46 00:26:43.892658 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 5, length 64 00:26:43.892672 ARP, Request who-has 10.182.31.204 tell 10.182.0.2, length 28 00:26:43.893789 ARP, Reply 10.182.31.204 is-at 00:19:99:59:8f:7a, length 46 00:26:44.897217 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 6, length 64 00:26:44.897232 ARP, Request who-has 10.182.31.204 tell 10.182.0.2, length 28 00:26:44.898380 ARP, Reply 10.182.31.204 is-at 00:19:99:59:8f:7a, length 46 ^C196 packets captured 161947 packets received by filter 0 packets dropped by kernel root@fw0:~ # arp -a -n | grep 10.182.31.204 ? (10.182.31.204) at (incomplete) on nfe0 expired [ethernet] root@fw0:~ # arp -s 10.182.31.204 00:19:99:59:8f:7a root@fw0:~ # tcpdump -i nfe0 -n arp or icmp | grep 10.182.31.204 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on nfe0, link-type EN10MB (Ethernet), capture size 65535 bytes capability mode sandbox enabled 00:26:52.943674 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 14, length 64 00:26:52.943692 IP 10.182.0.2 > 10.182.31.204: ICMP echo reply, id 1878, seq 14, length 64 00:26:53.944908 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 15, length 64 00:26:53.944921 IP 10.182.0.2 > 10.182.31.204: ICMP echo reply, id 1878, seq 15, length 64 00:26:54.966946 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 16, length 64 00:26:54.966959 IP 10.182.0.2 > 10.182.31.204: ICMP echo reply, id 1878, seq 16, length 64 00:26:55.970233 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 17, length 64 00:26:55.970246 IP 10.182.0.2 > 10.182.31.204: ICMP echo reply, id 1878, seq 17, length 64 00:26:56.972007 IP 10.182.31.204 > 10.182.0.2: ICMP echo request, id 1878, seq 18, length 64 00:26:56.972021 IP 10.182.0.2 > 10.182.31.204: ICMP echo reply, id 1878, seq 18, length 64 ^C95 packets captured 114882 packets received by filter 0 packets dropped by kernel -- You are receiving this mail because: You are the assignee for the bug.