Post

Advanced ISC Kea DHCPv4 Server: Installation, Configuration, Optimization, and Administration

Posted
By Ahmed Aljorani 26 min read

Introduction

Let’s provide a brief overview of DHCP, which stands for the dynamic host configuration protocol. This protocol automatically assigns TCP/IP information to computers. If you’ve worked with computer systems before, chances are you’ve encountered DHCP, where your computer receives an IP address automatically from a DHCP server. DHCP is a widely used protocol within the TCP/IP suite of communication protocols. The key information provided includes the IP address, net mask, gateway address, and DNS server IP address. While there are many more options available within DHCP, these are the primary ones to consider. By default, DHCP utilizes ports 67 and 68. Port 67 is used by the server side, while port 68 is used by the client. The DHCP process follows a four-step sequence called DORA: Discovery, Offering, Request, and Acknowledgment.

Let’s explore each step of this process. When a DHCP client, boots up, it broadcasts a request via port 68 to discover a DHCP server. The server, listening on port 67, responds with an offer of network configuration information. Upon receiving the offer, the client may accept it, officially requesting the provided IP address. If the DHCP server approves the request, it assigns the IP address and sets a lease duration, acknowledging that the IP address can now be utilized by the client. To verify DHCP operation, on a Windows client, you can use “ipconfig /all,” while on Linux, examining the network configuration files provides insight. For Debian-based systems, check /etc/NetworkManager/system-connections, while for CentOS and similar distributions, navigate to /etc/sysconfig/network-scripts.

For deeper understanding, refer to RFC Request for Comments number 2131, which outlines DHCP in detail. Additionally, explore related RFCs for updates and extensions to the protocol. If resources like IANA’s DHCP options list are unavailable, ISC’s documentation provides valuable information. In summary, DHCP dynamically configures TCP/IP settings for computers, facilitating network communication. It operates through a four-step process, employs specific ports, and Complies to RFC standards for consistency.

Installation

DHCPv4 Server Installation

Let’s proceed with the installation of our DHCPv4 Server using ISC’s Kea DHCPv4 server, which we’ll be setting up on our Debian server. The ISC, or Internet Systems Consortium, is the entity behind the development of Kea DHCP software, alongside the older DHCPD and BIND DNS software.

There are several installation methods available. First, there’s the source code installation, suitable for customizing Kea DHCP according to specific requirements. Another option is to selectively download individual files, such as the DHCPv4 and DHCPv6 servers, from cloudsmith. These files can be verified using SHA-256 or SHA-512 codes to ensure integrity post-download.

However, our approach will involve utilizing repositories and packages for installation. This method allows us to install the entire repository securely using apt in Debian or dnf in CentOS, ensuring a secure connection to ISC for package installation. The package listing and installation instructions are available on the ISC website.

1
2

# ISC-Kea uses even point releases for stable versions. And odd point releases for testing versions.
https://kb.isc.org/docs/isc-kea-packages

Let’s walk through the installation steps. The first thing we’re gonna do is install the Kea Repository.

1
2
3

# To install .deb packages, you can quickly setup the repository automatically (recommended):
# We just have to replace x-x with a repository number that we want to install.
curl -1sLf 'https://dl.cloudsmith.io/public/isc/kea-x-x/setup.deb.sh' | sudo -E bash

  • curl: is a command-line tool used to transfer data to or from a server. In this case, it’s being used to download a script from the specified URL.

  • -1sLf: These are options for curl:
    • -1: Tells curl to use TLS version 1.0 or higher for secure communication.
    • -s: Tells curl to operate in silent mode, which means it doesn’t show progress or error messages.
    • -Lf: -L tells curl to follow redirects if the server responds with a redirect status code, and -f tells curl to fail silently (i.e., not produce an error message) in case the server returns an error status code (like 404 Not Found).
  • sudo -E bash: sudo is a command that allows users to run programs with the security privileges of another user (typically the superuser, or root). In this case, it’s used to execute the downloaded script with elevated privileges. -E tells sudo to preserve the environment variables, and bash is the command interpreter that will run the script.
1
2
3
4
5
6

# Install ISC Kea Common utilities
apt install isc-kea-common
# Install ISC Kea DHCP4 server
apt install isc-kea-dhcp4-server
# Check to see if the service is running
systemctl status isc-kea-dhcp4-server

It’s completed and operational. The system is active and functional. However, it’s currently doing anything as we haven’t configured a listening interface or set up a network card to monitor DHCP requests on the network. Unlike older servers like DHCPD, which required manual startup, the Kea server is automatically enabled and started upon installation.

1
2
3
4
5

# You can remove the repository with:
rm /etc/apt/sources.list.d/isc-kea-x-x.list
apt-get clean
rm -rf /var/lib/apt/lists/*
apt-get update

Overview

Overview of the Bult-in DHCPv4 Configuration File

Let’s examine the preconfigured kea-dhcp configuration file we’ve received. We’ll use the command cd /etc/kea to access it. Let’s using the less command on kea-dchp4.conf. Feel free to navigate using Page Down, arrow keys, or the mouse wheel. Most of the content is commented out, serving as an informational guide on file usage. Notably, under the interfaces section, the absence of content within square brackets implies no interface is currently configured for DHCP listening.

1
2
3

// interface name (e.g. "eth0" or specific IPv4 address on that
// interface name (e.g. "eth0/192.0.2.1").
"interfaces": [ ]

To exit, press Q. As a precaution, let’s create a backup of this file using the mv command, renaming it to kea-dhcp4.conf.bak.

Configuration

Sample Configuration Files

First, run ip a to check our network configuration. Look for the name of your network interface under section two. Ignore the loopback interface; focus on number two. Note the name of your network interface card and the IP address previously configured.

Next, navigate to the DHCP configuration file. Change the directory to /etc/kea and press enter. Inside, we’ll add the new configuration file kea-dhcp4.conf.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": ["<interface_name>"]
    },
    "dhcp-socket-type": "<socket_type>",
    "lease-database": {
      "type": "<database_type>",
      "persist": true,
      "lfc-interval": 3600,
      "name": "<database_path>"
    },
    "subnet4": [
      {
        "id": 1,
        "subnet": "<ip_address/subnet mask>",
        "pools": [
          {
            "pool": "<start_ip> - <end_ip>"
          }
        ],
        "option-data": [
          {
            "name": "<routers>",
            "data": "<gateway_ip>"
          },
          {
            "name": "<domain-name-servers>",
            "data": "<dns_server1>, <dns_server2>"
          },
          {
            "name": "<domain-name>",
            "data": "<domain_name>"
          }
        ]
      }
    ],
    "valid-lifetime": 86400,
    "renew-timer": 43200,
    "rebind-timer": 75600,
    "next-server": "<tftp_server_ip>",
    "boot-file-name": "<boot_file_path>",
    "option-data": [
      {
        "name": "<tftp-server-name>",
        "data": "<tftp_server_ip>"
      }
    ]
  }
}

Placeholder Descriptions

  1. Dhcp4:

    • interfaces-config:
      • interfaces: The name of the network interface to listen on (e.g., eth0, ens3).
    • dhcp-socket-type: The type of socket to use (e.g., udp).
    • lease-database:
      • type: The type of database to use (e.g., memfile, SQL, and PostgresQL).
      • persist: Boolean value indicating whether the lease database should persist (e.g., true or false).
      • lfc-interval: Lease file cleanup a service process that removes redundant information from the files used to provide persistent storage for the memfile data base backend (e.g., 3600).
      • name: Path to the lease database file (e.g., /var/lib/kea/dhcp4.leases or .csv).
    • subnet4:
      • id: Unique identifier for the subnet.
      • subnet: The subnet in CIDR notation (e.g., 192.168.1.0/24).
      • pools:
        • pool: The range of IP addresses to allocate (e.g., 192.168.1.10 - 192.168.1.100).
      • option-data:
        • name: Default gateway option (e.g., routers).
        • data: The default gateway IP address (e.g., 192.168.1.1).
        • name: DNS server(s) option (e.g., domain-name-servers).
        • data: The DNS server IP addresses (e.g., 8.8.8.8, 8.8.4.4).
        • name: Domain name option (e.g., domain-name).
        • data: Domain name associated with DHCP clients (e.g., example.com).
    • valid-lifetime: Lease validity duration in seconds (e.g., 3600).
    • renew-timer: Time in seconds before the lease renewal (e.g., 600).
    • rebind-timer: Time in seconds before the lease rebind (e.g., 1800).
    • next-server: The IP address of the TFTP server (e.g., 192.168.1.1).
    • boot-file-name: The path to the network boot file (e.g., /var/lib/tftpboot/pxelinux.0).
    • option-data:
      • name: specifies the TFTP server name.
      • data: The IP address of the TFTP server (e.g., 192.168.1.1).

Notes:

  • For the changes to take effect, you would typically restart the server. To prevent conflicts, stop the service for now. Use systemctl stop isc-kea-dhcp4-server (tab completion can help with the service name). Then, disable the service so it doesn’t start on reboot by using systemctl disable isc-kea-dhcp4-server.
  • in JSON, strings containing letters and numbers must be enclosed in double quotes, and arrays are in square brackets, allowing for multiple values if needed. We’re only working with one interface for now, but additional interfaces can be added by comma-separating them.
  • In this example, the id parameter is set to 1 for the subnet4 block. Ensure that each subnet4 entry has a unique id value if you have multiple subnets configured.
  • DHCP socket type, we have two main options: raw and udp, with raw being the default. If this line item were omitted, it would automatically default to raw. raw is suitable for a single local area network (LAN) that is not segmented and doesn’t have additional IP sub-networks. However, raw can consume a lot of resources because it accepts all traffic and bypasses firewall rules, leading to performance issues if there are many clients. The other option is udp (User Datagram Protocol). udp has a lower performance impact but is intended for relayed traffic. For example, if we have a router, a DHCP server, and clients in different IP sub-networks, the clients need to obtain IP addresses from the DHCP server through the router. This setup requires a DHCP relay agent on the router to allow DHCP packets to flow from the server, through the router, to the client. In this scenario, udp is more suitable than raw.
  • DHCP Lease Values valid-lifetime, renew-timer, and rebind-timer. The valid-lifetime is the total time a client can use an IP address provided by a DHCP server, typically set to 3600 seconds (1 hour). The renew-timer, set to 900 seconds (15 minutes), dictates when the client should attempt to renew the IP address with the DHCP server. The rebind-timer, set to 1800 seconds (30 minutes), is the time after which the client will request an IP address from any available DHCP server if the original server is unreachable. These timers ensure fault tolerance by allowing clients to maintain IP addresses even if the primary DHCP server fails. The maximum lease time you can set is 136 years. Alternatively, you can create an infinite lease by using a dollar sign followed by eight Fs ($FFFFFFFF). One less than this value represents the maximum finite lease time, which equates to 136 years, or approximately 4 billion seconds.
  • we can have multiple IP pools for each subnet and multiple subnets, each with multiple pools. An IP pool, also called an IP range or scope, is defined by its range.

Optimization

DHCP server lease Database

To switch to a PostgreSQL/MySQL database, you’ll need to install and set up the database server and modify the Kea configuration file accordingly:

  1. Install PostgreSQL and create a database and user.

Installation

1
2
3
4
5

apt update
apt install postgresql
systemctl status postgresql
su - postgres
psql

Create a database and user

1
2
3
4

CREATE DATABASE dbName;
CREATE USER dbUser WITH PASSWORD 'dbPassword';
GRANT ALL PRIVILEGES ON DATABASE dbName TO dbUser;
GRANT ALL PRIVILEGES ON SCHEMA public TO dbUser;

Modify the Kea configuration file

1
2
3
4
5
6
7
8
9
10
11
12

{
  "Dhcp4": {
    "lease-database": {
      "type": "postgresql",
      "name": "db-name",
      "user": "db-user",
      "password": "db-password",
      "host": "localhost/ip-address-to-your-db",
      "port": 5432
    }
  }
}

Initialize tables

1

kea-admin db-init pgsql -u db-user -p db-password -n db-name -h localhost -P 5432

Ensure the PostgreSQL service is running by checking its status:

1
2

systemctl status postgresql

Restart the Kea service to apply changes:

1

systemctl restart isc-kea-dhcp4.service

By using a PostgreSQL database, you gain enhanced functionality, security, and administrative control compared to the default memory file. However, database-based configurations typically perform slower than memory file configurations, though performance can be optimized.

Improving database performanceinvolves upgrading virtual or physical hardware, adjusting CPU threads, RAM allocation, and optimizing storage drives from magnetic discs to solid-state or NVME drives. Multi-threading can be enabled in the kea-dhcp configuration file to enhance database efficiency, though this requires careful testing and configuration adjustments.

DHCP server reservations

A reservation occurs when a DHCP server sets aside an IP address and associates it with a specific computer using various identification methods, typically the hardware address or MAC address. In cases where the DHCP pool uses the entire range, like 10.0.2.1-.254, leaving no room for static IPs, reservations become necessary for servers and printers, such as .4, .5, and .6, configured in the reservations object. Another reason for reservations might be a system that starts out as a DHCP client but evolves into a server storing critical data or applications, necessitating a fixed IP address. Reservations are typically done using the MAC address, which is unique to each network interface card. This ensures that even in large networks, each device gets a distinct address. To set up a reservation, you would find this MAC address and assign the desired IP.

Other reservation types include using client ID, which includes a network number and MAC address, and circuit ID for clients using relay agents. A less common method is using a DHCP unique identifier (DUID). Hostnames can also be used, though it’s crucial to ensure they remain unchanged to avoid issues.

After configuring reservations, it’s advisable to check for errors using the Kea DHCP command and restart the service. Issues like duplicate IP addresses or MAC addresses will prevent the DHCP server from running.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

{
  "subnet4": [
    {
      "reservations": [
        {
          "hw-address": "08:00:27:11:22:33",
          "ip-address": "10.0.2.122",
          "hostname": "server1"
        },
        {
          "client-id": "01:aa:bb:cc:dd:ee:ff",
          "ip-address": "10.0.2.123",
          "hostname": "printer1"
        },
        {
          "circuit-id": "'relay456'",
          "ip-address": "10.0.2.248",
          "hostname": "switch1"
        },
        {
          "duid": "00:03:00:01:12:34:56:78:90",
          "ip-address": "10.0.2.125",
          "hostname": "duid-client1"
        }
      ]
    }
  ]
}

DHCP server logging

The first approach, which we’ve used before, is to check the status with systemctl status isc-kea-dhcp4-server. This command confirms that the service is active and running smoothly. We can navigate through the output to find details like lease advertisements and any warnings. For a more comprehensive view since the last server restart, we use journalctl -u isc-kea-dhcp4-server. This command shows everything that has occurred since the last server restart.

To view persistent logs across restarts, you’d typically access syslog or utilize Kea’s built-in logging capabilities. For instance, you can examine syslog by running cat /var/log/syslog or using grep to filter specific entries related to isc-kea. The tail command with options like -n 20 or -f can also help in efficiently managing large log files.

Alternatively, vim /var/log/syslog allows for a detailed review from the system’s inception, albeit navigating through potentially thousands of lines.

Regarding Kea’s native logging functionality, we can configure it in /etc/kea/kea-dhcp4.conf. Here, we define loggers under loggers section, specifying output paths (/var/log/kea/kea-dhcp4.log in our case) and severity levels (e.g., info, warning). This setup keeps DHCP-related logs distinct and manageable, particularly useful for troubleshooting.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

{
  "Dhcp4": {
    "loggers": [
      {
        "name": "kea-dhcp4",
        "output_options": [
          {
            "output": "/var/log/kea/kea-dhcp4.log",
            "pattern": "#d{#Y-#m-#d #H:#M:#S.#q} [#p] #c - #m\n",
            "maxsize": 1000000,
            "maxver": 10,
            "flush": true
          }
        ],
        "severity": "INFO",
        "debuglevel": 99
      }
    ]
  }
}

Explanation of the Logger Configuration

  • loggers: Defines an array of loggers. You can have multiple loggers defined here, each with its own configuration.

    • name: Specifies the name of the logger. This identifier is used within Kea’s logs to distinguish where the log entry originated from.

    • output_options: Configures how logs are outputted.

      • output: Specifies the file path where logs will be written. In this example, logs are directed to /var/log/kea/kea-dhcp4.log.

      • pattern: Defines the format of each log message using placeholders:

        • #d{#Y-#m-#d #H:#M:#S.#q}: Date and time in YYYY-MM-DD HH:MM:SS.milliseconds format.
        • [#p]: Log level (INFO, WARNING, ERROR, etc.).
        • #c: Logger name (kea-dhcp4 in this case).
        • #m: Log message.
        • \n: Newline character.

      • maxsize: Specifies the maximum size in bytes for each log file (1000000 bytes = 1 MB in this example). Once this size is reached, Kea rotates to a new log file.

      • maxver: Defines the maximum number of rotated log files to keep (10 versions in this example). Beyond this number, older log files are overwritten starting from the oldest.

      • flush: Determines whether to flush log entries immediately (true). Flushing ensures that log entries are written to disk promptly, which can be crucial for debugging and real-time monitoring.

  • severity: Sets the severity level of the logs that should be captured. Possible values include INFO, WARNING, ERROR, DEBUG, etc. Only log entries with severity equal to or higher than this setting will be recorded.
  • debuglevel: Level of detail for debug messages (99 in this example).

Notes:

We could substitute # by %. Also, we can create different outputs for each severity level, we need to define multiple loggers with distinct patterns. Here’s an updated configuration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

{
  "Dhcp4": {
    "loggers": [
      {
        "name": "kea-dhcp4-info",
        "output_options": [
          {
            "output": "/var/log/kea/kea-dhcp4-info.log",
            "pattern": "#d{#Y-#m-#d #H:#M:#S.#q} [INFO] #c - #m\n",
            "maxsize": 1000000,
            "maxver": 10,
            "flush": true
          }
        ],
        "severity": "INFO",
        "debuglevel": 99
      },
      {
        "name": "kea-dhcp4-debug",
        "output_options": [
          {
            "output": "/var/log/kea/kea-dhcp4-debug.log",
            "pattern": "#d{#Y-#m-#d #H:#M:#S.#q} [DEBUG] #c - #m\n",
            "maxsize": 1000000,
            "maxver": 10,
            "flush": true
          }
        ],
        "severity": "DEBUG",
        "debuglevel": 99
      },
      {
        "name": "kea-dhcp4-warning",
        "output_options": [
          {
            "output": "/var/log/kea/kea-dhcp4-warning.log",
            "pattern": "#d{#Y-#m-#d #H:#M:#S.#q} [WARNING] #c - #m\n",
            "maxsize": 1000000,
            "maxver": 10,
            "flush": true
          }
        ],
        "severity": "WARNING",
        "debuglevel": 99
      },
      {
        "name": "kea-dhcp4-error",
        "output_options": [
          {
            "output": "/var/log/kea/kea-dhcp4-error.log",
            "pattern": "#d{#Y-#m-#d #H:#M:#S.#q} [ERROR] #c - #m\n",
            "maxsize": 1000000,
            "maxver": 10,
            "flush": true
          }
        ],
        "severity": "ERROR",
        "debuglevel": 99
      }
    ]
  }
}

DHCP relay agents

%%{init: {"flowchart": {"defaultRenderer": "dagre"}} }%%
flowchart TB
    subgraph NETWORK
        R1[ROUTER
        Relay Agent
        ]
        subgraph ISC-KEA
            D1[fa:fa-database DHCP Server
            ip: 192.168.0.2
            ]
        end
        subgraph S-A[subnet: 192.168.10.0/24]
            client-B[fa:fa-desktop Client
            ip: 192.168.10.10
            ]
        end
        D1 --> R1
        R1 --> S-A
    end

DHCP relay agents in the context of a network with multiple subnets connected through a router. Normally, subnets are isolated, but a relay agent allows DHCP messages to traverse between them. This is crucial for enabling clients in different subnets to obtain IP addresses from a central DHCP server. The router acts as a relay agent, forwarding DHCP requests from clients to the DHCP server and relaying back the server’s responses. Configuration involves specifying which subnets each relay agent interface serves, ensuring DHCP server settings align with these configurations. For instance, clients in subnet 192.168.10.0/24 wanting DHCP services must communicate through the router, which relays their requests to the DHCP server. Each subnet requires its own DHCP configuration on the server to allocate appropriate IP addresses.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

{
  "Dhcp4": {
    "interfaces-config": {
      "interfaces": ["eth0"],
      "dhcp-socket-type": "udp"
    },
    "subnet4": [
      {
        "id": 1,
        "subnet": "192.168.10.0/24",
        "pools": [{ "pool": "192.168.10.10 - 192.168.10.50" }],
        "relay": {
          "ip-addresses": ["192.168.0.10"]
        }
      }
    ]
  }
}

Ensure the DHCP server is configured to use UDP instead of RA (Raw Access).

Let’s consider a scenario where there is one Cable Modem Termination System (CMTS) with a single CM MAC address (a physical link for modems). The goal is for modems to receive addresses from the 10.1.1.0/24 subnet, while devices connected behind the modems should receive addresses from the 192.0.2.0/24 subnet. The CMTS, functioning as a relay, uses the address 10.1.1.1. The following configuration can accommodate this setup:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

"Dhcp4": {
    "subnet4": [
        {
            "id": 1,
            "subnet": "10.1.1.0/24",
            "pools":  [ { "pool": "10.1.1.2 - 10.1.1.20" } ],
            "client-class": "docsis3.0",
            "relay": {
                "ip-addresses": [ "10.1.1.1" ]
            }
        },
        {
            "id": 2,
            "subnet": "192.0.2.0/24",
            "pools": [ { "pool": "192.0.2.10 - 192.0.2.20" } ],
            "relay": {
                "ip-addresses": [ "10.1.1.1" ]
            }
        }
    ]
}

DOCSIS 3.0 is the next generation of DOCSIS (Data Over Cable Services Interface Specification)

DHCP server high availability

%%{init: {"flowchart": {"defaultRenderer": "dagre"}} }%%

flowchart TB
    subgraph NETWORK
        subgraph DHCP Server
            D1[fa:fa-database Server1
            Primary
            ip: 192.168.0.2
            ]
            D2[fa:fa-database Server2
            Secondary
            ip: 192.168.0.3
            ]
            D3[fa:fa-database Server3
            Backup
            ip: 192.168.0.4
            ]
        end
    end

Ensuring DHCP availability, For small businesses or individual learners, high availability might not be a priority. However, for mid-sized to large organizations, it’s crucial to implement fault tolerance to prevent service disruptions in case the primary DHCP server fails. Therefore, setting up both a primary DHCP server (192.168.0.2) and a secondary DHCP server (192.168.0.3) in a high availability configuration is essential. There are various modes of high availability, with load balancing and hot standby being the most common. In load balancing mode, DHCP requests are evenly distributed between multiple servers. For instance, if there are 1000 DHCP exchanges per second, each server would handle 500 exchanges per second, alternating between primary and secondary servers for each new client request.

On the other hand, hot standby mode designates one server as the active DHCP server while the other remains on standby. If the active server fails, the standby server automatically takes over DHCP operations, ensuring continuity without interruption. Additionally, a backup DHCP server (192.168.0.4) maintains lease information from the primary and secondary servers. While not part of the high availability cluster, it serves as a fallback option in case both primary and secondary servers fail, requiring manual activation.

Implementing high availability involves configuring each DHCP server with identical settings and ensuring the DHCP configuration file is replicated across all servers. This ensures seamless failover and load distribution. It’s also advisable to install necessary hooks for high availability features, which might involve downloading and configuring additional libraries. For optimal redundancy, consider distributing DHCP servers across different physical servers or virtual machines. This prevents a single point of failure and enhances the overall reliability of DHCP services. Whether running in virtual machines or containers, spread them across separate physical platforms to mitigate risks associated with hardware failures.

By adopting these practices, organizations can achieve robust DHCP service continuity, even in the face of unexpected server failures or disruptions. Always validate configurations and monitor system health regularly to maintain reliable DHCP service delivery.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70

{
  "Dhcp4": {
    "hooks-libraries": [
      {
        "library": "/usr/lib/kea/hooks/libdhcp_lease_cmds.so",
        "parameters": {}
      },
      {
        "library": "/usr/lib/kea/hooks/libdhcp_ha.so",
        "parameters": {
          "high-availability": [
            {
              "this-server-name": "server1",
              "mode": "load-balancing",
              "heartbeat-delay": 10000,
              "max-response-delay": 60000,
              "max-ack-delay": 5000,
              "max-unacked-clients": 5,
              "peers": [
                {
                  "name": "server1",
                  "url": "http://192.168.0.2:8000/",
                  "role": "primary",
                  "auto-failover": true
                },
                {
                  "name": "server2",
                  "url": "http://192.168.0.3:8000/",
                  "role": "secondary",
                  "auto-failover": true
                },
                {
                  "name": "server3",
                  "url": "http://192.168.0.4:8000/",
                  "role": "backup",
                  "auto-failover": false
                }
              ]
            }
          ]
        }
      }
    ],
    "subnet4": [
      {
        "id": 1,
        "subnet": "192.168.0.0/16",
        "pools": [
          {
            "pool": "192.168.1.1-192.168.10.254",
            "client-class": "HA_server1"
          },
          {
            "pool": "192.168.11.1-192.168.20.254",
            "client-class": "HA_server2"
          }
        ],
        "option-data": [
          {
            "name": "router",
            "data": "192.168.0.1"
          }
        ],
        "relay": {
          "ip-address": "192.168.0.10"
        }
      }
    ]
  }
}

Administration

How do you know if you have a DHCP address?

On a Windows client, identifying network details is straightforward using ipconfig /all. However, on Linux clients, it can be more challenging. For instance, when running an ip a, we may see the address but lack clarity on its nature. Although indicators like ‘dynamic’ can provide some insight, not all tools, like nmcli, offer explicit information. In such cases, consulting the configuration file is advisable. By accessing the networking configuration file, typically located at /etc/NetworkManager/system-connections for systems with NetworkManager, or /etc/sysconfig/network-scripts for CentOS, Fedora, or Red Hat, we can get valuable information. For instance, observing auto or automatic for the IPv4 address signifies DHCP assignment, while boot protocol DHCP in the configuration file confirms DHCP usage.

Linux command ss

The ss command is provided by the iproute2 package. You can install it using:

1

sudo apt install iproute2

Linux command ss, it stands for “socket statistics.” This command is used to display detailed information about network sockets on a system, including TCP, UDP, RAW, and Unix domain sockets. It provides various options to filter and customize the output for network analysis and troubleshooting purposes.

The ss command in Linux is a tool used to investigate sockets. When used with the -tulnw flags, it’s typically employed to display TCP sockets. Here’s a breakdown of each flag:

  • -t: Show TCP sockets.
  • -u: Show UDP sockets.
  • -l: Show only listening sockets.
  • -n: Show numerical addresses instead of resolving hosts.
  • -w: Show raw sockets.

So, when you use ss -tulnw, it displays information about all TCP and UDP sockets that are listening, along with their numerical addresses (instead of domain names) and any raw sockets. This command is useful for network troubleshooting, monitoring, and analysis.

Benchmarking the DHCP Server

Now it’s time to evaluate the performance of our DHCP servers. We want to determine the throughput in terms of DHCP exchanges per second each server can sustain before performance degradation occurs. To conduct these benchmarks, you’ll need a separate system equipped with benchmarking software capable of testing these servers.

Install the required packages:

1

apt install isc-kea-common isc-kea-admin

perfdhcp is included in the isc-kea-admin package, which provides administrative tools for ISC Kea DHCP server.

1
2

perfdhcp --version
perfdhcp <server_ip_address>

We’ll initiate the benchmarking utility perfdhcp against the DHCP server’s IP address. This tool provides a basic scenario that stabilizes over a minute. Checking the server’s performance using top, we observe that kea-dhcp4is utilizing significant CPU resources during the benchmark. This load intensifies the server’s operation, stressing it with DHCP exchanges per second.

It’s important to note that initial connections involve a full four-step process Discovery-Offering (DO) and Request-Acknowledgment (RA), whereas lease renewals only require Request-Acknowledgment (RA).

After about a minute, We halt the benchmarking process on the client with Ctrl + C to review the results. When tested the DHCP server utilizing a Postgres database, which typically exhibits slower performance than a memfile setup. The perfdhcp is an effective tool for benchmarking kea and dhcpd servers, providing insights into their performance under load. For optimal results, tailor hardware and software configurations to your specific needs and infrastructure constraints.

Additional Parameters can be used with perfdhcp:

  • -r <rate>: Specifies the rate of DHCP exchanges per second. For example, perfdhcp -r 1000 <server_ip_address> will benchmark the server at a rate of 1000 exchanges per second.

  • -l <lease_time>: Sets the lease time for DHCP leases used in benchmarking. Default is 3600 seconds (1 hour).

  • -s <seconds>: Specifies the duration (in seconds) to run the benchmark. By default, it runs indefinitely until interrupted with Ctrl + C.

Verify the configuration files

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# Verify the configuration file
kea-dhcp4 -t /etc/kea/kea-dhcp4.conf

# Verify the server has been configured correctly
systemctl status isc-kea-dhcp4-server

# We can also use
journalctl -u isc-kea-dhcp4-server

# Verify locally opened ports
# Ensure port 67 for DHCP and port 22 for SSH are open and listening. This confirms your DHCP Server is operational.
ss -tulnw

# Verify lease file on the server
cat /var/lib/kea/<lease-file-name>

# Verify lease file on the client
cat /var/lib/dhcp/dhclient.leases

References

Read More

Linux, Networking
dhcp
This post is licensed under CC BY 4.0 by the author.