Date: Wed, 30 Apr 2008 12:13:44 -0700 From: Bakul Shah <bakul@bitblocks.com> To: "Bruce M. Simpson" <bms@FreeBSD.org> 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: <20080430191344.6C4B95AD6@mail.bitblocks.com> In-Reply-To: Your message of "Wed, 30 Apr 2008 18:56:07 BST." <4818B2B7.2070401@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Apr 2008 18:56:07 BST "Bruce M. Simpson" <bms@FreeBSD.org> wrote: > > 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. Thanks for the explanation! I guess we look at it somewhat differently. You seem to imply that using anything other than destination address is not a FIB's job. While to me a FIB can use anything it wants for its forwarding decision. > > 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. Hmm... a few years ago when we looked at this stuff in the context of hardware assisted forwarding that used more than just the destination ip address (probably you'd call it "policy based routing"), it was not clear to me at the time whether it made sense to separate such classification. We were looking at a function something like nexthop = lookup(protocol, src addr, dst addr, src port, dst port, ...) I suppose it makes sense to feed everything except the dst addr to a classifier when doing this in software (and may be even hardware but there you have different constraints). For us the entire "forwarding table/classifier" was really just a funky microprogram. That is, each microinstruction ate some bits of a packet and decided which next instruction to fetch and execute. It wasn't clear to me at the time which was better -- should it eat the dst addr first or last.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080430191344.6C4B95AD6>