DHCP service: logs

Access is via a web interface, using the same password as for the DNS updates interface. Your network will only show in the list of networks if it is using the new servers; if your network has yet to migrate from the old servers you will not be able to use this facility.

Currently, two facilities are offered:

  • simple search: this allows you to search the logs for occurences of a given MAC address, IP address or client hostname.
  • dynamic pool information: this allows you to view the current, maximum and minimum usage of the dynamic pool on your network.

 

Expand All

The search facility allows you to determine from the server logs when a particular client was associated with a particular IP address. Results will be filtered for your subnet: except in certain circumstances you will not be able to view log entries from other networks.

You may search on the following terms:

  • MAC address: if known, this is the best term to use, as it will show all entries pertaining to a lease negotiation. The system accepts several common MAC address formats.
  • IP address: often in abuse cases you will have been given an IP address and will need to trace the MAC address of the client responsible. Be aware of the difference between a lease offered to a client (server sends a DHCPOFFER) and a lease accepted by a client (server sends a DHCPACK to the client to acknowledge take-up of a lease). Clients will often be offered leases from each server, and while under no obligation to accept either, will generally accept the first to be received.
  • Client hostname: this is an optional identifier which DHCP clients may send to the DHCP servers and generally corresponds to the name a user has assigned to their computer (eg "fred-laptop"). With the DHCP service, it does not affect whether or not a client is permitted to obtain a DHCP lease, but is recorded in the server logs.

Log entries begin with a timestamp. This is always in local time (GMT or BST as appropriate).

The next field gives the IP address of the DHCP server making the log entry, and is followed with the process name (always "dhcpd").

Next comes the type of DHCP message. Possible values include DHCPDISCOVERDHCPOFFERDHCPREQUESTDHCPACK

DHCPINFORMDHCPNAKDHCPDECLINE and DHCPRELEASE. Additionally, log entries from the older bootp protocol may occasionally be seen.

Next comes the information that identifies the client, including the IP address in question (where appropriate) and/or the client's MAC address.

Where the client supplies a DHCP client hostname, this will also be given in the logs. On the DHCP service, the client hostname never

affects the DHCP transaction and is purely informational.

A typical DHCP transaction will be as follows, in which a client boots up and attempts to discover its IP address:

Feb 27 00:08:07 129.67.2.2 dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 
 (billgates) via 129.67.103.254: load balance to peer OUCS-DHCP
Feb 27 00:08:07 163.1.2.2  dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 
 (billgates) via 129.67.103.254
Feb 27 00:08:07 163.1.2.2  dhcpd: DHCPOFFER on 129.67.103.1 to 00:11:22:33:44:55
Feb 27 00:08:07 129.67.1.2 dhcpd: DHCPREQUEST for 129.67.103.1 (163.1.2.2) from
 00:11:22:33:44:55 (billgates) via 129.67.103.254: load balance to peer OUCS-DHCP
Feb 27 00:08:07 163.1.2.2  dhcpd: DHCPREQUEST for 129.67.103.1 (163.1.2.2) from
 00:11:22:33:44:55 (billgates) via 129.67.103.254
Feb 27 00:08:08 163.1.2.2  dhcpd: DHCPACK on 129.67.103.1 to 00:11:22:33:44:55
 (billgates) via eth0

On some transactions, an additional IP address is given in brackets, for instance:

Feb 27 00:08:08 129.67.2.2 dhcpd: DHCPREQUEST for 129.67.100.80 (163.1.2.2) from
 00:11:22:33:44:55 (billgates) via 129.67.103.254: load balance to peer OUCS-DHCP
Feb 27 00:08:08 163.1.2.2 dhcpd: DHCPREQUEST for 129.67.100.80 (163.1.2.2) from
 00:11:22:33:44:55 (billgates) via 129.67.103.254

This address is the address of the DHCP server to which the request is directed; since the request is still sent as a broadcast it will be received by both servers (and possibly others). Occasionally the IP address will not be that of one of the servers but that of a rogue DHCP server operating on the subnet in question. Knowing the IP address can be very useful in identifying the offending system, particularly if its MAC address can be gathered by other means.

The final part of the log entry shows how the packet is to be received or transmitted. When the client already knows its IP address this will be "via eth0". Where the client has yet to have an IP address assigned (for instance on the initial DHCPDISCOVER or the server's DHCPOFFER), the IP address of the DHCP relay agent is given.

Additionally, on DHCPDISCOVERs and broadcast DHCPREQUESTs, both servers will receive the same packet. The servers are configured so as to load-balance and consequently one server will fail to respond, appending to the log entry "load balance to peer OUCS-DHCP". In the event of the client receiving no response within a few seconds (the peer may be down or there may be a network problem), it should then retry the request. As retries are identifiable by the server, the load-balancing will be overridden and either authoritative server can make an offer if it receives a request. In a similar manner, the log entry "lease owned by peer" may be seen when one server sees a DHCPREQUEST for an IP address controlled by the other server.

Other log entries may be seen; if you require any assistance in their interpretation then please feel free to contact the networks team.

 

A broadcast request from the client, asking any listening DHCP servers to respond with an offer. Example:

Feb 27 00:08:07 129.67.2.2 dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 
 (billgates) via 129.67.103.254: load balance to peer OUCS-DHCP
Feb 27 00:08:07 163.1.2.2  dhcpd: DHCPDISCOVER from 00:11:22:33:44:55 
 (billgates) via 129.67.103.254

Sent from the DHCP server to the client, normally via the forwarding agent, offering it an IP address. The server will have reserved the address for a brief period of time (typically two minutes), after which it is free to be offered to another client.

Feb 27 00:08:07 163.1.2.2  dhcpd: DHCPOFFER on 129.67.103.1 to 00:11:22:33:44:55
 (billgates) via 129.67.103.254

Here the DHCP client is requesting a particular address. This may be in response to a DHCPOFFER just received or to extend its current lease. A client for which a lease has expired will generally request the last IP address it had, although it may since have changed to a different network (for instance a laptop moving between a college connection and a departmental one).

Feb 27 00:08:07 163.1.2.2  dhcpd: DHCPREQUEST for 129.67.103.1 (163.1.2.2) from
 00:11:22:33:44:55 (billgates) via 129.67.103.254

An acknowlegement from the server to confirm a previous DHCPREQUEST or DHCPINFORM.

Feb 27 00:08:08 163.1.2.2  dhcpd: DHCPACK on 129.67.103.1 to 00:11:22:33:44:55
 (billgates) via eth0

Used by clients which already have an IP address to obtain additional information from the DHCP server (for example, DNS or WINS server addresses).

Feb 27 00:08:09 163.1.2.2  dhcpd: DHCPINFORM from 129.67.103.1 via eth0
Feb 27 00:08:09 163.1.2.2  dhcpd: DHCPACK to 129.67.103.1

 

ent by the server to a client requesting an address which the server cannot assign. This may happen when a client asks for an address now assigned to another client, or when a client has moved to a different subnet but initially requests the last address it had. For example, a host arrives having last been behind NAT on an RFC1918 address:

Feb 27 00:08:09 163.1.2.2  dhcpd: DHCPREQUEST for 192.168.0.56 (192.168.0.1)
 from 01:23:45:67:89:ab via 129.67.103.254: wrong network
Feb 27 00:08:09 163.1.2.2  dhcpd: DHCPNAK on 192.168.0.56 to 01:23:45:67:89:ab
 via 129.67.103.254

Normally sent by a client assigned an address which it then discovers another client to be using (by receiving a response to an ARP request). For example, a server allocates the address 129.67.103.10 to a client, only for the client to report a conflict. The servers will take note of the DHCPDECLINE and avoid allocating the address in question if possible.

Feb 18 23:39:55 129.67.1.2 dhcpd: DHCPDISCOVER from 00:22:44:66:88:aa
 (steveballmer) via 129.67.103.254
Feb 18 23:39:55 163.1.2.2  dhcpd: DHCPDISCOVER from 00:22:44:66:88:aa
 (steveballmer) via 129.67.103.254
Feb 18 23:39:56 129.67.1.2 dhcpd: DHCPOFFER on 129.67.103.10 to 
 00:22:44:66:88:aa (steveballmer) via 129.67.103.254
Feb 18 23:39:56 163.1.2.2  dhcpd: DHCPOFFER on 129.67.103.33 to 
 00:22:44:66:88:aa (steveballmer) via 129.67.103.254
Feb 18 23:39:56 129.67.1.2 dhcpd: DHCPREQUEST for 129.67.103.10 (129.67.1.2) 
 from 00:22:44:66:88:aa (steveballmer) via 129.67.91.254
Feb 18 23:39:56 129.67.1.2 dhcpd: DHCPACK on 129.67.103.10 to 00:22:44:66:88:aa
 (steveballmer) via 129.67.103.254
Feb 18 23:39:56 163.1.2.2  dhcpd: DHCPREQUEST for 129.67.103.10 (129.67.1.2) 
 from 00:22:44:66:88:aa (steveballmer) via 129.67.103.254: lease owned by peer
Feb 18 23:39:56 163.1.2.2  dhcpd: Abandoning IP address 129.67.103.10: declined.
Feb 18 23:39:56 129.67.1.2 dhcpd: Abandoning IP address 129.67.103.10: declined.
Feb 18 23:39:56 163.1.2.2  dhcpd: DHCPDECLINE of 129.67.103.10 from
 00:22:44:66:88:aa (steveballmer) via 129.67.103.254: not found
Feb 18 23:39:56 129.67.1.2 dhcpd: DHCPDECLINE of 129.67.103.10 from
 00:22:44:66:88:aa (steveballmer) via 129.67.103.254: not found

Sent by a client to return an assigned IP address prior to expiry of the lease, for instance on shutdown.

Mar  6 21:50:40 163.1.2.2 dhcpd: DHCPRELEASE of 129.67.103.74 from
 01:02:03:04:05 (p_allen) via 129.67.103.74 (found)

 

BOOTREQUEST: a request for an IP address sent using the older BOOTP protocol. Virtually all common operating systems have supported DHCP for several years and BOOTP is generally only used these days by appliances with simple networking support, such as some printers. BOOTP clients must be registered for a static address assignment.

A response from the DHCP server assigning an address by BOOTP. Unlike DHCP the negotiation is always two-stage (REQUEST, REPLY) rather than four (DISCOVER, OFFER, REQUEST, ACK). For example:

Mar  6 06:55:56 129.67.1.2 dhcpd: BOOTREQUEST from 08:00:aa:bb:cc:dd via 
 129.67.103.254
Mar  6 06:55:56 129.67.1.2 dhcpd: BOOTREPLY on 129.67.103.254 to 
 08:00:aa:bb:cc:dd via 163.1.109.254

Information regarding the usage of the dynamic pool on each subnet is gathered periodically from the DHCP server. The information displayed will typically be no more than a few minutes old.

Current usage will be displayed in terms of the number of available addresses out of the total number in the dynamic pool. Hosts with static IP addresses do not affect the count. Maximum and minimum usage is displayed from the previous Sunday onwards, i.e. a period of between seven and fourteen days.

Remote access to server logs relies on constant communications between the DHCP servers themselves and the webserver. While TCP connections are used for reliability, it is still possible that the webserver will fail to receive information in the event of an extended network fault or system downtime. As such, we do not recommend that the absence of a log entry be relied upon as evidence in incidents such as displinary cases. Hostmaster can provide logs from the DHCP servers themselves if necessary; please contact networks@it.ox.ac.uk to request this.

It is also possible for temporary network faults to result in log entries from the two servers to appear out of sequence. At present the web interface does not correct for this problem.

Be aware that users may manually set their system's IP address to one from the dynamic pool. The DHCP servers will have no information regarding the systems doing this, and may attempt to lease the IP address in question to other clients. Savvy users may also assign arbitrary MAC addresses to their network interface. Such behaviour will often be against local network policy and appropriate action against users is recommended.

Get support


Local IT support provide your first line of on-the-spot help

FIND MY LOCAL IT TEAM

 

Common requests and fault reports can be logged using self-service

   USE IT SELF-SERVICE    

   LOG A SUPPORT CALL    

VIEW MY SUPPORT CALLS  

The central Service Desk is available 24x7 on +44 1865 6 12345

 

If you do not have an SSO account you can use this form to contact the Service Desk