From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 17:56:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C4261065671 for ; Wed, 30 Apr 2008 17:56:10 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id 3500D8FC26 for ; Wed, 30 Apr 2008 17:56:09 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 659761046ED; Wed, 30 Apr 2008 13:56:09 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 30 Apr 2008 13:56:09 -0400 X-Sasl-enc: C4SMOmoddiKT9Wu9JNZn4wD6r3+Rpf0zs+LVCpOAXv2h 1209578169 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id A342D1E7B3; Wed, 30 Apr 2008 13:56:08 -0400 (EDT) Message-ID: <4818B2B7.2070401@FreeBSD.org> Date: Wed, 30 Apr 2008 18:56:07 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080423) MIME-Version: 1.0 To: Bakul Shah References: <20080430172705.2E3275AD6@mail.bitblocks.com> In-Reply-To: <20080430172705.2E3275AD6@mail.bitblocks.com> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Julian Elischer , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 17:56:10 -0000 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