Thursday, July 5, 2018

Distributed vs. centralized DHCP

I expect this to be a somewhat controversial topic, but I'm hoping to get some best practice advice on how to make the decision. Currently I have two primary hub & spoke networks under my supervision:

Network 1 - Main HQ houses DC, DHCP and DNS - 6 Remote sites relay DC, DHCP, and DNS traffic back to HQ - Spokes are dark fiber direct to HQ, 1-2 ms latency, will have IPSEC backup but don't yet

Network 2 - Main HQ houses DC, and DNS - 16 Remote sites have local DHCP, but relay DC and DNS traffic to HQ - Spokes are metro-e mesh, 1-2 ms latency, IPSEC backup in place

Both of these models are working fine, but ultimately we intend to converge both networks on a single design template. There's unlikely going to be any change to the Domain Controllers or DNS traffic - the remote sites don't have servers on site for the most part, so that traffic will always go back to the hub.

We're about to bring up a new site in "Network 1" next week, and will likely rebuild the rest of the remote sites in the next 6 months. I'd like to finalize a design now that we can use going forward.

WWRND? (what would /r/networking do?)

Edit: Yes, the remote sites all have internet access directly. DNS has historically been centralized, but we could do something like DNS 1 and 2 are the centralized, and DNS 3 is 8.8.8.8 in the case that a site-to-site link fails. All sites will eventually have an IPSEC tunnel to fall back on if the link goes down though.

Edit2: I should add that the remote DHCP will be on a Palo Alto device. I'm not sure there's any way to cause it to update DNS records though. There's very little love for the idea of sticking a Windows server at the remote sites, so local DNS w/ dynamic updates is probably out of the question.



No comments:

Post a Comment