Possible Bug - DHCP Client Lease List

Hi axsom1,

Thanks for the feedback.Sending you PM for more details.

Thanks,

Rana Sharma

Thinking about this more, I do not think one should have to wait for a client to start their IP renewal process before they show up in the table.  Why is the DHCP database not persistent?

I admit, we don't typically use the firewall as a DHCP server but with more and more smaller customer moving all in on the cloud, it's actually quite common for the only devices to be on-prem being a security appliance and switches/access points.  I'd rather the security appliance handle DHCP over a switch.

Anyhow, so to test this, I looked at the table and sure enough, had 27 leases.  Rebooted the firewall and upon reboot only 12 are present.  If this is expected, so be it.  If there is a persistent database somewhere, why is the GUI not reflecting this?

Regardless, I do think there is an opportunity to fix this.  Maybe I need to add "persistent DHCP database" as a feature request?  [:S]

Hello,

Consider how DHCP works.

You configure a scope, set a lease time, start a service and DHCP is ready.

A new client sends a broadcast packet out requesting a DHCP server to respond, and one does making a lease offer.

Once accepted, the client retains the IP address and options given for the lease period.

Once 50% of the lease time has expired, the client attempts to renew the address.

If in between that time, the DHCP database is cleared, then there is no record of the allocated address' and it is only when the client undertakes the renewal, that the fact of the IP address being in use is known.

Only systems that have conflict detection can repopulate databases faster, and this is because the DHCP server sends out a ping for the IP address before it is offered, to ensure it is not in use. This increases the time required to do the DHCP allocation.

While it might sound convenient for Database retention, this will only work where the XG is the Primary DHCP server. This would be in small environments. In larger environments with Windows Servers you would have the Domain Controller as the DHCP server. But a wise IT manager may configure a scope on their XG as a backup in case of an issue with the Domain Controller, so it can be a quick fallback. in all cases there would be no possibility of DHCP database transfers.

Hello,

Consider how DHCP works.

You configure a scope, set a lease time, start a service and DHCP is ready.

A new client sends a broadcast packet out requesting a DHCP server to respond, and one does making a lease offer.

Once accepted, the client retains the IP address and options given for the lease period.

Once 50% of the lease time has expired, the client attempts to renew the address.

If in between that time, the DHCP database is cleared, then there is no record of the allocated address' and it is only when the client undertakes the renewal, that the fact of the IP address being in use is known.

Only systems that have conflict detection can repopulate databases faster, and this is because the DHCP server sends out a ping for the IP address before it is offered, to ensure it is not in use. This increases the time required to do the DHCP allocation.

While it might sound convenient for Database retention, this will only work where the XG is the Primary DHCP server. This would be in small environments. In larger environments with Windows Servers you would have the Domain Controller as the DHCP server. But a wise IT manager may configure a scope on their XG as a backup in case of an issue with the Domain Controller, so it can be a quick fallback. in all cases there would be no possibility of DHCP database transfers.