Windows NT TCP/IP Network Administration
|
Windows NT TCP/IP Network Administration
|
The Microsoft Dynamic Host Configuration Protocol (DHCP) Server is a Windows NT Service that automatically assigns IP addresses to clients running DHCP client software. By using DHCP, you can centralize the management of IP addresses, netmasks and other IP configuration information, greatly reducing the amount of administration needed to maintain a network running TCP/IP transport.
A DHCP client does not have a permanently assigned, "hard-coded" IP address. Instead, at boot time, the DHCP client requests an IP address from the DHCP Server. The DHCP Server has a pool of IP addresses that are available for assignment. When a DHCP client requests an IP address, the DHCP Server assigns, or leases, an available IP address from that pool to the client. The assigned IP address is then owned by that client for a specified period, called the lease duration.
When the lease expires, that IP address is returned to the pool and becomes available for reassignment to another client. When a client reboots, it checks to see if its lease is still valid. If so, it continues using the same IP address. If not, it requests a new IP address from the DHCP server. Servers and other computers that should always have the same IP address may be assigned a permanent IP address using a DHCP permanent lease.
Many people believe that DHCP is a proprietary Microsoft protocol. It is not, although Microsoft was instrumental in having DHCP adopted as a formal Internet standard. The Internet community has long recognized that a dynamic means of assigning IP addresses to clients was needed, both to reduce the administrative load of manually managing IP addresses and related information like subnet masks and default routers, and to increase the efficiency with which the limited IP address space is allocated.
DHCP extends an earlier protocol called BOOTP, which provided similar, although more limited, functionality. DHCP added several new configuration options and the ability to allocate reusable network addresses automatically. DHCP and BOOTP clients are largely interoperable, and some network components still depend on BOOTP. BOOTP and DHCP are defined in the following Internet Requests for Comment (RFCs), which you may retrieve with your ftp client at ds.internic.net/rfc or with your Web browser at www.internic.net/ds/dspg2intdoc.html
DHCP uses a client-server architecture. DHCP servers are available for many operating systems, including UNIX, Novell NetWare 4.1x, and, of course, Windows NT Server. Similarly, DHCP clients are available for nearly any client operating system. A workstation running any standards-compliant DHCP client software can communicate with, and be serviced by, any standards-compliant DHCP server. The Microsoft DHCP implementations for both client and server comply fully with the relevant RFC standards.
Microsoft has taken things a step further by integrating DHCP functions on both the client and the server with Microsoft Domain Name System (DNS) and Microsoft Windows Internet Naming Service (WINS) functions. The one downside is that, in order to get the maximum benefits from this tight integration, you must run Microsoft operating systems on all of your servers and clients. Given the realities of today's environment, that's not much of a hardship for many administrators. NetWare servers, Macintosh clients, and other non-Microsoft DHCP devices on your network can still participate, although with a somewhat reduced level of integration.
DHCP has become a practical necessity for large IP networks for two reasons. First, each host in a TCP/IP network must have a unique IP address. This simple fact has caused a tremendous amount of aggravation and extra work for network administrators, and has resulted in more than a few crashed networks. In the early days of TCP/IP networking, there was no automated alternative; you had to assign an IP address manually to each host. Even today, many networks continue to use manual assignment and tracking of IP addresses.
Assigning IP addresses manually is practical only for small networks. As the size and complexity of the network increases, using manual IP address assignment becomes increasingly unworkable. Each time a workstation, server, network printer, router or other host is added or relocated, someone must determine a valid IP address, ensure that that IP address is not already in use by another host, record the assignment of that address, and then finally configure the host manually for that IP address. This process requires expert staff time and is always prone to error. Accidentally duplicating an IP address will at best cause a communication failure on both affected hosts. At worst - if the duplicated IP address belongs to a server, router or other critical network component - the duplicate IP address may cause the entire network to crash. Microsoft TCP always checks to see if its address is a duplicate by issuing an ARP before using the address.
The second motivation for using DHCP is that the perceived shortage of IP network addresses has made it necessary to use IP host addresses more efficiently. Only a few years ago, getting a Class C Network Address (256 IP addresses) was a matter of simply asking InterNIC to assign one to you. Requests for as many as 16 contiguous C blocks were routinely honored by InterNIC without much formality. If you said you needed it, they gave it to you. Even getting a Class B Network Address (256 C blocks, or 65,536 IP addresses) required minimal paperwork and justification.
Nowadays, it's a struggle to get InterNIC to assign even a single Class C Network Address. Getting multiple C blocks assigned requires spending hours or days completing detailed justifications, network plans, and so forth. Getting a B block assigned is almost impossible unless you are applying on behalf of a Fortune 500 corporation, and even then it's not a foregone conclusion.
The large granularity of Network Addresses - a C block is the smallest unit that can be assigned - means that many IP addresses are wasted. Consider a small branch office with a router, a server and 7 workstations. If that branch office is assigned a Class C Network Address, only 9 of the available 256 IP addresses are in use. The remaining IP addresses cannot be used except at that branch office, and so are wasted. In the past, this didn't much matter, because Network Addresses were free and were easily available from a seemingly inexhaustible supply. Some large companies with many small remote sites wasted 90% or more of the many IP addresses assigned to them.
Network addresses are assigned by InterNIC on a first-come, first-served basis, which means that there is absolutely no correlation between Network Address and geographic location. For example, InterNIC assigned to Triad Technology Group, Inc. (Thompson's company, located in Winston-Salem, NC) the Class C Network Address 204.238.30.0. The Network Address immediately preceding that one, 204.238.29.0, is assigned to Warner Brothers Imaging Technologies in Sherman Oaks, CA. The Network Address immediately following that one, 204.238.31.0, is assigned to the Bead Gallery in Juneau, AK.
A side effect of this policy has been the explosive growth of routing tables. Each individually assigned Network Address requires a routing table entry in every router on the backbone. A contiguous block of, say, 16 Class C Network Addresses assigned to the same network requires only a single routing table entry. Those same 16 C blocks, if assigned individually to different companies (and different networks), require 16 individual routing table entries. As of early 1997, the routing tables on the Internet backbone have grown to more than 30 MB
InterNIC strongly encourages you to use IP addresses assigned to you by your Internet Service Provider (ISP) rather than applying directly to InterNIC for your own block of addresses. They do so both to avoid wastage of IP addresses and to slow the growth of routing tables.
However, there is a downside to using addresses provided by your ISP, and you won't hear either InterNIC or your ISP talking much about it. Addresses provided by your ISP belong to the ISP rather than to you. This means they aren't portable. If you decide to change ISP's, you have no option but to recast your IP address assignments network-wide to use the addresses provided by your new ISP. In effect, using addresses provided by an ISP locks you into that ISP.
At first, InterNIC simply recommended that you use ISP-provided IP addresses, but that didn't accomplish much. Most administrators were concerned about address portability, and so simply continued to apply to InterNIC when they needed additional Network Address blocks. Seeing this, and still determined to slow the growth of routing tables, InterNIC next began warning applicants for Network Address blocks that there was no guarantee that individually assigned blocks would be routable in the future.
Apparently, this hasn't worked either, because InterNIC now proposes to charge for directly assigned IP addresses. Under this proposal, any organization to which InterNIC directly assigns a Network Address must pay a $1,000 annual fee, with additional charges assessed based on the number of IP addresses assigned. If this proposal is implemented, you will see the wholesale abandonment of Class C Network Addresses. Almost everyone will use Network Addresses provided by his ISP.
So, what relationship exists between the source of your IP addresses and using DHCP? Simply this. Implementing DHCP on your current network will allow you to recast your IP addressing much more easily when (not if) you find yourself switching to addresses provided by your ISP. If you are using DHCP when the time to recast arrives, you will need to change only the DHCP server configuration and the few static addresses assigned to servers and routers, including the DHCP server. If you are not running DHCP, you will need to change the IP configurations individually for each machine on your network.
Now that we know why using DHCP is desirable, if not essential, let's take a look at how it actually works. When you install the Microsoft DHCP Server, a DHCP Server database is created. This database contains two types of information. First, it contains static configuration data supplied by the administrator using DHCP Manager. These static data include the range of IP addresses available to the DHCP Server for assignment to DHCP clients, and various DHCP options set by the administrator. The DHCP Server database also maintains dynamic configuration data that is modified continuously by the interactions between the DHCP Server and its clients, e.g. those IP addresses that are currently in use and to which clients they are assigned.
When a DHCP client boots, the DHCP Server supplies it with the IP configuration information needed by that client to participate in the TCP/IP network. This configuration information includes:
The TCP/IP configuration parameters that are eventually assigned to the DHCP client are negotiated by messages exchanged between the DHCP Server and the DHCP client in the following sequence:
A DHCP client that has no further need to participate on the TCP/IP network can also issue a Dhcprelease packet to notify the DHCP server of that fact. When the DCHP Server receives a Dhcprelease packet from a client, it cancels the lease on the IP address allocated to that client. This can be forced by using ipconfig or winipcfg .
The DHCP Server honors this request - unless the IP address in question has already been assigned to a different client in the interim - by returning a Dhcpack packet. If the requested IP address is not available, the DHCP Server instead returns a Dhcpnack packet to inform the client that it must restart the DCHP negotiation by broadcasting a Dhcpdiscover packet.
A DCHP scope is a collection of IP configuration information that defines the IP parameters that will be used by all DCHP clients on a particular subnet. Each subnet may have exactly one DHCP scope, which comprises a single contiguous range of IP addresses. Each DHCP scope is defined by the administrator using the DHCP Manager application. A DHCP scope defines the following information:
In addition to the DCHP scope characteristics described above, you can use DHCP Manager to modify the following optional DHCP scope items:
In addition to the standard DHCP scope configuration parameters described in the preceding section, you can use DHCP Manager to configure the DHCP options defined by RFC1533 and RFC1541. DHCP options are used to configure advanced TCP/IP settings like WINS and DNS integration.
You can specify DHCP options individually for each DHCP scope, or globally for all DCHP scopes. DHCP option values defined globally are used for all DHCP scopes except under the following circumstances. First, if a global DHCP option is also defined for an individual DHCP scope, the value set for the individual DHCP scope overrides the global setting, and is used for that DHCP scope. Second, DHCP options set for an individual DHCP client override both global and scope DHCP option settings, and are used for that DHCP client.
The Microsoft DHCP Server supports most of the DHCP options defined by RFC1533 and RFC1541. Microsoft DHCP clients, however, understand only a small subset of these DHCP options. Defining DHCP option values in Microsoft DHCP Server that are not supported by Microsoft DHCP clients is useful only to support non-Microsoft DHCP clients that support those options. The client-side and server-side DHCP options supported by Windows NT are detailed in Appendix C, Microsoft DHCP Option Support .
A Microsoft DHCP packet can contain up to 312 bytes of DHCP option data, which is more than sufficient for most DHCP configurations. However, this 312 byte limit is fixed. Some third-party DHCP servers and clients allow you to use option overlays , which store additional DHCP option data in unused space in the DHCP packet. Neither the Microsoft DHCP Server nor Microsoft DHCP clients support the use of option overlays. If you attempt to specify a complex DHCP option configuration - one that requires more than 312 bytes of storage - option data beyond the 312 byte limit is truncated and ignored. Therefore, if your Microsoft clients obtain their TCP/IP configuration parameters from a non-Microsoft DHCP server, make sure that all DHCP options supplied by that server fit within the allowable length. If that is not possible, make sure that the DHCP options required by the Microsoft clients appear within the first 312 bytes of option data.
The Windows NT Server 4.0 DHCP Server service uses the same database engine as Microsoft Exchange Server 4. Installing DHCP Server automatically creates the following database files in %SystemRoot%\system32\Dhcp .
The DHCP database is modified dynamically. Each time a DHCP client boots and is assigned TCP/IP configuration parameters by the DHCP Server, these changes are recorded to the DHCP database. Similarly, as DHCP client leases expire, these changes are also recorded.
Because the DHCP database files are always open, it is impossible to back them up using traditional means. To ensure that critical DHCP data is not lost, Windows NT Server automatically backs up the DHCP database to the %SystemRoot%\system32\Dhcp\backup folder. Once written, these files are then closed, and so can be backed up normally.
The default value for BackupInterval is 0x3C (or 60 minutes). If you have many DHCP clients, particularly ones that connect to and disconnect from the network frequently, setting the BackupInterval to a smaller value - perhaps 0x14, or 20 minutes - makes sense. Similarly, if your DHCP environment is small and relatively static, setting BackupInterval to a larger value - perhaps 0xF0, or 240 minutes - risks little (but also gains little).
If your primary backup program can be run from a batch file, you can use it to backup the main DHCP database. To do so, create a batch file that shuts down the DHCP Server (closing the database), runs the backup program, and then restarts the DHCP Server. Controlling the DHCP Server from the command line is described at the end of the following section on installing DHCP Server.
Installing the Microsoft DHCP Server is so easy that some administrators install it without much thought, and paint themselves into a corner by doing so. In a typical network, the DHCP Server places such small demands on server resources that you can easily forget that DHCP is even there. That's a mistake. Once it is installed, the DHCP Server becomes a mission-critical component of your network. If the main DHCP Server fails and you do not have a standby DHCP server available, all of your workstations lose TCP/IP connectivity at the end of their lease, or when they reboot.
The size and complexity of your network largely determine how much DHCP planning you need to do. You might be able to plan DHCP for a small network in a few minutes on the back of an envelope. Planning DHCP for a large, complex internetwork may require much more effort. Before you install DHCP, spend some time thinking about how you want DHCP to work for you and how you will cope with a failure.
Planning DHCP for a simple network - one in which all devices are connected to a single logical segment - is pretty straightforward. A simple network may use repeaters to extend the reach of its physical segment; it may also use bridges to connect multiple physical segments into a single logical segment; it does not, however, use routers to link multiple logical networks (or subnets) into a single network - with one exception - a simple network may include a border router that is used to link that network to the public Internet. Take the following steps to plan and implement DHCP:
If you have only one server running Windows NT Server on the network, you can also use a third-party DHCP server, e.g. one running on a UNIX host, to provide redundancy. You can implement this sort of redundancy using either method described above - as a standby DHCP server or using independent DHCP scopes.
Planning DHCP for a large, complex network (or internetwork) is considerably more involved than doing so for a simple network. Although there is essentially no theoretical upper limit to the number of clients that a single DHCP server can support, practical limits appear on real-world networks because of issues like IP address classes, subnet topologies, redundancy needs, and server bottlenecks.
If such a thing exists as a "typical" arrangement for a complex network, it might look something like this:
Beyond this one-size-fits-all generic approach, when you implement DHCP on a routed internetwork, your planning should encompass the issues described in the following sections.
The defining characteristic of a complex network is that it uses routers to connect subnets via LAN or WAN links. Therein lies a difficulty, because DHCP is a broadcast protocol, and some routers simply discard DHCP broadcast packets instead of forwarding them.
Routers that implement the DHCP/BOOTP relay agent (as defined by RFC1542) forward DHCP broadcast packets properly, and are referred to as RFC1542-compliant. Many routers, particularly those that are intended primarily as IPX routers and route IP only as an adjunct, are not RFC1542-compliant. On RFC1542-compliant routers, the relay agent intercepts DHCP broadcast requests from clients on its local subnet and forwards those packets to a DHCP server on a remote subnet. When the DHCP server responds, the router forwards the response to the local client.
Even if your routers are RFC1542-compliant, your goal should be to minimize B-node broadcasts across the routers, particularly on slow WAN links. Accordingly, your existing subnet topology and the types of routers you have installed will have a distinct impact on how many DHCP servers you need and where they must be placed. If all or some of your routers are not RFC1542-compliant and cannot be upgraded to become so, you have two alternatives:
Having the ability to move DHCP broadcast packets across a router - either via compliant router hardware or the DHCP Relay Agent - is probably the single most important component in planning and implementing DHCP in a large-scale environment. Being able to cross routers gives you flexibility. For example, if a DHCP server on one subnet goes down, clients on that subnet will still be able to use a DHCP server on another subnet. If your network is not configured to allow DHCP broadcast packets to cross routers, all of your troubles are amplified. Not only must you provide a DHCP Server for each subnet, but you have to worry about what happens when that DHCP server fails.
Once implemented, DHCP becomes a critical part of your network. If no DHCP server is available, clients cannot initialize TCP/IP. The reasons to establish redundancy and the methods for doing so are similar to those in a simple network, but are complicated by the presence of multiple subnets and routers.
If for one reason or another you are unable to provide redundancy on a particular subnet - perhaps one located at a small branch office - consider not using DHCP at all for that subnet. Instead, configure static IP addresses and other TCP/IP parameters for hosts on that subnet, and exclude those addresses elsewhere on your network.
Although DHCP is a broadcast protocol, DHCP normally has little effect on network traffic. DHCP traffic occurs on the network in the following situations:
In the ordinary course of events, therefore, DHCP traffic can usually be safely ignored for planning purposes. At least one exception exists, however. Some networks have many clients that are started almost at the same time - usually at starting time and right after lunch. When this occurs, the network may be very heavily loaded, particularly if clients are configured to download profiles or start applications from a network drive.
We have seen Ethernet utilization climb above 95% in situations like this, which means that almost no traffic is getting through due to all the collisions. In such a situation, not only may DHCP be unable to function, it may actually add to the problem because of re-broadcasts by DHCP clients that are unable to obtain a response. In the worst-case scenario on a very heavily loaded network, a DHCP client may require literally minutes to boot (in approximately 5 minute increments because of the 5 minute timeout retry period).
Of course, this is not really a DHCP traffic issue so much as it is a philosophical one. The solutions are either to leave your client computers running all the time (which is probably a good idea anyway), or to subnet the network and install as many additional DHCP servers as are necessary to ensure acceptable response time to DHCP client requests. Using either solution also makes the DHCP boot-time problem go away.
The Microsoft DHCP Server allows you to define DHCP options globally, for a specified scope, or for an individual client. DHCP option values defined specifically for a client override values for the same option defined at the scope level, and values defined at the scope level override those defined at the global level.
Defining DHCP options in a complex network requires some thought. Defining the scope for a DHCP Server on a local subnet defines the required DHCP options - IP address range and subnet mask - for hosts on that subnet. If hosts on that subnet are to be able to communicate outside the subnet, you must also define a default gateway with the 003 - Router DHCP option.
Beyond this, things get a little hazy. If that DHCP Server is supporting only clients on its local subnet using a single scope, it makes little difference whether you define DHCP options at the scope level or the global level. If that DHCP Server is also supporting clients on other subnets - either as the primary or backup DHCP Server - you have to consider which options need to be defined globally and which for the local subnet only.
For example, if your company has only one DNS Domain Name, you might define 015 - Domain Name globally, because clients on all subnets that use this DHCP Server will use the same domain name, so all scopes should inherit it from Global DHCP options. Conversely, if the DHCP Server supports multiple scopes that map to different subnets, you would have to define the value for 003 - Router at the scope level.
In conjunction with this, you must coordinate scopes between the subnets. For example, assume that you have two DHCP Servers, A and B. Each is the primary DHCP Server for its own subnet. DHCP Server A serves subnet 192.168.115 and DHCP Server B serves subnet 192.168.116. However, you would also like DHCP Servers A and B to back each other up. This means that you need to define two scopes on each server, and that you must reserve a portion of the available IP address range on each subnet to be defined as the secondary scope on the server on the other subnet.
For example, on DHCP Server A you might define a primary scope that encompassed 192.168.115.1 through .175, reserving the remaining addresses for DHCP Server B. On DHCP Server B, you might define a primary scope that encompassed 192.168.116.1 through .175, reserving the remaining addresses for DHCP Server A. You would then define the secondary scopes - 192.168.116.176 through .254 on DHCP Server A and 192.168.115.176 through .254 on DHCP Server B.
Installing the DHCP Server Service
To install the DHCP Server service, take the following steps:
|
|
You can also control the DHCP Server service from the command prompt, using the commands net start dhcpserver , net stop dhcpserver , net pause dhcpserver , and net continue dhcpserver . These commands are useful primarily for creating batch files to backup your server, including the DHCP Server database, during off hours. You can stop the DHCP Server service, run the backup, and then restart the DHCP Server service, all from within a batch file.
For more extensive command-line control, use the dhcpcmd utility included in the Windows NT Server Resource Kit. This program allows you to perform numerous tasks related to managing your DHCP Server, including: adding additional IP address ranges to an existing scope; adding a reserved IP to an existing scope; listing IP lease information in detailed form, optionally including hardware information; displaying DHCP Server statistics; and displaying and setting DHCP Server parameters.
Installing and Configuring the DHCP Relay Agent
You install the DHCP Relay Agent, like other Windows NT services, from the Services pages of the Control Panel Network dialog. To install it, right click the Network Neighborhood icon on your desktop to display the context-sensitive menu and choose Properties to display the Network dialog. Display the Services page and choose Add. Windows NT builds a list of available network services and displays the Select Network Service dialog. Highlight DHCP Relay Agent and then choose OK to install it. As usual, you need to restart the server before the changes take effect.
Once the DHCP Relay Agent is installed, you can configure it from the DHCP Relay page of the Microsoft TCP/IP Properties dialog, shown in figure 6-2. To view this page, display the Network dialog, click the Protocols tab, highlight TCP/IP Protocol, and choose Properties to display the Microsoft TCP/IP Properties dialog.
|
|
To enable DHCP Relay, you must enter the IP address of at least one DHCP Server. To do so, choose Add to display the DHCP Relay Agent dialog, enter the IP address, and choose Add. Windows NT copies the address to the DHCP Servers pane. To edit or remove the IP address for a DCHP server, highlight it in the DHCP Servers pane and choose Edit or Remove.
The only remaining configuration steps are to set values for Seconds threshold and Maximum hops. The Maximum hops value controls the maximum number of times a DHCP packet can be relayed, and is analogous to setting the maximum number of router hops in RIP. The Seconds threshold value requires a bit more explanation.
A DHCP client sets the seconds field in the first DHCP packet to zero, and increments this value by one for each subsequent packet it retransmits. The setting of the Seconds threshold field controls whether or not the DHCP Relay agent forwards a received packet to the remote DHCP Server. The DHCP Relay agent compares the value in the seconds field of DHCP packets it receives against the value set for Seconds threshold. If the seconds field in the packet is less than the Seconds threshold value, the DHCP Relay Agent discards the packet. If the seconds field in the packet is greater than or equal to the Seconds threshold value, the DHCP Relay agent forwards it to the DHCP Server on the remote subnet.
Setting a non-zero value for Seconds threshold allows local DHCP Servers time to respond before the DHCP Relay Agent forwards a DHCP request to a DHCP Server located on a remote subnet. Allowing the local DHCP Server the first shot at responding to local DHCP clients greatly reduces the number of DHCP packets that are forwarded to remote subnets.
The value for Seconds threshold is set to 4 by default, which is the value Microsoft recommends. However, implicit in this recommendation is the assumption that there is a local DHCP Server. If this is the case, 4 is a reasonable value. If there is no local DHCP Server, you are depending entirely on the DHCP Relay Agent to service DHCP clients on the local subnet. In this situation, you could set the Seconds threshold value to zero to ensure that all DHCP request packets will immediately be relayed to the remote DHCP Server.
Needless to say, however, depending exclusively on remote DHCP Servers via the DHCP Relay Agent is a risky business. If your communications link goes down, local clients will be unable to boot. The DHCP Relay Agent is really intended as a means to provide secondary DHCP services for redundancy in a routed network. Rather than use it as the primary provider of DHCP services, you should install DHCP Server and define a DHCP scope on the local subnet.
Managing DHCP with DHCP Manager
After you have installed the DHCP Server Service, you use DHCP Manager to configure and manage it. Before the DHCP Server can support clients, you must complete the initial configuration steps described in the following section. After you have configured the DHCP Server, you can use DHCP Manager to reconfigure the DHCP Server as necessary, and routinely to view the status of the DHCP Server and DHCP clients.
After you have installed the DHCP Server and restarted the server, the next step is to define a DHCP scope. The DHCP scope determines the range of IP addresses that will be available for assignment to DHCP clients, and specifies other IP configuration information. To define a DHCP scope, proceed as follows:
|
|
You may repeat the process to exclude additional ranges, if necessary. You may also exclude a single IP address by entering its value in the Start Address field, leaving the End Address field blank, and clicking Add. Ordinarily, the only reason to use more than one exclusion range is to accommodate existing hosts that require static IP addresses, and whose current addresses you do not wish to change. In the example, we reserve the IP addresses in the range 172.16.30.200 through 172.16.30.254 inclusive.
Either method of restricting the number of addresses assigned to the pool works, at least until you need more pooled addresses. If you defined a small DHCP scope, you must remove the existing scope and create a new one, not something to be undertaken lightly on a production server. If you instead used exclusions to limit the number of pooled addresses, you can simply reduce the size of the excluded range in the existing DHCP scope, which automatically increases the number of available pooled addresses on the fly.
When working with C-block size network addresses, the common convention is to assign the host address 200 to the router for that subnet. Most administrators define the DHCP scope to include the entire C-block, and then exclude host addresses 200 through 254, reserving that range for routers, servers, RAS adapters, and other devices that require static addresses.
Enter a Name, and optionally a Comment, to identify the DHCP scope. Click OK to create the new scope. DHCP Manager displays a message to inform you that the new scope has been created but has not yet been activated. Click Yes to activate the new scope.
To define a DHCP superscope, take the following steps:
Before the DHCP Server can support clients properly, you must first set various DHCP Options. You can do so by choosing one of the following options from the DHCP Options menu of DHCP Manager:
Which DHCP Options need to be set depends upon your own environment. At a minimum, you should configure the following DHCP Options:
If you are running Windows Internet Naming Service (WINS) servers, you should also define the following two DHCP Options, which are further explained in Chapter 7, Using Windows Internet Name Service :
To set the DHCP Options required for minimum TCP/IP connectivity, proceed as follows:
|
|
You may repeat this procedure to enter IP address values for additional routers. However, only the first value listed will be used (as the default gateway) unless the server listed as the default gateway fails or is otherwise unavailable. If this occurs, the second address listed will be used as the default gateway, and so on. Use the up and down arrows to rearrange IP addresses so that the host you want to use as your default gateway is shown first. Click OK to save your changes and return to the DHCP Options: Scope dialog. The Active Options pane now displays 003 Router with the IP address you assigned showing in the lower pane.
You can use DHCP Manager to configure static TCP/IP configuration information for a specific client, which is called making a client reservation . To add a client reservation, take the following steps:
|
|
You can use DHCP Manager to view or delete active leases for ordinary DHCP clients and to view, modify, or delete active leases for Reserved DHCP clients. The options you have available depend on the type of DHCP client that is selected.
Viewing and Deleting Active Leases for Ordinary DHCP Clients
To work with an ordinary DHCP client - one that is assigned its TCP/IP configuration information dynamically by the DHCP Server - take the following steps:
|
|
Viewing, Modifying, and Deleting Active Leases for Reserved DHCP Clients
To work with an reserved DHCP client - one for which you have created a manual reservation - take the following steps:
|
|
Information about active DHCP leases is stored in both the DHCP database and the Registry of the machine running the DHCP Server service. For a variety of reasons, it is possible that the information stored in these two locations will become unsynchronized. The Registry may show one or more IP addresses as leased, or in use, while the DHCP database shows that these same addresses are available for assignment.
If this occurs, you can use the following procedure to run a consistency check between the two databases. Running this procedure lists inconsistent IP address assignments, and reconciles the actual state of the DHCP environment - as reflected in the DHCP database - with the incorrect information maintained by the Registry. To reconcile leases, take the following steps:
Run this reconciliation procedure any time the server crashes. You should also run it each time you restore the DHCP databases from backup. Reconcile is nondestructive. You may run it any time to ensure that the DHCP database and the Registry are in sync. Microsoft recommends doing so routinely. Some administrators do so for the warm, fuzzy feeling, but if you have several scopes, reconciling frequently is time consuming and provides little benefit.
Once it has been installed and configured correctly, the DHCP Server requires little routine maintenance, and is unlikely to have many problems. However, Murphy's Law still applies, so let's look at some of the problems that can occur with DHCP Server and how to go about resolving them. One of the following problems will likely be your first sign that all is not right with the DHCP Server:
If either of the first two problems occurs, first verify that the DHCP Server service is started. You can do so by running the Services applet from Control Panel. The Status column should report "Started" for both the DHCP Client service and the Microsoft DHCP Server service. If either or both of these services is not running, first attempt to start the service by highlighting its name and clicking Start. If the service starts successfully, verify that the problems you were experiencing have been resolved.
If the third problem occurs, or if you are unable to start the service using the procedure described immediately above, more drastic measures are called for. First, notify everyone that the server is going to be shut down. If your communications problems are severe, or if some of your clients are not running Windows NT or Winpopup.exe , you may have to do this using some other method than a broadcast to clients. Power down the server and allow it to remain down for at least a minute.
Once your drives have all spun down, turn the power back on, and watch the console for warning messages as the server restarts. Most of the time, you will find that the service has started normally. If not, take a club to it. Get to a command prompt, type net start dhcpserver, and then press Enter. The service should start normally. If it doesn't - and I've never had a server that recalcitrant - the next step is to restore the DHCP database from backup.
If the procedures described in the preceding section fail, or if they apparently succeed but the problems persist, the only alternative is to restore the DHCP database from a known-good copy. To restore the DHCP database, take the following steps:
If your DHCP problems arise as a result of hardware problems on the machine running the DHCP Server service, you may have no alternative but to rebuild the DHCP database on another server. To rebuild the DHCP database, take the following steps:
You can also use this procedure if you simply want to remove the DHCP Server from one server and relocate it to another. If you do so, you will find that DHCP Manager still shows the original scope because Registry entries remain on the original server. Run reconcile, as described earlier in this chapter, to remove DHCP lease information from the Registry of the original server.
Dynamic Host Configuration Protocol is used to configure the hosts on a TCP/IP network. DHCP is the configuration service used by Windows NT. It allows the administrator to centrally control all TCP/IP configuration parameters including the IP address. With DHCP, addresses can be dynamically assigned.
The range of addresses that are available for dynamic assignment by a Windows NT DHCP server is called a scope . The scope is configured by the system administrator using the DHCP Manager software. The administrator defines the range of addresses in the scope, those addresses in the range that should be excluded from dynamic assignment, and the length of the time allowed for an address lease.
The DHCP Manager is also used to define DHCP options. DHCP options are the TCP/IP configuration values passed to the client.
In the next chapter we configure another server that is commonly found on a Windows NT network: the Windows Internet Name Service (WINS).
