I would really appreciate thoughts and opinions on this strange issue experienced recently.

Consistent behaviour noted from problem clients:

  • Up to a certain time in the morning user PC's were requesting the use of 169.254.x APIPA addresses
  • Not accepting the legitimate addresses offered by the DHCP server within this time frame
  • Following a second DHCPDISCOVER after the time period clients would then accept the DHCP offered IP address


  • Impacted a single buildings network following a weekend
  • Users who had left there machines on over weekend, no issues - DHCP renewals etc operating normally
  • Users who had diligently turned off their PC's however experienced DHCP issues following power on
  • This affected the building for two hours, no fault found and resolved itself.
  • The network is monitored and extensive investigation completed - no network issues during the time frame
  • The DHCP servers issue addresses across site, this was isolated just to one building
  • Client machines predominantly Windows 7, various hardware and NIC vendors affected - no pattern found.
  • Mixture of static desktops and laptops
  • Wired connectivity
  • Affected one vlan although not all clients affected within the vlan.

Sequence of events captured in the DHCP server log

  1. DHCPDISCOVER - Client PC - First discover action by client
  2. DHCPOFFER DHCP Server - Legit IP address offered by DHCP Server
  3. DHCPREQUEST - Client PC - Request for 169.254x from client: 'wrong network' message
  4. DHCPNAK - DHCP Server - Server negatively acknowledges via NAK. Client must start process again
  5. DHCPDISCOVER -Client PC - Second discover action by client
  6. DHCPOFFER - DHCP Server - Legit IP address offered
  7. DHCPREQUEST - Client PC - Client requests use of the legit IP address
  8. DHCPACK - DHCP Server - Server acknowledges positively

Pseudo summarisation of RFC3927 points:

A 'brief' read through RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses - provides more questions than answers!

When link-local 169.254.x addresses used

  • 169.254. /16 link-local addressing used when addresses or address configuration not available
  • Typically run on startup

If host using 169.254.x address and routable address now available host must

  • Use routable address
  • Cease advertising 169.254.x

Methods routable address may cease to be available

  • Expiration of DHCP lease
  • Removal of address via manual configuration
  • Roaming host to new network where address no longer operable

169.254.x address selection

  • Windows and MAC hosts implement link local auto configuration
  • Windows note:
    • As soon as network connectivity detected DHCPREQUEST or DHCPDISCOVER sent on interface
    • Systems immediately transition our of autoconfigured as soon as connectivity available
  • pseudo random number generation seeded against host i.e. MAC
  • Occurs on boot

Claiming 169.254.x address

  • Host must test to see if 169.254.x link local address is not in use on network
  • Completed via broadcasted ARP request (target ip address included - to be probed)

Announcing 169.254.x address

  • Second ARP broadcast but this time including sender and target IP addresses are now the selected 169.254.x IP's

Final summary

  • The client DHCPDISCOVERs and the DHCP server responds with a DHCPOFFER
  • The client should take this offer of a routable address and cease to use the link-local 169.254.x. For some reason it does not..
  • The subsequent DHCPREQUEST from the client looks to be the ARP probe or ARP announcement broadcast? That the client is using 169.254.x.x and may not correlate to the DHCP server responses?
  • Second DHCPDISCOVER - it is not clear what prompts this as the PC's were powered on initially.

Thanks for your patience if you have got this far!

Would really appreciate some help in understanding this.



Are you out of addresses in the lease pool? Maybe that's why it can no longer hand out additional IP addresses.

Can you ping the DHCP server from the affected machines once you are into Windows? Can you hard code the NIC to a unused IP from the DHCP range and does that get you onto the network for testing? If needed too, test one of the working PCs on the same network port as a no working machine.

  • Yes the lease pool capacity was checked at the time and it was well within its normal utilisation. It is a good point though this time of the morning all users are starting work the the day and would the standard morning spike in DHCP requests. – 3iron Jun 19 '15 at 8:07
  • In terms of pinging the DHCP server from the client. Its now a retrospective investigation so difficult to simulate - this wasn't completed at the time. I do wonder if the DHCPREQUEST messages recorded in the DHCP log are just ARP broadcasts from the clients announcing the use of the associated 169.254.x address - because in the same vlan they are visible - rather than being actual client > server communication. – 3iron Jun 19 '15 at 8:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.