Linux Trafficshaping

From AdminWiki

(Difference between revisions)
Jump to: navigation, search
(initial commit)
m (Classification)
 
(12 intermediate revisions not shown)
Line 13: Line 13:
* The [http://lartc.org/howto/lartc.adv-filter.html#LARTC.ADV-FILTER.U32 U32 classifier]
* The [http://lartc.org/howto/lartc.adv-filter.html#LARTC.ADV-FILTER.U32 U32 classifier]
-
:Probably the fastest option when you want to classify traffic. The syntax is extremely user-friendly and intuitive when you happen to know the TCP header specs by heart.
+
:Probably the fastest option when you want to classify traffic. The syntax is [http://lartc.org/howto/lartc.adv-filter.html#AEN1303 extremely user-friendly] and intuitive when you happen to know the TCP header specs by heart.
-
* [http://lartc.org/howto/lartc.netfilter.html iptables mark]
+
* [http://lartc.org/howto/lartc.netfilter.html iptables/netfilter mark]
-
:Much more comfortable than U32, probably noticeable slower when you're pushing large amounts of pps.
+
:Much more comfortable than U32 when you're familiar with iptables, but probably noticeable slower when you're pushing large amounts of packets per second.
= Queueing =
= Queueing =
 +
 +
The packet queuer does the actual ''work'' when shaping traffic. It's responsible for deciding which packets get delayed, dropped or sent instantly. It's important that you understand that you can only shape traffic that you ''send''. There are no perfect solutions to shape incoming traffic, although TCP behaves relatively fine when you delay ACK-packets. This is possible with an IMQ device, see the [http://lartc.org/howto/lartc.imq.html lartc example] or the [http://www.linuximq.net/ IMQ Homepage].
 +
 +
There are two kinds of queuers, [http://lartc.org/howto/lartc.qdisc.classful.html classful] and [http://lartc.org/howto/lartc.qdisc.classless.html classless]. With classful queueing algorithms you can construct trees which share common limits; a classless queueing discipline OTOH only works on a per-device basis without much fine-grained control. Describing this in detail here wouldn't make sense, since it's already extensively documented on the lartc page.
 +
 +
The setups you're going to use nowadays are mostly a combination of [http://lartc.org/howto/lartc.qdisc.classful.html#AEN1072 HTB] for prioritizing traffic based on a tree/leaf-model and [http://lartc.org/howto/lartc.qdisc.classless.html#LARTC.SFQ SFQ] to ensure that every flow<ref>means TCP/UDP connections</ref> gets it's fair share of the available bandwidth.
 +
 +
The [http://luxik.cdi.cz/~devik/qos/htb/ HTB homepage] has a nice [http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm user guide] with much more detailed examples than on lartc.
 +
 +
 +
<references/>
 +
 +
= Examples =
 +
 +
Here's an example which does the following:
 +
 +
* Creates a root node with 100mbit speed
 +
* Creates two leaves:
 +
** one with 80mbit guaranteed minimum bandwidth, burstable to 100mbit, being prioritized
 +
** one with 20mbit guaranteed minimum bandwidth, also burstable to 100mbit, but only when the #4 leaf doesn't need it
 +
* Traffic from the 10.0.1.0/24 subnet gets classified into the 80mbit leaf
 +
* All other traffic is sorted into the 20mbit leaf.
 +
 +
This basically means that every user could use all available bandwidth when the server is idle, but when things should get tight, the users from the 10.0.1.0/24 subnet will get a guaranteed minimum bandwidth of 80mbit.
 +
 +
<pre>
 +
#!/bin/bash
 +
tc=/sbin/tc
 +
 +
#Cleaning up
 +
$tc qdisc del dev eth0 root handle 1: > /dev/null 2>&1
 +
 +
#Add the root handle, setting the default leaf
 +
$tc qdisc add dev eth0 root handle 1: htb default 5
 +
 +
#Set the basic speed of the device
 +
$tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit
 +
 +
#Set up the two leaves
 +
$tc class add dev eth0 parent 1:1 classid 1:4 htb rate 80mbit ceil 100mbit prio 1
 +
$tc class add dev eth0 parent 1:1 classid 1:5 htb rate 20mbit ceil 100mbit
 +
 +
#Add SFQ queueing disciplines
 +
$tc qdisc add dev eth0 parent 1:4 handle 4: sfq perturb 10
 +
$tc qdisc add dev eth0 parent 1:5 handle 5: sfq perturb 10
 +
 +
#prioritize traffic
 +
$tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.1.0/24 flowid 1:4
 +
</pre>

Latest revision as of 00:24, 26 May 2006

Contents

Introduction

Trafficshaping under Linux is as easy and intuitive as changing the drive belt in your car. Fortunately there's the lartc homepage which should be your first stop when you want to learn about advanced networking under linux.

When we talk about traffic shaping we're talking about two things:

  • Packet classification
  • Packet queueing

Classification

When you want to shape traffic you usually want to give some packets and/or flows precedence over others. To classify packets you've got a few options under linux:

Probably the fastest option when you want to classify traffic. The syntax is extremely user-friendly and intuitive when you happen to know the TCP header specs by heart.
Much more comfortable than U32 when you're familiar with iptables, but probably noticeable slower when you're pushing large amounts of packets per second.

Queueing

The packet queuer does the actual work when shaping traffic. It's responsible for deciding which packets get delayed, dropped or sent instantly. It's important that you understand that you can only shape traffic that you send. There are no perfect solutions to shape incoming traffic, although TCP behaves relatively fine when you delay ACK-packets. This is possible with an IMQ device, see the lartc example or the IMQ Homepage.

There are two kinds of queuers, classful and classless. With classful queueing algorithms you can construct trees which share common limits; a classless queueing discipline OTOH only works on a per-device basis without much fine-grained control. Describing this in detail here wouldn't make sense, since it's already extensively documented on the lartc page.

The setups you're going to use nowadays are mostly a combination of HTB for prioritizing traffic based on a tree/leaf-model and SFQ to ensure that every flow[1] gets it's fair share of the available bandwidth.

The HTB homepage has a nice user guide with much more detailed examples than on lartc.


  1. means TCP/UDP connections

Examples

Here's an example which does the following:

  • Creates a root node with 100mbit speed
  • Creates two leaves:
    • one with 80mbit guaranteed minimum bandwidth, burstable to 100mbit, being prioritized
    • one with 20mbit guaranteed minimum bandwidth, also burstable to 100mbit, but only when the #4 leaf doesn't need it
  • Traffic from the 10.0.1.0/24 subnet gets classified into the 80mbit leaf
  • All other traffic is sorted into the 20mbit leaf.

This basically means that every user could use all available bandwidth when the server is idle, but when things should get tight, the users from the 10.0.1.0/24 subnet will get a guaranteed minimum bandwidth of 80mbit.

#!/bin/bash
tc=/sbin/tc

#Cleaning up
$tc qdisc del dev eth0 root handle 1: > /dev/null 2>&1

#Add the root handle, setting the default leaf
$tc qdisc add dev eth0 root handle 1: htb default 5

#Set the basic speed of the device
$tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit

#Set up the two leaves
$tc class add dev eth0 parent 1:1 classid 1:4 htb rate 80mbit ceil 100mbit prio 1
$tc class add dev eth0 parent 1:1 classid 1:5 htb rate 20mbit ceil 100mbit

#Add SFQ queueing disciplines
$tc qdisc add dev eth0 parent 1:4 handle 4: sfq perturb 10
$tc qdisc add dev eth0 parent 1:5 handle 5: sfq perturb 10

#prioritize traffic
$tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dst 10.0.1.0/24 flowid 1:4
Personal tools