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

[Klaus Steden]

Hello Simon,

Unfortunately, while my team has argued that this is, in fact, bad network
design ... that fell on deaf ears, so we're stuck with this design for the
foreseeable future, and "having to manually configure something" seems to
me to be a feature, not a bug, in the eyes of management. We got rolled up
into a larger org as the result of a merger, 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". But I digress.

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

And yes, there have been a lot of "interesting times" so far.

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"?>
        ]
      }
    ],
"""

The kea-relay4.json file is just a JSON list of unicast (/32) IPs that are
used to relay DHCP requests (I posted it up-thread a few back), and the
kea-pool4.json file contains only a series of bog-standard scope
definitions like these:

"""
...
{
    "id": <redacted>,
    "option-data": [{"data": "192.168.167.129", "name": "routers"}],
    "pools": [{"pool": "192.168.167.139-192.168.167.254"}],
    "subnet": "192.168.167.128/25"
},
{
    "id": <redacted>,
    "option-data": [{"data": "192.168.164.1", "name": "routers"}],
    "pools": [{"pool": "192.168.164.11-192.168.164.254"}],
    "subnet": "192.168.164.0/24"
},
{
    "id": <redacted>,
    "option-data": [{"data": "192.168.182.1", "name": "routers"}],
    "pools": [{"pool": "192.168.182.11-192.168.183.254"}],
    "subnet": "192.168.182.0/23"
},
...
"""

I'll cop to not entirely understanding all of the nuances of the
shared-networks approach yet -- this is what we were able to make work in
the time we had available to make it work -- but I'm completely on board
with any suggestions or recommendations for improvement.

cheers,
Klaus

On Mon, Feb 27, 2023 at 11:26 AM Simon <dhcp1 at thehobsons.co.uk> wrote:

> Klaus Steden <klausfiend at gmail.com> wrote:
>
> > FWIW, my team had no input into the network design process, we just got
> saddled with a bespoke implementation and have been adapting as we go.
>
> Ah, the joys of inheriting someone else’s “bright idea”.
>
> > This is the basic model:
> >
> > - an instance of Kea behind a single unicast IP handles all DHCP for the
> entire physical site
> > - each switch is configured to use this same unicast IP as its DHCP
> helper address
> > - the site has multiple distinct networks distributed across multiple
> switches via VXLAN
>
> So far, so good.
>
> > - each VXLAN uses a distinct relay address to forward DHCP requests to
> the helper IP
> > - each relay address is in a subnet reserved specifically just for relay
> addresses
>
> At this point I would argue that the network design is broken.
> The expectation is that each relay agent should use a unicast address from
> a subnet in which the served clients reside. If this is done, then
> allocation happens “automagically” as the server will automatically
> associate the relay address with the subnet(s) served (or more accurately,
> the broadcast domain containing those subnets).
> The way they’ve done it, you need to “do something” manually with the
> config in order to associate relay address with client network.
>
> Questions:
> Are distinct IP addresses associated with each client network ? I.e., each
> relay address is used for only one client network, and there is no
> duplication ?
> Is there a pattern to this, e.g. a /27 range used for each client network,
> or are random single addresses used ?
>
> What I’m thinking is that you could define a shared-network containing the
> client subnet(s) and the allowed relay addresses for each of the VLANs.
> That will automatically associate clients to the correct network for
> picking up network specific options (e.g. router address(es)). That’s going
> to be simpler if you can use (e.g.) 192.168.120.16/28 than if you need to
> use multiple /32 subnets in the shared network.
>
> > The driver here is that it's been difficult to maintain the list of
> individual IPs because we're not kept in the loop when a new relay IP gets
> allocated, and the only solid info I can squeeze out of our network team is
> the subnets they've set aside specifically for relay IP addresses.
>
> So not only have you inherited a “poor” network design, but you have a
> network team that doesn’t like to co-operate for the benefit of the
> business. That’s going to be a never ending source of “interesting times”.
>
>
> 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/20230301/d327c0fe/attachment.htm>