With stock 1.5.2 (i386 with nearly GENERIC kernel; P2/400Mhz Celeron) it
takes about 5min 30 seconds to add 8192 aliases figures in that it will take
about 1.5 hours for the box to boot and the aliases added.  Would -current
be presumably any different?  I'm adding the aliases to the loopback as I
couldn't get a ping out of ones added to the fxp0.  Top shows the system
usage pretty much pegged at 100% the whole time.

So, once loaded things work fine and I don't figure that this thing will get
booted often, but...   If it would just load a wee bit quicker...

Thanks,

peter

on 9/25/02 2:31 PM, Thor Lancelot Simon at tls@rek.tjls.com wrote:

> On Wed, Sep 25, 2002 at 11:46:52AM -0400, Greg A. Woods wrote:
>> [ On Wednesday, September 25, 2002 at 08:54:11 (-0500), Peter Eisch wrote: ]
>>> Subject: Lots of ip addr aliases, best way?
>>> 
>>> 
>>> I'm good on all the other details but I'd like to avoid 128k aliases on an
>>> interface if there's a better way to do it.
>> 
>> I'm interested in knowing whether or not you did try instantiating the
>> aliases, and if so whether there were any actual problems in handling
>> them (I understand that doing the instantiation with 'ifconfig'
> 
> There should be no problem; when we initially wrote the interface-address
> hashing code, we tested with 64K aliases and it worked fine.  You'll want
> to increase the number of buckets int he ifaddr hash in your kernel config
> for good performance.
> 
> However, when we wrote that code someone (Bill Studenmund?) proposed an
> alternate path that we didn't take -- and perhaps should have.  It would
> not be very invasive and would be ideally suited to problems like yours.
> Instead of storing just an address and netmask for each interface address,
> perhaps we should store an "address mask", which would be defined so that
> any address falling within the "address mask" when applied to the address
> would be accepted as local.  That way you could have an interface with
> address 10.0.0.9/16 (let's say) which would accept packets for any address
> that fell within the 10.0.0.0/16 network.  Obviously, you would have to
> watch our for dependencies on "interface address" in the transmit path
> and be sure to use the address to which a given socket was bound (which
> could be anything within the "address mask").
> 
> This could probably be whacked together in an afternoon.  _This_ afternoon,
> however, I intend to climb some nice warm Sierra granite, which is how I
> intend to spend most of my afternoons for at least the rest of the week.
> But don't let that stop you from writing the code. ;-)