DHCP BINDING-ACK message
One of my domain controllers (Windows Server 2012 R2 Standard) is logging the following event to event viewer every 5 minutes:
and although the event ID matches what is being discussed, neither of the two issues listed make sense in my environment. I don't have any reservations set, and these servers were not migrated.
I also found this:
but the reject reasons listed are different from mine so I'm not sure if the hotfix still applies or not.
Any suggestions on how to fix this error?
A BINDING-ACK message with transaction id: 1234 was sent for IP address: x.x.x.x with reject reason: (Illegal IP address (not part of any address pool)) to partner server: server1.domain.local for failover relationship: server1.domain.local-serveThe event ID listed is 20291. It's the same IP address in every event but I'm not sure why. That IP isn't in use and isn't showing up in DNS at all. I have found the following:r2.domain. local.
and although the event ID matches what is being discussed, neither of the two issues listed make sense in my environment. I don't have any reservations set, and these servers were not migrated.
I also found this:
but the reject reasons listed are different from mine so I'm not sure if the hotfix still applies or not.
Any suggestions on how to fix this error?
ASKER
If the device is wanting to use that IP address would that mean it's been statically assigned to it? Because we allow static IPs on the network so why would I get a reject message for this device but no others that are statically assigned? I checked the arp tables on the switch but don't see anything with that address listed at all.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm wondering if it's an issue with failover. We do have 2 DHCP servers set up, one as primary and one as hot standby. The address in question is part of the scope on server 1, but not on server 2. (the one with the error) How does that happen? Should those scopes match exactly? Because I'm not sure why they don't.
ASKER
DHCP failover needed to be reconfigured.
That's why you see the reject. after a reject the system needs to ask for a valid address, not attempt the wrong request again.
so you need to identify the system that does it wrong... Now the MAC adress of the requester can be traced by looking at the MAC/CAM address tables on your switches (if you have managed switches that is). And identify on which port the culprit lives.