Difference between revisions of "Traffic Control"
(→State of the Code) |
|||
| Line 4: | Line 4: | ||
Of course, Linux traffic control can also be extremely useful in an IT context, and this document is intended to focus on the practical, useful applications of Linux traffic control, where these capabilities can be applied to solve problems that are often experienced on modern networks. | Of course, Linux traffic control can also be extremely useful in an IT context, and this document is intended to focus on the practical, useful applications of Linux traffic control, where these capabilities can be applied to solve problems that are often experienced on modern networks. | ||
| + | |||
| + | == Recommended Approaches == | ||
| + | |||
| + | Daniel Robbins has had very good results with the [http://luxik.cdi.cz/~devik/qos/htb/ HTB queuing discipline] - it has very good features, and also has [http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm very good documentation], which is just as important. And it works. If you use traffic control under Funtoo Linux, please use the HTB queuing discipline as the root queuing discipline because you will get good results in very little time. Avoid using any other queuing discipline under Funtoo Linux. Please see [[Traffic Control#State_of_the_Code State of the Code]] for more info on what Daniel Robbins considers to be the current state of the traffic control implementation in Linux. | ||
== State of the Code == | == State of the Code == | ||
Revision as of 17:26, 6 January 2011
Contents |
Introduction
Linux's traffic control functionality offers a lot of capabilities related to influencing the rate of flow, as well as latency, of primarily outgoing but also in some cases incoming network traffic. It is designed to be a "construction kit" rather than a turn-key system, where complex network traffic policing and shaping decisions can be made using a variety of algorithms. The Linux traffic control code is also often used by academia for research purposes, where is it can be a useful mechanism to simulate and explore the impact of a variety of different network behaviors. See netem for an example of a simulation framework that can be used for this purpose.
Of course, Linux traffic control can also be extremely useful in an IT context, and this document is intended to focus on the practical, useful applications of Linux traffic control, where these capabilities can be applied to solve problems that are often experienced on modern networks.
Recommended Approaches
Daniel Robbins has had very good results with the HTB queuing discipline - it has very good features, and also has very good documentation, which is just as important. And it works. If you use traffic control under Funtoo Linux, please use the HTB queuing discipline as the root queuing discipline because you will get good results in very little time. Avoid using any other queuing discipline under Funtoo Linux. Please see Traffic Control#State_of_the_Code State of the Code for more info on what Daniel Robbins considers to be the current state of the traffic control implementation in Linux.
State of the Code
Unfortunately, significant development of the core (in-kernel) Linux traffic control code hasn't occurred over the last five years, and the current "official" documentation (see http://lartc.org/) is not complete, and also (even worse) avoids mentioning known bugs and issues related to traffic control functionality which often are experienced by users, and are discussed on the mailing list. For this reason, I do not recommend relying on the official documentation for working recipes, although it is a fine reference for Linux traffic control theory. At least one example in the documentation is known to not work reliably (prio queuing discipline -- see below.)
However, there are some positive developments related to Linux traffic control, primarily related to projects that used the traffic control framework but implemented their own queuing disciplines. For example, the HTB packet scheduler appears to be well-maintained, tested and documented and could be a valuable resource for those wishing to use Linux traffic control and avoid implementation problems, and has been merged into the core in-kernel Linux traffic control code. In the future, we hope to offer some working, tested sample recipes using HTB as a basis for traffic control.
In addition, there is also good work being done on Linux IMQ.
It is also possible (though not yet confirmed) that the cbq queuing discipline that was part of the original Linux traffic control may work just fine, despite our poor experiences with prio (see below.) I'd recommend that users first explore HTB and try to get HTB working properly before delving into cbq and beyond to the less-maintained and tested parts of the Linux traffic control implementation.
Bugs
This is not a comprehensive list of problems with Linux traffic control, although please feel free to add documentation to this section as more issues are discovered. The purpose of this section is to document known issues so that other users can avoid struggling with these same issues. Another purpose of this section is to communicate the need to use known, tested recipes for Linux traffic control, and to test any implemented functionality to ensure that proper behavior is observed.
To see actual Linux traffic control code that doesn't work, but should, see Broken Traffic Control. The sub-sections below provide a more general description of the problems encountered.
prio qdisc
In my tests, I have found that the prio queuing discipline, which is one of the most basic ones so it may be appealing to those beginning to play with traffic control, does not work properly and suffers from a number of issues. For one, the priomap functionality is likely broken, and any filters applied to prio may not have their intended effect. In practice, I have seen prio throw away (discard) ARP packets when using a configuration that according to the documentation is completely correct. In practice, prio misbehaves 95% of the time, although in some situations it may work correctly. It also appears that prio may not work correctly on bridges, or interfaces that are in bridges.
This mailing list documents this same behavior as experienced in my testing - that prio may work when used without any filters, but as soon as filters are attached to the qdisc, unusual things happen.
Inspect Your Rules
If you are implementing Linux traffic control, you should be running these commands frequently to monitor the behavior of your queuing discipline. Replace $wanif with the actual network interface name.
tc -s qdisc ls dev $wanif tc -s class ls dev $wanif
Matching
Here are some examples you can use as the basis for your own filters/classifiers:
- u32 match ip protocol 0x11 0xff - match UDP packets
- u32 match ip protocol 0x6 0xff - match TCP packets
- u32 match ip protocol 1 0xff - match ICMP (ping) packets
- u32 match ip dst 4.3.2.1/32 - match all IP traffic headed for IP 4.3.2.1
- u32 match ip src 4.3.2.1/32 match ip sport 80 0xffff - match all IP traffic from 4.3.2.1 port 80
- u32 match ip sport 53 0xffff - match originating DNS (both TCP and UDP)
- u32 match ip dport 53 0xffff - match response DNS (both TCP and UDP)
- u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthdr+13 - match packets with ACK bit set
- u32 match ip protocol 6 0xff match u8 0x10 0xff at nexthdr+13 match u16 0x0000 0xffc0 at 2 - packets less than 64 bytes in size with ACK bit set
- u32 match ip tos 0x10 0xff - match IP packets with "type of service" set to "Minimize delay"/"Interactive"
- u32 match ip tos 0x08 0xff - match IP packets with "type of service" set to "Maximize throughput"/"Bulk" (see "QDISC PARAMETERS" in tc-prio man page)
- u32 match tcp dport 53 0xffff match ip protocol 0x6 0xff - match TCP packets heading for dest. port 53 (my not work)
