aaa tacacs dead-time to solve long waits and inaccessible device

[will]

simple problem: TACACS fails such that device completely inaccessible. cisco ios-xe switch with any new version (17+).

Problem1: we had some sort of asymmetric routing issue with TACACS flowing through 2 firewalls (1 out and a different one back). enough communication was working such that switch thought TACACS was alive, but the response was not received properly to login with TACACS user. as a result, switch never failed to local login backup option. how does TACACS sense livability: pings or an official TACACS response? the only thing I can see is that AAA livability is through pings, which were working asymmetrically but not via TCP 49, which was probably not working asymmetrically. if it senses livability through some non-ping method, why can i get into a state where TACACS fails my valid user login, but the switch never fails to "login local" option?

Problem2: in trying to fix this madness, I'm looking for TACACS dead timer and a test user configuration so that TACACS can be officially marked down, using the pre-configured test user. nexus has this, via this configuration:

tacacs-server host 1.1.1.1 test username <TACUSER> password <TACPWD> idle-time 3 (minutes)
tacacs-server deadtime 5 (minutes)

I found this surprising bug (albeit old), which suggests IOS-XE doesn't have TACACS dead-timer feature, but radius does? Really? this is kind of shocking:

CSCuo24600 : Bug Search Tool (cisco.com)

Problem3: occasionally, we have a real, truly dead TACACS server set, but then command authorization makes you wait 20-30 seconds for a response using the locally configured backup administrator account. Timeout for each server in a 2-set group is 10 seconds, so I presume 2x10=20 seconds is what I'm waiting for, for each command to fail authorization before the prompt proceeds. How to solve this issue and make the response speedy??

thx in advance!

[MHM Cisco World]

Config tunnel if you can and make device reach tacacs server via tunnel.

In that case there is no asymmetric and there is no delay in response.

Try this way

Note:- before try make sure you have local username abd local enable password 

MHM

[Arne Bier · Accepted solution]

TACACS+ just rides on top of a normal TCP connection. If the TCP connection doesn't work properly (i.e. SYN SYN/ACK ACK) then you will have a hard time getting TACACS+ to ride on top of that.  Sort the TCP flow out, and then TACACS+ will be fine. Don't think about ICMP or other hacks - it's just TCP.

You're right about RADIUS having dead timer support in IOS, and TACACS+ is quite primitive by comparison. That's why users will always experience a delay when the primary TACACS server is dead - the IOS is not clever enough to resist the urge to always try it, even though it knows that it didn't work 1 second ago!  Such is life.

The only solution to a speedy response is to set lower TACACS+ timeout values.

The only time I had to be cautious about setting them too aggressively low, was with one customer who used TACACS+ on ISE, but the authentication was to a remote RADIUS token server.  In one scenario, if the primary remote RADIUS token server was dead, then the minimum timeout in ISE was 5 seconds before it tried remote server 2. So my formula for TACACS+ timeout values on IOS devices was always at least 10 seconds + 5 seconds for some normal propagation/latency delays on slow WAN links.