Activate TCP BBR on Linux – Step‑by‑Step Guide

Learn how to activate the BBR congestion‑control algorithm on a Linux host, verify its operation, and benchmark its impact on throughput and latency. The guide covers prerequisites, configuration steps, testing with iperf3, and rollback to a loss‑based algorithm.

Desired Outcome

The goal is to enable TCP BBR (Bottleneck Bandwidth and RTT) on a running Linux system, confirm that new TCP connections use BBR, and demonstrate measurable throughput improvements over a loss‑based algorithm such as Cubic. The guide also provides a quick rollback path if BBR introduces instability.

Prerequisites

Linux kernel 4.9 or newer. BBR is included as a built‑in module in most distributions from this version onward.
Root or sudo privileges to modify kernel parameters and load modules.
Network connectivity to a test server that can run iperf3 or a similar traffic generator.
Optional: Disable TCP segmentation offload (TSO) or generic segmentation offload (GSO) on the NIC if you want the most accurate measurement of BBR behavior. On many modern NICs this is not required, but some environments report higher variability with TSO enabled.

Step 1 – Verify Current Congestion Control

Before making changes, check which algorithm is currently active:

# sudo sysctl net.ipv4.tcp_congestion_control\nnet.ipv4.tcp_congestion_control = cubic\n

Replace cubic with whatever algorithm your system reports.

Step 2 – Load the BBR Module (If Needed)

On most distributions, the BBR module is built into the kernel and automatically loaded when the algorithm is selected. If you see an error when attempting to enable BBR, load the module manually:

# sudo modprobe tcp_bbr\n# lsmod | grep tcp_bbr\n

Successful output will include a line for tcp_bbr indicating the module is loaded.

Step 3 – Enable BBR via sysctl

Activate BBR for new TCP connections:

# sudo sysctl -w net.ipv4.tcp_congestion_control=bbr\nnet.ipv4.tcp_congestion_control = bbr\n

To make the change persistent across reboots, create or edit a sysctl drop‑in file:

# sudo tee /etc/sysctl.d/99-bbr.conf > /dev/null <<'EOF'\nnet.ipv4.tcp_congestion_control = bbr\nEOF\n# sudo sysctl --system\n

After this, any new outbound TCP connection will use BBR.

Step 4 – Validate BBR is in Use

Run the following command to confirm the active algorithm:

# sysctl net.ipv4.tcp_congestion_control\nnet.ipv4.tcp_congestion_control = bbr\n

For a more granular check, inspect the netstat or ss output for a specific connection:

# ss -i -p | grep ESTAB | head\nESTAB  0  0  192.168.1.10:54321  203.0.113.5:80  users:((\"curl\",pid=1234,fd=4))  \n

While ss does not directly expose the congestion controller, you can confirm that the connection is active after enabling BBR and that no error codes appear.

Step 5 – Benchmark with iperf3

Use iperf3 to generate a sustained TCP stream and measure bandwidth and latency. Run a server on the remote host:

# iperf3 -s\n

Then on the client, perform a baseline test with Cubic (or the previous algorithm) and record the results:

# sudo sysctl -w net.ipv4.tcp_congestion_control=cubic\n# iperf3 -c  -t 30 -i 5\n

Note the throughput (MB/s) and average RTT values reported. Repeat the test after enabling BBR:

# sudo sysctl -w net.ipv4.tcp_congestion_control=bbr\n# iperf3 -c  -t 30 -i 5\n

Typical observations on a high‑bandwidth, high‑latency link are:

Throughput increases by 10–30% compared to Cubic.
Average RTT stabilizes and is often lower, especially when the link has a large bandwidth‑delay product.
Packet loss remains comparable or lower, as BBR reduces queue buildup.

For a more controlled comparison, capture traffic with tcpdump or wireshark and analyze the pacing behavior, but this is optional for most operational scenarios.

Step 6 – Optional TSO/GSO Disable

If you observe irregular performance or suspect NIC offload features are skewing measurements, you can disable TSO/GSO on the interface:

# sudo ethtool -K eth0 tso off gso off gro off\n# sudo ethtool -K eth0 tso on gso on gro on  # to re‑enable\n

Run the iperf3 test again to see if throughput or latency improves. Remember to revert these settings on production systems if they affect application traffic.

Rollback – Revert to Cubic

If BBR causes instability or you need to return to a loss‑based algorithm, simply change the sysctl again:

# sudo sysctl -w net.ipv4.tcp_congestion_control=cubic\n# sudo sysctl --system  # reload persistent settings\n

No service restart is required; the change applies to new connections immediately.

Limitations and Caveats

BBR performs best on paths with low packet loss (<2%). On very lossy links, it may underperform compared to Cubic.
In mixed‑algorithm environments, BBR may consume a larger share of the bottleneck, potentially starving loss‑based peers.
Middleboxes that drop or reorder packets based on ECN or explicit congestion notifications can confuse BBR’s bandwidth estimation.
Older kernels (<4.9) do not include BBR; attempting to load the module will fail.
Some NIC drivers interact poorly with BBR; disabling TSO/GSO can mitigate this but may reduce performance on high‑speed links.

Practical Checklist

\n\n\n\n\n\n\n\n\n\n\n

Task	Command	Verification
Check kernel version	`uname -r`	≥ 4.9
Verify current congestion control	`sysctl net.ipv4.tcp_congestion_control`	Displays current algorithm
Load BBR module	`modprobe tcp_bbr`	`lsmod \| grep tcp_bbr` shows module
Enable BBR	`sysctl -w net.ipv4.tcp_congestion_control=bbr`	Re‑run sysctl to confirm
Persist BBR	Create /etc/sysctl.d/99-bbr.conf	Reload with `sysctl --system`
Benchmark	`iperf3 -c <server> -t 30`	Record throughput/RTT
Rollback	`sysctl -w net.ipv4.tcp_congestion_control=cubic`	New connections use Cubic

Following this procedure gives you a clear, repeatable path to enable BBR, verify its operation, and assess its impact on your network traffic. When deploying in production, monitor for any changes in application latency or packet loss before and after the switch.

Enabling and Validating TCP BBR on Linux: A Practical Guide