From owner-freebsd-net@FreeBSD.ORG Tue Sep 14 16:32:19 2010 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46AA8106564A; Tue, 14 Sep 2010 16:32:19 +0000 (UTC) (envelope-from julian@elischer.org) Received: from out-0.mx.aerioconnect.net (out-0-35.mx.aerioconnect.net [216.240.47.95]) by mx1.freebsd.org (Postfix) with ESMTP id 222188FC0C; Tue, 14 Sep 2010 16:32:18 +0000 (UTC) Received: from idiom.com (postfix@mx0.idiom.com [216.240.32.160]) by out-0.mx.aerioconnect.net (8.13.8/8.13.8) with ESMTP id o8EGWHRM027204; Tue, 14 Sep 2010 09:32:17 -0700 X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id E525E2D601A; Tue, 14 Sep 2010 09:32:16 -0700 (PDT) Message-ID: <4C8FA3B2.4070204@elischer.org> Date: Tue, 14 Sep 2010 09:32:50 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: dave@seddon.ca References: <1284107762.5923.306.camel@das8530.vic.bigpond.net.au> <532349FC-9269-4674-872F-FA84292E264C@mimectl> <1284130306.6282.6.camel@das8440.seddon.ca> <009101cb5308$514066d0$f3c13470$@com> <1284423495.5238.99.camel@das8530.vic.bigpond.net.au> <4C8EC845.2060306@elischer.org> <1284445899.5238.155.camel@das8530.vic.bigpond.net.au> In-Reply-To: <1284445899.5238.155.camel@das8530.vic.bigpond.net.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 216.240.47.51 Cc: Robert Watson , Andrew Hannam , FreeBSD Net Subject: Re: FreeBSD route tables limited 16? (mbuf changes) 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: Tue, 14 Sep 2010 16:32:19 -0000 On 9/13/10 11:31 PM, Dave Seddon wrote: > Greetings, > > Thanks for the quick response. > > It sounds like dedicating some space for this in the mbuf would be the > best way forward, but the question is how much. I'm worried that most > freebsd users won't go for lots of route tables, which is why you went > for 4 bits originally. > > Within the network service provider space there is frequently a > requirement for lots of virtual-routing with MPLS. I imagine there are > others in my situation, including vendors and people working on > equipment like Cisco/Juniper/Lucatel. > > Regarding the size to dedicate, the best number might be 12 bits or > 4096. This would allow a route table per VLAN on a 802.1q interface. > (Actually I'm lying a little because the first and last vlan IDs aren't > usable :) ). > > Perhaps a separate option for non-common users who want many route > tables would be best. e.g. > > GIANT_ROUTETABLES=12 possibly but see below. note: it's not giant tables, but MANY tables. options LOTSA_FIBS # Use more than 4 bits to enumerate mbuf fibs. > > Seems like there would need to be changes in multiple places although > perhaps this list isn't exhaustive. So far the files to edit are: > /usr/src/sys/net/route.h > /sys/sys/mbuf.h Basically the definition of how fibs are stored in an mbuf is encapsulated in mbuf.h and a macro is used to do it everywhere. so the main damage is limited to that file. You shouldn't really do it with an option because modules built with one option would crash when mixed with a kernel built with the other option, which is problematic for support. We only allow modules and kernel to be incompatible across a version change. There was talk about revamping mbufs for 9.x. I think Robert, Andre , Randall and some of the others may want to comment on that. > > > Regarding firewalls and these multiple route tables, have you considered > having a separate firewall rule table per route table? no, but there is a separate ipfw rule-set per vnet-jail. eventually if you keep adding more and more feature per-routing table, you end up recreating the vnet-jail feature. > > > I haven't looked at the vnet jails, yet. Will do. Thanks. > > Kind regards, > Dave >