skip to content

Accounting

Start, interim-update and stop records with a session id, octet counters and a terminate cause - the basis for auditing, billing and session tracking. Asked to see if accounting is an afterthought.

on this pageshow

questions

5

Across one subscriber session, which Acct-Status-Type (40) values does a network access server send, and when?

level: juniorimportance: must knowfreq 46%

answer

  1. one session, more than one record
  2. a type code labels each record
  3. begins, continues, ends
  4. attribute 40 carries the marker
  5. Start 1, Stop 2, Interim-Update 3

basics

~20 s

Acct-Status-Type (40) marks each RADIUS accounting record: Start (1) when the session begins, Interim-Update (3) on a timer while it runs, and Stop (2) when it ends. Each record goes to UDP port 1813 as an Accounting-Request (Code 4).

solid answer

~40 s

RADIUS accounting reports a session as a series of records, each an `Accounting-Request (Code 4)` on UDP port 1813, and `Acct-Status-Type (40)` says which kind. A `Start (1)` goes out once the subscriber is on the link and fixes the session's identity — `Acct-Session-Id (44)`, `User-Name (1)`, the device's own `NAS-IP-Address (4)`. `Interim-Update (3)` repeats while the session lives, carrying `Acct-Session-Time (46)` and the octet counters as they stand. `Stop (2)` closes it with the final counters and `Acct-Terminate-Cause (49)`. The counters are cumulative for the session, not per interval. The same attribute also carries two device-level values, `Accounting-On (7)` and `Accounting-Off (8)`, which are about the access device rather than any one session.

code

pseudocode · 21 lines
pseudocode
// one subscriber session, reported as three records on UDP 1813

Accounting-Request  ->
    Acct-Status-Type  = Start (1)
    Acct-Session-Id   = "4f2a-00c1"
    User-Name         = "member1842"
    NAS-IP-Address    = 198.51.100.7
Accounting-Response <-   // acknowledgement of receipt only

Accounting-Request  ->
    Acct-Status-Type  = Interim-Update (3)
    Acct-Session-Id   = "4f2a-00c1"
    Acct-Session-Time = 3600
    Acct-Input-Octets = 918273645

Accounting-Request  ->
    Acct-Status-Type     = Stop (2)
    Acct-Session-Id      = "4f2a-00c1"
    Acct-Session-Time    = 86400
    Acct-Input-Octets    = 2147483648
    Acct-Terminate-Cause = Lost Carrier (2)

go deeper

for a junior

Recall the trio and the attribute that labels it: Start (1), Interim-Update (3), Stop (2) in Acct-Status-Type (40), sent as Accounting-Request records to UDP port 1813.

for a middle

Explain what each record carries and why the octet counters are cumulative rather than per-interval, and where the interim period comes from.

for a senior

Show what your design does when the trio is incomplete: a crash leaves a Start with no Stop, and the last interim record is the only measurement you have.

for a principal

Frame the reporting rate as a cost: interim records across a large subscriber estate buy measurement accuracy with server load, and the right interval is a business decision.

## What Acct-Status-Type (40) is for RADIUS accounting is a separate exchange from the login. Each record is an **`Accounting-Request (Code 4)`** sent to **UDP port 1813** and answered, if all goes well, by an **`Accounting-Response (Code 5)`**. That response is an acknowledgement of receipt and nothing more — it grants nothing, refuses nothing and renews nothing. Because a single subscriber session produces several records spread over minutes, hours or weeks, every record must say what it is, and `Acct-Status-Type (40)` is the attribute that says it. | Value | Name | What it marks | |---|---|---| | 1 | Start | A session has begun on this access device | | 2 | Stop | That session has ended | | 3 | Interim-Update | The session is still running; here are the counters so far | | 7 | Accounting-On | The access device has started accounting | | 8 | Accounting-Off | The access device is stopping accounting | | 9–14 | — | Reserved for tunnel accounting | | 15 | — | Reserved for failed | ## The three records of one session 1. **`Start (1)`** goes out once the access device has admitted the subscriber and the link carries traffic. Its job is to fix the session's identity, so it carries `Acct-Session-Id (44)`, `User-Name (1)`, the device's own `NAS-IP-Address (4)` or `NAS-Identifier (32)`, `NAS-Port (5)`, often `Calling-Station-Id (31)` and `Called-Station-Id (30)`, and usually the address handed to the subscriber in `Framed-IP-Address (8)`. It carries no traffic counters worth reading, because nothing has moved yet. 2. **`Interim-Update (3)`** repeats on a timer for as long as the session lives. It carries `Acct-Session-Time (46)` and the octet counters as they stand at that instant. `Acct-Interim-Interval (85)` is how a server tells the device how many seconds apart to send them. 3. **`Stop (2)`** closes the session. It carries the final `Acct-Session-Time (46)`, the final counters, and `Acct-Terminate-Cause (49)` saying why the session ended — `User Request (1)` for a subscriber who hung up, `Lost Carrier (2)` for a line that dropped, `Idle Timeout (4)` or `Session Timeout (5)` for a limit the access device itself enforced. ## The counters are cumulative, not per-interval This is the single most common misreading of the trio: - Every `Interim-Update (3)` reports totals **since the session started**, not since the previous update. A collector that sums consecutive updates bills a subscriber several times over. - `Acct-Session-Time (46)` behaves the same way: it is the elapsed seconds of the session, climbing monotonically across the updates. - The `Stop (2)` record's counters are the last word, and they supersede every update before them rather than adding to them. - If no `Stop (2)` ever arrives, the last `Interim-Update (3)` is the best measurement anyone has — which is the whole reason for sending interim records on a link that is expected to stay up for weeks. ## The two device-level values in the same attribute `Accounting-On (7)` and `Accounting-Off (8)` sit in the same attribute but describe the access device rather than a session. They carry the device's identity and no `Acct-Session-Id (44)`, because they are not about any one session. A device sends `Accounting-Off (8)` before a planned shutdown and `Accounting-On (7)` when it resumes. The values `9–14` are reserved for tunnel accounting and `15` for failed, so a record whose status type falls in those ranges is not part of the ordinary trio. ## Where deployments get this wrong - Sending only `Start (1)` and `Stop (2)`. It looks tidy until a device loses power, and then a month-long session has no measurement at all. - Reading the `Accounting-Response (Code 5)` as approval. It says the record arrived; it says nothing about whether it was stored or billed. - Setting the interim period very short. Ten thousand subscriber links each reporting every minute is ten thousand records a minute the server must absorb, and the extra billing precision is rarely worth it. - Expecting three records every time. A crash produces a `Start (1)` and nothing else, and the accounting design has to survive that rather than assume it away.

  • What does Acct-Interim-Interval (85) ask the access device to do?
    It names the number of seconds the device should leave between `Interim-Update (3)` records for that session. A server can return it so that the reporting rate is a policy decision made centrally, rather than something configured device by device across the estate.
  • Are the octet counters in an Interim-Update cumulative or per-interval?
    Cumulative for the session. Each update restates the totals since the `Start (1)`, so a collector takes the latest value rather than adding consecutive ones. Summing them is the classic over-billing defect, and it grows worse the longer the session runs.
  • What does Acct-Terminate-Cause (49) let an operator distinguish?
    Why a session ended. `User Request (1)` is a subscriber disconnecting; `Lost Carrier (2)` and `Lost Service (3)` point at the line or the network; `Idle Timeout (4)` and `Session Timeout (5)` are limits the access device enforced. Volume alone cannot tell those apart.

saying these in an interview costs you the question

  • Thinks the Access-Accept already records the session's traffic
  • Says accounting sends one record, at the end
  • Believes Interim-Update counters reset each interval
  • Treats the Accounting-Response as an authorization decision
  • Assumes a Stop record always arrives eventually
open as a page

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

level: middleimportance: must knowfreq 52%

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.

open as a page

Why does reading Acct-Input-Octets (42) alone under-report a long-lived subscriber link, and what completes the count?

level: middleimportance: should knowfreq 42%

basics

~20 s

Acct-Input-Octets (42) is a 32-bit counter, so it wraps every 4,294,967,296 octets — 4 GiB. Acct-Input-Gigawords (52) counts how many times it has wrapped, and the true total is gigawords times 2^32, plus the octets.

open as a page

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%

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.

open as a page

What does Acct-Delay-Time (41) on a retried RADIUS Accounting-Request correct for, and what must change alongside it?

level: seniorimportance: nice to knowfreq 26%

basics

~20 s

Acct-Delay-Time (41) reports how many seconds the access device has been trying to deliver this record, so the server can subtract it from arrival time to recover the approximate event time. Updating it changes the packet's content, so the Identifier must change too.

open as a page