KEA expired leases processing and others

Feature requests
1

Dear VyOs Team,

we appreciate the good working kea DHCP server very much - however, one minor detail is basically completely breaks it for us (I can’t think of why others wouldn’t need this tbh):

A host that reboots gets assigned a new IP address after the boot (randomly).

This is due to kea immediately deleting a lease after a host sends DHCPRELEASE due to shutdown.
Most others (even kea by default) reserves a released IP for a short period of time to catch exactly the “reboot” case.

By default, kea holds released leases for 3600 seconds (1 hour), this is defined in the default config even available in vyos: /etc/kea/kea-dhcp4.conf

// Setup reclamation of the expired leases and leases affinity. // Expired leases will be reclaimed every 10 seconds. Every 25 // seconds reclaimed leases, which have expired more than 3600 // seconds ago, will be removed. The limits for leases reclamation // are 100 leases or 250 ms for a single cycle. A warning message // will be logged if there are still expired leases in the // database after 5 consecutive reclamation cycles. // If both "flush-reclaimed-timer-wait-time" and "hold-reclaimed-time" are // not 0, when the client sends a release message the lease is expired // instead of being deleted from the lease storage. "expired-leases-processing": { "reclaim-timer-wait-time": 10, "flush-reclaimed-timer-wait-time": 25, "hold-reclaimed-time": 3600, "max-reclaim-leases": 100, "max-reclaim-time": 250, "unwarned-reclaim-cycles": 5 },

Sadly, the vyos-kea running config contains none of these (sane default) settings.

There are two possible solutions for this:

  1. low-effort: add the defaults that kea proposes to the running config - but: this changes behaviour for all vyos instances when upgrading, may not be desirable?
  2. add config option
    1. a dhcp-server option “set service dhcp-server keep-expired-leases 3600” that adds all these defaults settings with the hold-reclaimed-time being set as specified (or adds none of those if set to 0)
    2. dhcp-server options for each of those variables

In my opinion it makes most sense to go with option 2.1 - it keeps the current behaviour for everyone when upgrading (since default value is 0), but allows for a sysadmin to easily “enable temporary reserving of expired leases”.

I think this is a very straightforward feature to add with lots of practical use case. If accepted, I can go ahead and try to implement/PR it myself (experienced in python and systems, but have never worked on vyos source myself).

Thank you very much!

2

I have made the changes I think are necessary for this. I cannot confirm it though.

Sadly, the build and dev documentation is a riddle to me. I can’t find the part where it says how to build for testing this, and the build process (even the one in docker) does not run fully. Sadly I do not have time to debug this further.

If anyone can help me with this, very welcome:

~/vyos-build$ sudo docker run --rm -it --privileged -v $(pwd):/vyos -w /vyos --sysctl net.ipv6.conf.lo.disable_ipv6=0 vyos/vyos-build:current bash

vyos_bld@a6c1d8a0cafe:/vyos$ VYOS1X_REPO_URL=“``https://github.com/Moehritz/vyos-1x.git”`` sudo ./build-vyos-image generic --architecture amd64 --build-type development

fails due to “arpwatch” not being able to be installed (somewhere):slight_smile:

Setting up arpwatch (2.1a15-8+b1) …
runuser: failed to execute sh: Permission denied
dpkg: error processing package arpwatch (–configure):
installed arpwatch package post-installation script subprocess returned error exit status 1

1 Like
3

It seems to me that these defaults are still used, even if not present in the file?

echo '{"command": "config-get", "service": ["dhcp4"]}' | sudo socat - /run/kea/dhcp4-ctrl-socket | jq

Spits out the current running config of Kea, including everything.
Within it we find:

     "expired-leases-processing": {
        "flush-reclaimed-timer-wait-time": 25,
        "hold-reclaimed-time": 3600,
        "max-reclaim-leases": 100,
        "max-reclaim-time": 250,
        "reclaim-timer-wait-time": 10,
        "unwarned-reclaim-cycles": 5
      },

So while I don’t disagree having the ability to tune these knobs in the CLI would be a useful addition, I don’t think that’s the root cause of your original post. The standard defaults in the config file appear to be compiled in and used.

4

A more vendor neutral setup if you want semi-static IP-assignments is to use Option82.

This way DHCP-snooping/DHCP-relay will pick up where the DHCP-request originates from and the DHCP-server can reply (lease) with the same IP without be dependent on a lease-file or DUID/MAC-address of the requesing client.

This way whatever you connect to lets say SW2 INT5 will always get the same IP to be used.