skip to content

A CoA-Request for a live wireless session comes back as CoA-NAK with Error-Cause 503 — what identification went wrong, and how do you fix it?

level: seniorimportance: must knowfreq 44%

answer

  1. a partial match is no match
  2. every attribute you send is a constraint
  3. addresses and names are reassigned over time
  4. identify by what the device itself minted
  5. Acct-Session-Id from that session's accounting Start

basics

~20 s

503 Session Context Not Found means the access device holds no session matching every identification attribute sent. Fix it by keying on Acct-Session-Id (44) captured from that session's own accounting Start, sending it to the device that owns the session, and dropping attributes that may disagree.

solid answer

~50 s

`Error-Cause (101)` value 503, Session Context Not Found, is the receiving access device saying it looked and found nothing. The rule behind it is strict: **every identification attribute present in the request must match the same session**, so a request naming `User-Name (1)`, `Framed-IP-Address (8)` and `Calling-Station-Id (31)` fails entirely if just one of them is stale or formatted differently from what the device stored. There is no best-match. The usual causes are an address that was reassigned since it was captured, a station identifier whose text form differs from the device's, or a request delivered to the wrong access device — which normally shows as `403` first. The fix is to identify the session by `Acct-Session-Id (44)`, the value the access device itself minted and reported in that session's accounting `Start`, and to send nothing alongside it that could disagree.

code

pseudocode · 12 lines
pseudocode
function find_session(request, session_table):
    candidates = session_table

    for each attribute in request.identification_attributes:
        candidates = keep only sessions where
                     session[attribute.name] == attribute.value

    if count(candidates) == 0:
        return refuse(Error-Cause = 503)   // no best match exists
    if count(candidates) > 1:
        return refuse(Error-Cause = 508)
    return candidates[0]

go deeper

for a junior

Recall that a request to change or end a live session has to say which session, and that the naming can be wrong even when the user is plainly still connected.

for a middle

Explain the conjunctive rule — every identification attribute present must match the same session — and why that makes 503 and 508 opposite symptoms with opposite fixes.

for a senior

Diagnose it in order: right device, then reduce to the identifier the device itself minted, then check freshness, then accept that the session may genuinely have ended. Say which of your platform's stored fields rot and why.

for a principal

Decide what your platform stores per session and how it reconciles: carrying the device-assigned identifier end to end costs a pipeline change, while matching on observed addresses is cheap now and fails silently at scale later.

## What 503 is actually reporting `Error-Cause (101)` value **503 Session Context Not Found** means the access device searched its own session table with the attributes you supplied and matched nothing. It is not a statement about the user, who may well still be online; it is a statement about the *lookup*. In the launderette's prepaid wireless, a customer whose allowance has run out is still happily attached while the billing platform's `CoA-Request (43)` is being NAKed — because the platform and the gateway disagree about how that session is named. ## The matching rule: all, not best RFC 5176 identifies a session by attributes carried in the request, and the rule is conjunctive. **Every identification attribute present must match the same session**, or the request is refused. The attributes available are: - `Acct-Session-Id (44)` and `Acct-Multi-Session-Id` — assigned by the access device itself; - `User-Name (1)`; - `Framed-IP-Address (8)`; - `Called-Station-Id (30)` and `Calling-Station-Id (31)`; - `NAS-Port (5)` and `NAS-Port-Id`. Two failure shapes follow directly from that rule, and they pull in opposite directions: | Symptom | Code | What it means | |---|---|---| | Nothing matched every attribute | 503 Session Context Not Found | over-specified, stale, or wrong device | | Several sessions matched | 508 Multiple Session Selection Unsupported | under-specified; the device will not guess | Adding attributes therefore does not make a match more likely — it makes the request **stricter**, and each extra attribute is another chance for one value to have drifted. ## Why the obvious identifiers rot - **`Framed-IP-Address (8)`** is reassigned. An address captured when the session came up may now belong to someone else, and any address translation between the policy plane and the access device means the value you observed is not the value the device stored. - **`User-Name (1)`** is not unique. One customer with a phone and a laptop holds two sessions, so a name alone invites `508` rather than a clean match. Where a login was routed on a realm, the name the device recorded may also carry a suffix the policy platform stripped. - **`Calling-Station-Id (31)`** carries a station's hardware address as *text*, and its punctuation and letter case are not canonical across equipment. A value copied from an inventory system can be byte-different from the one the device holds, and a string comparison fails on it. - **`NAS-Port (5)`** changes as a device re-enumerates; it describes where the session attaches, not which session it is. ## The identifier that does not rot `Acct-Session-Id (44)` is minted by the **access device** for that one session and reported in the accounting `Start` it sends. Because the device generated it and keys its own table on it, it selects exactly one session and needs no normalisation. The operational discipline is to capture it from the accounting record for the session you intend to act on, store it beside the session state your platform keeps, and use it alone. `Acct-Multi-Session-Id` serves the same purpose where several links belong to one logical session. ## Diagnosing a 503 in order 1. **Check you reached the right box.** The session exists on exactly one access device. A request to the wrong one cannot succeed, and if the request also carried `NAS-IP-Address (4)` or `NAS-Identifier (32)` you would normally get `403 NAS Identification Mismatch` first — its absence with a 503 hints at a device whose recorded identity has drifted. 2. **Reduce the identification set.** Re-send with `Acct-Session-Id (44)` only. If that succeeds, one of the attributes you dropped was stale, and you have found the field that rots in your pipeline. 3. **Check the freshness of the record.** Compare the identifier against the latest accounting record for the session, not the first one you ever saw. 4. **Consider that it really has ended.** If the session closed between your decision and your packet, a 503 is the correct and final answer, and your platform should reconcile rather than retry. ## What a retry may and may not change An unchanged retransmission reuses the same `Identifier`, Request Authenticator and source port so the device recognises a duplicate. The moment you alter the identification attributes it is a **new** request and needs new ones. And because a session lives on one device, sending the corrected request to a second policy target is meaningless — there is no peer holding a copy of the session state to answer for it. ## The related refusal that is not 503 `504 Session Context Not Removable` is the opposite diagnosis: the device **found** the session and will not tear it down. Reading 504 as a naming problem sends you back through identification attributes that were already correct, when the answer lies in what the device permits.

  • The same request is refused with Error-Cause 508 instead. What changed?
    508 Multiple Session Selection Unsupported means the identification attributes matched more than one session and the device will not choose between them — typically a bare `User-Name (1)` for a customer holding two concurrent sessions. The fix is the opposite of a 503's: be more specific, ideally by naming `Acct-Session-Id (44)` for the one session you mean.
  • Why is a Framed-IP-Address captured an hour ago a poor key?
    Addresses are reassigned as sessions come and go, so the value may now name a different customer's session or none at all. Address translation between the policy plane and the access device compounds it: the address your platform observed is not necessarily the one the device recorded against the session.
  • You fix the attributes and resend. May you reuse the Identifier and Request Authenticator from the refused request?
    No. Duplicate detection on the receiver keys on the `Identifier`, the Request Authenticator and the source port, so reusing them for different content risks the device serving its cached refusal. Any change to the attributes makes it a new request, which needs a new Identifier and a new Request Authenticator.

saying these in an interview costs you the question

  • Identifies a session by User-Name alone and expects exactly one match.
  • Assumes the device picks the best-matching session when attributes disagree.
  • Thinks adding more identification attributes makes a match more likely.
  • Trusts an IP address captured hours ago to still name the session.
  • Sends the request to the policy server rather than the device holding the session.
  • Reads 503 as proof the customer is already offline.