The source bandwidth cap on Ubuntu 22.04 LTS is not a single static configuration value stored in one file. Instead, it is determined by the active traffic control policies applied to your network interfaces via the
tc command or managed by services like
netplan. To find the current limits, you must inspect the live kernel queueing disciplines using diagnostic commands that read the running state without modifying any settings.
Understanding Bandwidth Limiting Mechanisms
Ubuntu does not enforce a global "source bandwidth cap" out of the box. Network throughput is typically controlled through Linux Traffic Control (
tc), which allows administrators to shape, classify, and limit traffic on specific network devices. This system operates at the kernel level, meaning the limits are enforced by the operating system's networking stack rather than by user-space applications.
When an administrator wants to restrict bandwidth for a specific interface, such as
eth0, they attach a queueing discipline (qdisc) to that device. The most common method involves setting a maximum data rate, often measured in kilobits or megabits per second. If no such policy is attached, the interface will transmit at the full physical line speed allowed by the hardware and link negotiation. Therefore, finding the cap requires checking whether these policies exist and what values they hold.
For more complex environments involving multiple jobs or users, tools like
How do Ubuntu-server network interfaces work? provide context on how interfaces are named and configured. Understanding the underlying interface structure is crucial because bandwidth caps are bound to specific device names, not generic labels.
Inspecting Active Traffic Control Policies
The primary tool for viewing current bandwidth restrictions is the
tc utility. This command interacts with the kernel's traffic control subsystem and displays the current configuration in real-time. To see if any bandwidth caps are currently active, you should run the following command in a terminal:
tc qdisc show dev eth0
Replace
eth0 with the actual name of your network interface, which you can identify using the
ip link command. If the output shows a
qdisc htb (Hierarchical Token Bucket) or
qdisc fq_codel entry, it indicates that shaping is enabled. The
htb qdisc is particularly relevant because it allows explicit definition of maximum rates.
If the output is empty or only shows
noqueue, then there is no explicit bandwidth cap applied by the system. In this case, the interface is likely unrestricted. It is important to note that some modern setups use
fq_codel for fairness rather than hard caps, which may not display a simple "max bandwidth" number but instead manages packet scheduling to prevent bufferbloat.
Reading HTB Rate Limits
When using the Hierarchical Token Bucket (
htb) qdisc, the bandwidth limit is explicitly defined in the class configuration. You can view detailed information about these classes by running:
tc class show dev eth0
Look for lines containing
rate or
ceil. The
rate parameter defines the guaranteed minimum bandwidth, while
ceil defines the maximum burstable bandwidth. For example, an output might look like this:
class htb 1:1 root prio rate 100Mbit ceil 500Mbit burst 16Kb cburst 16Kb
In this example, the source bandwidth cap for this specific class is effectively 500 Mbit/s due to the ceiling limit. If you see multiple classes, each may have different limits depending on how the traffic is classified.
Checking Netplan Configuration
On Ubuntu 22.04 LTS, network configuration is primarily handled by Netplan. While Netplan itself does not directly set bandwidth caps in its standard YAML files, it generates the configuration for NetworkManager or systemd-networkd. However, some advanced setups might integrate traffic control rules into the Netplan renderer scripts or use custom hooks.
To check the current Netplan configuration, examine the files in
/etc/netplan/. Look for any
.yaml files and inspect their content using a text editor like
nano or
cat. Standard Netplan configurations focus on IP addressing, DNS, and routing, but they may include references to external scripts or plugins that apply
tc rules upon interface up events.
If you suspect that bandwidth limits are applied dynamically via a script triggered by Netplan, you should review the contents of those scripts. These scripts often contain the actual
tc commands that establish the limits. This approach ensures that the bandwidth cap persists across reboots and interface restarts.
Distinguishing Between Shaping and Policing
It is critical to distinguish between bandwidth shaping and policing when interpreting results. Shaping delays packets to conform to a rate limit, which reduces latency spikes but does not drop packets immediately. Policing drops packets that exceed the rate limit, which can lead to higher latency and jitter for compliant traffic.
The
tc command output will indicate which mechanism is in use. If you see
tbf (Token Bucket Filter), it is a simple shaper. If you see
police, it is a policer. Understanding this distinction helps in troubleshooting why certain applications might be experiencing throttling versus packet loss. For more details on managing network policies, refer to
Troubleshooting Dropping Packets in iptables, although iptables handles filtering rather than shaping.
Verifying Interface Status
Before concluding that a bandwidth cap exists, verify that the interface is actually active and linked. Use the
ip addr show command to list all interfaces and their states. An interface that is down or disconnected will not have meaningful bandwidth statistics, even if a cap is configured.
Additionally, check the link speed negotiated with the network hardware using
ethtool eth0. This command reveals the maximum physical capability of the interface. If the negotiated speed is lower than the configured cap, the physical link becomes the bottleneck, not the software configuration.
Summary of Diagnostic Steps
To accurately determine the source bandwidth cap on Ubuntu 22.04 LTS, follow this logical sequence:
1. Identify the correct network interface name using
ip link.
2. Run
tc qdisc show dev <interface> to check for active shaping disciplines.
3. If
htb is present, run
tc class show dev <interface> to find the
ceil rate.
4. Check Netplan configurations in
/etc/netplan/ for any custom hooks or scripts.
5. Verify physical link speeds with
ethtool to rule out hardware limitations.
This method provides a complete picture of the bandwidth constraints without altering the system state. It is safe, non-destructive, and applicable to both server and workstation environments.
Frequently Asked Questions
What happens if I change the bandwidth cap while connected via SSH?
Changing the bandwidth cap can cause immediate latency spikes or packet loss if the new limit is significantly lower than the current traffic volume. This may result in dropped SSH connections or slow response times. It is recommended to test changes during off-hours or have a local console available.
Can I find the bandwidth cap in /etc/network/interfaces?
No, the traditional
/etc/network/interfaces file does not support bandwidth limiting directives in Ubuntu 22.04. Bandwidth controls are handled externally by the
tc subsystem or via Netplan hooks. You will not find rate-limiting parameters in this legacy configuration file.
Why does my interface show no qdisc but still feels slow?
If no
tc qdisc is present, the slowness is likely due to physical network issues, DNS resolution delays, or application-level bottlenecks. Check the link speed with
ethtool and monitor CPU usage to ensure the system is not overwhelmed.
How do I reset all bandwidth caps to unlimited?
You can remove all traffic control policies by running
tc qdisc del dev eth0 root. This command removes the root qdisc, restoring the interface to its default unshaped state. Be cautious, as this affects all traffic on the interface immediately.
Is there a GUI tool to view bandwidth caps in Ubuntu?
Ubuntu 22.04 does not include a native graphical interface for viewing or editing
tc traffic control rules. Users must rely on command-line tools like
tc,
ip, or third-party monitoring utilities. Some network management suites offer visualizations, but they ultimately query the same kernel data.