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 [EMAIL PROTECTED]
pgp00000.pgp
Description: PGP signature
