skip to content

In RADIUS accounting, what does Acct-Session-Id (44) tie together, and how far does its uniqueness reach?

level: middleimportance: must knowfreq 52%

answer

  1. something must join the records together
  2. the device chooses it, not the server
  3. same value on every record
  4. unique among currently active sessions
  5. key on device identity plus the id

basics

~20 s

Acct-Session-Id (44) is the correlation key the access device puts in every record of one session, so Start, Interim-Update and Stop can be matched. Its uniqueness reaches only across the sessions currently active on that one device.

solid answer

~40 s

The access device generates `Acct-Session-Id (44)` when a session begins and repeats it in every record for that session, so a collector can match the `Start (1)`, the `Interim-Update (3)` records and the `Stop (2)` into one billable event. The server never assigns it. Its guaranteed uniqueness is narrow: it must distinguish the sessions **currently active on that access device**, which means a device may reuse a value after a session closes, and two devices may pick the same value at the same moment. So a collector keys on the device identity — `NAS-IP-Address (4)` or `NAS-Identifier (32)` — together with `Acct-Session-Id (44)`, and usually a time window as well. `Acct-Multi-Session-Id` is the separate key that links several sessions belonging to one logical service.

code

pseudocode · 20 lines
pseudocode
function correlation_key(record):
    // the attribute alone is not enough
    return join(record.NAS-IP-Address, record.Acct-Session-Id)

on Accounting-Request(record):
    k = correlation_key(record)

    if record.Acct-Status-Type == Start (1):
        open_session(k, arrival_time)

    if record.Acct-Status-Type == Interim-Update (3):
        update_session(k, record.Acct-Session-Time,
                          record.Acct-Input-Octets)

    if record.Acct-Status-Type == Stop (2):
        if not open(k):
            record_unmatched_stop(k, record.Acct-Session-Time)
        else:
            close_session(k, record.Acct-Session-Time,
                             record.Acct-Terminate-Cause)

go deeper

for a junior

Recall that every accounting record of one session carries the same Acct-Session-Id (44), and that the access device chooses it rather than the RADIUS server.

for a middle

Explain the scope of the guarantee — unique among the sessions currently live on that device — and why a collector keys on device identity plus the session id.

for a senior

Show the failures you have actually seen: a reused value merging two sessions, a late Stop closing the wrong one, and counters that jump backwards as the symptom.

for a principal

Own the identity scheme for the estate: decide what a durable, auditable session key is across devices and months, since the protocol supplies only a local one.

## The key, and who makes it A subscriber session produces several accounting records spread over its life, and they arrive at the server as independent datagrams that may be reordered, duplicated or lost. `Acct-Session-Id (44)` is what stitches them back together. Two facts about it matter more than anything else: - **The access device generates it**, at the moment the session begins and before the `Start (1)` record leaves. The RADIUS server never assigns it and cannot — the server may not even be reachable when the session opens. - **It is the same value in every record of that session.** The `Start (1)`, each `Interim-Update (3)` and the `Stop (2)` carry it unchanged. That is the entire correlation mechanism; nothing else in the record set performs this job. ## How far the uniqueness actually reaches This is where interview answers usually overreach. The requirement is that the value distinguish the sessions **currently active on that access device**. It is not a globally unique identifier, it is not unique over time, and it is not coordinated between devices. Three consequences follow directly: 1. **A value may be reused.** Once a session has ended, the device is free to issue the same string again. A billing system that keys a subscriber's history on the bare identifier will eventually merge two unrelated sessions months apart. 2. **Two devices may collide.** Nothing stops two access concentrators choosing the same value at the same moment, and a central collector receiving both streams sees one impossible session whose counters jump backwards. 3. **A late Stop can close the wrong session.** If a reused value's `Stop (2)` is delayed and arrives after the next session's `Start (1)`, a naive matcher closes the new session with the old one's counters. The fix is not clever: the correlation key is the tuple, not the attribute. | Keyed on | What it survives | What it does not | |---|---|---| | `Acct-Session-Id (44)` alone | Reordered records within one live session | Reuse over time, and collisions between devices | | Device identity plus the session id | Collisions between devices | Reuse of a value on the same device | | Device identity, session id and a time window | Both, in practice | Nothing left that matters for billing | ## What the neighbouring identifiers are not The word *identifier* is badly overloaded in this protocol, and picking the wrong one is a real failure: - The **one-octet Identifier in the RADIUS header** matches a single reply to a single request. It is reused constantly, it lives for milliseconds, and it has nothing to do with sessions. - **`NAS-Identifier (32)`** names the access device, not the session. - **`User-Name (1)`** names the subscriber. One member of a co-operative may hold several concurrent sessions, so matching records on the username merges them. - **`Acct-Multi-Session-Id`** is the deliberate exception: it links several sessions that belong to one logical service, so each has its own `Acct-Session-Id (44)` while sharing the multi-session value. ## What this costs when it is wrong Billing is the visible symptom, and the failures have distinct shapes rather than one generic wrongness: - Two sessions merged into one produce a single long record with counters that decrease part-way through, because the second session's totals restart from zero. - A `Stop (2)` matched to the wrong `Start (1)` produces a session whose duration bears no relation to `Acct-Session-Time (46)` in the record itself, and the discrepancy between those two numbers is the cheapest audit an operator can run. - An unmatched `Stop (2)` — one whose `Start (1)` never arrived — should be recorded as exactly that. The record carries `Acct-Session-Time (46)` and its own counters, so the session can still be billed honestly without inventing a start time from the collector's clock. ## The rule of thumb Treat `Acct-Session-Id (44)` as a value that is unique in a small neighbourhood: one device, one moment. Anything you want to be unique across your estate or across a month you must build yourself, out of the device's identity, the session id and the time the records arrived.

  • Which party generates Acct-Session-Id (44), and when?
    The access device, at the moment the session begins and before the `Start (1)` record is sent. The server plays no part in choosing it, which is necessary — the device must be able to open and measure a session even while the accounting server is unreachable.
  • What does Acct-Multi-Session-Id link that Acct-Session-Id (44) does not?
    Several distinct sessions that belong to one logical service. Each keeps its own `Acct-Session-Id (44)` so its records correlate individually, while the shared multi-session value lets a collector present them as a single service to the subscriber.
  • A Stop record arrives for a session the server never saw a Start for. What should a biller do?
    Record it as an unmatched stop and bill from the record itself. It carries `Acct-Session-Time (46)` and its own counters, so the duration and volume are known even though the opening record was lost. Inventing a start time from the collector's clock manufactures data.

saying these in an interview costs you the question

  • Assumes Acct-Session-Id (44) is globally unique forever
  • Matches Start and Stop records on User-Name (1)
  • Thinks the RADIUS server assigns the session id
  • Expects a new session id in each Interim-Update
  • Treats two devices' identical session ids as one session