Tuning Route Cache

Dean E. Weimer dweimer at dweimer.net
Fri Jan 20 12:49:53 UTC 2017


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/


More information about the freebsd-questions mailing list