DHCP Scope: Full of BAD_ADDRESS Entries

KB ID 0001651


I had a client machine struggling to get an DHCP address, and when I looked in DHCP the scope it was full of this;

BAD_ADDRESS This address Is Already in Use


A tour of Google and forums is full of posts by people with this problem, and other than, ‘Oh I looked in the logs and fixed it’ (with no mention of what log, or where this log was), or ‘Yeah I used Wireshark and located a problem client‘, then no follow up on what they did, or scanned for. So I pretty much had to slog through and work it out for myself. I’ll detail each step I took below, most of which didn’t help, or sent me in the wrong direction, but for you that may be a better solution.

And I will give you enough information to at least be helpful!

Firstly Common Sense Check: If this has just happened what have you changed? Have you added any Wireless Controllers, or Access Points? Have you deployed any new Switches or Firewalls. In my case, it was my test network so it could have been happening for months!

The most frequent cause of this error is simply because someone has setup another DHCP server on the network. That will be easy to diagnose, simply ‘Stop’ your DHCP Server;

Stop DHCP Server

Then on a DHCP client, issue an ifconfig /release and ifconfig /renew, If it gets an IP address, issue an ifconfig /all and look for the IP of the DHCP server it’s using, that’s your culprit. However as you can see, mine didn’t get an IP address so this wasn’t my problem.

Test for Rougue DHCP

The next most popular suggestion is to enable ‘Conflict Detection‘, though in most places the information on where to find this, is incorrect, (as it’s been copied and pasted around the forums without actually checking it!) See below, you locate it on the properties of the Protocol not the Server > Advanced Tab > You are supposed to set it between 1 and 6 so I went for 5, (but after deleting all the BAD_ADDRESS entries, they were all back after 30 minutes or so, so this didn’t work for me either).

Test for Rougue DHCP

Look in the logs: Well they were useless also, DHCP creates a new log every day in C:\Windows\System32\Dhcp called ‘DHCPSrvLog-DAY.log’ as you can see it was not helpful.

Test for Rougue DHCP

At this point I put my networking head on, and ‘thought outside the box’, If DHCP is detecting these as BAD ADDRESSES, then they must be in the arp cache on the DHCP server right? Well look at this;

arp -a


Well that’s encouraging, at least now I’ve got a suspect MAC address, lookup up that MAC address online, and it comes back as VMWare (which sent me off in the wrong direction, it was not a VMware virtual machine in my vSphere in the end). Ive got a decent Cisco Switch so I thought I’d see which interface it was connected to, (but it wasn’t there).

show mac address-table

Check MAC Address on Switch

At this point I was still thinking it was a VMware virtual machine, so I used PowerCLI (Thats PowerShell for VMware), to query for that MAC address, but that revealed nothing.

Find VM By MAC Address

So, my last hope was Wireshark, I fired it up on the DHCP server, and set the filter to;

bootp.option.type == 53

Then I deleted all the BAD_ADDRESS entries, left Wireshark ‘sniffing’, and went for lunch. I returned to this (see below). Now 192,168,100,107 was one of the BAD_ADDRESS entries, and I did not know what it was. The other entries on there for are understandable, (that’s my DHCP server!) So now I had a Layer 3 address to hunt.


When I RDP connected to it, I got prompted for a password, so now I know it’s a Windows box! I hunted all through my VMware virtual machines, it was not there. Just as an afterthought I remembered I have a Hyper-V server, could that be running a virtual machine? BOOM! There is is SCVMM server, I was using for some Zerto testing a couple of months ago! Turned it off, problem solved!


Hope you find your culprit quicker than I did!

Related Articles, References, Credits, or External Links


Author: PeteLong

Share This Post On


  1. Fantastic methodology. Thanks for sharing!

    Post a Reply
    • Thanks David, I try to write the articles I’d like to find 🙂

      Post a Reply
    • Awesome. Thanks for this article!

      Post a Reply
  2. Hi tnx for this helpful article. One question: when i use the command arp -a it just displays only a few IPs which have nothing to do with acutal IP addresses in my scopes… Is there any other way I could obtain the real MAC address from the DHCP leases?

    Post a Reply
    • arp -a will only show addresses on your ‘directly connect layer 2 network’, if you are on a different range then you need to put yourself on the same VLAN as the DHCP scope (or a VLAN with a DHCP helper of course).

      Post a Reply
  3. I have same situation. Ip adress end. DHCP logs help me find problem with Kyosera 1035 MFU. He take Ip adress, after that some error, and take another IP adress until adresses ended.

    Post a Reply
  4. Thanks for the info this really help with a troublesome Mac computer, I found a repetition of MAC Addresses with the arp -a command that made it easier to find the culprit


    Post a Reply
  5. Thank you very much for your sharing and records, wish you have a nice day 🙂

    Post a Reply
  6. Thank you so much! Same issue, but with a different BOOM! In my case it was a LANCOM access point that caused this stupid behavior.

    Post a Reply
  7. I ran through the same process. I’m a little new to wireshark but when I ran it with the command, I get for my output the DHCP server and also the address for all of the other entries.

    I looked at the entries and it seems to be a switch, an access point, and maybe a workstation. Not sure why I would get a address instead an address within the subnet. Any ideas? Any other filters or such I can try?


    Post a Reply
  8. A big thank you for this article ! It’s been 24 hours since I found the cause and thanks to you I was able to find the VM that was polluting


    Post a Reply

Submit a Comment

Your email address will not be published. Required fields are marked *