feat: Add GB200/GB300 support for DPU-in-NIC-mode ingestion

[martinraumann]

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

High

Please provide a clear description of problem this feature solves

GB200/GB300 platforms have managed-DPU ingestion coverage, but the DPU-in-NIC-mode path is not currently well supported or covered for these platforms. Some deployments operate the BlueField as a plain NIC rather than as a NICo-managed DPU. In that mode, ingestion needs to treat the host as a zero-DPU / HostInband host while still handling GBx00-specific Redfish discovery, boot-interface selection, and platform lifecycle behavior correctly.

Feature Description

Add support and integration coverage for ingesting GB200/GB300 hosts with dpu_mode: "nic_mode".

Expected behavior:

• ExpectedMachine can declare dpu_mode: "nic_mode" for GB200/GB300 hosts.
• Site Explorer discovers the GB200/GB300 platform correctly.
• NICo does not link or manage the BlueField as a DPU machine when it is operating in NIC mode.
• The host boots through the declared primary host_nics[] HostInband interface.
• The host can progress through ingestion to Ready.
• Flat VPC / autoNetwork allocation works after ingestion.
• Existing managed-DPU GB200/GB300 ingestion behavior remains unchanged.

Describe your ideal solution

Add machine-a-tron/API integration coverage for GB200/GB300 systems using dpu_mode: "nic_mode", including at least one Supermicro GB300 NVL-style platform. Use the test coverage to verify boot-interface prediction, HostInband interface promotion, no managed-DPU linkage, and successful host lifecycle progression. Fix any GBx00-specific Redfish or Site Explorer assumptions found by that coverage.

Describe any alternatives you have considered

Relying on existing managed-DPU GB300 coverage is not sufficient because NIC mode changes how the BlueField should be modeled and how the host in-band boot path is selected. Treating this as generic zero-DPU support is also incomplete because GB200/GB300 platforms have platform-specific Redfish and lifecycle behavior.

Additional context

Recent GB300 mock and integration work added managed-DPU GB300 coverage, but not explicit GBx00 DPU-in-NIC-mode ingestion coverage.

Related:

• feat(bmc-mock): add GB300 support & integration test #3295
• SMC GB300 Rack enablement. #1909

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

[martinraumann]

Additional requirement clarification from networking/platform discussion:

There are two related but distinct ingestion modes that should remain separate:

• dpu_mode: nic_mode: the DPU is present, but should be configured into NIC mode via Redfish and used as the host's primary boot device through the high-speed DPU port.

• dpu_mode: no_dpu: the DPU should be ignored entirely, and the host should boot through the onboard/integrated NIC.

For the GB200/GB300 NIC-mode path, the expected behavior is that NICo can configure the DPU into NIC mode, select/reconfigure it as the primary boot device, and ingest the host through the HostInband path.

Network-side requirement for nic_mode: DHCP relay must be configured on the high-speed DPU switch ports toward carbide-dhcp, since host traffic will leave via those high-speed ports. This differs from managed-DPU mode, where ArmOS and BMC are on OOB paths with DHCP helpers there.

Existing dev/QA NIC-mode testing has used HostInband network segments, including per-host /30 segments in some cases.