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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> > 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 <[email protected]> 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 <[email protected]> wrote: >> >> >> >> >> >> Darren Ankney <[email protected]> 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 <[email protected]> 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 >> >> >> [email protected] >> >> >> 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 >> >> > [email protected] >> >> > 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 >> >> [email protected] >> >> 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 >> > [email protected] >> > 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 >> [email protected] >> 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 > [email protected] > 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 [email protected] https://lists.isc.org/mailman/listinfo/kea-users
