A routing loop has taken down the production network, and administrators cannot reach the core switches over SSH because SSH runs over that same network. Which capability would have let them reach the switches' management consoles during this outage?
Select an answer to reveal the explanation.
Short Explanation
If the only road to the fire station is the one that's on fire, you're stuck. Out-of-band management is the separate back road, a console network that doesn't depend on production being up. Telnet's the trap; it's a different protocol riding the same broken road, and it's unencrypted to boot.
Full Explanation
Out-of-band management provides administrative access to network devices through a path that is independent of the production network, such as a dedicated management network connected to console ports through a console server, sometimes with a cellular or separate internet link as backup. When the production network fails, administrators can still reach device consoles to diagnose and correct the problem. It also improves security by keeping management traffic off user networks. In-band management with SSH over the production VLAN is exactly what failed in this scenario, because it depends on the network it is meant to repair. A jump server on the affected production VLAN is equally unreachable, or unable to reach the switches, when that network is down; a jump host helps control access but does not create an independent path. Telnet is another in-band protocol that uses the same failed network, and it sends credentials and commands in cleartext, so it adds risk without solving the reachability problem. Exam caveat: out-of-band access is powerful and must itself be secured with strong authentication, restricted access, and logging, because it bypasses many production controls. Operational check: connect each core device's console port to a console server on a separate network, test access while production links are disabled, and restrict and log who can use the console path.