Microsoft DHCP Server not consistently delivering IPs.

encoad
encoad used Ask the Experts™
on
We have two DHCP servers, the OLD server and the NEW server.  We'd like to migrate to the NEW server, but we cannot get it consistently deliver IP addresses to our various subnets.

We have all of the appropriate IP-Helpers in our switches.  The behavior is as follows:

We are using Microsoft Server 2016 with Microsoft DHCP Server.  The server sits on ESXi host.  (different host)

1.  We turn off the OLD DHCP server and turn on the NEW DHCP server.  Scopes are enabled.
2.  In some cases, users will get new IPs right away.\
3.  In some cases, users never get an IP, they get a 169.254.x.x address.
4.  In all cases, if we switch NICs on the user's computer, they will get an IP.  For example switching from the docking station NIC to the laptop NIC will always give an IP from the NEW server.
5.  We can usually find the following message in the logs: "Your computer was not assigned an address from the network (by the DHCP Server) for the Network Card with network address 0xF4D108E45BA6.  The following error occurred: 0x79. Your computer will continue to try and obtain an address on its own from the network address (DHCP) server."

Any suggestions?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Only explanation I have would be Spanning Tree set up on the switches, but not the newer "Rapid Spanning Tree". With the older spanning tree, a port stars in blocking mode, and it takes a while before it starts forwarding packets. This will mean DHCP does not work consistently, but a manually set IP works fine. Can also stop login scripts and GPO processing at startup.

Check that the ports that your client devices connect to are not running Spaning Tree, or if they are, use rapid spanning tree.

More on rapid spanning tree here:

https://en.wikipedia.org/wiki/Spanning_Tree_Protocol

Author

Commented:
I have  "spanning-tree portfast" on all user ports.  All my switches are running current software.
OK, with "Portfast" on a Cisco you are running Rapid Spanning Tree. (RSTP) It is still possible for Spanning tree (STP) packets being generate by another device to throw the switch into STP mode, or a client machine to initiate DHCP very quickly, but seem a long shot. I have seen DHCP problems with STP, but never with RSTP, which is what is normally configured in 2019.

On the other hand, it is quite simple to reconfigure a couple of problematic ports and see if it makes any difference. Worth a try IMHO.
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
Hi Mal,

Thanks for the reply.  Keep in mind if I plug a different device into the same port (like a USB NIC) it will pick up an IP right away.  Switch back to the NIC which was receiving the IP from the old server, and it will get 169.254.x.x
Another thought: Pretty obvious, but have you checked that there are IPs left on the DHCP scope? If exhausted, a NIC with a MAC address that had already been assigned an IP would get it back, unless the lease had expired, but a MAC without an existing lease would not.
SteveArchitect/Designer

Commented:
this kinda thing happens quite a lot. by default, a widows machine will try to reach it's original DHCP server to get a new lease before considering a new one.
Next time it occurs (and before you unplug the NIC that wont pick up an address) try running an ipconfig /release then an IPconfig/renew in a CMD window.

This forces the NIC to start from scratch and won't have a 'preferred' dhcp server.

Assuming this works, you could add this to a login script or go around and do it manually but it's a bit of a pain. let us now if this works and we can discuss options.
DrDave242Principal Support Engineer

Commented:
this kinda thing happens quite a lot. by default, a widows machine will try to reach it's original DHCP server to get a new lease before considering a new one.

That's not just Windows; that's part of the DHCP specification. When a client's lease hits 50% of its duration, it begins trying to renew the lease by sending directed (unicast) request packets to the DHCP server that initially leased the address to it. As long as it gets no response, the client will keep doing this until it hits 87.5% of the lease duration, at which point it starts broadcasting those request packets. Any DHCP server on the network can respond to those requests.

Author

Commented:
Thanks for the replies.

I'm still unclear as to why my users are not getting an IP address at all though.  We release and renew, but nothing.  If we change NICs on the laptop USB, Dock or Integrated, it does get an IP.  Switching back, no IP...
DrDave242Principal Support Engineer

Commented:
I suspect that either the client's DHCP requests aren't reaching the server, or the server's responses aren't getting back to the clients. This could be caused by a number of things, like improper configuration of VLANs or DHCP relay agents (aka IP helpers). If you're familiar with Wireshark or another packet-capture tool, running it on the DHCP server and filtering out everything but DHCP traffic might give some insight into what's going on.
SteveArchitect/Designer

Commented:
I'm still unclear as to why my users are not getting an IP address at all though.  We release and renew, but nothing.  If we change NICs on the laptop USB, Dock or Integrated, it does get an IP.  Switching back, no IP...
That's an interesting bit of info. So the same cable picks up an IP on another NIC without a problem, which suggests the ports/routing/firewalls are correctly configured, but but the original NIC still refuses when reconnected....

Have you checked the MAC of this NIC and looked if a (potentially faulty) DHCP reservation has been created?

Author

Commented:
Hello,

There is no DHCP reservations anywhere.

This is a very strange problem to have.  Network guys blame system guys, system guys blame network guys, but we can't see to get DHCP going.  Our next step is to migrate the VM from the new ESXi host to the old host, which will tell us if there's something different about the host or the path to get there.
SteveArchitect/Designer

Commented:
It is an odd one but not unheard of. it usually turns out to be related to a specific issue that occurred in the past, where an undocumented 'workaround' is causing odd results years later :-(

We've got to take a risk on loads of left-field stuff really, to see if we can find anything that sticks.

Check the DHCP server(s) don't have any odd settings relating to that PC. (e.g. Hostfiles for the hostname, ARP cache for static assignments to the MAC address)
Check the switch (assuming it's capable) to confirm the port is reporting the correct MAC address, and isnt configured to expect that MAC address anywhere else.
try wiresharking traffic to see if you can see the DHCP request and hopefully responses. if you can, lets break themdown and see if they look right. if not, lets work out whats missing.
Commented:
We ended up moving the virtual machine to the same host as the original DHCP server, tested and everything worked.  Then we moved it back, tested and it worked. And it's worked every since.  I've learnt nothing, but glad it works.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial