Troubleshooting DHCP

From Debian Clusters
Jump to: navigation, search

This is the third page of a three-part tutorial on setting up DHCP. The full tutorial includes

Changing dhcp.conf

After changing dhcp.conf, make sure to restart the dhcp server. /etc/init.d/dhcp3-server restart should work, as should /etc/init.d/dhcp3-server stop and then /etc/init.d/dhcp3-server start.

/var/lib/dhcp3/dhcpd.leases

The DHCP log file can be a handy tool for diagnosing whether leases have been handed out and for how long. Unfortunately, only leases handed out to unknown hosts (hosts not specifically mentioned in /var/lib/dhcp3/dhcpd.leases) will be logged in this file.

Verifying DHCP

The first step is making sure that the dhcp server is running. Issuing a ps aux command and grepping it for dhcp is the easiest way to do this. If the dhcp server is running, something like the following should be returned.

eyrie:~# ps aux | grep dhcp
root      4033  0.0  0.1   2488  1044 ?        Ss   00:24   0:00 /usr/sbin/dhcpd3 -q
root      4090  0.0  0.0   2176   768 ?        S<s  00:25   0:00 dhclient3 -pf /var/run/dhclient.eth0.pid
                                                                 -lf /var/lib/dhcp3/dhclient.eth0.leases eth0

If the server isn't running, try starting it with /etc/init.d/dhcp3-server start. If that fails, check /var/log/syslog for information as to why it failed to start.

On the other hand, if the server is running, sometimes it's difficult to tell whether it actually is handing out DHCP leases. There are two ways to double check if it is by running tcpdump on the dhcp server or on the client asking for an IP address. Both will require physical access to a dhcp client.

Client-side Testing: Dhclient

First check whether the client can request a dhcp lease. Do this by sitting in front of the client and executing dhclient. Ideally, it should return the following

Client Success

peregrine:~# dhclient
Internet Systems Consortium DHCP Client V3.0.4
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:50:04:b2:eb:a2
Sending on   LPF/eth0/00:50:04:b2:eb:a2
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.254
bound to 192.168.1.100 -- renewal in 6425 seconds.
  • The IP after DHCPACK should be the IP address of the DHCP server.
  • The IP after bound to should be the IP address specified for this client in /etc/dhcp3/dhcpd.conf.

Client Failure

Alternatively, you might receive something like this:

peregrine:~# dhclient
Internet Systems Consortium DHCP Client V3.0.4
Copyright 2004-2006 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/eth0/00:50:04:b2:eb:a2
Sending on   LPF/eth0/00:50:04:b2:eb:a2
Sending on   Socket/fallback
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPREQUEST on eth0 to 255.255.255.255 port 67
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 9
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12
No DHCPOFFERS received.

In this case, the dhcp server either isn't receiving the request or may be failing to respond. Double-check that the MAC address in /etc/dhcp3/dhcpd.conf matches the MAC shown by a dhclient.

Server-side Testing: Tcpdump

Tcpdump can give an idea of what's going on from the dhcp server's perspective. It should be easy to install with apt-get install tcpdump. Once installed, it can be used to display all the traffic coming in and out of a given network interface. You'll either want to do this sitting in front of the computer (if you're going to listen on all interfaces) or by listening only on the interface handing out DHCP leases. SSHing into the computer and then running tcpdump is a bad idea because the ssh connection will constantly be generating traffic, unless you specify which ports to listen on.

Tcpdump can be run on just one interface using

tcpdump -i <interface> -n port 67 or port 68

Ports 67 and 68 are specifically for DHCP traffic - 67 for requests and 68 for responses.

Server Success

Running dhclient from the client computer should result in traffic like this on the dhcp server if successful: notice in the last line, the IP address for the dhcp server is shown responding back (BOOTP/DHCP, Reply) to the client with its new IP address.

eyrie:~# tcpdump -i eth1 -n port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:08:32.100367 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:50:04:b2:eb:a2 (oui Unknown), length 300
15:08:32.104525 IP 192.168.1.254.bootps > 192.168.1.100.bootpc: BOOTP/DHCP, Reply, length 300

Server Failure

If no traffic occurs, then the request isn't going through the server, which means something may be wrong with the network in between. This can be tested with pings.

Alternatively, traffic like the following indicates that the server sees the request but is ignoring it. Make sure that /etc/dhcp3/dhcpd.conf is set up correctly to hand out leases and then the MAC address for this client is correct.

eyrie:~# tcpdump -i <interface> -n port 67 or port 68
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:04:03.105460 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:50:04:b2:eb:a2 (oui Unknown), length 300
15:04:07.105566 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:50:04:b2:eb:a2 (oui Unknown), length 300
Personal tools
Namespaces

Variants
Actions
About
services
node images
clustering
web monitoring
Tools