Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 3. Providing DHCP services

The dynamic host configuration protocol (DHCP) is a network protocol that automatically assigns IP information to clients. You can set up Kea to provide a DHCP server in your network.

3.1. The difference between static and dynamic IP addressing
Copier lien

To manage how devices receive their unique network addresses, administrators can select between two primary 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.
  • To 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 the user’s needs, preferences, and the network environment.

3.2. DHCP transaction phases
Copier lien

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

Discovery
The DHCP client sends a message to discover the DHCP server in the network. This message is broadcasted at the network and data link layer.
Offer
The DHCP server receives messages from the client and offers an IP address to the DHCP client. This message is unicast at the data link layer but broadcast at the network layer.
Request
The DHCP client requests the DHCP server for the offered IP address. This message is unicast at the data link layer but broadcast at the network layer.
Acknowledgment
The DHCP server sends an acknowledgment to the DHCP client. This message is unicast at the data link layer but broadcast at the network layer. It is the final message of the DHCP DORA process.

3.3. Overview of using Kea for DHCPv4 and DHCPv6
Copier lien

A key aspect of Kea’s design is that DHCPv4 and DHCPv6 are managed independently. Each protocol has its own configuration file and systemd service, giving you the flexibility to run a DHCPv4 server, a DHCPv6 server, or both to meet your network’s 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

3.4. The Kea lease database
Copier lien

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 the next time Kea updates the files.

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

For example, Kea updates the lease database in the following cases:

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

3.5. Setting up a Kea DHCP server
Copier lien

Kea is a modern, high-performance DHCP server with a modular design. Use a DHCP server to automatically assign IP addresses and other network settings to client devices. This eliminates the error-prone task of manual configuration.

Prerequisites

  • The kea package is installed.
  • You are logged in as the root user.

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"
      }
    ],

    // The network interfaces on which Kea will listen for DHCP traffic.
    "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.

      The settings specified in the example include the following:

      interfaces
      Defines the network interfaces on which Kea listens for DHCP requests. If a subnet is not directly connected to the server, ensure that you list the interface through which the subnet can be reached.
      id
      Defines a unique integer for the subnet. This is required if you define more than one subnet.
      subnet
      Defines the subnet in Classless Inter-Domain Routing (CIDR) format.
      pools
      Defines the IP address ranges from which 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"
      }
    ],

    // The network interfaces on which Kea will listen for DHCP traffic.
    "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. 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>
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 on which IPv4 and IPv6 addresses Kea is listening: 

    # 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

3.6. Configuring loggers in Kea
Copier lien

If you want to customize log settings, such as the severity level, configure loggers in Kea.

By default, Kea writes log messages to:

  • The systemd journal
  • The /var/log/messages files, if the rsyslogd service is running

Prerequisites

  • The kea-dhcp4 and kea-dhcp6 services are configured and running.
  • You are logged in as the root user.

Procedure

  1. If you are configuring an IPv4 network:

    1. Edit the /etc/kea/kea-dhcp4.conf file, and add the loggers configuration to the Dhcp4 parameter. For example: 

      {
  "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. If you are configuring an IPv6 network:

    1. Edit the /etc/kea/kea-dhcp6.conf file, and add the loggers configuration to the Dhcp6 parameter, for example: 

      {
  "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 you have configured to verify that it displays messages of the expected severity.

3.7. Assigning a static address to a host by using DHCP
Copier lien

In Kea, you can use a reservation inside a subnet definition to assign a fixed IP address to a media access control (MAC), a DHCP unique identifier (DUID), or other identifiers.

For example, use this method to always assign the same IP address to a server or network device.

Prerequisites

  • The kea-dhcp4 and kea-dhcp6 services are configured and running.
  • You are logged in as the root user.

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

3.8. Classifying clients in Kea
Copier lien

Kea client classes provide a mechanism for grouping clients based on specific criteria, allowing for granular control over network configuration. You can use this feature to 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 to ensures 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 substring of the DHCPv6 vendor class option.

Prerequisites

  • The kea-dhcp4 and kea-dhcp6 services are configured and running.
  • You are logged in as the root user.

Procedure

  1. If you are configuring an IPv4 network:

    1. Edit the /etc/kea/kea-dhcp4.conf file, and make the following changes:

      1. Add the following 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. Devices that do not match the rule are assigned to the Others client class.

      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 from the corresponding pool.

    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 make the following changes:

      1. Add the following 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. Devices that do not match the rule are assigned to the Others client class.

      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.

    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

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

3.9. Comparison of DHCPv6 to radvd
Copier lien

In an IPv6 network, only router advertisement messages provide information about an IPv6 default gateway. If you want to use DHCPv6 in subnets that require a default gateway setting, you must additionally configure a router advertisement service, such as Router Advertisement Daemon (radvd).

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
 DHCPv6radvd

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

3.10. Configuring the radvd service for IPv6 routers
Copier lien

The router advertisement daemon (radvd) sends router advertisement messages that are required for IPv6 stateless autoconfiguration. This enables users to automatically configure their addresses, settings, routes, and to choose 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 are logged in as the root user.

Procedure

  1. Install the radvd package: 

    # dnf install radvd
    Copy to Clipboard Toggle word wrap

  2. Edit the /etc/radvd.conf file, and add the following configuration: 

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

  prefix 2001:db8:0:1::/64 {
  };
};
    Copy to Clipboard Toggle word wrap

    These settings configure radvd to send router advertisement messages on the enp1s0 device for the 2001:db8:0:1::/64 subnet. The AdvManagedFlag on setting defines that the client should receive the IP address from a DHCP server, and the AdvOtherConfigFlag parameter set to on defines that clients should receive non-address information from the DHCP server as well.

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

  3. Optional: Configure that radvd automatically starts when the system boots: 

    # systemctl enable radvd
    Copy to Clipboard Toggle word wrap

  4. Start the radvd service: 

    # systemctl start radvd
    Copy to Clipboard Toggle word wrap

Verification

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

    # radvdump
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat