On Sat, Sep 25, 2004 at 07:11:05PM +0000, Michael van Elst wrote:
> carton@Ivy.NET (Miles Nordin) writes:
> 
> >The problem is, when one of these loopback aliases I've used for the
> >tunnel outer destination becomes unreachable and then comes back, the
> >tunnel stops working and then stays broken.  Here's a typescript from
> >a gif tunnel that broke when I rebooted its endpoint.  gif seems to be
> >the less quirky of gif and gre, in that I can get the tunnel working
> >by changing the outer destination to a different address and change it
> >back, on the endpoint that was not rebooted:
> 
> gif and gre cache the route to the destination when configured and
> this cache isn't invalidated when the routing table changes.

This is going to come up again and again.  In fact, it already has!
It doesn't look to me like it is a hard problem to fix.  In a discussion
on tech-net, somebody suggested that we use sequence numbers for the
purpose.  Let rtalloc compare a sequence number ro_seqno in the struct
route with a sequence number ro_rt->rt_seqno in the cached rtentry to
find out if the rtentry is out of date.  Increase by one the rt_seqno
field of changed/added routes and all of its ancestors.  When rtalloc
finds ro_seqno != ro_rt->rt_seqno, it knows that the cached route is
potentially out-of-date, so it calls rtalloc1 to look up the route again,
and copies ro_rt->rt_seqno into ro_seqno.  If ro_seqno == ro_rt->rt_seqno,
then the cached route is valid (modulo wrap-around!).  I'm not sure
how to deal with wrap-around, but it seems like that was part of the
discussion on tech-net.

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933