09-30-2018 06:32 AM
Everyone knows about the broadcasts issues on the network.
I know Infoblox can handle with huge network masks above /24, like /16 /17....and so on.
I tried to find some best practices guide to use for migration my old huge networks above /24 from Windows Server to Infoblox.
Is there some guide saying is good to use masks like /24 for better network performance due the broadcast into the network?
10-16-2018 12:41 PM
I believe your question is more of a network architecture/design suited one. When it comes to DHCP best practices, you'd want to focus more on High Availability pairings, DHCP Failover peers, making sure existing and/or any legacy DHCP Options will work in the newer environment, will the Infoblox device(s) you purchased or spec'ed for handle your overall LPS (leases per second), etc.
10-23-2018 08:11 AM
Generally speaking, you may have a lot of chatter with DHCP if your lease times are crazy low. Otherwise it's generally not a huge concern. The broadcasts are Layer 2 so those DHCP requests will only be heard by devices in that broadcast domain. Assuming that your DHCP server is on a separate network, you can set up your dhcp relay on your network devices and it essentially becomes unicast (or directed broadcast) to the server(s).
From a basic network architecture perspective, segmentation is good for more reasons than just broadcast chatter. If you can segment, do it. And right-size the networks. If you don't need a /20 then don't segment it that way...
10-24-2018 08:50 AM
Depending on the type of equipment you have in service and the topology you could use iphelpers to isolate the subnets and only relay the DHCP requests.
12-03-2018 11:41 AM
You will encounter issues if you make large DHCP Ranges. Specifically, we use /16 networks for each of the 5 regions on our campus and those networks each have a single DHCP Range per /16 block. Each member of the DHCP failover pair which handles those Ranges takes about 30 minutes to start up. When I opened a ticket with support about this, their recommendation was that we create many much smaller (/24) Ranges for each /16. Just for clarity, I tried a copy of ISC DHCP loading the lease file I extracted from a support bundle and it exhibited the same behavior. Because these particular DHCP servers are dedicated to our wireless networks alone, they don't need to be restarted except on rare occasions so we haven't sliced up the large DHCP Ranges yet. Now that we are careful to restart only 1 member of the failover pair at a time, there is no customer impact.