skip to content

What does a TACACS+ authentication REPLY with status RESTART ask of the network device, and what if it cannot comply?

level: seniorimportance: nice to knowfreq 24%

answer

  1. it rejects the form, not the person
  2. usually the chosen credential type
  3. a fresh sequence, not a continuation
  4. unimplemented means process as FAIL
  5. FOLLOW is deprecated redirection

basics

~20 s

RESTART says the authentication type the device chose is unacceptable, and the sequence may begin again from a fresh START — typically with a different authen_type. A device that does not implement RESTART must process it as FAIL.

solid answer

~40 s

`TAC_PLUS_AUTHEN_STATUS_RESTART` is not a verdict on the operator. It says the server will not conduct this sequence in the form the device chose — most often because the `authen_type` in the START is one it does not accept. The device may begin again: a new sequence, with a new `session_id` and the sequence numbering starting over, typically nominating a different type. The specification also gives devices an escape: one that does not implement RESTART **MUST** process it as FAIL, so the operator is refused rather than left hanging. `TAC_PLUS_AUTHEN_STATUS_FOLLOW` is the neighbouring curiosity — a deprecated redirection mechanism. Servers MUST deprecate it, while clients SHOULD treat it as FAIL, and that difference in strength is deliberate.

go deeper

for a junior

Note only the shape: this status is the far end saying "not like that", not "not you". The attempt can be made again in a different form.

for a middle

Say what is rejected — the credential form the START nominated — and that starting again means a fresh sequence rather than another packet in the current one.

for a senior

Bring the failure mode: a device that does not implement the status turns a type mismatch into a refusal, so the symptom reaching the operator is a password that stopped working while nothing is wrong with it.

for a principal

The call is how much of a mixed device estate you can narrow at once. Restricting accepted credential forms is cheap on the server and expensive across appliances whose behaviour on a rejected form you cannot verify in advance.

## What RESTART actually rejects Of the eight authentication REPLY statuses, `TAC_PLUS_AUTHEN_STATUS_RESTART` is the only one that rejects the **form of the request** rather than the requester. It tells the network device that the server will not conduct this sequence as offered. The usual reason is `authen_type`: the device nominated a type the server has been configured not to accept — and a server is required to give its administrator a way to impose exactly that restriction. What the device may do in response is begin again: - a **new** authentication sequence, not a continuation of this one; - with a new `session_id`, and the sequence numbering starting over; - typically nominating a different `authen_type`, since repeating the rejected one invites the same reply. Note the strength of that: the device **may** restart. It is not obliged to keep trying, and a device that loops on RESTART without changing anything is a device generating traffic to no purpose. ## The escape hatch, and why it exists RESTART is one of the statuses an implementation can legitimately not support, and the specification says what happens then: a client that does not implement RESTART **MUST process it as FAIL**. This is one of the few places the document converts a non-answer into a refusal on purpose rather than by an implementer's accident. That rule is worth holding next to the ERROR rule, because the two look similar and point in opposite directions: | Status | Is it a verdict on the operator? | What an unsupporting device must do | |---|---|---| | `TAC_PLUS_AUTHEN_STATUS_FAIL` | Yes, negative | Apply it | | `TAC_PLUS_AUTHEN_STATUS_ERROR` | No | Behave as if the host could not be contacted | | `TAC_PLUS_AUTHEN_STATUS_RESTART` | No | Process it as FAIL | | `TAC_PLUS_AUTHEN_STATUS_FOLLOW` | No | Treat it as FAIL (a SHOULD, not a MUST) | ERROR says "pretend nothing answered"; RESTART, unimplemented, says "refuse". Both are non-verdicts, and the specification routes them to opposite outcomes. An implementer who reasons by analogy from one to the other gets the wrong behaviour. ## FOLLOW: a deprecated mechanism you should be able to name `TAC_PLUS_AUTHEN_STATUS_FOLLOW` was a redirection mechanism: the server answered with information pointing the device at another host to authenticate against. It is deprecated, and the obligations are asymmetric in a way that is easy to misquote: - **Servers MUST deprecate it** — that is an obligation on the implementation. - **Clients SHOULD treat it as FAIL** — that is a recommendation, not an absolute. Promoting that SHOULD to a MUST is a small error that teaches a false certainty, and the specification is careful elsewhere about the same distinction. If you are asked about FOLLOW, saying "deprecated redirection; clients should treat it as a refusal" is exactly right, and stronger claims are not. ## The operational shape of a RESTART Where RESTART shows up in practice is a mismatch between a device's default type and a server's accepted set: 1. A device is configured — or ships — nominating a credential form the server has been narrowed against. 2. The server answers RESTART on every attempt. 3. A device that implements the status retries with another type and the login eventually works, at the cost of extra round trips. On a slow satellite link that is a visibly sluggish login, and the operator's complaint will be about speed rather than about a rejected type. 4. A device that does **not** implement it turns every attempt into a refusal, and the symptom presented to whoever is on the bridge is "my password stopped working" — with nothing wrong with the password. That second outcome is the reason this status is worth knowing beyond recall. The visible failure and the actual cause sit in different places, and nothing the operator can see connects them. ## What stays with the neighbours The `session_id` and the sequence numbering that a restarted sequence begins afresh are the wire-format subject's material; this leaf's claim is only that a restart is a new sequence rather than a continuation. Which types a server should be narrowed to, and why, is the `authen_type` question. And whether a device should be trying a second server at all after a run of refusals is deployment's.

  • Why does a restart begin a new sequence rather than continue the old one?
    Because the rejection is of the sequence's form, and the parameters that fix that form live in the START. There is no way to renegotiate `authen_type` inside a live sequence, so the device opens a fresh one — new `session_id`, numbering from the beginning — and nominates something else.
  • How is an unimplemented RESTART different from an ERROR, given neither is a verdict?
    By where the specification routes them. An unimplemented RESTART MUST be processed as FAIL, so the operator is refused. ERROR must be treated as though the host could not be contacted, so the device holds no result at all. Two non-verdicts, opposite outcomes — reasoning from one to the other gets it wrong.
  • What should a client do with FOLLOW?
    Treat it as FAIL. It is the deprecated redirection status, and the obligations are asymmetric: servers MUST deprecate it, clients SHOULD treat it as a refusal. Stating the client side as a MUST overstates the document.

saying these in an interview costs you the question

  • Reads RESTART as a rejection of the operator's password
  • Thinks the device continues the same sequence after RESTART
  • Says clients MUST treat FOLLOW as FAIL
  • Confuses RESTART with the obligation attached to ERROR
  • Assumes every device implements the whole status enumeration