How to limit bandwidth on Linux to better test your applications
How to limit bandwidth on Linux to better test your applications
Spread the love

Using the Traffic Control command you can simulate poorly configured networks to test how well your applications will respond to such an environment.

linuxnetworkhero.jpg

Image: Jack Wallen

The Traffic Control command (tc) is a tool that every network admin should know. What tc does is allow the admin to configure the kernel packet schedule to either simulate packet delay and loss for UDP/TCP applications or to limit bandwidth usage for a specific service.

I want to show you how you can make us of the tc command in order to control network traffic in and out of your Linux servers. By doing this, you can better test how your applications will handle a poorly configured or inconsistent network.

SEE: Implementing DevOps: A guide for IT pros (free PDF) (TechRepublic)

What you’ll need

I’ll be demonstrating on an instance of Ubuntu Server 18.04. You can use this command on any Linux server, but the installation of the tool (should it not be preinstalled) will vary. You will also need a user with sudo privileges.

How to install the tc command

If you find the tc command isn’t installed by default, on Ubuntu it is packaged with iproute2. So install as follows:

sudo apt-get install iproute2 -y

Basic usage

The first thing you must do is find out the name of the interface you want to apply to the kernel packet scheduler. To do this, issue the command:

ip a

This command will list out the information for all of your networking devices (Figure A).

Figure A

tca.jpg

I’m going to demonstrate by adding a constant delay to the ens5 interface on my machine. To be more specific, I’m going to delay the outbound traffic (egress) on the device by 200 ms. For this, the command would be:

sudo tc qdisc add dev ens5 root tbf rate 1024kbit latency 50ms burst 1540

The options in the above command are:

  • qdisc tells tc to modify the scheduler
  • add tells tc to add a new rule
  • dev ens5 tells tc the rules will be applied to device ens5
  • root tells tc to modify the outbound traffic scheduler
  • tbf rate 1024kbit tells tc to slow traffic down to the 1024kbit rate
  • latency 50ms tells tc we’ll be delaying traffic by 50ms
  • burst 1540 tells tc the size of our bucket

Once you’ve issued the command, you can verify the parameters were applied with the command:

sudo tc qdisc show dev ens5

You should see each of your options configured properly (Figure B).

Figure B

Our tc command has been applied.

” data-credit rel=”noopener noreferrer nofollow”>tcb.jpg

Our tc command has been applied.

To delete the newly added rule, issue the command:

sudo tc qdisc del dev ens5 root

One very important thing to remember is that you can only apply one rule to an interface at a time. Because of this, in order to create a different rule to an interface, you must first delete the previous rule.

How to simulate packet loss with tc commands

Let’s say, for example, you are developing an application and you need to test to see how it will handle packet loss on your network. This can be crucial to ensure your application can tolerate poorly configured or unreliable networks. Here are two example tc commands to simulate packet loss:

sudo tc qdisc add dev ens5 root netem loss 0.1%

The above command will drop packets randomly, with a probability of 0.1%.

What if we want a packet loss probability of 0.3% with a 25% drop decision for previous packets? That command would be:

sudo tc qdisc add dev ens5 root netem loss 0.3% 25%

After running the above command, issue a ping test to another machine on your network and you should see packet loss indicated (Figure C).

Figure C

25% packet loss

” data-credit rel=”noopener noreferrer nofollow”>tcc.jpg

25% packet loss

With that rule in place, fire up your application and see how well it functions when the network isn’t quite as up to par. If the application fails, you’ve got more work to do. 

If that particular packet loss rule isn’t enough for you, you can employ the Gilbert-Elliot scheme, which defines two states:

  • Good (or drop Gap)
  • Bad (or drop Burst)

This scheme offers a closer model for network impairments, rather than simple packet loss. To use the Gilbert-Elliot scheme, the command would look something like this:

sudo tc qdisc add dev ens5 root netem loss gemodel 1% 10% 70% 0.1%

Now when we run our ping test, we should see similar numbers as we did before, but the packet loss should be more realistic for your testing purposes (Figure D).

Figure D

Another type of packet loss.

” data-credit rel=”noopener noreferrer nofollow”>tcd.jpg

Another type of packet loss.

And there you have it, a few examples of using the tc command to shape network traffic on your Linux machines, so you can better test your network-aware applications. For more information about tc issue the command man tc and read through the manual page carefully.

Also see

Let’s block ads! (Why?)

Facebook Comments

Leave a Reply

Close Menu
%d bloggers like this: