[Kea-users] CIDR or range notation in relay lists when using shared-networks?

Fri Mar 3 03:22:14 UTC 2023

Hello Simon,

Thank you for demystifying this.

FWIW we are already using MySQL to store lease and reservation data, and we
built an API to manage leases and reservations years ago that is also
integrated with our config management service, which we use to update the
Kea config (e.g., adding/changing/removing pools), so it's already a pretty
closed loop.

I could modify the API code to include the address of the relay in each
subnet declaration (I did some experiments with this several weeks ago,
when we were initially exploring solutions to the problem, and that worked
fine), but even then, we're still stuck with the same problem -- we don't
know, aren't told, and can't predict what the next relay IP will be, or to
which subnet it will be assigned. What a pisser. :-(

It sounds like I will have to circle back with the network team and hammer
out something better; one bright spot is that they're at least using an
IPAM that has an API, and it *may* be possible to codify some kind of
association between subnets and their relays. Then it becomes less of a
management problem, and more of a programming one.

thanks!
Klaus

On Thu, Mar 2, 2023 at 8:59 AM Simon <dhcp1 at thehobsons.co.uk> wrote:

> Klaus Steden <klausfiend at gmail.com> wrote:
>
> > … so it’s been an uphill battle just to push for basic changes like
> "let's use one DHCP server for multiple subnets instead of standing up a
> separate local DHCP server on each subnet because L3 is not actually that
> complicated".
>
> I guess you can be grateful for the little wins !
>
> > To answer your questions:
> >
> > 1. yes, each distinct subnet has a distinct relay IP that is not reused
> by the other subnets
> > 2. yes, all of the relay IPs are part of a specific subnet (iirc it's a
> /21 or /22), although I don't know if there's a pattern to how relay IPs
> are chosen (sequentially? randomly? stepwise? etc.) from this subnet
>
> OK, so some good news then.
>
> > And yes, there have been a lot of "interesting times" so far.
>
> I bet :-(
>
> > FWIW, this is the relevant section of my Kea4 config file:
> >
> > """
> >     "shared-networks": [
> >       {
> >         "name": "iad1",
> >         "relay": {
> >           "ip-addresses": <?include "/etc/kea/kea-relay4.json"?>
> >         },
> >         "subnet4": [
> >           <?include "/etc/kea/kea-pool4.json"?>
> >         ]
> >       }
> >     ],
> > """
>
> That’s not going to work. That says “all of the subnets, and all of the
> relay addresses, are in one big shared network. As I understand KEA config,
> you need :
> "shared-networks": [
>   {
>     "name": “VLAN57",
>     "subnet4": [
>       {
>         "subnet": “192.168.120.66/32",
>       },
>       {
>         "subnet": "192.0.57.0/24",
>         "pools": [ { "pool":  "192.0.57.100 - 192.0.57.199" } ]
>         "option-data": [
>           {
>             "name": "routers",
>             "data": "192.0.57.1"
>           } ]
>       }
>     ]
>   },
>   {
>     "name": “VLAN123",
>     "subnet4": [
>       {
>         "subnet": “192.168.120.250/32",
>       },
>       {
>         "subnet": "192.0.123.0/24",
>         "pools": [ { "pool":  "192.0.123.100 - 192.0.123.199" } ]
>           {
>             "name": "routers",
>             "data": "192.0.123.1"
>           } ]
>
>       }
>     ]
>   }
>
> ],
>
> Yes, it’s going to be one right p.i.t.a. to manage.
> What that says is that if you receive a relayed packet from the subnet
> 192.168.120.66/32 then treat it as including clients from subnet
> 192.0.57.0/24 as well. Since there is no pool for the 192.168.120.66/32
> subnet, then only addresses from the 192.0.57.0/24 subnet will get
> considered for offering to the client. In the general case you can have
> multiple subnets for clients within the shared network - and the server
> will consider them as all equal in terms of what can be handed out to
> clients.
>
> From memory, I think you mentioned that all devices have static address
> reservations, in which case you’ll need to adapt the subnet declarations,
> so :
>       {
>         "subnet": "192.0.57.0/24",
>         "pools": [ { "pool":  "192.0.57.100 - 192.0.57.199" } ]
>         "option-data": [
>           {
>             "name": "routers",
>             "data": "192.0.57.1"
>           } ]
>       }
>
> becomes :
>       {
>         "subnet": "192.0.57.0/24",
>         "pools": [ { "pool":  "192.0.57.100 - 192.0.57.199" } ]
>         "option-data": [
>           {
>             "name": "routers",
>             "data": "192.0.57.1"
>           } ]
>         "reservations": [
>           {
>             "hw-address": "1a:1b:1c:1d:1e:1f",
>             "ip-address": “192.0.57.17"
>           },
>           {
>           ... more reservations
>           } ]
>        }
> And if there’s no dynamic clients at all, then you could delete the pool
> section altogether. It’s a matter for you and the rest of the business to
> determine if there’s a case for keeping a very small pool (with suitably
> short lease times) - allowing newly added devices to get an address (which
> I suspect you could spot in the logs with suitable filtering) prior to you
> actually being told about it and configuring the correct reservation.
>
>
> By the time you get to this level of complexity, it may be time to
> consider a database backend for config - or store your config elsewhere and
> use scripts to build the KEA config. The latter is quite common with DHCPD
> for large configs.
>
>
> Simon
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20230302/7caf440a/attachment-0001.htm>