A game studio uses TACACS+ for Nexus logins. When both TACACS+ servers are unreachable, operators can still sign in with a local username. Which AAA arrangement allows that?
Select an answer to reveal the explanation.
Short Explanation
A spare key is not the same thing as the locksmith being open. You can still sign in with a local account when TACACS+ is unreachable only because the method list falls through to the local database. A read-only role limits commands after login and does not choose the server.
Full Explanation
NX-OS authentication walks the login method list in order. The list that tries the TACACS+ group first and then the local user database is what lets studio operators sign in when both TACACS+ servers are unreachable. The switch moves to the local username database because that method is next on the list. An OSPF key chain authenticates routing peers on the uplinks. It does not authenticate interactive operator sessions and it does not store local usernames. A MACsec policy on the management port encrypts frames on that link. It does not store the local usernames and it is not the login method list. A read-only RBAC role limits which commands a session may run after authentication succeeds. The role is not consulted to pick a login server when TACACS+ times out, so the role by itself does not create this fallback. Caveat: an unreachable server is not the same as a reachable server that rejects the password. A reject stays a failed login for that method unless the method list is written to continue. Operational check: block the TACACS+ path in a lab, confirm a local account still opens a session, and confirm the OSPF key chain and the MACsec policy were not required for that login.