Troubleshooting "%TAC+: no address for get_server" on Cisco Devices

If a Cisco router or switch logs %TAC+: no address for get_server, start with the boring explanation: the device has a TACACS+ server entry it cannot turn into a usable destination address.

That usually means one of four things:

The TACACS+ server is configured with a bad hostname or missing address.
DNS is not working from the network device.
The AAA server group points at a server name that is not actually defined.
The device is trying to source the request from the wrong interface, VRF, or management path.

Do not let the message send you straight into AAA policy debugging. AAA policy can absolutely be wrong, but this particular message is usually earlier in the chain. The device is failing before it gets a useful TACACS+ conversation going.

Fast Path

If you are in the middle of an outage window, check these first:

show running-config | include ^aaa|^tacacs|server-private|source-interface
show tacacs
show hosts
ping <tacacs-server-ip>
telnet <tacacs-server-ip> 49
test aaa group tacacs+ <username> <password> legacy

Replace the test username and password with a real test account. If your platform expects new-code instead of legacy, use the form supported by that IOS, IOS XE, NX-OS, or IOS XR release.

Also check the firewall rule. TACACS+ uses TCP port 49, not UDP. That detail gets mistyped in configs, firewall requests, and old runbooks often enough that it is worth saying plainly.

Cisco's own TACACS+ configuration documentation describes the default TACACS+ daemon port as TCP 49, and Cisco's TACACS troubleshooting guide recommends test aaa, debug aaa authentication, debug aaa authorization, debug tacacs, and TCP transaction debugging when the basic checks do not explain the failure.

What The Message Means

The useful part of %TAC+: no address for get_server is no address.

The device is trying to choose a TACACS+ server from the configured method list or server group. When it goes to use that server, it cannot find an address for it. That may be because the server was configured by hostname and DNS failed, or because the server group references a name that does not map to a configured server.

That is different from these TACACS+ failures:

TCP connection timeout to the TACACS+ server
Shared secret mismatch
User rejected by the TACACS+ server
Authorization failure after successful authentication
Accounting update failure

Those are later-stage problems. no address for get_server is a configuration, resolution, or routing sanity check first.

Check The TACACS+ Configuration

Start by looking at the running configuration. The exact syntax depends on the age of the platform, but you are looking for three things: server definitions, server groups, and AAA method lists.

Older IOS configurations often look like this:

aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local

tacacs-server host 192.0.2.10 key 7 <encrypted-key>
tacacs-server host 192.0.2.11 key 7 <encrypted-key>

Newer IOS XE-style configurations are more likely to use named servers:

aaa new-model

tacacs server TACACS-1
 address ipv4 192.0.2.10
 key 7 <encrypted-key>

tacacs server TACACS-2
 address ipv4 192.0.2.11
 key 7 <encrypted-key>

aaa group server tacacs+ TACACS-SERVERS
 server name TACACS-1
 server name TACACS-2

aaa authentication login default group TACACS-SERVERS local
aaa authorization exec default group TACACS-SERVERS local

The easy mistake in the named-server model is a mismatch between the server name and the group reference. TACACS-1, tacacs-1, ISE-TACACS-1, and ISE_TACACS_1 are not interchangeable just because a human knows what they mean.

Look for server group entries that point to names that do not exist:

aaa group server tacacs+ TACACS-SERVERS
 server name TACACS-PRIMARY

If there is no matching tacacs server TACACS-PRIMARY block with an address line, you have a strong suspect.

Do Not Trust Hostnames Until DNS Works

Hostnames are convenient until they are not. If your TACACS+ server is configured by hostname, verify that the Cisco device can resolve it from the same routing context it uses for management.

Check the host table and DNS configuration:

show hosts
show running-config | include ^ip name-server|^ip domain|lookup

Then test resolution:

ping tacacs-1.example.com

If the name does not resolve, either fix DNS on the device or use IP addresses for TACACS+ server definitions. I generally prefer IP addresses for network device AAA. DNS is fine for plenty of things, but authentication for emergency device access is not where I want extra moving parts unless there is a clear operational reason.

Check Source Interface And VRF

The next common trap is the source path. Your TACACS+ server may be perfectly reachable from the data plane while the device is trying to use a management VRF, a loopback address, or an interface the server does not recognize.

Look for source-interface configuration:

show running-config | include tacacs source-interface|ip tacacs source-interface

Depending on platform and syntax, you may see something like:

ip tacacs source-interface Loopback0

or:

aaa group server tacacs+ TACACS-SERVERS
 ip tacacs source-interface Loopback0

That source interface has to make sense from both directions:

The device must be able to route from that interface or VRF to the TACACS+ server.
The TACACS+ server must have the device configured with the source IP it will actually use.
Any firewall between the device and server must allow TCP/49 from that source IP to the server.

If the management interface lives in a VRF, test in the VRF:

ping vrf Mgmt-vrf <tacacs-server-ip>

VRF-aware TACACS+ syntax varies by platform and release, so this is one of those places where blindly pasting from another switch can waste an afternoon. Confirm the syntax for the platform you are touching.

Test TCP/49, Not Just Ping

Ping only proves ICMP reachability. TACACS+ needs TCP/49.

On many IOS-style devices, a quick TCP test is:

telnet <tacacs-server-ip> 49

You are not trying to log in with Telnet. You are using the command as a crude TCP socket test. A blank screen or open connection usually means the TCP session established. A timeout or refusal tells you to look at routing, ACLs, firewalls, the TACACS+ daemon, or the server's local firewall.

If Telnet is not available or is disabled by policy, use whatever equivalent TCP connectivity test your platform provides. The important part is testing TCP/49 from the device and, if relevant, from the correct VRF or source interface.

Use `test aaa` Carefully

Once the server address and TCP path look sane, test AAA directly:

test aaa group tacacs+ <username> <password> legacy

On some platforms or configurations, the useful form may be new-code instead of legacy. Cisco's VRF TACACS+ troubleshooting examples call out cases where new-code is required. The annoying answer is that you need to know the device family and software train in front of you.

The result tells you where to go next:

User successfully authenticated means the basic TACACS+ path works.
No authoritative response from any server usually means the device reached no usable TACACS+ server, or all servers failed to answer in a way IOS accepts.
Authentication rejected means the server was reachable, but the user, policy, secret, or command authorization path is wrong.
no address for get_server keeps you focused on server definition, DNS, source-interface, or server-group mapping.

Turn On Debugs Last, And Turn Them Off

Debugging AAA on a busy production device can be noisy. Use it when the basic checks do not explain the problem, and be ready to disable it.

Useful IOS-style debugs include:

debug aaa authentication
debug aaa authorization
debug tacacs
debug ip tcp transaction

Then reproduce the failure with a login attempt or test aaa.

When you are done:

undebug all

If the debug says the device is opening TCP to the expected IP and port, the no address problem is probably gone and you are now debugging a different AAA failure. That is progress. Annoying progress, perhaps, but progress.

Avoid Locking Yourself Out

Before changing AAA on a remote Cisco device, make sure you have a fallback. At minimum, keep local authentication in the method list:

aaa authentication login default group TACACS-SERVERS local
aaa authorization exec default group TACACS-SERVERS local

Have a known local user configured, and be careful with VTY restrictions. I have a separate write-up on securing virtual terminal lines that pairs well with this kind of AAA work, along with a basic example of username/password authentication in Cisco IOS.

For risky remote changes, schedule a rollback reload before touching AAA. The old trick still works because it protects you from your own confidence. See Scheduled Reloads Will Save Your Bacon for the pattern.

A Practical Troubleshooting Order

Here is the order I would use on a real device:

Confirm the running configuration has a valid TACACS+ server address.
Confirm every server name in the AAA group maps to a real tacacs server block.
If hostnames are used, confirm DNS resolution from the device.
Confirm the source interface and VRF are intentional.
Ping the TACACS+ server from the correct routing context.
Test TCP/49 from the device to the server.
Run test aaa group tacacs+.
Check the TACACS+ server logs for the device source IP.
Use debugs only after the configuration and path checks make sense.

That order keeps you from spending thirty minutes staring at TACACS+ policy when the switch simply cannot resolve tacacs-1.example.com.

The Fix Is Usually Small

The %TAC+: no address for get_server message looks more mysterious than it is. Most of the time, the fix is one of these:

Add the missing address ipv4 line under the named TACACS+ server.
Correct a typo between the AAA server group and the named server.
Replace a broken hostname with an IP address.
Fix DNS on the network device.
Configure the correct source interface or VRF.
Permit TCP/49 from the actual device source IP to the TACACS+ server.

Once the device can identify the server address and open TCP/49, you may still have normal AAA work to do: shared secret, user policy, shell profile, command authorization, accounting, and fallback behavior. But at least you will be debugging the right layer.

References

Cisco: Troubleshoot TACACS Authentication Issues
Cisco: Configuring TACACS
Cisco: IOS Per VRF TACACS+ Troubleshooting

For more Cisco network operations notes, start at Slaptijack.