what is a suitable scope for isc dhcp?

[David W. Hankins]

On Mon, Jun 28, 2010 at 10:36:24AM -0400, Steve van der Burg wrote:
> That number is halfway to the OP's.  I do that on both members of a v3.0.7 failover pair and it works well.

I made two changes to how DHCP does its internal hash table structures
in 3.1.0.  This has carried forward to our current releases, 4.1.1-P1
and 4.2.0rc1.

First, I resized a number of hash tables (some were ludicrously big,
others were undersized, all were fixed sizes - wanted to do dynamic
sizing but didn't have the time).  The 3.0.x compiled-in default was;

#define DEFAULT_HASH_SIZE       9973

Nearly every hash table in memory was that size (that's why it had to
be so small, there are a lot of tables).  Allowing some tables to be
small, while other tables could be larger, permitted me to 'right
size' more tables on a net zero effect to memory used.

For host records, this allowed;

# define HOST_HASH_SIZE         22501

With no increase in baseline memory between 3.0.x and 3.1.x.

This can be altered at compile-time (provide 'HOST_HASH_SIZE' in
includes/site.h I think).  Values over 65535 will not be useful.  This
is because the 'data string' hash function (used for hardware and
client identifier lookups) uses a 16-bit accumulator, so it outputs a
16-bit integer.  You can use a larger table, but it will go to waste.

Anecdotally, I only made this change so that we could support option
space hashes, rather than direct array lookups by option code index
as is done in 3.0.x (dhcp_universe->options[0-255] does not work
very well in DHCPv6 where option codes are 16-bits, and the table is
sparsely populated...it works even less well in the VSIO, VCIO, VIVSO
and VIVCO option spaces were option codes are enterprise ID's, 32
bits).  So, this change was made in 3.1.0 in preparation for the
DHCPv6 work we released in 4.0.0.

So an upgrade to 3.1 or later is advisable for anyone with more
than 9,973 host records.  I would recommend 4.1.1-P1.


At the same time, the algorithm to do hash table lookups by IP
address in 3.1.0 was changed, as I discovered it was embarrassingly
bad.  The 3.0.x software uses the same 'data string' function for
all hash inputs, client identifier or IP address alike.  Since IPv4
addresses are always 4 bytes long, and the accumulator uses a 1-bit
shift per each octet for mixing, the hash algorithm can never output
a value larger than 3825.  So it can never use a hash bucket larger
than that, for IP-address based lookups.

The 3.1.0/current by-ip-address hash algorithm simply treats the IPv4
address as a 32-bit integer, and performs a direct modulus.  But
the 'data string' hash algorithm (for chaddr and uid lookups) still
has the 16-bit limitation.  Something I intended to address later.

So an upgrade to 3.1 or later is advisable for anyone with more
than 3,825 dynamic leases.  I would recommend 4.1.1-P1.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20100702/efdef783/attachment.bin>