RADIUS / AAA Platform Solution
Industry defined AAA stands for Authentication, Authorization and Accounting. It is the framework that allows your network devices to authenticate subscribers, authorize their access, and account for their usage.
Interstellio offers a complete RADIUS / AAA solution in two parts: the RADIUS software that speaks the protocol on the wire, and a managed backend that makes every decision. Take the software alone and pair it with your own backend, or take both and run a full AAA platform without building anything yourself.
How a typical AAA solution is built
A typical AAA solution has two halves. On one side is a RADIUS server that communicates with your network devices (the NAS / BNG / BRAS): it speaks the RADIUS protocol on the wire, receives authentication, accounting and change-of-authorization requests, and encodes the replies. On the other side is a backend that decides what to do with each request: it stores subscribers and their sessions, tracks data usage, holds your policies, and determines which reply attributes to return for each type of NAS, among much more.
A RADIUS server on its own is therefore only half the picture. Even with a capable RADIUS server, you must still build that backend. It has to manage subscribers and their sessions, record usage, define policy, and decide which attributes to return for which vendor's NAS, and it has to stay fast and scalable as you grow.
Interstellio provides both halves, separately:
Lunar is the RADIUS software, the network-protocol half. Like any RADIUS server it handles the wire, while you supply the backend. Choose Lunar if you want to run your own backend.
NebularStack is the backend, delivered as a fully managed service, so you do not build it at all. Choose NebularStack if you want the complete package. It is a fully managed, SaaS AAA backend, with all the supporting infrastructure, purpose-built for internet service providers and for scale.
The split is deliberate. The RADIUS edge (Lunar) is the fast, protocol-correct front line, while the backend is the brain that owns your subscribers, policy and billing. The two communicate over plain HTTP/JSON.
New to AAA?
It is important to understand that the backend manages your subscribers, but it is not a billing platform or a CRM. You keep your own CRM, billing and other systems, and the backend integrates with them. RADIUS and the AAA backend form only one part of the wider OSS/BSS ecosystem.
There are all-in-one systems you can purchase that run on a single server and combine the RADIUS server, AAA backend, CRM, billing, order management and more. These are convenient, but they are not role-based and are not designed for scale: they do not offer separation of concerns or best-in-class, carrier-grade functionality for every use case. This is why large operators instead assemble their infrastructure from dedicated OSS/BSS components.
Lunar: the network software
Lunar is our high-performance, multi-service network daemon that you license and run on your own servers and infrastructure. A single Lunar instance hosts one or more independent services, each a distinct network function behind a single control API, and it is designed to host additional services over time.
For AAA, Lunar is the RADIUS software: you simply bring your own backend (BYOB). Lunar handles the RADIUS protocol on the wire, giving you a fast, correct network edge, while your backend makes the decisions. Lunar is licensed software you purchase from Interstellio and deploy on your own infrastructure. Contact support@interstellio.io for licensing and a trial.
To get started with Lunar:
RADIUS Integration, the backend API you build.
NebularStack: the managed backend
If you would rather not build and operate the backend yourself, NebularStack is our cloud (SaaS) platform that provides it for you. Its Subscriber Management service implements every route and outbound call Lunar expects, so it plugs straight into Lunar as the backend.
With NebularStack as your backend you manage subscribers, RADIUS virtuals, clients and policy in NebularStack, and it answers Lunar's authentication, accounting and CoA calls. Its Subscriber Management backend takes care of subscriber sessions, expiry, quotas and policies, and exposes a full REST/JSON API that you can integrate into from your own provisioning systems. There is no backend code to write: point Lunar's subscriber endpoint at NebularStack and you have a full AAA platform.
Run NebularStack when you want the whole solution managed, with the RADIUS edge driven by a ready-made, hosted backend.
When to use NebularStack Subscriber Management:
You are starting out and want something that enables a quick time to market.
You plan to scale, and want a backend built for it.
You want complete control over the user experience from your own custom web portal that simply makes an API call to provision a subscriber, rather than being locked into how a prebuilt system works.
You plan to use best-in-class ticketing systems, order management systems and more, keeping each system separate and under your control.
You would rather outsource this infrastructure than build it yourself.
Because NebularStack Subscriber Management is simply a backend for Lunar, you are never locked in. The backend and the RADIUS edge stay independent. At a later stage you can build your own platform and point Lunar at it instead, as and when your business and operational requirements demand.
If you are new to the platform please follow:
Documentation Guidelines describe how to use this documentation.
NebularStack Overview introduces the platform.
User Guidelines short introduction to NebularStack basics.
API Guidelines are basic guidelines for consuming API(s).
Identity (IAM) covers domains, tenants and users.
Otherwise jump straight into it here:
Subscriber Management Overview introduces the subscriber service.
A known problem we solve
Most RADIUS AAA infrastructure looks healthy right up until the moment it matters most, and then it collapses. The cause is almost always the same: the thundering herd.
Under normal load, authentications trickle in and everything is fine. The weakness stays hidden. Then something disturbs the network (a BNG or BRAS reboots, an uplink flaps, a power event blips, or a maintenance window ends) and tens of thousands of subscribers try to reconnect in the same few seconds. That simultaneous reconnect is the herd.
Here is what goes wrong, and why it cascades. RADIUS runs over UDP, so when a NAS does not get a timely Access-Accept it retransmits the request. If your AAA path can only authenticate a few subscribers at a time (because the RADIUS server processes requests with little concurrency, or your user-store queries run through a small connection pool) the backlog builds instantly. Latency climbs past the NAS timeout, replies arrive too late or not at all, and every timed-out NAS resends. Now the offered load is multiplying at the very moment the system is already saturated. The queue never drains and good requests starve behind retransmissions. The whole platform grinds to a halt, and it often stays down long after the original event has passed, because the retransmission storm sustains the overload all by itself.
The root cause is concurrency, not raw speed. Throughput under a herd is bounded by how many authentications you can keep in flight at once, not by how fast any single query runs. If each credential lookup takes 20 ms but you can only run a handful in parallel, you are capped at a trickle. If you can run thousands in parallel, you serve thousands of times more requests per second from the very same database cluster. The bottleneck is nearly always the backend (the credential store) and the fix is to widen it: more replicas, shards or partitions, with many queries issued concurrently.
This is exactly where Lunar helps. Lunar keeps thousands of backend requests in flight in parallel, with no locking on the hot path, so it drives your backend at whatever concurrency your backend can absorb. Lunar itself is never the ceiling. It also de-duplicates in-flight retransmissions, so a NAS resend storm does not multiply into extra backend calls: Lunar dampens the herd instead of amplifying it. And because your backend is just a plain HTTP/JSON API that you build, you are free to scale it however suits your data. You can add backend servers behind a load balancer, shard or partition the user store with consistent hashing or any scheme you choose, and cache the hot path. There is no RADIUS-specific module system or scripting in the way.
The result: when the herd hits, you have headroom. High concurrency end to end means requests are answered inside the NAS timeout, retransmissions never pile up, and the system stays stable and recovers fast. That turns the classic AAA failure mode into a non-event.