-
Notifications
You must be signed in to change notification settings - Fork 13
Description
Description
A common feature request is support for DHCP server. Discussions have been around continuing to use dnsmasq
, which is used as the system DNS resolver and helper for coordinating received DHCP client options and configured settings, or to leverage the ISC DHCP server. The latter has a new implementation called Kea which also use sysrepo + yang. However, it does not seem their YANG model and implementation can easily be reused, see the Infix discussion thread for more: https://github.com/orgs/kernelkit/discussions/345.
Requirements
- Easy to set up a general DHCP server
- Selecting an interface in the CLI infers pool range, DNS server, and gateway option from interface address
- Inferred default options (dnsmasq defaults) from the CLI
- Support static host leases
- Support matching on MAC address, client-id option, and (future) Option 82 sub-options
- Support "easy replacement" with Option 82, i.e., not lock static leases to MAC address
- Support setting DHCP options (with YANG validation of standard types like inet address)
- Global options
- Pool option, possible to override global options
- Static host options, possible to override global and pool options
- Common settings, that many vendors have dedicated settings for, like "default router", "dns server", should be managed as DHCP options instead
- Use common vernacular in the YANG model:
- Compare existing models, including draft models (see below links)
- Compare with nomenclature used by Cisco/Juniper/Procurve/Moxa/Westermo
- Fit in with nomenclature used in
infix-dhcp-client.yang
and other models in Infix - If all else fails, use terminology from
dnsmasq
One critical use-case Infix must support is "IP per port". I.e., a central DHCP server1, with relay agents on other subnets that are capable of tacking on Option 82, containing local port name and relay agent ID. See issue #438 for more information. The server can then use this information to always hand out the same IP address to client(s) connected to that port on that switch. For quick device replacement these static leases must be possible to disable locking to the MAC address of the old (to be replaced) device.
In the simplest variant of this use-case the relay agent and DHCP server run on the same Infix device. But for the implementation of DHCP server support in Infix, the server must support serving leases (including static) on per-subnet rather than on a per-interface basis.
Additional Information
- IETF DHCPv6 model, standardized as RFC9243, YANG tree view
- IETF DHCP model, contains server + relay + client, never made it passed draft rfc state, YANG tree view
- Cisco IOS DHCP Server
- JunOS OS DHCP Server
- HP Procurve DHCP Server Example
- Moxa Next Generation OS, DHCP Server pp. 3-25
- Westermo WeOS DHCP Server config
General Information
You can help out by sponsoring the development, or contributing a pull request for its support. Use this issue for discussions around this topic.
Footnotes
-
possibly with a hot-standby backup. ↩
Sub-issues
Metadata
Metadata
Assignees
Labels
Type
Projects
Status