---
title: "ISC DHCP Logging compared to Kea"
slug: "isc-dhcp-logging-compared-to-kea"
description: "Configure Kea to produce logs similar to ISC DHCP"
updated: 2024-11-11T20:28:32Z
published: 2024-11-11T20:28:32Z
canonical: "kb.isc.org/isc-dhcp-logging-compared-to-kea"
---

> ## Documentation Index
> Fetch the complete documentation index at: https://kb.isc.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Logging in Kea for ISC DHCP Users

Many administrators are familiar with logging in ISC DHCP and have learned to use it for troubleshooting over the past two decades. Kea can have similar logging although it must be setup properly for this to occur.

          Kea 2.5.3 required

          

Some log messages will be missing prior to Kea 2.5.3 as there were a few more log messages added to correct missing information that was available in ISC DHCP. See GitLab issue [2918](https://gitlab.isc.org/isc-projects/kea/-/issues/2918) for details.

### Kea logger setup

The simple `loggers` configuration shown below will provide the necessary messages and details in Kea that were present in ISC DHCP logging.

```
{
    "Dhcp4": {
        "loggers": [
            {
                "name": "kea-dhcp4.packets",
                "severity": "DEBUG",
                "debuglevel": 45,
                "output_options": [
                    {
                        "output": "/tmp/isc-dhcp-like-logging.log",
                        "maxver": 10
                    }
                ]
            },
            {
                "name": "kea-dhcp4.leases",
                "severity": "DEBUG",
                "debuglevel": 50,
                "output_options": [
                    {
                        "output": "/tmp/isc-dhcp-like-logging.log",
                        "maxver": 10
                    }
                ]
            }
        ]
    }
}
```

Adjust the "output" settings to be a file and location of your choosing. You can also send the logs to syslog by changing the "output" to be `syslog`. It is also possible to specify multiple "output" blocks with different destinations. You might consider setting up other logging entries to send other server logs elsewhere as shown below:

```
{
    "Dhcp4": {
        "loggers": [
            {
                "name": "kea-dhcp4",
                "severity": "INFO",
                "output_options": [
                    {
                        "output": "/tmp/dhcp4.log",
                        "maxver": 10
                    }
                ]
            },
            {
                "name": "kea-dhcp4.dhcpsrv",
                "severity": "INFO",
                "output_options": [
                    {
                        "output": "/tmp/dhcp4-dhcpsrv.log",
                        "maxver": 10
                    }
                ]
            },
            {
                "name": "kea-dhcp4.packets",
                "severity": "DEBUG",
                "debuglevel": 45,
                "output_options": [
                    {
                        "output": "/tmp/isc-dhcp-like-logging.log",
                        "maxver": 10
                    }
                ]
            },
            {
                "name": "kea-dhcp4.leases",
                "severity": "DEBUG",
                "debuglevel": 50,
                "output_options": [
                    {
                        "output": "/tmp/isc-dhcp-like-logging.log",
                        "maxver": 10
                    }
                ]
            }
        ]
    }
}
```

### Comparing ISC DHCP logs and Kea logs

A selection of ISC DHCP logs will be shown here followed by their counterparts in Kea. This should adequately illustrate how these logs might be used in troubleshooting client problems obtaining an address. The date, times and other various info have been removed from the beginning of the messages in the interest of space.

          Hostname

          

Note that hostname was included in many ISC DHCP log messages. It is not shown here because the test client used did not provide a hostname. Kea will only display the hostame at higher levels of debug in the packets log or possibly if it was configured to do something with the hostname.

#### Discover

ISC DHCP example message:

```
DHCPDISCOVER from 00:0c:01:02:03:04  via ens256
```

Kea example message:

```
DHCP4_BUFFER_RECEIVED received buffer from 10.1.2.6:67 to 10.1.2.2:67 over interface ens256
DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: DHCPDISCOVER (type 1) received from 10.1.2.6 to 10.1.2.2 on interface ens256
DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: the subnet with ID 1 was selected for client assignments
DHCP4_DISCOVER [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: server is processing DHCPDISCOVER with hint=(no hint)
```

As can be seen, Kea is a bit more verbose than ISC DHCP. However, you can pick out matching details. For example, the line that begins `DHCP4_PACKET_RECEIVED` contains the mac address `[hwtype=1 00:0c:01:02:03:04]` the type of message `DHCPDISCOVER` and the interface on which it arrived `ens256`, which all match the data shown in the ISC DHCP message.

#### Offer

ISC DHCP example message:

```
DHCPOFFER on 10.1.2.100 to 00:0c:01:02:03:04 via ens256
```

Kea example message:

```
DHCP4_LEASE_OFFER [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: lease 10.1.2.100 will be offered
DHCP4_PACKET_SEND [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: trying to send packet DHCPOFFER (type 2) from 10.1.2.2:67 to 10.1.2.6:67 on interface ens256
```

All of the details of the OFFER message can be picked out of `DHCP4_LEASE_OFFER` except the interface and message type which must be picked out of `DHCP4_PACKET_SEND` and so this is relatively straight foward.

#### Request

ISC DHCP example message:

```
DHCPREQUEST for 10.1.2.100 (10.1.2.2) from 00:0c:01:02:03:04  via ens256
```

Kea example message:

```
DHCP4_BUFFER_RECEIVED received buffer from 10.1.2.6:67 to 10.1.2.2:67 over interface ens256
DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: DHCPREQUEST (type 3) received from 10.1.2.6 to 10.1.2.2 on interface ens256
DHCP4_SUBNET_SELECTED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: the subnet with ID 1 was selected for client assignments
DHCP4_REQUEST [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: server is processing DHCPREQUEST with hint=10.1.2.100
```

The details from the REQUEST packet are available (in first found order) as follows: Interface and server in the message `DHCP4_BUFFER_RECEIVED`; MAC address and message type in the message `DHCP4_PACKET_RECEIVED`; The IP address requested in `DHCP4_REQUEST` listed as a hint;

#### Ack

ISC DHCP example message:

```
DHCPACK on 10.1.2.100 to 00:0c:01:02:03:04  via ens256
```

Kea example message:

```
DHCP4_LEASE_ALLOC [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: lease 10.1.2.100 has been allocated for 7200 seconds
DHCP4_PACKET_SEND [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x0: trying to send packet DHCPACK (type 5) from 10.1.2.2:67 to 10.1.2.6:67 on interface ens256
```

The MAC address and leased IP address are found in the first message `DHCP4_LEASE_ALLOC` while the interface must be found in the second message titled `DHCP4_PACKET_SEND`.

#### Nak

ISC DHCP example message:

```
DHCPNAK on 10.1.2.100 to 00:0c:29:9e:4f:41 via ens256
```

Kea example message:

```
DHCP4_PACKET_SEND [hwtype=1 00:0c:29:9e:4f:41], cid=[no info], tid=0x5ced8214: trying to send packet DHCPNAK (type 6) from 10.1.2.2:67 to 10.1.2.100:68 on interface ens256
```

There is only one log entry for a NAK in most cases. All of the needed information is contained in this single log message. This consists of the IP that was requested, the client's MAC address, and the interface.

#### Release

ISC DHCP example message:

```
DHCPRELEASE of 10.1.2.100 from 00:0c:01:02:03:04 via ens256 (found)
```

Kea example message:

```
DHCP4_BUFFER_RECEIVED received buffer from 10.1.2.6:67 to 10.1.2.2:67 over interface ens256
DHCP4_PACKET_RECEIVED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x74: DHCPRELEASE (type 7) received from 10.1.2.6 to 10.1.2.2 on interface ens256
DHCP4_RELEASE [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x74: address 10.1.2.100 was released properly.
DHCP4_RELEASE_EXPIRED [hwtype=1 00:0c:01:02:03:04], cid=[01:00:0c:01:02:03:04], tid=0x74: address 10.1.2.100 expired on release.
```

The details from a RELEASE are found spread throughout the first three messages. The interface is in the first message `DHCP4_BUFFER_RECEIVED`. The MAC address is in the second message `DHCP4_PACKET_RECEIVED` while the IP and success are both in the message titled `DHCP4_RELEASE`.

#### Decline

ISC DHCP example message:

```
DHCPDECLINE of 192.0.2.12 from 00:00:00:11:11:11 (CLIENT1) via 192.0.2.129: found
```

Kea example message:

```
DHCP4_DECLINE_LEASE Received DHCPDECLINE for addr 192.0.2.12 from client [hwtype=1 00:00:00:11:11:11], cid=[01:00:00:00:11:11:11], tid=0x3508dc20. The lease will be unavailable for 86400 seconds.
```

There is only one message associated with DHCPDECLINE typically. This is usually followed immediately by the client sending a DISCOVER in an attempt to obtain a new address.

#### Inform

ISC DHCP example message exchange:

```
DHCPINFORM from 192.0.2.12 via eth0
DHCPACK to 192.0.2.12 (00:00:00:11:11:11) via eth0
```

Kea example message exchange:

```
DHCP4_PACKET_RECEIVED [hwtype=1 00:00:00:11:11:11], cid=[no info], tid=0x5cecf32d: DHCPINFORM (type 8) received from 192.0.2.12 to 255.255.255.255 on interface eth0
DHCP4_PACKET_SEND [hwtype=1 00:00:00:11:11:11], cid=[no info], tid=0x5cecf32d: trying to send packet DHCPACK (type 5) from 192.0.2.254:67 to 192.0.2.12:68 on interface eth0
```

This is typically a two message exchange, where the client sends a DHCPINFORM and Kea responds with a DHCPACK.
