multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bruce M. Simpson wrote:
> Bakul Shah wrote:
>> 1) A packet arrives on an interface.  If this interface is
>>    associated with more than one FIB, which FIB does it get
>>    given to?
>>   
> 
> If you only have a single FIB, there is no issue here.
> If you have multiple FIBs, the decision gets made by the classifier.
> 
>> 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.
>>   
> 
> Up until now, the BSD forwarding code always forwarded packets on the 
> basis of the destination address.
> 
> In an IP environment this is totally reasonable. Most implementations 
> work on this basis -- ultimately, there is a fan-out to a collection of 
> tries which hold the prefix information, and there has to be a decision 
> about which trie(s) to use for resolving the next-hop. Linux iproute2 
> works on this basis more or less.
> 
> So the classifier is NOT doing the job of the FIB.
> 
>> 3) When a local packets needs to be sent, which FIB gets it?
>>    Does setfib decides that?  If there a default FIB?
>>   
> 
> If you look at Julian's patch, he's added an option to the socket layer 
> to control this.
> There is a default FIB which is used when no FIB tag exists.

actually this ha changed in the latest code..
now all packets have a fib. as do all sockets and processes.
If you do nothing those values are all 0 meaning FIB 0.

> 
> 
>> 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?
>>   
> 
> You only need to pass through pf/ipfw if you wish to source-route 
> packets, or need to apply a forwarding policy decision more complex than 
> the destination field, which is all rtalloc() has historically supported.
> 
> If there is any additional latency or slowdown, it's down to how good 
> your matching algorithms are as you enter the classifier.
> 
>>
>> 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?
>>   
> 
> It doesn't buy anything because there is still no 1:1 mapping -- the 
> link-layer destination address maps to an ifp, and multiple aliases 
> exist on the ifp.
> 
> You still need a classifier to look at other fields in the message and 
> decide, based on policy, which FIB is used for next-hop resolution.
> 
> Tag switching systems avoid the issue by prepending a tag, but of 
> course, what does a packet go through upon entry to an MPLS domain?
> 
> You guessed it: A classifier.
> 
> cheers
> BMS
>