Increased daemon startup time after combining subnets

[Akey, Michael]

After combining 4 subnet statements into one monolithic subnet statement our DHCP servers take more than double the time to process the leases database file on startup (from about 1 minute to over 3).  These subnets were already quite large /17's but combined make a single /15.  Normally we wouldn't make a subnet and pool that large but the usual rules don't apply to this network - it's for wireless clients and broadcast traffic is limited by network gear.

Having little knowledge of how dhcpd handles the leases file on startup, I assumed that merely combining these four subnets and pools into one single subnet and pool would have little effect on the operation of dhcpd.  I'm not adding any significant about of potential leases, so what is causing the additional startup time?  Any ideas?

Here is a before and after config snippet:

# Before

subnet 10.248.0.0 netmask 255.255.128.0 {
    default-lease-time 3600;
    max-lease-time 3600;
    option routers 10.248.0.1;
    option subnet-mask 255.255.128.0;
    pool {
        # Pool Statements
        failover peer "dhcp";
        deny dynamic bootp clients;
        # Allow statements
        range 10.248.0.128 10.248.127.254;
    }
}

subnet 10.248.128.0 netmask 255.255.128.0 {
    default-lease-time 3600;
    max-lease-time 3600;
    option routers 10.248.128.1;
    option subnet-mask 255.255.128.0;
    pool {
        failover peer "dhcp";
        deny dynamic bootp clients;
        range 10.248.128.128 10.248.255.254;
    }
}

subnet 10.249.0.0 netmask 255.255.128.0 {
    default-lease-time 3600;
    max-lease-time 3600;
    option routers 10.249.0.1;
    option subnet-mask 255.255.128.0;
    pool {
        failover peer "dhcp";
        deny dynamic bootp clients;
        range 10.249.0.128 10.249.127.254;
    }
}

subnet 10.249.128.0 netmask 255.255.128.0 {
    default-lease-time 3600;
    max-lease-time 3600;
    option routers 10.249.128.1;
    option subnet-mask 255.255.128.0;
    pool {
        failover peer "dhcp";
        deny dynamic bootp clients;
        range 10.249.128.128 10.249.255.254;
    }
}


# Afterward

subnet 10.248.0.0 netmask 255.254.0.0 {
    default-lease-time 3600;
    max-lease-time 3600;
    option routers 10.248.0.1;
    option subnet-mask 255.254.0.0;
    pool {
        failover peer "dhcp";
        deny dynamic bootp clients;
        range 10.248.0.128 10.249.255.254;
    }
}


Mike Akey
Systems Engineer, IT Infrastructure
University Information and Technology | Oregon State University
541-737-4948 | uit.oregonstate.edu
_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users

[Simon Hobson]

Akey, Michael <[hidden email]> wrote:

> After combining 4 subnet statements into one monolithic subnet statement our DHCP servers take more than double the time to process the leases database file on startup (from about 1 minute to over 3).  These subnets were already quite large /17's but combined make a single /15.  Normally we wouldn't make a subnet and pool that large but the usual rules don't apply to this network - it's for wireless clients and broadcast traffic is limited by network gear.
>
> Having little knowledge of how dhcpd handles the leases file on startup, I assumed that merely combining these four subnets and pools into one single subnet and pool would have little effect on the operation of dhcpd.  I'm not adding any significant about of potential leases, so what is causing the additional startup time?  Any ideas?

That does seem odd - as you say, there's very little difference in the size of the pool.

AIUI from previous comments in here (I'm not a dev, so the code means very little to me), internally the server keeps a structure for all potential leases - that's an entry for every IP that falls within a defined pool/range regardless of whether it actually appears in the leases file. Access into the structure is via a hashing function - so that's one potential area to look at, I vaguely recall comments that this can become inefficient unless adjusted for large pools.
Then the leases file is read in, with each entry being used to update the in-memory storage.

Since AIUI there is only one leases structure, it's hard to see why having all the addresses in one pool vs 4 pools of the same total size should make such a difference. I assume this is consistent and not just a "one off as it converts stuff" issue ?

That is for a single server - you are running failover. I wonder if there's a difference between processing one big pool vs 4 smaller ones with failover. You could easily test that by going back to your 4 separate pools while keeping the same subnet - you can have multiple pools/ranges, each with a separate failover statement, per subnet.

_______________________________________________
dhcp-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/dhcp-users