How to buy Partners Documentation Support Log in
NETAVO·BNG
Start free eval
How to buy Partners Documentation Support Log in
BNG & LNS / Running Netavo BNG with Splynx: a RADIUS integration guide

Engineering · 14 Oct 2026

Running Netavo BNG with Splynx: a RADIUS integration guide

Splynx is the billing brain and RADIUS server; Netavo is the NAS. Here's how to wire them together for speed plans, CoA, suspension and accounting.

IntegrationSplynxRADIUS

Splynx is a popular ISP management and billing platform, and it ships its own FreeRADIUS-based RADIUS server. If you already run Splynx, you do not need to change any of that to adopt Netavo BNG. Splynx stays the billing brain and the RADIUS server; Netavo becomes the NAS that terminates subscribers and enforces what Splynx decides. The two talk standard RADIUS, and Netavo is built to understand the attributes Splynx sends, including the MikroTik rate-limit VSA its default setup emits.

This guide walks through the integration end to end. Splynx field labels are from the 6.x interface and move between versions, so treat the menu paths as a map rather than gospel, and confirm them against your instance.

Who does what

Splynx owns the customer, the tariff and the decision to allow, throttle or suspend a line. It authenticates each session, returns the speed plan, sends a change-of-authorization when a plan changes, and suspends a non-payer. Netavo owns the data path: it terminates PPPoE or IPoE, applies the rate Splynx returns, assigns addressing, runs CGNAT and routing, and puts a suspended subscriber in the walled garden. Accounting flows back from Netavo to Splynx for usage and online status.

Nothing is pre-provisioned on the box. Every per-subscriber decision arrives from Splynx in the RADIUS exchange.

Step 1: add Netavo as a router in Splynx

In Splynx, go to Networking → Routers → Add and create an entry for the BNG:

  • IP / Host: the address Splynx will see RADIUS packets arrive from (behind NAT, the public address).
  • NAS IP: the value Netavo puts in NAS-IP-Address. Set this to match Netavo's configured NAS IP.
  • Radius secret: the shared secret. It must match the secret you configure on Netavo.
  • NAS type: choose the MikroTik type (or a custom type based on it). The NAS type is what selects the vendor rate-limit attribute set, and the MikroTik type emits the Mikrotik-Rate-Limit VSA, which Netavo honours natively. You are not using any MikroTik-specific API here, only the attribute format.

The RADIUS server listens on the usual ports: UDP 1812 for authentication, 1813 for accounting, and 3799 for CoA and Disconnect. Make sure all three are open between Splynx and the BNG.

Step 2: point Netavo at Splynx

On the Netavo side, the RADIUS driver does auth, accounting and CoA against Splynx:

"auth": {
  "driver": "radius",
  "radius": {
    "servers": [ { "host": "10.20.0.5", "port": 1812, "secret": "op://netavo/splynx/secret" } ],
    "nasIdentifier": "bng1",
    "nasIpAddress": "45.84.203.1",
    "rateAttributeMode": "mikrotik",
    "coaPort": 3799,
    "coaSecret": "op://netavo/splynx/coa",
    "coaAllowedSources": ["10.20.0.5"]
  }
},
"accounting": { "driver": "radius", "interimIntervalSeconds": 300 }

rateAttributeMode set to mikrotik tells Netavo to read the Mikrotik-Rate-Limit VSA that Splynx sends. The auto default also works and additionally understands the Netavo and Broadband-Forum rate families, which is useful if you later run a mixed estate. coaAllowedSources should list the Splynx server address so the box only accepts CoA from it.

Step 3: speed plans

A Splynx tariff sets a download and upload speed. With the MikroTik NAS type, Splynx builds the rate from its rx_rate_limit and tx_rate_limit template variables (both in bit/s) into the standard RouterOS string, for example Mikrotik-Rate-Limit = 20000000/100000000. In that string rx is the client's upload toward the NAS and tx is the client's download, and Netavo applies them with exactly that meaning. Bursts carried in the same attribute are honoured too.

The result is that your tariffs define the speeds in Splynx as they always did, and the BNG needs no per-plan configuration. Change a package in Splynx and the next session gets the new rate.

Step 4: change a plan without a reconnect (CoA)

When a customer upgrades or downgrades, Splynx sends a CoA to port 3799 carrying the updated Mikrotik-Rate-Limit, and Netavo re-applies the rate to the live session. The subscriber keeps their IP and their session; only the shaping changes. Splynx identifies the session by User-Name, Framed-IP-Address and Acct-Session-Id, all of which Netavo carries. Splynx logs every CoA and Disconnect it sends to its coa.log, which is the first place to look if a change does not take.

A point worth knowing: Splynx's documentation notes that CoA and Packet-of-Disconnect are not supported in its MikroTik DHCP-plus-RADIUS setup, where the workaround is a short DHCP lease and address-list blocking. That is a MikroTik limitation, not a RADIUS one. Netavo accepts CoA and Disconnect the same way on IPoE as on PPPoE, so you are not forced into the short-lease workaround.

Step 5: suspend a non-payer (the one part that differs)

This is the step where you diverge from the MikroTik default, so read it carefully.

When a customer goes to Blocked, Splynx sends a CoA with a blocking attribute. Its default is Mikrotik-Address-List = Reject_1, which only a MikroTik understands. Netavo does not read Mikrotik-Address-List. Instead it has a first-class service-state attribute of its own, Netavo-Service-State (vendor 66418), with the values active, restricted (also accepted as walled-garden) and blocked.

So in the Splynx NAS type, set the CoA block and restore attributes to Netavo's VSA rather than the MikroTik address-list:

  • CoA Block attributes: Netavo-Service-State = restricted to move the subscriber into the walled garden (session stays up, traffic is redirected), or Netavo-Service-State = blocked to accept the session but drop its traffic.
  • CoA Restore attributes: Netavo-Service-State = active to release them when they pay.

For a walled-garden experience, Splynx can also send Netavo-Http-Redirect-Url pointing at your payment portal, and Netavo's captive DNS steers the restricted subscriber there. You add the Netavo attributes to Splynx through its RADIUS attribute customization, the same mechanism Splynx provides for any non-MikroTik vendor. The suspension can be applied at authentication as well as by CoA, so a customer who was already in debt comes up straight into the walled garden rather than getting a moment of full service first.

Step 6: accounting and usage

Netavo sends RADIUS Accounting Start, Interim-Update and Stop, and Splynx consumes them for usage counters and online status. Splynx returns Acct-Interim-Interval in the Access-Accept to set how often interims are sent, configurable per NAS type; the Netavo side sets a matching default. The accounting records carry Framed-IP-Address and, for dual-stack subscribers, the IPv6 WAN address and prefix, so Splynx sees the full picture of what the subscriber holds.

Step 7: PPPoE and IPoE identity

For PPPoE, each customer has a username and password on their Splynx internet service, and the CPE logs in with them. Nothing special is required beyond pointing auth at Splynx.

For IPoE / DHCP, Splynx identifies the line by the client MAC and, where you use it, DHCP Option 82. Splynx reads the Agent-Circuit-ID from the subscriber's Port ID field. To make that match, set Netavo's Option 82 encoding so the circuit-id reaches Splynx in the form it expects:

"auth": { "radius": { "option82Encoding": "nas-port-id" } }

nas-port-id and calling-station-suffix are both available, so you can present the line identity in whichever attribute your Splynx customization keys on.

Step 8: IPv6, where Splynx stops and Netavo continues

Splynx's documented RADIUS flow covers IPv4 addressing (it can assign Framed-IP-Address or hand the NAS a pool name with Framed-Pool), but it does not document IPv6 prefix or prefix-delegation assignment. That gap does not hold you back, because addressing can live on the NAS. Netavo assigns the IPv6 WAN address and the delegated prefix from its own typed address pools, independent of Splynx, so your subscribers get dual-stack while Splynx continues to own authentication, rate and suspension. Let Splynx drive identity and policy, and let Netavo own addressing.

Honest caveats

  • Splynx labels move between versions. The menu paths and field names here are from 6.x. Confirm the exact "CoA Block attributes" and NAS-type fields in your instance before relying on them.
  • The blocking attribute is the thing to get right. If you leave Splynx on its default Mikrotik-Address-List = Reject_1, suspension will silently do nothing on Netavo. Use Netavo-Service-State, and remember to set the restore attribute too, or a suspended customer never comes back.
  • Add the Netavo dictionary to Splynx. The Netavo-Service-State and Netavo-Http-Redirect-Url attributes are under enterprise number 66418; add them to Splynx's custom attributes so it can send them.

Try it against a test tariff

The free evaluation build is the full production build, licensed for up to 50 concurrent subscribers. Point a staging Splynx at it, add the box as a router, and bring a test customer up: check the speed from the tariff, change the plan and watch the CoA land, then suspend and restore. Start at netavobng.com/evaluation; the RADIUS and attribute reference is in the manual.

More from Engineering