Why is Your Windows DHCP Server Filled with BAD_ADDRESS Entries?

Open the Windows DHCP console, find dozens or hundreds of addresses showing as BAD_ADDRESS, and the obvious reaction is to clear them. That’s usually the wrong move. A BAD_ADDRESS DHCP entry means something decided the address shouldn’t be handed to a client, and deleting the entry removes the record, not the reason.

So the useful question isn’t “how do I clear the BAD_ADDRESS entries?” It’s “what detected a conflict, and why?” Two separate mechanisms produce these entries, and knowing which one you’re dealing with changes where you look:

• Client-side duplicate address detection. A DHCP client receives an address, discovers something else is already using it, and sends a DHCPDECLINE. The server records the address as bad.
• Server-side conflict detection. The Windows DHCP server checks an address before leasing it. This is controlled by the ConflictDetectionAttempts setting, and it’s disabled by default.

That second point explains most of the confusion around this problem.

What BAD_ADDRESS actually means

In the DHCP console, a bad address is one that DHCP considers unavailable because a conflict was detected. PowerShell calls these bad or declined leases, and their AddressState is normally Declined. To find them across the whole server:

powershell

Get-DhcpServerv4Lease -BadLeases

Or for one scope:

powershell

Get-DhcpServerv4Lease -ScopeId 192.168.10.0 -BadLeases

Microsoft’s Get-DhcpServerv4Lease documentation confirms that using -BadLeases without -ScopeId returns the bad leases from the entire server.

One detail worth knowing

You’ll often read that a bad address is blocked permanently until you clear it manually. The same Microsoft documentation says otherwise: a lease in the declined state isn’t offered to any client until a timer expires, and that timer is 10 minutes.

In practice, administrators routinely see BAD_ADDRESS entries persist far longer than ten minutes. That suggests either the conflict keeps recurring, or the console is showing historical records rather than active blocks. Either way, it’s worth knowing the documented behaviour before you assume a stale entry is blocking an address you need.

DHCPDECLINE versus server-side conflict detection

Client-side duplicate address detection

The sequence looks like this:

text

DHCP server
    |
    | DHCP OFFER
    v
Client receives 192.168.10.50
    |
    | Gratuitous ARP
    v
Client finds 192.168.10.50 already in use
    |
    | DHCPDECLINE
    v
DHCP server
    |
    v
Address recorded as Declined / BAD_ADDRESS

Windows clients perform duplicate address detection with a gratuitous ARP before they finish configuring a DHCP-supplied address. If anything replies, the client declines the address. The DHCP server never has to detect the conflict itself, because the client does.

Server-side conflict detection

Windows DHCP has its own check, and it’s off by default. To see the current setting:

powershell

Get-DhcpServerSetting | Select-Object ConflictDetectionAttempts

According to Microsoft’s Set-DhcpServerSetting documentation, the default value is 0, which means conflict detection is disabled. Values of 1 to 5 set the number of attempts. To enable a single attempt:

powershell

Set-DhcpServerSetting -ConflictDetectionAttempts 1

Each attempt is a ping sent before the address is offered. Microsoft’s guidance on enabling address conflict detection notes that each extra attempt delays the server’s response by about a second while it waits for the ping to time out, and recommends no more than two. One or two is plenty; higher values mostly add latency.

Treat conflict detection as a safety net, not a fix. If a static device is sitting inside your DHCP pool, enabling conflict detection doesn’t solve that. It just makes DHCP more likely to notice before handing the address to someone else.

Why this matters with hundreds of bad entries

Say ConflictDetectionAttempts is 0 on your server and you have 200 BAD_ADDRESS entries. The natural question is: if the server isn’t checking addresses, where did these come from? The answer is the clients. Each one received an address, found it in use, and declined it, and the server recorded every decline. Server-side conflict detection was never involved.

That’s the single most useful thing to understand here, because it immediately redirects the investigation away from the DHCP server and towards whatever is answering on those addresses.

What makes a client decline an address?

Something else is using it, or appears to be. The interesting part is what that something is.

A static IP inside the DHCP scope

This is still the most common cause. Say your subnet is planned like this:

Someone configures a printer with 192.168.10.75, inside the DHCP pool. DHCP has no idea. Eventually it offers .75 to a client, the client’s duplicate address detection gets a reply from the printer, the client declines, and the server records a bad address. You clear it, and a few days later it comes back. That’s why deleting entries doesn’t work: the printer is still there.

A device moved into the DHCP range

The device doesn’t have to have been misconfigured in the first place. Someone may have changed a subnet, replaced a switch, moved a device between VLANs, restored from backup or resized the DHCP scope, and an address that was safely outside the pool is now inside it. Compare the current DHCP scope against your static addressing plan, rather than only looking at the DHCP server.

Reservations confused with static addresses

They’re not the same thing. A reservation tells the DHCP server to give a particular client a particular address. A static configuration tells the device to use an address regardless of what DHCP says.

Reservations keep the DHCP server as the source of truth, so the address can’t be handed to anyone else. For devices that need a predictable address but can use DHCP, a reservation is nearly always the better choice.

A cloned or restored system

Badly cloned VMs can end up with duplicate MAC addresses, duplicated machine configuration or copied virtual network adapters, and restored snapshots can reintroduce an address the network has since reallocated. It’s worth checking, but don’t jump straight to it. First establish whether the address is genuinely being claimed by more than one device.

Network infrastructure causing a false positive

This one is easy to miss, because the device that triggers the decline isn’t using the address at all. It’s your network infrastructure. Layer 3 switches and routers with IP Device Tracking send ARP probes, and if one arrives while a Windows client is doing duplicate address detection, the client concludes the address is in use and declines it.

Microsoft documents this exact false positive in its article on Event ID 4199 and clients that can’t get an address. It notes you’ll see many BAD_ADDRESS entries in the DHCP audit logs, and the fix is to disable IP Device Tracking or delay its ARP probes. Cisco’s Troubleshoot Duplicate IP Address 0.0.0.0 Error Messages recommends the probe delay as the primary method, using ip device tracking probe delay 10, which gives Windows time to finish its check. Aruba’s client-tracker feature causes the same pattern, and has an equivalent probe-delay setting. On newer IOS XE releases, device tracking is configured differently, so check the equivalent setting for your platform.

The lesson is that a DHCPDECLINE doesn’t prove another endpoint has the address configured. It proves something replied. Those aren’t the same thing, and chasing a phantom device because of a switch feature wastes a lot of time.

Rogue DHCP servers are a different problem

It’s worth separating these, because they get conflated. A rogue DHCP server causes clients to receive unexpected addresses, subnet masks, gateways or DNS servers, which is a different symptom from BAD_ADDRESS entries. On a client, run:

cmd

ipconfig /all

The DHCP Server line shows which server supplied the configuration. If it isn’t yours, you have a rogue. To list the servers authorised in Active Directory:

powershell

Get-DhcpServerInDC

That tells you what’s authorised. It won’t discover unauthorised servers, because by definition they aren’t in the list. To find one, a packet capture showing multiple DHCP Offers will identify the source. DHCP snooping on managed switches prevents the problem rather than detecting it after the fact.

Finding the device causing the conflict

This is where the work actually pays off. Start with the bad leases:

powershell

Get-DhcpServerv4Lease -BadLeases |
    Select-Object IPAddress, ClientId, HostName, AddressState

Pick an address and ping it. If something answers, get its MAC address:

cmd

ping 192.168.10.75
arp -a 192.168.10.75

text

Interface: 192.168.10.20
  Internet Address      Physical Address      Type
  192.168.10.75         00-11-22-33-44-55     dynamic

Now you have something to work with. Look up the first three octets of the MAC address in an OUI database. That won’t tell you which physical device it is, but it turns “something is using this address” into “this looks like a printer” or “this is a virtualisation vendor”, which narrows the search considerably.

If the device is on a managed switch, search the MAC address table. On Cisco IOS:

text

show mac address-table address 0011.2233.4455

That gives you the switch port, and from there you can work through the topology until you find the device. Ten minutes of this beats months of clearing leases.

If the address doesn’t respond to ping

A silent address doesn’t prove it’s unused. Windows Firewall blocks ICMP by default on many profiles, network appliances often ignore ping, and the device might be switched off, used only intermittently, or the conflict may have resolved before you looked. Check ARP anyway, or generate some traffic to the address first and then inspect the cache. For a stubborn case, a packet capture is far more informative than repeated pings from one workstation.

Check the DHCP audit logs

Windows DHCP writes audit logs to %windir%\System32\dhcp, with one file per day of the week, such as DhcpSrvLog-Mon.log and DhcpSrvLog-Tue.log. Conflict entries appear with ID 13:

text

13,11/22/19,09:30:43,Conflict,10.2.29.108,BAD_ADDRESS,,,0,6,,,,,,,,,0

These are DHCP audit log IDs, not Windows Event Viewer event IDs. The two numbering schemes are unrelated, and mixing them up sends people looking in the wrong place.

The logs are useful for establishing when the conflicts happened. A burst of entries one afternoon points at a change made that day. A steady trickle over weeks points at a device that’s been there all along.

Clearing bad leases

Once you’ve investigated and fixed the cause, remove the bad leases. For all bad leases on the server, or for one scope:

powershell

Remove-DhcpServerv4Lease -BadLeases
Remove-DhcpServerv4Lease -ScopeId 192.168.10.0 -BadLeases

Microsoft’s Remove-DhcpServerv4Lease documentation confirms that -BadLeases without -ScopeId removes bad leases from every scope on the server.

If you’d rather pipe, note that -BadLeases belongs on the Get cmdlet, not the Remove. The objects coming down the pipeline are already the bad leases, and adding -BadLeases to the Remove as well changes which parameter set it uses. Use -WhatIf first if you’re unsure:

powershell

Get-DhcpServerv4Lease -BadLeases | Remove-DhcpServerv4Lease -WhatIf
Get-DhcpServerv4Lease -BadLeases | Remove-DhcpServerv4Lease

Don’t clear first

If you have 200 bad addresses and delete all 200 straight away, you’ve destroyed the evidence. The better order is to identify several affected addresses, check when they appeared, determine whether they’re really in use, find the device or condition causing it, fix that, and only then clear the leases. Afterwards, watch whether new ones appear. That last step is how you know you actually fixed it.

A troubleshooting workflow

Start by counting the bad leases per scope:

powershell

Get-DhcpServerv4Lease -BadLeases |
    Group-Object ScopeId |
    Select-Object Name, Count

Whether it’s one scope or several is the first fork in the road. Then list them and look for patterns:

powershell

Get-DhcpServerv4Lease -BadLeases |
    Select-Object ScopeId, IPAddress, ClientId, HostName

Clustered addresses suggest a range someone has assigned statically. Scattered addresses across a scope suggest something else, such as infrastructure probes.

Next, check the server setting with Get-DhcpServerSetting. If ConflictDetectionAttempts is 0, the server didn’t create these entries. The clients did, so look at what’s on the wire rather than at the DHCP configuration.

Then investigate one address properly. Ping it, check ARP, get the MAC address, look up the vendor and trace it to a switch port. One fully traced address often explains the whole pattern.

Use the audit logs to establish when the conflicts occurred and whether they’re still happening or historical. Match the timing against recent changes such as switch replacements, VLAN moves, scope changes or new equipment.

Compare the affected addresses against your static devices: printers, cameras, firewalls, switches, access points, servers, hypervisors, appliances and lab equipment. Most organisations have an addressing spreadsheet somewhere that’s out of date, and that’s usually where the answer is.

If the addresses appear genuinely unused, look at the infrastructure: IP Device Tracking or client tracking on Layer 3 switches, ARP inspection, DHCP snooping, firewalls and segmentation. Bad addresses scattered across a scope with nothing answering on them strongly suggest switch ARP probes rather than real devices.

Finally, fix the cause before clearing anything. Then remove the bad leases and keep watching. If new entries keep appearing, the cause hasn’t been found yet.

Designing the scope to avoid this

Most of this problem disappears with a clean scope design. The exact ranges in your addressing plan don’t matter much, but the separation does. Static addresses should never overlap the DHCP pool, and if a static range has to move, resize the scope or add exclusions first so the two never overlap.

For devices that need a predictable address but support DHCP, use a reservation in the scope rather than configuring the address on the device. That keeps the DHCP server as the authority on what’s allocated, gives you central visibility, and makes it far easier to redesign the scope later.

BAD_ADDRESS is information, not a fault

A scope full of bad addresses doesn’t mean DHCP is broken. It usually means DHCP is telling you something about the network. The questions worth asking are why the address was considered in use, whether a client sent a DHCPDECLINE or the server detected the conflict itself, and whether server-side conflict detection is even enabled. Then ask whether there’s a static device inside the pool, whether network infrastructure is generating ARP probes, whether a cloned or restored device is involved, whether the problem is confined to one VLAN, and whether it started after a change.

The distinction that matters most is that the DHCP server doesn’t have to be the thing detecting the conflict. With server-side conflict detection disabled by default, the clients are usually doing the detecting, and the server is just recording what they told it. Once that’s clear, BAD_ADDRESS stops being a list of red entries to clean up and becomes a fairly precise pointer to something on the network that isn’t where the addressing plan says it should be.

BAD_ADDRESS troubleshooting checklist

1. Count the bad leases per scope with Get-DhcpServerv4Lease -BadLeases, and note whether they’re clustered or scattered.
2. Check ConflictDetectionAttempts. If it’s 0, the clients created these entries by declining the addresses, not the server.
3. Pick one affected address, ping it, check ARP, look up the MAC address vendor and trace it to a switch port.
4. Check the DHCP audit logs for ID 13 entries to establish when the conflicts started and whether they’re still happening.
5. Compare the affected addresses against your static addressing plan and any recent network changes.
6. If nothing is answering on the addresses, check for IP Device Tracking or client tracking on Layer 3 switches, and apply the probe delay if it’s in use.
7. Fix the cause, whether that’s moving the static device out of the pool, converting it to a reservation, or adjusting the switch configuration.
8. Clear the bad leases with Remove-DhcpServerv4Lease, using -WhatIf first.
9. Watch for new BAD_ADDRESS entries over the following days to confirm the fix.
10. Consider enabling one or two conflict detection attempts as a safety net, not as the fix.

Microsoft and Cisco references

• Get-DhcpServerv4Lease – retrieving bad and declined leases, and the ten-minute declined timer
• Remove-DhcpServerv4Lease – clearing bad leases by scope or across the server
• Set-DhcpServerSetting – configuring conflict detection attempts
• Event ID 4199: Windows client can’t get an IP address from the DHCP server – IP Device Tracking ARP probes causing BAD_ADDRESS entries
• Cisco: Troubleshoot Duplicate IP Address 0.0.0.0 Error Messages – the switch-side fix using the IP device tracking probe delay

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.