[Kea-users] from isc dhcp classes -> kea 3.0

[Darren Ankney]

Hello Gregor,

> Hi Darren,
>
> Deciding the reservation model
>
> 9.3.9. Global Reservations in DHCPv4 describes in general our
> setup. Clients generally can roam in our network based on the
> attributed "pool class" to the specific mac address and the
> "accessability" of the specific network.
>
> The following section:
>
> #+begin_quote 9.3.9. Global Reservations in DHCPv4:
> An address assigned via global host reservation must be feasible for the
> subnet the server selects for the client. In other words, the address
> must lie within the subnet; otherwise, it is ignored and the server will
> attempt to dynamically allocate an address. If the selected subnet
> belongs to a shared network, the server checks for feasibility against
> the subnet's siblings, selecting the first in-range subnet. If no such
> subnet exists, the server falls back to dynamically allocating the address.
> #+END_quote

This is generally true, but you are not (as far as I understood)
assigning an address to the clients in the reservation and instead are
selecting a pool for them to use for a dynamic address with the
reservation (by adding the client to one or more classes and using a
class guard on the pools).

>
> with the given example:
>
> #+begin_quote
> "Dhcp4": {
>      # This specifies global reservations.
>      # They will apply to all subnets that
>      # have global reservations enabled.
>
>      "reservations": [
>      {
>         "hw-address": "aa:bb:cc:dd:ee:ff",
>         "hostname": "hw-host-dynamic"
>      },
>      {
>         "hw-address": "01:02:03:04:05:06",
>         "hostname": "hw-host-fixed",
>
>         # Use of IP addresses in global reservations is risky.
>         # If used outside of a matching subnet, such as 192.0.1.0/24,
>         # it will result in a broken configuration being handed
>         # to the client.
>         "ip-address": "192.0.1.77"
>      },
>      {
>         "duid": "01:02:03:04:05",
>         "hostname": "duid-host"
>      },
>      {
>         "circuit-id": "'charter950'",
>         "hostname": "circuit-id-host"
>      },
>      {
>         "client-id": "01:11:22:33:44:55:66",
>         "hostname": "client-id-host"
>      }
>      ],
>      "valid-lifetime": 600,
>      "subnet4": [
>      {
>          "id": 1,
>          "subnet": "10.0.0.0/24",
>          # Specify if the server should look up global reservations.
>          "reservations-global": true,
>          # Specify if the server should look up in-subnet reservations.
>          "reservations-in-subnet": false,
>          # Specify if the server can assume that all reserved addresses
>          # are out-of-pool. It can be ignored because "reservations-in-subnet"
>          # is false.
>          # "reservations-out-of-pool": false,
>          "pools": [ { "pool": "10.0.0.10-10.0.0.100" } ]
>      }
>      ]
> }
> #+end_quote
>
> contradicts (at least at my current understanding) with:
>
> https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#host-reservations-in-dhcpv4
> (9.3. Host Reservations in DHCPv4)
> #+begin_quote
> Making a reservation for a mobile host that may visit multiple subnets
> requires a separate host definition in each subnet that host is expected
> to visit. It is not possible to define multiple host definitions with
> the same hardware address in a single subnet. Multiple host definitions
> with the same hardware address are valid if each is in a different subnet.
> #+end_quote
>
> that wants a reservation at the subnet level.

There are multiple ways to do it.  The advice shown in the example:
"Use of IP addresses in global reservations is risky." Is no longer
correct as explained in the "Note" just above this example:

"Prior to release 2.3.5, the server did not perform feasibility checks
on globally reserved addresses, which allowed the server to be
configured to hand out nonsensical leases for arbitrary address
values. Later versions of Kea perform these checks."

The current stable releases of Kea are 2.6.4 and 3.0.2 both of which
are fully capable of assigning an address globally with the
reservation mechanism.  It is no longer possible for Kea to assign an
address in a subnet that doesn't actually match that address because
of a global assignment.  However, global reservations are ignored by
default (for performance reasons) and must be enabled with
`"reservations-global": true` as noted previously.



>
> Then there is also the part:
> #+begin_quote
>   # Specify if the server should look up global reservations.
>          "reservations-global": true,
>          # Specify if the server should look up in-subnet reservations.
>          "reservations-in-subnet": false,
> #+end_quote
>
>
> where in
> https://kea.readthedocs.io/en/kea-3.0.2/arm/dhcp4-srv.html#fine-tuning-dhcpv4-host-reservation
>
>
> (9.3.8. Fine-Tuning DHCPv4 Host Reservation) it is explained
> that in the setup using resertations-global deactivates the use of
> reservations-in-subnet anyway (so why is it even defined):
>
> #+begin_quote  9.3.8. Fine-Tuning DHCPv4 Host Reservation
> {
>    "Dhcp4": {
>      "reservations-global": true,
>      "reservations-in-subnet": false
>    }
> }
> #+end_quote
>

It is possible to have "reservations-global": true,
"reservations-in-subnet": true, and "reservations-out-of-pool": false,
in the configuration.  At that point, you can define reservations for
clients globally, in the subnet, and in the pool.  However, Kea may
behave strangely if it encounters the multiple reservations for the
same client while traversing these three scopes.  So you do need to
keep that in mind.  This is all about what works best in your
situation.  There are performance concerns here as well, but most
networks won't bump up against the performance limits of Kea.  You can
see performance testing results here: https://reports.kea.isc.org/

>
> Right this mail is already to big, so i will postpone my questions on
> the decision diagram in 9.3.8. Fine-Tuning DHCPv4 Host Reservation.
>
>
> gg

Thank you,
Darren Ankney