Troubleshooting DHCP Client Problems
Articles and Tips: article
Proactive Resolution Team
Novell Worldwide Support
ncashell@novell.com
24 Mar 2000
Note: You can read this article in conjunction with Ken Nielson's "Introducing the DHCP Client for NetWare" that appears in the Tips and Tricks section of the April 2000 NetNotes. Where that article gives an overview of how the DHCPCLNT.NLM works and its syntax, this one provides a brief DHCP (Dynamic Host Configuration Protocol) theory of operations and presents basic steps for troubleshooting the DHCP Client for NetWare.
DHCP Theory of Operation
When a DHCP device attaches itself to the network for the first time, it broadcasts a DHCPDISCOVER packet. A DHCP server on the local segment will see the broadcast and return a DHCPOFFER packet that contains an IP address, along with other information. The servers may also conduct some sort of preliminary testing prior to offering the IP address, such as generating an ARP (Address Resolution Protocol) or an ICMP (Internet Control Message Protocol) echo to see if the address is already in use by another node. (If your network does not have a DHCP server on every segment, you will need to configure your routers to provide BOOTP relay agents that forward the broadcasts to a predefined server on a remote segment.)
The DHCP client may receive multiple DHCPOFFER packets from any number of servers, so the client must choose between them and broadcast a DHCPREQUEST packet that identifies the explicit server and lease offer that it likes the best. This decision may be based on which offer has the longest lease, or which offer provides the most information that the client needs for optimal operation (more on this later). The non-chosen servers would notice the explicit DHCPREQUEST packet from the client and go about their business.
Assuming that the offer is still valid, the chosen server would return a DHCPACK that tells the client the lease is finalized. If the offer is no longer valid for some reason-perhaps due to a time-out or to another client allocating the lease-then the selected server must respond with a DHCPNAK message. This would cause the client to send another DHCPDISCOVER packet, starting the process over again.
Once the DHCP client receives a DHCPACK from the DHCP server, all ownership and maintenance of the lease is the responsibility of the client. For example, a client may refuse an offer that is detailed in the DHCPACK message, and it is the client's responsibility to do so. Clients are supposed to test the addresses that have been offered to them by conducting ARP broadcasts. If another node responds to the ARP, the client would assume that the offered address is in use. At this point, the client would reject the offer by sending a DHCPDECLINE message to the offering DHCP server, and then the client would also send another DHCPDISCOVER packet, thereby starting the process yet again.
Once the DHCP client obtains a lease on an IP address, the lease must be renewed prior to its expiration date through another DHCPREQUEST message. If a client finishes using a lease prior to its expiration date, the client may send a DHCPRELEASE message to the DHCP server so that the address can be made available to other nodes. If the DHCP server doesn't hear from the client by the end of the lease, it marks the lease as expired, and makes the address available for other clients to use.
Basic Troubleshooting for DHCP Client Problems
DHCP Client Cannot Obtain an IP Address from Server. In cases where the DHCP client cannot obtain an IP address from the DHCP server, perform the following troubleshooting steps to identify the problem.
Verify that the DHCP Server is up and running. To do this, check the following:
If a DHCP server exists on the local segment, make sure that the IP interfaces are active, and that the UDP port 68 is registered (DHCP servers listen for requests on this port).
If there is no DHCP server on the local segment, make sure that a relay agent is setup so that the DHCP requests are forwarded to the appropriate DHCP server.
Check that the DHCP Server has available IP addresses to hand out. It could be that the DHCP server has run out of addresses for a specific subnet and a client request for another IP address on that subnet will fail. In most cases, the DHCP server generates warnings or errors when this occurs. Checking the DHCP server logs will confirm the issue.
Check that the DHCP Server does not expect certain tags to be set in the DHCP request. Some ISP's that provide IP addresses to cable modems via DHCP expect the customers host name or customer ID in the incoming DHCP request. If this is the case, make sure that the DHCPCLNT module is loaded with the HOST=<hostname/customer ID> parameter.
Verify that the DHCP server responds to the request and that the DHCP client receives this request. To do this, check the following:
Most DHCP servers can be run in debug mode, which logs information about DHCP requests along with their responses. Check this log to verify that Novell's DHCP client request made it to the DHCP server and that the DHCP server responded. For example, with NetWare 5.x DHCP server, the DHCPSRVR server module can be loaded with a -D1, -D2, or -D3 debug option. Whenever a DHCP event takes place, the information, debug, warning, or error messages are written to the SYS:\ETC\DHCP\DHCP-SRVR.LOG file.
When DHCPCLNT loads, it spawns a "DHCP Client Info Screen" at the server console. This Info screen displays error and warning information whenever it detects a problem, including error checks for resource issues, thread issues, and DHCP protocol issues. Check this screen for possible messages.
Check to see if the NetWare server that is running the DHCPCLNT module has moved to a different subnet. In cases where the NetWare server was moved from one segment to another and IP cannot bind to the LAN card in the new segment, make sure that you execute a LOAD DHCPCLNT -RELEASE command from at the server console so that all information corresponding to the IP address from the old segment is removed.
DHCP Client Cannot Communicate with Hosts
In cases where the DHCP client obtains an IP address but the DHCP server cannot communicate with any hosts, perform the tasks listed below.
Check the DHCP Client Info Screen. This action will help you determine your computer's DHCP assigned TCP/IP settings. With this information, verify that the IP address and subnet mask displayed by the IPCONFIG command are the correct values for your host. Whenever the DHCP Client loads, the client spawns a DHCP Client Info Screen with information about the client. When the DHCP client successfully gets an IP address, it usually displays the following information:
DHCP Client Info Screen
Bound IP to board e100b_eii
Address____ = 1.1.1.3
Subnet Mask = 255.255.255.0
Gateway____ = 1.1.1.254
Domain Name:__ db.mycompany.com
Domain Name Server Addresses
1.1.1.26
1.1.1.1
1.1.1.113
Ping the Loopback_ address (127.0.0.1) to ensure you can get a reply. Failure at this stage would indicate a major problem with the TCPIP.NLM or system resources. Check the available server resources to make sure that there's enough cache memory, and make sure that the number of ECBs (Event Control Blocks) and small ECBs have not hit their maximum. You can up these numbers through the 'SET minimum packet receive buffer' system console set command, or via the MONITOR module (such as MONITOR | SERVER PARAMETERS | COMMUNICATION).
Ping your computer's IP address to ensure you can get a reply. Failure at this stage may indicate a problem between the TCP/IP stack and your network adapter. To correct this problem, remove and reinstall your network adapter driver and verify that the latest driver is being used. If you are running on a switched network, make sure that the LAN driver configuration is Not set to auto detect the speed of the wire and duplex mode settings.
Clear the Address Resolution Protocol (ARP) cache. The address resolution protocol (ARP) cache is a list of recently resolved IP address to Media Access Control (MAC) address mappings. The MAC address is the unique physical address that is embedded in each network adapter. If an entry in the ARP cache is incorrect, IP datagrams may be sent to the wrong computer. To display all mappings that are currently in the ARP cache, use the TCPCON utility at the server console and select the Protocol Information option from the Available Options menu. Select IP, then the IP Address Translations menu and use the <Del> key to delete all entries that are found in the IP Address Translations Table.
Verify the Default Gateway. This can be done by loading the TCPCON utility at the server console and selecting the IP Routing Table | Proceed option from the Available Options menu. This screen will help you to determine whether a 0.0.0.0 entry exists, and that the next hop address corresponds to the correct default route. When you have verified that you do have the correct IP address for your default gateway, use the PING <IP address> command at the server console prompt to verify that you can ping your default gateway's IP address. If your default gateway is not connected to the network or is not functioning properly, the ping request will fail.
Ping the IP address of a remote IP host. If this fails, verify the Route Table Entries by going into the TCPCON utility and using the IP Routing Table | Proceed option. The TCP/IP routing table entries are automatically rebuilt each time the DHCP server host receives a new route that presents a "better cost" than an already existing route. Make sure that no newer routes have been received have overwritten the previous default route. Also, use the IPTRACE command at the server console to trace the route between your system and the remote IP host you are trying to access. If there is a problem with one of the intermediate routers that the network packet tries to cross, you may receive a response similar to the following:
Tracing route to <IP address> over a maximum of 30 hops:
1__ <10 ms__ <10 ms__<10 ms_ <1.1.1.1>
2____ *_______ *_______ *____ Request timed out.
3____ *_______ *_______ *____ Request timed out.
4____ *_______ *_______ *____ Request timed out.
In such cases, try to identify the next hop routes for router 1.1.1.1 and determine why it's failing to register the next hop route. If there is a configuration error on one of the routers between your server computer and the other computer, you may receive a response similar to the following:
Tracing route to <IP address> over a maximum of 30 hops:
1__ <10 ms__ <10 ms__<10 ms_ <###.###.###.###>
2___ 50 ms___ 50 ms___51 ms_ <###.###.###.###>
3_<###.###.###.###>_ reports: Destination net unreachable.
Perform a protocol analyzer trace. In cases where the above suggestions do not resolve the problem, protocol traces will help identify whether the DHCP client is generating the request correctly, or whether a DHCP server is responding with valid information.
Current Known Issues
So far, testing has shown that the DHCPCLNT.NLM utility works with Novell's DHCP server, Microsoft's DHCP server, most DSL (Digital Subscriber Link) and some Road Runner cable modem setups. Due to limited resources, the Novell Support group has not been able to test the DHCP client with very many ISPs, so problems may exist. The DHCPCLNT.NLM utility is only certified to work under NetWare 5.0 and 5.1.
Some of the problems that the NetWare Support Group are aware of include the following:
If the DHCPCLNT is unloaded and reloaded without getting the previously assigned IP address, all connected clients will be disconnected. This is not a limitation of the DHCPCLNT module, but with the TCP protocol. TCP sessions are uniquely represented by the source and destination IP address/port number combination. Should any of these variables change (such as either the source of destination IP address in this case), the session will no longer be valid.
NDS synchronization may report temporary -625 errors if the DHCP server assigns an IP address that is different from what an DHCP client previously had used. These errors will continue until such time as the limber process updates the NCP Servers "network address" attribute on remote servers in the replica ring with the newly updated IP address.
When running DHCPCLNT.NLM on BorderManager servers, the Proxy, IP Gateway, VPN servers and Packet Filters are not automatically updated with the newly assigned IP address.
Enabling NAT on a server running the DHCPCLNT module will require the following operations to be carried out.
Load DHCPCLNT with the '-INETCFG' option
Load INETCFG and select YES to "Transfer LAN drivers, protocol and remote access commands"
Run "Reinitialize system" at the server console
TCP/IP Troubleshooting Tools
NetWare includes several command line utilities and tools that are helpful in diagnosing TCP/IP problems. Although many administrators seldom use them (and some may not even know that they exist(, these utilities can provide essential information for troubleshooting TCP/IP problems. Familiarize yourself with at least the following utilities and use them in your troubleshooting routines.
DHCP Client Info Screen - Screen available at Server Console that displays the current IP configuration. Use this screen to verify that IP currently has valid information, or to view error messages indicating where the problem may lie.
TCPCON - Menu-driven module that displays protocol statistics and current TCP/IP connections. DHCP is an application that uses UDP at the transport layer. Verify that there are no UDP errors, and that the ICMP messages do not point to remote host or port errors (check destination unreachable message count).
PING - Server console command that allows you to verify that at least minimum TCP/IP connectivity exists between two hosts. Should be used after DHCP exchange to verify that connectivity is in place.
IPTRACE - Server console command that displays the path, including intermediate hops, that connects two hosts, allowing you to determine at what point TCP/IP connectivity is being lost.
MONITOR - The DHCPCLNT.NLM is a simple prescan stack that interfaces with LSL. Check the MONITOR | LAN/WAN Statistics menu for possible errors or resource issues with ECBs (receive discarded, no available buffers count, and so on).
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.