Image Blog How to Extend ISC DHCP
June 9, 2016

How to Extend ISC DHCP to Serve Over 14.1 Million IPs

Development

There are very few scenarios that would require a DHCP server to offer over 14.1 million IPs, but if you happen to encounter one, you may find that your ISC DHCP server immediately segfaults at startup or reports a vague error message and fails to start.

In this blog, we'll show how to avoid that problem by extending ISC DHCP to serve large numbers of IP addresses.

Extending ISC DHCP

Let’s assume that you need to serve a full /8 CIDR block (16.7 million IPs) from your DHCP server. While there are reasons why this is probably not a good idea, such as long daemon start-up times and too flat of a network topology, you would probably try to use a configuration similar to the following scope in your dhcpd.conf file:


subnet 10.0.0.0 netmask 255.0.0.0 {
    range dynamic-bootp 10.0.0.2 10.255.255.254;
    option broadcast-address 10.255.255.255;
    option routers 10.0.0.1;
}

If you happen to be running ISC DHCP 4.3.2 or older, the daemon will segfault upon startup and you will find the following error in your logs:

 

May  2 09:54:35 localhost kernel: dhcpd[9668]: segfault at 0 ip           (null) sp 00007ffd0d0be408 error 14

But, if you’re running ISC DHCP 4.3.3 or newer, you’ll receive the following in your logs:


May 13 16:25:08 localhost dhcpd: /etc/dhcp/dhcpd.conf line 13: 10.0.0.2-10.255.255.254 is an overly large address range.
May 13 16:25:08 localhost dhcpd:    range dynamic-bootp 10.0.0.2 10.255.255.254;
May 13 16:25:08 localhost dhcpd:                                                ^
May 13 16:25:08 localhost dhcpd: Memory overflow.

Syntactically, the scope defined above is perfectly valid, but since 304 bytes of RAM is allocated for each IP address in the scope, we need a 5.1GB allocation for this scope. Recalling that 2^32 = 4294967296 (4GB), we can see where the problem lies.

Calculating Memory Allocation

At approximately 14.1 million IPs, the amount of memory necessary to hold the scope exceeds a 32-bit allocation maximum of 4GB.

An important fact to know here is that the memory allocation is scope-based, therefore the memory overflow is also scope-based.

In order to serve a contiguous block of more than 14.1 million IPs, consider breaking up the scope into multiple, overlapping scopes.

Applied Example

For our example where we want to serve 10.0.0.0/8, we can break the single /8 scope into two /9 scopes. The first scope will cover the lower half of the /8 (10.0.0.2-10.127.255.255) and the second scope will cover the upper half of the /8 (10.128.0.0-10.255.255.254):

Dividing the scopes with an additional subnet bit isn’t necessary; it’s just what I choose to do.


# Scope #1 – lower half of 10.0.0.0/8
# a.k.a. 10.0.0.0/9 = 8.39 million IPs
subnet 10.0.0.0 netmask 255.0.0.0 {
    range dynamic-bootp 10.0.0.2 10.127.255.255;
    option broadcast-address 10.255.255.255;
    option routers 10.0.0.1;
}

# Scope #2 – upper half of 10.0.0.0/8
# a.k.a. 10.128.0.0/9 = 8.39 million IPs
subnet 10.0.0.0 netmask 255.0.0.0 {
    range dynamic-bootp 10.128.0.0 10.255.255.254;
    option broadcast-address 10.255.255.255;
    option routers 10.0.0.1;
}

The following is equally valid:


# Scope #1 – first 14 million IPs of 10.0.0.0/8
subnet 10.0.0.0 netmask 255.0.0.0 {
    range dynamic-bootp 10.0.0.2 10.213.159.128;
    option broadcast-address 10.255.255.255;
    option routers 10.0.0.1;
}

# Scope #2 – all but two of the remaining 2.7 million IPs of 10.0.0.0/8
subnet 10.0.0.0 netmask 255.0.0.0 {
    range dynamic-bootp 10.213.159.129 10.255.255.252;
    option broadcast-address 10.255.255.255;
    option routers 10.0.0.1;
}

# Scope #3 – the remaining 2 IPs of 10.0.0.0/8
subnet 10.0.0.0 netmask 255.0.0.0 {
    range dynamic-bootp 10.255.255.253 10.255.255.254;
    option broadcast-address 10.255.255.255;
    option routers 10.0.0.1;
}

If your DHCP server has enough resources, primarily RAM, you could theoretically serve scopes larger than /8, but you will need to break the scope into smaller scopes of no larger than 14.1 million IPs per scope.

You may see the following warning message in your logs:


May 17 15:58:47 localhost dhcpd: Warning: subnet 10.0.0.0/8 overlaps subnet 10.0.0.0/8

Since we are purposely creating overlapping subnets because our original subnet is “overly large”, this warning is to be expected.

The same 5.1GB of RAM must be allocated, but we’ve broken into two allocations of just over 2.5GB each.

Breaking up a large scope into smaller scopes within the same subnet may work, and could serve as a temporary fix if you’re up against the wall during an outage, but having this many hosts in a single subnet is usually not a good idea.

In this example, you’d have up to 16.7 million hosts all within the same broadcast domain. Even using switches to break up the collision domain only solves a small part of the problem. Each time one of the devices on the network sends a broadcast packet (such as a DHCP DISCOVER), that packet will be duplicated and forwarded out of every switch port and delivered to every device in the broadcast domain.

Breaking Up Your Broadcast Domains

Consider breaking up your broadcast domains by routing between disparate portions of your network, using subnets to classify different types of users or devices, and/or assigning devices or network segments to specific VLANs.

For example, if you are serving a very, very large office building, assign a subnet to a router on each floor, break that subnet into smaller subnets for each company or group on the floor and use VLAN-aware switches to deliver these subnets where they are needed. Switches which support untagged VLAN ports can make the conversion from a totally flat network much easier since implementing VLANs can usually be accomplished without any changes on the end-device.

Breaking up your broadcast domains not only improves the efficiency of your network, it also allows you to have greater control (read: security) over your network.

Get Guidance From Our Experts

Need more information? Connect with one of our expert architects at OpenLogic by Perforce. 

CONNECT WITH AN EXPERT