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