case studies
Modernizing Broadband Subscriber Management with a Software BNG and Splynx
Separating a Regional ISP's Subscriber Edge from Its Routing with NetElastic vBNG and Splynx
Customer Story
A growing regional ISP was running its entire subscriber edge and its Internet routing on one converged platform. It had worked for years. As subscriber numbers climbed, it stopped scaling. ITcare’s Professional Network Services team was brought in to separate the two and rebuild the subscriber edge on a software BNG that grows with the network instead of capping it.
This is a deep look at the architecture: why a converged edge runs out of room, why we moved to a software Broadband Network Gateway (BNG), how we replaced subscriber passwords with the physical access circuit, and how the whole migration happened underneath a live network.
Design / Engineering
Published: Jul 13, 2026
Client: Confidential
Industry: Internet Service Provider
Services: Professional Network Services, Network Automation
The Starting Point: One Platform Doing Everything
Before the project, the ISP operated a single integrated router platform from one vendor that simultaneously handled:
- PPPoE subscriber termination
- Carrier-Grade NAT (CGNAT)
- Internet edge routing
- BGP peering with upstreams and peers
- Subscriber policy enforcement and accounting
This converged model is common with smaller and mid-sized operators because it is cheap to start and simple to reason about on day one. One box, one configuration, one thing to manage. It had genuinely served the business well for years.
Why a Single Converged Edge Stops Scaling
The problem is not capacity on day one. It is that every function on a converged box draws from the same finite pool of resources.
Each PPPoE session, each NAT translation, each routing update and every forwarded packet competes for the same control-plane CPU and the same data-plane forwarding capacity. As subscriber counts and traffic grew, three things happened at once. Capacity planning became guesswork, because subscriber load and routing load were entangled on one platform. Internet routing stability was now coupled to subscriber churn. And the only upgrade path the platform offered was a larger chassis, a forklift replacement, with the same architectural ceiling waiting at the next tier.
On a fixed hardware platform, subscriber scale, NAT scale and forwarding throughput are all welded to one product SKU. Hit any single limit and you replace the entire unit.
The Redesign: Separating Subscriber Management from Routing
Rather than buy a bigger box, we decoupled the two roles that should never have shared a platform.
A Software BNG on Commodity x86
We moved PPPoE and IPoE termination, subscriber policy enforcement and CGNAT onto NetElastic vBNG, a software Broadband Network Gateway running on standard x86 servers rather than purpose-built silicon.
A software BNG matters here for one reason: scale economics. On an appliance, control-plane capacity, subscriber scale and forwarding throughput are bound together. A software BNG decouples them. Forwarding throughput is a function of CPU cores, NIC count and a high-performance userspace data path, so capacity grows by adding compute, adding instances behind the access network, and distributing subscribers across them. The operator scales in increments that can be budgeted, and can place subscriber-processing capacity where the subscribers actually are instead of backhauling everyone to a single chassis. The control plane and the data plane scale on independent axes.
With subscriber processing offloaded, the edge routers returned to doing one thing well: BGP and forwarding. Internet routing no longer shares fate with subscriber sessions.
Splynx as Centralized AAA
Rethinking Subscriber Authentication
We deployed Splynx as the central platform for Authentication, Authorization and Accounting, plus provisioning and Change of Authorization. Subscriber identity, service profiles and accounting records now live in one system rather than being scattered across edge device configuration. NetElastic enforces policy; Splynx is the source of truth.
The most valuable part of the project was redesigning how subscribers are identified, because this is where most ISPs carry hidden operational cost.
Historically the ISP authenticated PPPoE subscribers with a username and password configured on customer premises equipment. Every router swap, every mistyped credential, every reconfiguration became a support ticket. We removed credentials from the design entirely and made the physical access circuit the identity.
Circuit-ID for PPPoE
For PPPoE, the access node inserts Circuit-ID information (the PPPoE Intermediate Agent tags, conceptually the same as DHCP Option 82) identifying the physical port the subscriber is connected to. NetElastic receives the Circuit-ID and passes it to Splynx in the RADIUS Access-Request. Splynx identifies the subscriber by the circuit and returns the matching service profile. The subscriber is the circuit, not a password.
The operational benefits are immediate: no credentials to configure on customer equipment, faster activation, trivial equipment replacement, and a sharp drop in authentication-related support requests.
DHCP Option 82 for IPoE
The same philosophy extends to IPoE. The access node inserts DHCP Option 82 (Relay Agent Information) into the subscriber’s DHCP request, carrying the Agent Circuit ID and Agent Remote ID sub-options. NetElastic extracts Option 82 and forwards it to Splynx over RADIUS, which maps it to the subscriber and applies the service profile.
The result is one unified identification framework across both access technologies: PPPoE subscribers identified by Circuit-ID, IPoE subscribers identified by DHCP Option 82, all subscriber state centralized in Splynx, and all policy enforced by NetElastic.
Dynamic Policy with RADIUS CoA
Because subscriber state lives in Splynx and is applied through RADIUS, service changes are pushed to live sessions using RADIUS Change of Authorization (CoA). A plan upgrade, a speed change or a policy update takes effect on the active session without forcing the subscriber to reconnect.
The Migration: Changing the Edge Without Downtime
This was a live network that could not stop serving customers, so the migration was staged to minimize risk.
NetElastic vBNG was first deployed in parallel and integrated into the existing environment. It was connected to Splynx and put through extensive validation: subscriber authentication, accounting records, bandwidth policies, service profiles, failover scenarios and CoA behaviour were all verified before any customer was moved. Existing PPPoE subscribers were then migrated in controlled phases. Once PPPoE was fully cut over, IPoE was introduced on the new DHCP Option 82 framework. Service continuity was maintained throughout.
Before and After
Before
- One converged router platform handling PPPoE, CGNAT, BGP and edge routing
- PPPoE username and password authentication on customer equipment
- No standardized IPoE authentication framework
- Subscriber services tightly coupled to routing infrastructure
- Capacity growth meant replacing the whole platform
After
- A software BNG dedicated to subscriber processing and CGNAT on x86
- Splynx providing centralized AAA, provisioning and CoA
- Edge routers dedicated to BGP and forwarding
- PPPoE authentication by Circuit-ID, IPoE by DHCP Option 82
- A unified subscriber-identification framework across both access types
- Independent scaling of the subscriber and routing planes
Results
The migration delivered measurable operational and architectural gains. Subscriber management and routing now scale independently, so capacity planning is no longer guesswork. Capacity grows by adding x86 compute rather than forklifting a chassis. Credential-related support tickets effectively disappeared once passwords were removed from customer equipment. Operations teams gained centralized visibility and control through Splynx. And IPoE became a first-class, fully supported service that the previous architecture could not deliver.
Most importantly, subscriber management was cleanly separated from routing, letting both environments scale on their own terms and reducing the overall complexity of the network.
Frequently Asked Questions
What is a software BNG (vBNG)? A software Broadband Network Gateway terminates and manages broadband subscriber sessions (PPPoE and IPoE), enforces policy and performs functions like CGNAT, running on standard x86 servers rather than fixed-function hardware. Throughput scales with CPU cores, NICs and a high-performance userspace data path, so capacity grows by adding compute instead of replacing a chassis.
Why separate the BNG from edge routing? On a converged platform, subscriber sessions and the Internet routing table compete for the same CPU and forwarding capacity, which makes capacity planning difficult and couples routing stability to subscriber load. Separating them lets each scale independently and keeps Internet routing isolated from subscriber churn.
How does Circuit-ID replace PPPoE usernames and passwords? The access node tags each session with the physical circuit it arrives on. The BNG passes that Circuit-ID to the AAA platform over RADIUS, which identifies the subscriber by their port and returns a service profile. No credentials are stored on customer equipment, which removes a common source of support tickets.
What is DHCP Option 82 used for in IPoE? DHCP Option 82 (Relay Agent Information) carries Agent Circuit ID and Agent Remote ID sub-options inserted by the access node, identifying the subscriber’s physical port. The BNG extracts Option 82 and uses it, via RADIUS, to identify the IPoE subscriber and apply their service profile, the IPoE equivalent of Circuit-ID for PPPoE.
What does RADIUS CoA enable? RADIUS Change of Authorization pushes policy changes to active subscriber sessions in real time, so plan and speed changes take effect without forcing the subscriber to reconnect.
Build a Subscriber Edge That Scales
ITcare‘s Professional Network Services team designs and migrates broadband subscriber architectures: software BNG, Splynx AAA, RADIUS and CoA, Circuit-ID and DHCP Option 82, CGNAT, and the BGP edge underneath. If your BNG is also your edge router and you are starting to feel the ceiling, this is the kind of migration we run, on live networks, without downtime.
be our next success story!
Drop us a line! We care for your Business and are here to answer your questions 24/7