5. Software and Tools

5. Software and Tools
Prev		Next

5.1. Kernel requirements

Many distributions provide kernels with modular or monolithic support for traffic control (Quality of Service). Custom kernels may not already provide support (modular or not) for the required features. If not, this is a very brief listing of the required kernel options.

The user who has little or no experience compiling a kernel is recommended to Kernel HOWTO. Experienced kernel compilers should be able to determine which of the below options apply to the desired configuration, after reading a bit more about traffic control and planning.

Example 1. Kernel compilation options ^[8]

#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y

A kernel compiled with the above set of options will provide modular support for almost everything discussed in this documentation. The user may need to modprobe module before using a given feature. Again, the confused user is recommended to the Kernel HOWTO, as this document cannot adequately address questions about the use of the Linux kernel.

5.2. iproute2 tools (tc)

iproute2 is a suite of command line utilities which manipulate kernel structures for IP networking configuration on a machine. For technical documentation on these tools, see the iproute2 documentation and for a more expository discussion, the documentation at linux-ip.net. Of the tools in the iproute2 package, the binary tc is the only one used for traffic control. This HOWTO will ignore the other tools in the suite.

Because it interacts with the kernel to direct the creation, deletion and modification of traffic control structures, the tc binary needs to be compiled with support for all of the qdiscs you wish to use. In particular, the HTB qdisc is not supported yet in the upstream iproute2 package. See Section 7.1, “HTB, Hierarchical Token Bucket” for more information.

The tc tool performs all of the configuration of the kernel structures required to support traffic control. As a result of its many uses, the command syntax can be described (at best) as arcane. The utility takes as its first non-option argument one of three Linux traffic control components, qdisc, class or filter.

Example 2. tc command usage

[root@leander]# tc
Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }
where  OBJECT := { qdisc | class | filter }
       OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] }

Each object accepts further and different options, and will be incompletely described and documented below. The hints in the examples below are designed to introduce the vagaries of tc command line syntax. For more examples, consult the LARTC HOWTO. For even better understanding, consult the kernel and iproute2 code.

Example 3. tc qdisc

[root@leander]# tc qdisc add    \ 
>                  dev eth0     \ 
>                  root         \ 
>                  handle 1:0   \ 
>                  htb

	Add a queuing discipline. The verb could also be `del`.
	Specify the device onto which we are attaching the new queuing discipline.
	This means “egress” to tc. The word `root` must be used, however. Another qdisc with limited functionality, the `ingress` qdisc can be attached to the same device.
	The `handle` is a user-specified number of the form `major`:`minor`. The minor number for any queueing discipline handle must always be zero (0). An acceptable shorthand for a `qdisc` handle is the syntax "1:", where the minor number is assumed to be zero (0) if not specified.
	This is the queuing discipline to attach, HTB in this example. Queuing discipline specific parameters will follow this. In the example here, we add no qdisc-specific parameters.

Above was the simplest use of the tc utility for adding a queuing discipline to a device. Here's an example of the use of tc to add a class to an existing parent class.

Example 4. tc class

[root@leander]# tc class add    \ 
>                  dev eth0     \ 
>                  parent 1:1   \ 
>                  classid 1:6  \ 
>                  htb          \ 
>                  rate 256kbit \ 
>                  ceil 512kbit

	Add a class. The verb could also be `del`.
	Specify the device onto which we are attaching the new class.
	Specify the parent `handle` to which we are attaching the new class.
	This is a unique `handle` (`major`:`minor`) identifying this class. The minor number must be any non-zero (0) number.
	Both of the classful qdiscs require that any children classes be classes of the same type as the parent. Thus an HTB qdisc will contain HTB classes.
	This is a class specific parameter. Consult Section 7.1, “HTB, Hierarchical Token Bucket” for more detail on these parameters.

Example 5. tc filter

[root@leander]# tc filter add               \ 
>                  dev eth0                 \ 
>                  parent 1:0               \ 
>                  protocol ip              \ 
>                  prio 5                   \ 
>                  u32                      \ 
>                  match ip port 22 0xffff  \ 
>                  match ip tos 0x10 0xff   \ 
>                  flowid 1:6               \ 
>                  police                   \ 
>                  rate 32000bps            \ 
>                  burst 10240              \ 
>                  mpu 0                    \ 
>                  action drop/continue

	Add a filter. The verb could also be `del`.
	Specify the device onto which we are attaching the new filter.
	Specify the parent handle to which we are attaching the new filter.
	This parameter is required. It's use should be obvious, although I don't know more.
	The `prio` parameter allows a given filter to be preferred above another. The `pref` is a synonym.
	This is a `classifier`, and is a required phrase in every tc `filter` command.
	These are parameters to the classifier. In this case, packets with a type of service flag (indicating interactive usage) and matching port 22 will be selected by this statement.
	The `flowid` specifies the `handle` of the target class (or qdisc) to which a matching filter should send its selected packets.
	This is the `policer`, and is an optional phrase in every tc `filter` command.
	The policer will perform one action above this rate, and another action below (see action parameter).
	The `burst` is an exact analog to `burst` in HTB (`burst` is a buckets concept).
	The minimum policed unit. To count all traffic, use an `mpu` of zero (0).
	The `action` indicates what should be done if the `rate` based on the attributes of the policer. The first word specifies the action to take if the policer has been exceeded. The second word specifies action to take otherwise.

As evidenced above, the tc command line utility has an arcane and complex syntax, even for simple operations such as these examples show. It should come as no surprised to the reader that there exists an easier way to configure Linux traffic control. See the next section, Section 5.3, “tcng, Traffic Control Next Generation”.

5.3. tcng, Traffic Control Next Generation

FIXME; sing the praises of tcng. See also Traffic Control using tcng and HTB HOWTO and tcng documentation.

Traffic control next generation (hereafter, tcng) provides all of the power of traffic control under Linux with twenty percent of the headache.

5.4. IMQ, Intermediate Queuing device

FIXME; must discuss IMQ. See also Patrick McHardy's website on IMQ.

Prev		Next
4. Components of Linux Traffic Control	Home	6. Classless Queuing Disciplines (`qdisc`s)