Capacity and performance
Capacity is a property of the platform: worker cores and receive queues set the packet rate, memory sets session and translation scale, and the enabled subsystems set the per-packet cost. Netvyn plans itself across 16 to 64 cores from one binary, so sizing is a hardware conversation rather than a licence tier.
Validated capacity
20,000 concurrent PPPoE and IPoE sessions carrying 2.5 Mpps of subscriber traffic, with deterministic CGNAT, hierarchical QoS and stateful firewalling all active — sustained with zero forwarding loss and a resident footprint near 2 GB. Session and conntrack tables are memory structures, so translation scale past a million entries is a question of RAM rather than of forwarding cost.
How capacity scales
Packet rate scales with worker cores and receive queues, since each worker runs the whole pipeline to completion on the core that received the frame. Session count and conntrack size cost memory and hugepages. Subsystems divide into per-packet cost (CGNAT translation, deep filtering) and per-session cost (shaper pipes), which is why a shaped-and-translated deployment sizes differently from plain forwarding at the same bit rate.
Sizing a deployment
Four inputs: peak concurrent sessions, busy-hour packet rate, which subsystems are enabled, and whether you need an active/standby pair. From those we set worker count, receive-queue count per port, hugepage reservation for the mbuf pools, scheduler and conntrack table, and the address-pool size. Keep the workers on a single NUMA node and isolate them from the scheduler and from device interrupts.
show topology # the live MAIN / CONTROL / WORKER plan show system # CPU-plan knobs (control-cores, workers, ht-policy) show interface stats # per-port rx/tx, errors, ring-missed
Verifying on your own hardware
Every number we quote is readable from the same counters you have. Establish a baseline by clearing the counters, run the load for a known window, then read: per-worker busy cycle from show health, forward and drop totals from show drops, and translation hits, misses and conntrack utilisation from show nat statistics. A moving counter after a known start point is far easier to interpret than a lifetime total.
clear counters nat # ... run the load ... show health # per-worker busy cycle, memory, drops show drops access0 # fast-path forward + drop counters show nat statistics # translation hits / misses, conntrack use show qos bindings # resolved per-subscriber rate + source
Adding headroom
Growth is a configuration change, not a purchase: give the planner more worker cores, raise the hugepage reservation for the extra workers and a larger conntrack table, and size the address pool for the new subscriber count. Pools grow live on commit, so the address side of a capacity increase does not need a restart.