multiple routing tables review patch ready for simple testing.

[John Hay]

> >This confuses me....
> >
> >The whole point of a FIB is to decide the *next* hop for a
> >given input packet. So questions.
> >1) A packet arrives on an interface.  If this interface is
> >   associated with more than one FIB, which FIB does it get
> >   given to?
> >
> 
> which ever one you select, using the policy of your choice.
> 
> that's what policy routing is about.
> if you don't WANT policy based routing, dont turn it on.
> 
> 
> 
> >2) If that decision is taken by a a packet 'classifier',
> >   isn't it in effect doing the job of a FIB (deciding the
> >   next hop, which happens to be a local FIB)?  Recall that
> >   basically a packet passes from a FIB to another FIB until
> >   it gets to its eventual destination.
> 
> the packet classifier selects a FIB which in turn implements a 
> particular routing decision tree.
> In the degenerate case where a FIB has only one route
> then you are correct, but there are technical reasons why this is
> superior to just using a fwd rule in the firewall.

The linux guys seems to have multiple fibs (or whatever they call them)
which they can chain together by giving them different priorities. The
effect seems to be that a packet will be matched through the highest
priority fib to the lowest until a route match is found en then is used.
Will something like that be possible? I came across that kind of use
with the olsr guys. They let olsrd twiddle one of the higher priority
fibs and then put fallback routes in a lower priority fib. That way
olsrd can override a route (even the default route) and when olsrd
exists and deltes all its routes, the original ones are still in the
lower priority fib and will be used.

John
-- 
John Hay -- John.Hay at meraka.csir.co.za / jhay at FreeBSD.org