[Kea-users] CIDR or range notation in relay lists when using shared-networks?
Klaus Steden
klausfiend at gmail.com
Thu Feb 23 01:06:22 UTC 2023
Hello all,
Thanks for the responses, and sorry for the ambiguity in my original
question, so I'll try to clarify. 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.
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
- 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
We're already using the <? include ?> macro to manage the existing (and
growing) list of relay IPs, but what I'm really looking for is to be able
to use CIDR notation or Kea range notation instead of using individual IPs,
e.g., this is what the relays list looks like right now:
"""
["192.168.120.16", "192.168.120.17", "192.168.120.18", "192.168.120.19",
"192.168.120.20", "192.168.120.21", "192.168.120.22", "192.168.120.23",
"192.168.120.232", "192.168.120.233", "192.168.120.234", "192.168.120.235",
"192.168.120.236", "192.168.120.237", "192.168.120.238", "192.168.120.239",
"192.168.120.240", "192.168.120.241", "192.168.120.242", "192.168.120.243",
"192.168.120.244", "192.168.120.245", "192.168.120.246", "192.168.152.18",
"192.168.152.19", "192.168.152.20", "192.168.152.21", "192.168.152.22",
"192.168.152.23", "192.168.152.24", "192.168.152.25", "192.168.152.26",
"192.168.152.27", "192.168.152.28", "192.168.152.29", "192.168.184.18",
"192.168.184.19", "192.168.184.20", "192.168.184.21", "192.168.184.22",
"192.168.184.23", "192.168.216.16", "192.168.216.17", "192.168.216.18",
"192.168.216.19", "192.168.216.20", "192.168.216.21", "192.168.252.16",
"192.168.252.17", "192.168.88.18", "192.168.88.19", "192.168.88.20",
"192.168.88.21", "192.168.88.22", "192.168.88.23", "192.168.88.24",
"192.168.88.25", "192.168.88.26", "192.168.88.27", "192.168.88.28",
"192.168.88.29", "192.168.88.30", "192.168.88.31", "192.168.88.32",
"192.168.88.33", "192.168.88.34", "192.168.88.35", "192.168.88.36",
"192.168.88.37", "192.168.88.38", "192.168.88.39", "192.168.88.40",
"192.168.88.41", "192.168.88.42", "192.168.88.43", "192.168.88.44"]
"""
and what I would love to do instead is write that as this:
"""
["192.168.120.0/24", "192.168.152.0/26", "192.168.184.0/26", "
192.168.216.0/25", "192.168.252.0/25", "192.168.88.0/24"]
"""
or perhaps more accurately as this:
"""
["192.168.120.10-192.168.120.253", "192.168.152.10-192.168.152.62",
"192.168.184.10-192.168.152.62", "192.168.216.10-192.168.216.126",
"192.168.252.10-192.168.252.62", "192.168.88.10-192.168.88.253"]
"""
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 I figured that if I could use address ranges in the relays list instead
of individual IPs then I don't have to update the relays file as frequently
and DHCP is less likely to not offer an IP because the incoming relay
address is currently unknown.
I hope this adds a bit more context to my original question!
thanks,
Klaus
On Wed, Feb 22, 2023 at 6:32 AM Simon <dhcp1 at thehobsons.co.uk> wrote:
> Darren Ankney <darren.ankney at gmail.com> wrote:
>
> > In addition to what Peter said, another option would be to use shared
> > networks and add the subnet for relays along with the subnet of
> > addresses that you wish to allocate to the clients to a shared
> > network. See:
> https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp4-srv.html#shared-networks-in-dhcpv4
> >
> > Example:
> >
> > {
> > "Dhcp4": {
> > "shared-networks": [
> > {
> > "subnet4": [
> > {
> > // relays
> > "subnet": "10.1.0.0/21"
> > },
> > {
> > // client subnet
> > "subnet": "192.0.2.0/24",
> > "pools": [ { "pool": "192.0.2.100 - 192.0.2.199" } ]
> > }
> > ]
> > }
> > ]
> > }
> > }
>
> That won’t work in the sort of situation I think the OP is referring to -
> but I admit it’s not completely clear.
> You can only associate the relays subnet with one client subnet. So once
> you introduce more than one client subnet, it breaks.
>
>
> PM Klaus Steden <klausfiend at gmail.com> wrote:
>
> >> In some of our environments, we deal with DHCP relays, and their
> addresses seem to proliferate faster than we can update our configs, which
> leads to delays with DHCP service.
> >>
> >> However, they have reserved an entire /21 for relay IPs, and ideally, I
> would like to be able to add that entire network as a relay instead of what
> I'm currently doing, which is adding individual IPs when I notice them
> reported in the log.
>
> Can you clarify exactly what’s going on here ?
> Is it that there is a client network with “many” relays on it; or many
> client networks with one or two relays on each, but the relay addresses are
> not part of the client subnet ?
>
> If it’s the latter, then this is a “very poor” network config and not
> compliant with how things are supposed to work.
>
> Some more clarity of the network topology and config would enable a better
> answer.
>
> 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/20230222/53008691/attachment.htm>
More information about the Kea-users
mailing list