While configuring basic management networking, a typo places the head's address in a VLAN that no longer exists, and the system goes dark — no GUI, no SSH. What is the designed way forward?
Select an answer to reveal the explanation.
Short Explanation
Every deployer's nightmare: one mistyped VLAN and the head vanishes. This is exactly the day the service path was built for — talk to the system outside the network you just broke and fix it in minutes. Out-of-band isn't decoration, it's your recovery insurance.
Full Explanation
The out-of-band path exists precisely for self-inflicted network lockouts. When the configured address points into a VLAN that no longer exists, every in-band door — GUI and SSH alike — depends on the very configuration that is broken; the designed recovery is direct service-path access, which reaches the system outside the broken network so the address or VLAN can be corrected with no impact on stored data. Power-cycling to revert a mistyped address fails on the persistence model: network configuration is a permanent setting that survives reboot, so a restart simply reapplies the bad value. Sweeping the routing domain with ARP requests fails on mechanism and scale — an address placed in a nonexistent VLAN has no listeners to answer, and hunting the open internet for a management interface is brute force where a designed cable exists. Requiring a warranty reimaging fails by misclassifying a routine operator error as a product fault; the recovery path is a product feature. Exam caveat: this scenario is the standard exam test for why the service path stays part of the access design. Operational check: from a laptop on the service path, correct the VLAN and address, confirm management reachability from the proper subnet, and leave the service cable dressed but attached.