ORIONOS 7.05 · PLATFORM RELEASE
STABLE CHANNEL · NOVEMBER 2026

Draft. Values shown as pending or as hatched shapes are waiting for the full rc4 characterisation run (both datapath modes). Every other number on this page is measured on the published 7.05 image.

NEW OrionOS 7.05 · stable channel

128,000 subscribers. Zero-downtime operations.CGNAT port blocks that never leak.

OrionOS 7.05 brings a new traffic-engine data layout, CGNAT port blocks that are never shared or lost, NAT logs that stay complete across restarts, DHCP server ports closed on the uplink, and security updates for OpenSSH, rsync and atftpd. It contains everything from the unpublished releases 7.01 to 7.04, so a gateway moves to it with one image upgrade. Every number marked measured comes from the published 7.05 image at 128,000 live PPPoE subscribers with traffic.

01128k, measuredOnline in 344 s, 0 flaps
02Zero-downtime opsUpgrade and restart with traffic
03CGNAT blocksNever shared, never lost
04Complete NAT logsContinuous across restarts
05One lookup per packetOn every WAN layout
06Hardened edgeDHCP closed on the uplink
07One-step upgradebngctl first, then the image
08E810 sizing100G vs 200G, explained

The 7.05 lab run at a glance · measured on the published image

128,000PPPoE subscribers online with traffic

344 sfrom zero to all 128,000 online (~372 per second)

0session flaps and 0 datapath seeding or allocation failures in the ramp

0NIC drops at 0.98 Mpps / 11 Gbit/s with all 128,000 online

~2 of 64

CPU threads busy at 128,000 subscribers with 11 Gbit/s of traffic

3 ppm

download loss at the 128k plateau (640 of 640 streams flowing)

~2 s

to close 2,000 IPoE sessions after the access side goes quiet

0.21 s

for a bandwidth view of all 128,000 subscribers

01What your company gets with 7.05

Each part of 7.05 changes something an ISP pays for: maintenance windows, support calls, compliance work or risk at the network edge.

No maintenance window

Within 7.05, the traffic engine and the session service update live. Subscribers stay online and billing continues, because sessions keep their Acct-Session-Id.

CGNAT you can trust

A port block is never shared by two subscribers and never lost until a restart. A released block waits 60 s before anyone else gets it, and a check every 10 minutes repairs any leak.

Complete legal logs

NAT logs (syslog and IPFIX) stay continuous across traffic-engine restarts. QoS-only mode now logs every new UDP flow and inbound port-forward flows, with the public port on every IPv4 record.

A harder edge

DHCP server ports 67 and 547 are dropped on the uplink, NULL-scan TCP is dropped in both datapath modes, and OpenSSH, rsync, atftpd and the kernel carry current security fixes.

Fast recovery

128,000 subscribers come online in 344 s after a mass redial, with 0 flaps. IPoE sessions behind a silent access switch are closed in seconds, with Accounting-Stop.

Fewer surprises

CGNAT pool changes that need a restart are held, not half-applied, and are shown as pending. Unclear yes/no settings are reported. A bandwidth view of 128,000 subscribers takes 0.21 s.

02How 7.05 is built

One standard x86 server. The traffic engine runs as XDP inside the NIC driver; the session service handles PPPoE, IPoE and RADIUS; NOC2 manages the fleet. In QoS-only mode XDP shapes and counts, and the kernel does NAT. In full-CGNAT mode XDP does NAT and firewall too, and sends the packet straight to the WAN.

OrionOS 7.05 architecture

by design

XDP datapath (both modes)QoS-only: kernel NAT pathfull-CGNAT: NAT in XDP, direct to WANmanagement

03Performance at 128,000 subscribers

The lab server is an AMD EPYC 9375F (32 cores / 64 threads, 128 GB) with two Intel E810 100G ports. A traffic generator emulates 128,000 PPPoE subscribers and sends traffic on 640 + 640 streams (every 200th session, both directions). The generator has 2 × 10G ports and tops out at about 1.2 million packets per second, so it is the limit in these tests, not the BNG.

measured

344 s

zero to 128,000 subscribers online: ~372 new subscribers per second, 0 flaps

measured

11.07 Gbit/s

at the plateau: 0.984 Mpps of 1,400-byte packets, 0 NIC drops over 156 s

measured

2.16

of 64 CPU threads busy at the 128k plateau with traffic (QoS-only)

measured

173 s

to close all 128,000 sessions in a mass logout, nothing left behind

Throughput at 128k, per mode

pending

P1 = 1,400-byte packets (bandwidth). P2 = 128-byte packets (packet rate). Both are capped by the traffic generator (2 × 10G, ~1.2 Mpps).

XDP time per packet, per mode

pending

Nanoseconds of XDP program time per packet from the kernel's BPF statistics, at 128,000 subscribers. Lower is better. Includes the cost of the statistics themselves.

CPU used at 128,000 subscribers (64 threads)

measured

Packet processing cost, QoS-only

measured

Softirq and drops: 30 samples of 30 s at 128,000 subscribers, ~1 Mpps. Softirq = CPU time spent receiving and processing packets.

The CPU is not the limit. With 128,000 subscribers online and the traffic generator at its ceiling, the datapath used about two of 64 CPU threads and dropped nothing at the NIC. On a BNGSOFT server the network card and its PCIe slot decide how much traffic one box carries. See section 12.

04How the server scales with subscribers

We profile CPU and memory at 20,000, 40,000, 80,000 and 128,000 subscribers in every run, so a cost that grows faster than the subscriber count shows up early.

Busy CPU threads vs subscribers

pending

QoS-onlyfull-CGNAT

Memory vs subscribers (QoS-only)

measured

bngsessd (session service)bngxdpd (traffic engine)

Memory = resident set size at each point of the ramp. At 128,000 subscribers the session service holds ~17 KB and the traffic engine ~4 KB per subscriber. The server had 128 GB.

05Zero-downtime operations, measured with traffic

A BNG is upgraded and restarted far more often than it is installed. 7.05 does all three of the risky moves with 128,000 subscribers online and traffic flowing, and we measure loss, flaps and billing records for each.

What happens during each event

by design

Packet loss during each event (ppm, 640 + 640 streams)

pending

QoS-only, eventfull-CGNAT, eventcontrol window, no event

ppm = lost packets per million sent, download direction, from the generator's per-stream counters. Each event is shown next to a control window of the same length taken just before it, so the noise floor of the measurement is visible.

At 128,000 subscribers with traffic	QoS-only	Full-CGNAT
Session flaps (all three events)	pending	pending
Accounting-Stop records sent by a crash (kill -9)	pending	pending
Sessions online after the live upgrade	pending	pending
Soak: loss over 6 × 300 s at full traffic	pending	pending
NIC page-pool warnings after every event	pending	pending

06CGNAT port blocks: never shared, never lost

In full-CGNAT mode each subscriber gets a block of ports on a shared public address. If a block is handed out twice, one customer receives another customer's traffic. If a block is lost, a public address slowly fills up. 7.05 closes both doors.

The life of a port block

by design

100%

of every public IP's port range is handed out. Active subscribers get X blocks of 128 ports (504 blocks per IP); inactive (walled-garden) subscribers get one 64-port block (1,008 blocks per IP). Before 7.05 the allocator stopped at block 512, so a 64-port pool filled at half its capacity.

by design

≥ 60 s

before a released block goes to another subscriber, even when the public IP has run out of blocks.

by design

10 min

between reconcile checks. repair by default; detect and off are available.

pending

RELEASE records written when 128,000 full-CGNAT subscribers were torn down, one per allocated block.

No half-applied pool changes. Changing pools, public IPs, the port range, the block size or deterministic mode needs a CGNAT cold start. In 7.05 a config reload keeps the running values for these keys and lists them as cgnat_restart_pending in NOC status and in bngxdpctl cgnat pool, so the box never runs on a mix of old and new pool settings.

07NAT logs that stay complete across restarts

A legal request asks "who had this address and port at this time?". The answer is only as good as the log. 7.05 keeps the log continuous when the traffic engine restarts, and widens what QoS-only mode records.

The NAT log across a zero-downtime restart and a stop/start

by design

both modes

Continuous across restarts

A zero-downtime restart no longer writes a second ALLOC for every live subscriber. A stop followed by a start writes matching RELEASE and ALLOC records. Syslog and IPFIX both.

QoS-only

Every new UDP flow

Games, VoIP, VPN, any port, not only DNS and QUIC. Inbound port-forward flows are logged too, and every IPv4 record carries the public (translated) port.

pending

Measured across a restart

NAT log completeness across a zero-downtime restart at 128,000 subscribers: pending.

For legal logging: syslog over UDP can lose records on the network or at the collector, and the box cannot see this. Use TCP or RELP forwarding with a disk-assisted queue. QoS-only UDP records are rate-limited to 1,250 per second per CPU.

08IPoE sessions close in seconds

When a switch or OLT on the access side goes quiet, its IPoE subscribers must be released quickly, with Accounting-Stop, so that billing is right and addresses and CGNAT blocks return to the pool.

2,000 IPoE subscribers, full-CGNAT mode

measured

Measured	Result
Sessions active after the access side stopped	0 after ~2 s
Sessions with a Terminate-Cause	2,000 of 2,000
Terminate-Cause	User-Request
Sessions terminated twice	0

A CLI or RADIUS terminate also ends an IPoE DHCP session at once, with Accounting-Stop; the customer router gets a DHCPNAK at its next renewal. The configuration migration sets this on every upgraded box.

09One forwarding answer per packet, on every WAN layout

Every upload packet needs a routing answer: which WAN interface, which next hop. The 7.05 engine asks the kernel's forwarding table once and reuses that answer for the egress, on all three WAN layouts we see in the field.

The three WAN layouts

tested on the lab server in both datapath modes

Per-packet cost of the forwarding path

pending rc4 rerun

Median of repeated runs of the full XDP program per case (bpftool prog run) on the published 7.05 engine. "Answer reused" is what the engine does when the WAN interface is recognised; "second lookup" is the path it takes otherwise. A microbenchmark measures the program alone, not a loaded server.

Why it matters: on a BNG every upload packet goes to the WAN. Asking the forwarding table once instead of twice saves work on every packet, and the gateway's own addresses are still recognised and passed to the gateway.

IPv6 note: the reused path for IPv6 needs the IPv6 uplink VLAN to be listed in native_wan_vlans (or to be the first download interface). Otherwise IPv6 takes the second-lookup path: about 80 ns slower per packet, same result.

10Security and hardening

uplink

DHCP closed to the internet

DHCP server ports 67 (DHCPv4) and 547 (DHCPv6) arriving on the uplink are dropped by the firewall template. A DHCP server for subscribers must never be reachable from the internet side.

packages

Current security releases

OpenSSH 10.6p2, rsync 3.5.2, atftpd 0.8.1 and kernel 7.3.4. The session service carries bounds fixes in DHCPv4 option handling and the CLI parser.

both modes

NULL-scan TCP dropped

TCP packets with no flags set are dropped in QoS-only and full-CGNAT mode; full-CGNAT also screens IPv6 TCP the same way. Normal TCP is not affected.

scoped

SSH, DNS, SNMP rules aimed right

Protection rules for ports 22, 53 and 161 apply only to traffic addressed to the gateway itself. Subscribers' own traffic on these ports is no longer dropped by them.

walled garden

Inactive means inactive

Subscribers in the inactive pool are really walled, and a rate CoA no longer reactivates them. NOC inactive walls a subscriber at once and keeps the same public IP.

full-CGNAT

Traffic to the gateway goes to the gateway

Subscriber upload addressed to one of the gateway's own addresses is passed to the gateway, not treated as internet traffic.

11Operator tools

Bandwidth view of 128,000 subscribers

measured · A/B/A

Wall time of bngxdpctl list --format bw at 128,000 subscribers, 3 runs each, in the order daemon / direct / daemon. The engine keeps a ready snapshot, so the command reads it instead of walking the datapath maps.

Plan rate in sub show and diag
The subscriber's RADIUS or CoA rate is shown; a direction without a limit reads "unlimited".
NOC API tells you what really happened
config_set returns written, restart_required and held_keys next to applied.
Unclear settings are reported
A yes/no setting written as 1 or "on" logs an is not a boolean warning when it differs from the value used.
Lower idle CPU
Faster flow-tracker clean-up after a load ends.

12Hardware sizing: the Intel E810 and 100G vs 200G

At 128,000 subscribers the CPU has room to spare, so the network card decides how much traffic one server carries. The most common choice, the Intel E810-CQDA2, has two 100G ports but one controller: it carries 100 Gbit/s in total, in any bond mode.

E810-CQDA2 bonding	Maximum	How it behaves
Active-backup (mode 1)	100 Gbit/s	Only one port is active. The second stands by and takes the traffic only if the first fails.
LACP (mode 4) / XOR (mode 2)	100 Gbit/s total	Traffic is shared between the two ports. Because of the chip's internal limit they balance dynamically (for example 2 × 50 or 60 + 40 Gbit/s), but the sum never exceeds 100 Gbit/s.
Split with Intel EPCT	100 Gbit/s total	2 × 50, 4 × 25 or 8 × 10 Gbit/s: more ports, the same ceiling.

Why the limit: the card sits in a PCIe 4.0 x16 slot, which in theory carries more than 250 Gbit/s. The controller is the limit, at 100 Gbit/s aggregate for the whole card.

For a real 200 Gbit/s by bonding two 100G ports, Intel offers the more expensive E810-2CQDA2 (note the "2CQDA2"). It has two separate controllers on one board and supports the full 200 Gbit/s. Two E810-CQDA2 cards in two x16 slots also work.

Subscriber traffic enters and leaves through the same card (access VLAN in, WAN VLAN out), so plan the card's capacity for both directions together.

13The upgrade path: bngctl first, then the image

7.05 contains everything from 7.01 to 7.04. A gateway on 7.00 or older moves to it with one image upgrade and one reboot in one window, and its configuration is migrated on the way. After that, live updates work again.

data layout

Why one image step

7.05 uses a new shared data layout for the traffic engine, so a box older than 7.01 takes the image and a reboot, not a live update. The live update tools refuse such a box with a clear message.

fix forward

No rollback to the old layout

There is no rollback to a pre-7.01 image or to the old session service. A failed upgrade is fixed forward, so plan the window and keep the console reachable.

after the upgrade

One check to make

Look for is not a boolean in the traffic-engine log and correct those keys to true or false, checking each first: some switch on a mode that needs a CGNAT cold start.

14Zero-touch install from NOC2

A new BNG should not need an engineer on site. The BNGSOFT live installer sets up a server from an install code created in NOC2, over the server's remote console or network boot.

Create the box in NOC2Choose QoS-only or full-CGNAT, the ports and the addresses. NOC2 gives you an install code.

Boot the installerFrom the remote console or network boot. The first stage is small, so a slow management link is fine.

Enter the codeThe box claims its slot and downloads the image and tools. Every file is checked against its sha256.

Install and verifyThe disk is written, then read back from the disk itself before anything is trusted.

Boot and reportThe box boots with a configuration built from the same template as the rest of your fleet, and reports to NOC2.

15How 7.05 was tested

The published image went through the same gates on two kinds of system: a 128,000-subscriber lab server with traffic in both datapath modes, and two demo gateways that run like customer boxes, one per mode. Each gate had a pass/fail rule set before it ran.

What a pass means: every probe was first shown to be able to fail, so a quiet result really means nothing broke. A configuration that survives save, verify and reboot is checked from the saved copy, not from memory.

16Read before you upgrade

We list the limits we know, so that you plan for them rather than discover them.

Area	What to know
DHCP relay	A box with `dhcpv4-relay=` whose DHCP server answers through the uplink needs an accept rule before the new drop (port 67, and 547 for DHCPv6). A read-only survey of 175 gateways found no relay configured.
Full-CGNAT after a mass redial	On a pool more than about 50% used, new flows can be refused for up to 60 s while released blocks wait out the reuse delay. Watch `block_alloc_failures` and `refused_min_age`.
Untagged WAN	The check for gateway addresses costs up to about 50 ns per untagged upload packet that passes through.
Syslog over UDP	Can lose records without the box seeing it. For legal logs use TCP or RELP with a disk-assisted queue, and check that local4 is forwarded at all.

17What ships in OrionOS 7.05

Traffic enginebngxdpd 4.0.31 · XDP, QoS-only and full-CGNAT

New shared data layoutLive updates within 7.05; one image step to get there.
CGNAT block safetyReuse delay, full use of every public IP, 10-minute reconcile.
Continuous NAT logNo duplicate ALLOC on a zero-downtime restart.
One forwarding lookupOn tagged and untagged WAN layouts.

Session servicebngsessd 2.0.25 · PPPoE, IPoE, RADIUS

Fast IPoE terminateAccounting-Stop at once, DHCPNAK at renewal.
Safe live updateChecks the data layout before it changes anything.
New namesbngsessd, bngsessctl; old names kept as links.

PlatformOrionOS 7.05 · bngctl 6.16

Kernel 7.3.4OpenSSH 10.6p2, rsync 3.5.2, atftpd 0.8.1.
DNS resolver 43.4.7Flow exporter 1.14.1.
Firewall templateDHCP ports closed on the uplink.
Config migrationRuns with the image upgrade.

See 7.05 at 128,000 subscribers

We can show the 7.05 lab run live, walk your team through the upgrade path, and size a server for your subscriber base, busy-hour traffic and NIC choice.

Request a demo Read the sizing guide →

Figures marked measured come from a BNGSOFT lab system (AMD EPYC 9375F, 32 cores / 64 threads, 128 GB, Intel E810 with 2 × 100G ports) running the published OrionOS 7.05 image, with 128,000 emulated PPPoE subscribers and 640 + 640 traffic streams from a BNG Blaster traffic generator (2 × 10G, about 1.2 Mpps ceiling), and from BNGSOFT demo gateways on the same image, in November 2026. Traffic numbers are limited by the generator, not by the BNG. Figures marked by design describe how the software works. The engine microbenchmark measures the XDP program alone. Your results depend on your hardware, traffic mix and configuration.

Product page: BNGSOFT platform · Talk to us