Date: Fri, 20 Jan 2017 06:49:45 -0600 From: "Dean E. Weimer" <dweimer@dweimer.net> To: Jon Radel <jon@radel.com> Cc: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Tuning Route Cache Message-ID: <23dc5b28cf21bbea762700e426346d39@dweimer.net> In-Reply-To: <28d24a44-9e1c-7c12-d7e8-6f243a350510@radel.com> References: <ae39bbc53f3e2f2b1afa3afa93b43fa4@dweimer.net> <28d24a44-9e1c-7c12-d7e8-6f243a350510@radel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?23dc5b28cf21bbea762700e426346d39>