An engineer finishes the last cable, opens the Data Domain management GUI, and starts entering network settings while half the interfaces still have unverified link state. What should have happened first, and why?
Select an answer to reveal the explanation.
Short Explanation
Verify the wires before you build on them. A dead port makes every setting you type look broken, and you'll spend the day blaming your configuration for a cable that was never seated. One walk of the interface statuses now saves you an afternoon of debugging you didn't need to do.
Full Explanation
Link verification precedes configuration because the two failure domains have different costs. A physical-layer check — every cabled interface showing link at the expected speed — takes minutes and answers whether optics, cables, and switch ports are alive. Configuration entered before that check rests on unverified assumptions: a half-seated optic, a wrong-speed port, or a dead patch cord will make perfectly correct settings appear broken, and troubleshooting then hunts through configuration while the fault sits in the cabling. Deferring verification until after configuration fails because Ethernet trains at layer one regardless of IP address, VLAN, or routing — a port with no address still shows link, so nothing about the settings is required to test the wire. Restricting first GUI use to the service port until routes exist is an invented ordering with no basis in the platform's access model; the service path is one way in, not a prerequisite gate. The claim that the GUI detects and repairs faulty cables fails on capability: management software reports interface state honestly but cannot fix a physical fault. Exam caveat: a link that trains at less than the expected speed is exactly the finding a before-configuration sweep catches. Operational check: list every cabled interface, confirm link state and negotiated speed for each against the design, and correct or relabel anything mismatched before entering a single setting.