Background
The Internet Services Consortium is a 501 non-profit (according to Wikipedia) that has developed and maintains both BIND DNS Server and ISC-DHCP-Server. Both of these open-source projects are used all over the world and are deployed on many, many servers. While ISC-DHCP-Server is handy and easy to configure, ISC has developed a new DHCP server called Kea that they say will eventually replace ISC-DHCP-Server. ISC claims Kea is better in nearly every way, so I’m going to give it a shot.
While all of ISC’s software is open-source, like many open-source maintainers they generate revenue by selling professional support for the software that they develop. Check out their support page for more info.
Topology
Pretty basic here. Kea will be installed on my Ubuntu 18.04 server and an IPv4 network is configured. We’ll see if we can use DHCP to get an IP address on my Cisco IOSv 15.6 router. I’m doing a packet capture in the middle which is always helpful for troubleshooting and verification.
Installation
Installation was pretty easy, provided you are ok with downloading a script from the internet and running it on your system. This method has some serious security concerns, so if you’re planning to run it on a production system you’ll want to probably take a more cautious approach. However my environment is entirely in GNS3 on a cloned Ubuntu VM so I can destroy the whole thing when I’m done. Please be careful out there, don’t talk to strangers.
It took me some time to find the official documentation, but as usual it was at readthedocs.io.
Running the ISC-Consortium’s bash script went pretty smooth for me, this process installs the package repository that ISC provides:
$ curl -1sLf \ > 'https://dl.cloudsmith.io/public/isc/kea-1-6/cfg/setup/bash.deb.sh' \ > | sudo bash Executing the setup script for the 'isc/kea-1-6' repository ... OK: Checking for required executable 'curl' ... OK: Checking for required executable 'apt-get' ... OK: Detecting your OS distribution and release using system methods ... ^^^^: OS detected as: ubuntu 18.04 (bionic) FAIL: Checking for apt dependency 'apt-transport-https' ... OK: Updating apt repository metadata cache ... OK: Attempting to install 'apt-transport-https' ... OK: Checking for apt dependency 'gnupg' ... OK: Importing 'isc/kea-1-6' repository GPG key into apt ... OK: Checking if upstream install config is OK ... OK: Installing 'isc/kea-1-6' repository via apt ... OK: Updating apt repository metadata cache ... ^^^^: The repository has been installed successfully - You're ready to rock! $
Once the repository is successfully installed, you can now install the packages:
$apt install isc-kea-dhcp4-server isc-kea-dhcp6-server isc-kea-admin
Configuration
We’ll start with something really simple. I’ll set the range to be from 10.0.0.100 to 10.0.0.200, the default gateway to 10.0.0.1 (the Ubuntu box) and database set to “memfile” which for Kea means written to a csv file. This is pretty much the exact same functionality as ISC-DHCP-Server.
Ubuntu18.04-1
The default configuration file on my Ubuntu 18.04 box was located at /etc/kea/kea-dhcp4.conf. I deleted all the pre-added stuff and replaced with the following basic configuration:
{
# DHCPv4 configuration starts on the next line
"Dhcp4": {
# First we set up global values
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
# Next we set up the interfaces to be used by the server.
"interfaces-config": {
"interfaces": [ "eth0" ]
},
# And we specify the type of lease database
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/kea/dhcp4.leases"
},
# Finally, we list the subnets from which we will be leasing addresses.
"subnet4": [
{
"subnet": "10.0.0.0/24",
"pools": [
{
"pool": "10.0.0.100 - 10.0.0.200"
}],
"option-data":[
{
"name": "routers",
"data": "10.0.0.1"
}]
}
]
}
}
# DHCPv4 configuration ends with the next line
And restart Kea with
$systemctl restart isc-kea-dhcp4-server #and also check status: $systemctl status isc-kea-dhcp4-server
If everything is good, you should see a green dot from systemd telling you Kea is up and running.
In this step it’s really easy to get hung up because of invalid JSON. Make sure you close all your {‘s and [‘s.
If all is well, Kea should be running and ready to hand out DHCP leases.
CiscoIOSv16.6(2)T-1
Configuration of a DHCP client on an IOS router is dead simple. On the interface just issue “ip address dhcp”. The interface section of your show run will look like this:
interface GigabitEthernet0/0 ip address dhcp duplex auto speed auto
Verification
Ubuntu18.04-1
Since we’ve specified in our config that we want to store DHCP leases in /var/lib/kea/dhcp4.leases, my first step is to check to see if there’s a lease in there for the Cisco router.
$cat /var/lib/kea/dhcp4.leases address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context 10.0.0.100,0c:b0:c4:ed:c8:00,00:63:69:73:63:6f:2d:30:63:62:30:2e:63:34:65:64:2e:63:38:30:30:2d:47:69:30:2f:30,4000,1583687165,1,1,1,router,0,
It’s a little hard to read, but it’s there.
CiscoIOSv16.6(2)T-1
On the Cisco device you’ll be looking for a log message like this:
*Mar 7 22:39:47.135: %DHCP-6-ADDRESS_ASSIGN: Interface GigabitEthernet0/0 assigned DHCP address 10.0.0.100, mask 255.255.255.0, hostname
You’ll also want to check IP interfaces for an IP address and issue “show ip interface brief”:
Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 10.0.0.100 YES DHCP up up GigabitEthernet0/1 unassigned YES unset administratively down down GigabitEthernet0/2 unassigned YES unset administratively down down GigabitEthernet0/3 unassigned YES unset administratively down down
You’ll also want to check the packet capture for the standard DHCP set of 4 messages – Discover, Offer, Request, Acknowledge. Wireshark will recognize “bootp” as a filter:
Troubleshooting
The first sign of trouble will be that you’ll see nothing but “Discover” messages coming from the Cisco router, and no response from Kea. At that point, you’ll want to make sure Kea is running:
Then check the syslog file. On Ubuntu 18.04, this is in /var/log/syslog. Make sure to grep for “kea” because the file is usually pretty big, I used “cat /var/log/syslog | grep kea”:
In this particular instance, I had written invalid JSON in the Kea configuration file, so Kea failed to start.
I also had an instance where I was trying using a MySQL server to store leases, and my configuration wasn’t correct. Kea started but simply didn’t respond to DHCP requests. If you’re using SQL, make sure communication is happening between Kea and your SQL server.
Optional – MySQL Server for Leases storage
One of the options that Kea supports is storing lease data in a database. For this you can use a MySQL server (or others). ISC states in their documentation that the SQL database option is really for needs specific to large deployments, so it’s optional of course.
To install MySQL:
$sudo apt update $sudo apt install mysql-server
You can check to make sure it’s running:
$systemctl status mysql
Status should be green:
Then you need to jump into mysql and create a database for Kea to use:
$mysql -u root -p Enter password: mysql>CREATE DATABASE james_kea; Query OK, 1 row affected (0.00 sec) mysql> CREATE USER 'james'@'localhost' IDENTIFIED BY 'james'; Query OK, 0 rows affected (0.01 sec) mysql> GRANT ALL ON james_kea.* TO 'james'@'localhost'; Query OK, 0 rows affected (0.00 sec) mysql> exit Bye $
Then initialize the Kea database with the kea-admin tool:
kea-admin db-init mysql -u james -p james -n james_kea
You’re going to need to change the “lease-database” section of /etc/kea/kea-dhcp4.conf to tell it to store leases in MySQL:
"lease-database": {
# "type": "memfile", #I just commented these out.
# "persist": true,#I just commented these out.
# "name": "/var/lib/kea/dhcp4.leases" #I just commented these out.
"type":"mysql",
"name":"james_kea",
"host":"127.0.0.1",
"user":"james",
"password":"james"
"password":"james"
},
Restart Kea for it to take effect.
As I mentioned before, if Kea can’t communicate with MySQL, it will start but simply not respond to DHCP requests. If you’re in that situation, make sure to check that your SQL and Kea configurations are correct.
You can take a look at the database via the mysql CLI to see if leases are being stored there:
$mysql -u root -p
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| james_kea |
| mysql |
| performance_schema |
| sys |
+--------------------+
5 rows in set (0.00 sec)
mysql> use james_kea
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show tables;
+-------------------------------+
| Tables_in_james_kea |
+-------------------------------+
| dhcp4_audit |
| dhcp4_audit_revision |
| dhcp4_global_parameter |
| dhcp4_global_parameter_server |
####EDITED FOR BREVITY####
| lease4 |
| lease4_stat |
| lease6 |
| lease6_stat |
| lease6_types |
| lease_hwaddr_source |
| lease_state |
| logs |
| modification |
| parameter_data_type |
| schema_version |
+-------------------------------+
mysql> SELECT * FROM lease4;
+-----------+--------+-----------------------------+----------------+---------------------+-----------+----------+----------+----------+-------+--------------+
| address | hwaddr | client_id | valid_lifetime | expire | subnet_id | fqdn_fwd | fqdn_rev | hostname | state | user_context |
+-----------+--------+-----------------------------+----------------+---------------------+-----------+----------+----------+----------+-------+--------------+
| 167772260 |
���� | cisco-0cb0.c4ed.c800-Gi0/0 | 4000 | 2020-03-09 02:16:09 | 1 | 1 | 1 | router | 0 | NULL |
+-----------+--------+-----------------------------+----------------+---------------------+-----------+----------+----------+----------+-------+--------------+
1 row in set (0.00 sec)
mysql>
It shows up better on a terminal with a lot of width, but there is lease data stored for my Cisco router. Success.
Optional – MySQL Server/REST API for Configuration Storage
I was really hoping to get to test this, however I learned this functionality is provided through external libraries, or “hooks” that the ISC team offers through a premium package.
The “Configuration Backend”, as they call it, offers the ability to store configurations for networks, some options, and other stuff in MySQL and not a JSON config file. Changes to these configurations can be made through REST calls to the kea-ctrl-agent which processes and strips away the HTTP headers and forwards the JSON data to Kea. Essentially, you could make configuration changes from a script or program on the fly without having to restart or reconfigure the server. Pretty cool, I can see why they charge for it.
As of this writing in March of 2020, the ISC website says you need a premium support subscription for the premium hooks package.