BAD_ADDRESS listed in DHCP Server
It is a Windows 2019 Standard Server. In the DHCP Address Leases there are several that list the IP address followed by BAD_ADDRESS. I know from experience this mean there is a duplicate IP address somewhere doesn't it?
To start with does that mean it tried to assign the listed IP address to the listed MAC address but something else already had that IP Address?
It looks like a lot of them are phones on the guest network. So why would this happen?
Seth Simmons
something else is already using that address. even if you put a reservation, if something is already using it, it won't assign it. you need to find out what is using those addresses. you could have an overlapping dhcp scope somehow or the device has a really long lease and hasn't released it - or something could have it statically assigned
ASKER
I hate to be picky but I need to understand what I am look at. The bad address displayed has a IP and MAC. So when you see that it means "We tried assigning this IP to this MAC but couldn't because something else is already using that IP"?
In staring at it.... it look like the phones retained a previous IP. I implemented a "Guest Network" mid day. The phone got an IP this morning. I then implemented the "Guest Network" and when they reconnected to the "Guest Network" it tried getting a IP but some phone already had it from early morning. Is that more or less what might have happened?
If I delete all the current leases in the DHCP server it won't clear it from the phones will it?
In staring at it.... it look like the phones retained a previous IP. I implemented a "Guest Network" mid day. The phone got an IP this morning. I then implemented the "Guest Network" and when they reconnected to the "Guest Network" it tried getting a IP but some phone already had it from early morning. Is that more or less what might have happened?
If I delete all the current leases in the DHCP server it won't clear it from the phones will it?
Download IP Scanner, it's free. I recommend you run it rather than install it, mainly for security reasons. It may shed some light on duplicate IP's
You can do a couple things, you can segment different address ranges in your DHCP, for example, 192.168.1.1 - 192.168.1.10 are excluded, maybe these are hard coated and don't need DHCP. This way you never have to worry about duplicates.
You can also take IP's from the lease list in DHCP, right click and choose "Add to Reservation" which tags the IP with the computer name.
If I delete all the current leases in the DHCP server it won't clear it from the phones will it?No, you'll be fine.
You can do a couple things, you can segment different address ranges in your DHCP, for example, 192.168.1.1 - 192.168.1.10 are excluded, maybe these are hard coated and don't need DHCP. This way you never have to worry about duplicates.
You can also take IP's from the lease list in DHCP, right click and choose "Add to Reservation" which tags the IP with the computer name.
You cannot use the MAC address displayed with BAD_ADDRESS - that's (IIRC) just the hex representation of the IP address.
The system with the same IP will have an event in the system, application log reflecting that it saw a conflict that some system was using the same IP.
It will output the Mac Address of the other device.
You would need to look and identify the other device.
and properly address the IP conflict.
It will output the Mac Address of the other device.
You would need to look and identify the other device.
and properly address the IP conflict.
I'll just say, it sounds like the "corporate" and "guest" networks are using the same VLAN/subnet. You should really be using a different VLAN/subnet for the guest network at the very least. It's not very secure to allow guests onto your corporate network without some kind of protection.
Some DHCP devices may ask for the last IP address they had when they send the DHCP DISCOVER packet. If that is the case, the DHCP server will offer that IP address if it is free in the scope. This is usually fine as the DHCP server will simply offer a different IP if the requested IP is already leased.
If a device sends a unicast DHCP REQUEST though, rather than a broadcast, this is often where the problem lies. The DHCP server may have relinquished the IP back to the pool for lease, but when the client asks for the same IP, the DHCP server will use conflict detection to see whether the IP is in use on the network before it offers it. If ICMP is enabled on the device, the DHCP server sees an ICMP Echo Response and therefore thinks the IP is already used, so marks it as a BAD_ADDRESS, then offers a different IP address. An example of this is when a computer is put to sleep and wakes past its lease expiration time. It wakes up and still has an IP address, but tries to refresh the lease periodically. When that refresh happens (usually only a few sec after the device wakes), you see the BAD_ADDRESS.
The problem can also be caused when there is more than one DHCP server serving the network. If the DHCP servers have overlapping pools, this can cause the same issue.
Some DHCP devices may ask for the last IP address they had when they send the DHCP DISCOVER packet. If that is the case, the DHCP server will offer that IP address if it is free in the scope. This is usually fine as the DHCP server will simply offer a different IP if the requested IP is already leased.
If a device sends a unicast DHCP REQUEST though, rather than a broadcast, this is often where the problem lies. The DHCP server may have relinquished the IP back to the pool for lease, but when the client asks for the same IP, the DHCP server will use conflict detection to see whether the IP is in use on the network before it offers it. If ICMP is enabled on the device, the DHCP server sees an ICMP Echo Response and therefore thinks the IP is already used, so marks it as a BAD_ADDRESS, then offers a different IP address. An example of this is when a computer is put to sleep and wakes past its lease expiration time. It wakes up and still has an IP address, but tries to refresh the lease periodically. When that refresh happens (usually only a few sec after the device wakes), you see the BAD_ADDRESS.
The problem can also be caused when there is more than one DHCP server serving the network. If the DHCP servers have overlapping pools, this can cause the same issue.
ASKER
As expected the BAD_ADDRESS entries have pretty much disappeared today. That would support my theory that the phone were hanging on to previos IP addresses to long. Anyway... I am more concerned about unserdtanding what I am looking at on the DHCP Server. Is the bad_address below saying "I tried assigning IP address 172.18.3.114 to this MAC address 720312ac but couldn't because something else is already using that IP"?
Bad address means when the DHCP considered offering an IP, it was already in use. Pingable.
ASKER
You need to look at the screenshot above. See the bad_address?
What does the "Client IP Address" of 172.18.3.114 represent? The IP address it tried to pass out (or the duplicate)?
What does the "Unique ID" of 720312ac represent? The MAC address of the client request the IP, the MAC address of the duplicate IP or neither?
Look at the captions on the columns and tell me what they represent......
What does the "Client IP Address" of 172.18.3.114 represent? The IP address it tried to pass out (or the duplicate)?
What does the "Unique ID" of 720312ac represent? The MAC address of the client request the IP, the MAC address of the duplicate IP or neither?
Look at the captions on the columns and tell me what they represent......
The IP to the right of the BAD ADDRESS is the IP that had a conflict, two devices using the same IP.
Unique ID is supposed to be the Mac Address of the device who currently had the IP (the 720312Ac is not a valid Mac Address.
You could prefix it with 00:00:72:03:12:AC
An earlier suggestion was to use ip scanner, or a similar tool like nmap to scan your network
If you have managed switches access to the router, one option is to mark the Mac address as bad on the router while searching for it on the switch to try and determine which port it is seen on. then trace to the device.
Info based on Mac address/
https://maclookup.app/vendors/miniware-technology
Unique ID is supposed to be the Mac Address of the device who currently had the IP (the 720312Ac is not a valid Mac Address.
You could prefix it with 00:00:72:03:12:AC
An earlier suggestion was to use ip scanner, or a similar tool like nmap to scan your network
If you have managed switches access to the router, one option is to mark the Mac address as bad on the router while searching for it on the switch to try and determine which port it is seen on. then trace to the device.
Info based on Mac address/
https://maclookup.app/vendors/miniware-technology
ASKER
I have has an IP scanner for decades. The problem was getting an accurate description of what I was looking at. To be syntactically correct the IP is to the left of "BAD_ADDRESS" correct? The Biggie was the Unique ID and to confirm that is the MAC address of the device that already has that IP correct?
yes,
IP, bad address.
Well. you can do it one way or the other.
the DHCP would log a valid device, I'm not sure I've seen it before that A device did not properly present the Mac address as the 48bit data.
I'd start on the Switch to see if I can at least narrow down where this device might be while at the same time confirm the mac address.
what happens when you ping the IP, 172.18.3.114 then run arp -a 172.18.3.114.
What is reported for the Mac address of the device that has the IP?
A system commonly logs an event when another system is trying to use the same IP.
Another option you might have is on the firewall to lock the MAc address you want to have that IP.
IP, bad address.
Well. you can do it one way or the other.
the DHCP would log a valid device, I'm not sure I've seen it before that A device did not properly present the Mac address as the 48bit data.
I'd start on the Switch to see if I can at least narrow down where this device might be while at the same time confirm the mac address.
what happens when you ping the IP, 172.18.3.114 then run arp -a 172.18.3.114.
What is reported for the Mac address of the device that has the IP?
A system commonly logs an event when another system is trying to use the same IP.
Another option you might have is on the firewall to lock the MAc address you want to have that IP.
As I wrote above, the "MAC address" is just the IP:
0x72 = 114
0x03 = 3
0x12 = 18
0xac = 172ASKER
OK. This is why I keep asking and hammering. One person says it is the MAC Address. One says IP. So it is the complete IP but in reverse order? Is it IP only with respect to BAD_ADDRESS? on all the other entries it is indeed MAC?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Wow. That was exhausting. Thanks Gents.
I so not understand the confision.
The issue you are having is two separate and distinct devices using the same IP address 172.18.3.114.
The DHCP server reports the device that has the IP is held by a device that has the mac address 00:00:72:03:12:AC
The issue is to identify the second device.
One optio. is to create a reservation for this MAC address to use a different IP. This way you eliminate the current conflict.
OK. This is why I keep asking and hammering. One person says it is the MAC Address. One says IP. So it is the complete IP but in reverse order? Is it IP only with respect to BAD_ADDRESS? on all the other entries it is indeed MAC?
The issue you are having is two separate and distinct devices using the same IP address 172.18.3.114.
The DHCP server reports the device that has the IP is held by a device that has the mac address 00:00:72:03:12:AC
The issue is to identify the second device.
One optio. is to create a reservation for this MAC address to use a different IP. This way you eliminate the current conflict.
The DHCP server reports the device that has the IP is held by a device that has the mac address 00:00:72:03:12:ACThat's wrong and confusing, see last comments.
Qlemo,
Correction noted, unique shows 114.3.18.172 in hex.
Correction noted, unique shows 114.3.18.172 in hex.
If you run nslookup 172.18.3.114
What do you get?
Brute force, take a system and set it to static with this ip: 172.18.3.114
Then look at the application/system event log on win 10 it might also generating a notification when that IP is used.
The event log will include the mac address of the other systems.
Using that it might help you track them down.
What do you get?
Brute force, take a system and set it to static with this ip: 172.18.3.114
Then look at the application/system event log on win 10 it might also generating a notification when that IP is used.
The event log will include the mac address of the other systems.
Using that it might help you track them down.