“U NA ORIENTACIÓN RELACIONAL ”

A multihomed server is a computer that is attached to more than one physical network. This requires the installation of multiple network cards in the server.

A multihomed DHCP server is a server that may be providing the DHCP service on multiple physical networks. Although I personally would not recommend the use of a multihomed DHCP server, it can be used in situations where there are two or more network segments that are not connected via a router, or where the network segments are connected with a router but the router does not have any DHCP relay agent functionality. Both of these situations are extremely unlikely, however. The most likely situation is that where the Windows 2000 server is functioning as both a router and a DHCP server.

By default, when DHCP first starts on a multihomed server, the service binds to the first network interface. If this first network interface has a static IP address (which is required to run a DHCP server), the service binds to that card as normal. However, if the first network interface is using a dynamically assigned IP address, the service does not bind to that interface.

In this case, an administrator needs to either assign static IP addresses or selectively bind the DHCP service to an interface with a static IP address.

I will take a moment to describe another situation where the administrator needs to selectively bind the DHCP service to an interface. Let's say that there is a network with two segments. Both of these segments are connected to a Windows 2000 server that is acting as both an IP router and a DHCP server. The first segment contains Windows 2000 Professional workstations. These workstations are using the DHCP service to obtain their IP address configurations. The second segment contains network devices that rely on a BOOTP server. The BOOTP server is located on the second segment. By default, the DHCP service is bound to both network segments. Since both BOOTP and DHCP use the same UDP ports for their conversations (67 and 68), they cannot both be running on the same segment. If they did, some of the network devices would get their configurations from the BOOTP server and the others from the DHCP server. In this case, the administrator should unbind the DHCP service from the network interface that is connected to the BOOTP segment.

You can use the following Netsh command to view the binding on a multihomed DHCP server:

D:\>netsh dhcp server show bindings

Binding information : 0

========================================================================= Bound To Server : TRUE

Adapter Primary Address : 10.0.0.10 Adapter Subnet Address : 255.0.0.0

Interface Description : Local Area Connection 2 Interface ID : E3665B450D7DAC4B8633D464055B5352

========================================================================= Binding information : 1

========================================================================= Bound To Server : TRUE

Adapter Primary Address : 192.168.0.10 Adapter Subnet Address : 255.255.255.0

Interface Description : Local Area Connection Interface ID : C4D2C67C6DC86A4DADE24D9EABDA00F3

========================================================================= Command completed successfully.

To modify the bindings, follow these steps: 1. Open the DHCP console.

2. Right-click on the DHCP server. Select Properties.

3. The Properties dialog box is displayed. Select the Advanced tab. 4. On the Advanced page, click on the Bindings button.

5. The Bindings dialog box is displayed (see Figure 7.6). Any connections selected (or checked) are interfaces that are bound to the DHCP server. Uncheck an interface to

Figure 7.6. Modifying the bindings on a DHCP server

6. Click OK to apply the settings.

7. Click OK to close the Properties dialog box.

Once finished, you can use the same Netsh command (netsh dhcp server show bindings ) to verify that the bindings have been changed.

Using a multihomed DHCP server may be more trouble than it's worth. It can be difficult to troubleshoot and maintain. However, if cost is an issue and you are planning to use Windows 2000 as an IP router, this gives you a low cost alternative. Just remember that you have options when it comes to binding the DHCP service to the network segments you desire.

7.5 The DHCP Database

The DHCP database is the most critical component in a DHCP infrastucture. Each DHCP server maintains its own database. This database contains the server's current configuration, such as scopes, reservations, exclusions, options, and so on, as well as active leases.

The DHCP database found in Windows 2000 uses the Exchange Server Storage engine v4.0. The files that make up the DHCP database are located in the directory %systemroot%\system32\dhcp. They are listed and described in Table 7.2.

Table 7.2. DHCP Database Files

File Description

DHCP.MDB The DHCP database file.

DHCP.TMP A swap file used by the database during maintenance operations.

J50.LOG A transaction log detailing database activity. These log files are used to recover the database in the _{event of a failure.} J50.CHK A checkpoint file.

The DHCP database is backed up automatically every 15 minutes by default. By editing the following registry key, this interval can be changed:

HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\BackupInterva l

The location of the backup copy of the DHCP database located in the directory %systemroot%\system32\dhcp\backup by default. The location can be changed by editing the following registry key:

HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\BackupDatab asePath

You can force a backup copy of the database to be created by stopping and restarting the DHCP service.

7.5.1 Compacting the DHCP Database

The size of the DHCP database is proportional to the number of DHCP clients that the DHCP server is servicing. As such, there is no limitation on the number of entries the database may contain. The database will continue to grow as DHCP clients activate and release leases. Since the database continues to grow and not contract, the DHCP database must be compacted periodically to recover unused space. This unused space occurs as DHCP clients release their leases or their leases expire.

There are two methods of compacting the DHCP database: dynamic and offline.

Dynamic compacting occurs automatically as a background process during idle time. When the DHCP server does not have any updates to perform on the DHCP database, it starts to compact the database.

Offline compacting is more appropriate for DHCP databases on very large and busy networks. Since the database is constantly being updated, the DHCP server does not have the idle time available to do a dynamic compact. Offline compacting is recommended for DHCP databases that have grown beyond 30 MB in size. The utility that performs an offline compaction is called Jetpack.

The syntax for Jetpack is:

jetpack <database_name> <temporary_database_name> database_name

Specifies the name of the original DHCP database file temporary_database_name

Specifies the name of the file that Jetpack will copy the database information to during the compaction

For offline compacting, the DHCP service must be stopped. To stop the DHCP service, go to Start Programs Administrative Tools Computer Management. In the left-hand pane, select Services and Applications, then double-click Services in the right-hand pane. In the list of services, find DHCP Server. Right-click on DHCP Server and select Stop. In a few seconds the DHCP Server service stops.

Another method of stopping the DHCP Server service is by opening a command prompt by selecting Start Run and entering cmd . Type net stop dhcpserver to stop the service. Next, change to the location of the DHCP database files. At the command prompt type cd %systemroot%\system32\dhcp .

Type jetpack dhcp.mdb tmp.mdb .

Jetpack now compacts the database. First, Jetpack copies the DHCP database information to the temporary file tmp.mdb. After copying the information, Jetpack deletes the original database file dhcp.mdb. Finally, it renames the temporary database file, tmp.mdb, to the original file, dhcp.mdb.

When Jetpack is finished, the DHCP Server service can be restarted. At the command prompt type net start dhcpserver .

You have now performed an offline compaction of the DHCP database.

Offline compacting is usually very fast (within a minute or so), even on DHCP servers that service many DHCP clients. If you find that offline compacting is taking an extended period of time, you can create a batch file that stops the DHCP service, compacts the database, and restarts the DHCP service once complete. This batch file can then be scheduled to execute at a time when there is less network activity, such as 3:00 A.M.

7.5.2 Backing Up and Restoring the DHCP Database

If the DHCP database has been corrupted or lost, there are a few steps that can be performed to recover and restore the DHCP service.

First, determine whether data has been lost or corrupted. If data has been lost or corrupted, check to make sure that it is not related to a hardware or software fault, such as a disk drive failure. Another possibility is that the server may have run out of disk space. In that case, the server will not be able to write changes to the database as it services DHCP clients.

Data corruption can also be detected by examining the System event log for JET database errors. Table 7.3 lists the JET database errors that are generated when database corruption has occurred.

Table 7.3. Jet Database Errors

Event ID Source Description

1014 DhcpServer The JET database returned the following error: -510. 1014 DhcpServer The JET database returned the following error: -1022. 1014 DhcpServer The JET database returned the following error: -1850.

Once it has been determined that corruption has taken place, perform an offline compaction using the Jetpack utility as demonstrated earlier in this chapter.

If the offline compaction fails to correct the data corruption, the database will need to be completely restored.

The first option in restoring the database is to restore the DHCP database files from an offline source, such as the latest tape backup.

Another option is to use the Netsh set databaserestore flag command. This flag tells the DHCP server to load the database files from the backup database location.