The Supplied Router on Trial: A Measurement Plan for ISP CPE
Photo: ISP supplied router with ethernet cables and laptop running network throughput test on desk, via i.pinimg.com
Every ISP router arrives with an accusation attached. It is the free box, the beige plastic afterthought, the device that forums and YouTube channels agree must be replaced before anything else is touched. On a UK full-fibre connection in 2026 that assumption deserves scrutiny. Most current ISP customer premises equipment will route at line rate for ordinary gigabit traffic, and the real constraint is frequently Wi-Fi coverage, a single-core PPPoE path, or a test that measured something other than what its author believed.
The purpose of this article is not to defend ISP hardware. It is to establish a method for proving, in a way that can be repeated and shown to someone else, whether the supplied router is the limiting factor. Measured scepticism is cheaper than a premature upgrade.
Begin with a baseline that can be repeated
Before changing anything, record the conditions. Note the ISP, the package speed, the router model and firmware version, and the time of day. UK FTTP performance varies with evening peak demand, particularly on wholesale-based services, so a single test at 14:00 on a Tuesday proves very little.
Use at least two measurement tools. The official speed-test CLI is useful for a quick confirmation against the ISP's own expectations, but it measures a single stream to a nearby server. An iperf3 session against a known endpoint, ideally a VPS you control, gives a cleaner view of sustained throughput and exposes loss and jitter that a browser-based test hides. For bufferbloat, a latency-under-load test alongside the throughput run is more informative than the headline figure alone.
Run each test three times, wired, with a known-good client and cable. A laptop with a USB Ethernet adapter is not a known-good client until it has been tested against something else.
PPPoE: the usual single-core suspect
Most major UK FTTP providers, including BT, EE, Plusnet and TalkTalk, hand out a connection that requires PPPoE. Sky historically requires DHCP option 61 rather than PPPoE, and Virgin Media uses its own arrangement in modem mode. The distinction matters because PPPoE is encapsulated, and on some consumer routers the encapsulation and session handling run on a single CPU core.
At 900Mbps this is rarely a problem. At the symmetric 1.6Gbps and 1.8Gbps packages now sold by several altnets, it can be. A router that comfortably handles 900Mbps may plateau well below the line rate on a faster service, with one core pinned at 100 per cent while the rest of the device idles.
The test is straightforward. Route iperf3 traffic through the router to a remote endpoint and watch CPU utilisation if the interface allows it. If the throughput ceiling coincides with a saturated core, the router is the bottleneck. The comparison is to put the ISP device into bridge mode, run PPPoE on a small PC or a capable router, and repeat the test. If the ceiling lifts, the case is made.
NAT and the connection table
Home labs generate connection state in a way that ordinary households do not. Containers pulling images, a media server holding peer connections, monitoring probes, and a handful of browser tabs can push a consumer NAT table harder than its designers intended. Many ISP routers ship with connection tracking tables in the low thousands.
The symptoms are distinctive: DNS lookups begin to time out under load, new TCP connections stall while established ones continue, and the router's administrative interface becomes sluggish. A reproducible test is to open several hundred outbound connections in a controlled way, then check whether new connections succeed. If the table fills and the router does not recover gracefully, that is a measured deficiency, not a suspicion.
Wi-Fi is a separate question
It is common to conflate a slow wireless experience with a slow router. They are different failures with different remedies. An ISP router with integrated Wi-Fi 6 may deliver 400 to 600Mbps to a modern laptop at close range and considerably less through two walls. That is normal radio behaviour, not evidence that the routing engine is inadequate.
Test Wi-Fi separately: fixed positions, a wired server as the endpoint, the same client each time, and a note of channel width, band and neighbouring networks. If wired throughput meets the package and wireless falls away with distance, the correct purchase is usually a wireless access point rather than a new router. That also preserves the ISP's support obligation for the line itself, which is not a trivial consideration when a fault is eventually raised.
Bridge mode and its limits
Bridge or modem mode passes the WAN connection to your own router. It removes double NAT, gives you control of firewall rules, VLANs and IPv6 prefix delegation, and is generally the right configuration for a lab. It does not improve the line, and it does not fix Wi-Fi, because the radio is typically disabled in that mode.
Availability varies. Virgin Media hubs offer modem mode. Some altnet providers supply a combined unit with no bridge option at all, which forces a choice between double NAT and replacing the device entirely. Check before buying a replacement router on the assumption that bridge mode is there.
When replacement is justified
A replacement is defensible when routed throughput sits below the purchased package with CPU saturation demonstrated, when connection-table exhaustion is reproducible, when required features such as VLANs, static routes or controllable IPv6 are absent, or when no bridge mode exists and double NAT breaks inbound services.
It is not automatically justified by Wi-Fi performance alone, nor by the fact that the device was supplied by an ISP. In many UK home labs the most economical arrangement is to keep the supplied box as a modem and add a router behind it, retaining both the line support and the features that matter.
A short test schedule
Day one: baseline wired throughput and latency, three runs, firmware recorded. Evening peak: repeat. Day two: connection-table stress and a Wi-Fi survey at three positions. Day three: bridge-mode comparison if the hardware supports it.
The output is a short table of numbers rather than an opinion. If the supplied router survives that process, it has earned its place. If it does not, the replacement is bought on evidence, which is the only basis on which it should be bought at all.