Windows Server 2003 : Troubleshooting DHCP (part 1) - Verifying the Client Configuration

Verifying the Client Configuration

One of the first signals of a DHCP failure appears either when a client loses connectivity to network resources or when a new client cannot establish such connectivity in the first place. In these cases, you need to determine whether the problem originates on the client or elsewhere.

Begin by using the Ipconfig command to determine whether the DHCP client has received an address lease from the DHCP server. If so, the Ipconfig /all output shows that DHCP is enabled, and the IP address is described as an “IP Address” and not an “Autoconfiguration IP Address.” Alternatively, you can check the address type listed on the Support tab of the status dialog box for the connection. You open this dialog box, shown in Figure 1, by double-clicking the relevant connection in the Network Connections window. When the IP address has been assigned by a DHCP server, the address type is described on the Support tab as Assigned By DHCP.

If the client has been assigned by DHCP an address that is compatible with the rest of the network, and no warning messages have appeared about address conflicts, you can assume that the network problem does not result from an addressing error on the local client.

Address Conflicts

If a client computer has been assigned an address in use by another computer on the network, a warning message informing you of this conflict appears in the system tray. You can also learn about such address conflicts in the System log, which you can access through Event Viewer. Figure 2 shows this type of warning message.

When you receive a warning message about an address conflict, and when you can verify that the client has received its IP configuration from a DHCP server, this conflict can be a sign of competing DHCP servers or of a sudden DHCP scope redeployment.

To check for competing DHCP servers, you can use the Dhcploc.exe utility (included in Windows Support Tools) to locate rogue DHCP servers on the network. After removing rogue servers as needed, verify that no two remaining DHCP servers can issue address leases from the same address range.

To recover gracefully from a scope redeployment, first increase the conflict detection attempts on the server and then renew client leases. To renew a client lease, use either the Ipconfig /renew command or the Repair button in the relevant connection’s status dialog box. If you need to renew many leases, you can use the Shutdown /i command to restart multiple remote computers.

Failure to Obtain a DHCP Address

When the Ipconfig /all command output or the connection status dialog box reveals that the client address is assigned by APIPA or by an alternate configuration, you can first attempt to refresh the IP configuration by using either the Ipconfig /renew command or the Repair button in the connection’s status dialog box.

If the problem persists, this situation can signal either the absence of a DHCP server or relay agent deployed within broadcast range, a break in the physical connection, or an error at the DHCP server or scope. If you can verify that a DHCP server or relay agent is deployed within broadcast range, verify next that the physical connection to the DHCP server or relay agent is functioning properly. Note that to ping the DHCP server or relay agent successfully, you might need to assign a temporary manual address that places the client on the same logical subnet as its default gateway.

Once you can rule out problems in physical connectivity, and if you can rule out problems in the configuration or status of the DHCP relay agent (if deployed), you can move on to troubleshoot the DHCP server and scope. When troubleshooting the DHCP server for the client’s failure to obtain an IP address, verify that the server is fully installed, configured, and authorized. When troubleshooting the scope for the client’s failure to obtain an IP address, verify that the scope is active and that the available leases have not all been assigned to other clients. (See the “Verifying the Server Configuration” section later in this lesson for more information on troubleshooting these problems at the server and scope.)

Address Obtained from Incorrect Scope

If the Ipconfig /all command output or the connection’s status dialog box reveals that the client has obtained an address from a DHCP server, and you determine that this address belongs to an incorrect scope, first verify that no competing servers exist on the network. To assist in this task, you can use the Dhcploc.exe utility to determine whether rogue servers are distributing IP addresses. If no rogue servers exist, verify that all DHCP servers authorized on the network are leasing from distinct address ranges. No overlap in leasable address space should exist among active DHCP servers.

The correct DHCP server might also have supplied an address from an incorrect scope. Multiple scopes can be active on a single DHCP server; scopes not native to the server’s own subnet are used for remote clients. However, the DHCP server can match remote clients to the proper scope only when the RFC 1542–compliant router or DHCP relay agent through which the client communicates is properly addressed. In this scenario, when a remote client is assigned an incorrect address by the DHCP server, verify that the DHCP relay agent or router forwarding DHCP messages is itself correctly addressed.

Note

DHCP: Relay IP Address (giaddr) = 192.168.2.1