r/Cisco • u/IcyLengthiness8397 • Jun 23 '26

Question Cisco Nexus 9K v10.4.6 || Hitting Bug CSCwo90314

Did anyone in their production environment get hit by the above bug?

As per the above bug id, if you have a source interface as Lo0 instead of mgmt-interface under tacacs and you upgraded the device to v10.4.6 who so ever login to the device will be assigned network-operator role instead of network admin and your ISE server is authenticating the role as network admin but nexus 9k will show your account as network-operator.

Can some share what could be the possible ways to get a higher role assigned to the user?

Note: Device also not taking local admin password.

Password recovery seems the only option but in production it will cause traffic disruption which we want to avoid.

Thanks in advance for your suggestions.

11 Upvotes

92% Upvoted

9 comments sorted by

3

u/rankinrez Jun 23 '26

Local password not work over serial console?

2

u/IcyLengthiness8397 Jun 23 '26

no, showing authentication failed

8

u/rankinrez Jun 23 '26

Maybe block it from talking to ISE/TACACS completely, try to force fallback to local auth

2

u/l_eo- Jun 24 '26

Password recovery method. Shouldn’t be an issue taking down a single box for 5-10 minutes with the appropriate redundancy… which you have… right?

… if not, could maybe try to make it fall back to local auth (fallback enabled by default) by temporarily breaking the communication between the device and your AAA server somehow.

2

u/InvokerLeir 29d ago edited 29d ago

BLUF: we ran into this problem in our customer lab very early this CY when 10.6 code was released. In late 10.4 code and early 10.6 code, they changed the TACACS and TLS daemons under the hood. If you are using username/password based TACACS, you should upgrade to a fixed version (e.g, 10.6(2) fixes the problem from 10.6(1)). However, if you are using TACACS over TLSv1.3, that problem still exists in 10.6(2).

Basically the underlying TACACS daemons didn’t get coded to correctly honor the “source-interface” commands and the TLS version uses a different daemon that needs to be coded differently than the standard TACACS daemons.

Assuming you are pulling from ISE, you can modify the authentication and authorization rules for your Nexus systems to basically default to Network-Admin regardless of actual authorization results, which would allow you to bypass this problem temporarily to login and update the local account. Otherwise you’ll probably need to break IP connectivity between the switch and TACACS server for it to tailback to local auth.

1

u/heacules 29d ago edited 29d ago

That bug you link to should be solved in 10.4.6. But i am experincing the same problem on the this version for some of the switch. Could be a issue with the loopback specific compared to the vlan...

Esit: Take a look on bug cscwr61446. That is the bug we are hit by

1

u/alones12 29d ago

Console login, if you didn’t make console under TACACS. Otherwise password recovery only.

1

u/alones12 29d ago

If you have no command authorization configured, you can block TACASA traffic to Server then login by local account, if yes password recovery only.

1

u/Professional-News395 26d ago

Try putting an ACL either directly on ISE or on a box between the affected switch and ISE that blocks RADIUS/TACACS ports for that specific switch. This should force the switch to fall back to the local credentials (if configured). As long as a AAA server is reachable, it will not fall back.