• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4083
  • Last Modified:

Bad Addresses in DHCP keep coming back

Hello. This problem has been bugging me for the last few months and I can't seem to find any good info on why I am getting this problem or how to fix it.

Here is the problem:
We have 3 Domain Controllers, 2 of which are DHCP servers, all running Server 2003 SP-2 Standard Ed. Both DHCP servers have a range from 192.168.2.1 to 192.168.3.254. Server "A" excludes addresses 192.168.2.1 through 192.168.3.0. Server B excludes addresses 192.168.3.0 through 192.168.3.254.

Now, we have about 140 DHCP reservations for certain PCs on the network.  The reservations are created on both DHCP servers.  We have been seeing a number of reservations turn to "BAD_ADDRESS" on one server and we are left to recreate the reservation. Any thoughts?

P.S. If you need any other info I forgot to add please let me know.
0
chkdsk01
Asked:
chkdsk01
  • 6
  • 5
  • 2
2 Solutions
 
theras2000Commented:
Are these servers on the same LAN?  Because that means that when a client asks for a lease, but servers will respond (one with a random IP and one with a reserved IP).  This may have something to do with it.  DHCP servers should be on one LAN and have each scope designated to one LAN.
Another question.  What IP ranges do your servers and other static devices sit in BTW?
See here http://support.microsoft.com/kb/325919 describes bad addresses happening when a multihomed DHCP has both NICs connected to the same LAN, which would be similar to what I'm guessing your enviro is.
0
 
chkdsk01Author Commented:
Yes.  These servers are on the same LAN.  We have a single subnet, class B, flat network.

Both DHCP servers initially have the DHCP reservation.  Then one of the servers will say "BAD_ADDRESS" and the reservation needs to be recreated on the one server.  I see no rhyme or reason to which ones go bad.  It's not the same addresses every time.

Servers and static devices are in the 192.168.1.xxx range.

And I checked out that MS KB article.  We do not have multihomed DHCP Clients nor are we running windows 2000.  All servers are 2003 and all clients are a mixture of XP Service Pack 1 and 2
0
 
SimonL-UKCommented:
Generally, BAD_ADDRESS means that a client already has an address.
What are your scope lease times? Are they identical on both DHCP servers?
Are static resverations mirrored across both DHCP servers?
Are your domain controllers multi-homed - if so, this is not a recommended configuration.  
Within DHCP, do you:
1. have conflict detection turned on?
2. Increase the number of conflict detection attempts

Also, are your DHCP database and log files excluded from any on-access virus scanning?

HTH

0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
chkdsk01Author Commented:
Simon -
Lease times are 3 days and are the same on both servers.  The DHCP reservations are initially the same on both servers until one changes to a bad address.  Domain Controllers are not multi-homed and conflict detection is turned off on both servers.  Is it recommended to turn it on?

And DHCP databases and logs are excluded from AV scanning.

The strange thing is that that I have been reading about people getting BAD_ADDRESS in their DHCP Address Pool but they never mention it is an address they have reserved.  The BAD_ADDRESS only seems to happen with addresses that have a reservation set.
0
 
SimonL-UKCommented:
Yes, turn on conflict detection - if you have two servers on the same subnet, they could both be offering a valid DHCP address but the client is not completing the DHCP handshake i.e. sending a DHCP Decline message.  Set this to 2 to start with and monitor the DHCP logs located in %systemroot%\system32\dhcp\- they will be named DhcpServerLog.<day of week>.
Also, ensure that your network card is hard-coded to match the switch port speed and the device driver is up to date.
If you are on a busy network, increase your Tx and Rx buffers (sometimes known as coalesce buffers or transmit descriptors on the network card) on the servers.
Over-loaded legacy hubs can also give this issue as the DHCP decline message will not return in time to the DHCP servers...
0
 
theras2000Commented:
I know you don't have a multi-homed DHCP, but you have created an environment that is almost the same by having 2 DHCPs on the one LAN.
Try this:
Find a computer which has a reservation that has turned into a bad address on DHCP server A.
Ipconfig /release the IP on the client.
Stop the DHCP service on DHCP server B.
Ipconfig /renew on the client.
Has it now got the correct IP from DHCP server A?
0
 
chkdsk01Author Commented:
Here is a clip of the logs that recorded the error. Anyone able to decipher what's happening?
I blurred out the Machine Name for security purposes.

DHCP.jpg
0
 
SimonL-UKCommented:
NACKs (negative aknowledgements) can occur when you have multiple DHCP servers and one of the DHCP servers out of available addresses. If the server gives out all the available addresses, and then receives a DHCPREQUEST from the offer of another server on the same segment, it will send a NACK in response to the request.
Check your scope(s) for adequate addresses
0
 
SimonL-UKCommented:
Oh, reconcile your database to check for any inconsistencies
0
 
chkdsk01Author Commented:
I did reconcile the scopes and they were ok.

I inherited this network but as I understand it the two DHCP servers are setup for high availablity and redundancy.  We have two DHCP servers setup with the same scope (192.168.0.0) with the same server pool, and with reciprocating exclusions.

Ex.
Server A Server Pool ---> 192.168.2.1 - 192.168.3.254
Server B Server Pool ---> 192.168.2.1 - 192.168.3.254

Server A Exclusions ----> 192.168.2.1 - 192.168.3.0
Server B Exclusions ----> 192.168.3.0 - 192.168.3.254

We also have a number of machines that must not be allowed to have internet access so our solution was to create DHCP reservations and remove the router (gateway) from it.

These reservations were mostly being created on one server but we were seeing that occasionally the client would pickup DHCP from the other server where the reservation didn't exist and it would have internet access.  So, in response we replicated the DHCP reservations on the second server.  

The next issue we are seeing are the bad addresses.  The only trend I notice is that Client "C" would have a reservation for 192.168.2.100 would get it's reservation from Server B and the BAD_ADDRESS would appear on Server A.

Make sense?  It seems like our setup is correct but any advise would be welcmed.
0
 
SimonL-UKCommented:
That does make sense.
When a client attempts to obtain an address via DHCP, both servers will answer with a DHCPOFFER packet.  The client will respond with a DHCPREQUEST to only one server and will take an address from the pool.  For the other server, you will see a NACK packet in the DHCP logs as it never recieved a response back from the client - this will show up as a BAD_ADDRESS.  These can safely be deleted.
Ensure you create the reservations on both scopes for DR purposes
0
 
chkdsk01Author Commented:
So it sounds like there is no way to stop the bad addresses from appearing on the 2nd server?
0
 
SimonL-UKCommented:
That's correct - it's normal behaviour when you have multiple DHCP servers on the network, especially on the same network
0

Featured Post

Microsoft Certification Exam 74-409

VeeamĀ® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

  • 6
  • 5
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now