FeDHCP is a DHCP server for the IronCore Project network. It is based on coredhcp.
Leases a single IP address to a single client as a non temporary IPv6 address.
Meant to be used in 1:1 client-server connection scenarios, for example a smartnic (Bluefield) leasing a single address to the host.
The IP address to lease shall be passed as a string.
- supports IPv6 addresses only
- IPv6 relays are supported
Implements HTTP boot from Unifed Kernel Image.
Delivers the HTTP boot image as a BootFileURL. Based on configuration it delivers either a client-specific UKIs dynamically or a default UKI for all clients. When client-specific UKIs are configured, IPv6 relays must be used, so the client can be identified based on its link-local address (which the relay always provides).
A single HTTP(s) URL shall be passed as a string. It must be either
- a direct URL to an UKI (default UKI for all clients)
- magic identifier
bootservice:+ a URL to a boot service delivering dynamically client-specific UKIs based on client identification
- not tested on IPv4
- IPv6 relays are supported
- the only supported client-specific UKI delivery service is the IronCore Boot Operator
- only EFI X64_64 architecture is supported, see #154
The IPAM plugin acts as a Kubernetes persistence plugin for IronCore's in-band network. Thus, it's meant to be used in combination with the onmetal plugin only. Those two may be consolidated in the future into a new plugin called inband.
The IPAM plugin does not modify DHCP responses to the client, it rather creates (or updates) IP objects in Kubernetes. For each created IP object, the in-band plugin onmetal will lease an IP address to the client. Due to the nature of the IronCore's in-band network - /127 client networks connected to each switch port - the IP object created has and address calculated by a simple "plus one" rule. In such a way each client gets a "plus one" of the switch port address it is connected to.
A kubernetes namespace shall be passed as a string. All IPAM processing (subnet identification, IP object creation/update) are done in that namespace. Further, as a second parameter, a comma-separated list of subnet names shall be passed. The IPAM plugin will do the subnet creation based on the IP address of the object to be created as well as on the vacant range of the corresponding subnet.
- supports only IPv6
- IPv6 relays are mandatory
- shall be used in combination with
onmetalplugin - IP addresses are just created/updated, they are not deleted upon DHCP IP address release. Cleanup process is still tbd.
- depends on IPAM operator
The OnMetal plugin leases a non temporary IPv6 address to an in-band client, based on the algorithm described above. Additionally, when requested from the client, a prefix delegation with preconfigured length is leased. Currently multiple prefix delegations are not supported, client prefix delegation length proposals are ignored completely. The prefix delegation length should be in the range 1 <= length <= 127.
The onmetal configuration consists of the prefix delegation length only.
Providing the length in onmetal_config.yaml goes as follows:
prefixDelegation:
length: 64- supports only IPv6
- IPv6 relays are mandatory
- can be used standalone or (in combination with the
ipamplugin) in kubernetes
The OOB plugin leases an IP object to an out-of-band client, based on a subnet detection. The plugin is an equivalent of the metal+ipam kombination, meant to be used in IronCore's out-of-band network.
An IP object with a random IP address from the subnet's vacant list is created in IPAM, the IP address is then leased back to the client. Currently no cleanup-on-release is performed, so clients with stable identifiers are guaranteed to become stable IP addresses.
As for in-band, a kubernetes namespace shall be passed as a parameter. Further, a subnet label list in the form value:key shall be passed, it is used for subnet detection.
- supports both IPv4 and IPv6
- IPv6 relays are supported, IPv4 are not
- other than for in-band, where the DHCP leasing and kubernetes persistence are handled in different plugins, for out-of-band a single plugin is used
- depends on IPAM operator
The Metal plugin acts as a connection link between DHCP and the IronCore metal stack. It creates an EndPoint object for each machine with leased IP address. Those endpoints are then consumed by the metal operator, who then creates the corresponding Machine objects.
The metal configuration consists of an inventory list. Currently, there are two different ways to provide an inventory list: either by specifying a MAC address filter or by providing the inventory list explicitly. If both a static list and a filter are specified in the metal_config.yaml, the static list gets a precedence, so the filter will be ignored.
Providing an explicit static inventory list in metal_config.yaml goes as follows:
hosts:
- name: server-01
macAddress: 00:1A:2B:3C:4D:5E
- name: server-02
macAddress: 00:1A:2B:3C:4D:5FProviding a MAC address prefix filter list creates Endpoints with a predefined prefix name. When the MAC address of an inventory does not match the prefix, the inventory will not be onboarded, so for now no "onboarding by default" occurs. Obviously a full MAC address is a valid prefix filter.
To get inventories with certain MACs onboarded, the following metal_config.yaml shall be specified:
namePrefix: server- # optional prefix, default: "compute-"
filter:
macPrefix:
- 00:1A:2B:3C:4D:5E
- 00:1A:2B:3C:4D:5F
- 00:AA:BBThe inventories above will get auto-generated names like server-aybz.
- supports both IPv4 and IPv6
- IPv6 relays are supported, IPv4 are not
- depends on metal operator
The PXEBoot plugin implements an (i)PXE network boot.
When configured properly, the PXEBoot plugin will break the PXE chainloading loop. In such a way legacy PXE clients will be handed out an iPXE environment, whereas iPXE clients (classified based on the user class for IPv6 and IPv4) will get the HTTP PXE boot script.
Two parameters shall be passed as strings: an TFTP address to an iPXE environment and an HTTP(s) boot script address. The order matters!
- relays are supported for both IPv4 and IPv6
- TFTP server as well as HTTP boot script server must be provided externally
- as with
HTTPBoot. only EFI X64_64 architecture is supported
FeDHCP is licensed under MIT License - Copyright 2018-2024 by coredhcp and the FeDHCP authors.