7. How to Install and configure DHCP 2016 – (Part3)

How to Install and configure DHCP 2016 – (Part3)

In this part we are going to talk about configuring high availability for DHCP. There are two ways to accomplish that, the “old way” involving split scopes, and the new way involving what is called DHCP failover and I’ll kind of explain the very subtle difference between the two that aims to solve the same problem, meaning allowing a DHCP server to die, and still be able to hand out addresses to clients that are coming in.
We will also take a look on SuperScope, Multicastscope, DNS Registration and DHCP Name Resolution.
Let’s get started.
Split-Scope
The definition of a highly available configuration for DHCP has evolved somewhat over the years. Back in the old days, we used a configuration called split scopes as the way to create high availability for DHCP, and you should not actually think that this is by any means an intelligent way of implementing DHCP. Split scopes are, very simply, exactly what it would say. It is the splitting of a scope between two different hosts.
One of the biggest issues of the split scope configuration is that you have to really create two different databases, and these two different databases have no knowledge of each other. So, the addresses that exist in Database 1 have no knowledge of the addresses that exist in Database 2. When you bring server (which was offline) back on line, you could end up with some situations where addresses that were leased to one server were perhaps already leased to the other server, and as a result, the addresses that were leased out by Server 2 would have to be re-assimilated back into Server 1 after you brought Server 1 back on line. Furthermore, in order to implement high availability, you had to pay what is essentially a tax of 20% of your addresses for this server to sit and wait for your primary server to go offline. In environments that were relatively limited on the addresses they had, this 20% tax is actually fairly painful, and could require you to move to superscopes earlier than you thought you would need to.
The most common configuration would be the splitting of these two addresses in an 80/20 configuration, meaning that 80% of the addresses would be served by Server 1, 20% of the addresses would be served by Server 2. The reason for this configuration is that the intent of Server 2 is to exist in the case where Server 1 should actually go down for a period of time
Let’s see how we can configure split-score.
Right click on the scope that is to be split and press the advanced menu item and split scope menu item.

DHCP Split-Scope Wizard will pop-up. Click Next

Now we need to determine what the additional DHCP server would be, in my case, will be the DC02. Choose Next

Now we need to identify what we want the percentage, essentially the split between these two servers to be. The best practice for years and years has been 80/20, but you can literally drag this slider to whatever you want, 50/50, or some other configuration. Click Next

On Delay on DHCP Offer, now we have the option to choose whether or not we’re going to have, or implement a delay in the DHCP offer. Now it’s here you can determine whether or not both machines are going to offer an IP address to each client as it comes in, or if you’re going to setup sort of a failover scenario where the second machine will only respond if the first machine doesn’t. In that situation, you would change the DHCP Delay to something on the order of about a second, or 1000 msec. What this means is that if your primary machine is not functioning, and a whole second goes by, well, then the secondary machine will go ahead and offer an address whenever it’s requested. When you finish that, you choose Next, Finish and close.


The scope is now added to the 2nd server, to finish the setup, right click the scope and choose activate

That’s it.
DHCP Failover
Now I told you that one of the curious things about enabling split scopes is that the actual contents of each individual database, they have really no knowledge of each other, and so if you want to set a true failover, the way in which you do that comes back up here under IPv4, and Configure Failover. The process to accomplish this can be done on a per-scope basis, and it’s really kind of similar to how you do the Split Scopes Wizard, except in this case you’re setting up a partner server, which in my case will be DC02.
Right click on IPv4 of primary DHCP and select Configure Failover.

On the welcome page of Configure Failover select Select all (or select your scope which you want to configure for HA) and click Next.

On Specify the partner server… Add the second DHCP server and click Next.

On the Create a new failover relationship page, The Relationship Name is just these two machines, and then I can set a Maximum Client Lead Time, but more importantly I can determine what the Mode (Load Balance / Hot StandBy) should be for the failover relationship that I’m setting up. We already talked a bit about load balancing versus hot standby, but here in our failover relationship, load balance gives us the ability to set aside what percentage of that scope should be serviced by which server. So, in the traditional load balance scenario, it’s 50/50, but I could rebalance those if I want to, if I have one machine that has more resources than the other.

When I convert things over here to hot standby is when I determine which machine is actually going to wait for the demise of the other server, by default, 5% of the addresses that are reserved over for the standby server. I can change that if I want, and then I can determine which machine is actually the active, and which one is the standby server between the two in the partnership relationship.
State Switchover Interval: When you activate this DHCP says, okay, 60 minutes have to pass before we enable ourself to failover/failback, Click Next


Finally click Finish to set up failover between two servers. Make sure the process should be finished successfully.

Close the page and go to see the changes on DHCP management console.

Refresh the DHCP console to see the final result. Now the DHCP servers are ready to work as DHCP load balancing service.

Super-Scope
A DHCP superscope provides you with the ability to essentially take multiple DHCP scopes, and then combine them together to give yourself a broader range of addresses to hand out to incoming clients. Now, superscopes come into play when you have an environment where the subnet mask that you’ve applied to the environment does not give you enough addresses that you need for a particular location. This happens fairly commonly when you have a 24-bit subnet mask, so 255.255.255.0. In a 24-bit subnet mask, you only have 254 available addresses that you can use, and because of that, you might actually find yourself running out of addresses.
Now when that happens, when you find yourself running out of addresses, there are a couple of different approaches that you can use. One common approach is to define your subnets by geographic location, and just keep those locations under that maximum number of addresses.
Keeping those separate actually provides you a pretty easy way of using one DHCP server with multiple different scopes to identify the machines that exist in those physical locations. Now occasionally you come up with a situation where the subnet mask that you have just can’t support the number of machines that you require. You don’t have, in this circumstance, the ability to reduce the subnet mask, so a 23-bit subnet mask, or lower. You want to keep things at that old usual 24-bit subnet mask. Well, in this situation, you have a couple of different approaches that you can use for getting these multiple subnets sort of consolidated together into a single network space. One way is by configuring your router with multiple different addresses so that you have the ability to browse to all these different subnets.
Another alternative to configuring routers with multiple addresses uses a little trick called DHCP relays, and built into a lot of Enterprise routers these days is the ability for the router to be configured with what is called a DHCP relay agent.
So let’s create one.
Right-Click on IPv4 and select New Superscope

Welcome Wizard will pop-up. Click Next
On Superscope name page, type in the name and click next

On Select Scopes page, select scopes and click next and Finish

You’ll notice here that in creating the superscope that the Properties for configuring the scopes themselves are still, those Properties still exist in the individual scope, but these two are now consolidated together into this Superscope object with really not that many properties that are associated. So again, use this for the distribution of addresses, take care of the individual management down here with these two individual scopes by themselves.


Multicast Scope
Now whereas you might find yourself actually creating a superscope from time to time, the creation of a multicast scope is something you might not find yourself doing that often. Multicast by nature is a very traffic intensive activity, and so you might not find yourself doing this simply because your network team might not allow you to route multicasts across the entirety of their network at once.
Right-Click on IPv4 and Select New Multicast scope

Welcome Wizard will pop-up. Click Next
On Multicast Scope name page, give it a name and click next

On IP Address Range page, type in start and end ip.
TTL time to live, or in other words, the number of hops through routers that this address can actually pass through. Click Next

On Add Exclusion page, add IP addresses which you would like to exclude and click next

On Lease Duration page, I will leave it as default

On Activate Multicast scope page, click next and finish


When you are creating these multicast scopes, multicast is a one to many transaction. You lease the content onto the network in one time, and multiple machines pick it up at the same time. This can be used for streaming any kind of content. Out in the real world, the most common use we find these days of multicast has to do with the deployment of operating systems through Windows Deployment Services
DHCP Name Resolution
If you’re in an environment that is all Windows, this is not something you probably kind of worry about. But if you’re in an environment that has non-Windows based computers, it’s actually possible for some of those non-Windows based computers to register in DNS with a name that is already registered to a computer that is running Windows. So, if, in our case, we have my desktop, we’ll have someone running a Linux version tries to register my desktop into DNS for their Linux machine, we want to protect ourselves from the squatting on that name by some non-Windows client.
Turn on DHCP Name Protection
Right-Click on Scope and select Properties

On DNS tab click Configure

Select Enable Name Protection checkbox and click OK

What we’re doing is adding a dynamic host configuration identifier, or DHCID, onto our DHCP server, and we’re adding in a resource record for that identifier over into DNS. That resource record in DNS is going to map names to prevent duplicate registration by allowing DHCP to watch for potential duplicate names, and refuse the registration of a computer with a different address that’s attempting to register a name with the existing record.


DNS Registration
Your Windows-based DHCP server also has the ability to automatically register entries into DNS on behalf of clients either that cannot automatically register by themselves, or for all clients that are coming through DHCP, and the way that you actually accomplish that is a relatively simple configuration up here under the Properties of the scope.
If I take a look here at the DNS tab, this is where I can determine whether or not DNS dynamic updates are going to be made by the DHCP server when that request is made by the DHCP client.

Dynamically update DNS records for DHCP clients that do not request updates …check this box if you have mixed environment with both Windows and Linux machine
Disable dynamic updates for DNS PTR records… be careful with this one, because some aspects of Active Directory, a couple of items in group policy, actually require clients to have reverse records in DNS, so be careful with implementing this, because you might find yourself actually wanting those reverse records in your DNS.
That’s it.
What we covered in this part.

• How to configure Split-Scopes and what is the difference between Split-Scope and DHCP Failover
• How to configure Superscope
• How to configure Mulitcast scope
• How to configure DNS Registration
• How to configure DHCP Name Resolution