[Xorp-users] Patch for making it harder to crash rib when removing interfaces.

[Pavlin Radoslavov]

> > To solve the problem it needs to be decided who is responsible for
> > deleting the unicast routes that refer to the deleted vif. Currently
> > it is the protocol that added the routes, but this creates a race
> > condition.
> > If the RIB becomes responsible for deleting those routes, then we
> > need to change the route add/delete semantics between the RIB and
> > the routing protocols, because currently the protocols assume they
> > have complete control over the adding/deletion of their own routes.
> > 
> > One possible solution of breaking the race condition is to keep the
> > Vif instance around (e.g., marked as DELETED or in some different
> > container) until no RIB routes refer to it. This eventually will be
> > until all protocols finish deleting the routes they had installed
> > and were using this particular vif.
> 
> This sounds promising, and saves the lookup of the Vif.  We would have
> to check all accesses of the vif pointer to make sure the vif has not
> been logically deleted before taking actions on it.
> 
> There may be a related problem where we don't un-register multicast
> addresses on deleted vifs as well.  This doesn't appear to cause crashes,
> just keeps things from working.
> 
> If you get a patch of this nature, I'd be happy to test it.

Ben,

I just implemented the reference counting for the vif entries inside
the RIB.
I believe the reference counting needs to be done only inside the
RouteEntry constructor and destructor which reduces significantly
the amount of changes.

I will send you the patch in a private email to reduce the
unnecessary traffic on the list.
Please test it and let me know whether it fixes the problem.

Thanks,
Pavlin