Hi All,
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
Summary
- 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
- DHCPDISCOVER - Client PC - First discover action by client
- DHCPOFFER DHCP Server - Legit IP address offered by DHCP Server
- DHCPREQUEST - Client PC - Request for 169.254x from client: 'wrong network' message
- DHCPNAK - DHCP Server - Server negatively acknowledges via NAK. Client must start process again
- DHCPDISCOVER -Client PC - Second discover action by client
- DHCPOFFER - DHCP Server - Legit IP address offered
- DHCPREQUEST - Client PC - Client requests use of the legit IP address
- 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.
Thanks,
