The Internet upgrade was one of the final steps of my rack and network migration. An Aussie Broadband 2000/500 Mbps service had to work through the infrastructure actually carrying production traffic — not merely show a multigigabit link at the firewall. The path included a virtual machine, a virtualisation bridge, aggregated host uplinks, a redundant switching fabric, segmented routing, a firewall and the broadband handoff.
The question was not whether Aussie Broadband had sold me a 2 Gbps tier. It was whether a workload inside the rack could reach that tier, and what the measurements did — and did not — prove.
// what a speed claim actually measures
The contracted 2000/500 Mbps tier, the negotiated Ethernet interface rate, and application-level speed-test throughput describe different things. A 2.5GbE WAN interface can provide sufficient physical link capacity without guaranteeing an application 2 Gbps. Equally, a single lower test result does not establish an ISP shortfall.
My engineering report records that the upgraded service was active on 15 October 2026. A 24 October firewall interface capture shows the broadband-facing interface active at 2500Base-T full duplex. The physical media mode exceeds the nominal downstream service rate. This is necessary capacity, not a throughput measurement by itself.
// the path I measured
I ran the final benchmarks from a production service VM on a virtualisation host, rather than from the firewall console. Host networking used an IEEE 802.3ad bond built from two 10GbE links, traversing the switching and routed security edge to a 2.5GbE WAN. According to the source report, no 1GbE interface was present on the measured path. The test was conducted while the production compute platform was active; no service impact was recorded.
Figure 1. Generic logical path for the production-VM throughput tests. It deliberately omits product names, addressing and VLAN identifiers. This is a forwarding-path representation, not a diagram of active/standby member selection or a failover validation.
// nine runs across three networks
On 19 October 2026 between 06:03 and 06:06 AEDT, I ran Ookla Speedtest CLI 1.2.0 from that VM. Three Sydney networks — Telstra, Superloop and Optus — were tested three times each. The tests were sequential, interleaved across endpoints, and separated by approximately five seconds. Ookla's default multi-connection method was used, with JSON results retained for later review.
A tenth test to Aussie Broadband's own Sydney server was deliberately excluded from the nine-run off-net statistics, avoiding reliance on a single on-net measurement.
| Metric | Nine off-net runs | What it means |
|---|---|---|
| Download median | 2,069 Mbps | Measured from the production VM |
| Upload median | 535 Mbps | Measured from the production VM |
| Idle ping median | 2.57 ms | Idle latency, not loaded latency |
| Download range | 2,013–2,077 Mbps | All nine runs exceeded 2,000 Mbps |
| Upload range | 533–542 Mbps | All nine runs exceeded 500 Mbps |
Both bandwidth medians were calculated independently from the nine off-net runs. The recorded throughput was consistent with delivery of the advertised tier under those test conditions. These measurements do not establish sustained all-day throughput or performance to every Internet destination.
// the earlier 936 Mbps result
An earlier firewall-local iperf3 reverse-direction test returned 936 Mbps at the receiver; its corresponding upload receiver figure was 455 Mbps. That client was the firewall itself, testing against a single remote server. This is a materially different test from a multi-connection speed test initiated on a production VM and repeated across three external networks.
The earlier result resembles a throughput ceiling often encountered around a 1GbE segment, but I have no proof that a 1GbE link caused it. Remote-server limits, stream behaviour and other test-path differences remain possible. In particular, the available evidence does not identify the limiting hop. I retain the 936 Mbps result as a useful diagnostic lesson, not as a resolved fault.
// latency belongs next to throughput
Bandwidth results were strong across all three test networks, but loaded latency was not uniform. The three Superloop download tests recorded 50.2, 55.2 and 44.4 ms of loaded latency, despite idle ping near 2.5 ms. The Telstra and Optus download-loaded values remained below 5 ms in these runs.
Figure 2. Download-loaded latency, three sequential runs per ISP (Ookla IQM metric). An endpoint-specific observation, not proof of the location or cause of congestion.
The reported packet-loss field was 0% for Telstra and Superloop runs. Optus did not report a loss value; it would be inaccurate to claim 0% loss for all nine runs. Likewise, the latency pattern cannot be attributed conclusively to queueing, shaping, peering or equipment without further path-specific measurements.
// what the result proves — and what it does not
The production traffic path delivered more than 2 Gbps downstream and 500 Mbps upstream to the selected off-net test endpoints, with a WAN physical negotiation of 2.5GbE. I could validate that result without removing the workloads from the operational network. That is materially stronger evidence than a firewall-only speed test.
The test does not establish per-hop headroom, firewall CPU consumption, queue depth, application experience at peak times, or failover convergence. Firewall CPU and state-table data were not collected during these runs. Cumulative interface counters showed no reported errors or drops at the later capture, but they do not isolate the benchmark window. Separate routing/failover tests belong to separate verification records.
// the engineering takeaway
For a multigigabit upgrade, keep the chain of evidence intact: confirm the commercial service state, verify physical negotiation, identify every link on the end-to-end path, test from a real workload, use multiple capable external endpoints, retain machine-readable outputs, and interpret loaded latency separately from idle ping. When one test disagrees with the others, document its context before declaring a bottleneck.
The upgrade mattered because the network — not just the WAN socket — could carry the new service rate. The useful result was the evidence trail: a named test path, repeatable measurements, explicit exclusions and honest boundaries around what remained unverified.
// method and evidence note
Measurement source: my validation record dated 24 October 2026, covering tests executed 19 October. Ookla Speedtest CLI 1.2.0, three sequential tests each to Telstra, Superloop and Optus Sydney endpoints; one provider on-net test excluded. Raw JSON and a summary table are retained in internal operations records. Earlier firewall-local iperf3 results are from a separate terminal capture. Internal IP addresses, public WAN addresses, machine identifiers and result URLs have been intentionally omitted.
Top comments (0)