Monday, 3 August 2015

DHCP Failover in Server 2012 R2 (Part 1)

In this article, we’ll take a look at the new DHCP features that are available in Server 2012 R2. 

Introduction

Although DHCP has been around since I can remember, there has always been limited communication between DHCP servers, in fact, mostly none. If you were going to have two DHCP servers serving the same subnet, you would have had to configure the same scope on both and each server would need to exclude the range of the other server so that they wouldn't give out the same IPs and cause IP conflicts. This is the classic 80/20 scopes that you would have read about from pretty much when DHCP was released. It does require some planning because you would need to ensure that should a single server fail, you are able to get the other server up and running before you run out of available leases. DHCP failover sorts this out.

The other option you would use would be DHCP running on a windows failover cluster. This provides high availability for the DHCP role but isn't commonly used. 

Anyways, when Server 2012 was released, Microsoft introduced DHCP failover.

Overview

DHCP failover allows two Server 2012 or later DHCP servers to replicate lease information between them. This means that both servers are able to lease IPs to the entire scope without causing IP conflicts. In reality, each server manages its own clients but in the event of a DHCP server failure the other server can take over management of its clients but more on this later.

Each DHCP server has a failover relationship with another DHCP server. You can have one DHCP server have a failover relationships with many servers but each relationship can only include two servers.

Each DHCP scope is then associated with a failover relationship and this means that each of those DHCP servers in the failover relationship provide IPs for this scope.

Limitations and requirements

As with all things, there are limitations but I don’t expect these to be very restrictive. See below:

Each DHCP server can only have a maximum of 31 failover relationships as in, if you wanted, you could have a single DHCP server with a relationship with 31 other DHCP servers. I suppose if you hit this limit, you just need to deploy the DHCP role a few more times and with remote PowerShell now enabled by default, this makes life much easier but more on that another time.

Each DHCP failover relationship can only include 2 DHCP servers. This means that you can only have N+1 for your failover scopes if using DHCP failover alone. There are ways around this – a clustered DHCP server is counted as a single DHCP server so if you really wanted, you could have a failover relationship between these two clusters.

IPv6 is not supported for DHCP failover.

Requires TCP port 647 open in the firewall for both servers in the DHCP failover relationship. The firewall rules are: Microsoft-Windows-DHCP-Failover-TCP-In, Microsoft-Windows-DHCP-Failover-TCP-Out.

If using DHCP servers in different sites or subnets, ensure that the clients can reach both servers. You will need two IP helpers configured on your switches or two DHCP relays configured if using Windows server.

AD is not required. The DHCP servers authenticate each other using shared secrets.

How does it work?

There are two modes – load balance mode and hot standby. Load balance is the default however it’s sometimes a good idea to choose hot standby such as when you have the active server in a small branch office and have a standby server in a more central location.

Load Balance Mode:

·         Maximum Client Lead Time: When a new client requests a lease, one of the DHCP servers provides a lease with a length equal to what is configured for the Maximum Client Lead Time (MCTL). This is 1hr by default. As you know, the client renews its lease at 50% of the lease so this will be 30mins later by default. At this time, it will get a lease equal to what is configured on the scope

·         Load balancing: The two DHCP servers compute hashes of the client MAC addresses and distribute the clients between them so that the DHCP servers only respond to the MAC addresses of their clients or what is known as that DHCP server’s MAC address hash bucket. The default is for each DHCP server to manage 50% of the load.

·         Failure of the partner server (state switching): the remaining server will go into a state called COMMUNICATIONS INTERRUPTED which is a state before it has confirmed that its partner is down. Here the administrator needs to confirm the partner is down and put the remaining server into PARTNER DOWN state (manual failover). If you want the server to enter this state automatically then you need to configure the state switchover interval which is a default of 1hr. Once in PARTNER DOWN state, the server will respond to all MAC addresses.

·         Failure of the partner server (temporary fix): These steps take place if MCTL has not yet expired. If it is a client with a MAC address from its partner’s MAC hash bucket renews or requests a lease, it’ll provide a temporary lease for the time specified by the MCTL setting which is 1hr by default. If it gets a request from a new client then it’ll provide a full lease from its pool. This temporary fix is only for the duration of the MCTL.

·         Failure of the partner server (longer term fix): When the MCTL expires and the partner server is still not up then it’s likely that it won’t come up any time soon. In this case, the remaining server takes over management of the entire IP range

Hot Standby Mode:

·         Standby server: This server is for standby only in that it won’t respond to any client requests but it does however hold 5% of the leases.

·         Maximum Client Lead Time: As with the load balance mode, the active server will provide an initial lease time equal to the MCTL.

·         Failure of the partner server (state switching): This is the same as for the load balance mode – the server will enter a COMMUNICATIONS INTERRUPTED state before either being manually put into PARTNER DOWN state or waiting for the state switchover interval before automatically entering the PARTNER DOWN state.

·         Failure of the partner server (temporary fix): This is when the MCTL hasn’t yet expired. The standby server can respond to new leases and provides leases of the length of the MCTL but can only provide leases from the 5% of scope IPs that it had reserved. Once depleted, it no longer provides leases.

·         Failure of the partner server (longer term fix): After the MCTL expires, the standby server can then take ownership of the entire scope and provides new leases or renews leases for any IP in the scope.

Conclusion

In this first article, we discussed the need for DHCP failover, the modes available, namely load balance and hot standby and how failover works.

In part 2, we will look at how to configure failover relationships and scopes. 

No comments:

Post a Comment