[Kea-users] CIDR or range notation in relay lists when using shared-networks?
Darren Ankney
darren.ankney at gmail.com
Thu Mar 2 11:32:52 UTC 2023
Klaus,
My suggestion only works if there is a pattern to the way the relay
IPs are chosen. Specifically, if they are grouped together such that
they COULD be subnetted, but are not on the switch side. You would be
pretending (on the Kea side) that they are. Then you could add these
subnets as part of the appropriate shared-networks { } statements.
You would not need relay { } statements at all. BUT, it would not
work with randomly chosen IP addresses for the relay agents as some
would almost certainly be too far apart to group together in a
"subnet". Also, if you have little influence on the people choosing
the relay IP addresses, then you couldn't be sure they wouldn't do
something in the future to break your entire plan anyway. In
conclusion, I'd say ignore my suggestion as it won't work in your
situation probably, or if it would be ok to do now, it might not
continue to work in the future.
On Thu, Mar 2, 2023 at 1:45 AM Klaus Steden <klausfiend at gmail.com> wrote:
>
>
> 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
>
> --
> 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
More information about the Kea-users
mailing list