The city NOC cannot reach a newly racked GPU node in-band and needs first console access. Which approach is correct?
Select an answer to reveal the explanation.
Short Explanation
When the front door (in-band) is locked, use the side door—BMC out-of-band—to get on the console. That is exactly why municipal AI racks wire OOB before they count on the host network.
Full Explanation
When the city NOC cannot reach a newly racked GPU node in-band, the correct first console path is the out-of-band BMC management interface, which is designed to work when host networking, DHCP, or the OS data plane is unavailable. OOB console and power control let operators inspect boot progress, fix network configs, and recover the node without assuming Slurm or in-band SSH already work. Waiting for the node to appear in Slurm before any console attempt depends on a scheduler view that will never populate if in-band networking is the failure. Shipping the chassis back immediately without using management interfaces skips the standard recovery path and wastes hardware that may only need OOB configuration. Disabling OOB networking to force the host to fix in-band DHCP removes the very tool needed during bring-up failures and is the opposite of municipal NOC practice. Exam caveat: OOB does not replace fixing in-band networking for production jobs; it is the break-glass path while in-band is broken. Operational check: from the NOC management VRF, reach the node’s BMC IP, open Serial-over-LAN or HTML5 console, confirm identity against the rack map, then remediate in-band networking before returning the host to the city GPU pool.