multiple routing tables review patch ready for simple testing.

[Julian Elischer]

John Hay wrote:
>>> 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.

no we are going to do the simple thing..
such enhancements can be done later if there is a call for it.

We will just have a number of tables that you can associate a packet 
with at a number of points in its path.   having another table as the
'default route' for a table (i.e. if you don't find something look in 
another table) is something that would be relatively easy to do, but
I have not done it.



> 
> John