KEA DHCP part 3

This is the study notes of Using the Kea DHCP Server -Session 3 of 6. The DHCP reservation part will be added later on.

DHCP Lease allocation

When DHCP lease request is received, after Kea server successfully granted a lease, the following log is generated.

2020-10-15T20:35:36.137822+00:00 onprem-dhcp-6c98f7f9d9-lxd5d kea-dhcp4: INFO  [kea-dhcp4.leases] DHCP4_LEASE_ALLOC [hwtype=1 10:7d:b9:2f:0d:eb], cid=[no info], tid=0x1: lease 172.17.10.1 has been allocated

This informational message indicates that the server successfully granted a lease in response to client’s DHCPREQUEST message. The lease information will be sent to the client in the DHCPACK message.

The first argument contains the client and the transaction identification information. The second argument contains the allocated IPv4 address. The third argument is the validity lifetime.

The following diagram illustrated the simplified process of Kea lease allocation.

When searching for a new lease, Kea 1.8 iterates over all subnets by subnet-id, previous versions iterated over subnets in config file order. In the example above, lease is not found by client ID, so Kea server gets lease by hardware address.

Client Classification

Kea DHCP can assign on or more client classes to client requests. Depending on the client classes, different DHCP information can be send to the client: DHCP-Options, IP-Addresses, BOOTP-Parameter inside DHCP responses Kea can select from multiple subnets / pools with the help of client classes.

Where do DHCP identifiers come from

Client classes can be build from various DHCP identifier

• information from client host
• information from DHCP relay
• information from DHCP packet path towards the DHCP server

The DHCP identifiers could come from the client host, including hardware address, client-id, vendor-option and hostname. It also could come from DHCP relay agent to add more options. Finally, it could come from DHCP server itself to add DHCP server interface, and DHCP server destination address, etc.

Automatic vendor classing

Kea DHCP automatically assigns a vendor client class if a vendor option (DHCPv4 option 60 or DHCPv6 option 16) is set in the DHCP request.

The content of that option is prepended with VENDOR_CLASS_ and the result is interpreted as a class. For example, modern cable modems send this option with value docsis3.0, so the packet belongs to class VENDOR_CLASS_docsis3.0.

Example subnet selection based on the vendor option

"subnet4": [
    {
        "subnet": "192.168.2.0.24",
        "client-class": "VENDOR_CLASS_fedoraLinux",
        "option-data": [{
            "name": "routers", "data": "192.168.2.1" }],
        "pools" : [{
            "pool": "192.168.2.60 - 192.168.2.220" }]

    },
]

The KNOWN and UNKNOWN classes

Kea automatically assigns classes based on host reservations.

• all clients with a host reservation will be in the KNOWN class
• all client without reservation will be in the UNKNOWN class

For example

{
    "client-classes": [{
        "name": "dependent-class",
        "test": "member('KNOWN')",
        "only-if-required": true
    }]
}

Client classification example

Configuration for dynamic client classing based on the vendor option (Option 60) content

{
    "client-classes": [
        {
            "name": "windows",
            "test": "substring(options[60].hex,0,3) == 'win'",
            "option-data": [{
                "name": "domain-name", "data": "win.example.com" }]
        }
    ]
}

Classification via hooks

Client classification via complex expressions can hurt the DCHP server performance. Alternative: writing a custom hook for client classification.

Debugging client classing

To debug client classing, the quick option is to enable debugging level when start KEA DHCP4.

kea-dhcp4 -d -c /etc/kea/kea-dhcp4.conf

Alternatively, we can enable the special kea-dhcp4.eval or kea-dhcp6.eval debug logger in the KEA configuration file

"Logging": {
    "loggers": [ {
        "name": "kea-dhcp4.eval",
        "output_options": [ {
            "output": "/var/log/kea-dhcp4-eval.log"
        } ],
        "severity": "DEBUG",
        "debuglevel": 55
    }]
}

The debuglevel ranges from 0 (least verbose) to 99 (most verbose). If severity for the logger is not DEBUG, this value is ignored.

DHCP options

DHCP options can be configured in different scopes in the Kea configuration, global, class, subnet, pools, reservations

Global DHCP options

"Dhcp4": {
    "option-data": [{
        "name": "domain-name-servers",
        "code": 6,
        "space": "dhcp4",
        "csv-format": true,
        "data": "192.168.1.1, 192.168.1.2"
    }]
}

Subnet Specific DHCP option

    "subnet4": [ {
        "subnet": "192.168.1.0/24",
        "pools": [ { "pool": "192.168.1.100 - 192.168.1.200" }],
        "option-data": [{
            "name": "routers",
            "data": "192.168.1.1" 
        },
        {
            "name": "domain-name",
            "data": "a.example.com" 
        }]
    }],

Client Class Options

"client-classes": [{
    "name": "My-Server",
    "test": "option[vendor-class-identifier].text == 'My'",
    "option-data": [ {
        "name": "log-servers",
        "data": "192.168.1.30"
    }]
}]

Defining Custom DHCPv4 options

Sometimes it is required to define custom DHCP options that are not part of the DHCP standards.

{
    "Dhcp4": {
        "option-def": [{
            "name": "my-message",
            "code": 234,
            "type": "string",
            "array": false,
            "record-types": "",
            "space": "dhcp4",
            "encapsulate": "" }],
        "option-data": [{
            "name": "my-message",
            "space": "dhcp4",
            "csv-format": true,
            "data": "My customized DHCP message" 
        }]
    }
}

Related Links

• Using KEA DHCP Webinar 01
• Using KEA DHCP Webinar 02
• Using KEA DHCP Webinar 03
• Using KEA DHCP Webinar 04
• Using KEA DHCP Webinar 05

• ← Previous Post
• Next Post →