A regional planning commission sees routers reject AAA login even though usernames exist on the TACACS+ server. Which cause commonly produces that failure pattern?
Select an answer to reveal the explanation.
Short Explanation
If the router and TACACS box do not share the same secret handshake, the server never really trusts the request—even when the username looks perfect in the directory.
Full Explanation
A regional planning commission seeing routers reject AAA login even though usernames exist on the TACACS+ server commonly faces a shared-secret mismatch. The router and AAA host must agree on the key; if they differ, requests are dropped or rejected before user validation succeeds, producing failures that look like bad credentials even when the directory entry is correct for planners’ admin accounts.
An OSPF hello-interval mismatch on a LAN unused by management does not govern TACACS+ client/server trust. Enabling NHRP authentication on an unrelated DMVPN hub elsewhere does not explain VTY AAA rejects on planning-commission routers. Setting VTY transport to SSH does not disable AAA method lists; SSH and AAA coexist as the normal hardened pattern for civic device access.
Exam caveat: when usernames are confirmed on the server, verify key, ports, reachability, and source-interface before blaming the user database. Operational check: compare the router TACACS key to the AAA server NAS entry, test from the router with test aaa or careful debugs, confirm packets arrive and are accepted, then retest login for the planning-commission operators. In practice, capture before-and-after outputs in the municipal ticket so the chosen fix is proven against the distractors, and re-check overlay or AAA health after the change window closes.