Migrating our DHCP Server to Kea
Deutsche Übersetzung weiter unten
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
Migration unseres DHCP Servers auf Kea
Ein DHCP Server ist für die automatische Allokation von IP Adressen an die Clients zuständig. Wie der Name sagt, geschieht das über das Dynamic Host Configuration Protocol. Wenn unser DHCP Server nicht funktioniert, bekommen die Clients im LAN keine IP Adresse und kommen nicht ins Internet. Daher ist die dauerhafte Verfügbarkeit des DHCP Servers essenziell für uns. Das Selfnet WLAN hat einen separaten FreeRADIUS Server, der die Allokation der IPs über DHCP übernimmt. Da jedoch die Access Points ihre IP Adressen über den DHCP Server bekommen ist das WLAN von einem Ausfall des DHCP Servers auch betroffen.
In letzter Zeit hatten wir häufiger mal Probleme mit unserem alten DHCP Server. Bisher haben wir den ISC DHCP Server verwendet, der allgemein hin als Industriestandard gilt. Seit Ende diesen Jahres ist der ISC DHCP Server jedoch End of Life, bekommt also keine Updates oder Support mehr. Firmenkunden können sich verlängerten Support erkaufen, wir als Studentennetzwerk wollen das aber nicht und da der DHCP Server aktuell sowieso in regelmäßigen Abständen ausgefallen ist und neu gestartet werden musste, haben wir die Gelegenheit ergriffen und auf einen neuen DHCP Server migriert. Der Kea DHCP Server wird ebenfalls vom Internet Systems Consortium entwickelt und soll ein vollwertiger Ersatz für den alten DHCP Server sein.
Da wir die Konfiguration des DHCP Servers nicht manuell anpassen möchten, sobald wir ein neues Mitglied an das Netzwerk angeschlossen haben, wird die Konfigurationsdatei alle 15 Minuten automatisch generiert und bei Veränderungen auf den DHCP Server kopiert. Grundlage dafür ist unsere PostgresSQL Datenbank, auf der die Subnetze aller Mitglieder hinterlegt sind. Um die Konfiguration zu generieren, werden in einem Python Skript die betreffenden Daten mit einer SQL Abfrage aus der Datenbank abgerufen und in Python Dictionaries gespeichert. Die alte Konfiguration wurde daraus mithilfe von Jinja-Templates generiert. Da der neue DHCP Server die Konfiguration im JSON Format erwartet, wird die Datenstruktur direkt serialisiert. Ein Subnetz der Kea Konfiguration sieht so aus:
{
"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": []
}
Wir stellen jedem User ein /28 Subnetz zur Verfügung, das Subnetz ist also 16 IP Adressen groß. Dabei ist die erste IP Adresse (hier 100.72.0.16) die Netzwerk Adresse, die letzte ist die Broadcast Adresse (100.72.0.31) und die vorletzte ist die Gateway Adresse zum Switch (hier als Option routers mit 100.72.0.30 angegeben). Es bleiben also 13 Adressen für den User übrig (das ist hier im pool angegeben). Über das MySelfnet Portal hat man die Möglichkeit, Geräten eine öffentliche IPv4 Adresse zuzuweisen und Ports freizuschalten. Dafür muss die IP Adresse des betreffenden Gerätes im lokalen Netz gleich bleiben. Daher können unter reservations MAC-Adressen angegeben werde, die immer die selbe IP bekommen sollen.
Zusätzlich gibt der DHCP Server noch ein paar Informationen an alle Subnetze weiter:
"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",
Die IP Adresse die ein Client erhält ist immer für 24 Stunden gültig max-valid-lifetime, wobei die Clients üblicherweise bereits nach 12 Stunden mit dem DHCP Server kommunizieren (valid-lifetime) um die Laufzeit der Zuweisung zu verlängern. In der Antwort des DHCP Servers wird neben der IP Adresse auch unser DNS und NTP-Server angegeben. Zudem wird mit den letzten drei Optionen ein Netboot Server angegeben, über das jedes Gerät im LAN ein neues Betriebssystem über das Netzwerk installieren kann.
Diese Konfiguration wird für ca. 6800 Subnetze generiert und umfasst ca. 700000 Zeilen. Um hohe Verfügbarkeit sicherzustellen laufen die DHCP Server als High-Availability Paar, sodass ein zweiter Server übernimmt falls der erste ausfällt. Nachdem wir die neue Konfiguration in den letzten Monaten implementiert und in ein paar Wohnheimen getestet haben wurde der DHCP Server am 8.12. in den laufenden Betrieb migriert. Da wir den alten DHCP Server auch redundant betrieben haben, konnten wir erst einen und dann den anderen DHCP Server migrieren, ohne dass es zu größeren Ausfällen kam.
Neben dem DHCP Server stehen aktuell noch zahlreiche weitere Projekte an, für die wir uns über Unterstützung freuen würden: Den Switch-Tausch im Laufe des nächsten Jahres, das Upgrade der WLAN-Gateway, der Ausbau unseres Monitorings, etc. Wenn du Interesse hast, an den Projekten mitzuwirken oder eigene Ideen umzusetzen, komme gerne Montags oder Donnerstags zu unseren Support-Stunden nach Vaihingen in unser Büro. Wir freuen uns immer über Freiwillige, egal ob technisch versiert oder nicht.
Das Selfnet-Team