Adding a new scope - Address range in conflict with existing scope.

Ok,

The subnet mask defined for 10.57.16.200 - 10.57.16.250 is 255.255.252.0
This covers the address range: 10.57.16.0-10.57.19.255

So what you could do is redefine the existing scope to: 10.57.16.200-10.57.18.220
and exclude: 10.57.16.251-10.57.18.204.

The subnet mask defined for 10.57.16.200 - 10.57.16.250 is 255.255.252.0
This covers the address range: 10.57.16.0-10.57.19.255

This is correct.

So what you could do is redefine the existing scope to: 10.57.16.200-10.57.18.220
and exclude: 10.57.16.251-10.57.18.204.

Bit confused here.  We only have one scope setup - this is:

10.57.16.200 to 10.57.16.250

All other addresses outside of this scope are set statically.  Setting up a new scope, which will include IP addresses that have been statically assigned seems wrong.  Sorry, but care to explain this a bit more please.

Why are we getting the error when trying to setup a new scope with IP address that have not statically been assigned.  

Thanks.

This appears to be equipment specific to me.  But I'm sure there's more to it than that.

I would not want more than one DHCP server on the network.  So this limits the ability to pick and choose multiple subranges for DHCP - depending on the equipment.
The DHCP ranges you mention are disjoint and I'm not sure your equipment can handle that.
Also, many DHCP servers take single address ranges specified by:
- first and last;
- first and number of addresses;
-and some might take CIDR notation or netmask notation as some routers do.  
In the last case you are stuck with CIDR or subnet boundaries.  Is that the case here?
- and some may take multiple ranges or might exclude ranges but I've not seen one of those.  It seems that's what's being mentioned.

It appears that you are using 10.57.16.0 / 22.
It appears, from what you describe, that the boundaries for DHCP are simply unfortunate.
(For example, in hindsight it may have been better to use 10.57.16.0 / 25 for DHCP i.e. 10.57.16.1 - 10.57.16.127).

Might you do something like this:
- Switch to 10.57.16.0 / 21?
Then you would have available 4 more blocks of 256 addresses and could assign an entire block (or most of it) to DHCP .. without changing any of the static IP addresses perhaps.  (I have no idea how you're doing your subnetting or how you have your gateways set up).
This would not increase the number of hosts any more than you already intend - even though it would increase the size of the address space.  The latter should have no impact.

Hello guys,

Thanks for the input - I see that the reason for the error is we are trying to implement a subnet range of 255.255.252.0 to a new scope, when the first scope already has that defined for its range.

We have just got a new IP range sorted out (As we are a college we have to ask our college ISP), which is;

IP range is 10.57.80.1 to 10.57.83.254. This is what our additional Cisco config looks like:
!
interface Vlan30
description Link to Tech 2nd /22 Range 4026
ip address 10.57.80.1 255.255.252.0
zone-member security in-zone
!
interface FastEthernet0/1/7
description Link to Tech 2nd /22 Range 4026
switchport access vlan 30
no shutdown

So what we are planning to do is delete our existing scope of;
DHCP:  10.57.16.200 - 10.57.16.250

And create a new scope (within the superscope) of;

 10.57.81.1 to 10.57.82.254 with a subnet range the same 255.255.252.0

Question:
Can you see any problems doing this.

Thanks.

Can't see anything wrong with that as long as the routing to the static ranges is done properly.

Well, the routing infrastructure would be the same - and as the new IP range is within the existing subnet range, there should be no problems.  And of course, as long as we remove the existing scope, and create a new one, then we should not get the error message stated before.


Will update post when this has been done.
Thanks.

We'll be here :)

Hah, makes me feel all warm knowing that.

Have a good day Ernie!

:)

Same to U, good luck reconfiguring.

Ok, run into a problem.

We have deleted our old scope - recreated a new one with the new range - we go to a computer, set it to DHCP, but it cannot get an IP address... 169.

Now, we know the new IP address range is ok, as we have setup a static IP address, which was fine.  We pinged that IP address from a computer, who had an existing IP fine.

So, the new IP address range is working fine, but when creating a new DHCP scope (the only one), DHCP clients cannot get DHCP information.

We have made sure the scope is activated, and that we restarted the DHCP server.  It appears, maybe, as its a routing issue.  But, like expressed when setting a static IP address from the range that the DHCP server will be using, it works fine - thus ruling out a routing issue.

Any ideas?

Thanks.

Did you configure ip helper addresses in the Cisco?

Ah, no - can you explain that process a bit more please.

Thanks.

Here is a ping from a client, with an IP that we want the DHCP server to assign.

C:\Users\karnovskis>tracert hera

Tracing route to DC [10.57.17.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  10.57.80.1
  2    <1 ms    <1 ms    <1 ms  DC.DC.com [10.57.17.1]

Trace complete.

I'm assuming that the IP helper command is for clients that are more than 2 hops from the DHCP server?  I could be wrong, first time of looking into this.

Thanks for your help.

Should be something like:

interface Vlan30
ip helper-address x.x.x.x

x.x.x.x being the IP of your DHCP server of course :)

Oh crosspost :)

The ip helper-address forwards the broadcasts (the DHCP requests) from a configured VLAN to the configured IP address (as a unicast if I remember correctly).

Hey Ernie,

Spot on, that had not been added - unfortunately, due to restrictions in place at our college, the local council's ISP has control over the main router, so I cannot add IP helper code.

However, I have just been informed that it has been added; but after testing;  clients can still not access the DHCP server.   And as I cannot access the router management console, I cannot write down the code here to see if its correct.  

Is there anything else that could be stopping clients from sending / receiving DHCPAKC to the DHCP server.

For example, does the router have to be rebooted (which they have not told us to do - if fact, when we asked for a new set of IP addresses, they didn't even mention adding the IP-Helper address to the router's config!), after the config has been saved.

Assigning a static IP in the new range is fine - just clients still cannot gain access to the DHCP, even after they added the IP-Helper address.

Thanks for your help

Hello Ernie,

Is it possible for traffic (DHCP packets on port 69 UD) to be filtered on a different vLAN interface?  Just trying to figure out why clients are not receiving DHCP on this particular newly created vLAN.  

Also, is there a way to test where the communication is failing, in regards to the DHCP packets - e.g., is it the clients  DHCP discovery packet that is not reaching the DHCP server, or is it the DHCP offer packet not being sent back to the client.

Using wireshark or something like that? You think.