TAC+: Closing TCP/IP

[scbbni]

Problem: I'm having problems getting one of my Catalyst 6513 switches to authenicate with my ACS server.

Background: I've got two Cisco ACS servers and several hundred switches on my network. All of my switches (except teh 6513) can authenticate with both ACS servers. The 6513 in question can authenticate with the exteral ACS but not the internal ACS. Debugging productes the following output:

Aug 9 11:06:36: TAC+: send AUTHEN/START packet ver=192 id=2395573294

Aug 9 11:06:36: TAC+: Using default tacacs server-group "tacacs+" list.

Aug 9 11:06:36: TAC+: X.X.X..15 (2395573294) AUTHEN/START/LOGIN/ASCII queued

Aug 9 11:06:36: TAC+: Opening TCP/IP to X.X.X..15/49 timeout=5

Aug 9 11:06:36: TAC+: Opened TCP/IP handle 0x45938888 to X.X.X..15/49

Aug 9 11:06:37: TAC+: Closing TCP/IP 0x45938888 connection to X.X.X..15/49

Aug 9 11:06:37: TAC+: Opening TCP/IP to X.X.X..15/49 timeout=5

Aug 9 11:06:37: TAC+: Opened TCP/IP handle 0x45938888 to X.X.X..15/49

Aug 9 11:06:37: TAC+: Closing TCP/IP 0x45938888 connection to X.X.X..15/49

Aug 9 11:06:37: TAC+: Opening TCP/IP to X.X.X..15/49 timeout=5

Aug 9 11:06:37: TAC+: Opened TCP/IP handle 0x51653708 to X.X.X..15/49

Aug 9 11:06:37: TAC+: Closing TCP/IP 0x51653708 connection to X.X.X..15/49

Does anyone know what would be causing the TCP connection to open and close constantly?

[Richard Burts]

Jason

My first thought was that the request was timing out and retrying. But looking at the timestamps of the messages there is not enough time elapsed for it to be a timeout.

My next thought is that the 6513 is sending the request (on TCP port 49) and the ACS server is sending some kind of reject. Is there anything in the failed attempts report on the server that would indicate that the server saw the request and did not process it for some reason? If there are entries in the failed attempts report they should indicate what the server thought the problem was. It might be an incorrect password, it might be that the 6513 is sourcing the packets from an address different than the server is expecting.

It also might be helpful to verify that the config of the 6513 is correct, that it has the correct address for the server and correct password. If you know the address that the 6513 is sourcing from it would be good to verify IP connectivity by doing an extended ping. In the extended ping specify the destination as the address of the server and specify the source (in the extended commands) as the address that TACACS is sourced from.

HTH

Rick

[scbbni]

Rick,

Thanks for the tip. I found the problem this morning while looking over the "Failed Attempts" log file on the ACS.

In a nutshell, the ACS is directly connected to 6513 that is having the problems. I discovered that the default gateway IP address of SVI 2 (same VLAN that the ACS belongs to and is configured on the 6513 in question) shows up prominently in the "Failed Attempts" log file. I added the default gateway IP X.X.2.1 of SVI 2 to the ACS entry for my 6513 and was able to successfully log in via TACACS.

This would explain why it worked when it was pointed at my secondary ACS which is located on another switch, VLAN and subnet, but not on the ACS that it was directly connected to.

Question: Is there a way to source a specific IP address on the router? I've tried creating a Loopback interface and router ID but did not have any success. I vaguely remember a command from years past "Source Interface . . . " but that command does not exist on the current IOS of 720 Sup Engine.

Thanks,

Jason

[Richard Burts]

Jason

Thanks for posting back and indicating that you found the problem and for identifying the solution. It makes the forum more helpful when we can read about a problem and also see what the solution to the problem was.

Try the command ip tacacs source-interface and I believe it will do what you want.

HTH

Rick

[scbbni]

Rick,

Sorry, just got back in the office. The "IP TACACS source-interface . . ." command worked.

I might have been a little unclear in my last posting. Just to clear things up for everyone follings this little problem, SVI 2(Int VLAN 2) has the X.X.2.1 IP address assigned to it and is used as the default-gateway by all devices in VLAN 2 (including the ACS). It is not the default gateway of the switch. As the ACS is directly connected to the switch physically/logically via VLAN 2 the 6513 was using X.X.2.1 as the source address to reach the ACS instead of the management IP address assigned to VLAN 600. When connecting to the secondary ACS it would source the management IP assigned to VALN 600, as would be expected.

Again, thanks for the help.