Date: Fri, 14 Apr 2006 10:53:23 -0400 From: "Eric W. Bates" <ericx_lists@vineyard.net> To: Jon Otterholm <jon.otterholm@ide.resurscentrum.se> Cc: freebsd-net@freebsd.org Subject: Re: Sub-interfaces Message-ID: <443FB763.3010808@vineyard.net> In-Reply-To: <443DFBF0.70606@ide.resurscentrum.se> References: <443CF4D7.1030204@ide.resurscentrum.se> <20060412201725.GA42102@heff.fud.org.nz> <443D6325.2050109@vineyard.net> <443DFBF0.70606@ide.resurscentrum.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Jon Otterholm wrote: > Eric W. Bates wrote: > >> Andrew Thompson wrote: >> >> >>> On Wed, Apr 12, 2006 at 02:38:47PM +0200, Jon Otterholm wrote: >>> >>> >>>> Hi. >>>> >>>> I am designing a new network and one way to go is to configure a >>>> router based on FreeBSD with one IF/customer. This would mean around >>>> 1000 VLAN-IF's/router - would this work? Do you see any problems >>>> with this? >>>> >>> >>> 1000 vlan interfaces will work fine. In all the stable branches (and >>> releases) the vlans will be in a linked list, this can be slower as the >>> list increases in size. In CURRENT this is now a hash list and you can >>> optimise it even more by defining VLAN_ARRAY which will directly >>> dereference the tag->ifnet. >>> >> >> >> We did run into a problem when we had too many (more than 15) >> addresses/interfaces on a system. isc-dhcpd has some table sizes >> hard-coded for some data structures. This was solved by patching >> common/discover.c (thanks to help from this list). >> >> Obviously not a problem if you aren't planning on dhcp. >> >> >> >>> Andrew >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >>> >>> >>> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > I am planing on using DHCP - any workarounds? Or maybe using another > DHCP-server? I have this snippet in my dhcpd.conf file: # PLEASE NOTE: # The dhcpd on this machine has been patched to accommodate the very # large number of IP addresses attached to the CCH interface. There # is a fixed size struct which is used to contain the list of all # current interfaces when dhcpd starts up. I upped it 16 times it's # default size # *** work/dhcp-3.0.1rc11/common/discover.c Mon May 26 09:33:31 2003 # --- work/dhcp-3.0.1rc11/common/discover.c~ Sat Nov 16 21:26:57 2002 # *************** # *** 135,144 **** # { # struct interface_info *tmp, *ip; # struct interface_info *last, *next; # ! /* In order to support more than 15 interfaces we need to # ! increase the size of the buffer. */ # ! /* char buf [2048]; */ # ! char buf [32768]; # struct ifconf ic; # struct ifreq ifr; # int i; # --- 135,141 ---- # { # struct interface_info *tmp, *ip; # struct interface_info *last, *next; # ! char buf [2048]; # struct ifconf ic; # struct ifreq ifr; # int i; I originally got this patch from a kind soul on this list (sadly I didn't keep the name). I do not fully appreciate the consequences of patching ISC's code; but our copy has run flawlessly. We currently have 151 IP's on the one machine. Ignore the version numbers in the patch. I think the line numbers in discover.c may have changed also. Note also that in our case, dhcpd is only attached to 2 of those 151 IP. It seems that when it starts up, it maintains some sort of list. When it runs out of room to store IP's/interfaces, it simply reports 'no such address' if you want to attach it to an address which comes later. It appears that if you don't care about those later addresses dhcpd will function fine on the earlier ones. However, you can't always expect that list of addresses to maintain the same order it has at boot. After adds/moves/changes restarting dhcpd caused it to fail. According to the list, fixing this properly so that dhcpd dynamically allocated sufficient space would not be hard. Perhaps it has been fixed. > /J > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?443FB763.3010808>