Cabling
GPU Management Cabling: Records for BMC and Host Connections
Record a management connection by its actual chassis port, destination and approved network role. A BMC connection, a host management interface and a high-speed fabric interface can belong to the same server while serving different functions. Similar connectors or nearby labels do not make them interchangeable.
Identify which management function the connection serves
Ask the system/network owner to distinguish the management controller connection from host operating-system management and any separate provisioning or fabric roles. Record the approved role without inventing a topology. A dedicated physical port is one implementation; do not assume every system uses identical ports or management arrangements.
NVIDIA’s DGX GB rack-scale networking documentation separately names management, out-of-band, compute and storage networks. That example shows why a drawing labelled simply management can leave important ambiguity. Use the applicable system model and project design to determine the actual connections; do not copy a rack-scale network table into an unrelated server installation.
References: [N5]
Read out-of-band as a network role, not a connector shape
An out-of-band management network and a compute fabric serve different purposes. In NVIDIA’s DGX GB rack-scale guide, ipminet provides the management system and headnode with access to out-of-band interfaces. The named component population includes compute trays, NVLink switch trays, power shelves, top-of-rack switches and control-plane nodes. The same guide separately describes dgxnet for provisioning and managing compute trays, and computenet for communication across racks. Management therefore does not identify one interchangeable port or one kind of work.
The guide’s compute-tray table makes the distinction concrete: its BMC Ethernet port belongs to ipminet, while a separate LAN port with the same RJ45 connector type is marked Not Connected. Its ConnectX-7 OSFP entry belongs to the InfiniBand compute network. Preserve those source-specific descriptions; they are neither a generic wiring rule for another server nor an instruction to disconnect a project’s LAN connection. The applicable equipment revision and approved project plan still need to agree.
A management capability is another level of information. For example, NVIDIA’s DGX B200 component table describes a 1 GbE RJ45 BMC interface with management capabilities including Redfish and IPMI. That identifies a documented product interface; it does not say that a particular installed cable reaches an authorized service. A physical port, an assigned network role and an authenticated control function need separate evidence. Do not record Redfish or BMC as if either were a complete point-to-point cable identity.
Scroll the table horizontally on smaller screens.
| Published port entry | Connector type | Published network association | Buyer record implication | Source |
|---|---|---|---|---|
| 1 GbEthernet Port BMC | RJ45 | ipminet (Ethernet) | Identify the exact tray and BMC port, then bind the approved destination and OOB role to that connection ID. | [N6] |
| 1 GbEthernet port LAN | RJ45 | Not Connected | A similar connector does not justify copying the BMC role. Resolve a conflicting project assignment with the system/network owner. | [N6] |
| ConnectX-7 port | OSFP | computenet (InfiniBand) | Keep the compute connection and its remote endpoint distinct from the OOB record; no cable quantity follows from this table. | [N6] |
Port and network strings are retained from the named guide table. The final column is original buyer analysis. This comparison supplies no full port map, security topology, cable selection, configuration or installation procedure.
Reconcile the chassis label with the logical record
A field installer needs the physical endpoint that can be located on the equipment. The operating team may also need a configured interface name or adapter identifier. Keep those values together without treating them as the same thing. NVIDIA’s DGX B200 documentation explicitly maps physical port designations to system interface names; the applicable configuration still controls those names.
Request the exact model, rear-panel reference and released port plan. If the physical label and logical schedule disagree, record the conflict for the network/system owner. Do not change a live connection or infer a switch configuration from a familiar-looking jack.
References: [N4]
Distinguish two iDRAC interfaces on one actual server
An endpoint called iDRAC can still leave the physical interface unresolved. Dell’s PowerEdge XE9680 manual lists a front iDRAC Direct port with a Micro-AB USB 2.0 interface. Its separate iDRAC9 specification identifies a rear RJ45 Ethernet port, and the rear-view table calls that interface the dedicated iDRAC9 Ethernet port. These are model-specific descriptions of different physical connectors, not two names for one jack.
Both descriptions concern management access. The distinction is not management versus non-management: Dell explicitly describes the micro-USB port as an iDRAC Direct or management port. What the field record needs is the exact interface and physical reference selected by the system owner. The XE9680 example does not establish the port layout, connector generation or permitted management arrangement of another server.
Fictional example EX-MG-23: a released connection row asks for an Ethernet path to switch port EX-P07, but its server-port attachment identifies the XE9680 front iDRAC Direct Micro-AB USB port. The endpoint references do not describe the same physical connector family. Record the two conflicting references and ask the system owner which interface and destination the task actually requires. This is a document mismatch, not a diagnosis of a failed controller or permission to attach a device, change a port or invent an adapter.
A resolved response might identify the intended rear Ethernet interface, or explain that the requested work concerns a different approved service connection. Neither result follows automatically from the word iDRAC. Carry the authorized physical endpoint and destination back into the connection record, with the controlling source revision. Do not silently replace a USB reference with an Ethernet label to make the paperwork appear consistent.
The table identifies the documented interfaces only. It does not establish which function is enabled, whether access is authenticated or which configuration and security controls apply. Those decisions stay with the system and security owners; this article supplies no connection, login, reset, update or diagnostic procedure.
Scroll the table horizontally on smaller screens.
| XE9680 documentation reference | Documented physical interface | Record question to resolve | Source |
|---|---|---|---|
| Front iDRAC Direct port | Micro-AB USB 2.0 | Which exact service interface and permitted task does the request identify? | [D1] |
| Rear dedicated iDRAC9 Ethernet port | RJ45 Ethernet | Which approved physical endpoint and remote destination belong to this connection? | [D2][D3] |
The interface descriptions apply to the cited PowerEdge XE9680 pages; the record question column is original buyer analysis. No port-mode, connection method, enabled state, access right or security result is inferred, and no layout is transferred to another model.
Use a management connection register
The example below is intentionally free of IP addresses and credentials. Add confidential operational information only in the customer’s authorized system of record. A cable label should identify the connection under the approved scheme, not expose the means of accessing the equipment.
Scroll the table horizontally on smaller screens.
| Field | Example or required reference | Who confirms it | Source |
|---|---|---|---|
| Physical source | Asset S-12; labelled BMC interface; applicable chassis diagram | System documentation owner and physical observation | Planning analysis |
| Cable identity | Cable M-012; observed end labels | Installation record owner | Planning analysis |
| Physical destination | Management switch MS-01; released port reference | Network/design owner | Planning analysis |
| Role | Out-of-band management, per approved design | System/network owner | Planning analysis |
| Logical reference | Restricted configuration-record ID; no password in this worksheet | Authorized operations owner | Planning analysis |
| Evidence/status | Observed endpoint; open issue or agreed verification reference | Accepting owner for that evidence | Planning analysis |
Original illustrative planning record. Values and identifiers are examples, not a customer record, engineering design or acceptance standard.
Separate connection-record state from control readiness
Fictional example EX-MG98 contains three planned connection records for a proposed DGX GB installation. Their equipment references use the cited compute-tray table, while every asset, cable and destination ID below is an invented project identifier. Two rows have consistent reference-level port and role descriptions; one row has a source-versus-plan conflict. None has a returned observation, physical verification result or authenticated-access result.
The unresolved row names the LAN port but assigns the BMC network role. The public table alone cannot decide whether the project plan is wrong, a different configuration applies or the endpoint description is incomplete. Return the exact conflict to the system/network owner, retain the disputed revision and record the disposition before changing the affected work package. Do not silently rename the port or treat a documentary disagreement as proof that a real cable is misconnected.
Keep three status fields independent. Endpoint-record status says whether the source, destination, connection ID and their evidence agree. Role status says which controlled project reference assigns the connection to OOB management, host management or compute. Control-readiness status records a separately supplied operational result or an explicit absence of that result. Completing the first field cannot automatically complete the other two. An Ethernet link indication or a correctly printed label does not establish authenticated control, isolation or resilience.
When the owner resolves the conflicting row, return the approved port and role reference to the same connection ID and retain the earlier discrepancy. That can close a document issue without inventing a test result. The physical handoff can identify what was planned, what was actually observed and what still awaits the operating owner. It supplies no login, reset, port-mode, addressing or access-control procedure.
Scroll the table horizontally on smaller screens.
| Fictional connection ID | Planned physical endpoints | Role reference and record decision | Returned observation or control result | Source |
|---|---|---|---|---|
| EX-MG98-A | Tray EX-T01 BMC port to EX-OOB01 port EX-P07 | ipminet/OOB in fictional plan EX-NR4; reference-level endpoint and role descriptions agree | Not supplied; plan consistency is not an as-built or access result | Planning analysis |
| EX-MG98-B | Tray EX-T02 LAN port to EX-OOB01 port EX-P08 | Fictional plan EX-NR4 assigns ipminet, while the cited LAN entry is Not Connected; retain the conflict for owner disposition | Not supplied; no relabeling, reconnection or fault diagnosis follows | Planning analysis |
| EX-MG98-C | Tray EX-T01 ConnectX-7 OSFP port, exact cage still to be supplied, to EX-COM01 port EX-P12 | computenet in fictional plan EX-NR4 agrees with the reference-level port class; the specific physical port remains open | Not supplied; the record class is distinct from OOB but this connection is not ready for execution | Planning analysis |
These are three fictional planned records, not three installed cables. Two role/class descriptions agree with the public reference and one conflicts; exact endpoint completeness is a separate state. No network address, credential, operational command, actual device, observation or acceptance is represented.
Keep label corrections separate from security changes
Illustrative example: the cable end reads BMC, but the released schedule names the host LAN port. Record the observed cable, actual physical port and conflicting revision. The designated owner must decide whether the schedule, label or connection needs correction. Relabeling the cable to make the two documents appear consistent could conceal the underlying error.
This record does not establish network isolation, access controls, firmware policy or secure configuration. Those decisions belong to the authorized system and security owners. Do not include default passwords, recovery secrets or instructions for bypassing access controls in an installation handoff.
Deliver physical completion without overstating access
Hand over the endpoint register, approved deviations, outstanding items and any agreed physical connectivity evidence. State whether a result was observed by the installer or supplied by the system owner. A mounted cable or visible link indicator does not establish authenticated management access or a correctly configured service.
Leviathan can discuss physical routing, dressing, labeling and agreed documentation for the approved management connections. Configuration, security acceptance and application readiness require their own owners. Define formal verification separately rather than inferring it from completion of the cable installation.
References: [L1]
Common planning questions
Can every RJ45 management-looking port use the same connection plan?
No. Determine each port’s function from the exact system documentation and approved design. Connector shape does not identify its role.
Should the cabling handoff contain management passwords?
Use the customer’s authorized credential process. The physical register can reference a restricted operational record without copying secrets into labels, photographs or general handoff files.
Is an iDRAC label enough to identify the physical cable endpoint?
No. The cited XE9680 documentation separately describes front Micro-AB USB iDRAC Direct and rear RJ45 iDRAC9 Ethernet interfaces, both related to management. Keep the exact model, physical interface reference and approved destination in the record. The name alone establishes neither the intended connection nor its enabled or authenticated state.
Does a complete OOB cable record prove the management service is ready?
No. Keep physical endpoint evidence, approved network-role assignment and any returned operational result separate. A record can be internally consistent while an endpoint observation, exact port, applicable configuration or authenticated-access result is still missing. The system/network owner must resolve those questions; the cabling record supplies no security or service-readiness approval.
Primary sources
- [N5] NVIDIA DGX GB rack-scale systems: networkingChecked 2026-10-14. Model-specific compute, storage and management network roles. Select the applicable product documentation; this is not a generic topology for all GPU systems.
- [N4] NVIDIA DGX B200: system introduction and network portsChecked 2026-10-14. DGX B200-specific physical/logical port mapping and cable information. Do not transfer this mapping to other systems or infer their shipped contents.
- [L1] Leviathan structured cabling scopeChecked 2026-10-14. Approved physical cabling service boundaries; exact design, materials, authorization and verification are project-specific.
- [D1] Dell PowerEdge XE9680: USB port specificationsChecked 2026-10-16. Only the documented front Micro-AB USB 2.0 iDRAC Direct interface and its management context on XE9680. No connection/configuration steps, operational timing, generic server layout, access or health result adopted.
- [D2] Dell PowerEdge XE9680: iDRAC9 port specificationsChecked 2026-10-16. Only the XE9680 rear RJ45 iDRAC9 Ethernet interface. No network configuration, authentication, approved destination, operating state or applicability to another model inferred.
- [D3] Dell PowerEdge XE9680: rear-view interface labelsChecked 2026-10-16. Only the rear-view label for the dedicated iDRAC9 Ethernet port. No reset, button, POST, repair, power, GPU or service procedure or connection authorization adopted.
- [N6] NVIDIA DGX GB rack-scale guide: named networks and compute-tray port rolesChecked 2026-10-19. Network Overview and Compute Tray Network Ports only: named OOB/management/compute functions and the BMC, LAN and ConnectX-7 table entries. No universal layout, configured project role, interface-name map, command, security topology or operative method inferred. Prior N5 object remains unchanged.
- [N7] NVIDIA DGX B200: BMC component-interface descriptionChecked 2026-10-19. Only the component-table BMC 1 GbE RJ45 interface and listed management capabilities including Redfish/IPMI. No port map, configuration, access procedure, operational availability, security or authenticated result adopted. Prior N4 object remains unchanged.