Known issues
Issue references below are internal tracking identifiers, not public links.
#NN refers to the QuantumTouch console and appliance; bng#NN to the
Quantum BNG controller — the two are numbered separately, so #38 and
bng#38 are different items. Quote them when raising a support ticket.
Session reclamation at high scale [controller] — bng#50
Under sustained churn at 18,750 concurrent sessions, the controller's session
view stops reclaiming released sessions: measured at exactly its high-water mark
for 550 seconds with a drain rate of zero, while clients had released down to
8,191. Nothing is lost — orphans were zero in every run — and the cap, dataplane
and onboarding paths are unaffected.
Traced upstream to two defects, both fixed in controller 1.5: relayed DHCP
RELEASEs were dropped entirely (so reclamation only happened on lease timeout),
and teardown ran per-packet, capping reclaim at a few hundred per second.
Not reproducible at 7,500 and below across three runs.
Session count under sustained churn [controller] — bng#36
A separate effect from the reclamation issue above, and it presents differently:
under sustained high churn the controller's reported session view can
under-count a cohort of otherwise-stable sessions. The sessions themselves
remain bound and carrying traffic; it is the count that is short, and the
affected sessions reappear in the view when they next renew.
Reclamation above is a count that stays too high; this is a count that reads
too low. Both are view-level, and neither loses a session. Investigation is
ongoing upstream, with verification scheduled for a post-1.4 test cycle.
Practical consequence: during a churn event, treat the session count as
indicative and the pool's allocation figure as authoritative.
The Dataplane page reports the BNG's own NICs as unassigned — #49
The console's devbind view sorts NICs into kernel, DPDK and VPP. A NIC is
placed under VPP only when it appears in the stored port-assignment list;
the bucket records the assignment an operator made, not what VPP is driving at
that moment. On a box whose ports were never assigned through the console — a
hand-configured startup.conf, or a commissioning run that stopped before the
Dataplane step — the access and uplink NICs are correctly shown as DPDK-bound
but never attributed to VPP, even while VPP is forwarding on them.
The display is the smaller half. The same stored list is what makes
/api/dpdk/devbind/bind, /unbind and /reset-all-to-kernel refuse an
operation on a port VPP is using: with the list empty those endpoints do not
return 409 VPP_MUST_BE_STOPPED, so a rebind requested against a live
dataplane NIC is carried out instead of refused. The rebind also re-renders
/etc/vpp/startup.conf. Nothing does this on its own — it needs an operator or
a script to ask for it — but the guard that should stop it is not armed.
Workaround. Assign the dataplane ports on the Dataplane page as part of
commissioning, before the box carries subscribers. That records the assignment,
restores the VPP attribution and re-arms the guard. On a box already in service,
do not use the bind / unbind / reset-to-kernel controls to fix the display:
the operation will be allowed and will interrupt forwarding. Assign the ports
during the next planned maintenance window instead.
Affects the console's reporting and that guard only. Subscriber onboarding,
forwarding, QoS and the session cap do not consult this list, and the dataplane
itself is unaffected — this is visible in the 1.4.0 validation run, where the
check for VPP-attributed NICs is the single failing check on a box that passed
every forwarding, onboarding and QoS measurement in the same run.
RADIUS is not active — #17
The /bng/radius surface is inert in this build; local AAA is the AAA backend.
GET reports active: false and PUT is refused, deliberately, so an operator
cannot configure a backend that silently does nothing. An ISP that already runs
an external AAA or OSS cannot integrate with this release.
There is no RADIUS page in the console — it has been unrouted since v1.2, so
nothing in the UI invites you to configure a backend that would not work. The
Health page reports AAA (source, subscriber count, and the unknown-CPE
policy) rather than RADIUS server reachability. Earlier builds showed two red
"RADIUS Unreachable" cards on every box, which was a false alarm for a subsystem
that is inert by design; that is fixed in this release.
External AAA integration is tracked as #17, as a paid plugin covering
FreeRADIUS, Splynx, Sonar, UISP and Powercode — provisioning in, records out.
No live coverage that an add-on installs — #38
The add-on install path is thoroughly unit-tested, but every one of those tests
mocks the fetch, the hash and the unpack. Nothing verifies that a real pack
downloads from its distribution point, installs on a real box and then functions.
Tracked for 1.5.0 as #38.
The Subscriber column — #27, restored by #37
Removed — see Behaviour changes.
Only subscribers reconcile after a controller upgrade — #31
See Upgrading. The controller discards its configuration replica on upgrade,
and nothing re-pushes it automatically. The console is the authority, but it
has no drift-triggered full-state reconciler in 1.4.0: there is no config_hash
drift detection in the console at all, and the only reconciler that exists
operates on the AAA store.
Recovery is therefore operator-initiated: take a snapshot first and restore it.
That works — see Upgrading for the two restore paths and what each covers —
but it is a manual step, and a box upgraded without one has to be reconfigured
by hand. #31 is the full-state reconciler that would make it automatic.
No durable per-subscriber usage history — #33
Accounting interim records are collapsed into one mutable row per open session
plus a daily rollup, which discards the time dimension. So "how much did this
subscriber use, by hour, last week" cannot be answered from the box.
Current and cycle-to-date usage are correct and are what data-cap enforcement
acts on — this affects history only. Note the controller's own per-session rate
history is an in-memory ring (~10 minutes, deliberately lost on restart), so
until #33 lands there is no durable per-subscriber series on either side.
No validated VPP sizing profiles — #29
The stats segment is now sized by the installer. Earlier releases left it
at VPP's default, so it had to be set by hand. GA sets it to 1 GiB on install,
raises a smaller existing value, and never lowers a larger one — if you sized
it up yourself, your value is kept.
The figure is a deliberate margin rather than a calculation. Measured on a
25,000-session-licensed box, usage is a fraction of a percent of that
1 GiB, and it scales with the VPP worker-thread count and the number of
interfaces and graph nodes — not with the number of subscribers online.
A box with more workers needs more at any subscriber count. The margin is
there because the segment is cheap on any supported host and because the
behaviour under a recovery replay, which is where exhaustion would be worst,
is not something these figures cover.
1.4.0 sets processor_statseg_size_mb = 1024 on install, raises a smaller
existing value, and never lowers a larger one. If you sized it up yourself,
your value is kept.
What is still missing is the per-tier part: 1024M is a known-good ceiling
for 25,000 sessions, not a derived minimum, so it may be over-provisioned for
smaller deployments. There are no profiles for other subscriber or throughput
targets, and worker counts and buffer sizing are still derived by the operator
outside the tested configuration. #29 tracks shipping validated profiles.
You can watch it: GET /api/compute/memory_breakdown returns
vpp_stats_segment with total_kb, used_kb and free_kb, and the console's
memory panel renders it — so approaching the limit is visible rather than
something you discover under load.
Console polling load scales with session count and open tabs — #14, #15
Two separate effects, neither of which affects correctness:
- The sessions view fetches the whole session list every 5 s and differences
it client-side to derive rates. At 25,000 sessions that is a large repeated
read. The controller endpoints that let us replace it with a server-side
top-N and per-session rate land in controller 1.5 (bng#38);
retiring the full-list pull is #14. - Each open browser tab runs its own polling loops, so controller load scales
with (tabs x pages x loops). Coalescing them through the backend is #15.
Operationally: on a large deployment, prefer fewer simultaneously-open console
tabs during a scale test or a maintenance window.
A licence activated on the evaluation appliance can revert to the free tier — bng#52
You do not need a licence to evaluate. The evaluation appliance runs on the
free tier, which needs neither a licence nor a TPM, and licence activation is
not part of the supported evaluation path. If you never activate, this issue
cannot affect you.
If you do activate a capacity licence on the evaluation appliance, it can later
report EXPIRED, and the session cap returns to the free tier's 1,000. It has
been seen after a power cycle, but the validity check also re-runs every 60
seconds while the box is up, so the box does not have to be restarted for the
state to change.
What is not happening is as useful as what is. The machine fingerprint is
unchanged across the restart, and the sealed licence material is still read back
successfully — a licence that could not be unsealed would report NOT_ACTIVATED
rather than EXPIRED. Identity and sealing are intact; the validity window itself
is being computed wrongly. That window is derived from the TPM clock, and on the
evaluation appliance the TPM is emulated. Whether a discrete hardware TPM
behaves the same way has not yet been measured; bng#52 tracks that.
Workaround. Re-submit the same licence file on the Licensing page. It
returns to VALID with the full capacity immediately, and no other state is
disturbed. Otherwise evaluate on the free tier, which is unaffected.
Capacity is the only thing this touches. Licence enforcement in this release is
capacity-only: no feature is gated on holding a licence, only quantity is, and a
missing, expired or tampered licence reverts to the free tier rather than
withdrawing function. Configuration, subscriber onboarding, forwarding, QoS,
accounting and the console all continue to work normally at up to 1,000
sessions.
Usage Records is slow to appear on a box with a large ledger — #57
The Usage Records page reads the whole stored CDR ledger in one request. On a
box that has been carrying subscribers for a while that request is large, and
until it finishes the page shows two dashes in place of the Stored CDRs and
Live sessions figures, and an empty table. On a lab box holding 609,000
records it took about 45 seconds; it scales with how many records you are
holding.
Nothing is wrong with the data while this is happening. The figures and the
records are intact and arrive in full once the read completes — the page is
slow to render them, not missing them.
Workaround. Narrow the read before you load it. The Since / Until
and Subscriber ID filters are applied by the server, so a filtered view
returns promptly on any ledger size. Filtering to the period or the subscriber
you are actually reconciling is both faster and usually what you wanted.
Export CSV and Export JSON are also server-side and unaffected.
If you have a very large ledger and the page is unresponsive rather than merely
slow, prefer the exports, and prune the ledger on its normal schedule.
Billing is unaffected. The accounting drain, the stored records, the daily
usage totals and the exports all behave normally; this is a display path only.