What does a network device hold per TACACS+ server, and what decides which server a given service asks?
answer
- ordered list, keyed on a name
- server-type routes the three exchanges
- port 49, timeout five seconds
- each attempt costs its own timeout
- counters separate timeouts from errors
basics
~20 sEach server entry carries a name, an address, a port (49 by default), a shared secret and a timeout in seconds (5 by default); the list is ordered by the operator, and each entry's server-type says which exchanges that host answers.
solid answer
~40 sRFC 9105's `ietf-system-tacacs-plus` model gives vendor-neutral names for what a device holds per server. `/system/tacacs-plus/server` is a list **ordered by the operator** (`ordered-by user`) and keyed on `name`; each entry carries `address`, `port` (49 by default), `shared-secret`, `timeout` in seconds (5 by default), `single-connection` (false by default), and optionally `source-ip` or `source-interface` and `vrf-instance`. `server-type` selects which of the three exchanges - authentication, authorization, accounting - that host will be asked about, so one ordered list can send command authorization to one host and logins to another. Order is trial order, and `timeout` prices each attempt: a silent entry costs its full timeout before the next is tried. On the other side, RFC 8907 requires a server to allow individual clients to be defined and to accept connections only from those defined clients.
go deeper
Recall that a device holds an address, a port, a shared secret and a timeout for each device-administration server, and that the servers are tried in the order the operator wrote them.
Explain how server-type routes an exchange to an eligible host and how timeout prices each attempt, and keep the method list's ordering separate from the server list's.
Diagnose from the counters: name which of them separate an unreachable host from one answering with errors, and turn a login's wall-clock delay into a count of silent entries.
Judge how per-device key separation and source-address control constrain who can administer which sites when the engineers are a contractor's rather than your own.
## What one server entry holds On this branch the **client is the network device**, not the human and not a piece of software, and what follows is what that device holds about each device-administration server it may talk to. RFC 9105's `ietf-system-tacacs-plus` module is the vendor-neutral way to name it; every vendor's command line expresses the same fields under different words. | Field | What it holds | Model default | |---|---|---| | `name` | the key that identifies the entry in the list | none | | `address` | where the device-administration server is reached | none | | `port` | the transport port the device connects to | 49 | | `shared-secret` | the per-client key this device uses with that server | none | | `server-type` | which of the three exchanges this host answers | none | | `timeout` | seconds to wait for a response before trying elsewhere | 5 | | `single-connection` | whether several sessions may share one TCP connection | false | | `source-ip` / `source-interface` | which address the device originates the connection from | none | | `vrf-instance` | which routing instance the traffic is carried in | none | ## What routes a service to a host Two things together, and candidates routinely collapse them into one. - The **method list** for the service decides that TACACS+ is asked at all, and where TACACS+ sits relative to the other methods. - The **server list** decides which hosts stand behind the TACACS+ method, in which order, and `server-type` decides which of those hosts is eligible for the exchange in hand. So a device can be pointed at three servers of which only two answer authorization, and a command-authorization exchange will simply never be offered to the third. Nothing about that is visible to an operator reading the method list alone. ## Ordered, and what the order costs The list is **ordered by the operator**, walked from the top, and tried one entry at a time. There is no load balancing, no parallel query and no scoring: the device asks one host, and only when that attempt produces no decision does it try the next. `timeout` is therefore a price per entry, not a budget for the whole list. Two silent entries ahead of a live one at the model's five-second default is ten seconds of an engineer's login, every login, until the configuration or the servers change. That is also why the statistics in the same model matter. An operator diagnosing a site that has gone slow reads, per server: - `connection-opens`, `connection-closes` and `connection-aborts` - whether connections are being made and how they end; - `connection-failures` and `connection-timeouts` - whether the device cannot get an answer at all; - `messages-sent`, `messages-received` and `errors-received` - whether the host is answering and what it is answering with; - `sessions` - how much work is actually flowing through that entry. The pair that settles the usual argument is `connection-timeouts` against `errors-received`. A host that is unreachable and a host that is answering badly look identical from an operator's chair, and those two counters tell them apart. ## What the server expects from the device The wiring is not one-sided. RFC 8907 requires a TACACS+ server to allow individual clients to be defined, and to accept connections only from clients so defined. That is why `source-ip`, `source-interface` and `vrf-instance` on the device side are operationally load-bearing rather than cosmetic: they decide which address the server actually sees, and the server will refuse a connection from anything it does not hold. Outside the TLS transport, the **per-client shared secret is the only per-device separation the protocol offers**. Where a contractor's engineers administer routers at sites a co-operative owns, that granularity is what lets one site's key be changed without touching another's, and what lets a server distinguish one site's device from the next. How strong that key should be and how often it should change belong to the protection side of the branch, not here; what belongs here is that the entry names one, per server, per device. ## What the entry does not decide - It does not decide the content of an answer. Which argument-value pairs come back, and what the device does with them, is the authorization exchange's business. - It does not decide the obfuscation. `shared-secret` feeds it, but the mechanism and its weaknesses are the payload-protection subject. - It does not make a host authoritative for a service it is not typed for; an entry with the wrong `server-type` is silently not asked.
- An engineer's login to a site router takes about ten seconds to complete - what does that number suggest?Two entries ahead of the host that answered, each silent for its own five-second timeout, is the arithmetic that fits. Timeouts are charged per server, not per list, so the wait grows with the number of unresponsive entries the device walks before reaching a live one.
- Which counters distinguish a server that is unreachable from one that is answering badly?`connection-timeouts` and `connection-failures` rise when the device gets nothing back, while `messages-received` stays flat for that entry. A host that is answering raises `messages-received`, and `errors-received` rising with it points at a server that is reachable and reporting a problem.
- Why does RFC 8907 require a server to accept connections only from clients it has been configured with?Because the client is a network device and, outside the TLS transport, the per-client shared secret is the only per-device separation the protocol offers. Defining each client lets the server refuse anything else outright, rather than accepting a session from an unknown host at all.
saying these in an interview costs you the question
- Thinks the device load-balances across the configured servers.
- Assumes every configured server answers all three exchanges.
- Says the shared secret is per operator rather than per device.
- Treats the timeout as the total wait for the whole list.
- Believes the source address the device uses is cosmetic.