Migrating our DHCP Server to Kea
A DHCP Server automatically allocates IP addresses to clients in a network using the Dynamic Host Configuration Protocol. If our DHCP Server fails, the clients in our LAN will not be able to get an IP address and can’t connect to the internet. Therefore our DHCP Server is a crucial part of our infrastructure. While the Selfnet WLAN uses a FreeRADIUS Server to allocate IPs via DHCP, all WiFi Access Points get their IPs from the DHCP Server. So in case of a failure the WiFi is also affected.
In the past months we had quite a few problems with our old DHCP server. Until recently we used the ISC DHCP Server which is considered the industry standard. Since end of this year however ISC DHCP is end of life which means we won’t get any updates or support, unless we pay the developers. Due to this we decided to migrate to a new DHCP server. The Kea DHCP Server is also developed by the Internet Systems Consortium and promises to be a drop-in replacement for ISC DHCP.
Since we don’t want to manually edit the DHCP configuration every time a new member gets access to the network there is a Python script in place which generates the configuration automatically every 15 minutes by querying our PostgreSQL database. The old configuration was then generated using Jinja Templates. Our new scipt stores the configuration in Python data structures which get serialized to JSON which is required by Kea. A single subnet in the new configuration looks like this:
{
"subnet": "100.72.0.16/28",
"option-data": [
{
"name": "routers",
"data": "100.72.0.30"
},
{
"name": "domain-name",
"data": "user.selfnet.de"
}
],
"pools": [
{
"pool": "100.72.0.17 - 100.72.0.29"
}
],
"reservations": []
}Every user gets a /28 subnet which consists of 16 IP addresses. Since the first IP (in this case 100.72.0.16) is the network address, the last IP (100.72.31) is the broadcast IP and the second to last(see option routers) is the Gateway IP to the switch we end up with 13 available IPs per user (this range is specified in the pool field). Additionally users have the option to get a public IPv4 address and forward ports to a device in the local network using MySelfnet. To ensure the device receives external traffic the local IP has to stay the same. This is done through the reservations field by specifying the MAC address of the device.
Additionally a few global options are specified for all subnets:
"valid-lifetime": 43200,
"max-valid-lifetime": 86400,
...
"option-data": [
{
"name": "domain-name-servers",
"data": "141.70.124.5"
},
{
"name": "ntp-servers",
"data": "141.70.124.2"
}
],
"next-server": "141.70.126.60",
"server-hostname": "netboot-1.server.selfnet.de",
"boot-file-name": "/pxelinux.0",The IP address allocated to a client is always valid for 24 hours (max-valid-lifetime) and clients are supposed to renew the allocation after 12 hours (valid-lifetime). Besides the IP itself the response from the DHCP server also contains some additional information such as the IPs of our DNS and NTP-Servers. The last three lines advertise our netboot server which can be used to install a new operating system directly from the network.
This configuration is generated for around 6800 subnets and contains 700000 lines of text. To ensure high availability our DHCP Servers run redundantly as a pair, so if one server fails the other one takes over. After implementing and testing the new DHCP server over the last few months we migrated on December 8th. Since our old DHCP server ran redundantly as well, we were able to migrate one by one which kept downtime to a minimum.
Besides the DHCP migration there are a lot of other projects we’re currently working on. We’re always happy about new volunteers joining us to help with existing projects or to realize new ideas. You’re welcome to join us in our Vaihingen office on Monays and Thursdays during support hours.
The Selfnet-Team