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>