1, Reason that DHCP use UDP Protocol instead of TCP Protocol: DHCP don’t need to guarantee the delivery, but need fast reaction.
DHCP is a layer 4 protocol, the DHCP Clients use UDP port 68, DHCP Servers use UDP port 67
- Eliminate IP conflict
- Zero error
- Save time and labor
- Centralized administration
- Flexible for mobile users: choose different lease duration for different environments.
3, Exclusion IP addresses for Router, Printer, network storage, etc.
- In windows environment, we use configuring exclusions.
- In Linux environment, we use subnet declaration to get the same result. Eg.
If you have multiple ranges of IP addresses on the same subnet, you can add multiple range options to a subnet declaration.
- GUI: Click start, then server manager.
- CLI: Use servermangercmd.exe on FULL version or Use ocsetup.exe on SERVER CORE.
Syntax: ocsetup DHCPServerCore (The name is CASE SENSITIVE!!!!!)
- Creating a DHCP SCOPE:
netsh Dhcp Server 192.168.100.10 add scope 192.168.150.0 255.255.255.0 “Primary Scope” “Primary Scope for Netsh Example”
netsh Dhcp Server 192.168.100.10 Scope 192.168.150.0 add iprange 192.168.150.1 192.168.150.254
- Creating a DHCP reservation:
netsh Dhcp Server 192.168.100.10 Scope 192.168.150.0 add reservedip 192.168.150.20 03043c40fb6af MSN-SRV-150
- Creating a DHCP exclusionary range:
netsh Dhcp Server 192.168.100.10 Scope 192.168.150.0 add excluderange 192.168.150.1 192.168.150.10
- Creating a DHCP option:
netsh Dhcp Server 192.168.100.10 Scope 192.168.150.0 set optionvalue 6 IPADDRESS “192.168.100.10” “192.168.100.20”
- Deactivating a DHCP scope:
netsh Dhcp Server 192.168.100.10 scope 192.168.150.0 set state 0
- Set the network adapter on a client to use DHCP:
netsh int ip set addr “local area connection” DHCP
netsh int ip set dns “local area connection” DHCP
IP Reservation and exclusion can be used for the static IP assigning plan, such as printers, servers. However, Ip reservation need the MAC address of the host to assign a specific address for it. We need to configure the IP information at the client when we use the exclusion. Exclusion can reduce network latency produced by DHCP service.
DHCP options
DHCP options can be assigned at following levels:
- Server options: affect all scopes but can be overridden by a scope, policy, or reservcation option.
- Scope options: scope options affect clients that get a lease from the scope in which the option is configured. Scope options can be overridden by reservation options or DHCP policies.
- Policy options: DHCP policies allow an administrator to assgin IP address options to clients based on client properties, such as device type, MAC address, or OS. Options specified at the policy level can be overridden only by reservation options.
- Reservation options: take precedence over any conflicting options set at any other level.
DHCPv6 Operation
Unlike DHCPv4, the client’s MAC address isn’t used to lease an address and create reservations. DHCPv6 uses DHCP Unique Identifier (DUID). In windows, a DUID is a hexadecimal number, usually derived from the network interface’s MAC address.
- It is created when Windows is installed
- It does not change even if the NIC changes.
- The DUID is stored in the
HKLM\System\CurrentControlSet\Services\TCPIP6\Parametersregistry key. If you delete this key, the DUID is created when the system is restarted. - You can check the DUID by
ipconfig /allcommand.
The DHCP client listens on port 546, and DHCP server listens on port 547.
The four message exchange:
- The DHCPv6 client sends a Solicit message from its link-local address via UDP source port 546 to the IPV6 multicast address ff02::1:2 on destination port 547
- The DHCPv6 server replies with an Advertise message to the link-local address of the client on destination port 546. This message contains the IPv6 address offered to the client.
- The DHCPv6 client replies with a request message from its link-local address, accepting the offered address. The message is still addressed to the IPV6 multicast address ff02::1:2 at UDP port 547.
- The DHCPv6 server responds with a reply message confirming the address assignment. At this point, the client binds the assigned IPv6 address to its interface, the server adds the address to its list of leased address, and the process is completed.
command to renew ipv6 address: ipconfig /renew6
Create a DHCPv6 Scope in windows server:
Note: You must assign the server interface an IPv6 address within the scope you created.
New in Windows 2012
DHCP failover in Windows Server 2012 enables administrators to deploy a highly resilient DHCP service to support a large enterprise. The main goals of the feature are the following:
- Provide DHCP service availability at all times on the enterprise network.
- If a DHCP server is no longer reachable, the DHCP client is able to extend the lease on its current IP address by contacting another DHCP server on the enterprise network.
The DHCP server failover feature provides the ability to have two DHCP servers provide IP addresses and option configuration to the same subnet or scope, providing for continuous availability of DHCP service to clients. The two DHCP servers replicate lease information between them, allowing one server to assume responsibility for servicing of clients for the entire subnet when the other server is unavailable. It is also possible to configure failover in a load-balancing configuration with client requests distributed between the two servers in a failover relationship.
DHCP failover in Windows Server 2012 provides support for a maximum of two DHCP servers, and the failover relationship is limited to IPv4 scopes and subnets. Network nodes using Internet Protocol version 6 (IPv6) typically determine their own IPv6 address using stateless IP auto configuration. In this mode, the DHCP server delivers only the DHCP option configuration, and the server does not maintain any lease state information. A high availability deployment for stateless DHCPv6 is possible by simply setting up two servers with identical option configuration. Even in a stateful DHCPv6 deployment, the scopes do not run under high address utilization, which makes split scope a viable solution for high availability.
DHCP high availability
Ways to achieve high availability for DHCP:
- Split scopes : fault-tolerant DHCP configuration in which two DHCP servers share the same scope information, allowing both servers to offer DHCP services to clients.
- DHCP failover
- DHCP server cluster: complex network setup, including shared storage for the DHCP database that multiple DHCP servers have access to.
- Hot standby : two DHCP servers configured with identical scopes and options. If primary server fails, an administrator must manually restore the DHCP database from backup to the standby server, which might not have the most recent lease data.
The most recommended methods : split scopes and DHCP failover.
DHCP split scopes (only on ipv4)
One server is configured as the primary DHCP server and the other as the secondary. In most cases, the secondary server lease addresses only if the primary server is unavailable.
- Before windows 2008 R2, you must configure the split scope manually.
- Starting with Windows 2008 R2, we can create split scope by using wizard.
Right-click the scope in the DHCP console, point to Advanced, and then click Split-Scope. Then we can configure following:
- The percentage of split: A typical split percentage is 80/20.
- Delay in DHCP offer: Specify the number of milliseconds each server should delay between receiving DHCPDISCOVER and sending a DHCPOFFER. You should set the primary server for a 0 delay, a secondary server typically set to 1000, but you can adjust this value to intended result.If you want to provide load balancing, you can set both server to 0 delay.
Note that split scopes only works on IPv4 not IPv6.
DHCP failover architecture
Administrators can deploy DHCP servers running Windows Server 2012 as failover partners in either hot standby mode or load sharing mode.
Some term in the failover architechture:
- Communication Interrupted state: each server operates independently but assumes the other server is still operational.
- Partner down state: in this state, the DHCP server assumes that its failover partner is no longer operational.
- Maximum client lead time(MCLT): defines the maximum amount of time a DHCP server can extend a lease for a DHCP client without the partner server’s knowledge. It also defines the amount of time a server waits before assuming control over al DHCP services if its partner is in Partner Down state.
In hot standby mode, two servers operate in a failover relationship where an active server is responsible for leasing IP addresses and configuration information to all clients in a scope or subnet. The secondary server assumes this responsibility if the primary server becomes unavailable. A server is primary or secondary in the context of a subnet. For instance, a server that has the role of a primary for a given subnet could be a secondary server for another subnet.
Hot standby mode of operation is best suited to deployments where a central office or data center server acts as a standby backup server to a server at a remote site, which is local to the DHCP clients (ex: hub and spoke deployment). In such deployments, it is undesirable to have a remote standby server service any clients unless the local DHCP server becomes unavailable. The figure below is an example of a hub and spoke deployment.
2. Load sharing mode (load-balancing)
In a load sharing mode deployment, which is the default mode of operation, the two servers simultaneously serve IP addresses and options to clients on a given subnet. The client requests are load balanced and shared between the two servers.
The load sharing mode of operation is best suited to deployments where both servers in a failover relationship are located at the same physical site. Both servers respond to DHCP client requests based on the load distribution ratio configured by the administrator.
Parameters:
- Maximum client lead time(MCLT): defines the maximum amount of time a DHCP server can extend a lease for a DHCP client without the partner server’s knowledge. It also defines the amount of time a server waits before assuming control over al DHCP services if its partner is in Partner Down state.
- Load balance percentage: define the percentage of client requests serviced by each server. default is 50%.
- State switchover internal: When a DHCP server loses communication with its partner, it enters the Communication Interrupted state. If the state switchover internal option is enabled, you can define the time in which a server transitions from communication interrupted state to partner down state. By default this option isn’t enabled, and an administrator must manually configure Partner Down state.
- Enable message authentication : to increase security, you can enable authentication between failover partners by enter a shared secret.
Once the failover relationship is established, both inbound and outbound rules for TCP port 647 (DHCP failover) are configured on windows firewall to allow communication between the two servers.
Reference: https://technet.microsoft.com/en-us/library/hh831385
Configure DHCP for DNS registration
MS DHCP server can work with DNS to provide name resolution on behalf of DHCP clients.
The DHCP server can be used to register and update the pointer (PTR) and host (A) resource records on behalf of its DHCP-enabled clients.
This process requires the use of an additional DHCP option, the Client FQDN option (option 81). This option permits the client to provide its fully qualified domain name (FQDN) as well as instructions to the DHCP server about how the server should process DNS dynamic updates (if any) on its behalf.
More about option 81
Option 81 (a.ka. FQDN option) is one of the many DHCP option fields. This one in particular is used by the clients at DHCPREQUEST time to tell the DHCP server how it should behave concerning DNS updates.
For clients running Windows 2000, Windows XP or Windows Server 2003, the process goes like this:
1. The client sends a DHCPREQUEST and include the option 81. By default it requests that the server updates (sends to the DNS server) only the PTR record, while the client is in charge of updating his own A record.
2. If the server is configured with the default settings (update DNS entries only if clients ask for it) answers with a DHCPACK which contains the option 81 which says that it will only update the PTR record, as requested.
3. The only thing left after the agreement is to do it! The client sends a dynamic DNS update to the DNS server and the DHCP server updates the PTR on behalf of the client.
I got this info at the Microsoft Technet site but how does this work when the DHCP server is a Cisco router, instead of a MS server?
Inside the ip dhcp pool section there’s an option to specify how should this server manage the DNS updates. The syntaxis is as follows:
update dns [both | never] [override] [before]
The default option, that is, the behaviour when this option is not explicitly configured is to don’t perform any update. This is similar to using the option never, I guess.
The interesting options here are both and override, which have opposite effects.
Both will make the Cisco router to update both entries (A and PTR) on behalf of the client. This could be useful if the client lacks this capability, for example a very old Windows client.
Override, on the other side, will instruct the router to perform DDNS updates for PTR records even if the client has specified that the server should not send updates.
Long story short, in a regular network configuration with MS Windows clients, the Cisco router should be configured with the (sub)command “update dns” to let the client update its own A record, while the router takes care of the PTR RR.
When this option is issued by a qualified DHCP client, option 81 is processed and interpreted by a DHCP server running Windows Server 2008 to determine how the server initiates updates on behalf of the client. If the server is configured to perform DNS dynamic updates, it takes one of the following actions:
- The DHCP server updates both DNS A and PTR records if requested by clients using option 81.
- The DHCP server updates DNS A and PTR records regardless of whether the client requests this action.
In addition, the DHCP server can dynamically update DNS A and PTR records on behalf of legacy clients that are not capable of sending option 81 to the server. You can also configure the DHCP server to discard client A and PTR records when the client lease is deleted.
The DHCP server might be configured in one of the following ways:
- The DHCP server registers and updates client information with the authoritative DNS server of the zone in which the DHCP server is located according to the DHCP client request.This is the default configuration for DHCP servers running Windows Server 2008. In this mode, the DHCP client can request the way in which the DHCP server performs updates of its host (A) and pointer (PTR) resource records. If possible, the DHCP server accommodates the client request for handling updates to its name and IP address information in DNS.To modify this setting, select the Dynamically update DNS A and PTR records only if requested by the DHCP clients check box, which is located in Properties on the DNS tab on the applicable DHCP server or on one of its scopes. This is the default setting.
- The DHCP server always registers and updates client information in DNS.This is a modified configuration supported for DHCP servers running Windows Server 2008 and DHCP clients. In this mode, the DHCP server always performs updates of the client’s FQDN, leased IP address information, and both its host (A) and pointer (PTR) resource records, regardless of whether the client has requested to perform its own updates.To modify this setting, select the Enable DNS dynamic updates according to the settings below check box and click Always dynamically update DNS A and PTR records, which is located in Properties on the DNS tab on the applicable DHCP server or on one of its scopes.
- The DHCP server never registers and updates client information in DNS.To set this behavior, the DHCP server must be configured to disable performance of DHCP/DNS proxied updates. By disabling this feature, no client host (A) or pointer (PTR) resource records are updated in DNS for DHCP clients.If necessary, this change in setting can be made at DHCP servers running Windows Server 2008 by clearing the Enable DNS dynamic updates according to the settings below check box, which is located in Properties on the DNS tab on the applicable DHCP server or one of its scopes. By default, updates are always performed for newly installed DHCP servers running Windows Server 2008 and any new scopes created for them.
In addition to these standard DHCP/DNS interactions, the DHCP server can be configured to perform these optional update tasks as follows:
- The server can selectively be configured to not send updates for discarding a client host (A) resource record when the client lease expires.When the DHCP server is enabled to perform DNS updates, it always sends updates to discard the client pointer (PTR) resource records when the lease expires. You can configure whether the server also does this with client host (A) resource records when the lease of a client expires (by default, the server discards these).To modify this at the applicable DHCP server, clear the Discard forward (name-to-address) lookups when leases expires check box in Properties on the DNS tab. (enabled by default )
- The server can be selectively configured to not send updates for clients unable to use the Client FQDN option (option 81), to request the way that updates are handled.By default, the DHCP server does not send updates for clients that do not support option 81.To modify this setting, select the Dynamically update DNS A and PTR records for DHCP clients that do not request updates (for example, clients running Windows NT 4.0) check box, which is located in Properties on the DNS tab on the applicable DHCP server or one of its scopes.
Reference: How DHCP and DNS interact with each other.
DHCP name protection
On networks with both Windows and Non-Windows computers, a problem known as name squatting can occur when a non-windows computer registers its name with a DNS server, but the name has already been registered by a windows computer. When all computers are member of a Windows Domain, name squatting is not a problem, because Active Directory ensures that all computer name are unique.
DHCP name protection prevents name squatting by non-windows computers by using a DHCP resource record called DHCPID.It’s a resource record used by DHCP and DNS to verify that a name being registered in DNS is from the original computer that registered it if the name already exists. In other words, first in first protect.
DHCP name protection can be configured at server node or scope node. The protection configured at the scope node doesn’t affect other scopes.
DHCP recovery
If not, we can try to boot into safemode or boot into a windows server installation DVD > repair your computer> Troubleshoot >Advanced option > command prompt , then copy all the DHCP configuration file(%systemdrive%\Windows\System32\dhcp\backup\DhcpCfg) and Database files(under %systemdrive%\Windows\System32\dhcp\backup\DhcpCfg\new\)from the failed server to a USB.
Once we have all the configuration file of the DHCP, then we can install a clean win server, configure the server name, assign a same static IP address same as the failed server, then install the DNS and DHCP server roles .
Then stop the dhcp server and copy the files which are from %systemdrive%\Windows\System32\dhcp\backup\DhcpCfg\new\ to the %systemdrive%\Windows\System32\dhcp\. Edit the Dhcpcfg file with notepad, add the line “Windows Registry Editor Version 5.00” , save it as dhcpcfg.reg, then double click it to import the registry configuration. By now we have restored all the DHCP configuration and database, start the DHCP service.
Lab: DHCP failover configuration
- Right-click on Scope from the left column and select Configure Failover:
- Uncheck All, Select the scope you would like to configure.
- Click Add Server and select the new authorized DHCP server to add the partner server:
- Select the failover mode, I select 10% for the Addresses Reserved for Standby. then specify the role of partner server (in our example Hot standby mode):
- Click Finish. Check if all the jobs are completed successfull
To test with the standby server functionality, stop the primary DHCP service, then on a client machine, issue ipconfig /release, then ipconfig /renew. You should receive an IP address which is in the last 10% of the IP range.
Error: 20010. The specified option does not exist.
If your old DHCP server has any option defined, then you would receive this error, all we need to do is define this option again on the new server. I will take WPAD as an example, then you can configure yours.
- Go to DHCP management console, Expand the server name, right click on IPv4. select “set predefined options”
- In the Predefined options dialog box press “add”
- In the option type dialog box set the following values:
Name: WPAD
Data Type: String
Code: 252
Description: - Then click OK to close all the windows.
Go back to configure the failover again, it should finish successfully this time.
(Optional) export and import Allow/Deny list:
- On the old server, right click allow/Deny, then click “Export List…”, copy the file to the new server.
- unfortunately, there is no GUI go import the list, so we need to modify the file into a csv and import via Powershell.
- Change the file extension into csv. Open it with Notepad++ (download if you don’t have it installed),
- delete space between MAC and Address.
- hit ctr+f, then select Replace tab.
- Under search mode: select Extended, in find what: type \t , which means find the Tab space; in Replace with: type ,
- Then click Replace All. Save the file
- Open powershell with admin right, type below command: Import-Csv -Path “C:\tmp\dhcp_allowed.csv” | Add-DhcpServerv4Filter -list Allow
- Confirm it in the DHCP console list
References
http://windowsitpro.com/networking/dhcp-recovery
Import the allow/deny list with Powershell:https://docs.microsoft.com/en-us/powershell/module/dhcpserver/add-dhcpserverv4filter?view=win10-ps