Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 4. Providing DHCP services

To automatically assign IP addresses and other network settings to client devices, use the dynamic host configuration protocol (DHCP). You can set up Kea to assign a DHCP server in your network.

To manage how devices receive their unique network addresses, you can select between two methods: static and dynamic IP addressing.

Static IP addressing

When you assign a static IP address to a device, the address does not change over time unless you change it manually. Use static IP addressing if you want to:

  • Ensure network address consistency for servers such as DNS, and authentication servers.
  • Use out-of-band management devices that work independently of other network infrastructure.
Dynamic IP addressing

When you configure a device to use a dynamic IP address, the address can change over time. For this reason, dynamic addresses are typically used for devices that connect to the network occasionally because the IP address can be different after rebooting the host.

Dynamic IP addresses are more flexible, easier to set up, and administer. DHCP is a traditional method of dynamically assigning network configurations to hosts.

Note

There is no strict rule defining when to use static or dynamic IP addresses. It depends on your needs, preferences, and the network environment.

4.2. DHCP transaction phases
Copy link

DHCP works in four phases: Discovery, Offer, Request, Acknowledgment, also called the DORA process. DHCP uses this process to assign IP addresses to clients.

Discovery
The DHCP client sends a message to discover the DHCP server in the network. The client broadcasts this message at the network and data link layer.
Offer
The DHCP server receives the client’s message and offers an IP address to the client. The server unicasts this message at the data link layer and broadcasts it at the network layer.
Request
The DHCP client requests the offered IP address from the DHCP server. The client unicasts this message at the data link layer and broadcasts it at the network layer.
Acknowledgment
The DHCP server sends an acknowledgment to the client. The server unicasts this message at the data link layer and broadcasts it at the network layer. This acknowledgment is the final message in the DHCP DORA process.

4.3. Overview of using Kea for DHCPv4 and DHCPv6
Copy link

To manage both DHCPv4 and DHCPv6 services independently, use Kea. Kea is an open source DHCP server with a modular design. Each protocol has its own configuration file to run a DHCPv4 server, a DHCPv6 server, or both to meet network requirements.

For each protocol, Kea uses a separate configuration file and service:

DHCPv4
  • Configuration file: /etc/kea/kea-dhcp4.conf
  • Systemd service name: kea-dhcp4
DHCPv6
  • Configuration file: /etc/kea/kea-dhcp6.conf
  • Systemd service name: kea-dhcp6

4.4. Overview of the Kea lease database
Copy link

A DHCP lease is the period for which Kea allocates a network address to a client. The lease databases contain information about the allocated leases, such as the IP address assigned to a media access control (MAC) address or the timestamp when the lease expires.

All timestamps in the lease databases are in Coordinated Universal Time (UTC).

Kea supports the following lease backends:

memfile (default)

A text-based file stored on the disk. By default, Kea stores the DHCP leases in the following files:

  • For DHCPv4: /var/lib/kea/kea-leases4.csv

  • For DHCPv6: /var/lib/kea/kea-leases6.csv

    Warning

    Manually updating the files can cause inconsistencies and file corruption. For performance reasons, Kea stores the lease data in memory and does not monitor the lease files during runtime. Manual edits can be overridden by the next time Kea updates the files.

mysql
A MySQL database backend.
pgsql
A PostgreSQL database backend.

Kea updates the lease database in the following cases:

  • On lease updates
  • On graceful shutdown
  • During periodic lease file cleanup (LFC) processes
  • On API requests

4.5. Setting up a Kea DHCP server
Copy link

To avoid errors due to manual DHCP configurations, use the Kea DHCP server for automatically assigning IP addresses and other network settings to client devices.

Prerequisites

  • You have installed the kea package.
  • You have administrative privileges.

Procedure

  1. If you are configuring an IPv4 network:

    1. Edit the /etc/kea/kea-dhcp4.conf file, and use the following configuration: 

      {
  "Dhcp4": {
    // Global settings that apply to all subnets unless overridden.
    "valid-lifetime": 86400,
    "option-data": [
      {
        "name": "domain-name",
	"data": "example.com"
      },
      {
        "name": "domain-name-servers",
	"data": "192.0.2.53"
      }
    ],

    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },

    "subnet4": [
      // A definition of a subnet that is directly connected to the server
      {
        "id": 1,
        "subnet": "192.0.2.0/24",
        "pools": [
          { "pool": "192.0.2.20  - 192.0.2.100" },
          { "pool": "192.0.2.150 - 192.0.2.200" }
        ],
        "option-data": [
          { "name": "routers", "data": "192.0.2.1" }
        ],
      },

      // A definition of a remote subnet served through a DHCP relay
      {
        "id": 2,
        "subnet": "198.51.100.0/24",
        "pools": [
          { "pool": "198.51.100.20 - 198.51.100.100" }
        ],
	// Allowed DHCP relay agents
	"relay": {
          "ip-addresses": [ "198.51.100.5" ]
        },
        "option-data": [
          { "name": "routers", "data": "198.51.100.1" },
	  { "name": "domain-name-servers", "data": "198.51.100.53" }
        ]
      }
    ]
  }
}
      Copy to Clipboard Toggle word wrap

      This example configures Kea to serve two subnets: one directly connected to the server and a remote one that uses a DHCP relay agent.

      interfaces
      Defines the network interfaces on which Kea listens for DHCP requests. If a subnet is not directly connected to the server, list the interfaces to make the subnet accessible through these interfaces.
      id
      Defines a unique integer for the subnet, if you define more than one subnet.
      subnet
      Defines the subnet in Classless Inter-Domain Routing (CIDR) format.
      pools
      Defines the IP address ranges so that Kea can assign addresses to clients.
      option-data
      Defines DHCP options sent to clients, such as the default gateway and DNS servers. Per-subnet option-data settings override global settings.
      relay
      Defines the IP addresses of DHCP relay agents. While this setting is optional for remote subnets, it improves the security to limit forwarded requests to trusted agents. Do not use this parameter for directly-connected subnets.

    2. Verify the syntax of the configuration file: 

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    3. Update the firewalld rules to allow incoming DHCPv4 traffic: 

      # firewall-cmd --permanent --add-service=dhcp
# firewall-cmd --reload
      Copy to Clipboard Toggle word wrap

    4. Enable and start the service: 

      # systemctl enable --now kea-dhcp4
      Copy to Clipboard Toggle word wrap

  2. If you are configuring an IPv6 network:

    1. Edit the /etc/kea/kea-dhcp6.conf file, and use the following configuration: 

      {
  "Dhcp6": {
    // Global settings that apply to all subnets unless overridden.
    "valid-lifetime": 86400,
    "option-data": [
      {
        "name": "domain-name",
	"data": "example.com"
      },
      {
        "name": "dns-servers",
	"data": "2001:db8:0:1::53"
      }
    ],

    "interfaces-config": {
      "interfaces": [ "enp1s0" ]
    },

    "subnet6": [
      // A definition of a subnet that is directly connected to the server
      {
        "id": 1,
        "subnet": "2001:db8:0:1::/64",
        "pools": [
          { "pool": "2001:db8:0:1::1000 - 2001:db8:0:1::2000" },
          { "pool": "2001:db8:0:1::4000 - 2001:db8:0:1::5000" }
        ],
      },

      // A definition of a remote subnet served through a DHCP relay
      {
        "id": 2,
        "subnet": "2001:db8:0:2::/64",
        "pools": [
          { "pool": "2001:db8:0:2::1000 - 2001:db8:0:2::2000" }
        ],
	// Allowed DHCP relay agents
	"relay": {
          "ip-addresses": [ "2001:db8:0:2::5" ]
        },
        "option-data": [
	  { "name": "dns-servers", "data": "2001:db8:0:1::53" }
        ]
      }
    ]
  }
}
      Copy to Clipboard Toggle word wrap

      This example configures Kea to serve two subnets: one directly connected to the server and a remote one that uses a DHCP relay agent.

    2. Verify the syntax of the configuration file: 

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    3. Update the firewalld rules to allow incoming DHCPv6 traffic: 

      # firewall-cmd --permanent --add-service=dhcpv6
# firewall-cmd --reload
      Copy to Clipboard Toggle word wrap

    4. Enable and start the service: 

      # systemctl enable --now kea-dhcp6
      Copy to Clipboard Toggle word wrap

Verification

  1. Configure a network connection with DHCP on a client. For details, see Configuring an Ethernet connection by using nmcli.
  2. Connect the client to the network.

  3. Check if the client received an IP address from the DHCP server: 

    # ip address show <interface>
    Copy to Clipboard Toggle word wrap 
    2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:17:b8:b6 brd ff:ff:ff:ff:ff:ff
    inet 192.0.2.20/24 brd 192.0.2.255 scope global noprefixroute enp1s0
       valid_lft forever preferred_lft forever
    inet6 2001:db8:1::1000/64 scope global noprefixroute
       valid_lft forever preferred_lft forever
    Copy to Clipboard Toggle word wrap

Troubleshooting

  • Check the IPv4 and IPv6 addresses Kea is listening on: 

    # ss -lunp | grep -E ':(67|547)'
    Copy to Clipboard Toggle word wrap

    If Kea does not listen on all interfaces you configured, check the interfaces-config setting in the Kea configuration files.

Next steps

4.6. Configuring loggers in Kea
Copy link

To customize log settings depending on priority, such as the severity level, configure loggers in Kea. By default, Kea writes log messages to the systemd journal and the /var/log/messages files, if the rsyslogd service is running.

Prerequisites

  • You have installed the kea package on the server.
  • You have started the kea-dhcp4 and kea-dhcp6 services.
  • You have administrative privileges.

Procedure

  1. To configure an IPv4 network, edit the /etc/kea/kea-dhcp4.conf file:

    1. Add the loggers configuration to the Dhcp4 parameter: 

      {
  "Dhcp4": {
    ...,
    "loggers":[
      {
        "name":"kea-dhcp4",
        "output-options":[
           {
            "output":"kea-dhcp4.log",
            "maxsize":104857600,
            "maxver":5
           }
        ],
        "severity":"INFO",
      }
    ],
    ...
      Copy to Clipboard Toggle word wrap

      The settings specified in the example are:

      name
      Defines the name of the binary the logger settings apply to.
      output
      Sets the log file name in the /var/lib/kea/ directory.
      maxsize
      Sets the maximum size of the log file before Kea rotates it. The default value is 10240000 bytes.
      maxver
      Sets the maximum number of rotated versions Kea will keep. Note that a maxsize value less than 204800 bytes disables rotation.
      severity
      Specifies the category of messages logged. You can set one of the following values: NONE, FATAL, ERROR, WARN, INFO, and DEBUG. Kea logs only messages of the configured severity and above.

    2. Verify the syntax of the configuration file: 

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    3. Restart the kea-dhcp4 service: 

      # systemctl restart kea-dhcp4
      Copy to Clipboard Toggle word wrap

  2. To configure an IPv6 network, edit the /etc/kea/kea-dhcp6.conf file:

    1. Add the loggers configuration to the Dhcp6 parameter: 

      {
  "Dhcp6": {
    ...,
    "loggers":[
      {
        "name":"kea-dhcp6",
        "output-options":[
           {
            "output":"kea-dhcp6.log",
            "maxsize":104857600,
            "maxver":5
           }
        ],
        "severity":"INFO",
      }
    ],
    ...
      Copy to Clipboard Toggle word wrap

    2. Verify the syntax of the configuration file: 

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    3. Restart the kea-dhcp6 service: 

      # systemctl restart kea-dhcp6
      Copy to Clipboard Toggle word wrap

Verification

  • Monitor the log file to check if it displays messages of the expected severity.

To assign a fixed IP address to a media access control (MAC) address, a DHCP unique identifier (DUID), or other identifiers, use a reservation inside a subnet definition in Kea. For example, use this method to always assign the same IP address to a server or network device.

Prerequisites

  • You have configured the kea-dhcp4 and kea-dhcp6 services.
  • You have administrative privileges.

Procedure

  1. If you are configuring an IPv4 network:

    1. Edit the /etc/kea/kea-dhcp4.conf file, and add a reservation to the subnet4 parameter: 

      {
  "Dhcp4": {
    "subnet4": [
      {
        "subnet": "192.0.2.0/24",
	...,
        "reservations": [
          {
            "hw-address": "52:54:00:72:2f:6e",
            "ip-address": "192.0.2.130"
          }
        ],
	...
      Copy to Clipboard Toggle word wrap

      This example configures Kea to always assign the 192.0.2.130 IP address to the host with the 52:54:00:72:2f:6e MAC address.

      For further examples, see the /usr/share/doc/kea/examples/kea4/reservations.json file provided by the kea-doc package.

    2. Verify the syntax of the configuration file: 

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    3. Restart the kea-dhcp4 service: 

      # systemctl restart kea-dhcp4
      Copy to Clipboard Toggle word wrap

  2. If you are configuring an IPv6 network:

    1. Edit the /etc/kea/kea-dhcp6.conf file, and add a reservation to the subnet6 parameter: 

      {
  "Dhcp6": {
    "subnet6": [
      {
        "subnet": "2001:db8:0:1::/64",
  ...,
        "reservations": [
          {
            "hw-address": "52:54:00:72:2f:6e",
            "ip-address": "2001:db8:0:1::99"
          }
        ];
  ...
      Copy to Clipboard Toggle word wrap

      This example configures Kea to always assign the 2001:db8:0:1::99 IP address to the host with the 52:54:00:72:2f:6e MAC address.

      For further examples, see the /usr/share/doc/kea/examples/kea6/reservations.json file provided by the kea-doc package.

    2. Verify the syntax of the configuration file: 

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    3. Restart the kea-dhcp6 service: 

      # systemctl restart kea-dhcp6
      Copy to Clipboard Toggle word wrap

4.8. Classifying clients in Kea
Copy link

To group clients based on specific criteria and allow for granular control over network configuration, use Kea client classes. You can apply special processing rules or assign different DHCP options to clients.

You can create a client class that assigns Voice over IP (VoIP) devices to a specific IP pool. This is to ensure that VoIP phones get different IP addresses than other devices on the network. For example, in IPv4 networks, you can use a substring expression to test for the first 3 octets of their media access control (MAC) address. In IPv6 networks where the MAC address is not a reliable indicator, you can test for a sub-string of the DHCPv6 vendor class option.

Prerequisites

  • You have configured the kea-dhcp4 and kea-dhcp6 services and are active.
  • You have administrative privileges.

Procedure

  1. To configure an IPv4 network, edit the /etc/kea/kea-dhcp4.conf file

    1. Add client classes to the Dhcp4 parameter: 

      {
  "Dhcp4": {
    ...
    "client-classes": [
      {
          "name": "VoIP-Phones",
          "test": "substring(pkt4.mac, 0, 3) == 0x525400"
      },
      {
          "name": "Others",
          "test": "not member('VoIP-Phones')"
      }
    ],
    ...
      Copy to Clipboard Toggle word wrap

      In this example, devices with a MAC address starting with 52:54:00 match the VoIP-Phones client class. The Others client class includes devices that do not match the rule.

    2. Assign the client classes to your pool definitions: 

      {
  "Dhcp4": {
    "subnet4": [
      {
        "subnet": "192.0.2.0/24",
	"pools": [
          {
            "pool": "192.0.2.20  - 192.0.2.100",
            "client-class": "Others"
          },
          {
            "pool": "192.0.2.150 - 192.0.2.200",
            "client-class": "VoIP-Phones"
          }
        ],
        ...
      Copy to Clipboard Toggle word wrap

      Depending on which client class a host matches, Kea assigns an IP address from the corresponding pool.

    3. Verify the syntax of the configuration file: 

      # kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    4. Restart the kea-dhcp4 service: 

      # systemctl restart kea-dhcp4
      Copy to Clipboard Toggle word wrap

  2. To configure an IPv6 network, edit the /etc/kea/kea-dhcp6.conf file:

    1. Add client classes to the Dhcp6 parameter: 

      {
  "Dhcp6": {
    ...
    "client-classes": [
      {
          "name": "VoIP-Phones",
          "test": "option[16].exists and (substring(option[16].hex, 0, 8) == '00000009')",
      },
      {
          "name": "Others",
          "test": "not member('VoIP-Phones')"
      }
    ],
    ...
      Copy to Clipboard Toggle word wrap

      In this example, devices that send a DHCPv6 vendor class option (option 16) where the hexadecimal value begins with 00000009 match the VoIP-Phones client class. The Others client class includes devices that do not match the rule.

    2. Assign the client classes to your pool definitions: 

      {
  "Dhcp6": {
    "subnet6": [
      {
        "subnet": "2001:db8:0:1::/64",
	"pools": [
          {
            "pool": "2001:db8:0:1::1000 - 2001:db8:0:1::2000",
            "client-class": "Others"
          },
          {
            "pool": "2001:db8:0:1::4000 - 2001:db8:0:1::5000",
            "client-class": "VoIP-Phones"
          }
        ],
        ...
      Copy to Clipboard Toggle word wrap

      Depending on which client class a host matches, Kea assigns an IP from the corresponding pool.

    3. Verify the syntax of the configuration file: 

      # kea-dhcp6 -t /etc/kea/kea-dhcp6.conf
      Copy to Clipboard Toggle word wrap

      If the command returns Syntax check failed, fix the errors shown in the report.

    4. Restart the kea-dhcp6 service: 

      # systemctl restart kea-dhcp6
      Copy to Clipboard Toggle word wrap

Verification

  • Connect clients that match the rules in the client classes and verify that Kea assigned an IP address from the associated pool.

4.9. Comparison of DHCPv6 to radvd
Copy link

To use DHCPv6 in subnets that require a default gateway setting, configure an additional router advertisement service, such as Router Advertisement Daemon (radvd).

In an IPv6 network, only router advertisement messages have information about the IPv6 default gateway. The radvd service uses flags in router advertisement packets to announce the availability of a DHCPv6 server.

The following table compares features of DHCPv6 and radvd:

Expand
FunctionalityDHCPv6radvd

Provides information about the default gateway

no

yes

Guarantees random addresses to protect privacy

yes

no

Sends further network configuration options

yes

no

Maps media access control (MAC) addresses to IPv6 addresses

yes

no

To manage router advertisement messages, configure the router advertisement daemon (radvd) service. This service sends router advertisement messages for IPv6 stateless auto-configuration. You can configure addresses, settings, routes, and select a default router based on these advertisements.

Note

You can only set /64 prefixes in the radvd service. To use other prefixes, use DHCPv6.

Prerequisites

  • You have the administrative privileges.

Procedure

  1. Install the radvd package: 

    # dnf install radvd
    Copy to Clipboard Toggle word wrap

  2. Edit the /etc/radvd.conf file to configure radvd with the following parameters: 

    interface enp1s0
{
  AdvSendAdvert on;
  AdvManagedFlag on;
  AdvOtherConfigFlag on;

  prefix 2001:db8:0:1::/64 {
  };
};
    Copy to Clipboard Toggle word wrap
    • Send router advertisement messages on the enp1s0 interface for the 2001:db8:0:1::/64 subnet.
    • The AdvManagedFlag on flag defines that the client should receive the IP address from a DHCP server.
    • The AdvOtherConfigFlag flag defines that clients should receive non-address information from the DHCP server as well.

  3. Enable radvd to start automatically when the system boots: 

    # systemctl enable --now radvd
    Copy to Clipboard Toggle word wrap

    For details, see radvd.conf(5) man page and /usr/share/doc/radvd/radvd.conf.example file on your system.

Verification

  • Display the content of router advertisement packages and the configured values radvd sends: 

    # radvdump
    Copy to Clipboard Toggle word wrap
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2026 Red HatBack to top