DHCP probs with multiple LAN subnets

I have two NT 4.0 servers running on the same physical ethernet. Both have DHCP servers enabled - one server handles subnet x.x.20 and the other handles x.x.21.

When a Win95 client boots and request DHCP addresses, both
servers attempt to offer an address. The client (correctly) tries the
first address offered, but when the client tries to claim the address
given by one the server, the other server NACKs it.

Example (from a ethenet trace):

Client --DHCP req.-->broadcast
ServerA-offer on subnet 20->Client
ServerB-offer on subnet 21->Client
Client--Attempt address offered by ServerA->ServerA
ServerB-DHCP NACK-->Client
ServerA-DHCP ACK->Client

Unfortunately, the client sees the first NACK (from the wrong server!) and gives up on the attempted address, even though serverA attempts to ACK it.

Curiously, the DCHP transaction number NACKed by serverB wasn't even address to the serverB!

What am I doing wrong?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

What are the IP Addresses of the Servers? Are you using WINS?
JJanculaAuthor Commented:
ServerA: x.x.20.9 (and sometimes multihomed, for testing x.x.21.9)
ServerB: x.x.21.241 (and sometimes multihomed, for testing x.x.20.241)

Both servers run WINS and WINS-proxy.

Both are NT 4.0, service pack 2

1. Do you have a router?
2. Do you have DHCP on each side of the router?
3. Do you have the same ip scope split between the two DHCP servers on each side of the routers?( you might not want to do that ): )
Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

JJanculaAuthor Commented:
1. Yes, we have routers-many in fact, but the local routers only have 1 network interface. All routers are on the same ethernet LAN, the routers do not segment the LAN.

The ONLY reason we have local routers is because we ran out of class C address space. If we could redesign our subnet mask (and, boy do I wish we could!), this problem would completely go away - we don't really need 2 subnets otherwise, but that's a different (political) problem.

Our WAN router connects our LAN to a frame cloud. There is no DHCP into the frame.

2. Since there is only one LAN and the local routers don't have two sides, DHCP exists on only one side of the routers.

3. IP scopes are split so that one DHCP server handles subnet x.y.20 and the other handles subnet x.y.21. There is NO scope or subnet overlap.

What subnetmasks have you connfigured on the dhcp-servers?

JJanculaAuthor Commented:
Like I said, we're using Class C addressing styles, so subnet masks everywhere in our network are
I've been reading the situation again, and it occured to me that I've read somewhere that only one dhcp server should be implemented on each physical subnet. This might be to prevent just the problems you are referring to. If I understood correctly, you have one *physical* subnet, with two *logical* subnets defined. (Correct?)

I'll first try to explain what is happening:
When booting, a client either asks for confirmation for extending the lease for it's previously used adress, or asks for a new lease. When the latter occurs, the client gets offered an adress in net x.y.20.0 by server A. (by given example) When it acknowledges that adress, it does the same as when booting, and trying to lease the same adress as the previous time; it asks for a confirmation to use the given adress. Server B will deny this adress, because it does not fall within its defined scopes.

The reason that server B 'butts in' is beause it can see, by analysing the IP-packet, that the requesting client is on the same physical subnet. Server B assumes it is the only DHCP server on that physical subnet, and the requested adress is not part of its defined (and active) scopes.

A DHCP server can see if a requesting client is part of the same physical subnet, because a router either blocks BOOTP requests (and thus, the lease request never reaches the server) or a router forwards it, but adds information regarding the original subnet the request came from. A DHCP request with no router info added, has to be originated from the same physical subnet.

In short, I would say you are in trouble. Moving both DHCP ranges to one server, won't work. This is because the DHCP server will lease only those adresses to clients from the same physical subnet that have a corresponding logical subnet to that of the server. (i.e. The server with adres x.y.20.z will only 'deal out' adresses from scopes with subnet x.y.20 to local clients.)

The best solution I can offer is to try to define your subnet as being a B-class, with the subnet-mask set in such a way to mask out exactly your two C-class nets.
I guess that would make your subnetmask, but please check this before implementing.
After that, you should be able to create the two scopes you desire, (on one server, mind you)

Another thing to try is to chop your net in two, and put a router between the remains. :-) But I guess that's not an option.

Well, I hope this gets you going.

JJanculaAuthor Commented:
NT 4.0 Service Pack 2 adds a DHCP feature called "Superscopes" that explicitly allows multiple logical subnets on the same physical (non-routed) wire. I think that's where the problem is.... Some code changes broke multiple DHCP servers on the same ethernet.

You're right in explaining that the 2 servers "fight" each other for the right to lease or verify an address. For this reason, we will abandon this approach.

But, when a TRANSACTION number is assigned to a DHCP conversation, the server that is not involved in the transaction should not have the right to NACK it (IMHO).

Anyway, we're going to work around it by putting all of our scopes in one server  - I'll post how in another reply.

Using bogus subnet masks to extend the scope range doesn't work because DHCP clients (Win95 workstations) learn their subnet mask as defined in the DHCP server, so everyone's subnet mask we become wrong.

And yes, we've seriously thought about putting in a router - but that seems like overkill when the basic problem is just lack of address space.

Thanks to all for trying to answer this, I was hoping someone else has successfully done it.
JJanculaAuthor Commented:
We got around this problem by switching to a single DHCP server...

We installed 2 ethernet cards in the NT server. This first card's address is on subnet 20, the second card is on subnet 21. IP forwarding (routing) is enabled. DHCP relay is not installed. DHCP scopes for both subnets are defined.

Now the server leases addresses from subnet 20 until it has no more addresses, then it begins leasing subnet 21 addresses.

The only problems with this approach are:

1. Single point of failure (only 1 DHCP server). We compensated for this by setting longer lease times (i.e., 30 days means we have about 15 days to recover a lost DHCP server).

2. If a Win95 client obtains a subnet 21 address, then later obtains a subnet 20 address, the first address (subnet 21) is not automatically released. We compensated for this by setting shorter lease times. (Originally, we were going with 300 days).

If anyone wants to claim the points, post any answer - since I can't seem to answer this myself.
If your basic problem is adress space, you could switch to using one of the private IP address space schemes, namely 10.x.x.x which is an A-class adress block.
(I know that's a lot of effort, but the fact theat you're using DHCP will ease that.)

The only requirement of the scheme is that noe of the addresses may hit the internet.  This just means that you use a masquerading firewall box, which converts the internal corportate numbers into your "internet valid number" as transactions go through.   This is a technique I use for several of my clients - it keeps the cost of extra adress blocks down too.

Worth thinking about if it reduces you managment costs.

I Had the same problem with an Nt 3.51 Dhcp Server , and an Nt 4.0 Dhcp Server.

Both was running fine until i applied SP1 on the Nt 4.0 ,
than all of a sudden the 4.0 was nack'ing the answers from my
3.51 Server , even though it had no scopes in that range.

The solution is to go to SP2 on the NT 4.0 , or back out of SP1.

Remember to get the hotfixes for SP2 , that was released after
SP2 , as some of them are IMPORTANT !!!!.

I Haven't tried out SP3 yet , but are gonna try it within a week or so.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Networking

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.