Lunar - Subscriber (RADIUS)

The subscriber service is lunar's RADIUS server. It answers the RADIUS wire for you and turns every request into a simple HTTP/JSON call to your backend, which makes the actual decision. This page is a quick, high-level picture of how it fits together. The exact routes, payloads and rules are in the RADIUS Integration guide.

The idea

Lunar speaks RADIUS to the network. Your backend speaks JSON to lunar. Lunar does the protocol. The backend does the policy.

Key advantages

Extremely fast. Native C++ with no locking on the hot path, keeping thousands of backend requests in flight in parallel, so a single server comfortably handles hundreds of thousands (100k+) of RADIUS requests per second. See Performance.
Fully API-driven. Every configuration and every decision is a plain HTTP/JSON call, which makes building your own backend simple. No RADIUS-specific scripting or module system to learn.
Dynamic authorization by API, not by scripts. Sending a Disconnect or a Change-of-Authorization is a single API call to lunar. No more shelling out to vendor binaries like radclient to craft and fire packets. It is easier to build, safer, and scales far better than spawning a process per request.
Scales with your infrastructure. Because lunar talks to the backend over HTTPS, you scale capacity by scaling the backend (behind a load balancer), not by touching lunar.
Simple configuration that just works. No maze of tuning knobs or arcane config to get right. Sensible defaults and a small, clear configuration mean it runs correctly out of the box.
Fully supported. Lunar comes with full commercial support.

Looking ahead, we are working on making dynamic authorization scale even further in a future version. An async API will let you fire CoA / Disconnect requests without waiting inline, and the results are delivered back through callbacks. That way a burst of thousands of dynamic-authorization requests never blocks on per-request round trips.

Your backend, or ours

Because lunar delegates every decision to a JSON backend API, you have two ways to run it:

Bring your own backend. Implement the lunar backend API yourself against your own systems and data. Lunar runs standalone against it. You own the infrastructure, scaling and telemetry around it. Everything you need to build that is in the RADIUS Integration guide.
Use NebularStack Subscriber Management This is our flagship AAA backend for lunar. It implements the backend API for you and solves the hard operational parts (infrastructure, scalability and telemetry at scale) so you do not have to build and run them yourself. Point lunar at it and you have a complete, production-grade AAA platform.

Either way lunar is the same fast RADIUS edge. The choice is only whether you build the backend and its infrastructure, or let Subscriber Management provide it.

How a request flows

A NAS (BNG / BRAS / Wi-Fi controller) sends a RADIUS packet to a lunar virtual server.
Lunar validates it, decodes the binary packet into readable JSON, and POSTs it to your backend.
Your backend decides and returns the answer as JSON.
Lunar encodes that answer back onto the RADIUS wire and replies to the NAS.

Everything hard about RADIUS (wire format, shared-secret crypto, Message-Authenticator, dictionaries, retries, de-duplication) is handled by lunar. Your backend only ever sees clean JSON.

What it does

Lunar's RADIUS service covers all three RADIUS functions, each on its own UDP port of a virtual server:

Authentication (Access-Request): your backend accepts or rejects, and can return reply attributes (session limits, VLAN, rate, ...). PAP / CHAP / MS-CHAP / EAP are supported.
Accounting (Accounting-Request): session Start / Interim / Stop records. Lunar acknowledges the NAS immediately and delivers the record to your backend out of band.
Dynamic authorization (RFC 5176 CoA / Disconnect): change or terminate a live session. Your backend can push these to a NAS through lunar, and inbound CoA from a NAS is forwarded to your backend for a decision.

How it is configured

You never edit files on the lunar host to manage RADIUS. Lunar pulls its whole configuration from your backend:

On startup it fetches all its virtual servers (each a RADIUS server with its own IP, ports and set of NAS clients) from the backend.
A single API call tells lunar to (re)load or stop one virtual. Lunar fetches that virtual's current config and applies it in place, with no restart and no disruption to live traffic.

So the backend is the single source of truth for both the configuration and the per-request decisions.

Beyond answering the NAS

Observability: lunar ships the events that matter (misconfigurations, bad secrets, corrupt packets) to your backend as remote logs, and can optionally stream authentication and accounting to Kafka for billing, analytics and audit (see Kafka).
Performance: native C++ with lock-free hot paths and massively parallel, non-blocking backend calls, capable of well over 100,000 Access-Requests per second on a single server. See Performance (and its benchmarking notes before you load-test).

Where to go next

RADIUS Integration is the complete API: every route, the packet/attribute JSON format, and the exact backend calls to implement.
Kafka covers the optional authentication / accounting Kafka event streams.
Performance explains why lunar is fast, and how to benchmark it without under-measuring it.