DHCP probs with multiple LAN subnets

Posted on 1997-03-10
Last Modified: 2013-12-23
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?
Question by:JJancula
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 1559284
What are the IP Addresses of the Servers? Are you using WINS?

Author Comment

ID: 1559285
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


Expert Comment

ID: 1559286
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 ): )
Building an interactive eFuture classroom

Watch and learn how ATEN provided a total control system solution including seamless switching matrix switch, HDBaseT extenders, PDU, lighting control to build an interactive eFuture classroom.


Author Comment

ID: 1559287
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.


Expert Comment

ID: 1559288
What subnetmasks have you connfigured on the dhcp-servers?


Author Comment

ID: 1559289
Like I said, we're using Class C addressing styles, so subnet masks everywhere in our network are

Expert Comment

ID: 1559290
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.


Author Comment

ID: 1559291
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.

Author Comment

ID: 1559292
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.

Expert Comment

ID: 1559293
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.


Accepted Solution

dscf earned 100 total points
ID: 1559294
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.


Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
server is not seen in network 12 83
AD Account Lockout 22 64
adding user to local adminstrator group: JoeDoe@MyDomain.local  vs  MyD\JoeDoe 1 71
No IP Address Assigned to VM 10 92
FIPS stands for the Federal Information Processing Standardisation and FIPS 140-2 is a collection of standards that are generically associated with hardware and software cryptography. In most cases, people can refer to this as the method of encrypti…
Greetings, Experts! First let me state that this website is top notch. I thoroughly enjoy the community that is shared here; those seeking help and those willing to sacrifice their time to help. It is fantastic. I am writing this article at th…
Email security requires an ever evolving service that stays up to date with counter-evolving threats. The Email Laundry perform Research and Development to ensure their email security service evolves faster than cyber criminals. We apply our Threat…
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

733 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question