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 <klausfi...@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.ank...@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 <klausfi...@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 <dh...@thehobsons.co.uk> wrote: >> >> >> >> Darren Ankney <darren.ank...@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 <klausfi...@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@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@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@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@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@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users