Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Apr 2008 11:41:49 -0700
From:      Julian Elischer <julian@elischer.org>
To:        "Bruce M. Simpson" <bms@FreeBSD.org>
Cc:        Bakul Shah <bakul@bitblocks.com>, FreeBSD Net <freebsd-net@freebsd.org>, Kevin Oberman <oberman@es.net>
Subject:   Re: multiple routing tables review patch ready for simple testing.
Message-ID:  <4818BD6D.40806@elischer.org>
In-Reply-To: <4818B2B7.2070401@FreeBSD.org>
References:  <20080430172705.2E3275AD6@mail.bitblocks.com> <4818B2B7.2070401@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
> 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4818BD6D.40806>