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

## 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.