Date: Wed, 30 Apr 2008 18:56:07 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Bakul Shah <bakul@bitblocks.com> Cc: FreeBSD Net <freebsd-net@freebsd.org>, Julian Elischer <julian@elischer.org>, Kevin Oberman <oberman@es.net> Subject: Re: multiple routing tables review patch ready for simple testing. Message-ID: <4818B2B7.2070401@FreeBSD.org> In-Reply-To: <20080430172705.2E3275AD6@mail.bitblocks.com> References: <20080430172705.2E3275AD6@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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?4818B2B7.2070401>