DHCP Client Behavior

DHCP Client Behavior

  • Comments 13
  • Likes

Many Transmission Control Protocol/Internet Protocol (TCP/IP) networks use Dynamic Host Configuration Protocol (DHCP) servers that are administratively set up to allocate TCP/IP configuration information to clients on the network.  DHCP is a TCP/IP standard that reduces the complexity and administrative overhead of managing network client IPv4 / IPv6 addresses and other configuration parameters.  We will restrict ourselves to IPv4 behavior in this discussion.  A properly configured DHCP infrastructure eliminates the configuration problems associated with manually configuring TCP/IP.

A DHCP infrastructure consists of the following elements:

  • DHCP servers – Computers that offer dynamic configuration of IPv4 addresses and related configuration parameters to DHCP clients.
  • DHCP clients – Network nodes that support the ability to communicate with a DHCP server to obtain a dynamically leased IPv4 address and related configuration parameters.
  • DHCP relay agents – Network nodes, typically routers, that listen for broadcast and unicast DHCP messages and relay them between DHCP servers and DHCP clients. Without DHCP relay agents, you would have to install a DHCP server on each subnet that contains DHCP clients.

When a Client, configured with the TCP/IP setting “Obtain an IP address automatically”, plugs into a network, it sends out a broadcast from UDP port 68 to UDP port 67 to “DISCOVER” a DHCP Server (or relay agent).  The DHCP Server then responds by sending out an “Offer” (through a relay agent if applicable).  Then the client sends out a “Request”, requesting an IP address which is finally “Acknowledged” by the server so that the client starts using the IP address.

The above process is well understood by Administrators.  However, in situations where a DHCP Server fails or is not available, client behavior needs to be understood for efficient use.  Then there are cases where a laptop user roams between his house (static IP) and office (DHCP) and does not want to keep changing the TCPIP properties every time.

First, let’s understand DHCP client behavior when DHCP server is not available.  To understand well, we will observe the etl trace taken on a DHCP client. Ref: http://technet.microsoft.com/en-us/library/cc731630.aspx - “netsh dhcp client trace enable”.  Etl tracing is saved as the following files: %windir%\system32\logfiles\WMI\dhcpcsvc.etl, dhcpcsvc6.etl and dhcpqec.etl.

Both Windows Vista and Windows XP send out DHCP packets in the following sequence:

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:42.943 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:42.943 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:42.943 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 5 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:42.943 (TryReceive:dhcpmsg_c471)Select: waiting for: 5 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 7 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:47.304 (TryReceive:dhcpmsg_c471)Select: waiting for: 7 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 15 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:54.184 (TryReceive:dhcpmsg_c471)Select: waiting for: 15 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [1]0430.0910::10/14/2008-20:59:09.815 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [1]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [1]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 32 seconds
DEBUG_TRACE [1]0430.0910::10/14/2008-20:59:09.815 (TryReceive:dhcpmsg_c471)Select: waiting for: 32 seconds

EBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ObtainInitialParameters:protocol_c2510)121(ERROR_SEM_TIMEOUT)
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (DhcpSetRcvAllMode:protocol_c3941)RcvAll: 0
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ReObtainInitialParameters:protocol_c3111)Autoconfiguring....
DEBUG_TRACE [0]0430.0910::10/14/2008-20:59:41.243 (ReObtainInitialParameters:protocol_c3153)Ready to acquire autonet address. Notifying NLA...

DEBUG_LEASE [0]0430.0910::10/14/2008-20:59:41.244 (ReObtainInitialParameters:protocol_c3191)Sleeping for 275 seconds.

Thus, if we consider the first DISCOVER packet at 0 seconds, then 4 packets are sent out as:

  • 0th second - 1st packet with 5 sec timeout
  • 5th second - 2nd packet with 7 sec timeout
  • 12th sec: 3rd packet with 15 sec timeout
  • 27th sec: 4th packet with 32 sec timeout

The above 4 packets with a final timeout of about 1 minute may be considered as a “set” for the purpose of this discussion.

In Windows Vista: One such set is sent out every 5 minutes as can be seen above.  After one set, the DHCP client sleeps for 275 seconds or over 4.5 minutes.

In Windows XP: The first 2 sets are sent one after another, after which one set is sent once every 5 minutes (approximately).

A registry key to control this is: AutonetRetries which may be placed as a DWORD in:

HKLM\SYSTEM\CurrentControlSet\Services\Dhcp\Parameters

OR

HKLM\SYSTEM\CurrentControlSet\Services\tcpip\Parameters

AutonetRetries controls the: "DEBUG_LEASE [0]0430.0910::10/14/2008-20:59:41.244 (ReObtainInitialParameters:protocol_c3191)Sleeping for 275 seconds" time period

Thus if the registry is set to 30 (decimal) for example, then the sleep time is reduced to 30 seconds. This means that the set of 4 tries will be sent out every 30 seconds.

Also another interesting reference is:

KB 928233 –  Windows Vista cannot obtain an IP address from certain routers or from certain non-Microsoft DHCP servers

Another registry key suggested here is DhcpConnEnableBcastFlagToggle

Though the purpose of this registry is completely different, on closer inspection, this setting has a side effect in Windows Vista where it sends out 2 sets of DISCOVER packet sets like Windows XP, albeit one set with and the second set without the Broadcast flag.  Subsequent sets will be controlled by the AutonetRetries setting (300 seconds by default).

DHCP Automatic Client Configuration

When a Windows Server 2003 DHCP client is installed, it automatically attempts to locate a DHCP server and obtain a configuration from it.  If it cannot find a DHCP server, it configures its own IP address using either Automatic Private IP Addressing (APIPA) or an alternate configuration.

How APIPA works
  1. A client is configured to automatically obtain an IP address from the DHCP server.
  2. The client is however unable to contact the DHCP server for dynamic IP address assignment because the DHCP server is unavailable or otherwise unreachable.
  3. The client computer uses the APIPA feature to assign and configure its own private IP address. Using a gratuitous Address Resolution Protocol (ARP) reply, the DHCP client tests to determine whether the IP address it has chosen is already in use. If it is, the client selects another IP address, and if necessary, continues to do so. Once it has an address that is verifiably not in use, it configures the interface with this address.
  4. The IP address which the client assigns to itself is a private IP address in the address range of 169.254.0.0 to 169.254.255.255. This address range is reserved by Internet Assigned Numbers Authority (IANA).
  5. The client continues to check whether the DHCP server is available at 5 minute intervals.
  6. When the DHCP server is available again, the client that assigned itself an IP address through APIPA initiates the DHCP lease process to request and obtain an IP address from the DHCP server.
  7. When the DHCP server assigns an IP address to the client, the client replaces the APIPA address with the one it obtained from the DHCP server.

If the DHCP client obtained a lease from a DHCP server on a previous occasion, and the lease is still valid (not expired) at system startup, the client tries to renew its lease.  If, during the renewal attempt, the client fails to locate any DHCP server, it attempts to ping the default gateway listed in the lease, and proceeds in one of the following ways:

  • If the ping is successful, the DHCP client assumes that it is still located on the same network where it obtained its current lease, and continues to use the lease as long as the lease is still valid.  By default the client then attempts, in the background, to renew its lease when 50 percent of its assigned lease time has expired.
  • If the ping fails, the DHCP client assumes that it has been moved to a network where a DHCP server is not available.  The client then auto-configures its IP address by using the settings on the Alternate Configuration tab.  When the client is auto-configured, it attempts to locate a DHCP server and obtain a lease.

APIPA addresses are invalid on the Internet, and computers that are using APIPA addresses can only communicate with other computers using APIPA addresses on the same network segment.

The APIPA feature configures the client with the following:

  • IP address
  • Subnet mask

The APIPA feature cannot configure the client with any other TCP/IP configuration:

  • Default gateway
  • DNS server IP address
  • WINS server IP address

You have to use an alternate configuration to provide the above TCP/IP configuration information to a client when no DHCP server is available for the client.

So when does a machine decide to use APIPA or alternate configuration?  The behavior is different for Windows XP and Windows Vista. Ref: KB 931550 –  When a DHCP server is unavailable on a Windows Vista-based computer, Windows Vista uses an APIPA IP address much sooner than Windows XP does under the same circumstances.

Let’s look at the behavior in network traces:

Windows Vista:

0.000000    1    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x7518FEED
2.989037    2    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x7518FEED
6.774854    3    0.0.0.0    169.254.29.17        ARP    ARP:Request, 0.0.0.0 asks for 169.254.29.17

The first column denotes time in seconds since start.  Thus you can see that Windows Vista configured itself with an APIPA soon after sending first 2 DHCP DISCOVER packets, which is in about 6 seconds.

Now let’s look at Windows XP:

0.000000    3    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
3.000000    4    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
11.000000    5    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
27.000000    6    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0xB9FC38C7
58.000000    7    169.254.61.228    169.254.61.228    ARP    ARP:Request, 169.254.61.228 asks for 169.254.61.228

XP waits for one minute to configure an APIPA. In case one uses Alternate Configuration instead of APIPA, the configuration behavior is the same.  It’s just that instead of APIPA, the machine will be configured with the address & parameters specified by the user.

 

0.000000    3    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
4.000000    4    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
13.000000    5    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
28.000000    6    0.0.0.0    255.255.255.255    DHCP    DHCP:Request, MsgType = DISCOVER, TransactionID = 0x0068B2A9
60.000000    7    192.168.1.3    192.168.1.3    ARP    ARP:Request, 192.168.1.3 asks for 192.168.1.3

In case a machine is configured with APIPA, the computer shows “Limited or no connectivity” balloon by default.  In case one is using APIPA deliberately in a small network, then the alert can be disabled.

Open Control Panel -> Network & Internet Connections -> Network Connections -> Right click the specific network interface and choose Properties -> uncheck “Notify me when this connection has limited or no connectivity”.

To disable APIPA, set the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\adapter_name (for the specific adapter)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters (for all adapters)

IPAutoconfigurationEnabled: REG_DWORD

0 – APIPA disabled

1 – default

Ref: KB 244268 – Routing Does Not Work When Multiple Adapters Use Automatic Private IP Addressing Simultaneously

Alternate Configuration Ref: KB 283676 – How to use the Alternate Configuration feature for multiple network connectivity in Windows XP

- Rajeev Narshana

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Great explanation of two interesting client behaviors

  • How do you extract human-readable data from that binary .ETL logfile?

  • Thanks for that great explanation. Any chance you'd write another post on the client behavior at the other end: when the lease expires.

    (I have a problem with hosts that were hibernated when their leases expired, and when they resume they keep using the expired address.)

  • I have some questions related to shutting down clients and receiving an IP address conflict on the next reboot. Do XP clients completey drop their I/P config information when shutdown? Is the DHCP discover packet sent each time the client reboots or does the client hold onto it's previous configuration?  Does wake on lan cause an issue with obtaining a "clean" DHCP obatined I/P address?

  • Is there a way to programatically force another Discover, Offer, Request, etc cycle during the sleep cycle?  We've got a situation where the endpoint is not authenticated to the network (via 802.1x) until after the initial roughly 90 second timeout.  If we wait until after the sleep interval (which we can control via the above reg key) everything work fine. But we'd like to be able to initiate the discover, offer, etc cycle on demand to speed up the connection process.

  • I have an Erikson internal bb card (Dell 5530) it connects to AT&T at 7.2mbps but is given a 300 second lease on the IP.  Noone at Dell or AT&T or Erikson has been able to assist me in increasing the lease. The Lease value is uneditable based on your description above, how or where would one go to alter this?  It is very annoying to have packet travel halted every 2.5 minutes to renew the connection's IP.

    Please help!  My email is above.

  • I have some questions related to shutting down clients and receiving an IP address conflict on the next reboot. Do XP clients completey drop their I/P config information when shutdown? Is the DHCP discover packet sent each time the client reboots or does the client hold onto it's previous configuration?  Does wake on lan cause an issue with obtaining a "clean" DHCP obatined I/P address?

    XP clients keep the IP lease information in the registry for as long as the lease period. So if the machine is connected within a IP lease period, it tries to reach the DHCP server with a "Request" packet. If this is acknowledged, then the XP continues to use the IP. If the DHCP server NACKs the request, then a DORA is initiated.

    If the DHCP is not reachable, the machine tries to reach the Default Gateway to determine if it is the same network. If the DG is reachable, it uses the leased IP and continues to reach the DHCP till end of lease period.

    It is expected that the DHCP server will not scrap a lease before the time expires and thus not cause an IP conflict when the machine comes back.

  • At the end of a long and tiring process a bit, but there is also needed by the job fine:)

  • I have read your post and had a good article I'm sure everyone will split the job thanks

  • Ryan Hope, you may take a look on this:

    http://msdn.microsoft.com/en-us/library/aa394217%28VS.85%29.aspx

    Good post ;)

  • This is very good news was well informed that the followers of the issue I am. Thank you ..

  • thank you very good very good article

  • I had problems, when server assigns a lease period of 60 sec to the my laptop running on XP.

    After 30 sec, client (laptop), sends renew to server, server responds with ACK with new lease time of 60 sec.

    But looks like, client is not honouring this ACK and keep on requesting with RENEW till lease expires.

    Due to this behaviour, I have been frequently disconnecting, is this is a valid behavior??