New/Updated DHCP Scope - what am I doing wrong?

[LeMarchand]

Did this a couple of years ago without incident, but can't get it to work today. Admittedly last time was in the holidays and we weren't changing broadband supplier.

 

So far I have set up the new scope and added in the new DNS forwarders. Deactivated the old scope and activated the new one and restarted the DCHP Client and Server services and moved the forwarders to the top. Connected the main switch to the new router. Then... nada. Clients weren't getting new addresses and no internet connection.

 

Have reverted for now.

[Davit2005]

Give the client PC a static IP and see if it can ping it's gateway if it cannot when it should be able to then I'd start looking further. I'm assuming DHCP server is running on the new router??

 

Could you potentially do this with one client connected to the router and the router jus sitting next to the client i.e. not connected up to the main network with a spare switch if necessary??

Edited December 2, 2025 by Davit2005

[LeMarchand]

Will try the first at some stage. May have to come in of an evening or weekend so I don't get whinging teachers.

 

Did try the second, but didn't make the changes to the dhcp properties. Next in on Friday, so may try that again.

[iannn]

Is the new DHCP scope on a different VLAN? If so do you need a route on the router with a DHCP relay address?

[LeMarchand]

Nope, flat network.

[Davit2005]

2 minutes ago, LeMarchand said:

Nope, flat network.

Is it a tagged/trunk port on the new router or jus untagged/access port?

[Julian]

Please rember that DHCP, and DNS are seperate systems, with DNS layed on top of DHCP. So you need to see if he issue is with DHCP or DNS. Ping is very helpful here, if you can ping 8.8.8.8 (Google DNS server), then you know you have a working connection to the internet, and you issue is with DNS, failure and you need to look at your internet connection.

[LeMarchand]

2 hours ago, Davit2005 said:

Is it a tagged/trunk port on the new router or jus untagged/access port?

 

Good question that I don't know the answer too.

 

I think the problem is before we even get to the router, though. Nothing seemed to be picking up the new IP addresses after the switch, which surely isn't reliant on the router as both DHCP and DNS are on a local server?

[psydii]

Is it possible the clients were holding onto their old IP addresses/leases because they weren't due to expire, remained valid and noting else on the LAN said they couldn't?

 

When doing this sort of thing, its helpful to set a very short lease time a few weeks in advance so when you push the button on the new scope the clients fairly quickly pivot over on their own rather than hanging on to their old leases until they age-out.


From what you have said, this appears to be a change driven by moving ISP.  Do they mandate your internal range? If not, are you actually changing your internal lan range, or just the DNS servers to use?  You refer to DNS forwarders - this suggests you have a local DNS service running that the clients use and that DNS Service forwards request to the ISP/Google/CloudFlare (or whoever you use for pDNS services). Has your local DNS Service changed IP?  Or are the clients expected to query the external dns servers directly?

How big is your LAN IP Subnet? Is it possible that you've got a subnet mask wrong and the dns server / firewall gateway ip is actually invalid for the subnet as configured in DHCP / on the clients? (I've done that!) this one is a pain to check as it could be on the gateway, on the interfae of the DHCP server, on the interface of the internal DNS server, on the clients, or in the DHCP scope/settings.

Also worth checking are ACLs on the core switch - someone may have set up an ACL to allow only the old IP range, and even if you are using it as a flat network the acl could be dropping the traffic.

[LeMarchand]

57 minutes ago, psydii said:

Is it possible the clients were holding onto their old IP addresses/leases because they weren't due to expire, remained valid and noting else on the LAN said they couldn't?

 

When doing this sort of thing, its helpful to set a very short lease time a few weeks in advance so when you push the button on the new scope the clients fairly quickly pivot over on their own rather than hanging on to their old leases until they age-out.

 

I knew there was something I did last time that I didn't this! That could be it.

 

Changes are mandated by the ISP. I'm guessing that they already have customers on the ranges two of my schools use but not on my 255.255.254.0 school.

 

The leases are quite short, but I'll make them even shorter now and then again before it all (hopefully) goes live.

[LeMarchand]

This thread kept popping up on Google last night when I was searching for a solution, so I thought I'd update with what cured it.

1. As @psydii said above, pre-shorten the leases
2. Set the TCP/IP properties on the DHCP server manually
   
3. My biggest error: Set the scope options! You will probably have to edit options 003, 006 and 066 (if you use PXE boot). In my case I had to create 003.
   

After that it was fairly plain sailing.

[LeMarchand]

From my other school that needed the same job doing:

 

Step 2: The DNS addresses are for the domain DNS server/s (possibly th same one you're setting things on) and not any ISP mandated forwarder. Oops!

 

Also, some devices may well have their IP addresses set manually and not via DHCP. You'll need to deal with these individually.