QuantumTouch IPoE Community Edition · Alpha

The operator plane

One web front door to run the box — and prove what it did.

The management application over the headless BNG: it onboards a fresh box, harvests it every five seconds, and turns it into dashboards, audit, and snapshots.

5 sec
Sampler heartbeat
~65
Prometheus series
4
Audit sources merged
:8443
Single front door
Operator browser HTTPS :8443 · cookie + MFA / bearer QuantumTouch — the operator plane Web UI · sampler (5s heartbeat) · analytics store audit shipping · configuration snapshots Controller :3000 sessions · config · health VPP throughput BMC PSU · fans · temp Prometheus (loopback) scrapes :8443 /metrics → Grafana / Alertmanager Never touches a packet · if it's down, forwarding is unaffected

The one idea

It owns operator experience — not the forwarding path

The forwarding stack is deliberately headless: it forwards packets, runs the subscriber lifecycle, and speaks REST, but it has no human interface, no historical metrics, and no notion of an "operator." QuantumTouch is the layer that makes it operable.

It never touches a packet, never programs a session, never makes a routing decision. Every change it makes is a REST call to the controller; every number it shows is something it polled. That boundary is what makes it safe.

  • If QuantumTouch is slow, restarting, or down, subscriber traffic is completely unaffected
  • The bearer keys it minted keep working — the controller validates them independently
  • Its worst failure is a temporary loss of visibility, never a loss of service
Fail-open observability Controller unreachable no subscriber impact A bad sampler tick next tick recovers QuantumTouch restarts brief 502s only A state file is corrupted empty state, box fine Durable state (accounts, audit, snapshots) survives reinstalls.

What QuantumTouch does

Eight jobs, one management process

At operator altitude the operator plane has eight jobs. One process owns the operator state — the live history buffer, the sticky event feed, the audit shipper — which is what keeps them consistent.

Onboard a box

A first-run wizard walks a bare install to a forwarding BNG, gated by a one-time bootstrap token.

Harvest data

A single collector on a five-second heartbeat polls the controller, VPP, and hardware.

Present analytics

Real-time and historical throughput, session, and QoS-band charts, plus a Prometheus surface.

Drive configuration

Typed forms over every BNG resource, each change proxied with the operator's identity attached.

Ops dashboards

A single "is anything wrong, how loaded are we" view, plus health, hardware, and topology.

Audit & events

Four sources merged into one timeline, shipped off-box, distilled into a sticky event feed.

Protect config

Point-in-time snapshots across five domains, content-hashed, with a locked restore.

Authenticate

Session cookies with MFA for people, bearer keys with roles for machines.

The setup wizard

From bare install to forwarding BNG

A freshly installed box has a forwarding stack but no configuration and no operator accounts. The install prints a one-time bootstrap token; presenting it unlocks a single action — creating the first administrator. Once that admin exists, the token is spent. It's the only way to create the first account, and it closes the window in which a fresh box might be claimed by someone else on the network.

The wizard is guided and resumable — the whole draft auto-saves, so a browser refresh mid-wizard resumes where you left off. Each step gates Next behind a quick validity check.

Partial success is a first-class outcome.

The review step applies each section in order and shows a per-section ✓ / ✕ grid. A section that fails does not abort the rest — you fix the one thing rather than re-running everything.

One-time bootstrap token → first admin welcome platform dataplane plans pools auth [radius] captive tls review → apply radius step only if non-local Self-heal on first boot Seeds the DHCP punt path idempotently so unknown-subscriber Discovers always reach the controller — even after a config save.

How QuantumTouch sees the box

One heartbeat, three sources

A single data collector — the sampler — runs on a fixed five-second tick. It gathers sessions and config from the controller, derives live throughput straight from VPP, checks reachability probes, and publishes a fresh set of metrics. The whole tick is defensive: a momentary hiccup yields zeros for that tick, never a crash.

Why throughput comes straight from VPP

The controller's own counters refresh too slowly to drive a five-second chart, so the throughput harvester bypasses it and reads the data plane's interface and node counters directly, differencing them tick-over-tick. The parsers degrade gracefully — a wording change in a future VPP release makes a number go stale, not silently wrong.

Probes stay quiet when a feature is off

Each tick runs cheap liveness checks — RADIUS, uplink gateway (pinged from VPP), captive portal, service journal, hardware. A box with no RADIUS configured never alarms about RADIUS being unreachable. A stall detector compares downstream to upstream packet rates and flags only a sustained bad ratio under load.

What you're looking atRefresh cadence
Throughput / session / QoS charts5 s
Health & dashboard (one shared poll)5 s (+15 s grace)
Events feed5 s
VPP port statistics~7 s
Hardware / IPMI~10 s
Version / "about"~30 s
Historical charts (week / month)up to 60 s

No WebSocket push — five-second polling is the model throughout this release.

Analytics & observability

Evidence of what the box did, for two audiences

The same underlying data serves the QuantumTouch UI and your own monitoring stack. History is kept in memory at two resolutions — a fast buffer (5-second samples, ~1 hour deep) and a slow buffer (5-minute samples, ~30 days deep) — and a chart picks the resolution automatically from the span you asked for.

Throughput

Two stacked-area charts, up and down, bands stacked green → yellow → red on a shared scale, with packets-per-second as a dashed overlay.

QoS bands

A live proportion bar of green / yellow / red for the whole box this second, read straight from the current counters.

Sessions over time

Connected, captive, and offering counts against a moving window, with a reference line at the session ceiling.

A Prometheus surface for your stack

~65 aggregate metric series at /metrics (throughput, QoS bytes/packets, sessions by state, RADIUS reachability, port counters). Cardinality is kept deliberately aggregate — about five megabytes at thirty-day retention. Counter families are reset-aware: a source reset re-baselines and bumps a visible counter rather than emitting a nonsensical negative jump.

One-tick lag, by design

The sampler tick, the scrape interval, the chart's step, and the browser poll are all pinned to the same five seconds, so the only lag you see is one tick. An honest consequence: across an outage the charts show a real gap, not a flat line stretched over missing data.

Operations dashboards & health

One poll, one truth

Every health-consuming widget — the dashboard, the health page, the top-bar pills, the topology view, the hero verdict — reads from a single shared health poll. An earlier per-widget model let loops diverge, so a pill could show green while the dashboard showed the box down. Now they cannot disagree.

The shared poll refreshes every five seconds and holds the last good result through a fifteen-second grace window, so a single missed poll never flickers the whole dashboard red.

  • KPI row — provisioned / captive / in-flight sessions, RADIUS & VPP pills, orphan reconciliation
  • Pool pressure — per-pool utilisation, colored by the controller's ok / warn / full
  • Gauges — CPU, memory, workers, disk, RX/TX with their own thresholds
  • Topology — a live CPE → edge → BNG → core diagram whose flow freezes if the controller stalls
The one-glance verdict Healthy serving normally Degraded active events Fault critical event Monotonic under events — events can only make it worse and a plain-English reason names the concrete problem "Secondary RADIUS auth unreachable; 2 active events, 1 critical" reading why beats reading what

Audit, events & compliance

Two different things, built from overlapping data

Audit is the forensic record of what happened; the event feed is the live operational state of what is wrong right now. QuantumTouch assembles one searchable timeline by merging four independent sources on demand — queried in parallel, one failing source degrades to a marker, never a failed query.

QuantumTouch events

Config changes, exports, and lifecycle events it stamps itself.

Controller log

The forwarding stack's own record of REST changes.

System journal

The host's service logs for the BNG units.

Portal access

The captive-portal access log (opt-in).

Off-box shipping, built for stress

Ships its event log to syslog (RFC 5424 / 6587 over TCP/TLS), HTTP, or S3. At-least-once — each destination spools and retries with backoff until confirmed. Drop-oldest back-pressure — a full spool drops the oldest first, so the newest data still gets off-box. A slow destination can't stall the others; secrets are encrypted at rest.

A sticky event feed

Events are synthesized from current state on every read, then reconciled against a sticky history: a recovered fault flips to "RESOLVED — …", sorts to the top with its active duration, and stays visible until an operator acknowledges it. A flapping service re-fires onto the same incident rather than a storm of near-identical events.

Configuration & snapshots

Typed screens, and the defense against a config reset

Pools, plans, edge routers, RADIUS, captive portal, access interfaces, and NIC/driver selection each have a purpose-built form. Writable resources go to the controller through the proxy with your identity attached. The plan editor tells you exactly how many connected sessions a save will re-rate, and no-clobber drafts mean a background refresh never overwrites what you're typing.

Because the controller's config database is reset on every package upgrade, QuantumTouch keeps its own point-in-time snapshots across five domains — content-hashed, re-verified on read, and diffable field-by-field.

A local correction, handled for you.

The controller mis-counts pool occupancy on certain prefix sizes; QuantumTouch recomputes it locally from the true host count and live session addresses, so the utilisation bars are correct regardless of the controller's arithmetic.

Snapshot domainWhat it captures
QuantumTouch settingsThe operator-plane configuration
Controller configPools, plans, RADIUS, captive, uplinks, DNS
VPP startup configThe data-plane boot configuration
GRUB command lineKernel boot parameters
Sysctl / hugepagesHost memory tuning

Restore runs under an exclusive lock, restarts the data plane only if its config actually changed, and reports its outcome explicitly — fully applied, partial, or needs-a-deeper-reset. Exports are signed with a box-local key.

Security posture

QuantumTouch surfaces and stores; the platform enforces

Only :8443 (and the host's SSH) is legitimate external attack surface; the controller's :3000 should be firewalled to localhost with QuantumTouch's HTTPS as the intended front door.

PortServiceExposure
8443QuantumTouch web UIall interfaces · cookie+MFA / bearer
3000BNG controllerfirewall to localhost
9090Prometheusloopback only · scoped scraper key
8088Captive portal demodemo, plaintext

Three roles, reveal-once keys

Every key carries one of three roles — read-only, read-write, admin. A minted key's secret is shown exactly once behind an "I've copied this" gate; only a hash is stored, so a lost key is rotated, never recovered. Optional per-key IP allow-lists, path scopes, and expiries can be attached. The server-side role check is the real gate.

Secrets, TLS & webhooks

Secrets at rest are encrypted; passwords and keys are hashed; snapshot exports are signed. TLS is fully managed from the UI — import a PEM, keep a rollback history, or issue via in-product ACME. Signed security webhooks fire on failed-login bursts, admin grants, certificate expiry, and audit exports. For larger shops: SAML SSO and LDAP/AD with group-to-role mapping.

Scope & roadmap

Deliberate edges, and named next steps

Scope decisions are intentional edges of the operator plane — stable across releases. Caveats are specific to this Community-Edition Alpha, each with a defined path forward. The full operator experience — onboarding, harvesting, analytics, dashboards, audit, events, snapshots — is real and running today.

Product-line scope

  • Single-node operator plane — one process owns operator state for one box
  • Poll, don't push — REST + Prometheus; no WebSocket push, no NMS push
  • Aggregate-only metrics — per-subscriber detail stays in history & on-demand endpoints
  • One plugin per deploy — the single management plugin for a BNG

On the roadmap

  • Prometheus-first analytics store — in-memory history is the store today
  • Two metric families (bng_uplink_*, bng_access_*) report zero until a port-role map is populated
  • RADIUS / captive / pool UI writes — read cleanly today; a diff-to-apply modal covers the write for now
  • Full in-product ACME — configure-and-validate ships; automated DNS-01 is a later item

See the box, prove what it did

QuantumTouch ships with the Community Edition — the single-pane operator plane that makes a headless BNG operable, auditable, and recoverable.