Date: Wed, 13 Apr 2011 16:12:14 +0100 From: Pete French <petefrench@ingresso.co.uk> To: freebsd-stable@freebsd.org, petefrench@ingresso.co.uk, qing.li@bluecoat.com Subject: RE: IPv6 / ndp taking a long time to resolve in this weeks STABLE Message-ID: <E1QA1jq-0001Bm-2D@dilbert.ticketswitch.com> In-Reply-To: <B143A8975061C446AD5E29742C531723030182@PWSVL-EXCMBX-01.internal.cacheflow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> I haven't modified the ndp related code for quite a long time, but recently have seen > some postings regarding incomplete ndp entries (still catching up on emails). > > Changes committed in the past year or so were related to locking and memory leak, not > functional updates. > > I have seen this issue with ARP, where incoming ARP requests are not completing > the entries until an explicit outgoing packet is generated right after the > system boots. > > Email me when you recreate the problem. Hi, thanks for the email - I canb recreate this very easily here now. I have also shown that it the problem doesnt happen on a kernel from Feb 25th, but does happen on a kernel from this week. cery easy to demonstarte - set up 2 machines. Ping one from the other so that it is pinging nicely. Then delete the ndp entry. The ping freezes - sometimes for 20 seconds! It eventually starts again with all the inrtervening packets lost. This only happens if the machone being oinged is running the newer kernel. If you do it the other way round then all is fine. I havent tried to reproduce what I saw with CARP - but that feels like the same problem to me. i.e. ndp cannot find the CARP interface's ether address, and tahst why connectivity does not work. -pete.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E1QA1jq-0001Bm-2D>