Subscriber Edge on Commodity Servers
Broadband Gateway · CGNAT · QoS · Protection
Broadband Gateway · CGNAT · QoS · Protection
Border Mode · Transit Forwarding On Commodity Servers
Your border router forwards packets and runs BGP. Everything else is a separate box.
The firewall is a separate box. The DDoS scrubber is a separate box, or a service you rent. Per-customer rate control is a licensed feature. Low-latency queueing and latency measurement usually do not exist at all. Border mode puts all of it into one pass over the packet, on one commodity server, with FRR holding the routing.
4×40G
the entry configuration — 160 gigabits on an ordinary server, using the adapter family our production nodes already run
6
capability groups applied in a single pass over each packet — not a chain of appliances
0
service cards, scrubbing appliances or per-feature licences anywhere in the design
~3
processor cores to resolve routes at 160 gigabits on a realistic traffic mix — projected from measured lookup rates
Where this stands, stated once
Border mode is in active development, and this page describes what the software is built to do rather than a node you can buy this week. The capability set in section 2 is not speculative — every one of those functions is written and running today in our subscriber products, on live networks. What is new is the border role itself: the forwarding core, and the work of re-keying that stack from subscriber identity onto VLANs and prefixes. Section 3 explains why that re-keying is small, and it is the most useful technical argument on this page.
Performance figures here are engineering projections built on measured component behaviour, not results from a deployed border node. They are labelled where they appear. We would rather show you the arithmetic and its weak points than publish a number we cannot defend — and when we have a live deployment we will publish what it actually did.
The page in six lines
Border mode is uplink, downlink and routing — it is not a broadband gatewayTransit sessions upstream, customer VLANs downstream, FRR as the routing authority. No address translation, no subscriber sessions, no RADIUS. Those belong to our other deployment modes and are deliberately absent here.
Firewall, per-VLAN rate control, protections, AQM, L4S and latency measurement — on the border node itselfSection 2. All of it in software, on the same server that forwards the traffic.
The stack moves to a border because it was never keyed on subscriber identityThe firewall matches addresses and ports. Latency measurement keys on interface plus flow. Low-latency marking is a function of the rate limiter, not of who owns the line. Section 3 — the argument that makes the rest possible.
One pass over the packet, not six devices in seriesEach appliance you remove is also a hop, a failure domain, a power draw and a rack unit. Section 4.
Start at 160 gigabits, not 400Four 40-gigabit ports sits comfortably inside what the measurements support. 200G is defensible. 400G we would rather measure into than quote. Section 5 shows the arithmetic and names its weakest assumption.
Routing depth is conceded, not contestedNo MPLS, no SRv6, no IS-IS, no BFD. Section 7 states it plainly, because the absence of sub-second peer failure detection is the thing most likely to disqualify this node — and you should hear it from us on the first call.
01 What border mode is
One server sits between the transit providers you buy from and the network you run. Upstream it holds eBGP sessions with your upstreams. Downstream it presents VLANs — to your own gateway nodes, or directly to corporate customers. FRR is the routing authority; the fast path only ever executes what FRR has decided.
WHAT BORDER MODE DOES
Route, and protect what it routes
- Uplink: eBGP to your transit providers, full internet tables plus a default route, with multipath across them.
- Downlink: VLANs to gateway nodes or corporate customers, each with its own rate policy.
- Routing: FRR. It holds the sessions, runs best-path and owns the table. The fast path is an accelerator in front of it, never a second routing authority.
- Everything in section 2, applied as the packet passes through — not bolted on beside it.
WHAT BORDER MODE DOES NOT DO
It is not a broadband gateway
- No carrier-grade address translation. Not reduced, not licensed separately — simply not part of this mode.
- No PPPoE or IPoE session handling, and no subscriber authentication or accounting.
- Those functions are real, they are in production on our gateway products, and they belong on a different node. A border node has no subscribers to key them on.
- If you want one appliance doing both, that is a separate conversation and a different sizing exercise — ask us for it directly.
02 What runs on the border node
Six groups, all in software, all on the same server that is forwarding the traffic. Every one of these is written and running today in our subscriber products. What border mode changes is the thing each is keyed on — and section 3 is about why that change is small.
FirewallPriority-ordered rule chains matching source and destination address, prefix, port range and protocol, for IPv4 and IPv6. Accept, drop, redirect and jump-to-chain actions, with per-rule hit counters so you can see which rules are doing work and which are dead.
Rate control per VLAN and per addressA committed rate for each customer VLAN, or for individual addresses inside one. Same token-bucket engine that runs across thousands of subscriber lines on our gateway products today.
Attack mitigationVolumetric and protocol-vector detection — connection floods, datagram floods, control-message floods, fragment abuse — keyed on the prefixes you declare as your own, since a transit port has no subscriber to attribute traffic to.
Source-address validationReverse-path checking on traffic entering from a transit port, so spoofed sources are dropped at the edge rather than carried into your network.
Low-latency queue marking — L4S and AQMCongestion signalled to the sender by marking rather than dropping, using a sojourn estimate derived from the rate limiter, with the dual-queue coupling that lets latency-sensitive and bulk traffic share a link without the bulk traffic ruining it.
Latency and quality measurementRound-trip time measured passively from ordinary TCP traffic — handshake timing and TCP timestamps — per interface and per flow. No probe traffic, no agents, no synthetic tests.
The point is not that any one of these is rare. It is that they are in the same program. A firewall on a border router is unremarkable. A DDoS scrubber is unremarkable. Per-customer rate control is unremarkable. Having all of them execute in one pass over the packet, on the server that was going to forward it anyway, is the part that is different — and section 4 is about what that changes for your rack, your hop count and your bill.
03 Why this stack moves to a border at all
The obvious objection is that a protection and quality suite built for broadband subscribers should not work on a border router, because a border router has no subscribers. It is a fair objection and it is worth answering precisely. The answer is that almost none of these functions were ever keyed on subscriber identity. They are keyed on things a border node has in abundance: interfaces, flows, addresses and rate limiters.
| Function | What it is actually keyed on today | What that becomes on a border node | Size of the change |
|---|---|---|---|
| Firewall | Address, prefix, port range, protocol, and a chain identifier. There is no subscriber field in a rule. | Identical. The same rules describe the same traffic. | None. It transfers unchanged. |
| Latency and quality measurement | Interface index plus the flow’s address and port pair. The subscriber is identified by the interface — it is not what the measurement is keyed on. | The customer VLAN becomes the interface. Per-VLAN round-trip time and quality, from the same code. | None in the key. The entity changes meaning, not shape. |
| Low-latency marking — L4S and AQM | A queue-depth estimate divided by the configured rate. It is a property of the rate limiter, not of who owns the line behind it. | Put a rate limiter on a VLAN and the same marking follows it. Per-VLAN low-latency behaviour comes with per-VLAN rate control. | Follows the rate limiter. No new mechanism. |
| Rate control | A per-entity token bucket, one entry per subscriber. | One entry per VLAN, or per address inside one. Far fewer entries than a subscriber deployment, so the table stays small and cache-resident. | Re-key. Straightforward, and the easy direction. |
| Attack mitigation | Per-subscriber counters, with the subscriber as the victim being protected. | The victim becomes a prefix you declared as yours. Traffic destined anywhere else is not a candidate and costs one terminating lookup. | The largest change of the six, and the one we would not rush. Detail below. |
| Source-address validation | Checks a source address against what is legitimate for the interface it arrived on. | Same question, asked against the routing table instead of a subscriber binding. | Re-key, with a cost worth knowing — see section 5. |
Two honest notes, because both are the kind of thing a vendor normally leaves out of a page like this.
The mitigation engine should not simply be copied across. Reviewing it for this design surfaced two defects in the subscriber version, both now known and neither yet fixed: one rung of its escalation ladder is defined but never acted on, and its rate measurement uses a partial sample that any momentary dip resets, so escalation does not reliably converge. Its thresholds are also wrong for a border — aggregate rates there are far higher, and subscriber thresholds would flag ordinary traffic. These get fixed for border mode rather than inherited. We are telling you this because you would find it eventually, and it is better found here.
Rate control drops packets; it does not delay them. This forwarding model returns a verdict per packet and holds no packets, so there is no queue to delay anything in. A customer bursting above their committed rate sees loss where a traditional shaper would have given them delay. Many carriers police rather than shape and this is ordinary practice — but if your contracts assume burst tolerance, that is a commercial decision and you should make it deliberately. The low-latency marking above is the partial answer: a sender that understands the marks slows down before loss occurs, which is the whole point of it.
The mitigation engine should not simply be copied across. Reviewing it for this design surfaced two defects in the subscriber version, both now known and neither yet fixed: one rung of its escalation ladder is defined but never acted on, and its rate measurement uses a partial sample that any momentary dip resets, so escalation does not reliably converge. Its thresholds are also wrong for a border — aggregate rates there are far higher, and subscriber thresholds would flag ordinary traffic. These get fixed for border mode rather than inherited. We are telling you this because you would find it eventually, and it is better found here.
Rate control drops packets; it does not delay them. This forwarding model returns a verdict per packet and holds no packets, so there is no queue to delay anything in. A customer bursting above their committed rate sees loss where a traditional shaper would have given them delay. Many carriers police rather than shape and this is ordinary practice — but if your contracts assume burst tolerance, that is a commercial decision and you should make it deliberately. The low-latency marking above is the partial answer: a sender that understands the marks slows down before loss occurs, which is the whole point of it.
04 One pass, not a chain of boxes
The conventional way to get this list of functions at a border is to buy them separately and put them in series: a router, a firewall, a scrubbing appliance or a scrubbing subscription, and whatever does rate control. Each one is a hop, a failure domain, a power draw, a rack unit and a support contract. Border mode applies the same functions as consecutive decisions inside a single program, on the packet the server was already going to forward.
Every appliance you take out of the path is also a hop you stop adding latency at, a device that can no longer fail independently, and a contract you stop renewing. That is the argument — not that our firewall is better than a firewall vendor’s.
05 How much traffic one server carries — and where to start
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 the hardware you would deploy. A different processor family means a different cache hierarchy, and this measurement is almost entirely about cache behaviour. The shape of the curve transfers. The absolute numbers do not.
- They measure a route lookup and nothing else. Section 2’s functions are not in these figures; their estimated cost is folded in further down, as an estimate and labelled as one.
- 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 each is an upper bound rather than a forwarding rate.
| 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 rather than a forwarding rate.
| 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. |
From a lookup rate to an interface size — and where to start
Read this before the table, because it is the weakest reasoning on the page. Everything above is a routing-lookup rate with no network adapter in the path. Turning that into an interface size requires estimating everything the lookup does not include — header parsing, checksum update, layer-2 rewrite, the policing lookup, the mitigation lookup, driver receive and transmit, and direct memory access.
- We estimate that additional work at two to four times the lookup cost. It has never been measured. It is an estimate, it is the largest single factor in every figure below, and it decides the answer. No hardware should be bought against it.
- Strict reverse-path filtering is a second routing lookup on every packet, which roughly doubles the dominant cost. The looser form that only checks the arrival interface is one lookup. At these rates that difference is not cosmetic — it is a design decision with a price, and the figures below assume the looser form.
- One thing here is measured and helps: packet size does not change the lookup cost at all — 103, 103 and 104 nanoseconds at 64, 512 and 1,500 bytes. So applying a rate measured at 64 bytes to a 700-byte traffic mix is legitimate, and it is the one step in this chain that adds no assumption.
At a 700-byte average — a normal internet mix, not a worst case — the arithmetic is straightforward. What it shows is that the entry configuration is comfortable and the largest one is not, and the honest recommendation is to start at the bottom of this table rather than the top.
| Interface configuration | Aggregate | Packets/s at ~700 B | Cores for lookup only — real-world locality | Cores for lookup only — adversarial | Estimated cores in a real datapath, realistic mix |
|---|---|---|---|---|---|
| Four 40G ports — the starting point A small, ordinary server. The adapter family here is the one our production nodes already run. |
160G | 27.8 M | 3.1 | 15.1 | 6 – 13 |
| A single 200G port | 200G | 34.7 M | 3.9 | 18.9 | 8 – 16 |
| A single 400G port | 400G | 69.4 M | 7.8 | 37.7 | 16 – 31 |
How to read the last column, and what it hides. It is the real-world-locality lookup cost multiplied by the two-to-four-times estimate above, with the looser form of reverse-path filtering. Change any one of three things and it stops holding: pick strict reverse-path filtering and double it; assume the adversarial destination spread instead of the measured one and multiply by nearly five; drop the average packet size and it rises in proportion. The adversarial column is in the table precisely so that the pessimistic case is visible next to the optimistic one, rather than mentioned in a footnote. No figure in this table has been measured on a network adapter.
WHERE WE WOULD START
Four 40G ports, on an ordinary server
- 160G aggregate for roughly six to thirteen cores of forwarding on a realistic traffic mix — leaving most of a mainstream processor free for the subscriber role, the routing software, or simply for headroom.
- It sits well inside the range these measurements support, so it does not depend on the optimistic end of any assumption on this page.
- Its adapter family is the one we already run in production and have the most operational evidence for — including for the specific failure discussed below.
- It is the configuration we would build first, measure honestly, and only then talk about anything larger.
WHERE WE WOULD BE CAUTIOUS
A single 400G port
- It needs every assumption on this page to land favourably at once: real-world destination locality rather than adversarial, the looser reverse-path check, a healthy average packet size, and the multiplier nearer two than four.
- Any one of those going the other way puts it out of reach on a single machine.
- The adapters that reach it are outside the family we have production evidence for.
- We would rather measure into 400G than quote it. The largest configuration we would put in front of an operator today is 200G.
Network adapters — corrected
An earlier draft of this analysis was wrong about the hardware, and the correction widens the options rather than narrowing them. It claimed the adapter family we use tops out at 100G and that anything above it meant changing vendor. That is out of date: a 200G model exists in the current generation of that family, and 400G adapters are available from the other major vendor. The practical consequence is that 200G no longer requires leaving the silicon lineage our production nodes already use.
| Option | Aggregate | Fast-path driver support | What we actually know about it |
|---|---|---|---|
| Four 40G ports — entry | 160G | Mature — in production on our own nodes today | The most evidence of any option here. This driver family carries live subscriber nodes in our fleet, and it is the only one where we have tested the detach behaviour described below and found it clean. |
| Current-generation 200G adapter, same vendor family | 200G | Expected, not verified by us | Same silicon lineage as adapters we run, which is a reasonable basis for expecting fast-path support — and not a substitute for confirming it. We have not tested this part. |
| 400G adapter, other major vendor | 400G | Believed mature, unverified by us | No first-hand data at all. Different vendor, different driver, and the buffer-recycling behaviour discussed below has never been observed on it by us. |
One hardware caveat applies to every row above, and it is the one we would raise first in an evaluation. Detaching a fast-path program from an interface can strand the driver’s packet buffer pool, and when it happens the machine does not recover. We have measured this directly: on one virtualised adapter it occurred on four attempts out of four; on the production adapter family in the entry configuration it occurred on none out of one, on a live node carrying 5,317 subscribers. That is a small sample and we present it as one. Whichever adapter an operator chooses, this behaviour has to be re-established on that specific part before the node goes into production — and the entry configuration is the only one where we have any evidence at all.
Three additions the wider scope requires, with what each costs
The forwarding core in section 4 resolves a route and forwards. Full-table transit with customer VLANs needs three things it does not have. None is written. The sizes below are estimates against a program-size ceiling of four million, and the useful conclusion is that the ceiling is not the constraint — per-packet cost is, which is why each of these lands in the multiplier above rather than in a budget.
| Addition | Why the wider scope needs it | Estimated program size |
|---|---|---|
| Multipath across transit sessions | This one fails silently, which makes it the most dangerous item here. If the forwarding path does not supply port numbers to the route lookup, multipath collapses onto a single upstream. Nothing reports an error. Throughput is simply a fraction of what was bought, with no indication why. Any operator evaluating a multipath transit edge should test for this explicitly, on any vendor. | +50 |
| Per-VLAN and per-address rate enforcement | Corporate customers on inside VLANs are sold a committed rate. Reuses the rate limiter running today across thousands of subscribers with no drops attributable to it — re-keyed on VLAN rather than subscriber, which is far fewer entries. | +500 |
| Mitigation keyed on declared prefixes | A transit port has no subscriber identity, so detection is keyed on the destination being one of the operator’s own declared networks. Traffic to anywhere else is not a candidate and costs one terminating lookup. | +600 |
| Total against a four-million ceiling | ≈2,650 — negligible | |
Two honest notes on the additions, because both are the kind of thing a vendor normally leaves out.
The rate enforcement drops packets; it does not delay them. This forwarding model returns a verdict per packet and holds no packets, so there is no queue to delay anything in — the kernel proposal that would add one is still unmerged. A corporate customer bursting above their committed rate therefore sees loss where a traditional shaper would have given them delay. Many carriers police rather than shape and this is accepted practice, but if your contracts assume burst tolerance it is a commercial decision, not a technical footnote.
The mitigation cannot simply be copied from the subscriber engine. Reviewing it for this design surfaced two defects in the subscriber version, both now known and neither yet fixed: one rung of its escalation ladder is defined but never acted on, and its rate measurement uses a partial sample that any momentary dip resets, so escalation does not reliably converge. Its threshold policy is also wrong for transit — aggregate rates at a transit edge are far higher, and the subscriber thresholds would flag ordinary traffic. These have to be fixed here rather than inherited.
The rate enforcement drops packets; it does not delay them. This forwarding model returns a verdict per packet and holds no packets, so there is no queue to delay anything in — the kernel proposal that would add one is still unmerged. A corporate customer bursting above their committed rate therefore sees loss where a traditional shaper would have given them delay. Many carriers police rather than shape and this is accepted practice, but if your contracts assume burst tolerance it is a commercial decision, not a technical footnote.
The mitigation cannot simply be copied from the subscriber engine. Reviewing it for this design surfaced two defects in the subscriber version, both now known and neither yet fixed: one rung of its escalation ladder is defined but never acted on, and its rate measurement uses a partial sample that any momentary dip resets, so escalation does not reliably converge. Its threshold policy is also wrong for transit — aggregate rates at a transit edge are far higher, and the subscriber thresholds would flag ordinary traffic. These have to be fixed here rather than inherited.
06 What you would buy elsewhere to get the same function set
This is the comparison that is actually ours to make, and it is narrow on purpose. We are not going to argue that our routing is better than a chassis vendor’s. It is not, we concede it in section 7, and a page that argued otherwise would deserve the rebuttal it would get. The question worth asking is different: if you want this list of functions at your border, what does each vendor require you to buy, and how many boxes does it end up being?
| To get this at the border | Chassis router vendors | Software BNG vendors | Commodity-hardware router platforms | Border mode |
|---|---|---|---|---|
| Full-table transit routing | Yes — and better than ours. This is what the platform is for. | Yes | Yes | Yes, via FRR — in development |
| Firewall on the same device | Usually a licensed feature, sometimes a service card | Varies by product | Yes | Included |
| Volumetric attack mitigation on the same device | Typically a separate appliance or a scrubbing subscription | Varies; often partial | Rule-based only, at software forwarding rates | Included, in the forwarding path |
| Per-customer committed rates | Yes — and the hierarchy is deeper than ours | Yes | Yes | Included |
| Modern low-latency congestion signalling | Emerging; varies sharply by platform and release | Varies | Queue disciplines are well documented; the coupled dual-queue form is not the default | Included |
| Passive per-customer latency measurement, no probes | Generally a separate assurance product | Generally absent or a separate product | Absent | Included |
| Runs on a server you already know how to buy | No — proprietary chassis and line cards | Yes | Yes | Yes |
How to read this table, and its limits. Vendor columns describe deployment model — what has to be purchased and how many devices result — and not capability depth, where several of these vendors are ahead of us and section 7 says where. Cells reflect what each vendor’s public documentation showed on the access dates given in the sources below; a cell never asserts that a capability does not exist, only that we did not find it documented. Vendor documentation changes between releases. Verify anything here that would change your decision, with the vendor, before it changes your decision. The border-mode column describes software in development, and is marked accordingly on the row where that matters most.
The honest summary of this table: for the top row, a chassis vendor beats us and will keep beating us. For the middle five, the difference is not that our version is better — it is that ours is already inside the box that forwards the packet, and theirs is usually another purchase, another rack unit and another hop. If you only need the top row, buy a router. If you need the middle five as well, the count of boxes is the argument.
07 What border mode does not do
Two kinds of limit follow. The first is what the border role will not do whatever we build next. The second is where a competitor is simply ahead of us — which belongs on this page because a comparison that omits it is a rigged comparison, and because section 6 is worthless without it.
| Capability | In border mode | Why | What that means for you |
|---|---|---|---|
| BFD — sub-second peer failure detection | No | The routing software is built without it. Peer failure is detected on BGP hold time instead. | This is the sharpest limit on the page. Tolerable with a second path and a default route. Not acceptable where sub-second convergence is contractual — and if it is, tell us on the first call. |
| 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. |
| 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. |
| Carrier-grade address translation, subscriber sessions, subscriber accounting | Not in this mode | A deliberate separation. A border node has no subscribers to key them on, and these functions belong on a gateway node. | Not a gap — a different product mode. All three run in production on our gateway products. Ask us about those separately. |
| Traffic shaping, as distinct from policing | No | This forwarding model holds no packets, so there is no queue in which to delay one. Excess traffic is dropped or marked, never delayed. | Ordinary carrier practice, and a commercial decision if your contracts assume burst tolerance. The low-latency marking is the partial answer. |
| 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 BFD, MPLS, SRv6 or IS-IS should buy a router, and we will say so during an evaluation rather than after one. Section 6 is worth nothing unless this section is complete and early. A border role honestly scoped as “IPv4 and IPv6 unicast transit with full tables and multipath, with a firewall, per-VLAN rate control, attack mitigation, low-latency marking and latency measurement in the same pass — and no MPLS, no IS-IS, no BFD” is worth having. One marketed as a chassis-router replacement would cost us more than the role is worth.
08 Where this stands, and what happens next
Border mode is being built now. This is the order it is being built in, and the reasoning behind the order — so that you can judge the distance between this page and something you could run, rather than take our word for it.
DONE
The capability set
- Firewall, rate control, attack mitigation, source validation, low-latency marking and latency measurement are written and running in production on our gateway products.
- That is the bulk of the engineering, and it is behind us.
DONE
The forwarding core
- The border forwarding program is written: route resolution against FRR’s table, with a clean hand-off to the operating system for anything it declines.
- Design review complete, covering datapath structure, control-plane integration and failure modes.
NEXT
Load it, attach it, forward a packet
- Verify the program, attach it to a port, and compare what it emits 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 — the reversibility the design depends on.
THE NUMBER THAT DECIDES THE SIZING
Measure a whole forwarding path, adapter to adapter
- Section 5 converts a lookup rate into an interface size using an estimate of two to four times for everything the lookup does not include. Every sizing figure on this page rests on it.
- Until it is measured end to end, the interface table is arithmetic on an assumption — and we would rather you knew which assumption. It is roughly a day of work with a traffic generator, and it should happen before anyone buys an adapter.
- The same run settles the reverse-path-filtering question, which is worth a factor of two on its own.
RE-KEY THE STACK
Subscriber → VLAN and prefix
- Section 3 is the plan. The firewall and the latency measurement transfer with no change to what they key on; rate control and marking follow the rate limiter.
- Multipath across transit sessions comes first, because it is the one that fails silently — and it gets proved by confirming traffic actually spreads across the upstreams, not by reading the code.
- Attack mitigation is last and deliberately unhurried: two known defects get fixed rather than inherited, and thresholds get designed for border rates instead of ported from subscriber ones.
Every number on this page has a way of being proved wrong, and each of those ways is listed above. We would rather hand you the list than have you find it during an evaluation.
What would help us most, if this is interesting
Not an order. A topology and a traffic profile. Tell us how many transit sessions, how many customer VLANs, and roughly what average packet size your border sees. Section 5 shows that the destination mix and the packet size move the result far more than the hardware does, so those two facts change the sizing more than anything else you could tell us.
The second thing worth telling us is which functions in section 2 you are currently paying for separately — a scrubbing subscription, a firewall appliance, an assurance product. That is where the argument in section 4 is either real for you or it is not, and it is a short conversation either way.
And if any row in section 7 is a hard requirement — particularly BFD — 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 2, the capability set — each function described there is present in our shipping gateway software and running on live operator networks. The descriptions are of what that code does, read from the implementation, and not of border-mode behaviour, which has not yet been observed.
- Section 3, how each function is keyed — read directly from the data structures in our own source: the firewall rule record, the flow-measurement key, and the sojourn calculation used for low-latency marking. This is the basis for the claim that the stack is not keyed on subscriber identity, and it is verifiable by us on request under a suitable agreement.
- Sections 1 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. The border forwarding program has not yet been loaded or attached.
- Section 5, locality and lookup rate — a destination-locality study completed in August 2026. Destinations were captured read-only from a live node, then replayed on an AMD development host against a synthetic million-prefix routing table. Routing-lookup microbenchmarks with no network adapter in the path; every run was checked to confirm the lookup actually executed, because an earlier version of the harness reported far higher figures while silently never running it.
- Section 5, interface sizing — arithmetic on the section 5 lookup rates, using an estimated two-to-four-times multiplier for the rest of a real forwarding path. That multiplier has not been measured end to end, it is the largest single factor in those figures, and it is identified as such where it appears.
- Section 5, network adapter behaviour — first-party observation of buffer-pool behaviour on fast-path program detach: four occurrences in four attempts on one virtualised adapter, none in one attempt on the production adapter family, the latter on a live node carrying 5,317 sessions. A small sample, presented as one.
- Section 7, 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 6 and 7, 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.3 — accessed 3 August 2026. Cisco: IOS XR documentation via Internet Archive snapshots — accessed 3 August 2026; cisco.com was not reachable from the research environment, and an archive snapshot proves what was published at that moment, not what is current. MikroTik: help.mikrotik.com queue documentation — accessed 3 August 2026.
- Status — border mode appears under roadmap in our platform capability catalogue. This page is consistent with that entry and does not supersede it.
What this document is. It describes border mode, which is in development, and it is a capability and design document rather than a report on a deployed system. The functions in section 2 are implemented and running in our shipping gateway software; the border role that hosts them — the forwarding core, and the re-keying described in section 3 — is being built now and has not yet been loaded, attached or run in a network. Nothing here should be read as describing a node available to order today, and no delivery date is offered or implied.
About every performance figure. All of them are either routing-lookup microbenchmarks produced on an AMD development host, or arithmetic built on top of those microbenchmarks. They involve no network adapter, no driver receive or transmit path, no direct memory access and no packet arriving from anywhere, and they were taken on a development host rather than on the hardware an operator would deploy. The shape of the curves transfers; the absolute numbers do not. The conversion from a lookup rate to an interface size additionally uses an estimated two-to-four-times multiplier that has not been measured end to end. Every figure on this page is therefore an upper bound or a projection, and none is a forwarding rate observed on a border node. We will publish measured figures when a border node exists to measure.
About the capability descriptions. Section 2 describes what the implemented code does today in a subscriber deployment. Section 3 sets out, per function, what changes when it is re-keyed for a border. Where a change is required it is named and sized rather than glossed over — including the two known defects in the attack-mitigation engine, which are documented on this page precisely because they must be fixed for border mode rather than carried into it.
Rate control is policing, not shaping. This forwarding model returns a verdict per packet and holds no packets. Traffic above a committed rate is dropped or marked, never delayed. If your customer contracts assume burst tolerance, that is a commercial consideration and it should be decided deliberately rather than discovered later.
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 sources; it does not assert that a capability is unavailable. Vendor documentation changes between software releases, and a capability we did not find may exist. Comparisons address deployment model — what must be purchased and how many devices result — rather than capability depth, where section 7 records where competitors are ahead of us. Verify anything that would change a purchasing decision with the vendor directly.
About every performance figure. All of them are either routing-lookup microbenchmarks produced on an AMD development host, or arithmetic built on top of those microbenchmarks. They involve no network adapter, no driver receive or transmit path, no direct memory access and no packet arriving from anywhere, and they were taken on a development host rather than on the hardware an operator would deploy. The shape of the curves transfers; the absolute numbers do not. The conversion from a lookup rate to an interface size additionally uses an estimated two-to-four-times multiplier that has not been measured end to end. Every figure on this page is therefore an upper bound or a projection, and none is a forwarding rate observed on a border node. We will publish measured figures when a border node exists to measure.
About the capability descriptions. Section 2 describes what the implemented code does today in a subscriber deployment. Section 3 sets out, per function, what changes when it is re-keyed for a border. Where a change is required it is named and sized rather than glossed over — including the two known defects in the attack-mitigation engine, which are documented on this page precisely because they must be fixed for border mode rather than carried into it.
Rate control is policing, not shaping. This forwarding model returns a verdict per packet and holds no packets. Traffic above a committed rate is dropped or marked, never delayed. If your customer contracts assume burst tolerance, that is a commercial consideration and it should be decided deliberately rather than discovered later.
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 sources; it does not assert that a capability is unavailable. Vendor documentation changes between software releases, and a capability we did not find may exist. Comparisons address deployment model — what must be purchased and how many devices result — rather than capability depth, where section 7 records where competitors are ahead of us. Verify anything that would change a purchasing decision with the vendor directly.