[Kea-users] CIDR or range notation in relay lists when using shared-networks?
Klaus Steden
klausfiend at gmail.com
Thu Feb 23 22:23:37 UTC 2023
Correct.
Hypothetical networks "A" and "B" do not share a broadcast domain.
cheers,
Klaus
On Thu, Feb 23, 2023 at 2:57 AM Darren Ankney <darren.ankney at gmail.com>
wrote:
> Hi Klaus,
>
> So to be clear (with a hypothetical example), 192.168.120.16 might
> need to serve distinct network "A" with one or more subnets and
> 192.168.120.17 might need to serve distinct network "B" with other
> subnets. These "distinct" networks do not share the same broadcast
> domain?
>
> On Wed, Feb 22, 2023 at 8:07 PM Klaus Steden <klausfiend at gmail.com> wrote:
> >
> >
> > 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
> >
> > --
> > 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
> --
> 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/20230223/8201546b/attachment.htm>
More information about the Kea-users
mailing list