feat: Support external DHCP servers

[daluz]

Is this a new feature, an enhancement, or a change to existing functionality?

New Feature

How would you describe the priority of this feature request

Medium

Please provide a clear description of problem this feature solves

Right now, the DHCP server (nico-dhcp) is deeply integrated into nico. This poses operational challenges like:

• Granular DHCP relay configuration.
• Datacenter operators who already have previous infrastructure and want to run hybrid setups, for example: partial nico, or iterative adoption of nico.
• Inception issues, where nico is not yet operational, but future-managed capacity was already added to the network and spun up (where they start without a DHCP server to relay to), leaving the capacity stranded until a power-cycle (a manual DCOps operation).
• There's likely already a need for external DHCP servers for devices on the Datacenter not managed by nico, forcing DHCP to be a hybrid solution.

What we are suggesting as a new feature is to support external DHCP infrastructure, where nico accepts events (API calls) from this external DHCP infrastructure.

Feature Description

In essence, this could be very similar to the current nico-dhcp, using kea to emit the API calls to nico-api, but running externally. But this would allow operators to:

• Spin-up their DHCP infrastructure ahead of time.
• Configure their DHCP relays to point to already available services (potentially, a single relay configuration for all switches)
• Allow deeper integration of their services, like: connect to an IPAM service to be the source of truth for all DHCP devices on the datacenter, create quarantine address space for “unknown devices”, etc.

Maybe this is all already possible (by running nico-dhcp outside of nico's Kubernetes cluster), but I suspect there's deeper integration that prevents it from working (e.g. forwarding information to more than one nico, based on rules).

What would need to be implemented:

• Instead of querying nico-api to be the source of truth, those events would become the source-of-truth (I suppose they would be responsible for managing machine-interfaces).
• Document how events (API calls) should be emitted to nico-api.
• Document how potential reconciliations need to happen (garbage-collect unused address, etc).

We could offer an example implementation of said external DHCP service as reference to operators (maybe it's just an example of how to run nico-dhcp externally, if that fits the bill).

Describe your ideal solution

No response

Describe any alternatives you have considered

No response

Additional context

This suggestion might be more relevant for larger scale deployments, where you might have multiple nico's running simultaneously, like in DSX OS. Or for larger providers that already have global DHCP infrastructure in place and are looking for examples of how to integrate nico with said infrastructure.

Code of Conduct

• I agree to follow NVIDIA Infra Controller's Code of Conduct
• I have searched the open feature requests and have found no duplicates for this feature request

[ajf]

Maybe for out-of-band this is possible, but it's definitely not possible for anything beyond that (things inside overlay networks), or loopback assignments, or VRF loopbacks. Don't we already support static assignment of OOB addresses?

I also don't see any reason why you couldn't just point the DHCP devices @ NICo, statically assign OOB MAC addresses to the networks. NICo dhcp isn't limited to only nico managed hosts. No reason you couldn't point a power strip or printer at it to get an address.