skip to content

In a RADIUS Access-Accept, which attribute caps total session time and which caps idle time?

level: middleimportance: should knowfreq 45%

answer

  1. two clocks, not one
  2. total service versus consecutive silence
  3. seconds, as four-octet integers
  4. whichever expires first wins
  5. the access device holds the timers

basics

~10 s

Session-Timeout (27) caps the total seconds of service; Idle-Timeout (28) caps consecutive idle seconds. Both are four-octet integers in an Access-Accept, and the network access server enforces them, not the RADIUS server.

solid answer

~40 s

Both are four-octet integers in seconds, returned in an Access-Accept (Code 2), and the **network access server** is what enforces them. `Session-Timeout` (27) is the maximum number of seconds of service before the session is terminated — the hard cap on granted time. `Idle-Timeout` (28) is the maximum number of consecutive idle seconds allowed before termination — the silence cap. They run independently, so whichever expires first ends the session. `Termination-Action` (29) then says what the device does at that point: with `Default` it simply ends the service, and with `RADIUS-Request` it sends a fresh Access-Request for the same user instead of dropping them outright.

code

pseudocode · 8 lines
pseudocode
Access-Accept attributes for a day pass:

  Service-Type (6)        = Framed (2)
  Framed-IP-Address (8)   = 255.255.255.254   # the access device assigns
  Filter-Id (11)          = "tier-basic"      # a name the device resolves
  Session-Timeout (27)    = 86400             # seconds of service
  Idle-Timeout (28)       = 600               # seconds of silence allowed
  Termination-Action (29) = Default           # end it, do not re-ask

go deeper

for a junior

Recall that the two attributes measure different things: one bounds the whole session, the other bounds silence. Both are in seconds and both arrive in the reply that accepts the login.

for a middle

Explain that the counters run independently and the earlier one wins, that the access device enforces them, and that Termination-Action (29) decides whether the end is a disconnection or a fresh request.

for a senior

Show the operational consequence: attributes are instructions a device may not implement, and the failure is silent — a pool that drains overnight rather than an error at the moment the attribute was disregarded.

for a principal

The tradeoff to own is how much session-lifetime policy you express in reply attributes at all, given that enforcement is spread across field equipment of varying vintage and no two devices ignore the same ones.

## Two clocks, not one A RADIUS reply does not just say yes. An Access-Accept (Code 2) carries the shape of the session as attributes, and two of them are clocks that measure completely different things. - **`Session-Timeout` (27)** — the maximum number of seconds of service the user should be given before the session is terminated. It counts from the start of service and does not care whether anything is happening. - **`Idle-Timeout` (28)** — the maximum number of consecutive seconds of idle connection allowed before the session is terminated. Its counter resets whenever the session carries traffic. Both are four-octet integers holding a number of **seconds**, and both are instructions to the access device rather than something the RADIUS server can carry out itself. The server never sees the session again after the accept; the device holds the timers. | | `Session-Timeout` (27) | `Idle-Timeout` (28) | |---|---|---| | Measures | Total service time | Consecutive silence | | Resets on traffic | No | Yes | | Typical intent | A granted or purchased quantity | Reclaiming an abandoned session | | Unit | Seconds, four-octet integer | Seconds, four-octet integer | They are not alternatives, and a reply may sensibly carry both. On a ship's passenger wireless network, a day pass is a `Session-Timeout` (27) of 86400 while an `Idle-Timeout` (28) of 600 hands the address back ten minutes after a tablet is put down. The session ends at whichever comes first, and nothing in the protocol ranks one above the other. ## What happens at the end: Termination-Action (29) By itself, an expiring timer says only that service stops. `Termination-Action` (29) says what the access device should do when service is completed. Its two defined behaviours are: 1. **`Default`** — end the service. The user is simply disconnected. 2. **`RADIUS-Request`** — instead of dropping the user, send a new Access-Request for them. The server then gets a fresh chance to decide, and may issue a new accept with new attributes. That second behaviour is what lets a bounded grant be renewed without the user noticing, and it is also why `Session-Timeout` (27) is not automatically a disconnection: the attribute bounds *this* grant, and `Termination-Action` (29) decides whether another one is asked for. ## The same attribute, a different packet, a different meaning `Session-Timeout` (27) has a second meaning that catches people out. In an Access-Challenge (Code 11) rather than an Access-Accept, the attribute is not a session length at all — it is the maximum number of seconds the access device should wait for the user's response to the challenge. Same type number, same encoding, different packet, different semantics. That is why "what does Session-Timeout mean?" is an incomplete question until the packet is named. ## Where this goes wrong in production The failures here are quiet ones, because nothing rejects a timer: - **The device ignores the attribute.** Access devices are not obliged to honour every attribute they receive. A device that implements `Session-Timeout` (27) but not `Idle-Timeout` (28) holds abandoned sessions until the hard cap, and the first symptom is an address pool or a seat count that drains during quiet hours. - **The units are misread.** Both attributes are seconds. A value meant as minutes produces sessions sixty times too long, and every one of them looks deliberate. - **The timers are believed to be server-side.** Operators sometimes expect the RADIUS server to end the session when the number runs out. It cannot: after the accept it holds nothing belonging to that session, and the number it returned is the only influence it has. - **`Termination-Action` (29) is assumed.** A device behaving as `Default` when the design assumed re-asking will drop a user at precisely the boundary a renewal was supposed to smooth over. The habit worth building is the one the ambiguity forces: never say "the timeout" on this protocol. Say which attribute, in which packet, enforced by which box.

  • What does Session-Timeout (27) mean in an Access-Challenge (Code 11) rather than an Access-Accept (Code 2)?
    In an Access-Challenge it is not a session length. It is the maximum number of seconds the access device should wait for the user to answer the challenge before giving up. The type number and the four-octet encoding are identical, so only the packet it arrives in tells you which of the two meanings applies.
  • An access device honours Session-Timeout (27) but ignores Idle-Timeout (28) — what does that cost?
    Abandoned sessions survive until the hard cap instead of being reclaimed after a short silence. Addresses, session slots and any per-session resource stay held by devices that walked away hours ago, and because nothing errors, the first visible symptom is exhaustion during quiet periods rather than a fault anyone can trace to the ignored attribute.

saying these in an interview costs you the question

  • Says Idle-Timeout (28) caps the total length of a session.
  • Calls Session-Timeout (27) the retransmission timeout for the request.
  • Reads either timer as minutes rather than seconds.
  • Thinks the RADIUS server enforces the timers after the accept.
  • Assumes Termination-Action (29) always causes a new Access-Request.