This chapter is from the book
This chapter is from the book
This chapter is from the book
Troubleshooting DHCP
Although DHCP is typically one of the easiest of the common network services to configure and maintain, from time to time, you might encounter problems. More often than not, the DHCP-related problems that arise stem from a misconfiguration in a scope, unauthorized DHCP servers on the network, or network connectivity problems. You might also find information that has changed in some way, but the change has not been reflected in your DHCP configuration, as in the case of DHCP reservations (which are tied to MAC addresses) or a DHCP server's IP address change. The following sections examine some troubleshooting tasks you can do to quickly determine the cause of DHCP woes and get this vital network service back into proper operation.
Troubleshooting DHCP Server Authorization Problems
As discussed previously, one of the first indicators you might see of an unauthorized or rogue DHCP server is an unexpected increase in the number of DHCPNACK messages. You can monitor this statistic over time by using the Performance console. The Performance console includes several counter objects that you can use to monitor and troubleshoot your DHCP server:
- Acks/Sec—This counter monitors the number of DHCPACK messages sent per second by the DHCP server to client computers. The DHCP server uses the DHCPACK messages to acknowledge requests for an address. An increase in this number indicates that a large number of client computers are probably trying to renew their leases with the DHCP server. This could be because of a short lease time configuration or because a number of new computers are entering the network.
- Active Queue Length—This counter monitors the current length of the internal message queue of the DHCP server. This number represents the number of unprocessed messages received by the server. A large number here could indicate an unusually large amount of network traffic or a heavy load on the server.
- Conflict Check Queue Length—This counter monitors the current length of the conflict check queue for the DHCP server. Before a Windows Server 2003 DHCP server issues an address, it checks whether any IP address conflicts exist. The conflict check queue holds the messages not responded to while the DHCP server performs address conflict detection. A large value here could indicate heavy lease traffic at the server. You might also want to check the Conflict Detection Attempts parameter, which could be set too high.
- Declines/Sec—This counter monitors the number of DHCPDECLINE messages that the DHCP server receives per second from client computers. This counter indicates that the DHCP client computer has declined the IP address issued by the server. You see this number rise when client computers start having address conflict problems, and it could indicate a network problem, computers with static addresses also being part of a scope, or a rogue DHCP server on the network.
- Discovers/Sec—This counter monitors the number of DHCPDISCOVER messages received per second by the server. The DHCPDISCOVER message is the initial request a client computer sends when it first enters the network and looks for a DHCP server to issue an address. A sudden increase in this counter could indicate that a large number of client computers are attempting to initialize and obtain an IP address lease from the server at the same time. You might see this first thing in the morning, when users power on their PCs, or after a power failure, when all the PCs might be powered on at about the same time.
- Duplicates Dropped/Sec—This counter monitors the number of duplicate packets per second dropped by the DHCP server. Duplicate packets on a network are never a good sign, and they can indicate that DHCP clients are timing out before the server can respond. This can be caused by client computers timing out too fast or the server not responding quickly enough.
- Informs/Sec—This counter monitors the number of DHCPINFORM messages received per second by the DHCP server. DHCPINFORM messages are used when the DHCP server queries the directory service for the enterprise root and when dynamic updates are being done on behalf of client computers by the DNS server. This is part of the DDNS integration, and an unusual increase in this number could indicate a large number of addresses being issued.
- Milliseconds Per Packet (Avg)—This counter monitors the average time, in milliseconds, the DHCP server takes to process each packet it receives. This is a very subjective number that depends on the server configuration; therefore, having a baseline for this number is a good idea. A sudden increase in this counter could indicate a disk problem or an increased load on the server.
- Nacks/Sec—This counter monitors the number of DHCP negative acknowledgment (DHCPNACK) messages sent per second by the DHCP server to client computers. A DHCPNACK message indicates that the server cannot fulfill the DHCP request. A very high value for this counter could indicate a network problem or a misconfiguration of client computers or the server. Watch for a deactivated scope as a possible culprit.
- Offers/Sec—This counter monitors the number of DHCPOFFER messages that the DHCP server sends per second to client computers. A DHCPOFFER message is the message the server returns to the client computer after the client computer sends a DHCPDISCOVER message, and it indicates that the server is offering to issue an address to that client computer. A sudden increase in this value could indicate heavy traffic or a heavy load on the server.
- Packets Expired/Sec—This counter monitors the number of packets per second that expire and are dropped by the DHCP server. This situation is caused by a packet remaining in the server's internal message queue too long. A large number for this counter indicates that the server either is taking too long to process some packets or is causing other packets to wait in queue, or that the traffic on the network is too heavy for the DHCP server to handle. It is important to note that high numbers for this counter can indicate pure network traffic problems and not necessarily DHCP-related problems.
- Packets Received/Sec—This counter monitors the number of message packets received per second by the DHCP server. A large number indicates heavy DHCP message traffic to the server. These message packets might be requests for addresses, renewals, or releases.
- Releases/Sec—This counter monitors the number of DHCPRELEASE messages that the DHCP server receives per second from client computers. A DHCPRELEASE message is sent only when the client computer manually releases an address, such as when the ipconfig /release command is used or the Release All button in the winipcfg utility is used at the client computer. Because most users do not manually release their addresses, this number should be low in all but the most unusual network environments.
- Requests/Sec—This counter monitors the number of DHCPREQUEST messages that the DHCP server receives per second from client computers. These messages are the requests that the client computer sends to request an IP address after it has found a server that can issue addresses. An increase in this number indicates that a large number of client computers are probably trying to renew their leases with the DHCP server. This could be caused by a short lease time configuration or by a number of new computers entering the network.
Configuring the Performance console to monitor and collect data about a DHCP server is a simple process, as outlined in Step by Step 3.7.
Step By Step 3.7: Monitoring DHCP Performance
- Select Start, Program, Administrative Tools, Performance to open the Performance console.
- Click System Monitor, as shown in Figure 3.34.
Figure 3.34 You can view server performance statistics by using the Performance console.
- To create an entry in System Monitor, click the + icon. The Add Counters dialog box shown in Figure 3.35 opens, enabling you to begin adding counters.
Figure 3.35 You can add counters to begin monitoring DHCP server statistics.
- Select the DHCP Server performance object in the Performance object drop-down list box. You then see the list of counters available for selection that relate to the DHCP service. If you need to know what a counter means, select the counter and click the Explain button.
- When you have decided what counter you want to monitor, click Add. You can add multiple counters either by selecting each counter and clicking Add or by holding down the Ctrl key while you select all the counters you want to monitor and then clicking Add. Click Close when you are finished. Your counters are graphed like those shown in Figure 3.36.
)
)
)
Figure 3.36 You can monitor DHCP server statistics in real time.
If you notice a trend of higher-than-normal DHCPNACK messages, you need to determine the source. The most common cause is a rogue DHCP server that has been set up on the network. You can also examine the DHCP lease properties of clients to determine whether any of them have different information than what you have configured in your DHCP scopes.
It's important to remember that Windows 2000 and Windows XP clients in an Active Directory environment that are configured to use DHCP do not accept leases from unauthorized DHCP servers. Older clients accept these leases and can contribute to the number of DHCPNACK messages when they attempt to renew their DHCP leases.
You can also examine the DHCP server daily audit logs, located in the %systemroot%\ sysytem32\dhcp folder, to look for rogue-detection events. The DHCP audit logs are discussed in the next section.
Using the DHCP Logs
The DHCP server daily audit logs are often overlooked as a valuable source of information. You have learned how to enable the audit logs; now let's look at what they contain. Unlike the logs the Windows 2000 Server DHCP service produces, the Windows Server 2003 daily audit logs are natively in text format; you open them simply by double-clicking them. A sample of what you might expect to find in a log is displayed here:
ID,Date,Time,Description,IP Address,Host Name,MAC Address
00,04/27/06,20:08:38,Started,,,,
55,04/27/06,20:08:39,Authorized(servicing),,lab1.area51partners.com,,
24,04/27/06,20:44:10,Database Cleanup Begin,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
25,04/27/06,20:44:10,0 leases expired and 0 leases deleted,,,,
24,04/27/06,21:44:12,Database Cleanup Begin,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
25,04/27/06,21:44:12,0 leases expired and 0 leases deleted,,,,
11,04/27/06,19:39:46,Renew,192.168.0.231,
xpclient01.corp.quepublishing.com,00E07DC13E70,
31,04/27/06,19:39:46,DNS Update Failed,
192.168.0.231,xpclient01.corp.quepublishing.com,-1,
10,04/27/06,19:43:07,Assign,192.168.0.230,
iMac01.corp.quepublishing.com,00306509D772,
30,04/27/06,19:44:14,DNS Update Request,192.168.0.231,
xpclient01.corp.quepublishing.com,,
31,04/27/06,19:44:14,DNS Update Failed,192.168.0.231,
xpclient01.corp.quepublishing.com,-1,
30,04/27/06,19:47:03,DNS Update Request,192.168.0.231,
xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
xpclient01.corp.quepublishing.com,00E07DC13E70,
30,04/27/06,19:47:03,DNS Update Request,
192.168.0.231,xpclient01.corp.quepublishing.com,,
11,04/27/06,19:47:03,Renew,192.168.0.231,
xpclient01.corp.quepublishing.com,00E07DC13E70,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
xpclient01.corp.quepublishing.com,,
32,04/27/06,19:47:03,DNS Update Successful,192.168.0.231,
xpclient01.corp.quepublishing.com,,
As you can see from this example, the DHCP server cleans up the database hourly. You can also see that two clients requested leases. One of them, an Apple iMac, requested and was assigned the IP address 192.168.0.230, with no further actions. Another client, a Windows XP Professional computer, requested and received the IP address 192.168.0.231, with several failed DNS updates (evidenced by ID 31). After the DNS dynamic update account was properly configured, the DHCP server was able to make the DNS dynamic updates and generate an ID of 32. Table 3.3 explains the ID codes used in the DHCP daily audit logs.
Table 3.3. The DHCP Daily Audit Log ID Codes
|
ID |
Description |
|
00 |
The log was started. |
|
01 |
The log was stopped. |
|
02 |
The log was temporarily paused due to low disk space. |
|
10 |
A new IP address was leased to a client. |
|
11 |
A client renewed a lease. |
|
12 |
A client released a lease. |
|
13 |
An IP address was found to be in use on the network. |
|
14 |
A lease request could not be satisfied because the scope's address pool was exhausted. |
|
15 |
A lease was denied. |
|
16 |
A lease was deleted. |
|
17 |
A lease was expired. |
|
20 |
A BOOTP address was leased to a client. |
|
21 |
A dynamic BOOTP address was leased to a client. |
|
22 |
A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted. |
|
23 |
A BOOTP IP address was deleted after a check was made to see that it was not in use. |
|
24 |
The IP address cleanup operation has begun. |
|
25 |
IP address cleanup statistics are provided. |
|
30 |
A DNS update request to the named DNS server was made. |
|
31 |
The DNS update failed. |
|
32 |
The DNS update was successful. |
|
50+ |
These IDs are used for Rogue Server Detection information. |
In addition to the DHCP daily audit logs, events related to the DHCP service are generated and placed in the system log, as shown in Figure 3.37.
)
Figure 3.37 The system log contains events related to the DHCP service.
As you can see in Figure 3.38, a DHCP server on the network has not been authorized in Active Directory. The system log contains many useful log events about all aspects of a server, and this is an area you should review often.
)
Figure 3.38 An unauthorized DHCP server cannot start the DHCP service.
Troubleshooting DHCP Reservations
For the most part, the only problem that prevents a DHCP reservation from functioning properly is a misconfigured MAC address. If you have a misconfigured DHCP reservation, it should show up in the Address Leases node of your DHCP server with the status Reservation (Inactive). Reservations that are configured properly show the status Reservation (Active). If you look back at Figure 3.16, you'll see that the reservation we created had a bad MAC address and, thus, was the cause of the problem in Figure 3.39.
){kind=link}
)
Figure 3.39 A DHCP reservation that is not active usually indicates a misconfiguration.
To verify that a reservation is configured properly, you can compare the MAC address of the component that is to have a reserved DHCP address (a print server, for example) to the MAC address entered in the reservation Properties dialog box. The vast majority of the time, this will reveal the source of the problem.
Troubleshooting the DHCP Relay Agent
The DHCP relay agent, like a DHCP reservation, typically doesn't present a problem. However, in some cases, relay services are not being provided to network clients. Some of the most common problems that you might encounter with the DHCP relay agent include the following:
- The network interface on the DHCP relay agent server that is connected to the subnet where the DHCP clients are located has not been selected for use with the DHCP relay agent. You can verify whether the interface has been added or add it from the DHCP Relay Agent node of the DHCP console. You should also verify that the Relay DHCP Packets check box is selected on all adapters that have been selected for use.
- An incorrectly entered DHCP server IP address on the DHCP Relay Agent Properties dialog box (refer back to Figure 3.32) prevents the successful relay of packets. You can verify and correct this problem from the properties dialog box of the DHCP Relay Agent node of the DHCP console.
- Remote DHCP servers might not be reachable because of network or server problems. In this case, you need to troubleshoot basic network connectivity, as discussed in Chapter 1, "Planning, Implementing, and Troubleshooting a TCP/IP Network Infrastructure". You should troubleshoot the server status as discussed in this chapter.
- DHCP traffic might be being filtered. In this case, you need to ensure that no IP filters exist for UDP ports 67 and 68 at any point between the DHCP servers and the remote DHCP clients.
){kind=link}