Stop Stale PPPoE Sessions with RADIUS Reconciliation

A frustrating PPPoE incident often begins when a subscriber cannot reconnect because an old session still appears active. Support sees the account online, the access concentrator may disagree, and the customer only hears that the login is already in use.

The safest response is an accounting-led session ledger that is reconciled with the current NAS view before anything is cleared. This gives support, NOC, and billing one evidence-based view of the session.

Use accounting as the session lifecycle record

Authentication answers whether a subscriber may connect now; it does not prove that the previous session ended cleanly. Track the full accounting lifecycle—Start, Interim-Update, and Stop—and key each record by subscriber, NAS, and session identity.

A missing Stop then becomes a mismatch to investigate, not permission to disconnect by username. Compare the ledger with the live PPPoE session table and act only when both sources support the same conclusion.

Keep enough evidence to target the right session

A useful ledger must distinguish a stale session from a subscriber’s new working connection.

Reconcile before disconnecting

Use a controlled mismatch queue instead of one-off console decisions.

1. Check for maintenance, a recent NAS reboot, a RADIUS outage, clock drift, or database delay.
2. Compare the ledger with the live NAS session for the same subscriber, device, and session ID.
3. Require negative evidence: aged interim updates, no live counters or NAS entry, and no newer event that supersedes the old record.
4. Issue a targeted disconnect using the method supported by your environment, and log the identifiers and approval.
5. Verify that the old session disappears and any customer reconnect creates a clean accounting Start.

The main operational risk is not failing to clear a stale record; it is clearing the subscriber’s valid replacement session.

Test the failure cases

Before automating cleanup, test a normal Stop, a NAS reboot without a Stop, delayed interim updates, a fast reconnect after a link flap, and duplicate-login rejection. Support should be able to explain the state from one view, while NOC can target only the affected session.

Validate RouterOS behavior, FreeRADIUS policies, timeout and retry settings, database writes, attribute support, and local retention or privacy requirements against the versions and contracts in your network.

Connect the workflow to ISPbills

ISPbills brings subscriber billing, RADIUS and PPPoE operations, monitoring, support tickets, reporting, and role-based access into the same operational context. Teams can review a mismatch beside the subscriber account and support history, then record who approved the action and whether it worked.

Review the FreeRADIUS with MikroTik: A Production Setup Guide and the RADIUS accounting reconciliation guide when mapping this process to your environment. If iPilot helps summarize evidence or draft a ticket note, keep the disconnect itself under operator approval.

Use a clear decision standard

Automate stale-session cleanup only when you have stable session identifiers, reliable accounting updates, access to live NAS state, and an audit trail for every forced disconnect. If one of those controls is missing, keep the action manual and improve the evidence first.

Research basis: ISPbills product documentation; MikroTik RouterOS documentation; FreeRADIUS documentation. Validate implementation details against the software releases, contracts, configurations, and local regulations governing your network.