skip to content

After an access concentrator reboots, what does an Accounting-On (7) record tell a RADIUS server about sessions it still shows as live?

level: seniorimportance: should knowfreq 38%

answer

  1. a crash reports nothing on the way down
  2. the server's view outlives the sessions
  3. a record about the device, not a session
  4. no session id, no counters
  5. Accounting-On (7) after restart, Accounting-Off (8) before

basics

~20 s

It tells the server that this access device has started accounting afresh, so every session the server still shows open for that device ended without a Stop record. Closing them out is conventional server behaviour, not something the record itself commands.

solid answer

~40 s

An unplanned restart kills every session on the device and sends no `Stop (2)` for any of them, because the device is gone before it can report. When it comes back it sends an `Accounting-Request (Code 4)` with `Acct-Status-Type = Accounting-On (7)`, carrying its own identity in `NAS-IP-Address (4)` or `NAS-Identifier (32)` and no `Acct-Session-Id (44)` — it is a device-level record, not a session one. The inference a server draws is that its open sessions for that device are orphans. Closing them out is the conventional behaviour, not a rule the record carries. Those sessions have no final counters and no genuine `Acct-Terminate-Cause (49)`, so the best measurement available is the last `Interim-Update (3)` received. `Accounting-Off (8)` is the planned counterpart, sent before a controlled shutdown.

code

pseudocode · 15 lines
pseudocode
// the access device has restarted after losing power
Accounting-Request  ->
    Acct-Status-Type = Accounting-On (7)
    NAS-IP-Address   = 198.51.100.7
    NAS-Identifier   = "concentrator-north"
    // no Acct-Session-Id: this is a device record

// what an accounting store conventionally does with it
// (the record marks the restart; it does not command this)
for each session in open_sessions:
    if session.NAS-IP-Address == 198.51.100.7:
        close session
            using   last_interim(session).Acct-Input-Octets
            and     last_interim(session).Acct-Session-Time
            marking terminate_cause as unknown

go deeper

for a junior

Know that a RADIUS accounting session stays open until a record closes it — nothing in the protocol times it out, so a device that vanishes leaves its sessions open on the server.

for a middle

Explain the two device-level values: Accounting-Off (8) before a planned shutdown, Accounting-On (7) on restart, both naming the device and carrying no session id.

for a senior

Demonstrate the production judgment: what you bill for an orphan, why the interim period bounds the loss, and what sweeps up when the marker itself is lost.

for a principal

Frame it as an exposure the co-operative carries: reboots are certain, so decide the acceptable unmeasured window and fund the reporting rate and cleanup that hold it.

## What a reboot does to the accounting record stream RADIUS accounting has no keep-alive and no session timeout of its own. A session is open because a `Start (1)` arrived and stays open until a `Stop (2)` arrives. When an access device loses power or panics, both halves of that contract break at once: - Every session it was carrying ends instantly, in the real world. - No `Stop (2)` is sent for any of them, because sending one requires the device to still be running. - The server's view is unchanged: it still shows every one of those sessions as live, with counters frozen at the last `Interim-Update (3)` it happened to receive. Without some signal, those sessions stay open forever. `Accounting-On (7)` is that signal. ## The two device-level records | Value | Sent when | What it implies about existing sessions | |---|---|---| | `Accounting-Off (8)` | Before a planned shutdown | The device is going away deliberately; sessions are ending now, at a time the operator knows | | `Accounting-On (7)` | When the device starts accounting | The device has restarted; anything the server still shows open for it is an orphan | Both records share a shape that distinguishes them from the session trio: - They carry the device's identity — `NAS-IP-Address (4)`, often `NAS-Identifier (32)` — because the whole point is to name the device. - They carry **no `Acct-Session-Id (44)`**, because they are not about any one session. - They carry no traffic counters, for the same reason. ## What the specification says, and what the deployment does This distinction is worth holding precisely, because it is easy to over-claim. The accounting specification defines these values as markers that accounting has started or stopped on the device. **Closing out the server's stale sessions is what accounting stores conventionally do with that marker; it is not an instruction the record carries.** Two practical consequences follow: 1. A collector that ignores `Accounting-On (7)` is not violating the protocol. It is simply accumulating orphaned sessions, and it will keep doing so silently. 2. An operator cannot assume a third-party collector behaves this way, and has to confirm it rather than infer it from the record's existence. ## What the orphans cost The damage is rarely the record-keeping itself: - **Measurement is truncated.** The session's real end is unknown, and the only defensible figures are the last interim record's counters and `Acct-Session-Time (46)`. Everything between that record and the crash is unmeasured, which makes the interim period a direct measure of how much revenue a reboot can lose. - **Concurrency policy misfires.** An operator that limits a member to one live session reads the open orphan as that session, so the subscriber's reconnection is refused by a session that no longer exists anywhere but in a database row. - **Capacity and address views drift.** Anything driven by the set of open sessions — an address-in-use view, a live-subscriber count, a per-region utilisation figure — carries the ghosts. - **The signal itself is best-effort.** `Accounting-On (7)` travels as an ordinary `Accounting-Request (Code 4)` over UDP and can be lost like any other record. A deployment that relies on it alone, with no age-based sweep behind it, is one dropped datagram from permanent orphans. ## Why it is not a substitute for Stop records A tempting shortcut is to stop sending interim records and rely on reboot markers to tidy up. That fails on all three axes an operator cares about: - **No counters.** Sessions closed by inference have whatever the last interim record said, and if there were no interim records, they have the `Start (1)`'s zeros. - **No cause.** `Acct-Terminate-Cause (49)` is absent. The value `NAS Reboot (11)` exists, but it belongs in a `Stop (2)` record a device manages to send during a *graceful* reload — it does not appear by magic on a session closed by inference after a crash. - **One timestamp for everything.** Every orphan closes at the moment the marker was processed, so a thousand sessions share an end time that is true of none of them. The honest design keeps interim records frequent enough that the worst case is tolerable, treats `Accounting-On (7)` as the fast path for cleanup, and keeps an age-based sweep behind it for the times the marker never arrives.

  • What does Accounting-Off (8) mark, and why is it more useful than Accounting-On (7)?
    It is sent before a planned shutdown, while the device is still running. That lets it be followed by real `Stop (2)` records with true counters and a genuine `Acct-Terminate-Cause (49)`, so a maintenance window costs no measurement at all — unlike a crash, which is reconstructed after the fact.
  • Why is an Accounting-On record not a substitute for per-session Stop records?
    It carries no counters and no per-session cause, and it closes every orphan at one timestamp. The sessions get the last `Interim-Update (3)`'s figures, and everything after that record is unmeasured. It is cleanup, not measurement.
  • The Accounting-On record itself is lost in transit. What then?
    The orphans stay open indefinitely, because nothing else in the protocol expires a session. Retries help, but the record is best-effort like any other, so a deployment needs an age-based sweep — close sessions whose last interim record is far older than the interim period — as the backstop.

saying these in an interview costs you the question

  • Thinks the device sends a Stop for each session before crashing
  • Says Accounting-On (7) carries an Acct-Session-Id (44)
  • Claims the specification orders the server to close stale sessions
  • Confuses Accounting-Off (8) with tearing down a live session
  • Assumes orphaned sessions expire on their own