From owner-freebsd-questions@freebsd.org Fri Jan 20 12:49:53 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50509CB7325 for ; Fri, 20 Jan 2017 12:49:53 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from webmail.dweimer.net (24-240-198-187.static.stls.mo.charter.com [24.240.198.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.dweimer.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31CBF179A for ; Fri, 20 Jan 2017 12:49:52 +0000 (UTC) (envelope-from dweimer@dweimer.net) Received: from www.dweimer.net (localhost [10.9.5.2]) by webmail.dweimer.net (8.15.2/8.15.2) with ESMTP id v0KCnjm2025749; Fri, 20 Jan 2017 06:49:45 -0600 (CST) (envelope-from dweimer@dweimer.net) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 20 Jan 2017 06:49:45 -0600 From: "Dean E. Weimer" To: Jon Radel Cc: FreeBSD Questions Subject: Re: Tuning Route Cache Organization: dweimer.net Reply-To: dweimer@dweimer.net Mail-Reply-To: dweimer@dweimer.net In-Reply-To: <28d24a44-9e1c-7c12-d7e8-6f243a350510@radel.com> References: <28d24a44-9e1c-7c12-d7e8-6f243a350510@radel.com> Message-ID: <23dc5b28cf21bbea762700e426346d39@dweimer.net> X-Sender: dweimer@dweimer.net User-Agent: Roundcube Webmail/1.3-beta X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 12:49:53 -0000 On 2017-01-19 9:04 pm, Jon Radel wrote: > On 1/18/17 11:55 AM, Dean E. Weimer wrote: >> I have been searching, but so far unsuccessfully found any hints. I >> have >> a situation that occurred with a FreeBSD server that is running 11.0 >> that is in a DMZ with its default router directing traffic to other >> routers in the same subnet. we had one of those routers get swapped >> out >> last night. however the FreeBSD server still had the old router in its >> cache, and couldn't communicate with the remote sites. >> > > You don't seem to have gotten any responses, at least on the list, so > I'll take a stab at this. > > I'm handicapped by a complete lack of knowledge as to how you're > getting > those routes into the routing table in the first place. You don't > really appear to say. It appears that you're not using static routes, > as you expect things to happen automatically. Are you using a routing > protocol (RIP, etc.). Are you counting on Router Discovery working? > Are > you depending on ICMP Redirects? > > Have you confirmed that the appropriate routing daemon is actually > running? Have you confirmed that the routers are actually advertising > routes correctly? > > As far as I recall, the *longest* time that you should have stale > routes > hanging around is 30 minutes if you use Router Discovery with the > default settings. Everything else should, unless you really break it, > converge much faster than that. See > > man 8 routed > > for more on some of that, including reducing the 30 minutes. > > >> I need to find a way to shorten this cache, I understand why its there >> to prevent repeated lookups, this doesn't happen all the time but I am >> thinking if I could change this cache length to a couple of hours this >> would have saved me a lot of trouble. As the routes would have cleared >> out over night and when users got back on the network in the morning >> everything would have been working. > > The routing table really doesn't work like that. If you're using > static > routing, nothing changes until you tell it to. If you're using a > routing protocol then a daemon is responsible for adding and removing > routes based on what it learns, and routes that are no longer > advertised > by a router go away pretty quickly. Even if you want routes learned > from an ICMP Redirect to be cleaned up automatically, you'll need > routed > to do it for you. See the above referenced man page. Not using any routing protocol on the FreeBSD server it only has a default gateway set. The default gateway along with the other routers are in the same subnet, so the router responds with a route redirection, then the FreeBSD server caches that they show up if you do a netstat -rnf inet listing the remote devices and the next hop. These are staying there at least 11 hours that I can confirm. I guess maybe a solution would be to set the server up with a routing protocol and let it talk to the router to get the updates rather than just receive the re directions. But that seems overly complex. They show up with a flag of UGHD and no expire listed. Flags U=RTF_UP, G=RTF_GATEWAY, H=RTF_HOST, D=RTF_DYNAMIC (by Redirect) Perhaps the change needs to occur on the Cisco router so that it sends an expiration along with the redirect. -- Thanks, Dean E. Weimer http://www.dweimer.net/