A game studio Nexus switch cannot reach its TACACS servers. Operators can still log in with a local username. Which configuration explains that result?
Select an answer to reveal the explanation.
Short Explanation
Local fallback is a side door you leave unlocked when the main lobby cannot call the guard desk. You list the TACACS servers first and the local user database after them, so a studio operator can still log in while the servers are unreachable. A read-only role decides what that person may type, and it does not build a path to the server.
Full Explanation
NX-OS authentication methods are tried in the order you configure. A list that names the TACACS group and then local authentication will accept a local username when the servers cannot be reached, which is why these operators still get in. The role attached to that local account still limits the commands, but the role is not what created the fallback. A read-only role restricts CLI verbs after login. It does not open a network path to a TACACS server and it does not store a second way to authenticate. MACsec encrypts frames on a link. It does not cache remote user passwords for offline logins. A key chain holds rotating keys for a routing protocol. Those keys are not operator passwords, and the chain is not consulted when someone logs into the switch. Caveat: if the method list has no local method, an outage of the only server group can lock out remote sessions, so the local account has to exist before you depend on it. Operational check: block the TACACS path in a test, log in with the local username, and confirm the session receives the role you intended.