[Kea-users] Adding static /32 routes with Kea run_script hook

[perl-list]

You may want to look into the high availability hook https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=high%20availability#ha-high-availability
 as it can be configured to send lease state changes to some arbitrary listener such that you could make a software program that listens to this stream.  It could then be used to trigger these lease adds and removals based on the current lease status.  Specifically, you'll want to look at Passive Backup: https://kea.readthedocs.io/en/latest/arm/hooks.html?highlight=high%20availability#passive-backup-configuration

This would probably solve several of the problems you mention below.  Your program would no longer be a hook but rather a continuously running daemon of some sort listening to the stream of updates from Kea.  This would allow you to make your own decisions regarding what to do.



----- Original Message -----
> From: "kea-users" <kea-users at lists.isc.org>
> To: "kea-users" <kea-users at lists.isc.org>
> Sent: Monday, April 25, 2022 12:06:59 PM
> Subject: [Kea-users] Adding static /32 routes with Kea run_script hook

> Hi

> I've been playing with the idea of using Kea and the official run_script
> hook to add /32 routes to clients when they get a lease, and remove
> these static routes when the client goes away - through lease expiry,
> release, etc. The actual lease handed out to the client will still be a
> /24, or whatever is large enough to include the gateway address.

> Clients will connect to a router over various interfaces or VLAN
> subinterfaces; their DHCP traffic will be relayed to a Kea server which
> does subnet selection based on the relay GIADDR.
> As there is a relay/GIADDR per router interface, I can then use the
> run_script hook to have Kea communicate to the router over which
> interface a /32 route should be added or removed when a client gets or
> loses a lease.

> I've got this mostly working in a lab, but have hit a few issues.

> 1) In an ideal world I'd like to simply add a route on the initial lease
> assignment for a client, and remove it on, for example, a DHCPDECLINE or
> DHCPRELEASE, ignoring all renews in between; but I haven't been able to
> figure out how to differentiate between a client obtaining a lease
> through DORA vs a client renewing a lease through REQUEST/ACK.
> In both cases lease4_renew is called, and I can get the query type to
> tell if it's a DISCOVER or REQUEST, but I think that adding a route in
> the DISCOVER phase of DORA is too early...which leave me with doing it
> on REQUEST, which I can't distinguish from a REQUEST in the renew cycle.

> 2) Because of the above, I'm using "ip route replace" on every REQUEST
> which will add a route if there isn't one present, and do nothing if
> there is. With a large number of clients, this obviously triggers at a
> pretty high rate...is there a more efficient way to do this? I can
> obviously bump up lease timers, but I'd like to keep them reasonably sane.

> 3) My initial plan was to trigger the above using the lease4_renew hook
> point rather than the leases4_committed hook point, as I can't quite
> figure out when the latter is called, but I'm starting to lean towards
> using leases4_committed. Is there some piece of documentation that I
> missed that explains the differences, as well as what DHCP message types
> can trigger leases4_committed? I also seem to have hit a reproducable
> bug with lease4_renew; testing with dhtest
> (https://github.com/saravana815/dhtest), if I release any lease held
> (dhtest -r -i eth0) and then perform a discovery (dhtest -i eth0), the
> lease4_renew hook point does not get hit, while the leases4_committed
> point does. Subsequent renews hit both.

> 4) Which parameter would be the most correct to obtain the offered
> lease? Assuming I'm using the leases4_committed hook point, I think it
> could be:
> QUERY4_CIADDR - usually populated, but sometimes empty. When empty,
> seems to be client-specific.
> QUERY4_YIADDR - always zero'd - guessing this isn't implemented?
> LEASES4_AT0_ADDRESS - this seems to be reliably populated.

> 5) When it comes to removing routes, I think there are 3 points -
> lease4_expire, lease4_release, and lease4_decline.
> lease4_release - straight forward, just remove the route.
> lease4_decline - as I understand it this should only be hit if Kea hands
> out a lease that another device already has bound?
> lease4_expire - trickier...there's no DHCP packet triggering this, so I
> can't infer which interface on the router the /32 is added via; luckily
> you can "ip route del a.b.c.d/32" without specifying an interface.
> There's a parameter called REMOVE_LEASE in this hook point, which I've
> only ever seen set to false. I gather this has something to do with
> lease reclamation. Would it be correct to remove the route regardless of
> whether this parameter is true or false?

> 6) The last hook point is lease4_recover, which I think I can ignore.

> In summary, the hook points + actions:

> lease4_renew
> do nothing
> lease4_expire
> delete a route
> lease4_recover
> do nothing
> leases4_committed
> if dhcprequest, add/replace a route
> lease4_release
> delete a route
> lease4_decline
> delete a route

> The above is all tested on Debian 11.2, Kea 2.0.2-isc20220227221539. Any
> input or suggestions on a better way to do this would be welcome

> Regards
> Giles

> --
> Giles Filmer <giles at neuos.co.za>
> Neuos (Pty) Ltd
> Phone: +27 82 575 1190
> --
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.

> To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

> Kea-users mailing list
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users