dhcp

Linux and DHCP reservations aren’t working

This is something I just came across myself. While deploying an Ubuntu Linux VM the DHCP reservation did not work. This was mixed up with a Windows 2016 DHCP server.

After looking at the wrong DHCP lease I quickly saw an extremely long MAC address and figured that the Linux VM used some kind of randomization for the interface.

IFCONFIG on the system showed the correct hardware MAC address.

It took me a few minutes of research and testing till I found the root cause and rather simple solution.

Linux replaced their NIC handling on many distributions with a newer system called NETPLAN.

I read that a 2019 Windows DHCP would likely handle this correctly, did not have time to test this out. But the following worked for me:

  • List the contents /etc/netplan
    • ls /etc/netplan
    • there should be a file ending in .yaml
  • Edit this .yaml file
    • sudo nano /etc/netplan/<filename>.yaml

The file is structured like this:

Under your NICDEVICENAME add the line dhcp-identifier: mac and save (CNTRL+O) and exit (CNTRL+X) the file.

Now you can either try to apply the netplan config via sudo netplan apply or simply reboot.

This should solve the issue.

June 28, 2022 by configuration solutions

Windows 2016 DHCP load balancer and it’s quirks

Windows 2016 DHCP load balancer and it’s quirks

Windows 2016 or probably even 2012 allows you to create a real load balanced / full failover DHCP server configuration, other then Windows 2008 that only allowed you to split the scopes.

Now, this works pretty great for the most part – but it has actually two major flaws you need to be aware of and actually take action on.

Neither reservations nor server / scope options are replicated.

This actually is a big deal. Assuming you are changing settings on server A for the pool, you end up that clients depending on which DHCP answered them might apply the new settings from server A or pull the old ones from server B.

Further might a reservation work when you put it in place, and then – all of a sudden a few days later you get a ticket in telling you there is an issue and you find out that the reservation didn’t pull anymore. What happened? Well – you might have set the reservation on server B but not on server A – depending on which server answered the client, you run again in to an issue.

Microsoft seems to have put a quick and dirty synchronization in place and the only true way around is to force the two DHCPs to synchronize with the following PowerShell command:

This could be automated via the Task Scheduler by using invoking the command from a DOS prompt via:

But even then, you better check all your DHCP servers and always make sure any changes are made on all DHCP servers or at least correctly replicated. Otherwise you might encounter the weirdest issues.

 

July 27, 2018 by recommendations scripts server solutions

Blog Archives