An accel-ppp deployment with FreeRADIUS can be a sensible broadband edge. A stack assembled around VyOS, subscriber termination and external policy services can also fit an operator's requirements. The appeal is familiar systems with a low entry cost and control over configuration. You can make the edge work the way your network needs.
Maintenance gets harder as more subscribers depend on the scripts, packages and operational knowledge that connect those components. Looking for an accel-ppp alternative often means looking for a clearer support boundary. Netavo BNG takes the NAS role while your existing FreeRADIUS and billing platform continue to own subscriber policy.
What the self-built stack gets right
Open-source components let you inspect behaviour, automate changes and choose when to upgrade. FreeRADIUS can express the relationship between your subscriber database and access policy without forcing billing into the router. Linux tooling gives an experienced team useful ways to inspect packets, routes and process state.
The initial economics are attractive, especially where spare server capacity and Linux expertise already exist. A small deployment can use straightforward configurations and a recovery process the whole team understands. Avoid treating that as an immature design because it has no appliance badge.
Flexibility is also valuable when access arrangements are unusual. You can adapt naming conventions, authentication policy and provisioning without waiting for a vendor feature. The cost is that your team becomes responsible for preserving those adaptations through every change to the surrounding system.
Where the maintenance cost appears
The boundary between components is usually where work accumulates. Subscriber creation has to agree with route installation, rate enforcement, NAT allocation and accounting. Teardown has to reverse those operations even if one component is unavailable. A script that works during a normal disconnect may behave differently after a crash.
Over time, small adaptations become a system: generated configuration, service ordering, watchdogs, policy dictionaries, database queries and reconciliation jobs. Each may be reasonable individually. Together they need ownership, tests and a recovery procedure that works when the original author is unavailable.
HA and session resilience
Keeping an address reachable is different from preserving subscriber state. A redundant gateway or routing failover can restore a packet path while PPP state, DHCP leases or NAT mappings still belong to the failed host. The result depends on which parts of the stack synchronize state and how clients retry.
Write down the recovery contract for each access protocol. Does the CPE reconnect? Can billing correlate the old session's end with the new session's start? What prevents an old route from attracting traffic after a subscriber moves? These questions matter more than a generic HA label.
Apply the same scrutiny to a replacement product. Netavo's separation of control and data planes does not imply that every session survives every restart. Its documented L2TP control-plane restart recovery ends those sessions and prompts redial. Measure your actual access path and include its interruption in the maintenance plan.
CGNAT and attribution
Adding NAT rules is only the beginning of operating CGNAT. You need sufficient ports, predictable behaviour under exhaustion, correct return routing and records that connect a public address and port at a particular time to a subscriber.
Per-flow logging can make the collector and retention pipeline a substantial part of the system. Netavo integrates NAT44 with deterministic port-block allocation, allowing subscriber-to-block bindings to provide attribution without requiring a log entry for every connection. You still operate the collector and preserve allocation history; integration does not remove that responsibility.
Support and upgrades
In a self-built stack, a fault spanning the termination daemon, kernel, routing software and your automation arrives at your team first. Upstream projects may help with individual components, but somebody still has to produce a reproducible case and decide which boundary failed.
A supported BNG puts more of that integration under one product boundary. It does not eliminate qualification. Test upgrades against your CPEs, RADIUS policy, routing and failure scenarios, and retain a rollback path. Package installation succeeding says little about whether the next renewal or disconnect behaves correctly.
Keep FreeRADIUS and billing
Netavo is the network access server. It can authenticate using RADIUS PAP, CHAP or MS-CHAPv2, send Accounting-Start, Interim and Stop records, and receive RFC 5176 CoA and Disconnect requests. Your billing system can continue to decide who is entitled to service and which plan applies.
That separation limits the migration scope. Register a new NAS, translate any NAS-specific attributes, and validate the records your existing systems receive. There is no requirement to move subscriber credentials into a new billing platform merely because termination changes.
| Existing responsibility | Migration treatment | What to verify |
|---|---|---|
| FreeRADIUS authentication | Retain server and policy | Request identity and supported reply attributes |
| Billing and plan assignment | Retain business logic | Rate units, direction and suspended-state policy |
| Subscriber termination | Move to Netavo | Access protocol, VLANs, MTU and CPE behaviour |
| Accounting collection | Retain destination | NAS identity, session identifiers and final counters |
| Live service changes | Point at the active NAS | CoA authentication and session selection |
| Routing integration | Map to FRR-backed configuration | Route ownership, withdrawal and return traffic |
Do not assume a shared attribute name implies identical semantics. Capture a known subscriber's authentication exchange, then compare the effective rate and routing policy on both edges. Test an upload and a download independently. Include rejected authentication and a suspended account in the comparison.
Migrate a service slice
Build the new edge alongside the existing stack. Use separate allocation ranges or another explicit ownership arrangement so both NASes cannot issue the same address. Give the new NAS a distinguishable identity in monitoring and accounting before any customer moves.
Select a pilot containing the protocols and CPEs you actually support. Confirm that the billing system can locate the live session and send a plan change to the correct NAS. A dashboard that still points to the old server can make a successful access migration look like broken provisioning.
During the pilot, test teardown as carefully as setup. Check that routes disappear, address allocations are released appropriately and accounting closes. Repeat after a controlled failure. Monitor NAT capacity and logging delivery while traffic is present, rather than only inspecting configuration.
Move subsequent groups when the pilot meets explicit acceptance criteria. Keep the previous edge and its configuration available for rollback until renewals, busy-hour load and an upgrade rehearsal have all been observed. Avoid changing access technology and billing policy in the same cutover unless that is unavoidable.
When you have outgrown DIY
A self-built stack earns its keep at small scale, with a team that knows every layer. The signs that you have outgrown it are concrete: growth that means another box and another RADIUS client each time, CGNAT that strains the connection-tracking table and cannot produce a clean subscriber-to-port log, upgrades that are a held breath rather than a routine, and recovery that rests on one or two people. At that point the integration you maintain costs more than a supported platform, and because Netavo is just the NAS, you keep the FreeRADIUS and billing you already run.
Migration becomes worth considering when integration maintenance starts consuming the time needed to develop and run the network. Frequent upgrade deferrals, one-person knowledge, untested recovery and difficult attribution searches are stronger signals than any universal subscriber-count threshold.
A supported product changes who maintains the integrated BNG software. Your team still owns capacity planning, access design, billing policy and proof that recovery meets your service requirements.
Run your existing RADIUS policy against the free evaluation, the production build licensed for up to 50 concurrent subscribers. Use the manual to check the configuration and attribute mappings before moving a pilot.