Put every RADIUS subscriber on their ONU
Link Radius Server reads your OneRADIUS or Xonware XIMS server and matches each PPPoE subscriber’s router to the ONU it is plugged into, so an ONU page shows whose service it is, on which plan, and whether their session is up.
How the link is made
Your RADIUS server and your OLT each know half of the answer, and they share one fact: the MAC address of the subscriber’s router.
- The RADIUS server knows the subscriber
Username, plan, expiry and session, and, as the Calling-Station-Id of every PPPoE login, the MAC of the router that logged in.
- The OLT knows the ONU
The same MAC sits in the OLT’s forwarding table behind the ONU the router is plugged into.
- RadixOLT joins the two
It reads the MACs learned behind every ONU, fills the customer roster from the server, and links each customer to the ONU their router was seen behind.
The two servers it reads
They find customers in opposite ways, so each has its own client and the rest of the sync is shared.
| OneRADIUS | Xonware XIMS | |
|---|---|---|
| Made by | ARCR Technologies | Xonware |
| Login | One API token: Administration, Settings, API Settings, “Enable API?” | The API username and password Xonware set up for your portal |
| How customers arrive | The whole roster on the first sync, then linked to an ONU where a MAC bound to them in OneRADIUS is seen | Each MAC learned behind an ONU is looked up; a customer appears once their router has been seen |
| How often | The list is read about every 30 minutes; Sync now re-reads every customer’s MAC bindings | New MACs are asked about every 30 minutes; Sync now asks about everyone again |
| Status | Built to ARCR’s published API reference, every reply shape checked. The first link is verified with you: Test connection, one sync, compared against your OneRADIUS panel | Running against a live XIMS portal |
What you get on each ONU
The subscriber’s name, username, mobile, address, plan, expiry and live session, on the ONU’s own page and in the customer roster, so the question “whose ONU is this?” is answered before anyone picks up the phone.
The server stays the source of truth
While a server is linked, it owns username, name, mobile and address: editing them in RadixOLT is refused, because the next sync would put the server’s value back. Unlink it and they are yours to edit again.
Absence is never acted on
A forwarding table ages entries out and a read can stop short, so a MAC missing from one read unlinks nothing and deletes nothing. A customer missing from one OneRADIUS list is not deleted either.
A router seen behind an ONU wins
A MAC match moves a customer even if someone assigned them by hand, because the router was just seen there. A MAC claimed by two OneRADIUS customers links neither.
Times are read as Indian time
Neither server writes a time zone, and both are sold to Indian ISPs, so their times are read as IST. The record exactly as the server sent it is kept beside the customer.
Which OLTs can feed it
The sync needs one read of a whole chassis’s MAC table, never one per ONU, which on a large OLT would take more than an hour. Platforms without that read are named in the sync status rather than skipped silently.
Getting it switched on
Link Radius Server is a premium add-on, switched on per ISP by us alongside either plan and priced with you on the call. It is not part of a plan or of the trial, and every sync checks both the grant and the subscription, because the sync dials your OLTs.
Once it is on, an ISP Admin links the server under Customers: choose OneRADIUS or Xonware, give the address your admin panel or portal opens at and the API login, then Test connection.
The server address has to be a public HTTPS address. Loopback, private and other internal ranges are refused in the connection itself, so a typed address cannot be used to reach inside our network.