Design and Implement Network Infrastructure Services
- Objective 2.1: Design and maintain a Dynamic Host Configuration Protocol (DHCP) solution
- Objective 2.2: Design a name resolution solution strategy
- Objective 2.3: Design and manage an IP address management solution
- Chapter summary
A network infrastructure consists of those basic services like Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Internet Protocol (IP) address management. Windows Server 2012 provides all these services. New to Windows Server 2012 is a service called IPAM, short for IP address management. IPAM gives an organization a single location from which the addressing for the entire organization can be managed and monitored.
Objective 2.1: Design and maintain a Dynamic Host Configuration Protocol (DHCP) solution
Dynamic Host Configuration Protocol (DHCP) supplies Internet Protocol (IP) addresses and other network configuration information to devices on a network. Most clients and client devices in an enterprise use DHCP to obtain network information.
This objective covers the following topics:
Design considerations, including a highly available DHCP solution that includes split scope, DHCP failover, DHCP failover clustering, DHCP interoperability, and DHCPv6
How to implement DHCP filtering
How to implement and configure a DHCP management pack
How to maintain a DHCP database
Designing a highly available DHCP solution
DHCP is a vital service on an enterprise network. Without it, clients can’t obtain IP addresses and information such as DNS servers. For this reason, DHCP is frequently deployed in a highly available manner so that if one server becomes unavailable, another can take over. This section examines the considerations involved in designing a high availability solution for DHCP.
The two goals for highly available DHCP are as follows:
Provide DHCP service at all times.
When one DHCP server is no longer available, enable clients to extend their lease by contacting a different DHCP server.
When designing a highly available DHCP solution, you should consider whether to provide split-scope DHCP or failover clustering.
With split-scope DHCP, two servers provide address and network information using a portion of the address space or DHCP scope. For example, if an organization assigns addresses from the 192.168.100.0/24 subnet, a split-scope DHCP scenario might call for 80 percent of the addresses to be assigned by one server and the other 20 percent by another server. This is known as the “80/20” rule for DHCP scope assignment, and organizations sometimes place the server with 80 percent of the scope nearest to the clients. However, you don’t need to figure out the 80/20 split; the Dhcp Split-Scope Configuration Wizard includes a step to help configure the split (see Figure 2-1).
Figure 2-1 Configuring a split-scope percentage in the Dhcp Split-Scope Configuration Wizard.
Split scope enables traffic to be split among participating servers while also providing redundancy for clients should one of the two servers fail. However, clients accept the first DHCP response they receive, so you can’t guarantee from which server clients will receive a DHCP response. If the servers are split across a network boundary, you need to configure a DHCP relay agent on a router and introduce a delay at that point so as to prevent the secondary server from responding before the primary server. The Dhcp Split-Scope Configuration Wizard also includes an opportunity to add a delay to one of the servers involved in the split scope, as shown in Figure 2-2.
Figure 2-2 Adding a delay in a split scope can help ensure that network information comes from the correct server.
Alternatively, a delay can be configured into the scope itself through the Advanced tab in the Scope Properties sheet, as shown in Figure 2-3.
Figure 2-3 Configuring a delay for the DHCP server response can help in a split-scope scenario.
A new feature of Windows Server 2012, DHCP failover means that two servers are configured with the same DHCP configuration. Windows Server 2012 has two modes for failover: hot standby and load sharing. These modes of DHCP failover are different from failover clustering, which is discussed later.
With DHCP failover, each server has a replicated version of the entire scope, including lease information. This means that either server can offer addresses for the entire scope. The practical implication of scope and lease replication is to enable both modes of operation. With a hot standby operation, one server provides DHCP information while the other server maintains a replicated version of the DHCP lease information, ready to take over if the primary server fails. In a load-sharing mode, each server assigns DHCP information and updates the shared lease information database.
Hot standby mode is useful for organizations that have a remote location with DHCP clients, sometimes called a hub-and-spoke topology. The remote location acts as the primary server; a server at the central data center acts as a backup. If the remote server goes offline, the secondary server at the data center can take over. The primary and secondary assignment is done at the subnet level, rather than the scope level. This means that a server can be primary for one subnet and secondary for another subnet.
Load-sharing mode is helpful for data center or centralized DHCP scenarios in which two servers operate within a single site. In load-sharing mode, each server assigns DHCP information to clients based on a load ratio. You set the load balance percentage at configuration time, as shown in Figure 2-4.
Figure 2-4 Configuring the load balance percentage in a DHCP failover architecture.
You can edit the load balance percentage after initial configuration from the partner server.
DHCP failover clustering
A redundant architecture available prior to Windows Server 2012 is failover clustering. With failover clustering, the primary DHCP server offers DHCP information, and the secondary server takes over if the first server fails. In this scenario, the DHCP servers share the same storage, thus making a single point of failure at the storage level.
The term interoperability refers to the relationship between DHCP and other Microsoft technologies such as Routing and Remote Access, Network Access Protection (NAP), Active Directory Domain Services (AD DS), and other related technologies, rather than interoperability between the Microsoft DHCP implementation and the DHCP implementation from other vendors.
DHCP clients can register dynamic DNS entries upon address assignment. To do so, the DHCP server depends on a directory services domain controller to be available, and the DHCP server must be authorized to make such entries into the DNS. This can be configured on the DNS tab of the Scope Properties sheet (see Figure 2-5).
Figure 2-5 Configuring dynamic DNS settings related to a DHCP scope.
The DHCP server can update both the pointer (PTR) and host address (A) record for the client. The Client FQDN option (DHCP option 81) is used for this purpose. Option 81 includes the Fully Qualified Domain Name (FQDN) and other information from the client. As Figure 2-5 shows, the server can be configured to update the DNS at all times or only if requested by the client. Older clients are also supported (ones that can’t or don’t send DHCP option 81) by selecting the Dynamically Update DNS A And PTR Records For DHCP Clients That Do Not Request Updates check box within this Properties sheet.
DHCP interoperability with AD DS is typically used to detect and authorize additional DHCP servers on the network. DHCP servers running Windows can be authorized into the AD DS schema and if not authorized, can be prevented from leasing IP addresses to clients. However, this authorization scheme works only for DHCP servers running Windows 2000 and above and doesn’t work for a DHCP server running on Linux or a network device.
DHCP can work with NAP to limit client access unless the client is in a compliant state. Figure 2-6 shows the NAP-related configuration in a scope’s Properties sheet.
Figure 2-6 Network Access Protection settings related to DHCP.
You can configure NAP at the individual scope level or for all scopes on a server.
DHCP for IPv6 operates in stateless and stateful modes. In stateful mode, clients obtain both an address and information such as DNS servers from the DHCP server. In stateless mode, clients obtain ancillary information such as DNS servers but receive their addressing through IPv6 auto-configuration or as a static IP address.
Implementing DHCP filtering
DHCP filtering, sometimes called link-layer filtering, enables you to configure how the DHCP server responds to requests for address and network information. DHCP filtering enables the DHCP server to send information only to known clients or deny information to specific clients. This is especially important in a data-center scenario in which you likely want to control the devices allowed on the network.
DHCP filtering works with Media Access Control (MAC) addresses, which are sent by the DHCP client along with a DHCP request. Windows Server 2012 has two types of filters: Allow and Deny. An Allow filter sends network information only to those clients listed in the filter. A Deny filter excludes specific clients from obtaining information from the DHCP server.
In an Allow scenario, each authorized MAC address needs to be specifically entered into the filter; otherwise, it can’t obtain information from the DHCP server. Of course, this isn’t an issue if the client is using an address that’s statically assigned on the client itself.
Windows Server 2012 enables filtering with the full MAC address or by using wildcards. For example, these are all valid filters:
Using wildcards enables you to configure a group of the same devices or devices from the same manufacturer as being allowed or denied. This saves the effort of entering each MAC address individually if a group of devices share the same MAC prefix.
DHCP filtering is configured with the DHCP MMC snap-in. Adding a filtered address is accomplished by right-clicking either Allow or Deny (depending on which type you want to set up) and then entering the MAC address details, as shown in Figure 2-7.
Figure 2-7 Creating a DHCP filter.
You also need to enable filters at the overall filter (Allow or Deny) level rather than at the individual MAC address level. To enable the Allow or Deny filter, right-click Allow or Deny in the DHCP MMC snap-in and select Enable. You can also enable filters at the scope level.
Implementing and configuring a DHCP Management Pack
The DHCP Management Pack, part of the Operations Manager component of Microsoft System Center 2012, enables advanced logging and monitoring of the DHCP environment. For example, the DHCP Management Pack enables monitoring of the availability of the DHCP service, the filtering status, and the status of scopes to help prevent scope exhaustion.
Implementing a DHCP Management Pack requires Microsoft System Center 2012. The DHCP Management Pack is imported into Operations Manager. Creating a new management pack is recommended to incorporate any changes to the DHCP Management Pack without affecting the original configuration.
Table 2-1 outlines several scenarios for monitoring a DHCP infrastructure.
Table 2-1 Common scenarios for DHCP monitoring
What to Monitor
The servers themselves
Monitor for the availability of the service and detect unauthorized DHCP servers.
Monitor when a scope is nearing address exhaustion.
The DHCP database
Monitor when the database is having problems.
Monitor for excessive requests or queue length as well as the number of addresses in use, and related items.
Maintaining a DHCP database
Maintenance of a DHCP database involves backing up and restoring the database. The location of the database and its backup location can be configured at the server level within its Properties sheet, as shown in Figure 2-8.
Figure 2-8 Configuring the location of the DHCP database, as well as its backup location.
You can back up and restore the DHCP database through Actions at the server level in DHCP Manager. Also, to change an automated backup that runs every 60 minutes, set the BackupInterval value in the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters.
At times you may need to reconcile the database due to inconsistencies in client addressing between summary and detailed information. To do so, select Reconcile All Scopes from the address level (IPv4 or IPv6) or at the scope level by clicking Reconcile.
The DHCP server role in Windows Server 2012 provides for redundancy with split scope, failover through hot standby and load sharing, and failover clustering.
Hot standby failover enables a server to take over should its counterpart fail.
Load-sharing failover enables both servers to assign DHCP information.
Failover clustering enables both servers to assign DHCP information by sharing the same DHCP database on a shared storage location.
DHCP filtering configures how the server responds to clients by using link-layer MAC addresses.
The DHCP Management Pack, part of System Center Operations Manager, enables monitoring and reporting of the DHCP service.
The DHCP database is stored on the file system and needs to be reconciled occasionally to remove stale entries.
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
You’re configuring a split-scope DHCP scenario between two servers. What’s the recommended percentage for a DHCP split scope configuration?
Which of the following are valid MAC filters in Windows Server 2012? (You can assume that the MAC addresses themselves are valid.)
You need to move the DHCP database. Assuming a standard Windows directory and Program Files path structure and that you’ve changed the path in the DHCP Manager, what’s the default path where the DHCP database is found?
While implementing split scope, you notice that the secondary server is responding to numerous DHCP requests first. What’s the best way to handle this situation?
Increase the split ratio so that the secondary server has more IP addresses from the scope.
Introduce a delay for DHCP offers from the secondary using the DHCP management console.
Reduce the load on the primary server so that it can respond faster.
Place the secondary DHCP server on a different network segment to introduce a delay in the response.