Lunar - Overview
Lunar is a high-performance, multi-service network daemon. A single Lunar instance hosts one or more independent services, each a distinct network function behind a single control API. It is written in C++ to deliver low, predictable latency and high throughput on commodity Linux (Ubuntu).
Lunar deliberately holds no business logic of its own. Every service speaks the network protocol it owns (RADIUS, and in future BGP, DNS, SNMP, and others) and delegates every decision to a backend API over HTTP using JSON. Lunar is the fast, protocol-correct edge (the backend is the brain). This split keeps the hot packet path free of policy, database, and provisioning work, allowing the backend to evolve and scale independently of the wire.
What Lunar is today
Lunar currently ships one service, fully implemented and production-ready:
Subscriber (RADIUS) is a complete RADIUS AAA server: authentication, accounting and dynamic authorization (RFC 5176 CoA / Disconnect), with per-virtual RADIUS servers, standard and vendor attribute dictionaries, and optional Kafka event streaming. It answers the RADIUS wire and forwards every decision to the backend API as JSON. See the RADIUS Integration guide.
The core also provides a service-agnostic control API (health/vitals, licensing and per-service management) shared by every service. See the Core API.
Why use Lunar for RADIUS
Traditional RADIUS servers make you express your AAA logic inside the server, in config files, modules or plugins tied to that server's model. Lunar takes the opposite approach. It handles the hard, protocol-correct RADIUS work, and lets you own every decision in your own backend, in whatever language and data store you already use. Reasons operators pick Lunar today:
Your logic, your stack. Authentication, authorization and accounting decisions live in your backend API over plain JSON. No RADIUS-specific scripting language or module system to learn. If you can serve an HTTP/JSON request, you can drive lunar.
Very high throughput, low latency. 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.
Scales by scaling your backend. Because decisions are API calls, put a load balancer in front of your backend and scale AAA capacity there, without touching lunar.
Highly tuned. Fast even over HTTPS, with TLS session reuse, connection keep-alive and HTTP/2 support keeping backend calls cheap.
Push CoA / Disconnect with one API call. Changing or terminating a live session is a single JSON API call to lunar. No vendor CLI scripts, no per-request executables running on your servers. Lunar builds the RFC 5176 Change-of-Authorization or Disconnect packet and signs it (Message-Authenticator). It then sends it to the right NAS, retries, verifies the reply, and returns the decoded ACK / NAK with the full result in the same response. One call in, the outcome and all its details back, across any vendor's NAS through one uniform interface.
Standards-correct and current. Authentication, accounting and dynamic authorization (RFC 5176 CoA / Disconnect), standard and vendor dictionaries, and modern security practice (e.g. Message-Authenticator signing post BlastRADIUS / CVE-2024-3596).
Multi-tenant by design. One instance hosts many virtual RADIUS servers, each with its own listen address, ports and clients, ideal for per-customer or per-region separation.
Config changes without disruption. Virtuals and clients update in place with no restart and no impact on in-flight packets.
Built-in observability. Centralized remote logging of the events that matter, plus optional Kafka streaming of authentication and accounting for billing, analytics and audit.
In short: use Lunar when you want a fast, correct RADIUS front end but want the actual AAA policy to stay in your own system.
Where lunar is going
The same model, a protocol-correct edge service powered by a JSON backend API. Designed to carry many more network functions. Planned services include:
BGP server: API to explore and inspect BGP routes.
DNS server: authoritative / resolver DNS driven by the backend.
SNMP polling: scheduled polling of network devices.
SNMP trap server: receiving and forwarding SNMP traps.
NETCONF gateway: device configuration over NETCONF.
Ping / latency monitoring: reachability and latency probing.
VPN termination: to connect remote sites to services on lunar (L2TP/WireGuard etc).
...and more.
Every service will follow the same pattern: Lunar handles the protocol on the wire, and integrates with the backend API using JSON, so one backend integration style covers all of them.
Transport of the API payloads
Today, the backend integration is JSON over HTTP (HTTPS/TLS in production). JSON is the simplest way to get started and is widely supported, so it is the recommended encoding.
The data model itself is encoding-independent: the same payloads can be carried over more compact binary encodings for higher throughput without changing their meaning or the API semantics. A MessagePack encoding already exists as an experimental option, and we will continue to add and support further encodings as options over time