First Boot on a VSP 7400: OOB Management Is Silent
A new VSP 7400 is racked in a data center with an out-of-band management network of 10.20.30.0/24, gateway 10.20.30.1, and a planned switch address of 10.20.30.45. The switch is at the console login with no saved configuration. An engineer configures ip address mgmt oob 10.20.30.45/24, connects a laptop at 10.20.30.100/24 to the OOB port, and cannot ping the switch. The OOB port shows link, and the engineer is sure the cable is good. The switch must be managed by SSH from the 10.20.30.0/24 subnet, use NTP server 10.20.30.10 and syslog server 10.20.30.11, and have a local administrative account. The engineer also needs to be confident the configuration survives a reboot before handing the switch to operations.
1. The engineer can see link but cannot ping 10.20.30.45. List the likely reasons and the sequence you would use to make OOB management work, including VRF awareness.
Read the worked answer
Check the physical OOB port, then the VRF. On VOSS the OOB port is not in the global routing table; the address and default route must be installed in the management/OOB VRF. Verify with show ip interface mgmt oob or the release-equivalent that the address is up, and show ip route mgmt oob that a default route exists. The laptop at 10.20.30.100/24 should be in the same subnet; if it is, a missing default route would not prevent same-subnet ping, so also check port admin state, VRF assignment, and any management ACL. Configure the address in the OOB context, add ip route mgmt oob 0.0.0.0/0 10.20.30.1, then test switch-to-laptop ping and laptop-to-switch ping before enabling SSH. A route configured in the global VRF will not fix OOB reachability.
2. How would you verify the configuration survives a reboot, and what hardening would you apply before handing the switch to operations?
Read the worked answer
Save to NVRAM and verify the boot config, not just the running config. Use the platform's save command on the release in use, then compare show config with show running-config and confirm the boot image and config with show boot. Harden before handoff: named admin user with a strong password or SSH key, SSH enabled and Telnet disabled, NTP to 10.20.30.10, syslog to 10.20.30.11, SNMPv3 if needed, a management ACL permitting only 10.20.30.0/24, banner, and correct timezone. Do not rely on an unplanned reboot test in production; schedule one in a maintenance window and confirm OOB, SSH, NTP, and syslog after reload.
3. If the OOB network is unavailable and you must manage the switch in-band, what is a safe design?
Read the worked answer
Use a dedicated in-band management VLAN and SVI in a management VRF, not VLAN 1 and not a tenant I-SID. Give it an address and default route in that VRF, restrict it with an ACL to the management subnet, and carry it only on the links that need it. Prefer a separate physical management path or a dedicated LAG; if management rides the fabric, make sure a fabric failure does not remove your ability to troubleshoot. Keep console access as the break-glass path. Document the VRF, VLAN, and route so a future engineer does not add a global route and wonder why it is ignored.