Link to home
Start Free TrialLog in
Avatar of KirstyP
KirstyP

asked on

DHCP Superscope Assigning Wrong Address to Clients Windows Server 2003

Hi,
I have a Windows 2003 network switched using a collapsed core design with a Cisco 3560 as the core switch and standard 3com or Netgear non managed swithces at the edge. The network is divided into several VLANS (192.168.4.0/24, 192.168.5.0/24, 192.168.6.0/23, 192.168.8.0/24). The 3560 is configured to route traffic between the networks and this works perfectly. All servers are on the 8.0/24 network, all DHCP clients are located on the other networks. There ia a DHCP server on the 8.0/24 network configured with a superscope encompassing scopes for the 4.0/24, 5.0/24 and 6.0/23 subnets. Each VLAN interface on the 3560 is configured with an ip-helper address entry (DHCP relay agent) that points to the DHCP server. DHCP usually works fine. However if a user on the 5.0/24 network takes his laptop to a room on the 6.0/24 network the laptop will usually pick up an address from the 5.0/24 subnet which means that he can't access the network because he is plugged into an interface on the core switch with a 6.0/23 ip address. The only way that I can get a client to pick up the correct address reliably when it is moving between subnets is to disable all scopes other that the one which I want. This is causing us big problems. I'm usually pretty ok with networking but this one has me stumped. Can anyone out there help?

Thanks

Kirsty
Avatar of JFrederick29
JFrederick29
Flag of United States of America image

I'm sure it has to do with the fact that you are using a superscope in DHCP versus 3 individual scopes for the 3 subnets.  I bet if you removed the superscope the problem would disappear.
Avatar of KirstyP
KirstyP

ASKER

Thanks, I know that It should work if I set up 3 seperate scopes on different servers and point the respective helper addresess to them. However why doesn't it work with a superscope? This is what a supescope is designed to do - it looks at the originating subnet in the GIADDR field and assigns the appropriate address - so why doesn't it work?

Kirsty
It's my understanding that a superscope is used in a scenario where you have multiple logical subnets on the same physical segment.  You have 3 logical subnets on 3 physical segments.
Avatar of KirstyP

ASKER

Yes that's true but In the MS implementation superscopes are also designed to support logical subnets on different physical segments. I am currently looking at an MS press book describing how to set up a superscope on a DHCP server physically seperated from the multinets by a router. Which is exactly the set up that I have. I would just like to know why it doesn't work - why does the DHCP server not take notice of the GIADDR info passed by the ip-helper address? I think I might just set up 3 seperate DHCP servers and have done with it.

Kirsty
It may be because the lease is still active and since it is a superscope, it deems it okay to reissue the same IP.  Do they get the same IP when moving?  You could try adding the 002 option to your scopes (Release DHCP lease on shutdown) to see if that helps.  Otherwise, I would simply not use a superscope and see if that resolves it.
I agree with JFederick29.
I looks like your setup correctly to me.  I would say its giving it the same address from the wrong scope because the lease on that MAC address is not up.  

Let us know if it is resolving the same IP when you more from one scope to another.
Perhaps this will be of some use

Perhaps you considered the possibility of placing multiple DHCP
Servers on the same physical segment to solve the problem of
issuing IP address for multiple network IDs. Let's take a look at
what might happen here.

We have two DHCP Servers, DHCP-1 and DHCP-2. The DHCP Servers
contain scopes that include all addresses for the following
network IDs:

DHCP-1 192.168.1.0/24
DCHP-2 192.168.2.0/24

Now imagine that a DHCP client with IP address 192.168.1.10 needs
to renew its IP address. When the client sends out its
DHCPRequest message to renew its address, that request is
broadcast to the entire segment. Therefore, either DHCP Server
can receive the message. If DHCP-2 receives the message, it will
check the network ID on the request and compare that with the
network ID on its local interface and find that the source
network ID is different from its own network ID. Since these are
different, DHCP-2 will look for a member scope in a superscope
that can service this request. Since there is no superscope to
service the request, DCHP-2 will send a NACK to the client.

After receiving the NACK, the DHCP client then has to begin the
discovery process from the beginning and send out a DHCPDiscovery
packet. Let's say that DHCP-2 is the first to respond to the
DHCPDiscover packet, and assigns the clients the IP address of
192.168.2.15. Hey look at that! The client is now a located on a
different network ID. And what's really rich is that the whole
thing could start all over again, and the DHCP client could end
up on network ID 192.168.1.0/24 again.
ASKER CERTIFIED SOLUTION
Avatar of Stevexpress
Stevexpress

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of KirstyP

ASKER

Thanks guys. I tried the 002 option but it still didn't work. I therefore went with the suggestion of stevexpreess and set up several DHCP servers, each with a superscope with all addresses excluded apart from the scope that I want that server to assign. I then pointed the ip helper-address from each VLAN to its respective DHCP server. It works perfectly. Sorry for the delay in getting back to you all and thanks for all your help guys.
Hi, all I wanted to point out an alternative solution.  To those who plan to have double digit subnets, having a separate DHCP server for each would defeat the whole ease of management that dhcp relaying offers.  The alternative solution is to separate each scope outside of the superscope so that they are peers of the superscope.  Now, i can jump from one network to the next without getting stuck with the ip from the first network.  I hope this helps the rest of you multi network admins out there.