DHCP Reservations not honored

[czech12]

This issue appears to be the same as #871 and #872, but I wanted to provide my own detailed write up as a new issue.

I was running 2 Windows server VMs with DHCP and DNS services only. I'm a network security engineer, so my lab was mainly focused on my enterprise firewall cluster with multiple protected VLANs. While I could turn on DHCP server on the firewall, it isn't really meant for managing DHCP scopes, so it is configured with DHCP Relay (ip helper) to forward requests to the 2 windows servers. This was all working fine, but I didn't like having to run 2 VMs just to provide these services. Dynamic DNS was also problematic because of the weird IoT device hostnames, so I had to turn that off. I just wasn't a good fit for a homelab, but it was functional.

I recently found a reddit post about Gravity and it seemed to be exactly what I was looking for. I haven't learned much about Kubernetes yet, but I have become familiarized with docker enough to get it to do what I wanted. I initially started out with 1 docker container running gravity with the default configuration from the docs page. Initial DNS testing was perfect. I then configured a DHCP scope for my guest VLAN which was empty at the time. This worked well also. I kept following the docs to export my Windows config, figured out how to get the file copied into docker, then ran the export. I had a few issues with some of the IoT reservation names being blank or having special characters, but I was able to clean those up in the json file and the import was successful. Everything was great up until this point.

Although all my reservations imported successfully, as I rebooted devices to pull a new IP, they did not honor the reservation and pulled a new different IP from Gravity. To make it more confusing, it was still listed as a reservation with the same hostname, but the IP was wrong. I would correct the reservation IP, reboot the device again and then the IP would stick. So I continued with this process on my entire network and had everything correct.

I woke up the next morning to find all my devices having wrong IP addresses again. Some of them had the wrong IP but were given an address from the correct scope, but some were given an IP on the VLAN gravity was on. Some are also given the same IP. This is a huge problem for me because every device on my network has a reservation. My IoT VLAN specifically needs reserved IPs so Home Assistant can turn each device on or off.

I probably should have stopped here, but I really like everything about Gravity, so I fixed everything again. I also wanted to figure out how to give the gravity docker it's own IP address, I got this working by creating a macvlan network in docker and assigning a static IP to the container. Since this worked, I also deployed 2 more gravity containers and clustered them.

The DHCP reservation issue still persists. Because it was a problem before the cluster, I don't think the problem is cluster related. I have my DHCP relays pointing to all 3 gravity container IP addresses and devices always grab an IP. When I manually fix the reservation and have them pull an IP again, it always works. It's just that they randomly grab a new IP address some time later and everything breaks again. I have DHCP turned on for the local network gravity is on and I read that could be a problem with the DHCP master, but I can easily disable DHCP for that VLAN as it is just a fall back for servers that don't use a static IP by default. Although the scope is active, there are no active DHCP clients. If anyone thinks there is a problem with this particular configuration, please let me know and I can change it. I am willing to troubleshoot.

I really want to use gravity, but at this point I need to switch back to my Windows servers. I need DHCP reservations to be reliable and that is not the case right now. I plan to leave the servers up for my Guest VLAN only. Its the only VLAN where I don't need reservations.

Any help is appreciated. This is a great product with some really awesome features. I am also impressed that there is a terraform provider. I'm planning on adding all of my reservations via terraform so I can more easily fix them, but I'm hoping the product becomes more usable for me.

[adfrancis]

This is a bigger ticket issue. Waiting for this to be resolved before I can adopt in the home lab.

[tompaah]

Although all my reservations imported successfully, as I rebooted devices to pull a new IP, they did not honor the reservation and pulled a new different IP from Gravity.

I had the same experience but I assume I found what works and what not.
The Discovery function picks up MAC addresses and saves them in the Scope with capital letters (AB:CD:EF:01:23:45). But when the clients get DHCP leases (the wrong ones, not the ones you reserve) Gravity saves them in the Scope with lowercase letters (ab:cd:ef:01:23:45).

So I made a new reservation with lowercase letters, and presto- it works, the client gets the right reserved IP.

This should be an easy fix in the code I assume.

[BeryJu]

I'm not a hundred percent sure if the DHCP client identifier should be case sensitive or insensitive, but I think it would be an easy change for the discovery role to write the mac addresses in lower case (there will still be the case where this won't work for machines that use a different identifier and not their mac address)

[tompaah]

Different systems handle MAC-addresses differently. Some do uppercase, some lowercase. For instance, VMware displays them uppercase and Linux distros in lowercase. Preferrably Gravitys MAC-address matching would be case-insensitive, this would allow cutting and pasting addresses from systems with no regard to the case.

[BeryJu]

For other DHCP servers it seems like they support case sensitive arbitrary ASCII identifiers and case insensitive MAC addresses, which makes sense. I'm not sure what the best way would be for gravity to support that as it treats any client identifier as an opaque string, so we can't just force-lowercase it before its saved to the database