From owner-freebsd-net@FreeBSD.ORG Fri Apr 1 14:50:30 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 286DD1065674 for ; Fri, 1 Apr 2011 14:50:30 +0000 (UTC) (envelope-from korvus@comcast.net) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by mx1.freebsd.org (Postfix) with ESMTP id C8E7D8FC0A for ; Fri, 1 Apr 2011 14:50:29 +0000 (UTC) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta09.westchester.pa.mail.comcast.net with comcast id SEmZ1g0020cZkys59EqW02; Fri, 01 Apr 2011 14:50:30 +0000 Received: from [192.168.2.164] ([206.210.89.202]) by omta10.westchester.pa.mail.comcast.net with comcast id SEqK1g00q4Mx3R23WEqMnN; Fri, 01 Apr 2011 14:50:28 +0000 Message-ID: <4D95E62A.5000109@comcast.net> Date: Fri, 01 Apr 2011 10:50:18 -0400 From: Steve Polyack User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110316 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Frederique Rijsdijk References: <20110401141655.GA5350@deta.isafeelin.org> In-Reply-To: <20110401141655.GA5350@deta.isafeelin.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Network stack unstable after arp flapping X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 01 Apr 2011 14:50:30 -0000 On 04/01/11 10:16, Frederique Rijsdijk wrote: > Hi, > > We (hosting provider) are in the process of implementing ipv6 in our network (yay). Yesterday one of the final steps in configuring and updating our core routers were taken, which did not go entirely as planned. As a result, the default gateway mac addresses for all our machines changed about 800 times in a time span of about 4 minutes. > > Here's a small piece of the logging: > > Mar 31 18:36:12 srv01 kernel: arp: x.x.x.1 moved from 00:00:0c:9f:f0:3d to 00:00:0c:07:ac:3d on bge0 > Mar 31 18:36:12 srv01 kernel: arp: x.x.x.1 moved from 00:00:0c:07:ac:3d to 00:00:0c:9f:f0:3d on bge0 > Mar 31 18:36:13 srv01 kernel: arp: x.x.x.1 moved from 00:00:0c:9f:f0:3d to 00:00:0c:07:ac:3d on bge0 > Mar 31 18:36:14 srv01 kernel: arp: x.x.x.1 moved from 00:00:0c:07:ac:3d to 00:00:0c:9f:f0:3d on bge0 > Mar 31 18:36:14 srv01 kernel: arp: x.x.x.1 moved from 00:00:0c:9f:f0:3d to 00:00:0c:07:ac:3d on bge0 > Mar 31 18:36:14 srv01 kernel: arp: x.x.x.1 moved from 00:00:0c:07:ac:3d to 00:00:0c:9f:f0:3d on bge0 > Mar 31 18:36:15 srv01 kernel: arp: x.x.x.1 moved from 00:00:0c:9f:f0:3d to 00:00:0c:07:ac:3d on bge0 > > The x.x.x.1 is always the same IP, the gateway of the machine. > > The result of that, is that loads of FreeBSD machines (6.x, 7.x and 8.x) developed serious network issues, mainly being no or slow traffic between other (FreeBSD) machine accross different VLAN's in our own network. > > First thing that comes to mind is the network itself, but all Linux machines (Ubuntu, Red Hat and CentOS) had no issues at all. Only BSD. > > An arp -ad on both machines where problems occured, didn't solve anything. What worked better was /etc/rc.d/netif restart and a /etc/rc.d/routing restart. Some machines even had to be rebooted in order to get networking back to normal. > > This almost sounds like a bug in the network stack in BSD, but I can not imagine that I'm right. The BSD networking stack is considered to be one of the best.. > > Any ideas anyone? We experienced a similar issue here, but IIRC only on our 8.x systems (we don't have any 7.x). Disabling flowtable cleared everything up immediately. You can try that and see if it helps. It seems like the flowtable caches and associates the next-hop router MAC address with each flow, and unfortunately this doesn't get purged when the kernel senses and logs an ARP change. The only other solution I've seen was to stop all network traffic on the machine until the flows/cache entries expired. http://www.freebsd.org/cgi/query-pr.cgi?pr=155604 has more details of my run-in with this. The title should be corrected though, as I found shortly after that all traffic is affected. - Steve