How do a TACACS+ client and server agree to multiplex sessions onto one TCP connection?
answer
- settled on the first two packets
- an offer, then a confirmation
- the flag is ignored afterwards
- one bit in the header flags octet
- no second packet until the status is known
basics
~20 sThe network device offers single connection mode by setting TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 in the first packet's header flags and waits; the server confirms by setting the same flag in its first reply. After those two packets both ends ignore the flag.
solid answer
~40 sSingle connection mode is negotiated on the first two packets of a TCP connection and nowhere else. The network device offers it by setting `TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04` in the `flags` octet of the connection's first packet, and it must not send a second packet on that connection until the server's first reply has settled the question. If that reply also has the flag set, the mode is established and further TACACS+ sessions — each with a new `session_id`, each starting again at `seq_no` 1 — may run over the same connection until either end closes it. If the reply does not set the flag, the server will close the connection at the end of that first session. On every later packet the flag is meaningless and both ends MUST ignore it.
code
pseudocode · 18 linesclient opens a TCP connection to the device-administration server on port 49
send first packet of the first session
with flags bit TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04 set # an offer
wait — do not send a second packet on this connection
until the server's first reply settles the status
on first reply from the server:
if reply.flags has TAC_PLUS_SINGLE_CONNECT_FLAG set
then mode := established
later sessions may share this connection,
each with a new session_id and seq_no starting at 1
else mode := not established
the server closes the connection when this session ends
for every packet after the first two:
ignore the flag entirely, whatever its valuego deeper
Know that a TACACS+ connection normally carries one session, and that the two ends can agree to reuse it for more.
Describe the handshake precisely: the offer in the first packet's flags octet, the wait, the confirmation in the first reply, and the rule that the flag is ignored from then on.
Show you can settle a churn argument from a capture — two packets tell you whether the offer was accepted — and note that the mode permits reuse rather than guaranteeing one connection per device.
Weigh what reuse buys against what it concentrates: fewer connections and less setup cost, against a single failure or a connection-level error taking a device's whole management plane with it until it reconnects.
## The default, and why there is an alternative A TACACS+ connection carries one session by default: the device opens TCP to port 49 on the device-administration server, runs one authentication sequence, one authorization exchange or one accounting exchange, and the connection goes away. On a fabric where every command an engineer types produces an authorization exchange and then an accounting exchange, that default turns a quiet management plane into a stream of short-lived connections. **Single connection mode** is the protocol's own remedy: an agreement, made once per connection, that the two ends will keep it open and run later sessions over it. ## The negotiation, step by step 1. The network device opens the TCP connection and sends the first packet of the first session with `TAC_PLUS_SINGLE_CONNECT_FLAG := 0x04` set in the header's `flags` octet. This is an **offer**, not a statement of fact. 2. The device then waits. It MUST NOT send a second packet on that connection until the status has been established by the server's reply — so a device cannot pipeline a second session in the hope that the offer will be taken up. 3. The server's first reply answers. If it sets the same flag, the mode is established. If it does not, the mode is not established. 4. From the third packet onward the flag is meaningful to nobody: both ends MUST ignore it wherever it appears. That last rule is the part candidates miss. The flag is not a per-packet instruction and it is not re-negotiable mid-connection; it is a two-packet handshake carried inside a field that keeps travelling. ## What each outcome means for the connection | | Flag set in the reply | Flag not set in the reply | |---|---|---| | Mode | established | not established | | After the first session ends | the connection stays open | the server closes the connection | | Later sessions | run on the same connection, each with a fresh `session_id` starting at `seq_no` 1 | each needs a new TCP connection | | Flag on later packets | ignored by both ends | ignored by both ends | Note what does **not** change. Sessions are still sessions: multiplexing does not merge them, each still has its own `session_id`, and each still starts its sequence numbering at 1. Single connection mode is a transport economy, not a change to the session model. ## What still closes an established connection Establishing the mode is not a promise to keep the connection forever. - Either end may close the connection when it chooses; a device with nothing to ask has no obligation to hold it open. - A connection-level ERROR — one arising from connection issues such as a mismatched shared secret rather than from the content of an exchange — means no further new sessions may be accepted on that connection. - Ordinary transport failure closes it like any other TCP connection. So a diagnosis that says "single connection mode is on, therefore we should see one connection per device" is too strong. What the mode buys is the *permission* to reuse, not a guarantee of a single long-lived connection. ## Reading the negotiation in a capture Because the `flags` octet is in the unprotected 12-octet header, the whole negotiation is visible without the shared secret. Look at exactly two packets: the first from the device and the first from the server. If the device's packet has the bit set and the server's reply does not, you have found your answer — the device is asking for reuse and the server is declining, and every subsequent session will pay for a new connection. That is a configuration difference between the two ends, and it is settled on the wire before any body is exchanged. ## Where this sits against configuration Devices and servers expose single connection mode as a setting, and a standard data model for TACACS+ servers carries it as one. But the setting only decides what each end *offers* or *accepts*; what actually happens is decided by those two packets. In an interview, saying "we enabled it on the device" is a weaker answer than "the device offers it in the first packet's flags and the server's first reply either confirms it or does not" — the second describes the mechanism and explains why enabling it on one side alone changes nothing.
- A device sets the flag on the twentieth packet of an established connection — what happens?Nothing. The flag is meaningful only on the first two packets of a connection, and both ends MUST ignore it thereafter. It cannot be used to turn the mode on later, to turn it off, or to renegotiate; the status of the connection was fixed by the server's first reply.
- Under single connection mode, do sequence numbers continue across sessions?No. `seq_no` is per session, not per connection: every new session on the connection starts again at 1 with its own freshly generated `session_id`. The connection is only a pipe. Treating the sequence as connection-wide is a common misreading and would break the odd/even direction rule immediately.
saying these in an interview costs you the question
- Thinking the flag is honoured on every packet of the connection
- Believing one side's configuration alone establishes the mode
- Assuming sequence numbers continue across sessions on a reused connection
- Claiming an established connection can never be closed afterwards
- Saying the device may pipeline a second session before the reply arrives