I recently had to answer some questions concerning micro-managing leases in the Weird Solutions DHCP servers, DHCP Broadband and DHCP Turbo. By micro-management, I mean having an external program that manages every lease externally, reconfiguring the DHCP server on the fly as the external software sees fit.
Micro-managing leases can be done with our DHCP server, but there are some things you should think about before diving in. It’s not as simple as associating a DHCP client identifier with an IP address.
First, let’s get our terminology straight: there is a distinction between leases and bindings.
A binding is a contract that’s stored in the DHCP database. It describes a lease, which is a something that the DHCP server negotiates with the DHCP client.
The first point of interest is that our DHCP server includes quite a lot of information in each binding. In particular, it has fields for source_account and source_pool. These fields, so-called loose references, are the object Identifiers (OIDs) of a device account and an address or network pool, respectively.
Why are these fields present?
The source_pool OID tells the DHCP server which address pool or network pool was used when this IP address was chosen. If you are managing IP addresses externally than you aren’t technically choosing an address from a pool. But if the IP address you’re putting in the binding does fall within the range of an address pool, you should refer back to that pool for completeness. A report generator may count all leases by source_pool, for example, so leases that aren’t associated with a pool won’t show up in the report. But note that the server gracefully handles things even if a binding’s IP address falls within a pool range and there is no source_pool defined in the binding.
The source_account field in a binding should refer to the OID of the device account that corresponds to the device requesting the address. Since it’s acceptable to create leases without having device accounts, this field is not required. But there may be cases where it’s useful; for example, if you have device accounts in your server you can find the account simply by knowing the IP address of the device.
If you create a binding through the interface or API (as opposed to the DHCP server dynamically creating the binding for you), you should consider the values you use for the following fields:
Domains
The domains field specifies the security for the binding. Security isn’t really optional in our DHCP server because it’s not just about which users can see the binding – the same security also describes which devices can use the binding. So if you get the domains wrong, the device may not be able to use the binding at all. If in doubt, use the All Devices domain.
When the DHCP server is creating a binding dynamically, it chooses the intersect between the domains the device account has access to (the ACL) and the permissions that are configured on the pool.
Source_account
Set the source_account to be the OID of the device account for the this device. If there is no device account, leave this field empty.
Source_pool
Set the source_pool to be the OID of the pool that covers this address range. If there is no such pool, leave this field empty.
Lease_duration
This field specifies how long the IP address lease should be valid. It is stated in hours:minutes:seconds (hh:mm:ss).
Lease_Commit
This field specifies when the lease was last negotiated with the DHCP client. If you don’t provide a value, the default is midnight January 1 1970. Unless the lease duration is exceptionally long (in this case unacceptably long!), the lease will be expired (Lease_commit + Lease_duration < current time) as soon as the binding is saved in the DHCP database. If the binding is not fixed, and the lease is expired, the DHCP server can theoretically delete your binding immediately after you save it.
If you set a fake lease commit time in the binding you’re not doing any harm. In fact, it’s an acceptable way to flag the binding as viable. Setting the commit time to the current time, for example, simply indicates that the server should assume that the binding is in active use.
Fixed
Setting this field to true tells the DHCP server to never revoke the binding in an attempt to recover the associated IP address for reuse. The DHCP server typically revokes bindings that are expired when it needs free IP addresses for new devices on your network.
Lease_expiration
This field is not actually stored in the database; it’s computed on the fly when you read a binding. It simply represents the Lease_commit time plus the Lease_duration. Setting a value for this field when creating or updating a binding has no effect.
All times in the DHCP server are specified in Universal Coordinated Time (UTC). The format is the ISO standard date format.
Creating a binding simply declares a contract for an IP address; the address has not been actually given to the device. So the DHCP server can have a contract for a lease (a binding) without having actually committed the address to the device, but it will never commit an address to a device without a corresponding binding. Put another way, the DHCP server simply doesn’t do business without written contracts.
When the device does request an IP address, if your binding is configured correctly then the Lease_commit time will be updated to reflect the time at which the device received the address. You can exploit this fact to verify that the device actually leased the IP address.
Now, let’s look at a typical pitfall:
If you create a binding, the device then negotiates a lease from that binding, and afterwards you delete the binding, you’ve deleted the binding, but you haven’t canceled the lease.
In this scenario you may be tempted to reboot or reset the device in order to force it to relinquish the lease. Although this works in practice for some devices, it isn’t technically legal; the lease was given for a fixed period of time, and if you revoke the written contract (binding) before that time, you’re violating the contract.
Many devices have stable storage and can remember their assigned IP address across reboots. Whether an IP address lease can be extended or not, the client is within its rights to continue to use the IP address as long as the lease hasn’t expired. (DHCP NAK can help in this case, but there is no guarantee that it can be delivered.)
By removing the binding on the DHCP server before the lease has expired, you’re effectively telling the DHCP server that it’s free to reuse that address; to give it to any new device that requires an address. This can cause duplicate addresses on your network, and that’s always a bad thing.
It’s worth noting that the behavior I’ve described is not specific to our DHCP server line of products. It’s part of the international DHCP standard. Every DHCP server and client is expected to adhere to the contracts negotiated by DHCP.
In its default configuration, our DHCP server completely manages all of the bindings and leases on your network. It gracefully handles all of these messy details and ensures that the written contracts are always up to date for every lease. It also exposes a rich interface for querying the database and, lastly, it supports push notifications to allow external software to monitor the events occurring in the DHCP server.
Micro-managing IP addresses with external software is certainly possible with our DHCP server. But if you have more questions after reading this article than when you started, you may want to contact us for guidance before implementing external address management.