From owner-freebsd-net Tue Nov 20 21:19:13 2001 Delivered-To: freebsd-net@freebsd.org Received: from silby.com (cb34181-a.mdsn1.wi.home.com [24.14.173.39]) by hub.freebsd.org (Postfix) with ESMTP id 0E23637B416 for ; Tue, 20 Nov 2001 21:19:09 -0800 (PST) Received: (qmail 97952 invoked by uid 1000); 21 Nov 2001 05:19:07 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 21 Nov 2001 05:19:07 -0000 Date: Tue, 20 Nov 2001 23:19:07 -0600 (CST) From: Mike Silbersack To: Ian West Cc: Subject: Re: expiring cached routes on in_pcb entries. In-Reply-To: <20011121152648.Y80670@rose.niw.com.au> Message-ID: <20011120230807.O97823-100000@achilles.silby.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, 21 Nov 2001, Ian West wrote: > I have seen the problem occur on two different machines, one is running > code 4.3-STABLE FreeBSD 4.3-STABLE #0: Thu May 10 15:13:04 CST 2001 > the other is 4.3-STABLE FreeBSD 4.3-STABLE #0: Mon May 28 16:10:27 CST > 2001 Both machines showed named requests taking the wrong route. Both > recovered by restarting named. > > The code I am actually looking at is the source on a 4.4 stable box. I > will see if I can duplicate the problem with 4.4 stable. Are the recent > changes a fix for this type of behaviour, or something that may have > introduced it ? Hm, good question. I was going to suggest that rev 1.59.2.2 would fix your problem, but apparently it only fixes the problem with routes going away, not routes appearing. You're probably best contacting Ruslan (ru@freebsd.org) directly; he's been the one doing the work in that file, and could probably tell you if his more recent commits address your problem. As for the expiration of cloned routes: They're only timed out by a kernel process which runs minimally once every 10 minutes (more often under heavy route load.) This would explain why they're persisting longer than you expect them to. I wouldn't worry about the longer than expected expiration though; expiration of cloned routes isn't the issue here; the routing code should be invalidating the existing cloned routes when the new route appears. (Apparently this is not happening in your situation.) Mike "Silby" Silbersack To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message