From a management host on the same network, confirm the Redfish service is installed and responding:

curl -k https://<bmc_ip>/redfish/v1/UpdateService/FirmwareInventory/bmc_1
 "Status": {
 "Health": "OK",
 "HealthRollup": "OK",
 "State": "Enabled"
 },
 "Updateable": false,
 "Version": "12.2.0.0.0"

Redfish on CN5000 supports two authentication methods.

curl -k -u "admin:<password>" https://<bmc_ip>/redfish/v1/Chassis

CN5000 BMCs implement the three standard predefined Redfish roles.

curl -k -u "$BMC_USER:$BMC_PASS" -X POST \
  https://<bmc_ip>/redfish/v1/AccountService/Accounts \ 
  -H "Content-Type: application/json" \
  -d '{"UserName":"opsuser","Password":"Example123!","RoleId":"Operator"}'

curl -k -u "$BMC_USER:$BMC_PASS" \
  https://<bmc_ip>/redfish/v1/AccountService/Accounts/opsuser 

curl -k -u "$BMC_USER:$BMC_PASS" -X PATCH \
  https://<bmc_ip>/redfish/v1/AccountService/Accounts/opsuser \
  -H "Content-Type: application/json" \
  -d '{"RoleId":"ReadOnly"}'

curl -k -u "$BMC_USER:$BMC_PASS" -X DELETE \
  https://<bmc_ip>/redfish/v1/AccountService/Accounts/opsuser

The chassis Id segment in each URI depends on the board type being queried: CN5000 Switch (CNEdge) or Director Class Switch (CNMM).

The EventService delivers asynchronous notifications (for example, OpenBMC-registry messages) to a subscribed destination.

Supported SubscriptionType value: RedfishEvent

Log services are exposed under both the Managers/bmc and Systems/system namespaces.

To collect Redfish logs:

The CN5000 exposes Redfish resources through RDE. Each resource represents a different view of the SuperNIC—as a physical device, a set of fabric ports, a source of traffic telemetry, a PCIe device on the server bus, and a host-side network function.

Each resource is accessible through the BMC's standard Redfish API.

RDE is read-only. RDE is a monitoring and visibility interface, not a configuration interface. GET is the only supported HTTP method on CN5000 SuperNIC resources. You can read every exposed resource, but you cannot change, create, or delete anything through RDE; PATCH, POST, and DELETE are not supported and return 405 Method Not Allowed. This applies to sensor data as well: there is no way to set thresholds or write values back to the SuperNIC through this interface. To configure the CN5000, use in-band host tools.

Before the BMC can surface CN5000 SuperNIC resources through the Redfish API, the following must be in place.

From a management host on the same network, confirm the SuperNIC's RDE-provided resources are being surfaced by the BMC.

RDE resources are served through the BMC's standard Redfish service. Authentication is identical to the standard Redfish API (refer to Authenticating to Redfish for Basic authorization or Sessions with X-Auth-Token). No additional or device-specific authentication is required.

RDE does not provide its own accounts or roles. Access to RDE-surfaced SuperNIC resources is governed by the same BMC Redfish accounts and roles defined in Managing Redfish Accounts and Roles (Administrator, Operator, ReadOnly). Reading SuperNIC resources requires only Login privilege, so all three predefined roles can view them.

RDE chassis IDs come from the host server's BMC and are not the CN-prefixed switch IDs.

The following procedures assume you have already resolved <chassis_id> and <system_id> as described above. Each procedure shows how to obtain the additional ID it introduces.

The NetworkAdapter resource represents the physical NIC (the SuperNIC adapter itself) as the top-level device and links to its subordinate port and network device function collections.

Navigate from the service root to the NetworkAdapter resource.

Prerequisite: Getting the <chassis_id>

The Port resource represents an individual fabric port on the adapter, exposing its link state, speed, and connection properties.

Navigate from the NetworkAdapter to the Ports collection, then to a specific port.

Prerequisites: Getting the <chassis_id>, Discovering the SuperNIC NetworkAdapter

The PortMetrics resource provides per-port counters and telemetry for a given port, including RDMA counters relevant to an RDMA-capable NIC. When a QSFP module is present, it also reports transceiver telemetry: module temperature, supply voltage, and per-lane optical power and bias current under Transceivers[].ByLane[].

Navigate from the Port resource to its Metrics sub-resource.

Prerequisites: Getting the <chassis_id>, Discovering the SuperNIC NetworkAdapter, Viewing Port Status

curl -k -H "X-Auth-Token: <token>" \
  https://<bmc_ip>/redfish/v1/Chassis/<chassis_id>/NetworkAdapters/<adapter_id>/Ports/<port_id>/Metrics

Example output (with a 4-lane QSFP module installed):

{
"Id": "0",
"Name": "Port Metrics",
"RXBytes": 0,
"TXBytes": 0,
"RXErrors": 0,
"TXErrors": 0,
"Networking": {
   "RXFrames": 0,
   "TXFrames": 0,
   "RXUnicastFrames": 0,
   "TXUnicastFrames": 0,
   "RXMulticastFrames": 0,
   "TXMulticastFrames": 0,
   "RXDiscards": 0,
   "TXDiscards": 0,
   "RDMARXBytes": 0,
   "RDMATXBytes": 0,
   "RDMARXRequests": 0,
   "RDMATXRequests": 0,
   "RDMAProtectionErrors": 0,
   "RDMAProtocolErrors": 0
  },
"Transceivers": [
    {
     "RXInputPowerMilliWatts": 0.5,
     "SupplyVoltage": 3300,
     "TXBiasCurrentMilliAmps": 6.5,
     "TXOutputPowerMilliWatts": 0.8,
     "ByLane": [
        { "RXInputPowerMilliWatts": 0.5, "TXBiasCurrentMilliAmps": 6.5, "TXOutputPowerMilliWatts": 0.8 },
        { "RXInputPowerMilliWatts": 0.5, "TXBiasCurrentMilliAmps": 6.5, "TXOutputPowerMilliWatts": 0.8 },
        { "RXInputPowerMilliWatts": 0.5, "TXBiasCurrentMilliAmps": 6.5, "TXOutputPowerMilliWatts": 0.8 },
        { "RXInputPowerMilliWatts": 0.5, "TXBiasCurrentMilliAmps": 6.5, "TXOutputPowerMilliWatts": 0.8 }
      ]
    }
  ]
}

The PCIeDevice resource represents the PCIe-side view of the NIC, describing its PCIe interface characteristics and functions as attached to the system.

Navigate from the service root to the PCIeDevice resource.

Prerequisite: Getting the <chassis_id>

The NetworkInterface resource represents the system-side binding of the adapter, providing the functional (host-facing) view that links back to the physical NetworkAdapter.

Prerequisite: Getting the <system_id>

The NetworkDeviceFunction resource describes the host-side network function of the adapter: its InfiniBand identity (GUIDs and MTU) and device-enabled state.

Navigate from the NetworkAdapter to the NetworkDeviceFunctions collection.

Prerequisites: Getting the <chassis_id>, Discovering the SuperNIC NetworkAdapter

If CN5000 SuperNIC resources do not appear in the BMC Redfish tree, or if you receive unexpected errors when querying those resources, work through the issues below in order.

RDE lets the SuperNIC expose its Redfish resources to the BMC without implementing an HTTP or JSON stack on the device. DSP0218 defines only the encoding and transport mechanics — it does not define the Redfish resource data models themselves. This creates a clear division of responsibility that shapes every OEM integration task:

Because RDE is schema-agnostic and DSP0218 imposes no fixed resource set, the set of resources a given SuperNIC exposes is a product decision, not a standardized guarantee. OEMs must therefore code their BMC integration against the conformance data in this section and against the resource set the device actually advertises at runtime, never against an assumed standard set.

Before a BMC can surface SuperNIC resources through Redfish, the platform must satisfy the following. These are platform-design and BMC-firmware responsibilities owned by the OEM or server provider.

The BMC brings a SuperNIC online through standard MCTP endpoint enumeration followed by PLDM discovery. The device requires no host-side agent. The sequence is:

Per DSP0218 Section 7.2.1, to be recognized as an RDE Device the device must respond to GetPLDMTypes indicating support for both PLDM Type 2 (Platform Monitoring and Control) and PLDM Type 6 (RDE). After PLDM-level discovery, the BMC issues NegotiateRedfishParameters to establish baseline RDE parameters.

Adding RDE is not self-contained. Per DSP0218 v1.2.0, Section 7.2.1, an RDE Device must advertise and implement three PLDM layers at its terminus, and the OEM's BMC must be prepared to exercise all three:

The CN5000 RDE implementation conforms to the following DMTF specifications and protocol versions. The BMC negotiates these versions with the CN5000 during MCTP endpoint setup and PLDM type/version discovery (GetMCTPVersionSupport, GetPLDMTypes, GetPLDMVersion).

The exposed Redfish resource set is a product decision (refer to Exposed Redfish Resources). OEMs should enumerate the device's Redfish Resource PDRs at runtime rather than hard-coding an assumed set.

CN5000 baseline:

The Redfish Annotation schema is carried as a BEJ-encoding support dictionary (DSP0218, Section 5.3.2), not as a standalone resource. The OEM's BEJ decoder requires it, but it never appears in the Redfish resource tree presented to clients.

RDE on Cornelis SuperNICs is a monitoring and visibility interface, not a configuration interface.

To configure the CN5000 SuperNIC, use the applicable OPX Software tools (i.e., opaportconfig and opafm.xml).

The following conditions are platform/BMC-side and are the OEM's to diagnose during bring-up and qualification.

The BMC event-log location and format are platform-specific (iLO, iDRAC, XCC, OpenBMC, or other) and are the OEM's responsibility.