Cached IP routes

[Ruslan Ermilov]

On Mon, Mar 08, 2004 at 12:56:21PM +0100, Andre Oppermann wrote:
[...]
> > We still have a similar problem in in_gif_output(), and I wonder what
> > would be a correct fix, given the above?
> 
> in_gif_output() is not the same as the route cache of ip_forward.  It
> just caches the route to the tunnel destination which normally stays
> the same over long periods of time.  The only problem you might run
> into are route changes.  At one point in time your best path is the
> default route so a pointer to it is being cached in sc->gif_ro.  Later
> you have a better via some other gateway.  This won't be picked up by
> the gif route cache.  In 5.2 and -CURRENT you can scrap the route
> cache and just give a NULL to ip_output instead of a route.  This way
> you will always use the best path to destination.
> 
Yes, that's exactly the situation I'm faced with (yes, I know how the
routing code works).


For others.  Initially, the route to the gif(4) tunnel's destination
is through the default route.  I then add an explicit host route to the
tunnel destination, and "route change default" to point to the tunnel
(gif0).  The result is that in_gif_output() caches the default route
as the route to "tunnel destination", and doesn't pick up the "best
match" host route.

Of course, I'm working around this by deleting and re-adding the
default route, but I wonder what in your opinion would be the correct
fix.  As you properly mentioned, in_gif_output() is significantly
different from ip_forward() because the rt_dst is always the same.


Cheers,
-- 
Ruslan Ermilov
FreeBSD committer
ru at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040308/a1f24066/attachment.bin