How to Choose a Router for Your ISP: Throughput, Sessions and Features

Choosing a router for an ISP is rarely won or lost on the headline price or the logo on the bezel. It is decided by whether the box still performs when it is carrying real, messy, production traffic two years from now — after you have turned on every feature you swore you would never need and added a few thousand subscribers you had not planned for. A datasheet describes a router on its best behaviour in a lab. Production is the opposite of a lab. The job of a good buyer is to read past the marketing number and predict how the box degrades under your actual load.

This guide walks through the specifications that genuinely determine survival, in roughly the order they bite. Each one has a trap attached — a way the number on the box overstates what you will get — so we will name the trap as well as the spec. The goal is not to find the most expensive router, but to avoid the far more common and far more painful mistake of replacing a router a year after you bought it because it ran out of a resource you never checked.

Throughput: read it like a skeptic

Vendors quote best-case throughput, and best case usually means large packets, a minimal configuration and no services running. Real internet traffic is a mix of packet sizes with a heavy tail of small packets, and small packets are far harder to forward because the work is per-packet, not per-byte. A box rated for a big number with large frames can deliver a fraction of that with small packets. On top of that, every feature you enable — NAT, queues, firewall, tunnels, deep inspection — costs forwarding budget.

So ignore the single hero number. Look for a small-packet rate, look for figures measured with the features you will actually run, and then leave generous headroom over your real peak — not your average. Networks are sized by their worst busy minute, not their daily mean. A router comfortably handling your peak today with no headroom is a router that fails the first time traffic grows or a link reroutes onto it.

Hardware versus software forwarding: the single biggest determinant

Nothing shapes how a router behaves under load more than where it forwards packets. Boxes that forward in dedicated silicon — an ASIC or NPU — sustain high rates almost regardless of how many features you enable, because the fast path is built in hardware. Boxes that forward in software, on the CPU, are wonderfully flexible and far cheaper, but their throughput sags as you pile on NAT, large queue trees and long firewall chains, because every one of those is more CPU work per packet.

Neither approach is universally better. Software forwarding is often exactly right at a light edge where flexibility matters and traffic is modest. Hardware forwarding is what you want where rates are high and predictability is non-negotiable. The fatal error is buying a software-forwarding box, enabling a stack of features, and being surprised when throughput collapses — or paying for carrier silicon at a site that needed a cheap flexible box. Know which you are buying and size it for the role.

Scale: sessions, translations, routes and subscribers

Bandwidth is only one resource a router can exhaust, and often not the first. Several table-shaped limits will break customers while the bandwidth graph still looks healthy:

• Concurrent sessions and NAT translations: central to CGNAT and PPPoE concentration. When this table fills, new connections simply fail even though there is plenty of bandwidth. Modern user devices open huge numbers of simultaneous flows, so this ceiling arrives sooner than people expect. See our primer on CGNAT for why translation capacity, not throughput, is usually the binding constraint.
• Routing table and FIB capacity: if the box will hold a full internet table via BGP, confirm both the control-plane memory to store routes and the hardware FIB to actually forward on them — and confirm there is room for the table to keep growing, because it does, every year.
• Subscriber and session termination: how many PPPoE or IPoE sessions the box can terminate, authenticate and rate-limit at once. A router that routes beautifully but tops out on session count is the wrong tool for a subscriber-edge (BNG) role.

Interfaces and uplink headroom

Count the ports and speeds you need today, then again after one realistic growth cycle, and buy for the later number. But port count is the easy half. The half people forget is uplink capacity. A switch-like box with many access ports and a thin uplink becomes a bottleneck the day you fill the access ports, no matter how impressive the forwarding engine is. Check the ratio between what can come in and what can get out, and make sure the uplink has room to grow without a forklift upgrade.

Operability, redundancy and spares

Specifications are necessary and not sufficient. A router your team can operate flawlessly beats a faster one nobody fully understands. Weigh redundant power supplies, the quality and stability of the management interface, automation and API support for your provisioning workflow, and — unglamorously — whether you can get a spare quickly and a replacement that boots the same config. The best routers in an ISP are the ones that fail predictably and are restored fast, which is as much about your operational model and your redundancy design as it is about the silicon.

Control plane versus data plane

A router is really two machines sharing a chassis, and conflating them is a quiet source of bad sizing. The data plane is the forwarding engine that moves packets; the control plane is the brain that runs the routing protocols, builds the tables and manages the box. They fail and saturate independently. A router can be forwarding traffic flawlessly in the data plane while its control plane is buckling under BGP churn, a flood of routing updates, or management and telemetry overhead. When upstream instability sends a storm of route changes, it is the control plane's CPU and memory that suffer, and a weak control plane can drop sessions and destabilise forwarding even though the data plane had headroom to spare.

This matters when you buy because datasheets emphasise data-plane throughput and say far less about control-plane capacity. For an edge box that holds full internet tables and peers widely, control-plane resources — CPU and memory for the routing process — are as important as forwarding rate, sometimes more so. Ask how the box behaves during heavy reconvergence, not just at steady state, and favour platforms that keep the management and routing brain responsive when the network around them is having a bad day. A router that forwards fast but loses its mind during instability is exactly the wrong tool at the edge.

The buying checklist

Common mistakes

The recurring errors are easy to list and easy to fall into. Buyers size for average traffic instead of peak. They check bandwidth and forget the session and route tables that actually fill first. They enable features after purchase and never re-test throughput. They buy port count without uplink headroom. And they optimise for a benchmark their team cannot operate at 3 a.m. Validate every number against your own traffic, not the datasheet's, and choose by role — a light edge concentrator and a regional core router are different purchases even from the same vendor.

The takeaway

Buy for the role and for two years of growth, validate throughput and table scale against your real traffic, and weigh operability as heavily as raw performance. Do that and the router quietly does its job long after the purchase order is forgotten. Once the hardware is right, the leverage shifts to the management layer that provisions, bills and monitors those subscribers — which is the part ISP Digital is built to handle alongside whatever router you choose.