Date: Tue, 14 Sep 2010 09:32:50 -0700 From: Julian Elischer <julian@elischer.org> To: dave@seddon.ca Cc: Robert Watson <rwatson@FreeBSD.org>, Andrew Hannam <andrewh@itsallaboutbiz.com>, FreeBSD Net <net@FreeBSD.org> Subject: Re: FreeBSD route tables limited 16? (mbuf changes) Message-ID: <4C8FA3B2.4070204@elischer.org> In-Reply-To: <1284445899.5238.155.camel@das8530.vic.bigpond.net.au> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C8FA3B2.4070204>