Subscriber Edge on Commodity Servers
Broadband Gateway · CGNAT · QoS · Protection

Platform Capabilities · Complete Catalogue

Everything the Platform Does — and Whether It Is Switched On

This is the full BNGSOFT capability catalogue, organised by deployment model. It is written to a rule most capability lists do not follow: every entry states its delivery status. You will see which functions are running the moment the node is powered up, which are turned on during commissioning, which depend on the hardware in front of them, and which are not built yet. Nothing on this page is aspirational, and the sections at the end list what we deliberately do not claim.

A feature list that does not say what is on is a list of things you might one day get. This one distinguishes the two on every line, because the difference is the whole of an operator's first month.

deployment models,
from one software image

commodity server — no service
cards, no separate NAT appliance

traffic classes per subscriber,
independently rated per direction

health categories checked
continuously on every node

BNGSOFT is a subscriber-edge platform that runs on ordinary x86 servers. One software image provides three distinct deployment roles — a subscriber shaping gateway, a full subscriber gateway with carrier-grade address translation and firewalling, and a standalone translation node. The catalogue below covers every function in the product across all three, grouped by what an operator actually buys it to do.

How to read this document

Four labels are used, and they are used consistently. They are not marketing grades — they describe the state a capability is in when the node is delivered.

Active on delivery

Running with no configuration. Present and acting from the first packet, on every node of that deployment model.

Configured at commissioning

Complete and working; switched on during deployment. Real capability, delivered in the same image — it simply is not active until an engineer enables it for your network.

Conditional

Depends on something specific — the deployment model, the network-adapter family, or the attachment mode. The condition is stated in the same sentence, every time.

Roadmap

Not built. Listed once, in its own section at the end, so nobody mistakes an intention for a product. It never appears in the capability tables.

The short version of the honesty rule. Out of the box, the platform shapes every subscriber, protects interactive traffic, guards itself against upload abuse, and measures queueing latency. Nearly everything in the security and translation catalogue is complete, shipped in the same image, and switched on for you during commissioning — because turning a translation pool or a drop-enforcing filter on before we understand your network would be irresponsible, not impressive.

1 · How the platform is delivered

BNGSOFT is delivered as a complete appliance image for hardware of your choosing, not as a package to install on an existing distribution. The operating system, the tuned kernel and the forwarding engine ship together, are versioned together, and are supported as one unit. The forwarding engine depends on kernel capabilities that we build and maintain; it is deliberately not designed to be dropped onto a stock Linux install, and it will not load on one.

Say this plainly to your architecture team: you are buying an appliance that happens to run on a server you can source yourself, from any vendor, at any refresh cycle. You are not buying a userspace daemon to add to an existing fleet build. That is a constraint — and it is also the reason the forwarding plane can do what it does at the packet rates it does.

Two planes, one node

Control plane and forwarding plane

The control plane terminates subscriber sessions, speaks RADIUS and DHCP, and owns session lifecycle.
The forwarding plane runs in the kernel packet path and does the per-packet work: shaping, classification, protection, translation.
An internal session bus distributes the live session set from one to the other on the same node.

Entitlements

Licensed by capability

Twelve feature entitlements gate the major capability families; a capability is active only when both configured and licensed.
Licences are signature-verified and validated against a licence service, with a grace period so a connectivity failure does not take a node out of service.
On sustained failure the node degrades to subscriber shaping rather than stopping. Active on delivery

Upgrades

Zero-downtime software upgrade

Logic and daemon updates swap the forwarding program atomically, with no detach gap and no traffic loss. Active on delivery
Two honest conditions: a change to internal data structures forces a brief full restart, and the mechanism is unavailable where the adapter cannot support link-based attachment. Conditional
This is upgrade without traffic loss. It is not dual-supervisor ISSU, and we do not call it that.

2 · Deployment models

Three models exist. They are selected by configuration and licence, not by buying different products, and all three come from the same image. Which model a node runs determines which parts of the catalogue apply to it — so the model is the spine of this document.

The same image, three roles. Model B is the default configuration. A dashed band means the capability family is not present in that model — not that it is disabled.

MODEL A

Subscriber gateway

Sessions, shaping, latency management and edge protection. The node does not perform address translation and does not route in the forwarding plane.

Deployed where translation lives elsewhere, or is not needed at all
Smallest forwarding footprint of the three
Supported on the shipped appliance kernel Conditional

MODEL B · DEFAULT

Full data plane

Everything in Model A, plus carrier-grade address translation, the firewall rule engine, port forwarding, destination NAT, captive portal and IPv6 forwarding in the data plane.

One node performs gateway, translation and filtering
The configuration most operators deploy
Selected automatically when translation, firewalling or the walled garden is licensed and enabled

MODEL C

Standalone translation node

A translation appliance with no gateway role. Subscriber and session management are skipped entirely; the node translates, filters and reports.

For operators who already have a gateway and need translation capacity
Can also be enforced by the licence
Configured at commissioning

What a subscriber packet passes through

Order of operations at capability level. Stages 7 and 8 exist only where the deployment model includes them; in the subscriber-gateway model the packet leaves after stage 6.

The catalogue at a glance

The whole catalogue in one view. Nothing on the roadmap appears in this map — the dotted marker is defined here only so the vocabulary is complete.

3 · Subscriber access, AAA and session handling

Subscriber sessions are terminated by the control plane and handed to the forwarding plane over an internal session bus. Both halves ship in the same image and are supported as one product.

Capability	Delivery status	What it does, and what it does not
PPPoE termination and data plane	Active on delivery	Full session establishment, authentication and lifecycle in the control plane; header parse, strip and re-encapsulation in the forwarding plane. Both directions.
IPoE termination and data plane	Active on delivery	DHCP-driven subscriber sessions with address, ARP and link monitoring. In the forwarding plane an IPoE subscriber is simply one without a PPPoE header; the download path emits VLAN tags only.
RADIUS authentication and accounting	Active on delivery	Server groups, accounting start / interim / stop, and a published vendor dictionary carrying rate plans, per-class rate limits, per-class octet counters, off-peak boost schedules and connection limits.
Change-of-Authorisation and Disconnect-Message	Active on delivery	Mid-session rate changes and disconnects, applied through to the forwarding plane — a re-rate takes effect on the live session without tearing it down.
DHCPv4 server, with Option 82	Active on delivery	Agent circuit-ID and remote-ID parsing for subscriber identification at the access layer.
DHCPv4 relay	Configured at commissioning	Relay to an upstream server with retransmission, where the operator's address authority is external.
DHCPv6, router advertisements and prefix delegation	Active on delivery	Stateful addressing and IA_PD prefix delegation, including the case where the delegated prefix arrives after accounting start. The delegated prefix reaches the forwarding plane and is used for forwarding.
802.1Q VLAN and Q-in-Q	Active on delivery	Single and double tagging on ingress, with both tags restored on the download path. One documented constraint: for double-tagged frames direction is keyed on the inner customer VLAN, so an upstream VLAN must not collide with any subscriber VLAN ID. We check this at design review.
Per-VLAN statistics	Active on delivery	Traffic counted per VLAN as well as per subscriber.
Bonded interfaces with LACP awareness	Active on delivery	The forwarding plane resolves each bond to its active member and transmits directly, avoiding a per-packet re-parse. Up to eight bonds per node.
IPv6 unnumbered subscriber interfaces	Configured at commissioning	Installs the subscriber address as a device route rather than an interface address, with an IPv4 equivalent. Reduces per-session interface state on large nodes.
Session distribution to the forwarding plane	Active on delivery	The live session set is dumped to the forwarding plane on start and then updated by live event. This is session distribution within one node. It is not chassis redundancy: there is no peer-node state replication, no active/standby pair and no virtual-router failover, and we do not present it as high availability.

4 · Traffic management and quality of service

Shaping is the capability every subscriber touches on every packet, and it is the one that is fully active from the first second. Rates arrive from RADIUS as an upload/download pair and are enforced independently per direction and per traffic class.

Three shaping levelsLicensed global cap → VLAN-group aggregate → per-subscriber, per-class

Symmetric by designOne policer serves both directions, indexed by direction — no upload-only tier

Nine classesA default class plus eight the operator defines by destination prefix or port

Capability	Delivery status	What it does, and what it does not
Per-subscriber rate enforcement	Active on delivery	Committed-rate policing with a configurable burst allowance, applied per direction and per traffic class. Single-tier committed rate — we do not describe this as two-tier or dual-rate policing, because it is not.
Hierarchical shaping	Active on delivery	A genuine two-level aggregate hierarchy runs ahead of the subscriber policer: a licensed global cap, then a VLAN-group aggregate, then the subscriber. Group capacity is re-programmed automatically if entitlement changes.
Traffic classes and destination classification	Active on delivery	Nine classes: a default plus eight operator-defined. Classification is by exact destination port, then by longest-prefix match on IPv4 and IPv6 prefix lists. These are operator-defined buckets, not application categories — there is no deep packet inspection anywhere in the product.
Per-class rate plans from RADIUS	Active on delivery	Each class carries its own rate and its own octet counters, delivered and accounted per subscriber.
Burst	Active on delivery	A configurable burst factor with an operator-set byte ceiling, and a per-class override.
Per-subscriber off-peak boost	Active on delivery	A per-subscriber schedule delivered from RADIUS is evaluated unconditionally, even when the global schedule feature is not in use.
Global time-of-day schedule	Configured at commissioning	A node-wide schedule that multiplies with the per-subscriber schedule.
Peak-period congestion management	Configured at commissioning	Up to four defined periods, each with its own hours, capacity target, step-down percentage and floor. Reduces rates gracefully as a link approaches its target rather than letting queues build.
Per-VLAN static limits	Configured at commissioning	Up to 32 entries. Each becomes a synthetic subscriber and reuses the ordinary policer.
VLAN-group aggregate shaping	Configured at commissioning	Up to 64 groups. Present and enabled in the image; inert until an operator defines groups.
Runtime rate override	Active on delivery	An operator can change a live subscriber's rate from the management interface without a RADIUS round trip — useful for support and for testing.

5 · Latency and experience management

Rate control decides how much a subscriber gets. This group decides how it feels. It is also where the delivery-status distinction matters most, so read the statuses carefully — one of these is enforcing out of the box and the rest are opt-in.

The one thing enforcing on day one is Interactive Flow Protection. Queue-latency measurement is also on from the first packet, but it is measuring, not acting. Everything else in this section is switched on during commissioning. We would rather write that sentence than let you discover it during an evaluation.

Capability	Delivery status	What it does, and what it does not
Interactive Flow Protection	Active on delivery — enforcing	Identifies latency-sensitive packets — bare acknowledgements, connection setup, DNS, and optionally small packets and operator-chosen ports — and lets them through a token bucket that has bottomed out instead of tail-dropping them, and exempts them from early queue drop. This is the single capability that is acting on your traffic before anybody configures anything.
Queue-latency instrumentation	Active on delivery — observation only	A virtual-queue sojourn estimate is computed continuously per subscriber and per direction. In its delivered mode it measures and never marks or drops. Enforcement is a one-command change. We do not claim "active queue management on by default" without that qualifier.
Latency enforcement — probabilistic drop	Configured at commissioning	A CoDel-style linear drop-probability ramp above a sojourn threshold. There is no flow queueing and no per-flow scheduler, so we do not name CoDel, FQ-CoDel, PIE or RED as the algorithm — "CoDel-style" is the accurate description.
Congestion marking instead of dropping	Configured at commissioning	Under congestion the forwarding plane sets the IP congestion-experienced codepoint on ECN-capable flows rather than dropping them, in both IPv4 and IPv6, with correct incremental checksum handling, in both directions, and with RFC 9332 coupled probabilities available. This is congestion marking, not a complete L4S implementation: there is no separate low-latency queue, the two ECN-capable codepoints are not distinguished from one another, Accurate ECN is deliberately not implemented, and the shallow marking threshold is fixed rather than tunable. We describe what it does and stop there.
Flow Intelligence	Configured at commissioning	Passive per-flow loss and reorder detection in the forwarding path, heavy-flow identification, and optional demotion of a heavy flow — congestion-marked if it is ECN-capable, dropped if it is not — to protect latency-sensitive traffic. Loss detection covers IPv4 TCP flows. Each acting sub-behaviour is separately enabled. A userspace per-subscriber baseline and anomaly detector is available alongside it.
Quality-of-experience metrics	Configured at commissioning	Per-interface round-trip time, jitter, retransmission and reset counts collected in the forwarding path and aggregated every ten seconds into a score with health flags. Available through the CLI and the local management interface only — there is no collector or flow-record export path for these metrics. Loss figures additionally require Flow Intelligence to be enabled.
Autonomous Experience Controller	Configured at commissioning	A closed loop above the queue instrumentation. It scores each subscriber's experience, bands the subscriber base, and — in its acting mode, which is a second explicit switch — tunes the queue threshold within operator-set bounds, with regression detection and automatic revert. It steers existing controls; it is not itself in the packet path.
Per-subscriber responsiveness measurement	Configured at commissioning	Working-latency expressed as round-trips per minute, derived from the queue counters. It requires two switches, not one, and it is off until both are set.

6 · Carrier-grade address translation

Available in Model B and Model C. Translation is licensed and enabled per deployment; once enabled, a substantial set of behaviours within it are on by default because they are the healthy operating path.

Mapping

Three mapping behaviours

First-come-first-served — the delivered default; a subscriber's own source port is preserved wherever possible
Full cone — endpoint-independent mapping, the richest implementation, and the fallback path
Symmetric — per-destination mapping where policy requires it
Filtering per RFC 4787: endpoint-independent, address-dependent, or address-and-port-dependent

Allocation

Dynamic port blocks

A block pool allocates contiguous port ranges per subscriber, with a configurable ceiling on blocks per subscriber
Burst packing reduces hoarding when many subscribers arrive at once On
Graceful restart preserves allocated blocks across a software upgrade On
Separate, tighter allocation for the walled-garden pool

Lifecycle

Self-healing, not just aging

Pressure-adaptive reclaim tightens timeouts as the pool fills On
A periodic block reaper and an orphan-entry backstop sweep recover ports the ordinary path missed On
Table pressure triggers port reclamation directly from the forwarding path

Capability	Delivery status	What it does, and what it does not
Address translation, master switch	Configured at commissioning	Licensed and enabled per deployment, with pool, port range and mapping behaviour set for your address holdings.
Hairpinning	Active with translation	Two subscribers behind the same public address reach each other correctly, without leaving the node.
Flow-cache acceleration	Active with translation	Established flows take a shortened path. We publish no hit-rate figure, because the product does not measure one.
Port Control Protocol and NAT-PMP	Active in translation deployments	An on-node server implementing NAT-PMP (RFC 6886) and PCP (RFC 6887) map, peer and announce operations, with per-subscriber mapping quotas and lifetimes. Console and application traffic can request its own mapping instead of guessing.
Open-NAT promotion for gaming and real-time traffic	Active in translation deployments	Sessions that behave like game or real-time traffic are promoted to the mapping behaviour those applications need, automatically. Flow-aware timeouts observe by default and enforce on request.
Compliance logging — port-block allocation and release	Configured at commissioning	RFC 6888-style records over IPFIX (NetFlow v10) to up to three collectors, or syslog. One record when a subscriber's block is allocated, one when it is released — the compliance record a law-enforcement request is answered from. There is no file sink; export is to a collector or a syslog server.
Compliance logging — per-flow records	Configured at commissioning	A separate, higher-volume record family in its own observation domain, for operators whose regulator requires per-flow detail. Also covers IPv6 session records, public-IPv4 records and protocol-requested mappings.
Public-address reputation scoring	Active with translation — telemetry	Each public address in the pool is scored for reputation damage, and the scoring runs by default. It takes no action by itself. The observation half of steering also runs; automatic movement of subscribers off a damaged address, and the use of a penalty egress address, are available and ship disabled.
Reputation-based steering, acting	Configured at commissioning	Moves subscribers off a reputation-damaged public address automatically. Off unless enabled.
Per-subscriber translation counters and health	Active with translation	Allocation, drop and utilisation figures readable per subscriber, not just per pool — the difference between "the pool is fine" and "this customer is not".
TCP maximum-segment-size clamping	Configured at commissioning	Prevents path-MTU black holes on tunnelled or VLAN-carried upstreams, in both address families. Recommended on VLAN-carried translation deployments and set during commissioning.
Exempt destinations	Configured at commissioning	Destinations that bypass translation entirely — typically on-net services and settlement-free peers.
Standalone translation deployment	Configured at commissioning	Model C. Skips subscriber and session management entirely.

Scope note, stated up front. One translation pool per node. We do not offer deterministic, formula-derived port-block mapping, and we do not offer one-to-one carrier NAT as a mapping mode — where a fixed public address is required, destination NAT is the mechanism we use. These are boundaries of the product, not omissions from the page.

7 · Security and abuse containment

This section splits cleanly in two. A small number of protections defend the machine and the network unconditionally. Everything that can drop a customer's traffic is switched on deliberately, during commissioning, after we have seen what your network looks like.

ON FROM THE FIRST PACKET

Unconditional self-protection

Upload abuse protection — always on, with no enable key at all; the only control is a runtime stop switch
Built-in control-plane guards for management, name-service and monitoring traffic to the node itself
Interactive Flow Protection — enforcing, as described in section 5
Forwarding-plane packet capture, armed at runtime
Enforcement decision log — a bounded record of enforcement state changes

ENABLED DURING COMMISSIONING

Everything that can drop customer traffic

Inbound flood protection
Source-address validation in enforcing mode
The firewall rule engine
Outbound abuse containment and quarantine
Connection-rate limiting
Per-subscriber threat correlation, acting

Capability	Delivery status	What it does, and what it does not
Upload abuse protection	Active on delivery	Always-on machine self-protection against outbound abuse patterns in the upload direction. There is no configuration key to enable it; it is simply present. Operator allow and deny lists are supported alongside it.
Coordinated protection switch	Configured at commissioning	A single mode — off, monitor or enforce — that derives sensible settings across flood protection, quarantine, scanner detection and outbound flood detection for any domain the operator has not set explicitly. This is the recommended way to turn the security suite on, and it is the one place where enabling one thing enables several.
Inbound flood protection	Configured at commissioning	Per-subscriber, per-attack-vector detection of inbound floods, with traffic above the per-vector threshold rate-capped immediately on detection rather than after an escalation delay. A carpet-bomb detector covers aggregate attacks spread thinly across many subscribers, and solicited traffic is spared. We describe this as per-subscriber, per-vector flood detection and rate-capping. We do not describe it as a graduated monitor / limit / block ladder, because the middle rung has no effect in the data plane and the promotion to a blocking state does not converge reliably for most vectors. The capping is real; the ladder is not, and we will not sell you the ladder.
Fragment-flood shield	Ships with flood protection	The one part of the escalation path that does converge, because it deliberately bypasses the sustained-detection counter. Effective against fragment floods specifically.
Adaptive per-victim baseline	Configured at commissioning	Learns a per-subscriber normal and detects departures from it, rather than relying on a single fleet-wide threshold.
Source-address validation (BCP 38)	Configured at commissioning	Validates upload source addresses against the subscriber table and an operator allow-list, in observation or enforcing mode. IPv4 enforcement drops; IPv6 stays in observation unless explicitly enabled, because a subscriber with a delegated prefix can legitimately source from an address that is not the exact table key. A safety interlock holds a configured enforcement in observation until the node's interfaces are stable and the subscriber table has loaded, so a restart cannot black-hole customers.
Firewall rule engine	Configured at commissioning	Chained rules matching IPv4 and IPv6 source and destination, port range and protocol, with actions to pass, drop, return, jump and destination-NAT, and a hit counter on every rule. Up to 64 rules per chain. Scope to state clearly: rules are enforced on IPv4 in both directions, and on IPv6 in the inbound direction. Default-deny is expressed with explicit rules.
Node control-plane rate limiting	Configured at commissioning	Per-class caps on traffic addressed to the node itself — management, name service, monitoring, time, routing, authentication and the remainder. Built-in guards for management, monitoring and name-service traffic are on by default; the fuller per-class limiter is configured.
Outbound abuse containment	Configured at commissioning	Three independent detectors — volumetric quarantine, scanner fan-out, and outbound flood — each with its own observation and enforcement switch, a shared sticky quarantine hold and an automatic release. Contains a compromised customer without a truck roll.
Per-subscriber threat correlation	Configured at commissioning	Correlates signals across the detectors into a per-subscriber threat tier every couple of seconds. On a node with the security suite off, this does nothing at all — by design. Acting on the tier requires the coordinated switch in enforcing mode.
Connection-rate limiting	Configured at commissioning	Per-subscriber connection-rate ceilings delivered from RADIUS, for detecting connection-sharing and abusive clients. Known accuracy gap: where IPv6 flow keys collide, the colliding connections are not counted.
Captive portal and walled garden	Configured at commissioning	Inactive subscribers reach a portal and an allow-list only, translated through a separate, deliberately small address pool. Model B.
DNS redirection, domain blocking, site and domain NAT, ICMP redirection, SIP blocking	Configured at commissioning	Policy redirection and blocking mechanisms, each enabled and populated per deployment. An empty list is a silent no-op, so these are configured with content or not at all. SIP handling is a block capability — the product contains no SIP application-layer gateway, no SDP rewriting and no media pinholing, and we never describe it as an ALG.
Port forwarding	Conditional — Model B only	Bidirectional, direction-aware forwarding of an inbound port to a subscriber behind translation. Requires the full data-plane model; it is unavailable on a subscriber-gateway node.
Static / one-to-one destination NAT	Conditional — Model B only	A fixed public address mapped to a fixed subscriber address. Same model requirement as port forwarding.
Forwarding-plane packet capture	Active on delivery	Captures at the forwarding-plane level, filtered by interface, direction, protocol, port and source address, with a configurable snap length. It sees packets and verdicts that a conventional capture on the host cannot — this is the tool that ends arguments about whether a packet was dropped and by what.
Enforcement decision log	Active on delivery	A bounded in-memory ring of enforcement state transitions, served over the local management interface. It is a record of decisions, not a packet log, and it is not attributed to an attacker.

8 · IPv6

IPv6 is not an add-on module in this product. Subscriber resolution, forwarding, shaping and accounting all handle both families, and the delegated prefix is a first-class object in the forwarding plane rather than something the kernel is left to work out.

Capability	Delivery status	What it does, and what it does not
Dual-stack subscriber resolution	Active on delivery	A subscriber is resolved from its transport address or from anywhere inside its delegated prefix, using a longest-prefix structure sized for a large subscriber base, with a fast path for the common prefix length.
Prefix delegation in the forwarding plane	Active on delivery	Delegated prefixes — including shorter prefixes than the common case — are stored with their true length and forwarded on. A shorter prefix takes the general lookup rather than the fast path; correctness is unaffected.
IPv6 forwarding in the data plane	Conditional — Model B	Upload and download IPv6 forwarding with encapsulation handling and next-hop resolution from the node's routing table. The subscriber-gateway model does not route in the forwarding plane.
IPv6 shaping and accounting	Active on delivery	Both directions shaped, with IPv4 and IPv6 volumes counted separately so a dual-stack subscriber's bill and usage view are correct.
IPv6 flood protection	Ships with flood protection	Detection covers IPv6 and public IPv4 under one policy when flood protection is enabled.
IPv6 path-MTU clamping	Configured at commissioning	Implemented in both directions. It is not applied unless configured, so it is set during commissioning on deployments that need it.
IPv6 source-address validation	Conditional — observation unless enabled	See section 7. IPv6 remains in observation even when IPv4 is enforcing, unless the operator explicitly enables IPv6 dropping.
IPv6 firewall	Conditional — inbound direction	Firewall rules match full 128-bit source and destination and are enforced on IPv6 inbound. Upload-direction IPv6 rules are not enforced in the forwarding path. We state this rather than writing "IPv6 firewall" unqualified.

IPv6 transition — available for evaluation, not deployed. MAP-E, MAP-T and NAT64 are fully implemented and wired end to end in the shipping image, selected by the translation-engine setting. They have never been deployed in production and there is no field-validation evidence for them, and a defect in the return path was corrected recently enough that we treat the feature as unproven. We will make them available for evaluation and will say honestly when that changes. Selecting one of them means the node is not running stateful carrier-grade translation — they are mutually exclusive. NAT64 additionally requires a customer-supplied DNS64 resolver; the product does not contain one.

9 · Visibility, health and operations

This group is where a software subscriber edge either earns its keep or becomes a liability, so nearly all of it is active on delivery. It is designed around one principle: the node should tell you it is unwell before a customer does.

Capability	Delivery status	What it does, and what it does not
Continuous health engine	Active on delivery	Eleven categories checked on every node: entitlement, authentication and subscriber counts, data path, translation, platform, interfaces and links, adapter ring health, upstream reachability, experience metrics, quality-of-service and queueing, edge security, and hardware and time. All thresholds have working defaults; the configuration section is optional.
Learned, seasonal baselines	Active on delivery	Seven metrics tracked across 168 hour-of-week buckets, so "high for a Tuesday at 21:00" is distinguished from "high". Persisted across restarts.
Active health probes	Active on delivery	Disclosed openly: these make outbound name-resolution and HTTPS requests from the node to a well-known public endpoint to distinguish "our upstream is broken" from "the internet is broken". Some operators will want them off; they are a single setting.
Service-level objectives and error budget	Active on delivery	Four indicators tracked over 1-hour, 6-hour, 24-hour and 30-day burn-rate windows against a configurable target, persisted across restarts. The responsiveness indicator is skipped unless the optional responsiveness measurement in section 5 is enabled; the model degrades gracefully rather than failing.
Saturation and headroom reporting	Active on delivery	Six resources sampled each minute, with warning and failure thresholds. Two honest limits: the processor figure is the management process's own consumption, not box-wide or per-core; and two of the six are estimates rather than exact counts.
Capacity history	Active on delivery	Daily peaks retained on the node, so a capacity conversation starts from recorded history rather than from the last thing anybody happened to look at.
Local management interface	Active on delivery	Newline-delimited JSON over a local socket — configuration read and write, schema discovery, reload, status, statistics, metrics, self-test, the enforcement log, live rate override, translation controls and the security toggles. It is not HTTP, not TCP and not network-exposed, and it serves one client at a time. We do not call it a REST API.
Metrics export	Active on delivery	A JSON metrics file, rewritten atomically on a fixed interval, read by your collector agent. It is not a Prometheus endpoint, and we do not describe it as one. Statistics are otherwise read live from the data plane rather than written to per-interface files.
Start-up self-test	Active on delivery	Runs before the node carries traffic and on demand. Four groups of checks, including one that catches the failure mode nobody else catches: the forwarding plane silently attaching in a slower compatibility mode instead of the fast mode requested. A node that quietly halved its own throughput is a genuinely common outage cause and this finds it in seconds.
Host tuning — interrupts, cores and receive-side scaling	Active on delivery	Automatic interrupt distribution and queue-zero spreading, with per-driver handling across the common server adapter families. Receive-side scaling capability is detected and hashing configured; the indirection table itself is reported rather than rewritten.
Threaded receive processing	Conditional — one adapter family	A targeted fix for one Intel 10-Gigabit adapter family whose access-protocol traffic cannot be steered across queues. It is not a general optimisation — on a different adapter family it measurably increases processor use, so it is applied only where it is the right answer.
Configuration validation	Active on delivery	Configuration is schema-discoverable and validated, so a mistyped key is caught rather than silently ignored.

10 · Routing integration

The precise, honest statement. The appliance runs standard open-source routing software — BGP, OSPF and IS-IS — on the same node as the subscriber data plane, and the forwarding plane resolves next hops from the kernel routing table. Routes learned by that routing software therefore influence how the forwarding plane forwards. That is a routing-integration statement about the platform, not a border-router product claim. The data plane is subscriber-oriented: it resolves a subscriber, shapes, protects, translates and delivers. It is not a general IP transit forwarding engine, and in the subscriber-gateway model it performs no route lookups at all.

If what you need is a border router, that is a different product and it is on the roadmap below — it is not a repositioning of what exists today. Being clear about this at the start of an evaluation is cheaper for both of us than being clear about it at the end.

11 · Where the platform stands against other vendors

The matrix below compares published vendor documentation at a single research date. It is built to a rule: no cell is filled from memory or recollection. Where a vendor's documentation does not discuss a capability, that is recorded as silence in a named document — it is never reported as absence. Where a competitor is genuinely ahead, that is stated in the same table and again in the concessions block underneath.

Two things to read before the table. (1) Nokia and Cisco chassis platforms carry routing depth and system scale — IS-IS, MPLS, segment routing, EVPN, redundant control modules, multi-terabit chassis — that an x86 subscriber-edge appliance does not, and netElastic's datasheet lists a fuller routing and MPLS stack than we ship. Any table that hides this is rigged, so it is the last row. (2) No vendor examined here publishes throughput measured with per-subscriber quality of service enabled, so this comparison carries no throughput column at all. Comparing a lab packet-forwarding figure to a production figure with subscriber shaping active would be dishonest in either direction.

The forwarding plane is where subscriber packets are actually moved. The structural distinction that matters more than any feature row: in the disaggregated architectures, the part that runs on general-purpose hardware is the control plane. This is why we do not claim that running on commodity servers is unique to us. Each row reflects that vendor's own published documentation at the research date.

Capability area	BNGSOFT	netElastic vBNG	MikroTik RouterOS	Nokia 7750 SR / SR OS	Cisco ASR 9000 / cnBNG
Where the forwarding plane runs	Commodity x86 server, in-kernel packet path. Delivered as an appliance image.	x86 server, userspace fast path; "can run in a VM or on dedicated bare metal hardware".netElastic solutions page; Intel Network Builders brief 338405-001US (Nov 2018)	General-purpose router OS on MikroTik hardware or x86. No product is branded "BNG".help.mikrotik.com PPPoE page — "access concentrator"	Chassis line cards; also a virtualised router "optimized for x86 server deployment", "deployable as a VNF or CNF".Nokia VSR asset, onestore.nokia.com/asset/182483 (partial load)	cnBNG control plane on Kubernetes; "The UP can be on any of the physical platforms that supports the BNG UP, like Cisco ASR 9000". A VM-based vBNG on UCS is also documented.cnBNG CP Config Guide 2025.01 — archive snapshot 20260517130004
Reduced deployment roles	Three roles from one image: subscriber gateway, full data plane, standalone translation.	Standalone CGNAT SKUs "Upgradable to full BNG"; CGNAT optional on BNG tiers. A QoS-only role is not described.netelastic.com/products/packages/	Not applicable — role is a matter of which features are configured.No "BNG" product category documented	"All SR OS platforms can simultaneously act as a UP and as a standalone BNG." A QoS-only role is not described in the pages retrieved.MAG-c 23.10 value propositions	Physical BNG, VM-based vBNG, and cnBNG with a separated control plane.cnBNG overview — archive snapshot 20260517130004
Per-subscriber QoS and hierarchical shaping	Global cap → VLAN group → per-subscriber, per-class, both directions. Single-tier committed-rate policing with burst. Nine classes.	Datasheet lists "Hierarchical Policing" and "QoS/HQoS: 8 services/user"; the June 2021 configuration guide states that "because of the high memory cost in implementing queues in software, vBNG is currently only supporting priority queues QoS on interfaces", with subscribers receiving rate limiting.© 2019 datasheet (Winncom mirror); vBNG Service Config Guide v1.11, June 2021 (Splynx mirror)	Genuinely strong. Hierarchical Token Bucket with documented parent/child arithmetic, PCQ, per-subscriber RADIUS rate limits and CoA re-rating.help.mikrotik.com HTB, Queues and RADIUS pages	Deepest here — concede it. On the High Scale QoS IOM: "a seven-tier shaping hierarchy with six levels of scheduling"; subscriber queues "always allocated in a set of eight queues per SLA profile instance". Three tiers of virtual schedulers on standard cards.SR OS 26.7 ESM High Scale QoS IOM; SR OS 24.3 scheduler QoS policies	"two-level hierarchical policy (parent policy and child policy)", parameterised QoS from RADIUS. Cisco's own restrictions: "only 7 class-maps", and "Subscriber QoS is not supported on low-queue (-TR) variants" of 5th-gen line cards.ASR 9000 BNG Config Guide 7.11.x — archive snapshot 20250708193900
Queue-latency management at the subscriber edge	Virtual-queue sojourn measurement per subscriber, on by default in observation; CoDel-style probabilistic drop as an opt-in. No flow queueing and no per-flow scheduler.	L4S, DualQ, ECN, CoDel, WRED and AQM all appear zero times across three retrieved documents. Strict-priority plus weighted-fair queueing is what is documented.Config Guide v1.11 (2021), datasheet (© 2019), Intel brief (2018)	Broadest AQM menu here — concede it. RouterOS documents RED, SFQ, CoDel, FQ_CoDel and CAKE as selectable queue types, describing CAKE as combining "CoDel, FQ, and other technologies".help.mikrotik.com Queue types page, re-verified 2026-08-03	Real per-subscriber AQM: "WRED per queue is supported for SAP egress QoS policy queues (and therefore to egress SAP and subscriber queues)". WRED appears 46 times in the QoS guide.SR OS QoS Guide 25.7.R1	WRED, DSCP-based and precedence-based, per subscriber.ASR 9000 BNG Config Guide 7.11.x — archive snapshot 20250708193900
Congestion marking (L4S / RFC 9332 coupling)	Sets the congestion-experienced codepoint on ECN-capable flows in IPv4 and IPv6, both directions, with RFC 9332 coupled probabilities. Enabled per deployment. Not a full L4S implementation — no second queue, no ECT(1) distinction, no Accurate ECN.	L4S, DualQ and ECN each appear zero times in all three retrieved documents.Config Guide v1.11 (2021), datasheet (© 2019), Intel brief (2018)	Zero occurrences of L4S, DualQ or ECN on the Queue types page. Single-page silence — the weakest evidence grade on this table, and we make no MikroTik L4S claim.help.mikrotik.com Queue types page only	Nokia Bell Labs pioneered L4S and shipped it first in Nokia Wi-Fi Beacons; Nokia and Vodafone demonstrated end-to-end L4S over PON in a Newbury lab trial (April 2024) whose chain included a BNG. Nokia's own white paper describes the BNG's role as identifying and prioritising L4S traffic "without having to discriminate on a per-user basis or apply ECN marking". L4S, DualQ and ECN appear zero times in the SR OS QoS Guide across releases 25.7 and 26.7.Nokia L4S white papers; Nokia/Vodafone press release 3 Apr 2024; SR OS QoS Guide 25.7 & 26.7 — re-verified 2026-08-03	L4S, DualQ and ECN each appear zero times in the BNG QoS chapter. Scoped to that chapter only — the general congestion-management guide could not be retrieved, so ECN could be documented elsewhere.ASR 9000 BNG Config Guide 7.11.x — archive snapshot 20250708193900
Carrier-grade NAT — allocation model	Dynamic port-block allocation with burst packing, adaptive reclaim and block preservation across upgrade. Full-cone, symmetric and first-come-first-served mapping; RFC 4787 filtering. One pool per node. No deterministic mapping.	Full-cone mode plus an "SPR" port-range reservation giving endpoint-independent mapping and filtering, within which "User's public IP won't change", with configurable extension. The word "deterministic" appears zero times in the 109-page guide.vBNG Service Config Guide v1.11, June 2021	Endpoint-independent NAT documented. Deterministic mapping is presented as RFC background with the note "it is suggested to use a script instead" — not as a named feature.help.mikrotik.com NAT page	Ahead of us — concede it. "Each subscriber is permanently mapped to an outside IP and a dedicated port block… Logging is not needed as the reverse mapping can be obtained using a known formula", with dynamic extension when the block is exhausted. These NAT functions run on an MS-ISA2, MS-ISM or external ESA appliance, not the base line card.SR OS 22.10 MS-ISA/ESA NAT; SR OS 24.10 ISA/ESA hardware — re-verified 2026-08-03	RFC 7422 sequential allocation with endpoint-independent mapping and filtering, on the A9K-VSM-500 service card; bulk port allocation is rejected in that mode. The guide states "A9K-VSM-500 is not supported on Cisco IOS XR 64-bit image". Verified for release 6.5.x only; currency into 7.x not verified.ASR 9000 CGNAT Config Guide 6.5.x — archive snapshot 20250310074242
Translation compliance logging	Port-block allocation and release records, and optional per-flow records, over IPFIX to up to three collectors or over syslog. No file sink.	"vBNG logs the session creation and deletion activities of all NAT sessions", to external syslog servers or a local file — i.e. per-session logging.vBNG Service Config Guide v1.11, June 2021	NAT-rule logging is not documented in the action list on the NAT page.help.mikrotik.com NAT page	Port-range blocks reduce logging: "a single log entry is created when the first mapping is created for a subscriber and a final log entry when the last mapping is destroyed… This can reduce the number of log entries by 5000x or more." IPFIX flow logging documented; the exported element list was not visible on the page retrieved.SR OS 22.10 MS-ISA/ESA NAT; 7750 SR 22.7 IPFIX flow logging	Not retrieved in this pass.cisco.com unreachable; not sourced
Stateful firewall at the subscriber edge	Chained rule engine, IPv4 both directions and IPv6 inbound, with per-rule counters. Up to 64 rules per chain. Not a per-flow stateful inspection firewall.	ACLs — up to 1000 groups of 4000 rules — matching L2/L3/L4 headers. The word "firewall" appears zero times in the 109-page guide and zero times in the datasheet.vBNG Service Config Guide v1.11, June 2021; © 2019 datasheet	Ahead of us — concede it. A genuine connection-tracking stateful firewall with established / new / related / untracked matchers.help.mikrotik.com Connection tracking and Firewall matchers pages	Ahead of us — concede it. A per-subscriber Residential Firewall: "Only inbound traffic that matches flows that originated inside of the home is allowed to pass through", linked to the subscriber profile; plus an Application Assurance stateful firewall with a documented BNG deployment scenario. Both run on ISA/ESA cards.SR OS 22.10 Residential Firewall; 7750 SR 22.5 Application Assurance	Per-subscriber ACLs are documented. A subscriber-edge stateful inspection firewall is not described in the BNG overview and subscriber-features chapters retrieved. Note: "stateful switchover" in Cisco's feature list is a high-availability mechanism, not a firewall.ASR 9000 BNG guides — archive snapshots 20210415080903, 20250316042946
Subscriber-facing DDoS detection and mitigation	Per-subscriber, per-vector inbound flood detection with immediate rate-capping, a carpet-bomb aggregate detector and a fragment shield, in the base product. Enabled per deployment. Not a graduated monitor/limit/block ladder.	DDoS, attack, flood, protect and blacklist each appear zero times in the 109-page guide; DDoS appears zero times in the datasheet and zero times in the Intel brief. Silence across three vendor-authored documents, the strongest silence finding here — and still silence, not absence.Config Guide v1.11 (2021), datasheet (© 2019), Intel brief (2018)	Documented as manually configured, static-threshold mitigation — RAW-table bypass, destination limits, TCP syncookies — with MikroTik's own caveat that "these rules are only an improvement for firewall". Automatic detection is not documented on that page.help.mikrotik.com Filter and DDoS Protection pages	On-box Distributed CPU Protection "protects the CPU of the node that it is configured on"; its protocol list is control-plane protocols. Subscriber-facing volumetric DDoS is documented as Deepfield Defender, a separate product.SR OS System Management security; 7750 SR 22.2 DCP; Deepfield Defender solution sheet	Subscriber-facing volumetric flood detection could not be established in this pass — the archived guides describe control-packet punt policing rather than subscriber traffic-flood detection, and the current release state of that mechanism could not be resolved across the snapshots available, so no position on it is published here. One adjacent statement is unambiguous: "Flowspec is not supported on subscriber interfaces."ASR 9000 BGP FlowSpec guide 7.11.x — archive snapshot 20260110002854
Source-address validation	Subscriber-table validation with an operator allow-list, in observation or enforcing mode, with an arming interlock so a restart cannot black-hole customers. IPv4 enforces; IPv6 observes unless explicitly enabled.	uRPF, RPF, "reverse path" and "spoof" each appear zero times in the guide and datasheet. ACLs can restrict source prefixes, so this is a naming silence, not an inability.vBNG Service Config Guide v1.11; © 2019 datasheet	Strict and loose reverse-path filtering per RFC 3704, with the documented default "no" — i.e. opt-in — and a documented caveat that strict mode "does not work with routing tables".help.mikrotik.com IP Settings page	Ahead of us, and native — concede it. uRPF strict and loose; IPv6 ESM strict mode additionally checks the packet would route back out "the same SAP it was received on"; MAC, IP and IP+MAC anti-spoof filters "populated from the DHCP lease state table". No service card required.7750 SR 22.2 uRPF; 22.5 subscriber uRPF; Triple Play security guide	uRPF for PPPoE and IPoE subscribers, "supported on both IPv4 and IPv6 subscribers", enabled by dynamic template. Verified for 6.5.x; currency not verified.ASR 9000 BNG Config Guide 6.5.x — archive snapshot 20210415080903
Flow export carrying subscriber context	Translation records over IPFIX or syslog identify the inside subscriber address, the assigned public address and the port block. There is no general-purpose subscriber flow export beyond the translation records, and quality-of-experience metrics have no collector export at all.	"Full IPv6 flow visibility through IPfix flow export and RADIUS accounting" (Feb 2026). No template or field list was found, and the article does not state that the record carries a subscriber identity — we assert nothing either way.netelastic.com IPv6 best-practices article, 19 Feb 2026	NetFlow v9 / IPFIX with a documented field set that includes addresses, ports, interfaces, MACs and NAT fields. No subscriber-identity field appears in that list.help.mikrotik.com Traffic Flow page — field list pending raw re-verification	cflowd v9/IPFIX documented. Subscriber identity exists as a first-class concept elsewhere in SR OS, but a subscriber-identity element in base cflowd export is not documented at the two pages checked. NAT-specific IPFIX logging is a separate mechanism.SR OS cflowd introduction; SR OS 25.3 subscriber management	Explicit non-support: "Netflow is not supported on BNG subscriber." IPFIX is otherwise supported, ingress only, on third-, fourth- and fifth-generation line cards.ASR 9000 NetFlow Config Guide 7.11.x — archive snapshot 20240119111933, re-verified 2026-08-03
IPv6 dual-stack and prefix delegation	Dual-stack subscriber resolution from transport address or delegated prefix, prefix delegation in the forwarding plane, separate IPv4/IPv6 accounting, both directions shaped.	Dual-stack, SLAAC, DHCPv6 IA_NA and IA_PD; three pool types; claims "IPv6 forwarding can be implemented without any performance loss compared with IPv4".netelastic.com IPv6 article (Feb 2026); Config Guide v1.11 §6.10	"IPv6 Prefixes can be delegated over PPP interfaces", with a dynamic DHCPv6-PD server created per session.help.mikrotik.com IPv6 PD over PPP page	Prefix delegation per RFC 3633 "supported for the delegating router"; SLAAC; PPPoE dual stack creating "one subscriber host … for IPv4 and another one for the IPv6 address family".7750 SR 22.5 DHCPv6 PD; SR OS 22.10.3 SLAAC; ACG 24.3.2 dual-stack hosts	"By default, the prefix delegation feature is always enabled." In dual-stack, "two separate sessions are created on BNG — one for IPv4 and another for IPv6".ASR 9000 BNG Config Guide 7.6.x — archive snapshot 20221003055534
Software upgrade without traffic loss	Atomic forwarding-program swap with no detach gap for logic updates. A data-structure change forces a brief restart, and the mechanism is unavailable where link-based attachment is not.	ISSU, hitless and in-service each appear zero times in the guide and datasheet. The documented answer is redundancy: "Control Plane Hot Standby", "Data Plane Warm Standby", "Full N+1 Redundancy".© 2019 datasheet; Config Guide v1.11	Every documented upgrade path requires a reboot — "manual device reboot is required".help.mikrotik.com Upgrading and installation page	ISSU exists; the only ISSU statement located is scoped to "dual CPM systems", implying redundant control modules as a prerequisite. A full limitations chapter was not located and none is claimed here.SR OS 24.3 system initialisation; SR OS 26.3 CPM redundancy	Explicit non-support: ISSU is listed under "Unsupported Features on Cisco IOS XR 64-bit BNG", in two releases. Platform-wide, ISSU is "not supported on the ASR 9000 fourth generation line cards and fifth generation line cards" nor "on the single RP system of ASR 9901, ASR 9902, and ASR 9903".ASR 9000 BNG Config Guide 7.11.x — snapshot 20250316042946, re-verified; ISSU guide 7.9.x — snapshot 20250327203409
Routing depth	Behind everyone here — concede it. Standard open-source routing runs alongside the data plane and the data plane honours the kernel routing table. There is no MPLS, no segment routing, no EVPN and no multicast routing in this product.	Datasheet lists OSPFv2/v3, IS-IS, MP-BGP, MPLS LER/LSR/LDP, L2VPN VPWS/VPLS, L3VPN, plus IGMP v1/v2/v3, PIM-SM and PIM-SSM.© 2019 datasheet (Winncom mirror); Intel brief	MPLS with LDP; EVPN scoped to VXLAN only; IS-IS documented by configuration example.help.mikrotik.com MPLS, EVPN and IS-IS pages	Full suite including SR-MPLS and SRv6, EVPN and multicast, with Nokia's own caveat directing readers to the per-platform unsupported-feature list.SR OS 25.3 documentation suite; SR OS 23.10.1 segment routing	SRv6 with micro-SIDs, SRv6 traffic engineering, IS-IS Flexible Algorithm and TI-LFA, referencing RFC 8986.ASR 9000 SRv6 guide 7.9.x — archive snapshot 20260209090111

Cisco cells — read this. Cisco's documentation site was not reachable from the research environment at the research date. Every Cisco entry above comes from a dated Internet Archive snapshot, and each snapshot timestamp is printed in the cell. An archive snapshot proves Cisco published that sentence at that moment; it does not prove it is Cisco's current documentation. These entries are pending confirmation against the live canonical pages, and should be treated as archive-sourced until that check is done. Where a Cisco quote is scoped to a specific release — notably the 6.5.x CGNAT and uRPF entries — the release is stated in the cell and currency into later releases has not been verified.

CONCESSIONS

Where a competitor is ahead

Nokia — per-subscriber queueing depth on the High Scale QoS card; deterministic port-block NAT with formula-derived reverse mapping and a quantified logging reduction; a per-subscriber stateful residential firewall; native anti-spoofing depth; per-queue WRED; and Bell Labs' authorship of L4S itself
MikroTik — the broadest documented modern AQM menu (CoDel, FQ_CoDel, CAKE) and a full connection-tracking stateful firewall
netElastic — a fuller routing, MPLS and multicast stack than we ship
Nokia, Cisco, Juniper, netElastic — documented control/user-plane separation to BBF TR-459; we do not implement CUPS
Nokia and Cisco — chassis routing depth and system scale we do not attempt

JUNIPER — LIGHT PASS

Sourced on architecture only

Juniper was a deliberately narrow pass in this research and appears here rather than in the matrix, because only its deployment architecture was retrieved.

The BNG CUPS Controller is "a cloud-native application" that runs "on a Kubernetes cluster", forming a disaggregated BNG with "Juniper routing devices" as user planes, up to 32 of them
The documented Kubernetes minimum is three control-plane nodes and three worker nodes — six machines before any user plane. Stated neutrally: it is a documented requirement, not a criticism
Per-subscriber QoS, CGNAT, firewall, DDoS, AQM, source validation, flow export, IPv6 and upgrade behaviour were not researched for Juniper and no claim is made about any of them

The structural point worth more than any single row. In the Cisco, Juniper and Nokia CUPS architectures, the part that runs on commodity x86 is the control plane. The forwarding plane remains vendor routing hardware. That is a real, sourced architectural distinction from a platform that forwards subscriber traffic on an x86 server — and it is far more defensible than any feature checkbox. It is also why "nobody else runs on commodity x86" is a claim we do not make: Nokia's virtualised router is documented as x86-deployable, and Cisco documents a VM-based user plane on UCS.

12 · Roadmap — designed or requested, not built

Everything in this section is unbuilt. It appears nowhere else on this page, it is not in the matrix above, and it must not be read as a capability. It is here so that a question asked in a meeting gets the same answer it would get from an engineer.

Item	Status	Where it actually stands
Border-router role	Roadmap	There is no border-router deployment model, no such configuration, and no implementation. What exists today is the routing integration described in section 10. Delivering a border-router product would require new work, not a repositioning of the current data plane.
Attacker attribution in the enforcement record	Roadmap	The enforcement log records state transitions. Capturing the attacking flow's full five-tuple alongside them is designed and deliberately not implemented.
Multi-vector anomaly scoring at layer 2	Roadmap	Designed. Not implemented.
Field-proven IPv6 transition (MAP-E / MAP-T / NAT64)	Available for evaluation	Implemented and shipping in the image, never deployed in production. Listed here rather than in the IPv6 catalogue so that the distinction between "built" and "proven" stays visible. See section 8.

13 · What we do not claim

A capability list is only as trustworthy as the things it leaves out. These are the claims a reader might reasonably expect on a page like this, and which are deliberately absent.

Not claimed	Why not	What is true instead
Traffic policy by application category	No deep packet inspection and no protocol identification exist in the product, at any layer.	Destination-prefix and port-defined traffic classes, with independent rate and burst policy per class and per direction.
Deterministic / RFC 7422 port-block allocation	Not a supported allocation mode.	Dynamic port-block allocation with burst packing, adaptive reclaim and preservation across upgrade — and full allocation/release compliance logging.
SIP application-layer gateway	No SDP rewriting and no media pinholing exist.	SIP traffic blocking, as a policy control. Never described as an ALG.
DNS64	The product contains no resolver and no record synthesis.	Where NAT64 is evaluated, a customer-supplied DNS64 resolver is required.
Chassis redundancy or high-availability failover	No peer-node state replication, no active/standby pair, no virtual-router failover.	Session state is distributed from the control plane to the forwarding plane on the same node, and software upgrades do not drop traffic.
Prometheus or OpenMetrics	No such endpoint exists.	A JSON metrics file, atomically rewritten on a fixed interval, for your collector agent to read.
A REST management API	The management interface is not HTTP and is not network-exposed.	Newline-delimited JSON over a local socket, serving one client at a time, with schema discovery.
Two-tier / dual-rate CBS-EBS policing	The second tier is not implemented in the forwarding path.	Single-tier committed-rate policing with a configurable, per-class burst allowance.
"Full L4S support"	There is no second queue, the two ECN-capable codepoints are not distinguished, and Accurate ECN is not implemented.	Congestion marking on ECN-capable flows in both address families and both directions, with RFC 9332 coupled probabilities.
A graduated DDoS response ladder	The middle rung has no effect in the data path and promotion to a blocking state does not converge reliably.	Immediate per-subscriber, per-vector rate-capping of traffic above threshold, plus a fragment shield that does converge.
Software you can install on your existing Linux build	The forwarding engine depends on kernel capabilities we build and maintain.	A complete appliance image for commodity server hardware you source yourself, versioned and supported as one unit.

Why print this at all? Because every item above is something a prospect would otherwise find during evaluation, at the worst possible moment, and conclude — reasonably — that the rest of the page was written the same way. A capability list that survives its own evaluation is worth more than one that wins the first meeting.

Three roles. One image. One server. Every line labelled.

A subscriber edge needs session termination, quality of service, latency management, address translation, filtering, abuse containment and enough visibility to run it. BNGSOFT ships all of that in one software image on a server you buy yourself, in three deployment roles, with zero-downtime software upgrades and per-subscriber latency instrumentation running from the first packet.

What we will not do is let you find out in month two which half of the feature list was switched on. That is what the status label on every line of this document is for.

Sources

Vendor documentation only. All vendor sources accessed 3 August 2026. No pricing was researched. BNGSOFT capability statements are drawn from the shipping product at the release current on that date.

netElastic — vBNG Service Configuration Guide v1.11 (published June 2021, mirrored by Splynx); vBNG datasheet (© 2019, mirrored by distributor Winncom); vBNG, products, packages and large-carrier solution pages; "IPv6 dual-stack best practices" article (19 Feb 2026); vBNG FAQ (30 Jan 2024); 1 Tbps throughput press release; Intel Network Builders solution brief 338405-001US (Nov 2018). Several netElastic findings rest on documents that are five to seven years old; the document date is stated in every cell that relies on one.
MikroTik — help.mikrotik.com RouterOS documentation: PPPoE; PPP AAA; HTB Hierarchical Token Bucket; Queues; Queue types; RADIUS; NAT; Connection tracking; Common Firewall Matchers and Actions; Filter; DDoS Protection; IP Settings; Traffic Flow; IPv6 PD over PPP; Upgrading and installation; MPLS Overview; EVPN; IS-IS. MikroTik does not market a product branded "BNG"; RouterOS is documented as a general-purpose router OS with a PPPoE access-concentrator role.
Nokia — SR OS Quality of Service Guide 25.7.R1 and 26.7 (queue and WRED policies); SR OS 26.7 ESM High Scale QoS IOM; SR OS 24.3 scheduler QoS policies; SR OS 22.10 Multiservice ISA and ESA NAT; SR OS 24.10 ISA/ESA hardware; 7750 SR 22.7 IPFIX flow logging; MAG-c 25.3 residential NAT; SR OS 22.10 Residential Firewall; 7750 SR 22.5 Application Assurance; SR OS System Management security and 7750 SR 22.2 Distributed CPU Protection; Deepfield Defender solution sheet; 7750 SR 22.2 uRPF and 22.5 subscriber uRPF; Triple Play security guide; cflowd introduction; SR OS 25.3 subscriber management; 7750 SR 22.5 DHCPv6 prefix options; SR OS 22.10.3 SLAAC; ACG 24.3.2 PPPoE dual-stack hosts; SR OS 24.3 system initialisation and 26.3 CPM redundancy; SR OS 25.3 documentation suite; SR OS 23.10.1 segment routing; cMAG-c 25.7 and MAG-c 23.10 CUPS overviews; Nokia L4S white papers and the Nokia/Vodafone PON trial press release (3 April 2024); Nokia VSR asset. These pages span SR OS releases 22.2 to 26.7; the release is stated wherever a claim depends on it.
Cisco — ASR 9000 BNG Configuration Guide (IOS XR 6.5.x, 7.6.x, 7.9.x, 7.11.x); CGNAT Configuration Guide (6.5.x, 7.11.x); NetFlow Configuration Guide 7.11.x; BGP FlowSpec guide 7.11.x; ISSU guide 7.9.x; SRv6 micro-SID guide 7.9.x; cnBNG Control Plane Configuration Guide 2025.01. All retrieved as dated Internet Archive snapshots; snapshot timestamps are printed in each matrix cell, and these entries are pending confirmation against the live canonical pages.
Juniper — BNG CUPS User Guide: Controller overview, and CUPS theory of operation. Deployment architecture only; no other Juniper capability was researched.
Standards — RFC 9330 (L4S architecture) and RFC 9332 (Dual-Queue Coupled AQM), for definitional accuracy only.

Trademarks and non-affiliation. netElastic and vBNG are trademarks of netElastic Systems, Inc. Cisco, IOS XR, ASR and UCS are trademarks or registered trademarks of Cisco Systems, Inc. Nokia, Bell Labs, Deepfield and 7750 SR are trademarks or registered trademarks of Nokia Corporation. MikroTik and RouterOS are trademarks of Mikrotikls SIA. Juniper Networks and Junos are trademarks or registered trademarks of Juniper Networks, Inc. Intel and Xeon are trademarks of Intel Corporation. Vodafone is a trademark of Vodafone Group plc. Splynx is a trademark of Splynx s.r.o. Winncom Technologies is a trademark of Winncom Technologies Corp. Kubernetes is a trademark of The Linux Foundation. All other product and company names mentioned are the property of their respective owners. BNGSOFT is not affiliated with, endorsed by, sponsored by, or otherwise associated with any of the companies named above; product and company names are used solely for identification and factual comparison.

Basis of comparison. Each competitor entry reflects what was found in that vendor's public documentation on the stated access date; it does not assert that a capability is unavailable. Vendor documentation changes between software releases, and a capability may exist in a release, product variant or document not reviewed here. Where a vendor's documentation is silent on a capability, that is recorded as silence in a named document, never as absence — and the specific document searched is identified in the cell. Cisco entries are sourced from dated Internet Archive snapshots because cisco.com was not reachable from the research environment; an archive snapshot proves what was published at that moment and not what is current. No throughput comparison is presented, because no vendor examined publishes throughput measured with per-subscriber quality of service enabled. Readers evaluating a purchase should confirm current capabilities directly with each vendor.

About the delivery statuses. "Active on delivery" means the capability is present and acting with no configuration on a node of the stated deployment model. "Configured at commissioning" means the capability is complete and shipped in the same image and is enabled by an engineer during deployment; it is not running beforehand. "Conditional" means the capability depends on the deployment model, the network-adapter family or the attachment mode, and the condition is stated with it. "Roadmap" means not implemented. Capability availability is additionally subject to licensed entitlement. Feature behaviour and defaults change between releases; confirm the status of any capability material to a purchase decision against the release quoted for your deployment.