When troubleshooting a DHCP client, you must understand certain issues about configuring the client and client-server communication. DHCP may fail to configure the client properly, either because DHCP could not communicate with a server, or because, although configuration responses were received, they were incorrect. Problems can also occur later in the life of a DHCP lease if the client cannot renew its IP addresses.
When a client and a server cannot communicate with each other, the consequences depend on whether or not the client has a configuration cached from an earlier DHCP transaction. If it has, and if the lease is still valid, the client will use the cached data to configure the interface.
However, because the client has received no outside confirmation that this configuration is valid, there is no guarantee that the IP address, router address, and other information are valid. If the interface is connected to a network other than the one on which the configuration was received, one of two things can happen. Either errors may appear when other network services are started, or it may be impossible to communicate with other hosts on the network.
On the other hand, if no cache with an unexpired lease exists, the interface is not configured.
Configurations can be invalid for two reasons:
The client determines by ARP that the IP address offered to it is in use elsewhere. In this case, the client will send a DHCPDECLINE message to the server. If the server offers more than two bad addresses, dhcpagent fails.
The client gets offers, but when it tries to confirm them, the server sends a DHCPNAK message instead of a confirmation. If the client receives DHCPNAK messages more than twice, dhcpagent fails. This indicates a malfunctioning server.
Perform the following actions to isolate the problem to either the client or the server machine.
Problem
The DHCP server machine is not working.
Verification: Log in to another machine on the same subnet as the client, and use the ping command to try to reach the server.
Solution: Diagnose the problem on the server machine.
Problem
The DHCP server is not running.
Verification: Log in to the server and enter the command:
ps -ef | grep dhcp |
Solution:
Stop and restart the DHCP server.
Enter the command:
/etc/init.d/dhcp stop |
Wait about 10 seconds. Then enter the command:
/etc/init.d/dhcp start |
Problem
The boot process hangs during DHCP.
Verification: The interface is marked primary, but no valid DHCP transaction has occurred.
Solution: Interrupt DHCP by typing control-C. The boot continues.
Although booting continues, the host may be incorrectly configured for the networks to which it is attached.
Problem
After configuring the DHCP client software and rebooting the client, you are unable to reach a server on the network from the client. All DHCP network commands fail and you see messages that the client is trying to reach the DHCP server and failing.
Typical error messages include:
DHCP or BOOTP server not responding
A request to access nonexistent dhcp_network database: databasename in datastore: datastore.
No more IP addresses for network_address network.
Verification: To pinpoint exactly what the problem is, perform the following actions.
Run the client in debug mode.
Attempt to configure the interface manually to verify that the hardware is functioning.
Run the DHCP server in debug mode.
Use snoop to trace messages sent between the DHCP server and client.
Find out if the problem is on the client or server machines.
Look at the error message and choose a solution from the information below.
Run the client in debug mode. Refer to the documentation for the product you are running.
On a PC-NFS DOS client:
After dhcpagent has been started in debug mode, you can try to configure an interface manually by typing:
ifconfig interface_name auto_dhcp |
Packets that are sent, and any that are received, will be displayed.
Log in to the root account on a DHCP server on the same subnet as the client.
Kill and restart the DHCP server in debug mode. For example:
/etc/init.d/dhcp stop /usr/lib/inet/in.dhcpd -d -v |
/usr/lib/inet/in.dhcpd -i interface_names -d -v |
Log in to the root account on a DHCP server or BOOTP relay agent on the same subnet as the client.
Use the snoop command to trace network traffic. For example:
snoop -o /tmp/output udp port 67 or udp port 68 |
snoop -o /tmp/output udp port bootps or udp port bootpc |
Boot the client and watch the network messages on the server.
Type:
snoop -i /tmp/output -x 0 -v |
Look at the output from running the in.dhcpd command in debug mode and use the error message or condition you see to find a solution from the information below.
You see one of the following error messages:
Datagram received on network device: le0
ICMP ECHO reply to OFFER candidate: ip_address disabling
Verification: Before the DHCP server offers an IP address to a client, it verifies that the IP address is not in use by pinging the IP address. If a client replies, the IP address is in use.
Solution: Make sure the IP addresses you configured are not already in use.
You see the following error message:
No more IP addresses for network_address network
Verification: There are no available IP addresses in the client's dhcp_network table.
Solution: Use the dhcpconfig command to allocate more IP addresses. If the DHCP daemon is monitoring multiple subnets, be sure the additional IP addresses are for the subnet where the client is located.
There is a bad client id: id_name in the dhcp_network database.
Verification: The client ID (MAC address) in the dhcp_network table is incorrect.
Solution: If you are using Ethernet, the client ID is 01 followed by the Ethernet address. Make sure that all letters in this address are capitalized. A 00 means the address has not been assigned.
You see the following error message:
Request to access nonexistent dhcp_network database: database_name in datastore: nisplus_datastore.
Verification: The dhcpconfig script did not create a dhcp_network table for a subnet during the configuration of the DHCP server. This can happen if you set up an isolated LAN, such as a server and two clients, as a test network.
Solution: Use the dhcpconfig command to initialize the dhcp_network table and new IP addresses.
You receive the error message:
Client client_id is trying to verify unrecorded address ip_address, ignored.
Verification: There are two possible reasons for getting this message:
You can receive this message if your dhcp_network tables have been deleted. If you are using only the Solaris 2 DHCP server, then this is typically the reason.
You can receive it if you are not using NIS+ for datastore, so information is not shared. Make sure that the server is sharing data.
If you have a group of heterogenous servers, then ignore this message.
Solution: Remove old cache files on the client by typing:
ifconfig interface_name dhcp release |
DHCP is started, but some required network services will not start.
Verification: The DHCP server is not supplying the configurations required.
Solution: Find out why the server does not send the parameters that are required. Configure the server to do so.
DHCP is started, but certain network services, such as NIS and NIS+, report errors or hang. The host cannot communicate with other hosts on the network.
Verification: The dhcpagent command was unable to communicate with DHCP (presumably because DHCP was unavailable) and has used cached data.
Solution: Remove the cache. Type:
ifconfig interface_name dhcp release |
Since removing the cache does not solve the problem of getting the proper configuration, the host may have to be configured by hand. At boot time, DHCP should be disabled by removing the trigger file by typing:
rm /etc/dhcp.interface_name |
The client boots and works correctly, but the following message appears:
DHCP renewal on interface_name failed
Verification: DHCP is working, but dhcpagent cannot contact the server to extend the lease.
Solution: Find out why the server is not responding now. This could be because the router value configured in the dhcptab is incorrect or out of date for the client network.
Messages about failed DHCP renewals are received. Then the following message appears on the console:
DHCP lease expired on interface_name: interface is now down
Network services may hang at this point.
Verification: The lease has expired. The client has not been able to extend the lease after several attempts.
Solution: Find out why the server is not responding. Reboot the client.
Problem
The DHCP daemon is running in BOOTP compatibility mode (-b option).
Verification: BOOTP does not use a lease time. The DHCP server looks for free addresses with the BOOTP flag set to allocate the BOOTP clients.
Solution: Allocate BOOTP addresses. Use dhcpconfig to change the daemon options.
Use the information below to fix errors in the configuration of the NIS+ name service that prevent the client from accessing a server during boot.
Problem
No name service is configured for the client in the dhcptab table.
Verification: Log in to the server and type the command:
dhtadm -P | grep ip_address |
Check for entries such as NISdmain, DNSdmain, and NISservs. Make sure the addresses entered for them are correct. For example:
# dhtadm -P | grep 129.148.3.129.148.3.m:Subnet=255.255.255.0:Router=129.148.3.11: Broadcast=129.148.3.255:NISdmain="island.ocean":NISservs=129.148.3.3: |
The line above actually appears on one line, instead of being broken into two.
Solution: Use dhtadm to change any incorrect addresses.
Problem
You are using NIS+ and the server is not running in NIS+ compatibility mode. NIS+ tables do not have read rights for the Nobody category, so NIS clients cannot access the information stored there.
Verification: Run the command:
nisls -l org_dir |
Check whether the Y option is set for the rpc.nisd daemon. For example:
ps -deaf | grep nis |
Solution:
Problem
An incorrect default router prevents the client from reaching a server on another network.
Verification: Make sure the router symbol definition in the dhcptab table is actually a router.
Solution: Use dhtadm to correct the route symbol in the table.
Problem
You are running NIS+ but DNS forwarding is not turned on for NIS clients.
Verification: Use the command:
ps -ef | grep rpc.nisd |
A -B option means that NIS is running with DNS forwarding turned on. For example:
/usr/sbin/rpc.nisd -B |
Solution: Start the NIS+ server in NIS compatibility mode with DNS forwarding enabled. For example:
/usr/sbin/rpc.nisd -YB |
Use the information below to fix errors in the configuration of the NIS name services that prevent the client from accessing a server during boot.
Problem
An incorrect default router prevents the client from reaching a server on another network.
Verification: Make sure the router symbol definition in the dhcptab table is actually a router. If there are problems with the default router, make corrections with server-based tools.
Solution: Use dhtadm to correct the route symbol in the table.
Problem
No name service is configured for the client in the dhcptab table. For clients, the name service must be DNS, NIS, or NIS+, and appropriate parameters must be provided to each client.
Verification: Check the network-specific macro relating to the client's configuration.
Log in to the server and type the command:
dhtadm -P |
Look for an entry that matches your client's network.
Solution: Use dhtadm to correct the client's macro for the name service:
If this is the first client on the network:
Use dhtadm to correct the entries.
Then type:
/etc/init.d/dhcp stop, /etc/rc3.d/S34dhcp start |
The server does not dictate the name service choice to the client. The server only provides the relevant information. The client chooses its name service.
You have changed one or more macros for a client with dhtadm, but the changes are not evident on your machine. For example, you changed the client's router, but the client is still using the old router.
Use the information below to solve the problem of changed client macros not showing up on the DHCP server.
Problem
The DHCP server was not reinitialized to read your changes to the dhcptab table. This must be done every time you change a macro definition.
Solution: Use the rescan option-set with dhcpconfig, or:
Reinitialize the DHCP server: