Technology
Engineered for the access edge, not adapted to it
Netvyn was built as a subscriber gateway from the first line, rather than as features bolted onto a general-purpose router. That shows up in four places: how much a server can carry, how predictable it is under load, how safely it can be changed, and how much of it your own systems can drive.
Design principles
Four things we optimised for
Subscriber density per server
Session handling and forwarding were designed together, so a single commodity server carries a subscriber count that would otherwise need dedicated hardware. Capacity grows with the cores and memory you give it, with no licensed tier in the way.
Predictable behaviour under load
Forwarding cost stays flat as session counts rise, so busy-hour performance is a function of your traffic rather than of how many subscribers happen to be connected.
Change without disruption
Configuration is staged and applied atomically, and the high-value changes — plans, pools, policy, routes — take effect without dropping subscriber sessions.
Operable by your own systems
Everything available at the command line is available over an API, so subscriber lifecycle stays in the billing and OSS platforms that already own it.
Reliability
What happens when something goes wrong
An access gateway is a single point in the subscriber path. These are the properties that matter when it is 9pm and something has changed.
Self-protecting control path
Management, authentication and API traffic are isolated from subscriber traffic, so an access-side flood cannot starve the gateway’s own control functions.
Reversible changes
A change that cuts off your own access to the gateway can be applied with an automatic revert timer, so the recovery path is doing nothing.
Redundant pairs
An active/standby pair replicates session, translation and accounting state, so a failover does not restart every subscriber from scratch.
Diagnostics built in
Counters distinguish a policy problem from a capacity problem from an upstream problem, and a per-flow trace can follow one subscriber’s traffic through the gateway.
Compliance that cannot silently fail
If a mandated record cannot be written, that condition is counted and alarmed rather than dropped quietly.
Auditable operations
Every configuration change carries the operator, the source address and the channel it arrived on.
Integration
Fits the systems you already run
- Authentication — your existing RADIUS remains the source of truth for subscriber identity and plans.
- Billing — usage records in the accounting format your platform already ingests, at your chosen interval.
- Provisioning — an API for subscribers, plans, pools, policy and live session actions.
- Monitoring — metrics exposed for the stack you already scrape, plus a streaming northbound interface.
- Compliance — session and translation records to durable files and a remote collector.
This page is deliberately about outcomes. If you want the engineering — the forwarding model, the state and concurrency design, the validation methodology — it is written up in the technical documentation rather than summarised in marketing copy.
Want the engineering detail?
The documentation is public and unregistered. Read it, then bring your questions to a technical session.