How to Configure Linux TCP BBR (Bottleneck Bandwidth and RTT) for High-Speed Networks

For decades, the Internet has relied on loss-based TCP congestion control algorithms (like CUBIC or Reno). These algorithms share a fundamental, fatal flaw: they interpret packet loss as the only indicator of network congestion. They aggressively ramp up transmission speed until a packet is dropped, halve their speed, and slowly ramp up again.

In modern, high-speed, long-distance networks (like a 10Gbps fiber link spanning the Atlantic Ocean), packet loss can occur for reasons entirely unrelated to congestion (such as random optical errors or shallow switch buffers). When CUBIC misinterprets a random packet drop as congestion on a massive transoceanic pipe, it needlessly slashes throughput, causing a 10Gbps link to crawl at 50Mbps.

To solve this, Google engineers developed TCP BBR (Bottleneck Bandwidth and Round-trip propagation time). BBR completely ignores packet loss. Instead, it continuously measures the maximum bandwidth and the minimum round-trip time (RTT) of the network link, building an exact mathematical model of the network’s physics. It then paces the transmission of packets to match that exact speed, achieving theoretical maximum throughput even on lossy, high-latency links.

This guide explains how to enable and configure TCP BBR on a Linux server to drastically improve network performance.

Prerequisites for TCP BBR

To use TCP BBR, your Linux kernel must meet specific requirements:

1. Kernel Version: You must be running Linux kernel version 4.9 or higher. (Modern distributions like Ubuntu 22.04 or RHEL 9 meet this requirement by default).
2. Fair Queuing (fq): BBR requires the fq (Fair Queuing) traffic control qdisc to function optimally. While BBRv2 works with fq_codel, the original BBR implementation strictly requires fq for pacing packets.

Step 1: Checking the Current TCP Algorithm

Before making changes, verify which congestion control algorithm your kernel is currently using.

sysctl net.ipv4.tcp_congestion_control

In most default Linux distributions, this will return:

net.ipv4.tcp_congestion_control = cubic

You can also check the available algorithms compiled into your kernel:

sysctl net.ipv4.tcp_available_congestion_control

You should see bbr in the output list. If you do not, you may need to load the BBR kernel module (e.g., sudo modprobe tcp_bbr).

Step 2: Enabling the Fair Queuing (fq) Qdisc

TCP BBR relies on the kernel’s pacing infrastructure to space out packet transmission. To enable this, you must change the default queuing discipline to fq.

Open the sysctl configuration file to make this change persistent across reboots:

sudo nano /etc/sysctl.d/99-bbr.conf

Add the following line to enforce Fair Queuing on all interfaces:

net.core.default_qdisc = fq

Step 3: Activating TCP BBR

In the same configuration file, instruct the IPv4 networking stack to default to BBR.

Add the following line:

net.ipv4.tcp_congestion_control = bbr

Save the file and exit the text editor.

Now, apply the changes immediately without rebooting the server:

sudo sysctl -p /etc/sysctl.d/99-bbr.conf

Step 4: Verifying the Configuration

Ensure that the sysctl parameters were successfully applied to the running kernel.

sysctl net.ipv4.tcp_congestion_control

The output must explicitly state bbr.

To definitively prove that the BBR kernel module is actively loaded and processing traffic, use the lsmod command:

lsmod | grep bbr

You should see tcp_bbr listed, along with a number indicating how many active network sockets are currently utilizing it.

Understanding the Impact on Throughput

If you are serving traffic locally within a single data center (where latency is < 1ms and packet loss is 0%), you will not see a significant difference between CUBIC and BBR. Both will saturate the link.

The magic of BBR is revealed over the WAN. If you have a server in New York sending a 5GB file to a client in Sydney, Australia (latency ~250ms), and the connection experiences even 0.1% packet loss, CUBIC will throttle the connection drastically, assuming heavy congestion.

BBR will measure the actual bottleneck bandwidth (e.g., 1Gbps), ignore the 0.1% optical packet loss, and blast the file at the maximum physical speed of the fiber optic cable.

Conclusion

Replacing loss-based congestion control with TCP BBR is one of the highest ROI performance optimizations available to Linux systems administrators. By leveraging Google’s physics-based network modeling, servers can effortlessly push massive payloads across lossy, high-latency global networks, fundamentally altering the speed limits of the Internet.