multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bakul Shah wrote:
> On Tue, 29 Apr 2008 13:42:03 PDT Julian Elischer <julian at elischer.org>  wrote:
>> Interfaces are not however assigned to  FIB instance. each FIB may
>> contain entries for each interface, and by default they do, but you
>> can delete teh entries associated with a particular interface from
>> a particular FIB so that fib will never use that interface.
>>
>> An interface may however be present in entries from multiple FIBs
>> in which case the INCOMING packets on that interface need to
>> be disambiguated with respect to which FIB they belong to.
> 
> 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.


> 
> 3) When a local packets needs to be sent, which FIB gets it?
>    Does setfib decides that?  If there a default FIB?

the socket has a fib assocuated with it.
it is inherrited from the process which has a fib associated with it,
which it inherrited from its parent
which probbaly used the setfib syscall.

A process can also use the setfib socket option to make a socket with
a different FIB to its own default fib.

> 
>> This is a job for an outside entity (from the fibs).
>> In this case a packet classifier such as pf or ipfw is ideal
>> for the job. providing an outside mechanism for implementing
>> whatever policy the admin wants to set up.
> 
> I believe having to use pf/ipfw will slow things down a bit
> so the question is what does associating an interface with
> multiple FIBs buy you?

interfaces are not associated with FIBS on input. Just output..
i.e. a FIB knows about an interface or it doesn't. If it doesn't
know about it it can't send an packets out that way can it?

> 
>> if you have several alias addresses on an interface it is possible
>> that some FIBS know about some of them and others know about other
>> addresses. New addresses when added are added to each FIB and
>> whatever is adding them shoudl remove them from the ones that don't
>> need it.  This may change but it fits in with how the current code
>> works and keeps the diff to a manageable size.
>> (and it suits what I need for work where a route manager daemon
>> knows to do this.)

> 
> Wouldn't it make sense to treat each alias as on a separate
> logical interface?  Then each logical interface belongs to
> exactly one FIB.  On input you decide which logical inteface
> a packet arrived on by looking at its destination MAC
> address.  That reduces confusion quite a bit, at least in my
> mind!  What does doing more than this buy you?

you are talking about vimage (for FreeBSD) or what cisco calls VRF.

Stop thinking about receive interfaces... routing is only intersted in
OUTGOING interfaces.