Subscriber Edge on Commodity Servers
Broadband Gateway · CGNAT · QoS · Protection
Broadband Gateway · CGNAT · QoS · Protection
Convergence · One Appliance, Two Roles
You already need the broadband gateway.
The box above it is the one worth questioning.
If a subscriber node is going in the rack anyway, the interesting question is not whose BGP is deeper — theirs is, and we concede it below. The interesting question is what you have to buy to put the aggregation role in the same rack unit. This page keeps the two roles strictly apart: one is in production and measured, the other is designed, built, and has never run.
Two roles · two completely different evidence classes · read this first
Role 1 · In production today
The broadband subscriber role
Measured on a live node carrying paying subscribers, at evening peak, with the protection and quality-of-service suite enforcing on subscriber traffic throughout.
- More than 4,400 live subscriber sessions on one six-core server built on a 2016-generation processor
- Busiest core 72% in any one-second sample; zero packets discarded
- Carrier-grade address translation runs in the same product family, on other nodes, and is separately evidenced below
Role 2 · Has never run
The border transit role
Designed and built. Not in service, anywhere. Everything this page says about it is a design an operator can evaluate, never a capability.
- Never loaded — the kernel’s program safety verifier has never examined it
- Never attached to a network port, on any machine
- Never forwarded a packet. Not one, on any node, in any lab
- Listed under roadmap in our platform capability catalogue, and this page does not change that entry
4,400+
live subscribers on one six-core 2016-generation server — measured at evening peak, not modelled
72%
busiest core in any one-second sample of that window. Zero packets discarded
1
appliance, two roles. The second role would need no new hardware in the rack
0
packets forwarded by the border role to date. It has never run, and this page is written accordingly
The argument, in six lines
The subscriber role is real, and it is measuredNot a lab figure and not a model: one continuous minute on a production node at evening peak, sampled once per second, with every feature enforcing. Section 1, with its conditions attached.
That node is not working hardBusiest core 72%, no sample on any core at 80%, nothing discarded. There is room on the machine you were buying anyway — which is the whole reason a second role is worth discussing.
The second role is designed and built, and has never runSection 2 states that plainly and keeps stating it. Nothing about it is offered as a capability, a date, or a commitment.
The comparison is deployment model, not routing depthSection 3 asks one question of every vendor: what do you have to buy to get both roles in one rack unit? Answered from each vendor’s own documentation, with the access date on every quote.
Routing depth is conceded, not contestedNo MPLS, no SRv6, no IS-IS, no BFD, no default-free-zone transit. Two of those are absences in the platform underneath, not schedule. Section 6, alongside the rows where a competitor is simply ahead.
Protection belongs to the subscriber role onlyEvery protection capability on this page acts on subscriber traffic. There is none on a transit port, by design and in fact. We say so four times, because it is the sentence most likely to be misread.
01 The role that is already running
Every capacity figure an operator is shown by a vendor is usually a model — a spreadsheet extrapolation from a lab box running a stripped-down configuration. This is the opposite of that, and it is the evidential anchor for everything that follows. It is a single minute taken from a live subscriber network at evening peak, on hardware most operators would already have retired, with every feature switched on and enforcing.
MEASURED · PRODUCTION
4,400+
live subscriber sessions on a single six-core server built on a 2016-generation processor
- Approximately 16 Gbit/s of subscriber traffic, with short-term peaks approaching 18 Gbit/s.
- Close to two million packets per second.
MEASURED · PRODUCTION
72%
the busiest individual core in any one-second sample across the window
- No sample on any core reached 80%.
- Processor utilisation is reported as the busiest core per sample, not an average across cores.
MEASURED · PRODUCTION
0
packets discarded by the network interfaces or the forwarding system during the window
- Verified separately over a further 30-second observation at the same load.
The usual trick in a capacity benchmark is to turn the features off, because shaping, protection and monitoring all cost something and a number quoted with them disabled is a number an operator never sees again once the box is in service. On this node all of it was running, for every one of those subscribers, for the whole measurement:
Per-subscriber speed controlenforced on subscriber traffic
Low-latency queueingenforced on subscriber traffic
Interactive traffic protectionenforced on subscriber traffic
DDoS protectionenforced on subscriber traffic
Source-address validationenforced on subscriber traffic
Outbound abuse containmentenforced on subscriber traffic
Scope of every protection statement on this page
All six of the capabilities above act on subscriber traffic, in the subscriber role, and nowhere else. They are not present on a transit port, they are not part of the border role, and nothing on this page should be read as protecting transit traffic. The border role described from section 2 onward contains no filtering, no access control, no policing, no rate limiting and no attack mitigation of any kind — and it has never run in any case. If protection at the border is what you are evaluating, this page does not describe it and we are not going to imply otherwise.
What that node had left, at its busiest second
Two measurements from the same one-minute window on the same production node. The second is a true zero, so it is drawn as nothing rather than as a short bar.
Busiest core, worst one-second sampleagainst the full core — no sample on any core reached 80%
72%of one core
Packets discarded across the windownetwork interfaces and forwarding system, both counted
0packets
Conditions. A single continuous one-minute observation of one production broadband gateway node, sampled once per second, taken during the evening peak period. The node carries paying subscribers and was not driven to its limit — these figures describe this node under this load and are not a maximum, and they should not be converted into a per-core rate or treated as a capacity ceiling. This node is a broadband gateway and does not perform carrier-grade address translation, which is a separate function running on other nodes in the same product family; that role is evidenced separately below. Capacity on any deployment depends on installed port capacity, traffic profile, per-subscriber rates and feature configuration, and should be confirmed during design review.
This is the part of the page that matters most, and it is the part with the least in it. A server most operators would already have retired is carrying more than 4,400 live subscribers through evening peak, with every protection feature enforcing on their traffic, losing nothing, and finishing every second with capacity to spare. The convergence argument in section 3 exists only because that spare capacity is real and measured — if the node were at 95%, there would be nothing to talk about.
And the address-translation role, evidenced separately
Carrier-grade address translation runs on different nodes in the same product family, so it is evidenced on its own rather than folded into the figures above. From a maintenance window on a live translation node in August 2026, verified from counters rather than from a packet capture:
| What was checked | Observed | What it establishes |
|---|---|---|
| Translation actively advancing | The translated-packet counter advanced by 598,745 during the observation, a rate of about 397 per second | A live, advancing counter on a node in service — not a static configuration |
| Subscribers behind it | 228 active translated subscribers, matching the pre-maintenance count exactly | Every subscriber recovered across a full software replacement |
| Public-address blocks | Blocks in use advanced from 347 to 356; allocations continued throughout | Address allocation functioning, not frozen |
| Allocation failures | Two, across the whole window | Reported because it is not zero. It is a small number, not no number. |
Why this is presented separately and in this much detail. A single figure of merit for two different node types would be a figure of merit for neither. These counters were read from one node during one window and are evidence that the role runs in production — they are not a capacity claim, not a benchmark, and not comparable with the subscriber-node figures above. No subscriber-identifying information was accessed or is reproduced anywhere on this page.
02 The second role — and its status, stated plainly
The second role is border transit forwarding: IPv4 and IPv6 unicast transit at the broadband aggregation edge, on transit ports of the same appliance, alongside whichever subscriber role that appliance is already running.
It has never run. The forwarding program has never been loaded — the kernel’s program safety verifier has never examined it. It has never attached to a network port. It has never forwarded a packet, on any node, in any lab. It is designed and built, and not in service. There is no border-router deployment model, no configuration for one, and no date attached to this work. Our platform capability catalogue lists this role under roadmap, and that entry remains correct.
Everything from here to section 5 is therefore an architecture an operator can evaluate on its merits, together with the measurements that decided each choice in it — and never a description of behaviour you can expect from a node we ship today.
The scope, stated as a decision
The intuitive objection to routing in this kind of forwarding path is “you cannot hold a full internet table”. It happens to be the wrong objection: the forwarding path would resolve routes through the operating system’s own routing structure, the one that already handles more than a million prefixes for the kernel, and nothing in the forwarding path grows with the number of prefixes. What actually pushes the scope down is the platform around the forwarding path — what the operating system supports, and how the routing software is built. Those constraints are survivable at an aggregation edge carrying a default route and a partial table. They are not survivable in a default-free-zone core.
DESIGNED FOR · NEVER RUN
The broadband aggregation edge
- Two to eight eBGP sessions — upstream transit, peering, and a handful of downstream gateway nodes.
- A default route plus a partial table: hundreds to tens of thousands of prefixes, not a million.
- IPv4 and IPv6 unicast transit, forwarded on the same node that already terminates the subscribers.
- The routing software remains the single routing authority. The forwarding path never becomes one.
DELIBERATELY NOT DESIGNED FOR
Default-free-zone internet transit
- A full internet table with contractual sub-second convergence. Without BFD, peer failure is detected on BGP hold time — tolerable behind a default route with a second path, and not tolerable as a transit core.
- Anything needing MPLS, SRv6, IS-IS or an IPv6 interior gateway protocol.
- This is a decision, not a staging post. We are not withholding it pending a release.
The target is a broadband gateway that also routes — never a router that happens to terminate subscribers. Nobody should buy this node to be a router.
03 The comparison worth having is the deployment model
We are not going to argue that our routing is better than a chassis vendor’s. It is not, we concede it in section 6, and a page that argued otherwise would deserve the rebuttal it would get. The question that is actually ours to ask is different and much narrower: if you need a subscriber node anyway, what does each vendor require you to buy to put the aggregation role in the same rack unit?
The whole argument is the right-hand rack’s empty unit — and the honest caveat is the dashed strip above it, which has never carried a packet. We would rather show you both than show you one.
Two things to read before the table. (1) There is no throughput column in it, and there will not be one. No vendor examined publishes throughput measured with per-subscriber quality of service enabled, and putting a lab packet-forwarding figure next to a production figure taken with subscriber shaping active would be dishonest in either direction. (2) Every cell reflects what was found in that vendor’s public documentation on the access date given; it does not assert that a capability is unavailable. Where a vendor’s documentation is silent, that is recorded as silence in a named document, never as absence.
| Vendor | How the subscriber role is delivered | How the routing / border role is delivered | Both roles in one unit? |
|---|---|---|---|
| BNGSOFT this product |
A commodity server. In production today — the measurement in section 1. | A second role on transit ports of the same server. Designed and built; has never run. No MPLS, no SRv6, no IS-IS, no BFD, no default-free-zone transit. | Yes — same appliance, no added card, no second productFirst-party production measurement, August 2026. The border role is unproven and is listed under roadmap. |
| netElastic | The vBNG product: “provides subscriber management and automation for broadband service providers”. Carrier-grade address translation is a separate SKU, or an optional licence on a BNG package. | A separate product. netElastic’s own words: “netElastic vRouter is a scalable, cost-effective, high-performance virtual router typically used for full table IPv4 and IPv6 BNG routing from 10G to 100G.” | Documented as separate productsnetelastic.com/products/ and netelastic.com/products/packages/ — accessed 3 August 2026. |
| Nokia | BNG on SR OS platforms; the Virtualized Service Router is “optimized for x86 server deployment” and “deployable as a virtual network function (VNF) or container network function (CNF)”. | The same SR OS platform, with a full routing suite including segment routing and EVPN. Nokia converges these roles today and we concede it. | Yes — but carrier-grade address translation is documented as requiring an MS-ISA2, MS-ISM or ESA service card rather than the base line carddocumentation.nokia.com — MAG-c 23.10.1 value propositions; SR OS 25.3 documentation suite; Multiservice ISA and ESA guide; onestore.nokia.com asset 182483 (partial page load) — all accessed 3 August 2026. |
| Cisco | Three documented models: physical BNG, virtual BNG on x86 UCS servers, and cloud-native BNG whose control plane is “a Kubernetes-based platform”. | In the cloud-native model the documented user plane is Cisco routing hardware: “The UP can be on any of the physical platforms that supports the BNG UP, like Cisco ASR 9000 Series Routers.” | In the physical model, yes — on a chassis whose user plane is “a physical NPU or ASIC”. In the cloud-native model the control plane is a separate cluster.Cisco cnBNG Control Plane Configuration Guide, release 2025.01.0 — Internet Archive snapshot 17 May 2026, accessed 3 August 2026. Sourced from an archive snapshot because cisco.com was not reachable from the research environment; a snapshot proves what was published at that moment, not what is current. |
| MikroTik | No product is branded as a broadband network gateway; RouterOS is a general-purpose router with subscriber features. | RouterOS routing: MPLS and LDP documented; EVPN documented but scoped — “VXLAN (currently only one supported by ROS)”. Segment routing over IPv6 returned zero results on a site-restricted search — recorded as silence, not absence. | Yes, by nature — it is one device doing everythinghelp.mikrotik.com documentation pages — accessed 3 August 2026. |
The honest reading of that table, including the part that does not flatter us. “Nobody else can put both roles in one box” would be false, and Nokia could rebut it with one link — an SR OS platform is a router that also terminates subscribers, and that is genuine convergence on far deeper routing than we will ever offer. What the table actually shows is narrower and survives scrutiny: the roles converge on a chassis, on an added service card, or across separate products — and here they would converge on one commodity server with none of those. That is a cost and operations argument, not a technology argument, and it is the only one we are making.
04 Why the second role would cost the first one nothingdesign · never run
A convergence argument is worthless if the second role degrades the first. Two design decisions exist to make sure it could not, and both were measured before being chosen.
Decision one: the forwarding path would hold no routing table
Almost every serious defect this product family has had in its history was the same defect wearing different clothes: a second copy of some state fell out of step with the first. A cache that outlived what it cached. A reclaimer that removed something still in use. An index that disagreed with the thing it indexed. So the first decision here was made against that history rather than against a benchmark. The forwarding path would resolve every destination through the operating system’s own routing table — the same structure, through the same code, that the kernel uses for its own forwarding. Not a copy of it, not an export of it, not a summary of it.
The design’s main contribution is a decision not to build something. Shadow state can diverge; state you read cannot. There is no cache to invalidate, no expiry to tune, no reconciliation pass and no repair loop — because there is only one opinion about where a prefix goes, and the forwarding path does not own it.
| Control-plane event | What the system routing table does | What the transit forwarding path would do |
|---|---|---|
| A route is installed | Present once the routing software has installed it | The next packet uses it |
| A route is withdrawn | Gone | The next packet finds no route and is handed to the operating system, which decides what to do |
| A next hop changes | Changes atomically | The next packet uses the new next hop |
| A peer flaps | Routes withdrawn, then reinstalled | Follows exactly — there is no interval in which the two disagree |
| A large table reconverges | Transiently inconsistent while routes install | Identically inconsistent. No better, and no worse. |
| The routing software is killed outright | Routes persist until something removes them | Forwards on exactly the routes the operating system would have forwarded on. Its staleness cannot exceed the table’s. |
The last two rows are the honest ones, so read them as claims. This design would not make a reconverging table converge faster, and it would not rescue you from a routing daemon that has died. What it guarantees is narrower and more useful: it could never be more wrong than the operating system is. A design holding its own copy could be — and that is the failure this one is built to be incapable of.
Decision two: the question is asked once per port, not once per packet
A node doing both jobs has to answer one question about every packet: is this transit, or is this a subscriber? The obvious place to answer it is at the top of the existing subscriber program, once per packet. That obvious answer is the one that would make the second role expensive for the first, and we measured how expensive before choosing against it. A test whose two outcomes both carry on into the code beneath it forces everything beneath it to be checked twice — once for each outcome — and that doubling compounds through every decision that follows.
What asking the question per packet would actually cost
Program size, measured as the number of instructions the kernel’s safety verifier has to process before it will allow a program to run. Lower is better. Measured on a purpose-built probe with sixteen decision points beneath the test — the shape of a real datapath, at a size we could measure exhaustively.
No transit test at allthe baseline program
352instructions
Tested per packet, both outcomes carry onthe obvious design — rejected
735instructions
Tested per packet, transit outcome ends immediatelythe fallback, if ports cannot be separated
373instructions
A separate program per portwhat this design specifies
0instructions
Conditions. A purpose-built probe, not a product program, compiled with the same flags as our datapath and loaded on a development host running a stock kernel. The three measured shapes differ only in the test at the top. The fourth row is not a measurement of a program — it is the observation that a test which was never written costs nothing, and it is drawn as a true zero rather than as a short bar. The last row of the table below is the one charted here. These are program-size figures and say nothing whatever about packets per second.
| Decision points beneath the test | No transit test | Tested per packet, both outcomes carry on | Tested per packet, transit outcome ends immediately |
|---|---|---|---|
| 8 | 184 | 407 +121% | 205 +21 |
| 12 | 268 | 571 +113% | 289 +21 |
| 16 | 352 | 735 +109% | 373 +21 |
Two results, and both decided a design choice. A test whose outcomes both carry on costs roughly 2.1× the entire program beneath it — and the multiplier did not shrink as the program grew, so it is multiplicative rather than additive. A test whose transit outcome ends there and then costs a flat twenty-one instructions at every size, because an outcome that carries nothing forward is never re-walked. This is why the subscriber datapath would be left byte-for-byte alone: transit gets its own program on its own ports, and the subscriber program never learns that transit exists.
What would happen to a packet, and where each path ends
Forwardedthe fast path — never yet executed
packet on a transit port
→parse
→read the system routing table
→rewrite and send
→ends here
Handed to the operating systemno route, next hop not yet resolved, or larger than the next link allows
packet on a transit port
→read the system routing table
→the operating system handles it correctly
→ends here
Not a transit port at allthe only per-packet test that remains
packet on any other port
→handed straight to the operating system
→ends here
No two of these ever rejoin, and there is no fourth row. Every outcome ends the program where it stands — which is why the program stays small, and why the guard on the third row costs a flat twenty-one instructions rather than a multiple of everything after it.
Handing a packet to the operating system would be this design’s default, not its failure mode. The operating system is already a complete and correct router: it resolves neighbours, generates the right protocol messages when a packet is too large or a destination is unreachable, and handles every case the fast path declines. The fast path would be an accelerator sitting in front of it, not a replacement for it. Anything it declined would still be handled correctly — just more slowly.
Second statement of scope, because it matters more than once
Nothing in the three rows above filters, polices, rate-limits or mitigates anything. The transit path resolves a route and forwards, or it hands the packet to the operating system. There is no protection function on a transit port in this design, there never was one specified, and the role has never run in any case. The protection capabilities in section 1 act on subscriber traffic in the subscriber role, and would not be present on a transit port.
05 What the border measurements say — and what they do notdesign · never run
Read this before the numbers, because it changes what every one of them means.
- These are routing-lookup microbenchmarks, not forwarding throughput. There is no network adapter, no direct memory access, no driver receive or transmit path, and no packet arriving from anywhere. Real forwarding adds all of it. Every figure here is an upper bound on what a datapath could do, and the gap is not small.
- They were taken on an AMD development host, not on broadband gateway hardware. The gateway nodes run a different processor family with a different cache hierarchy. The shape of the curve transfers. The absolute numbers do not.
- They do not describe the node in section 1, which is a different machine doing a different job. Nothing in this section may be combined with anything in section 1.
- The routing table was synthetic — roughly fifty thousand destination blocks captured from a live subscriber node, padded to a million prefixes with generated entries at realistic lengths.
With that said, the result is genuinely interesting, and it is not the result we expected. The question was whether a routing lookup in this kind of forwarding path lands nearer four million packets per second per core or nearer 1.6. The answer is that both are right, and the difference is not the hardware and not the size of the routing table. It is how many subscribers sit behind the router.
A routing lookup is fast when the destinations it is asked about are ones it looked up recently, because the parts of the table it needs are still in the processor’s cache. Real traffic is heavily concentrated — on the live node we sampled, ten destination blocks absorbed forty per cent of flows and sixty per cent of packets. An adversarial spread evenly across a million prefixes is the opposite of that, and it is the slow case. Both were reproduced on the same core, the same table and the same packet size, varying nothing but the destination mix.
Lookup rate against the number of subscribers behind the router
Million packets per second, one core. Higher is better. Lookup harness — no network adapter is involved in any of these figures, so each is an upper bound rather than a forwarding rate.
measured directly from live traffic
measured replay of a projected working set
synthetic worst case
231 subscribersa live subscriber node — destinations captured and replayed
8.85Mpps, one core
1,000 subscribersworking set projected, then measured
5.08Mpps, one core
10,000 subscribersworking set projected, then measured
4.29Mpps, one core
50,000 subscribersworking set projected, then measured
3.04Mpps, one core
100,000 subscribersworking set projected, then measured
2.38Mpps, one core
An adversarial even spread941,719 destinations, one per prefix in the table — no real traffic behaves like this
1.84Mpps, one core
Conditions, in full. One core of an AMD development host, simultaneous multithreading disabled, warm cache, 64-byte packets, a synthetic million-prefix table, and a probe smaller than the datapath this design describes. Every run was checked to confirm that the lookup actually completed — an earlier version of this harness reported far higher figures because the lookup was silently never running, and the check exists because of it. The first row is the only one where the destination mix was captured from real traffic; the rest replay working-set sizes projected from it, so the projection is the assumption in each of those rows, not the measurement. None of these numbers is a forwarding rate, none was taken on gateway hardware, and none of them describes the production node in section 1.
| Subscribers behind the router | Distinct destination blocks in ten seconds | Lookup rate, one core — upper bound, no network adapter | Where the working-set figure comes from |
|---|---|---|---|
| 231 — a live subscriber node | 665 | 8.85 Mpps | Captured from that node’s live traffic and replayed unchanged |
| 1,000 | 2,227 | 5.08 Mpps | Projected from the live node, then that size replayed and measured. The projection is untested at a second node. |
| 10,000 | 13,788 | 4.29 Mpps | Projected from the live node, then that size replayed and measured. The projection is untested at a second node. |
| 50,000 | 49,314 | 3.04 Mpps | Projected from the live node, then that size replayed and measured. The projection is untested at a second node. |
| 100,000 | 85,376 | 2.38 Mpps | Projected from the live node, then that size replayed and measured. The projection is untested at a second node. |
| An adversarial even spread | 941,719 | 1.84 Mpps | Synthetic — one destination per prefix in the table, uniformly. No real traffic observed at any subscriber count behaves this way. |
The framing that matters is the one the measurement produced, not the headline figure. Performance in a design like this is a function of how many subscribers sit behind the router, far more than it is a function of the hardware or the size of the routing table. That is a useful thing to know while sizing a deployment — and it is worth more than any single number here, particularly since every number here is an upper bound on a role that has never run.
| What else was varied | Range tested | Effect on the result |
|---|---|---|
| Packet size | 64, 512 and 1,500 bytes | None. 103, 103 and 104 nanoseconds per packet. The lookup does not care how big the packet is. |
| Depth of the routing table structure | Two tables, average depth 1.4 and 2.0 | About 10% at realistic destination mixes, and nothing at all at the adversarial one. Not a decisive factor. |
| Other cores using the same table | 19 sibling cores driven against it simultaneously | 1% at the realistic working set, 6% at the adversarial one. The working set is small enough to stay core-local. |
| Order of destinations | Every trace shuffled before replay | Not measured. Shuffling destroys run-length locality that real traffic has, which makes these figures conservative rather than optimistic. |
| Simultaneous multithreading | Not tested — disabled on the harness host | Unknown. Gateway hardware has it enabled. It would most likely reduce the per-core figure. |
06 What we concede
Two kinds of concession follow. The first is what the border role would not do, whatever we did next. The second is where a competitor is simply ahead of us today — which belongs on this page because a comparison that omits it is a rigged comparison, and because the credibility of section 3 depends on it.
What the border role will not do
| Capability | In this design | Why | What that means for you |
|---|---|---|---|
| MPLS — and with it L3VPN, traffic engineering, pseudowire | No | Absent from the operating system entirely. A platform-level absence, not an unimplemented feature. | If you need it, buy a router. No release of this product would change the answer. |
| SRv6 | No | Absent from the operating system entirely. Same class of absence as MPLS. | If you need it, buy a router. |
| IS-IS | No | The routing software is built without it. | An IS-IS core is not a network this belongs in. |
| BFD — sub-second peer failure detection | No | The routing software is built without it. Peer failure would be detected on BGP hold time instead. | Tolerable behind a default route with a second path. Not acceptable where sub-second convergence is contractual. |
| An IPv6 interior gateway protocol | No | The routing software is built without one. An IPv6 core would need internal BGP or static routes. | Workable for a handful of peers. Not workable for a routed IPv6 core. |
| Default-free-zone internet transit | No | A scope decision, taken deliberately and for the reasons in section 2 — not a gap awaiting a release. | If the requirement is a transit core, this is the wrong product and we would rather say so now. |
| Filtering, access control, policing or attack mitigation on a transit port | No | Deliberately out of scope. The transit path would resolve a route and forward, or hand the packet to the operating system. Nothing else is in it. | There is no protection function of any kind on a transit port. The protection in section 1 acts on subscriber traffic only. |
| Surviving its own software upgrade without interruption | No | A chassis router does in-service software upgrade. This does not. | Plan maintenance windows the way you would for a server. |
Where a competitor is ahead of us
| Vendor | Where they are ahead, in their own documentation | Source and access date |
|---|---|---|
| netElastic | Their datasheet lists a fuller routing and MPLS stack than we ship: “OSPF v2, v3”, “ISIS”, “BGP v4, 4+, MP-BGP”, “Label Edge Router (LER)”, “Label Switch Router (LSR)”, “Label Distribution Protocol (LDP)”, “MPLS L2VPN – VPWS, VPLS”, “MPLS L3VPN – CE/PE”, “PIM-SM”, “PIM-SSM”. This is the closest peer to us and on this row they win. | netElastic vBNG datasheet, © 2019, as mirrored by distributor Winncom — accessed 3 August 2026. The document is dated 2019 and is cited as such. |
| Nokia | A full routing suite including segment routing with MPLS and IPv6 data-plane encapsulations, and Layer 2 services with EVPN. Also the deepest per-subscriber quality-of-service hierarchy of any vendor examined. Both are well beyond what we offer. | documentation.nokia.com — SR OS 25.3 documentation suite index; Segment Routing and PCE User Guide 23.10.1 — accessed 3 August 2026. Quoted with Nokia’s own caveat that a per-platform list of unsupported features exists in the release notes. |
| Cisco | Deep segment-routing support over IPv6, IS-IS, topology-independent loop-free alternates and flexible algorithm, plus strong per-subscriber quality of service. Again, beyond us. | Cisco IOS XR documentation — Internet Archive snapshots, accessed 3 August 2026. cisco.com was not reachable from the research environment; an archive snapshot proves what was published at that moment, not what is current. |
| MikroTik | The deepest documented active queue management stack of the four vendors examined — CoDel, FQ_CoDel, CAKE, RED and SFQ are all documented. | help.mikrotik.com queue documentation — accessed 3 August 2026. |
An operator who needs any of the first four rows of the previous table should buy a router, and we will say so during an evaluation rather than after one. The credibility of section 3 depends entirely on this section being complete and being early. A second role honestly scoped as “IPv4 and IPv6 unicast transit at the aggregation edge, partial table, no MPLS, no IS-IS, no BFD, and not yet run” is worth having. One marketed as a router would cost us more than the role is worth.
07 What would have to happen before the second role is real
In order, and none of it has been done. This list is the honest measure of the distance between section 4 and a product — and section 1 is unaffected by all of it, because section 1 is already running.
STEP 1 — NOT DONE
Let the verifier see it
- The kernel’s safety verifier has never examined the program. Until it does, the program-size figures in section 4 are predictions from a probe, not properties of a datapath.
- Half a day of work, and it retires the only unmeasured claim in the design.
STEP 2 — NOT DONE
Attach it and forward one packet
- Then forward many, and compare what comes out byte for byte against what the operating system would have sent for the same input.
- Then detach it under load and confirm forwarding simply continues through the operating system — the reversibility the design claims and has never demonstrated.
STEP 3 — NOT DONE
Measure it on real network adapters
- With a traffic generator, on gateway hardware. This is what converts every figure in section 5 from an upper bound into a forwarding rate.
- Until then no throughput claim about the border role is available to be made, and none is made here.
STEP 4 — THE BIGGEST UNKNOWN
Run it beside a real BGP peer, on a node also carrying subscribers
- The single question a design document cannot answer, and the one that decides whether this convergence argument holds at all: does installing routes at BGP scale compete with subscriber packet processing for the same processor cores?
- A local session between two daemons on one machine is not a peer. It does not reproduce burst timing, path churn, or a hold time expiring under load.
- If the answer is bad, the second role does not belong on a shared node and becomes a standalone product or nothing. That cannot be determined from a design, and we have not determined it.
STEP 5 — RE-MEASURE HONESTLY
Repeat the locality work properly
- Re-run the lookup harness on the processor family the gateways actually use — that removes the largest single source of error in section 5 in about half a day.
- Repeat the traffic capture at peak hour, and on a node with thousands of subscribers rather than 231, to test the projection at a second point instead of extrapolating from one.
- Replace the synthetic routing table with a real one.
Every number about the second role has a way of being proved wrong, and each of those ways is listed above. That is the difference between a design and a claim — and section 1 is the claim.
What we would like from you, if this is interesting
Not an order. A topology. The decision that most changes this is whether your transit ports can be physically separate from the ports carrying subscriber traffic — if they can, the second role is a separate program and costs the subscriber datapath nothing; if they cannot, the fallback measured in section 4 applies and the cost profile changes.
The second thing worth telling us is how many subscribers would sit behind the router, because section 5 shows that is the variable that moves the performance, not the hardware.
And ask us to run the section 1 measurement on a node in your own network, beside your incumbent. That role is running today and it is the only part of this page we would ask you to buy on. If any row in section 6 is a requirement for you, tell us first and we will save you the evaluation — we would rather lose the deal on the second call than on the sixth.
Sources
- Section 1, the subscriber node — a single continuous one-minute observation of one production broadband gateway node, sampled once per second, taken during the evening peak period. First-party measurement. Conditions are restated in full in the notes below.
- Section 1, the address-translation node — counters read from a live translation node during a maintenance window in August 2026, verified from counter state rather than from a packet capture. First-party measurement, and evidence that the role runs — not a capacity figure.
- Sections 2 and 4, the design — an internal design pass completed in August 2026 covering scope, datapath structure, control-plane integration, failure modes and a phased plan. Nothing in it has been loaded, attached or run.
- Section 4, the program-size figures — a purpose-built probe compiled with the same flags as our datapath and loaded on a development host running a stock kernel, reporting the instruction count the kernel’s safety verifier processed. Three program shapes at three sizes; all twelve figures shown.
- Section 5, locality and lookup rate — a destination-locality study completed in August 2026. Destinations were captured read-only from a live subscriber node carrying 231 subscribers, then replayed on an AMD development host against a synthetic million-prefix routing table. Every reported run was verified to have completed a real lookup, after two earlier versions of the harness were found to be reporting figures for a lookup that never ran.
- Section 6, platform absences — read directly from the operating system’s build configuration and the routing software’s build options as shipped. MPLS and SRv6 are absent from the operating system; IS-IS, BFD and the IPv6 interior gateway protocol are excluded when the routing software is built.
- Sections 3 and 6, vendor statements — netElastic: netelastic.com products and packages pages, and the vBNG datasheet (© 2019) as mirrored by distributor Winncom — accessed 3 August 2026. Nokia: documentation.nokia.com pages across SR OS releases 23.10 to 25.7, the MAG-c 23.10.1 value-propositions page, the Multiservice ISA and ESA guide, and onestore.nokia.com asset 182483 (partial page load) — accessed 3 August 2026. Cisco: cnBNG Control Plane Configuration Guide release 2025.01.0 and IOS XR BNG guides, all retrieved as Internet Archive snapshots — accessed 3 August 2026. MikroTik: help.mikrotik.com documentation pages — accessed 3 August 2026.
- Status — the border role appears under roadmap in our platform capability catalogue. This page is consistent with that entry and does not supersede it.
Status of the two roles. The subscriber role described in section 1 is in production and the figures given for it are first-party measurements. The border transit role described in sections 2, 4 and 5 has never run. Its forwarding program has never been loaded, has never been examined by the kernel’s program safety verifier, has never been attached to a network port, and has never forwarded a packet. There is no border-router deployment model, no configuration for one, and no date attached to this work. Nothing about the border role should be treated as a commitment to deliver, as a specification, or as a description of behaviour available from any node we ship today; it is listed under roadmap in our platform capability catalogue and this document does not change that listing.
Scope of every protection statement — subscriber traffic only. Per-subscriber speed control, low-latency queueing, interactive traffic protection, DDoS protection, source-address validation and outbound abuse containment act on subscriber traffic in the subscriber role. They are not present on a transit port, they are not part of the border role, and nothing on this page asserts that transit traffic is protected, filtered, policed or rate-limited in any way. The border design contains no such function and has never run in any case.
About the section 1 figures. All of them come from a single continuous one-minute observation of one production broadband gateway node, sampled once per second, taken during the evening peak period. The node was carrying more than 4,400 live subscriber sessions on a six-core server built on a 2016-generation processor, averaging approximately 16 Gbit/s of subscriber traffic and close to two million packets per second, with short-term peaks approaching 18 Gbit/s. Processor utilisation is reported as the busiest individual core in each one-second sample; the highest value observed was 72%, and no sample on any core reached 80%. No packets were discarded by the network interfaces or the forwarding system during the window, verified separately over a further 30-second observation at the same load. Per-subscriber speed control, low-latency queueing, interactive traffic protection, DDoS protection, source-address validation and outbound abuse containment were all enabled and enforcing on subscriber traffic throughout. The node is a broadband gateway and does not perform carrier-grade address translation, which is a separate function running on other nodes in the same product family and is evidenced separately. The node is configured with the network-card tuning we recommend for its interface family, applied during commissioning. These figures describe this node under this load and are not a maximum: the node serves paying customers and was not driven to its limit. They should not be converted into a per-core rate or treated as a capacity ceiling. Capacity on any deployment depends on installed port capacity, traffic profile, per-subscriber rates and feature configuration, and should be confirmed during design review. No subscriber-identifying information was accessed, retained or is reproduced anywhere in this document.
About the section 4 and 5 figures. All performance figures for the border role are routing-table lookup microbenchmarks and program-size counts produced on a development host. They involve no network adapter, no driver receive or transmit path, no direct memory access and no packet arriving from a network, and they are therefore upper bounds on what a forwarding datapath could achieve rather than measurements of forwarding throughput; the difference is not small and has not been quantified. The host processor is not the processor family used in the broadband gateway nodes: the shape of the locality curve transfers between them, the absolute figures do not. The routing table used was synthetic. Except where a row is explicitly marked as captured from live traffic, working-set sizes are projected from a single node carrying 231 subscribers during one sixty-second window at one time of day, and that projection has not been tested against a second node. Simultaneous multithreading was disabled on the harness host and is enabled on gateway hardware; that condition is untested and would most likely reduce the per-core figures. None of these figures describes the node in section 1, and none may be combined with it.
Trademarks and non-affiliation. netElastic and vBNG are trademarks of netElastic Systems, Inc. Nokia, Bell Labs and 7750 SR are trademarks or registered trademarks of Nokia Corporation. Cisco, IOS XR, ASR and UCS are trademarks or registered trademarks of Cisco Systems, Inc. MikroTik and RouterOS are trademarks of Mikrotikls SIA. Intel and Xeon are trademarks of Intel Corporation. AMD is a trademark of Advanced Micro Devices, Inc. Linux is a registered trademark of Linus Torvalds. Kubernetes is a trademark of The Linux Foundation. Winncom Technologies is a trademark of Winncom Technologies Corp. All other product and company names are the property of their respective owners. BNGSOFT is not affiliated with, endorsed by, sponsored by, or otherwise associated with any company named above; names are used solely for identification and factual comparison.
Basis of the vendor comparison. Each competitor entry reflects what was found in that vendor’s public documentation on the access date stated in the cell; 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. Cisco entries are sourced from dated Internet Archive snapshots because cisco.com was not reachable from the research environment; a snapshot proves what was published at that moment and not what is current. The netElastic datasheet relied on is dated 2019 and the date is stated wherever it is cited. 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.
Scope of every protection statement — subscriber traffic only. Per-subscriber speed control, low-latency queueing, interactive traffic protection, DDoS protection, source-address validation and outbound abuse containment act on subscriber traffic in the subscriber role. They are not present on a transit port, they are not part of the border role, and nothing on this page asserts that transit traffic is protected, filtered, policed or rate-limited in any way. The border design contains no such function and has never run in any case.
About the section 1 figures. All of them come from a single continuous one-minute observation of one production broadband gateway node, sampled once per second, taken during the evening peak period. The node was carrying more than 4,400 live subscriber sessions on a six-core server built on a 2016-generation processor, averaging approximately 16 Gbit/s of subscriber traffic and close to two million packets per second, with short-term peaks approaching 18 Gbit/s. Processor utilisation is reported as the busiest individual core in each one-second sample; the highest value observed was 72%, and no sample on any core reached 80%. No packets were discarded by the network interfaces or the forwarding system during the window, verified separately over a further 30-second observation at the same load. Per-subscriber speed control, low-latency queueing, interactive traffic protection, DDoS protection, source-address validation and outbound abuse containment were all enabled and enforcing on subscriber traffic throughout. The node is a broadband gateway and does not perform carrier-grade address translation, which is a separate function running on other nodes in the same product family and is evidenced separately. The node is configured with the network-card tuning we recommend for its interface family, applied during commissioning. These figures describe this node under this load and are not a maximum: the node serves paying customers and was not driven to its limit. They should not be converted into a per-core rate or treated as a capacity ceiling. Capacity on any deployment depends on installed port capacity, traffic profile, per-subscriber rates and feature configuration, and should be confirmed during design review. No subscriber-identifying information was accessed, retained or is reproduced anywhere in this document.
About the section 4 and 5 figures. All performance figures for the border role are routing-table lookup microbenchmarks and program-size counts produced on a development host. They involve no network adapter, no driver receive or transmit path, no direct memory access and no packet arriving from a network, and they are therefore upper bounds on what a forwarding datapath could achieve rather than measurements of forwarding throughput; the difference is not small and has not been quantified. The host processor is not the processor family used in the broadband gateway nodes: the shape of the locality curve transfers between them, the absolute figures do not. The routing table used was synthetic. Except where a row is explicitly marked as captured from live traffic, working-set sizes are projected from a single node carrying 231 subscribers during one sixty-second window at one time of day, and that projection has not been tested against a second node. Simultaneous multithreading was disabled on the harness host and is enabled on gateway hardware; that condition is untested and would most likely reduce the per-core figures. None of these figures describes the node in section 1, and none may be combined with it.
Trademarks and non-affiliation. netElastic and vBNG are trademarks of netElastic Systems, Inc. Nokia, Bell Labs and 7750 SR are trademarks or registered trademarks of Nokia Corporation. Cisco, IOS XR, ASR and UCS are trademarks or registered trademarks of Cisco Systems, Inc. MikroTik and RouterOS are trademarks of Mikrotikls SIA. Intel and Xeon are trademarks of Intel Corporation. AMD is a trademark of Advanced Micro Devices, Inc. Linux is a registered trademark of Linus Torvalds. Kubernetes is a trademark of The Linux Foundation. Winncom Technologies is a trademark of Winncom Technologies Corp. All other product and company names are the property of their respective owners. BNGSOFT is not affiliated with, endorsed by, sponsored by, or otherwise associated with any company named above; names are used solely for identification and factual comparison.
Basis of the vendor comparison. Each competitor entry reflects what was found in that vendor’s public documentation on the access date stated in the cell; 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. Cisco entries are sourced from dated Internet Archive snapshots because cisco.com was not reachable from the research environment; a snapshot proves what was published at that moment and not what is current. The netElastic datasheet relied on is dated 2019 and the date is stated wherever it is cited. 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.