[Kea-users] CIDR or range notation in relay lists when using shared-networks?
Klaus Steden
klausfiend at gmail.com
Fri Feb 24 12:11:46 UTC 2023
Hi Darren,
Correct, I am currently listing all relay IPs individually. It seems to be
the case that by using the shared-network parameter and defining my DHCP
pools within that context that I only have to include the list of relays
once, and then requests from any of these relay IPs are processed correctly
for every pool.
But ... it's still a static list of relays that requires making updates
that we're not always informed of -- hence the desire to use range or CIDR
prefix notation -- as the only thing that is known for sure is that future
relay IPs will always be found only on specific subnets within our network.
I think I should also mention as additional context that each device is
given a static IP which is unchanged over the lifetime of the hardware;
it's a large data center environment where dynamic address assignments
would wreak havoc, so IPs in the pool are never offered to more than one
MAC address.
cheers,
Klaus
On Thu, Feb 23, 2023 at 2:38 PM Darren Ankney <darren.ankney at gmail.com>
wrote:
> Klaus,
>
> Then my proposed solution will not work (assuming there is only one
> subnet for the relay agent source ip). It seems that you will need to
> list each address anyway since they could be all over the place?
> Hypothetical example:
>
> relay 10.1.2.1 might be a relay source for network "A"
> relay 10.1.2.2 might be a relay source for network "B"
> relay 10.1.2.3 might be a relay source for network "A"
>
> On Thu, Feb 23, 2023 at 5:24 PM Klaus Steden <klausfiend at gmail.com> wrote:
> >
> >
> > 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
> >
> > --
> > 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/20230224/a4b0f1f9/attachment-0001.htm>
More information about the Kea-users
mailing list