Avoid Deactivating Scopes
Do not deactivate a scope until you are ready to remove it (and its included range of addresses) permanently from use on the network. After a scope is deactivated, the DHCP server no longer accepts the scope addresses as valid, which can cause unwanted DHCP negative acknowledgement messages (DHCPNAKs). You can temporarily deactivate scope addresses by modifying exclusion ranges in an active scope to achieve the intended result without unwanted messages.
Use Proper Superscope Implementation
Although superscopes can ease DHCP management, they are not required just because a DHCP server is handling more than one scope (subnet ID). A single DHCP server can serve two or more physically different subnets separated by a router, where BOOTP/DHCP relay agents are configured to provide relay of client requests for scopes that serve subnets located away from the DHCP server. Relay agents are typically included with your routers and, where used, must be configured with IP addresses for your DHCP servers.
Use Multiple DHCP Servers for the Same Superscope
When using more than one DHCP server to serve a superscope segment, the superscope for each DHCP server should include all subnets, using placeholder scopes for the subnets to which it does not supply addresses but must recognize as valid.
For example, consider a segment running four logical IP subnets: 192.168.1.0, 192.168.2.0, 192.168.3.0, and 192.168.4.0, all with a subnet mask of 255.255.255.0. Two servers running DHCP support this segment, each configured with a superscope covering half of the subnets (the SRV1 superscope contains only subnets 192.168.1.0 and 192.168.2.0; and the SRV2 superscope contains only subnets 192.168.3.0 and 192.168.4.0). As DHCP requests arrive from clients, addresses can come from either of the superscopes. However, a problem might arise if a client gets an IP address from SRV1, and then SRV2 receives its renewal request. SRV2 does not recognize the client’s address as belonging to that subnet and responds to the client by sending a DHCPNACK.
You can avoid this problem by configuring both SRV1 and SRV2 with all logical IP subnets and using exclusions to prevent the servers from overlapping address ranges. SRV1 should have a superscope containing all four subnets and excluding all the addresses of the last two subnets. SRV2 should also have a superscope containing all four subnets but excluding all the addresses of the first two subnets.
BOOTP Relay Configuration
The correct deployment of DHCP servers prevents BOOTP relay agents from generating duplicate packets, which can cause the DHCP server to receive several copies of the same Discover or Request message. For example, Figures 4 and 5 show two BOOTP relay designs that have the same number of networks, servers, and routers. The Figure 4 design causes eight packets to reach the DHCP servers for every DHCP message sent by a client. The network design in Figure 5 eliminates duplicate packets while providing enough fault-tolerant redundancy such that any single part of the network can fail, but clients continue to received leases.
Figure 4. Inefficient Network Relay Design
Figure 5. A Network Design that Eliminates Duplicate Packets and Provides Fault-Tolerance
Summary
DHCP provides an efficient and reliable TCP/IP network configuration. The DHCP service also helps prevent IP address conflicts and conserves the use of IP addresses through centralized management of address allocation. In contrast to manual configuration, where each client computer must have its IP address information individually set before it can join the network, DHCP offers a form of instant access for supported clients that use DHCP.
The DHCP service provided in Windows Server 2003 builds on a long history of support for DHCP and adherence to open industry standards, while introducing features that make DHCP easy to deploy and manage. Network administrators benefit from the integration of DHCP with DNS as well as enhanced monitoring and statistical reporting for DHCP servers, new vendor-specific options and user-class support, multicast address allocation, unauthorized DHCP server detection, and Windows Clustering Services.
Related Links
See the following resources for further information:
-
Windows Server 2003 DHCP Server Role at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/serverroles/dhcpserver/default.asp
-
Windows Server 2003 Networking and Communications Services at http://www.microsoft.com/windowsserver2003/technologies/networking/default.mspx
-
Windows Server 2003 DNS Server Role at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/serverroles/dnsserver/default.asp
-
Windows Server 2003 WINS Server Role at http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/serverroles/winsserver/default.asp
For the latest information about Windows Server 2003, see the Windows Server 2003 Web site at http://www.microsoft.com/windowsserver2003.
Appendix A:
Predefined Options for DHCP Clients
The following tables describe the predefined options available for configuring servers running DHCP to automatically configure DHCP clients. Options listed in bold are options that Windows–based DHCP clients request from the server by default.
Table A-1. Basic Options
Code
|
Option Name
|
Meaning
|
0
|
Pad
|
Causes subsequent fields to align on word boundaries.
|
255
|
End
|
Indicates end of options in the DHCP packet.
|
1
|
Subnet Mask
|
|
2
|
Time offset
|
Specifies the Universal Coordinated Time (UCT) offset in seconds.
|
3
|
Router
|
Specifies a list of IP addresses for routers on the client's subnet.¹
|
4
|
Time server
|
Specifies a list of IP addresses for time servers available to the client.¹
|
5
|
Name servers
|
Specifies a list of IP addresses for name servers available to the client.¹
|
6
|
DNS servers
|
Specifies a list of IP addresses for DNS name servers available to the client.¹
|
7
|
Log servers
|
Specifies a list of IP addresses for MIT_LCS User Datagram Protocol (UDP) log servers available to the client.2
|
8
|
Cookie servers
|
Specifies a list of IP addresses for RFC 865 cookie servers available to the client.¹
|
9
|
LPR servers
|
Specifies a list of IP addresses for RFC 1179 line-printer servers available to the client.¹
|
10
|
Impress servers
|
Specifies a list of IP addresses for Imagen Impress servers available to the client.¹
|
11
|
Resource location servers
|
Specifies a list of RFC 887 Resource Location servers available to the client.¹
|
12
|
Host name
|
Specifies the host name of up to 63 characters for the client. The name must start with a letter, end with a letter or digit, and have as interior characters only letters, numbers, and hyphens. The name can be qualified with the local DNS domain name.
|
13
|
Boot file size
|
Specifies the size of the default boot image file for the client, in 512-octet blocks.
|
14
|
Merit dump file
|
Specifies the ASCII path name of a file where the client's core image is dumped if a crash occurs.
|
15
|
Domain name
|
Specifies the DNS domain name that the client should use for DNS host name resolution.
|
16
|
Swap server
|
Specifies the IP address of the client's swap server.
|
17
|
Root path
|
Specifies the ASCII path for the client's root disk.
|
18
|
Extensions path
|
Specifies a file retrievable through TFTP, containing information interpreted like the vendor-extension field in the BOOTP response, except that the file length is unconstrained and references to Tag 18 in the file are ignored.
|
The following table lists IP layer parameters on a per-host basis.
Table A-2. IP Layer Parameters per Host
Code
|
Option Name
|
Meaning
|
19
|
IP layer forwarding
|
Enables or disables forwarding of IP packet for this client: 1 enables forwarding; 0 disables it.
|
20
|
Nonlocal source routing
|
Enables or disables forwarding of datagrams with nonlocal source routes. 1 enables forwarding; 0 disables it.
|
21
|
Policy filter masks
|
Specifies policy filters that consist of a list of pairs of IP addresses and masks specifying destination/mask pairs for filtering nonlocal source routes. Any source routed datagram with a next-hop address that does not match a filter is discarded by the client.
|
22
|
Max DG reassembly size
|
Specifies the maximum size datagram that the client can reassemble. The minimum value is 576.
|
23
|
Default time-to-live
|
Specifies the default time-to-live (TTL) that the client uses on outgoing datagrams. The value for the octet is a number ranging from 1 through 255.
|
24
|
Path MTU aging time-out
|
Specifies the timeout in seconds for aging Path Maximum Transmission Unit (MTU) values (discovered by the mechanism defined in RFC 1191).
|
25
|
Path MTU plateau table
|
Specifies a table of MTU sizes to use when performing Path MTU Discovered as defined in RFC 1191. The table is sorted by size from smallest to largest. The minimum MTU value is 68.
|
The following table lists IP parameters on a per-interface basis. These options affect the operation of the IP layer on a per-interface basis. A client can issue multiple requests, one per interface, to configure interfaces with their specific parameters.
Table A-3. IP Parameters per Interface
Code
|
Option Name
|
Meaning
|
26
|
MTU option
|
Specifies the MTU discovery size for this interface. The minimum MTU value is 68.
|
27
|
All subnets are local
|
Specifies whether the client assumes that all subnets of the client's internetwork use the same MTU as the local subnet where the client is connected. 1 indicates that all subnets share the same MTU; 0 indicates that the client should assume some subnets may have smaller MTUs.
|
28
|
Broadcast address
|
Specifies the broadcast address used on the client's subnet.
|
29
|
Perform mask discovery
|
Specifies whether the client should use Internet Control Message Protocol (ICMP) for subnet mask discovery. 1 indicates that the client should perform mask discovery; 0 indicates that the client should not.
|
30
|
Mask supplier
|
Specifies whether the client should respond to subnet mask requests using ICMP. 1 indicates that the client should respond; 0 indicates that the client should not.
|
31
|
Perform router discovery
|
Specifies whether the client should solicit routers using the router discovery method in RFC 1256. 1 indicates that the client should perform router discovery; 0 indicates that the client should not.
|
32
|
Router solicitation address
|
Specifies the IP address to which the client submits router solicitation requests.
|
33
|
Static route
|
Specifies a list of IP address pairs that indicate the static routes the client should install in its routing cache. Any multiple routes to the same destination are listed in descending order or priority. The routes are destination/router address pairs. (The default route of 0.0.0.0 cannot be used as a destination for a static route.)
|
The following table lists link layer parameters on a per-interface basis. These options affect the operation of the data link layer on this basis.
Code
|
Option Name
|
Meaning
|
34
|
Trailer encapsulation
|
Specifies whether the client should negotiate use of trailers (RFC 983) when using the ARP protocol. 1 indicates that the client should attempt to use a trailer; 0 indicates that the client should not.
|
35
|
ARP cache time-out
|
Specifies the timeout, in seconds, for ARP cache entries.
|
36
|
Ethernet encapsulation
|
Specifies whether the client should use Ethernet version 2 (RFC 894) or IEEE 802.3 (RFC 1042) encapsulation if the interface is Ethernet: 1 indicates that the client should use RFC 1042 encapsulation; 0 indicates that the client should use RFC 894 encapsulation.
|
The following table shows TCP parameters. These options affect the operation of the TCP layer on a per-interface basis.
Table A-5. TCP Parameters
Code
|
Option Name
|
Meaning
|
37
|
Default time-to-live
|
Specifies the default TTL the client should use when sending TCP segments. The minimum value of the octet is 1.
|
38
|
Keep-alive interval
|
Specifies the interval in seconds the client TCP should wait before sending a keep-alive message on a TCP connection: 0 indicates that the client should not send keep-alive messages on connections unless specifically requested by an application.
|
39
|
Keep-alive garbage
|
Specifies whether the client should send TCP keep-alive messages with an octet of garbage data for compatibility with older implementations: 1 indicates that a garbage octet should be sent; 0 indicates that it should not.
|
The following table shows application layer parameters. These miscellaneous options are used to configure applications and services.
Table A-6. Application Layer Parameters
Code
|
Option Name
|
Meaning
|
40
|
NIS domain name
|
Specifies the name of the Network Information Service (NIS) domain as an ASCII string.
|
41
|
NIS servers
|
Specifies a list of IP addresses for NIS servers available to the client.3
|
42
|
NTP servers
|
Specifies a list of IP addresses for Network Time Protocol (NTP) servers available to the client.¹
|
Table A-7. Options for Vendor-specific Information.
Code
|
Option Name
|
Meaning
|
43
|
Vendor-specific info
|
Specifies binary information used by clients and servers to exchange vendor-specific information. Servers not equipped to interpret the information ignore it. Clients that do not receive the information attempt to operate without it.
|
Table A-8. NetBIOS over TCP/IP
Code
|
Option Name
|
Meaning
|
44
|
WINS/NBNS servers
|
Specifies a list of IP addresses for NetBIOS name servers (NBNS).¹
|
45
|
NetBIOS over TCP/IP NBDD
|
Specifies a list of IP addresses for NetBIOS datagram distribution servers (NBDD).¹
|
46
|
WINS/NBT node type
|
Allows configurable NetBIOS over TCP/IP clients to be configured as described in RFC 1001/1002, where 1=b-node, 2=p-node, 4=m-node, and 8=h-node.
|
47
|
NetBIOS scope ID
|
Specifies a string that is the NetBIOS over TCP/IP Scope ID for the client, as specified in RFC 1001/1002.
|
48
|
X Window system font
|
Specifies a list of IP addresses for X Window font servers available to the client.4
|
49
|
X Window system display
|
Specifies a list of IP addresses for X Window System Display Manager servers available to the client.¹
|
|
