Tacacs+ server dead issue

[lni1]

Dear Cisco Guru's,

tacacs-server host 10.2.100.100

tacacs-server host 10.2.17.203

We have 2 tacacs+ servers defined in ACS 5.2. When putting 10.2.100.100 down, tacacs authentication continues to try to authenticate to the dead server,how is this possible ?

Normal behaviour should be going to the second (10.2.17.203) after the first Tacacs+ server timeout (default 5s).

Tacacs+ Server            : 10.2.100.100/49

              Socket opens:         15

             Socket closes:         15

             Socket aborts:          0

             Socket errors:          0

           Socket Timeouts:          0

   Failed Connect Attempts:         85

        Total Packets Sent:          0

        Total Packets Recv:          0

Tacacs+ Server            : 10.2.17.203/49

              Socket opens:        166

             Socket closes:        166

             Socket aborts:          0

             Socket errors:          0

           Socket Timeouts:          0

   Failed Connect Attempts:          0

        Total Packets Sent:        195

        Total Packets Recv:        195

Many thanks,

Lieven Stubbe

Belgian railways

[Richard Burts]

Lieven Stubbe

Perhaps we could gain some insight into the problem if you would provide some details of what you actually do to "putting 10.2.100.100 down". I have seen situations where doing something like stopping a service component would prevent authentication processing, but would still leave the server on line so the request would get to the server but not be processed. If I remember correctly it produced a symptom similar to what you are describing.

And I am somewhat puzzled at your description which seems to indicate that it is not using the second server. But both the socket opens and closes and total packets send and received are quite a bit higher on the second than they are on the first, which seems to suggest that the second server is indeed being used. Perhaps you can provide some clarification?

HTH

Rick

[kaaftab]

kindly check the following link for reference

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2/configuration/guide/acs_config.pdf

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080742f60.shtml

http://www.cisco.com/en/US/docs/net_mgmt/cisco_secure_access_control_server_for_windows/4.2.1/User_Guide/NetCfg.html

[lni1]

Richard, Kashif,

1) 10.2.100.100 is a dummy IP to be sure we have a correct test scenario :

tacacs-server host 10.2.100.100

tacacs-server host 10.2.17.203

2) We have defined 2 testswitches with this config :

C3560 (12.2(53))

C3750 (12.2(55))

with our 3560, it hits the timeout counter of 5s of the dead tacacs server, once logged in, all other tacacs commands are treated by 10.2.17.203

Failed connect attemps raises by 1

with our 3750, with each tacacs command, it hits the timeout counter of 5s of the dead tacacs server everytime, before going to the 10.2.17.203, so all commands are executed but each time with a timeout delay of 5s.

Failed connect attemps raises by number of tacacs commands typed

Many thanks,

Lieven Stubbe

Belgian Railways

[Richard Burts]

Lieven Stubbe

The difference in behavior that you describe between 3560 and 3750 is surprising. I am not clear whether the different behavior reflects differences in platform behavior between 3560 and 3750 or reflects differences between 12.2(53) and 12.2(55) but am inclined to think it is more likely a code version difference. I appreciate that it is aggravating to have 5 s delay on each command. Is it enough of a problem to justify trying a different code version and see if that improves things?

HTH

Rick

[lni1]

Rick,

We carefully selected these 2 software versions within the context of dot1x (dot1x bug free), so it's not really an option to change things. I find it very disturbing that we encounter this behaviour with different IOS. So we suppose it is linked with the software version. Do you think it is worth the try to open a TAC case for this ? It is also very strange there is no deadtime & deadtime-criteria that can be configured (as with Radius) and very little info can be found on Google concerning this subject.

Many thanks,

Lieven Stubbe

Belgian Railways

[Richard Burts]

Lieven Stubbe

If there are factors that led you to choose these specific releases then this is not enough reason to change versions. And I am not certain that it is a version related issue, though that is my first guess at the reason. It might certainly be worth opening a case with Cisco TAC. At a mimimun they may be able to confirm that it is a software version issue, and that could start the process of them producing a fix for the problem.

HTH

Rick