skip to content

TACACS+ uses TCP port 49 and RADIUS uses UDP ports 1812 and 1813 — what follows from that?

level: juniorimportance: must knowfreq 56%

answer

  1. one is connection-oriented, one is not
  2. who repeats a lost packet
  3. a conversation, not a single question
  4. TCP port 49 against UDP 1812 and 1813
  5. an open connection is not a healthy server

basics

~20 s

TACACS+ over TCP port 49 gets ordered, acknowledged delivery and an explicit connection whose loss is visible, so it can hold a multi-exchange conversation open. RADIUS over UDP makes the network access server own retransmission and server-liveness guessing itself.

solid answer

~40 s

TACACS+ opens a TCP connection to port 49 and runs its exchanges inside it, so ordering and acknowledgement are the transport's job and the device learns immediately when the connection is refused or reset. That suits a protocol whose exchanges are conversations — prompts answered, then possibly one exchange per command an operator types. RADIUS sends each packet as a UDP datagram, authentication to port 1812 and accounting to port 1813, and the network access server owns the retry: it resends the same `Access-Request` after a timeout, a configured number of times, then moves to the next server in its group. That suits a high-volume, one-round-trip admission decision. Note the limit on both sides: TCP tells you a connection died, not that a server which holds it open is still working.

code

pseudocode · 18 lines
pseudocode
// RADIUS over UDP: the network access server owns the retry
send Access-Request to radius_server on UDP port 1812
for attempt in 1 .. max_retries:
    wait retransmit_timeout
    if a reply arrived (Access-Accept, Access-Reject or Access-Challenge):
        stop retransmitting
    resend the identical Access-Request
if still no reply:
    move to the next server in the group

// TACACS+ over TCP: the transport owns delivery, the client still owns liveness
open TCP connection to tacacs_server on port 49
if connection refused or reset:
    move to the next server in the group
send the first packet of the exchange
await the answer, ordered and acknowledged by the transport
if no answer before reply_timeout:
    the connection is open but the server is not answering -> give up on it

go deeper

for a junior

Recall the two transports and the three port numbers, and be able to say one consequence: with TCP the transport repeats a lost packet, with UDP the network access server does it itself.

for a middle

Explain why the transport matches the shape of each protocol's exchange — a multi-packet interactive conversation against a single request and reply — rather than treating TCP as simply the better choice.

for a senior

Show that you know what the transport does not tell you: an open connection is not a healthy server, so a reply timeout and a decision about what the device does when nothing answers are still yours to design.

for a principal

Frame it as where you want failure to be handled. Connection-oriented delivery concentrates failure detection in the transport and state on the server; datagrams push retry and failover into every device, which is cheaper per transaction and harder to reason about at fleet scale.

## The two transports, stated plainly TACACS+, standardised in **RFC 8907**, carries every packet over a **TCP connection to port 49**. RADIUS, defined in **RFC 2865** for authentication and **RFC 2866** for accounting, sends each packet as an independent **UDP datagram**, to **port 1812** and **port 1813** respectively. Everything else in the comparison sits downstream of this one choice, because the transport decides who is responsible when a packet goes missing and whether a sequence of packets is a conversation or a set of unrelated events. ## What TCP buys TACACS+ - **Ordered, acknowledged delivery.** The protocol does not have to detect or repair loss or reordering; if bytes arrive at all, they arrive once and in order. - **An explicit connection.** A refused connection, a reset, or a failure to complete the handshake is an immediate, unambiguous signal that this server is not usable right now. - **Room for a conversation.** A TACACS+ authentication is not one packet each way: the server may come back asking for more input, and the exchange continues over the same connection with the same `session_id`. Running that over a datagram transport would mean re-inventing ordering and retransmission inside the protocol. - **Room for more than one exchange.** Because the connection outlives a single exchange, an implementation can carry several of them on one connection rather than paying for a new handshake each time. - **A cost.** A handshake before the first byte of useful work, per-connection state on the server, and a server that must manage many concurrent connections rather than a stream of independent datagrams. ## What UDP buys RADIUS - **No setup.** One datagram out, one datagram back, and the transaction is complete. For a site admitting thousands of devices, the connection that never had to be built is the cheapest one. - **The client owns the retry.** When no reply arrives, the **network access server** retransmits the *same* `Access-Request` after its configured timeout, for a configured number of attempts, and then fails over to the next server it has been given. - **Cheap failover.** Because there is no connection to abandon, moving to a second server is simply addressing the next datagram somewhere else. - **An ambiguity you cannot remove.** A dropped request, a dropped reply, and a server that received the request and chose not to answer are indistinguishable to the client. All it observes is silence. - **Accounting on its own port**, with its own behaviour: an accounting record is retried until it is acknowledged, because a lost record is a hole in an audit trail rather than a login that can simply be retried by the user. ## Side by side | | TACACS+ | RADIUS | |---|---|---| | Transport and port | TCP, port 49 | UDP, ports 1812 and 1813 | | Who retransmits a lost packet | the transport | the network access server | | Ordering of packets | guaranteed by the transport | not guaranteed | | Immediate failure signal | connection refused or reset | none; only a reply timeout | | Natural shape of an exchange | a multi-packet conversation | one request, one reply | | Cost per transaction | connection setup and server state | a datagram | ## What the transport does not buy either protocol This is where candidates overreach, so state the limits out loud: 1. **TCP is not confidentiality.** It reorders and acknowledges; it hides nothing. Whatever protection a TACACS+ body has comes from the protocol, not from the transport, and the classic transport's protection is obfuscation rather than encryption. 2. **TCP is not liveness.** An open connection to a server that has stopped processing looks exactly like an open connection to a healthy one. The device still needs its own reply timeout, and still needs a plan for the case where no server answers. 3. **UDP is not carelessness.** RADIUS is not missing retransmission; it has placed it in the client, where a one-round-trip transaction can retry cheaply and fail over without unwinding any state. ## Why this is asked first It is the axis a candidate can get wrong in a way that poisons the rest of the comparison. Someone who believes UDP means RADIUS silently drops requests will invent reliability problems that do not exist; someone who believes TCP is what makes TACACS+ 'the secure one' will confuse a transport property with a protection property and then be unable to say what either protocol actually hides. Get the transports and the ports right, say who owns the retry, and the rest of the comparison has somewhere to stand.

  • Why does the transport difference matter more for device administration than for network access?
    A device-administration login is an interactive, multi-packet conversation that may be followed by a further exchange for every command typed, over a session lasting minutes. An admission decision for a device is one short request and one reply. Ordered, connection-oriented delivery earns its setup cost in the first shape and not in the second.
  • What can a RADIUS client not distinguish when no reply arrives?
    A request lost on the way out, a reply lost on the way back, and a server that received the request and chose not to answer all look identical: silence. The client's only observable is the absence of a reply, so it retransmits the same `Access-Request` and eventually fails over rather than diagnosing which happened.
  • Is an established TCP connection enough to tell a device its TACACS+ server is healthy?
    No. TCP reports a refused connection, a reset and a failed handshake, which is more than UDP offers, but a server that holds the connection open and stops answering is invisible at the transport layer. The device still needs its own reply timeout and its own decision about what to do when it fires.

saying these in an interview costs you the question

  • Claims TCP is what makes TACACS+ the secure one
  • Thinks UDP means RADIUS never retries a lost request
  • Says an open TCP connection proves the server is processing
  • Puts RADIUS authentication and accounting on one port
  • Calls UDP a legacy mistake rather than a fit for one-shot decisions
  • Believes the transport, not the protocol, hides the packet body