DHCP Log Explanation

This is an example of the DHCP report. Because this report can be a bit cryptic for first-time users, Networking Systems has created this explanation page.

 Looking for hardware address 00:0d:93:b1:9e:d6

    last request   : 2006-11-06 11:40:06 
    type           : dhcp 
    gateway        : direct 
    status         : found 
    ip             : 171.64.20.120 (mac-kent-x.Stanford.EDU) 
 
 
         server   count      most recent           first          IP address
         ======  =======  =================  =================  ===============

 DISCOVER:    1       14  10/13/06 11:48:26  05/26/05 09:58:07  171.64.20.1
              2       14           11:48:26           09:58:07  171.64.20.1

 OFFER:       1        1  10/13/06 11:48:26  10/13/06 11:48:26  171.64.20.120
              2        1           11:48:26           11:48:26  171.64.20.120

 REQUEST:     1      110  11/06/06 11:40:06  05/19/06 15:05:40  171.64.20.120
              2       82  11/02/06 11:40:24           15:05:40  171.64.20.120
              1       13  05/19/06 15:05:39  02/07/06 18:27:27  171.64.171.85
              2      126           15:05:39  12/16/05 11:06:19  171.64.171.85
              1       68  12/16/05 10:41:09  05/26/05 09:58:08  171.64.20.54
              2      136           10:41:09           09:58:08  171.64.20.54

 ACK:         1      110  11/06/06 11:40:06  05/19/06 15:05:40  171.64.20.120
              2       82  11/02/06 11:40:24           15:05:40  171.64.20.120
              1       12  05/17/06 15:47:50  02/07/06 18:27:27  171.64.171.85
              2      124           15:47:50  12/16/05 11:06:19  171.64.171.85
              1       67  12/12/05 14:44:25  05/26/05 09:58:08  171.64.20.54
              2      135  11/30/05 14:45:18           09:58:08  171.64.20.54

 RELEASE:     1        1  10/13/06 11:48:17  10/13/06 11:48:17  171.64.20.120

DHCP Steps

To understand the report, you must understand the DHCP process. There are 4 steps:

Discover. The client, which does not yet have an IP address, broadcasts a series of DHCP Discover packets in order to locate DHCP servers.
Offer. Each DHCP server will respond with an IP address for the client to use. Note, for normal DHCP at Stanford, where the user gets the same address each time, both DHCP servers will reply with the same address. Note that clients do not send out Discovers (and no Offers are returned) when renewing a DHCP address.
Request. The client requests the use of one of the addresses provided. Note that, in the case of renewals, the client will contact the DHCP server who provided the address directly.
ACK/NAK. The server acknowledges (ACK) or denies (NAK) the use of the address requested by the user.

It is important to note that each DHCP message is reported by message type, then cronologically. In the above example, which shows a successful DHCP sequence of events, we see the following:

The client sent its most recent Discover almost 1 month ago:

    DISCOVER:    1       14  10/13/06 11:48:26  05/26/05 09:58:07  171.64.20.1
                 2       14           11:48:26           09:58:07  171.64.20.1

At that time, both DHCP servers responded within one second with the same address:

    OFFER:       1        1  10/13/06 11:48:26  10/13/06 11:48:26  171.64.20.120
                 2        1           11:48:26           11:48:26  171.64.20.120

The most recent request was the one shown below. (Note that there are requests listed for several months in the past. Most often, you will be interested in the most recent events.)
```
    REQUEST:     1      110  11/06/06 11:40:06  05/19/06 15:05:40  171.64.20.120
   
```
Less than a second later (note the timestamps), the server responded with an acknowledgement. At this stage, the device has successfully obtained the IP address 171.64.20.120.
```
    ACK:         1      110  11/06/06 11:40:06  05/19/06 15:05:40  171.64.20.120
   
```

What Might Go Wrong

Possible things that may go wrong:

For the device of interest, you see a discover, but there is no offer or the offer is an unexpected address. The device of interest may not be registered correctly. Check the MAC address in NetDB for accuracy. Also, NetDB loads new information to the DHCP every 15 minutes or so, so a newly entered address may not yet have been uploaded to the server. It is also possible, especially for roaming addresses, that there is no available roaming address available, so there is no offer returned by the server.
The device of interest makes a request for an unusual address (e.g., 192.168.1.100) and the DHCP servers respond with a NAK (use denied). There is almost certainly a rogue DHCP server (such as a misconfigured wireless router) on the local net which is distributing IP addresses. The device in question has selected the address offered by the rogue server, and the campus DHCP servers show that this is, in their view, an improper IP address for the device to use.