MikroTik vs Quantum: An IPoE BNG Bake-Off

Executive Summary

For a dedicated IPoE BNG, Quantum is the winner — and the reason is
architectural, not a feature count.

A MikroTik device configured as an IPoE BNG is not a BNG. It is a
multi-component solution the operator hand-integrates: RouterOS for
forwarding, a separately downloaded user-manager package for AAA, a DHCP
server wired to it over RADIUS, and a simple-queue topology the operator designs
for rate enforcement. Those parts were built for different jobs and never fully
join, so a subscriber ends up spread across three tables with three keys and
three lifetimes — a lease with no counters, an accounting row with two totals,
and a queue re-zeroed whenever the rate changes.

Quantum is one product, built for one job. DHCP and AAA are embedded, and
the subscriber is one IP-keyed session record carrying identity, plan,
address and a handle to twelve per-session counters in the data plane. That is
why its embedded AAA emits a conformance-resolved billing record per subscriber,
why a tier change reaches the policer immediately rather than at the next lease
renewal, and why the platform is carrying commercial IPoE traffic within an hour
of download — with no RADIUS server in the path.

The nine rounds that follow test that claim one capability at a time.

The Bake-Off

Two boxes. The same job: terminate IPoE subscribers, authorise them, rate-limit
them, and produce the data an ISP bills from.

Both can hand out an address and cap a speed. That is where the similarity
ends, and the reason is not a feature list. It is what each product keeps in
its session table.

MikroTik spreads a subscriber across three unrelated tables with three different
keys and three different lifetimes. Quantum keeps one IP-keyed session record
that holds identity, policy, address, usage and live throughput together. Every
round in this document is downstream of that single difference.

The scorecard, up front

Eight rounds to one. Round 9 is real and we state it plainly: if the question is
"can one box be my RADIUS server for Wi-Fi, hotspot, PPPoE and IPoE at once?",
MikroTik answers better. If the question is "can I run an IPoE subscriber base
and bill it properly?", only one of the two answers at all.

What we compared, and how to read it

Contender A is a RouterOS device configured the way MikroTik documents an IPoE
deployment: a DHCP server with use-radius=yes, pointed at the user-manager
package on the same box or a neighbouring one, with rate limits delivered as
Mikrotik-Rate-Limit and enforced by dynamic simple queues. Everything claimed
about Contender A is drawn from MikroTik's own published documentation, with the
field record used only where the documentation is silent.

Contender B is the Quantum IPoE BNG Platform Community Edition, release 1.4 —
the free download. Everything claimed about Contender B is drawn from its
shipped source and release notes. Where a capability lands in 1.5 rather than
1.4, it is marked [1.5] at the point of use.

Round 1 — What Arrives When You Download

A bake-off that starts after installation hides half the result. So start at the
download.

The shopping list

To run IPoE with per-subscriber authorisation, rate control and usage billing,
an operator needs seven things. Here is where each one comes from.

Quantum's row reads "in the box" seven times. That is the product claim, and it
is a literal one: an operator downloads the platform, runs the setup wizard,
and carries commercial IPoE traffic in under an hour — with no RADIUS server, no
FreeRADIUS, and no third-party software anywhere in the subscriber path.

The embedded AAA is not a stepping stone to a real RADIUS server. It is the AAA
service, fully featured, and for a standalone deployment it is all an operator
needs. An external RADIUS connector exists as an optional future integration
for operators who already run a RADIUS estate and want Quantum to join it — not
as a gap being filled.

The glue you write yourself

The table above lists components. The difference in effort is in what is not
a component.

On MikroTik you design and maintain:

• A queue topology — parent queues, insert-queue-before ordering, and a
  convention that keeps dynamic per-lease queues from colliding with static ones.
• An Option 82 strategy. MikroTik's own insertion sets circuit-ID to the ingress
  interface MAC and remote-ID to the client MAC, which carry no line identity, so
  the useful case is Option 82 arriving from an access node upstream.
• An accounting consumer. The session table is readable from the CLI and the
  /um page; turning it into invoices is a scripting exercise against a device.
• A provisioning path. One user per CLI invocation, with no AAA API.
• A backup discipline, because the subscriber database is a SQLite file on the
  device's flash and there is no replication, no HA and no external backend.

On Quantum, for the standard path, you write none of it. The policer is
programmed from the plan at onboard. Line identity is carried on the session as
circuit_id and remote_id and matched to an account. Billing records drain
over a documented cursor API. Provisioning is REST, atomic and bulk-capable to
10,000 records. And the subscriber database lives in QuantumTouch, deliberately
outside the BNG — Round 7.

Day one, hour one

Round 1 verdict. MikroTik arrives as a router an operator turns into a BNG:
the AAA server is a separate download, and the queue topology, Option 82
strategy, accounting consumer and provisioning path are all the operator's to
design. Quantum arrives as a BNG, with the glue already written.

Round 2 — The Session Table

This is the round that decides the other eight.

Where the subscriber lives

Where a subscriber lives in each product. MikroTik needs three lookups in three tables on three different keys; Quantum needs one. Pills marked 1.5 are CE 1.5 additions — everything else in the picture ships in CE 1.4.

MikroTik: three tables that never join

A MikroTik IPoE subscriber has no single representation. They exist as three
fragments:

The DHCP lease (/ip dhcp-server lease), keyed by address or MAC, holds the
address, the client identifier and the expiry. It holds no byte or packet
counters at all. It is an address-allocation record, and nothing more.

The User Manager session (/user-manager session), keyed by
acct-session-id, is the accounting fragment. Its complete field set is
acct-session-id, active, calling-station-id, download, ended,
last-accounting-packet, nas-ip-address, nas-port-id, nas-port-type,
started, status, terminate-cause, upload, uptime, user and
user-address. For usage that is three numbers: download, upload,
uptime — and they are only as fresh as the last Accounting-Request interim
that arrived over UDP.

The dynamic simple queue is the enforcement fragment. It holds the rate
limits and it does have live byte and packet counters — but it is keyed by queue
target, it is not part of either table above, and it is torn down and re-zeroed
whenever the lease is rebuilt or the rate changes.

Three keys. Three lifetimes. Three owners. Nothing joins them, and the
consequences are concrete:

• No live per-subscriber rate exists as data. The queue knows the bytes; the
  session knows the identity; nothing knows both.
• Usage resolution is the interim interval. Between interims, usage in the
  session table is stale by design.
• A rate change destroys the counters. Re-rating a subscriber rebuilds the
  queue, so the live byte counts restart from zero — mid-cycle.
• The expired session status exists because the model leaks. User Manager
  needs a state for "this session stopped reporting and never sent a Stop."
  That state is the accounting-side admission that a DHCP lease gives the AAA
  server no reliable liveness signal.

Quantum: one record, and it is the join

A Quantum session is a first-class object, keyed by framed_ip, persisted
across controller restarts, and carrying everything about that subscriber at
once:

Alongside it, deliberately off the persisted blob so that writing counters never
writes state, sits the transient half: last_counters — twelve u64 counters,
green/yellow/red × in/out × octets/packets — plus idle_streak_ms, and
[1.5] the sampler's per-band rate and short history ring.

That single record is the join MikroTik does not have. Identity, entitlement,
address, policer state, usage and live rate are all one lookup from each other.

What the session table makes possible

The practical argument is a chain. Each property of the session table unlocks a
capability, and each capability has a commercial consequence.

Round 2 verdict. MikroTik's three-table split is not an implementation
detail that a release could tidy up — the lease, the accounting session and the
queue have genuinely different lifetimes in that architecture. Quantum's single
session record is the reason the next three rounds go the way they do.

Round 3 — Throughput, Subscriber by Subscriber

Round 2 established where usage lives. This round is about what is measured,
and how good the measurement is.

Two outcomes versus six

MikroTik's enforcement is a token-bucket simple queue. A packet is passed or
dropped. Those are the only two outcomes the mechanism can distinguish, so
they are the only two outcomes it can count — and only the passed count reaches
the accounting record.

Quantum's enforcement is an RFC 2698 two-rate three-colour marker in the VPP
data plane. Every packet is coloured:

Three colours, two directions, octets and packets: twelve counters, per
subscriber, maintained in the data plane, reachable through the
vpp_session_handle on the session record.

Red is the one no competitor at this price point has. It is not an error
counter — it is suppressed demand, measured per subscriber. A subscriber with
a persistent non-zero red count is asking for a faster plan.

The measurement chain, end to end

From policed packet to billable record. Both chains end in a billing export; only one of them carries the shape of the traffic with it. The 1.5 pills mark the server-side telemetry additions; the twelve band counters, the buildUsage rollups, the per-band billing record and the durable spool all ship in CE 1.4.

Reading it at any cadence

Because the counters live in the data plane and the session record holds a
handle to them, reading throughput costs no RADIUS exchange and no state write.
Quantum exposes three distinct reads, each tuned to a different question:

The sampler [1.5] is worth a note, because it shows the architectural
dividend. On a five-second clock it reads every live session's counters in bulk
cohorts, differences them to bits per second, and maintains an instantaneous
per-band rate for every session plus a short history ring for the working set.
It never touches the write path. A top-talkers table over the entire subscriber
base is therefore a cheap synchronous read — because the session table already
had somewhere to put the answer.

On MikroTik the same question has no cheap form. The rate is in the queues, the
identity is in the session table, and joining them is work the operator does
outside the product.

Precision

Quantum carries counters as decimal strings deliberately: a 64-bit octet count
exceeds the exact-integer range of a double, so anything that passes through a
JSON number risks silent rounding at scale. The string representation survives
the controller, the REST layer, the spool and the management plane without a
single lossy conversion. On a 2 TB-per-month subscriber that is the difference
between a bill and an argument.

Round 3 verdict. MikroTik measures what a token bucket can tell it: bytes
passed, as of the last interim. Quantum measures what the subscriber was
offered, what was delivered in contract, what was delivered as burst, and what
had to be dropped — per subscriber, per direction, continuously.

Round 4 — The Billing Data

This round is the payoff. The session table and the band counters exist so that
the embedded AAA can produce a billing record an ISP can actually run a business
on.

What each product hands the billing system

The Quantum record, field by field

A note for whoever writes the billing integration. The four rollups are the
sum of all three bands, so output_octets is traffic offered to the
subscriber. Delivered traffic is green + yellow. Both readings are available
from the same record, and choosing between them is a deliberate commercial
decision rather than an artefact of the measurement. No other product in this
class gives the operator that choice, because no other product keeps the bands.

Worked example — one subscriber, one month

An illustrative residential subscriber on a 100 Mbps committed / 150 Mbps peak
plan, over a 30-day cycle. The figures are illustrative; the fields are exactly
what the two products produce.

What Quantum's CDR contains:

What MikroTik's session row contains:

Both are true. Only one of them can be worked with:

The 9.10 GB of red is the line that matters commercially. On MikroTik that
traffic is invisible: it was dropped, so it was never counted, so nothing in the
system records that the customer asked for more than they bought. On Quantum it
is a number attached to a subscriber_id — and a retention and upsell programme
can be built on it.

When the billing consumer goes away

Accounting is only worth as much as its weakest hour.

MikroTik. Accounting is UDP to the User Manager. accounting-backup on
/radius offers a second server; no local spooling of unsent accounting records
is documented. The expired session status implies that sessions which stop
reporting are reaped rather than reconciled.

Quantum. The CDR spool is the system of record for usage until the consumer
acknowledges it:

• A single dedicated writer thread owns the SQLite spool with WAL — the
  checkpoint never lands on the event loop that processes subscriber onboarding.
• The spool is log-compacted, latest-per-session: a session updated fifty
  times since the cursor appears once, at its latest. Spool growth tracks the
  subscriber count, not the elapsed outage.
• Drain is a cursor contract — ?since=<seq> then POST …/ack — at-least-once
  and idempotent on acct_session_id. Consumer lag is an observable number:
  high_water − last acked seq.
• An ack prunes terminated sessions at or below the cursor and retains active
  ones, so they remain available for recovery.
• Backpressure watermarks at 50,000 / 25,000 records, and a worker that crashes
  is respawned with backoff.
• After an unclean restart, any session left open under a prior boot_epoch
  and not seed-and-continued is sealed with a stop carrying
  NAS_REBOOT and its last-known usage. The ledger never carries a session
  that a reboot silently ended.

That last point is the direct answer to MikroTik's expired. Both products know
that a subscriber session can end without anyone being told. One of them has a
status for it; the other closes the record and bills it.

Round 4 verdict. MikroTik produces two numbers and a clock, exported by
hand, over a protocol with no durability story. Quantum produces a ten-figure,
conformance-resolved, u64-precise record per session, drained over a documented
idempotent cursor from a spool engineered to survive both the consumer and the
box.

Round 5 — Changing a Live Subscriber

An operator's day is made of mid-session changes: a tier upgrade, a payment that
clears, a payment that does not, an abuse complaint. This round is about whether
the product can act on a subscriber who is already online.

MikroTik on IPoE: the lease is not a session

MikroTik supports Disconnect-Message and CoA, and they work on PPPoE, where
a control-plane session with a keepalive exists. On the DHCP/IPoE path the
field record across many years and versions is consistent: a Disconnect-Request
against a lease comes back as Session-Context-Not-Found, or as a
Disconnect-NAK with Unsupported-Extension. The settled community workaround
is short lease times of one to five minutes, so that policy changes take
effect at the next renewal.

MikroTik is also explicit in its own documentation that IP addresses, pools
and routes cannot be changed by CoA — the session must be disconnected — and
that Packet of Disconnect is not supported.

There is a further structural point. User Manager's attribute engine targets
only access-accept and access-challenge; CoA-Request is not an available
target, and there is no AAA API. So even where Dynamic Authorization works, User
Manager can only emit what its own internal quota evaluator decides to emit. An
external billing system cannot say "re-rate subscriber X now." It can rewrite
the profile and wait for the next authentication event.

The defence usually offered — "there is no mechanism in DHCP to revoke a lease
and tell the client" — is true about the client and false about the BNG.
A BNG does not need the client's cooperation to change policy. It owns the
forwarding state, the policer, the filter and the FIB entry for that
subscriber's address. Re-rating is a data-plane action, not a DHCP action.

Quantum: one record write, live effect, reported back

On Quantum the operator edits the subscriber record. The write cascades into the
live session and the API reports what happened:

A plan change applied to a live session. QuantumTouch makes the change durable in aaa.db before it is promised to anyone, and the BNG reports what it actually did in the same response.

Two details make this operationally different rather than merely faster.

The effect is reported synchronously. session_action comes back in the API
response, so a billing system knows the change landed rather than hoping it did.
In a bulk operation every row carries its own action.

Non-payment is a state, not a disconnect. CAPTIVE keeps the session, the
address and the accounting alive while restricting reachability to the walled
garden. The subscriber can self-serve a top-up and be restored with activated
— no re-onboarding, no lost session continuity, and a continuous billing record
across the whole episode. The alternative model, which MikroTik's quota engine
implements, is to disconnect on quota exhaustion.

Data caps. Quantum carries an enforcement overlay — throttle to a floor
tier, captive to a top-up page, or clear — applied both at admission and to
live sessions, with an enforcement/bulk call for billing-cycle mass restore.

Round 5 verdict. On IPoE, MikroTik's answer to "change this subscriber now"
is to shorten the lease and wait. Quantum's is one record write with the result
in the response.

Round 6 — Who the Subscriber Is

A quieter round, but it is the one that decides whether the product can model a
customer.

MikroTik: the MAC is the identity

On the DHCP path RouterOS sends an Access-Request in which User-Name is the
client's MAC address and User-Password is empty. The User Manager session
table's user column therefore holds a MAC. Identity and locator are the same
object, and three consequences follow directly:

• A CPE swap is a new customer. New MAC, new user, new session history.
• Two devices are two unrelated subscribers. There is no account to which
  both belong.
• Usage history is attached to hardware, not to a person. Replace the router,
  lose the record.

MAC-based authorisation is standard IPoE practice; carrying the MAC as the
identity is the part that does not scale to a subscriber base.

Quantum: identity, and the locators that find it

Quantum's local AAA provider is explicit on this point in its own source: the
BNG never creates a subscriber's identity. The data plane presents locators
— circuit-id, MAC — and the record store returns a stable subscriber_id.

• MAC is the session / device key. Never an identity.
• circuit-id is the attachment / line locator.
• subscriber_id is the identity, operator-assigned and opaque.

A record carries a match[] list, so one subscriber may be reachable by several
locators — a line and two devices, or a line that keeps its account through a
CPE replacement. The resolver takes locators in and returns an identity plus an
outcome: accept, captive or reject, with the enforcement overlay applied.

Round 6 verdict. MikroTik identifies hardware. Quantum identifies customers,
and treats hardware as one of several ways to find them.

Round 7 — Provisioning, and What Survives an Upgrade

Provisioning

The question nobody asks until it bites

Where does the subscriber database live, and what happens when you upgrade the
box?

On MikroTik the answer is: on the device's flash, in User Manager's SQLite file,
and that is the only copy. No replication. No HA. No external database backend.
No external identity source — no LDAP, no AD, no SQL lookup.

Quantum answers it differently, and the reason is instructive. The controller
package's installation script clears its own configuration database on every
install and upgrade. An AAA service that kept 5,000 subscriber accounts there
would lose them on a routine package update. So the architecture was changed
rather than the symptom patched: QuantumTouch is the system of record for
AAA.

Three rules govern it, and each one exists because the alternative was tried:

• Durable first, then push. The irreversible half of an operation never
  happens before the durable half.
• Never delete a subscriber we did not create. Accounts found upstream that
  QuantumTouch did not provision are recorded as unmanaged and are never
  auto-removed; the console offers Adopt or Remove.
• A push failure is not an operator error. The write succeeded durably; the
  reconciler keeps trying and the console says so.

Wipe detection uses a two-pass debounce before bulk re-provisioning, so a single
slow poll cannot trigger a mass rewrite.

Round 7 verdict. MikroTik keeps the subscriber base in one file on the
device that forwards the traffic. Quantum keeps it deliberately outside the BNG,
and treats the BNG as a cache that can be rebuilt — which is the only
architecture under which "upgrade the BNG" is a routine act.

Round 8 — Scale, Licensing and Operating Cost

Two differences matter in a procurement conversation.

The free tier is a production tier. 1,000 subscribers without any
registration, and 5,000 after a free self-service unlock, is a real small-ISP
deployment — not an evaluation allowance. An operator can build a business on
Community Edition and upgrade when the subscriber base, not the licence, demands
it.

The cap is reported with its provenance. A management plane can render the
tier honestly because the API says both the number and where it came from. On
MikroTik, discovering the ceiling is an operational event.

Round 8 verdict. Quantum's free tier is five times the size of a plausible
small ISP's base, and its paid tiers go an order of magnitude beyond what a
RouterOS licence addresses.

Round 9 — Where MikroTik Wins

A bake-off that scores nine-nil is not a bake-off, it is a brochure. MikroTik
wins this round, and the wins are genuine.

Three of these — EAP, TOTP, RadSec — are outside the IPoE path by design: an
IPoE subscriber authorises with a MAC and a line identifier, and no amount of
EAP machinery changes that. On the DHCP path MikroTik's own entire
authentication subsystem is bypassed too.

Calendar-tiered prepaid is the one to take seriously. For a prepaid or
hotspot-adjacent operator, off-peak tiers and timed vouchers are a real product
requirement, and MikroTik has them today. It belongs on Quantum's roadmap, not
in a rebuttal.

RadSec is the one to watch. A TLS-protected RADIUS transport, selectable per
NAS, is a serious capability at this price point, and it is the right answer for
an operator whose RADIUS traffic crosses untrusted transport.

Round 9 verdict. MikroTik is the broader AAA server, and on calendar-tiered
prepaid it has a capability Quantum does not have at any price. Quantum's AAA is
built for IPoE subscribers only, which is why most of this table sits outside
its scope by design — the calendar tiers do not, and they belong on the roadmap
rather than in a rebuttal.

The Scorecard

Session model and identity

Measurement and billing

Control of a live subscriber

Platform and operations

Breadth outside IPoE

How to Decide

Three questions settle it in a customer conversation.

1. "Is IPoE the business, or one service among several?"
If the box has to be a RADIUS server for PPPoE, hotspot, wireless and router
login as well, MikroTik's breadth is the right answer and we should say so. If
the business is a residential or business IPoE subscriber base, breadth outside
IPoE buys nothing and the session model decides everything.

2. "Do you bill on usage, or on a flat rate?"
A flat-rate operator who never re-rates mid-cycle and never disputes a bill can
live with two numbers and a clock. Everyone else needs conformance-resolved,
u64-precise, durably spooled records tied to a subscriber identity — and that is
Rounds 3 and 4.

3. "When a customer calls to upgrade, what happens?"
On MikroTik: change the profile and wait for the lease to renew — which is why
the deployments run one-to-five-minute leases. On Quantum: one record write, the
policer swaps atomically, the API confirms re_rate, and the subscriber sees a
speed change and nothing else.

The one-paragraph version

MikroTik gives an ISP a capable multi-service RADIUS server that was not built
around a subscriber session, bolted to a DHCP server that was not built to be a
BNG. The subscriber ends up spread across a lease, an accounting row and a
queue, which is why there is no live per-subscriber rate, no conformance detail
in the usage record, and no way to change a live IPoE subscriber without waiting
for a lease to expire. Quantum starts from the session: one IP-keyed record
holding identity, plan, address, twelve data-plane band counters and the
handle that reads them — which is why the embedded AAA can emit a
conformance-resolved billing record per session, why a plan change takes effect
in the policer immediately, and why the whole thing is complete and carrying
traffic within an hour of the download.

Appendix A — MikroTik Reference

Condensed from BlueDot's RouterOS 7 user-manager teardown. Retained here so
the body can stay a comparison.

Packaging and lineage

The v7 rewrite is the key lineage fact: most third-party tutorial content and
most negative performance folklore refers to v5. The v7 engine added the
capability that makes User Manager arguably a general-purpose RADIUS server —
operator-definable RADIUS attributes with an arbitrary vendor ID.

Documented absences

For a product of this maturity, undocumented is functionally unsupported.

• No RADIUS proxy or forwarding; no realm routing, no home-server pools.
• No high availability or replication — the SQLite database is local.
• No external database backend: no MySQL, PostgreSQL or ODBC.
• No external identity source: no LDAP, AD or SQL user lookup.
• No programmatic AAA API for provisioning or on-demand CoA injection.
• No documented Accounting-On / Accounting-Off handling, and therefore no
  documented NAS-restart session reconciliation.

RFC posture

MikroTik explicitly states that IP addresses, pools and routes cannot be changed
by CoA, and that Packet of Disconnect is not supported.

Messaging channels

require-message-auth is the BlastRADIUS (CVE-2024-3596) control and should be
enabled on any new deployment.

The DHCP seam

/radius
  add address=10.0.0.1 secret=VERYsecret123 service=dhcp

/ip/dhcp-server
  set dhcp1 use-radius=yes

Access-Request for a DHCP client carries User-Name (the MAC),
User-Password (empty), NAS-Identifier, NAS-IP-Address, NAS-Port
(ifIndex), NAS-Port-Id (interface name), NAS-Port-Type (Ethernet),
Calling-Station-Id (active-client-id), Called-Station-Id (server instance)
and Framed-IP-Address, plus Mikrotik-Host-IP (VSA 10).

Access-Accept honoured on the DHCP path — six documented attributes:

Precedence is Mikrotik-Rate-Limit > Ascend > WISPr. Per-lease RADIUS rate
limiting for DHCPv4 arrived in RouterOS 6.43. The PPP surface additionally
honours Filter-Id, Framed-Route, Framed-IP-Netmask, Mikrotik-Mark-Id,
Mikrotik-Address-List, Mikrotik-Recv-Limit/Xmit-Limit,
Mikrotik-Total-Limit, Idle-Timeout, Port-Limit, Acct-Interim-Interval,
Class, Mikrotik-Group and the IPv6 set — a substantially larger documented
table.

Accounting on the DHCP path. Interim updates are mandatory for the quota
engine; without them quota exhaustion cannot be detected and no disconnect is
issued.

Option 82 and TR-101. add-relay-info defaults to no; when enabled,
circuit-ID is the ingress interface MAC and remote-ID is the client MAC — no
line identity. support-broadband-tr101 adds suboptions 0x81 / 0x82 (actual
upstream / downstream rate), documented as included in RADIUS Access-Request and
Accounting-Request messages.

Vendor attribute surface — PEN 14988

Other vendor dictionaries recognised: Microsoft (PEN 311), Ascend (529), WISPr
(14122), DSL Forum (3561).

Changeable by CoA (PPP context): Mikrotik-Rate-Limit, Mikrotik-Mark-Id,
Mikrotik-Address-List, Filter-Id, Session-Timeout, Idle-Timeout,
Mikrotik-Recv-Limit/Xmit-Limit/Total-Limit and gigawords variants. Not
changeable: IP address, pool, routes.

Component structure

A RouterOS device configured as an IPoE BNG: core RouterOS on the left, the separately downloaded user-manager package on the right, joined by the operator over RADIUS on the loopback.

For IPoE, the authentication core is entirely bypassed. The DHCP service
authenticates with a MAC in User-Name and an empty password; EAP, TLS, TOTP
and method negotiation are inaccessible on that path.

Appendix B — Quantum Reference

The local AAA decision

resolve(locators, records, enforcement)
   → { subscriber_id, outcome, plan_name, framed_ip, timeouts, overlay }

The REST surface

Defaults that matter operationally

A plan is eight integers: dn_cir_kbps, dn_pir_kbps, up_cir_kbps,
up_pir_kbps (required) plus dn_cbs_kb, dn_pbs_kb, up_cbs_kb, up_pbs_kb
— resolved to the data-plane policer at onboard.

Terminate causes — RFC 2866 numerics

USER_REQUEST 1 · LOST_CARRIER 2 · IDLE_TIMEOUT 4 · SESSION_TIMEOUT 5 ·
ADMIN_RESET 6 · NAS_REBOOT 11 · SERVICE_UNAVAILABLE 15

Onboarding call flow

A first-contact IPoE onboarding with aaa_source = local. No RADIUS server appears anywhere in the exchange.

Where Quantum goes next

The connector point is the architectural one. The CDR client implements the same
accountingStart / accountingInterim / accountingStop interface a RADIUS
client would, but writes to a durable local spool instead of a wire protocol.
The spool is then drained per edition — QuantumTouch tails it in Community
Edition; a RADIUS client forwards from it commercially. Accounting durability is
therefore a property of the platform, not of the operator's RADIUS server.

Sources

MikroTik primary documentation

• User Manager — RouterOS Documentation
• User Manager — RouterOS Manual
• RADIUS — RouterOS Documentation
• RADIUS — RouterOS Manual
• DHCP — RouterOS Documentation
• DHCP — RouterOS Manual
• RADIUS Client — RouterOS Docs mirror
• RouterOS license keys

Standards

• RFC 2698 — A Two Rate Three Color Marker
• RFC 2866 — RADIUS Accounting
• RFC 2869 — RADIUS Extensions
• RFC 5176 — Dynamic Authorization Extensions to RADIUS
• RFC 4679 — DSL Forum Vendor-Specific RADIUS Attributes

MikroTik field and community evidence

• Disconnect DHCP user from RADIUS?
• MikroTik DHCP RADIUS — Disconnect-NAK Unsupported-Extension
• 406 Error When Sending disconnect request to DHCP Radius
• New User Manager in RouterOS v7
• Session limit reached (current license allows only 200 session)
• TR101 support
• Edge Router & BNG Optimisation Guide for ISPs — Daryll Swer

Prepared by BlueDot Insight for the Quantum IPoE BNG launch.
© 2026 BlueDot Insight LLC. BlueDot Proprietary.