Change from using direct Postgres queries to using the Netbox API. This is much simpler to deploy, and should perform acceptably well if done as follows:
Retrieve a list of prefixes, filtered to those which are intended for DHCP use (e.g. by using a tag)
Iterate over the IP addresses within each of those prefixes, and identify those which are on interfaces with MAC addresses (or again, have a tag to identify addresses with static DHCP assignments) to write out static reservations
We can avoid writing out the entire kea file, by instead writing out snippets of JSON that can be referenced via <?include?>. This could mean either:
generate a separate file for each subnet, containing just the reservations block; then the kea config has a "reservations":<?include "..."?> for each subnet; or
generate a single file containing all subnets, which is included at as "subnet4/6":<?include "..."?>; or
hybrid: generate separate file for each subnet plus a skeleton which includes the reservations from separate files
Cases 2 and 3 would require Netbox to emit the full configuration including "pools" and "option-data". Note that:
Netbox doesn't currently have a good way to define IP ranges for DHCP pools. For IPv4 you can set a bunch of individual IPs with status "DHCP" (ugh), but this is far too inefficient for large IPv6 pools. Better to make the pool be a custom field.
It may be necessary for a single subnet to contain multiple pools, and for each pool to have associated attributes. e.g. for HA setups:
Subnet4/subnet6 sections may be nested inside shared-networks - see #1.
This could be configured via a bunch of separate custom fields on the Prefix object - unfortunately there are no list or structured types. e.g.
Custom fields:
"kea.pools[0].pool": "192.0.3.10-192.0.3.20" // note above, multiple pools may be required
"kea.pools[0].client-class": "unreserved_class"
"kea.option.domain-name-servers": "192.0.3.1, 192.0.3.2"
"kea.option.routers": "192.0.3.1"
//"kea.shared-network.name": "my-secret-lair-level-1"
//"kea.shared-network.interface": "eth0"
//"kea.shared-network.relay.ip-addresses[0]": "192.1.1.1" // needs to be turned into a list
(possibly other custom fields for client-classes, require-client-classes etc). This doesn't cover all possible use cases, but is easy to manage via the GUI when adding new subnets.
(Inspired by Michael Schwartzkopff's approach)
Change from using direct Postgres queries to using the Netbox API. This is much simpler to deploy, and should perform acceptably well if done as follows:
We can avoid writing out the entire kea file, by instead writing out snippets of JSON that can be referenced via
<?include?>. This could mean either:reservationsblock; then the kea config has a"reservations":<?include "..."?>for each subnet; or"subnet4/6":<?include "..."?>; orCases 2 and 3 would require Netbox to emit the full configuration including "pools" and "option-data". Note that:
Netbox doesn't currently have a good way to define IP ranges for DHCP pools. For IPv4 you can set a bunch of individual IPs with status "DHCP" (ugh), but this is far too inefficient for large IPv6 pools. Better to make the pool be a custom field.
It may be necessary for a single subnet to contain multiple pools, and for each pool to have associated attributes. e.g. for HA setups:
Subnet4/subnet6 sections may be nested inside shared-networks - see #1.
This could be configured via a bunch of separate custom fields on the Prefix object - unfortunately there are no list or structured types. e.g.
(possibly other custom fields for
client-classes,require-client-classesetc). This doesn't cover all possible use cases, but is easy to manage via the GUI when adding new subnets.