Users expect to plug in and turn on their PC, tablet, or other device, and to be automatically connected. When a device doesn’t receive an IP address, users cannot connect to their resources. After checking settings on the device like Wi-Fi or verifying that the ethernet cable is secure plugged in, a network administrator may need to review the DHCP server. You can review a Windows DHCP server’s scope of addresses to troubleshoot the issue.
Reviewing the scope and log file
Your DHCP scope may normally have plenty of open addresses. But now users cannot connect due to no IP addresses available, and the scope may be filling with BAD_ADDRESS.
Check the DCHP log file for the appropriate day, C:Windows\System32\dhcp\DhcpSrvLog-Thu.log.
Sample of the log file:
In this case the PC, BrokenPC, was in DNS listed with IP 192.168.1.213, but would not respond. The log file shows the MAC address in this example as 123456789123 so we added a reservation for this MAC to IP 192.168.1.213. We cleared all the BAD_ADDRESS entries in the scope. At this point, the DHCP scope is working but we still needed to find BrokenPC.
Finding the broken device
You may need to find a rouge device on the network, so it can be unplugged and/or repaired.
- The DHCP log file may have a recognizable name of the device. In our case we knew exactly where the computer named BrokenPC could be found.
- Review the arp cache of your switches to find the switch port that the MAC address in the log DHCP server log file.
- There are several sites that help you identify the manufacturer that uses the MAC address found in the log file. A couple of examples are https://www.wireshark.org/tools/oui-lookup.html & http://www.whatsmyip.org/mac-address-lookup/.
Note: These websites are from a 3rd party.
Keep your users connected and find that device causing the bad addresses in DHCP.
Need more information? Email firstname.lastname@example.org. We are happy to help.