ISP & WISP
Edge routing and aggregation that holds line rate under real subscriber load, not lab load.
What the network looked like before we touched it.
A growing WISP hits a wall that no amount of backhaul fixes: the edge router that was fine at 800 subscribers starts dropping packets at 2,000, because full BGP tables and NAT sessions are eating a CPU that was never sized for it. Latency climbs during evening peak, support tickets follow, and the temptation is to throw bandwidth at a forwarding problem.
Built to spec, once.
OKTET sizes the edge to the session count, not the headline throughput. The OR-8000 carries full BGP tables and the NAT/CGNAT load with hardware forwarding, so peak-hour latency stays flat. Tower and PoP aggregation moves to the OS-4800 with OF-SFP10 10GbE uplinks, and the OR-2000 handles smaller PoPs and customer-facing edges where a full core router is overkill.
Compare the hardware →line rate held at evening peak
subscriber capacity on the same backhaul
added latency through the NAT edge
How the deployment actually went.
A fixed-wireless operator covering a rural county had done everything right on the radio side — licensed backhaul, clean spectrum, well-aimed sectors — and still watched evening latency climb past 40ms as they crossed 1,800 subscribers. The cause was not the air. It was a general-purpose edge router doing full BGP, CGNAT, and shaping on a CPU that hit its ceiling exactly when subscribers came home and started streaming. More backhaul would not have moved the number, because the bottleneck was forwarding and session state, not bandwidth.
We rebuilt the edge around session count. The OR-8000 took over the border: full BGP tables from both transit providers, CGNAT for the IPv4 pool, and per-customer shaping, all in hardware forwarding so the control-plane CPU is no longer in the packet path. Tower aggregation moved onto OS-4800 distribution switches feeding the core over OF-SFP10 10GbE optics, and the smaller PoPs that did not justify a full core router were re-homed onto the OR-2000, which carries a partial table and the local NAT load comfortably.
After cutover the edge holds 10GbE line rate through the evening peak, the NAT path adds under 3ms, and the operator added another 1,900 subscribers on the same licensed backhaul before needing to think about capacity again — roughly double the subscriber count the old edge could serve. Support tickets tagged “slow internet at night” effectively stopped, because the network now degrades gracefully under load instead of falling off a cliff.
The lesson the operator took away was simple and we tell every ISP the same thing: size the edge to the number of sessions and the forwarding rate you actually expect, document it, and the headline throughput takes care of itself.
The line that built it.
OKTET OR-8000
Enterprise edge routing and stateful firewall at 40 Gbps, line-rate where it counts.
- Throughput
- 40 Gbps firewall · 28 Gbps IPsec VPN
- Ports
- 8× SFP+ 10GbE · 2× RJ45 2.5GbE
OKTET OR-2000
A fanless branch gateway that routes 5 Gbps and runs VPN without flinching.
- Throughput
- 5 Gbps firewall · 3.4 Gbps IPsec VPN
- Ports
- 2× SFP+ · 4× RJ45 2.5GbE
OKTET OS-4800
Forty-eight 10GbE ports and six 100G uplinks for the aggregation layer.
- Ports
- 48× SFP+ 10GbE · 6× QSFP28 100GbE
- Switching capacity
- 2.16 Tbps / 1,607 Mpps
Specify it for your site.
Send us the constraints — rack count, building count, subscriber load — and we'll return a bill of materials sized to spec.