[Kea-users] CIDR or range notation in relay lists when using shared-networks?
Klaus Steden
klausfiend at gmail.com
Thu Mar 2 06:44:28 UTC 2023
Hello Darren,
Could you elaborate a bit on what you mean? We are already using the
shared-networks configuration pattern, although in our use case, relay IPs
are scoped to all subnets, not specifically assigned to each subnet
individually. Here's the relevant section of our Kea config file:
"""
"shared-networks": [
{
"name": "iad1",
"relay": {
"ip-addresses": <?include "/etc/kea/kea-relay4.json"?>
},
"subnet4": [
<?include "/etc/kea/kea-pool4.json"?>
]
}
],
"""
and the kea-relay4.json file is just a JSON list of /32 IPs that are used
to forward DHCPREQUEST packets from prospective client machines, and the
kea-pool4.json file looks something like this:
"""
...
{
"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'm hoping that's a bit more informative than what I fear may have involved
a bit of word salad from me.
cheers,
Klaus
On Fri, Feb 24, 2023 at 4:49 AM Darren Ankney <darren.ankney at gmail.com>
wrote:
> Klaus,
>
> If your relays fallin a known CIDR per subnet(s) in a shared network,
> then you can add a "subnet" to the shared network with no pool that is
> just for the relays and dispense with the relays parameter. It
> doesn't even have to be a real subnet. example:
>
> Network "A" is 10.1.2.0/24 and 10.1.3.0/24 and relays will be between
> 192.0.2.1 - 192.0.2.254 even though the relay subnet is actually
> 192.0.0.0/21
>
> You could add a "subnet" in your shared network for Network "A" that
> has 192.0.2.0/24 even though that is not really a subnet configured on
> your network.
>
> That assumes some rhyme or reason to the allocation of relay IP
> addresses by your network people.
>
> On Fri, Feb 24, 2023 at 7:12 AM Klaus Steden <klausfiend at gmail.com> wrote:
> >
> >
> > 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
> >
> > --
> > 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/20230301/cedbc1f7/attachment-0001.htm>
More information about the Kea-users
mailing list