Replacing an ASR9000 BNG, Nokia 7750 or Juniper MX starts with a service inventory. The chassis may terminate broadband, carry business VPNs, provide aggregation and absorb traffic bursts at the same time. Those functions need separate acceptance criteria, even when they currently share a purchase order.
Netavo BNG runs on standard x86 hardware with Debian. It terminates subscribers, applies authentication and policy, integrates NAT44, and uses FRR for routing. A software BNG migration is practical when those functions match the service you deliver and the chosen server meets the workload. Compare the tested subscriber edge with your existing edge, including failure conditions.
Why operators consider the move
A chassis purchase bundles forwarding capacity, physical slots, redundancy and software entitlements. That can be sensible at a large aggregation site. At a smaller edge, the next expansion may require a line card or chassis long before the subscriber workload justifies it. Standard servers give the operator another unit of capacity to buy, stock and replace.
Compare the complete cost over the intended service life. Include redundant servers, suitable NICs, optics, switching, support, spare parts and engineering time. Rack space and power belong in that calculation, but neither is automatically lower because the replacement is a server. Measure power under the intended workload and count the equipment needed to replace every function of the chassis.
Lead times matter operationally. A server design that can be reproduced from stocked components changes how you recover from a failed box or open another site. Hardware qualification still matters: a substitute NIC or different CPU topology needs validation before becoming an emergency spare.
Licensing also changes the capacity discussion. Per-subscriber licensing makes concurrent subscriber demand part of the budget, alongside throughput and packet rate. Check which limit you will reach first and what happens during a failure when surviving equipment takes additional sessions. A licence sized for normal occupancy can be insufficient for the recovery plan.
Build a feature-parity checklist
Start with the services actually enabled in production. A feature name alone is insufficient evidence: two implementations can both support PPPoE while differing in the policy and operational details your provisioning depends on.
| Area | Netavo mapping | Acceptance check |
|---|---|---|
| PPPoE and IPoE | Subscriber termination on access interfaces | VLAN identity, DHCP behaviour, MTU and CPE reconnects |
| RADIUS | PAP, CHAP, MS-CHAPv2 and accounting | Attributes, NAS identity, retries and billing correlation |
| Live policy | RFC 5176 CoA and Disconnect | Rate changes, suspension and targeted logout |
| CGNAT | Integrated NAT44 with deterministic port blocks | Port demand, return routing and attribution records |
| MPLS L3VPN | FRR routing and configured VRFs | Route targets, VPN routes and isolation |
| QoS | Per-subscriber rate policy | Rate direction, congestion behaviour and service guarantees |
| Redundancy | Recovery depends on protocol and deployment | Session loss, route convergence and accounting consistency |
For RADIUS, capture representative request and reply attributes from the existing NAS. Keep the policy intent and check how Netavo interprets it. Test rejected credentials and unavailable authentication servers as well as successful logins. Accounting Start, Interim and Stop records must remain useful to billing after the NAS changes.
For MPLS L3VPN, validate route import and export independently of subscriber authentication. A successful login in the wrong routing context is a failed migration. Include IPv6 routes, return traffic and a negative test proving that one service cannot reach another service's private routes.
QoS deserves its own decision. Netavo's per-subscriber rate enforcement uses policing; it does not reproduce every hierarchical scheduler tree on a chassis. If you sell guarantees that depend on nested queues across subscriber, access circuit and uplink, establish the equivalent service behaviour before scheduling a cutover.
Size the server against the workload
Subscriber count, bandwidth and packet rate describe different constraints. So do session establishment rate and NAT state. A test consisting only of established sessions carrying large packets leaves several important failure modes untested.
Use the packet sizes, encapsulation and service mix you expect. Include dual-stack traffic, NAT where required, accounting and route updates. Then test a reconnection burst while traffic is already flowing. Reserve capacity for growth and failure recovery rather than treating a clean benchmark result as the operating target.
Record the CPU, NIC, queue layout and software versions with the results. A throughput number detached from those details cannot qualify a different server. Keep management access available independently of the subscriber forwarding path so a network incident does not remove the tools needed to diagnose it.
Run both edges during migration
Establish a parallel edge
Bring up the Netavo edge alongside the chassis. Establish routing and monitoring, register it as a NAS, and give it address space that cannot collide with allocations on the existing equipment. Confirm that the access network can direct the intended circuits to the new edge without exposing them to competing termination services.
Define rollback before moving subscribers. It should specify how access returns to the original NAS, which routes are withdrawn and how stale sessions are cleared. Returning a cable or VLAN is only part of returning service.
Move a representative pilot
Choose a pilot that includes the awkward cases: different CPE models, IPv6, business VRFs and subscribers using NAT. Observe authentication, negotiated MTU, actual rate limits, accounting and the support team's ability to find a session.
Schedule failure tests within the pilot window. Loss of an uplink, a process restart and a host failure are different events. Do not infer subscriber continuity from a successful routing failover. In particular, Netavo's documented L2TP recovery after a control-plane restart clears those sessions so they can redial; plan and measure that interruption.
Shift the remaining groups
Move bounded groups with clear success and rollback criteria. Watch reconnect rates, authentication failures, address-pool occupancy, packet drops and accounting gaps. Leave enough time between groups to see recurring problems, including DHCP renewals and busy-hour congestion.
Keep the old edge available until the operational evidence supports retiring it. Update provisioning targets and support procedures as part of each move so subsequent plan changes reach the NAS that actually owns the session.
Where a chassis still earns its space
There is a narrow case where a chassis still wins. Raw port density is the main one: a site aggregating many physical hand-offs may need fewer devices, optics and interconnects with line cards than with servers plus switching, so count those alongside the rack units. Deep-buffer line cards can also matter on oversubscribed links that take large bursts, where purpose-built buffering and scheduling do something server memory does not. For most subscriber-termination workloads neither is the deciding factor, but where they are, size them honestly before you commit.
If a required service depends on chassis-specific forwarding or a scheduler model you cannot reproduce, retain that function on suitable hardware and migrate only the services you have validated.
A chassis BNG replacement can be selective. Moving broadband termination while retaining aggregation or specialist services is a valid outcome when it gives the network a simpler operational boundary.
Use the free evaluation, the full production build licensed for up to 50 concurrent subscribers, to qualify a pilot. The manual covers configuration and deployment details.