On first boot the engineer opens the GUI's interface list, notes which interfaces report link, then walks behind the rack comparing each name to the cable actually plugged into that port. What does this cross-check accomplish?
Select an answer to reveal the explanation.
Short Explanation
The GUI knows what the software believes; only your walk-behind proves the wall plate matches the story. A management-labeled port sitting on the backup VLAN passes every software check until the first real restore — and that's not the day you want a surprise. Cross-check names against cables while the rack is open and mistakes are still cheap.
Full Explanation
The purpose of the cross-check is closing the loop between software abstraction and physical plant. Interface names in the GUI describe logical intent; they are only true if the cable actually attached to that port leads where the design says it leads. A management-labelled port patched into the backup VLAN passes every software check and reveals itself only in operation, so walking the rear and matching each reporting interface to its actual cable landing catches mis-patches, swapped pairs, and mislabelled cords while the rack is still open and changes are free. Transceiver retraining triggered by reading names is an invention: optics negotiate at layer one independently of any human observation. Dismissing the check as cosmetic fails by misreading what it verifies — the names are fixed to ports, but cables move, and it is the patching, not the naming, that the walk confirms. MAC assignment waiting on visual confirmation is likewise invented: MAC addresses are assigned by the platform and configured in software, never gated by a person at the rack. Exam caveat: the cabling task closes when links are verified to land in the right places, not merely when they are up. Operational check: after the walk, the as-built table lists every interface with name, cable label, and switch target, and each row matches both the rack and the GUI.