572 lines
29 KiB
Plaintext
572 lines
29 KiB
Plaintext
|
Traffic Control using tcng and HTB HOWTO
|
|||
|
|
|||
|
Version 1.0.1
|
|||
|
|
|||
|
Martin A. Brown
|
|||
|
|
|||
|
[http://linux-ip.net/] linux-ip.net
|
|||
|
Network Administration
|
|||
|
|
|||
|
<martin@linux-ip.net>
|
|||
|
|
|||
|
April 2006
|
|||
|
Revision History
|
|||
|
Revision 1.0.1 2006-10-28 Revised by: MAB
|
|||
|
Updating contact information
|
|||
|
Revision 1.0 2003-04-16 Revised by: tab
|
|||
|
Initial Release, reviewed by LDP
|
|||
|
Revision 0.5 2002-04-01 Revised by: MAB
|
|||
|
submit to tldp, rename/retitle with HOWTO
|
|||
|
Revision 0.4 2002-03-31 Revised by: MAB
|
|||
|
new example, bucket crash course
|
|||
|
Revision 0.3 2002-03-16 Revised by: MAB
|
|||
|
corrections and notes from Jacob Teplitsky, raptor and Joshua Heling
|
|||
|
Revision 0.2 2002-03-15 Revised by: MAB
|
|||
|
links, cleanup, publish
|
|||
|
Revision 0.1 2002-03-14 Revised by: MAB
|
|||
|
initial revision
|
|||
|
|
|||
|
|
|||
|
<EFBFBD> 2006, Martin A. Brown
|
|||
|
|
|||
|
|
|||
|
Permission is granted to copy, distribute and/or modify this document
|
|||
|
under the terms of the GNU Free Documentation License, Version 1.1 or any
|
|||
|
later version published by the Free Software Foundation; with no
|
|||
|
invariant sections, with no Front-Cover Texts, with no Back-Cover Text. A
|
|||
|
copy of the license is located at [http://www.gnu.org/licenses/fdl.html]
|
|||
|
www.gnu.org/copyleft/fdl.html.
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
Table of Contents
|
|||
|
1. Introduction
|
|||
|
1.1. What is traffic control and how does it work?
|
|||
|
1.2. What is htb?
|
|||
|
1.3. What is tcng?
|
|||
|
|
|||
|
|
|||
|
2. Requirements
|
|||
|
2.1. kernel requirements
|
|||
|
2.2. tc requirements
|
|||
|
2.3. tcng requirements
|
|||
|
|
|||
|
|
|||
|
3. Configuration examples
|
|||
|
3.1. Using tcng to shape download only
|
|||
|
3.2. Using a two-rate three-color meter
|
|||
|
|
|||
|
|
|||
|
4. Miscellaneous Notes
|
|||
|
5. Links and Further documentation
|
|||
|
|
|||
|
1. Introduction
|
|||
|
|
|||
|
This is a brief tutorial on using tcng (Traffic Control Next Generation)
|
|||
|
with HTB (Hierarchical Token Bucket) to perform traffic shaping on a Linux
|
|||
|
machine.
|
|||
|
|
|||
|
This tutorial is intended for systems administrators who have
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> AT LEAST, a basic understanding of traffic control
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> EITHER the capability to compile iproute2 and tcng from source
|
|||
|
|
|||
|
OR the capability of building RPMS from provided SRPMs
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> EITHER a modular kernel with support for htb and dsmark
|
|||
|
|
|||
|
OR capability to compile a kernel with support for htb and dsmark
|
|||
|
|
|||
|
|
|||
|
Note This article is neither comprehensive nor authoritative. The author
|
|||
|
solicits positive and negative feedback at <martin@linux-ip.net>.
|
|||
|
Corrections, additions, and further examples are always welcome.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.1. What is traffic control and how does it work?
|
|||
|
|
|||
|
Traffic control is the term given to the entire packet queuing subsystem in
|
|||
|
a network or network device. Traffic control consists of several distinct
|
|||
|
operations. Classifying is a mechanism by which to identify packets and place
|
|||
|
them in individual flows or classes. Policing is a mechanism by which one
|
|||
|
limits the number of packets or bytes in a stream matching a particular
|
|||
|
classification. Scheduling is the decision-making process by which packets
|
|||
|
are ordered and re-ordered for transmission. Shaping is the process by which
|
|||
|
packets are delayed and transmitted to produce an even and predictable flow
|
|||
|
rate.
|
|||
|
|
|||
|
These many characteristics of a traffic control system can be combined in
|
|||
|
complex ways to reserve bandwidth for a particular flow (or application) or
|
|||
|
to limit the amount of bandwidth available to a particular flow or
|
|||
|
application.
|
|||
|
|
|||
|
One of the key concepts of traffic control is the concept of tokens. A
|
|||
|
policing or shaping implementation needs to calculate the number of bytes or
|
|||
|
packets which have passed at what rate. Each packet or byte (depending on the
|
|||
|
implementation), corresponds to a token, and the policing or shaping
|
|||
|
implementation will only transmit or pass the packet if it has a token
|
|||
|
available. A common metaphorical container in which an implementation keeps
|
|||
|
its token is the bucket. In short, a bucket represents the both the number of
|
|||
|
tokens which can be used instantaneously (the size of the bucket), and the
|
|||
|
rate at which the tokens are replenished (how fast the bucket gets refilled).
|
|||
|
|
|||
|
See Section 1.2 for an example of buckets in a linux traffic control
|
|||
|
system.
|
|||
|
|
|||
|
Under linux, traffic control has historically been a complex endeavor. The
|
|||
|
tc command line tool provides an interface to the kernel structures which
|
|||
|
perform the shaping, scheduling, policing and classifying. The syntax of this
|
|||
|
command is, however, arcane. The tcng project provides a much friendlier
|
|||
|
interface to the human by layering a language on top of the powerful tc
|
|||
|
command line tool. By writing traffic control configurations in tcng they
|
|||
|
become easily maintainable, less arcane, and importantly also more portable.
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.2. What is htb?
|
|||
|
|
|||
|
Hierarchichal Token Bucket is a classful qdisc written by Martin Devera
|
|||
|
with a simpler set of configuration parameters than CBQ. There is a great
|
|||
|
deal of documentation on the author's site and also on [http://www.docum.org
|
|||
|
/] Stef Coene's website about HTB and its uses. Below is a very brief sketch
|
|||
|
of the HTB system.
|
|||
|
|
|||
|
Conceptually, HTB is an arbitrary number of token buckets arranged in a
|
|||
|
hierarchy (yes, you probably could have figured that out without my
|
|||
|
sentence). Let's consider the simplest scenario. The primary egress queuing
|
|||
|
discipline on any device is known as the root qdisc.
|
|||
|
|
|||
|
The root qdisc will contain one class (complex scenarios could have
|
|||
|
multiple classes attached to the root qdisc). This single HTB class will be
|
|||
|
set with two parameters, a rate and a ceil. These values should be the same
|
|||
|
for the top-level class, and will represent the total available bandwidth on
|
|||
|
the link.
|
|||
|
|
|||
|
In HTB, rate means the guaranteed bandwidth available for a given class and
|
|||
|
ceil is short for ceiling, which indicates the maximum bandwidth that class
|
|||
|
is allowed to consume. Any bandwidth used between rate and ceil is borrowed
|
|||
|
from a parent class, hence the suggestion that rate and ceil be the same in
|
|||
|
the top-level class.
|
|||
|
|
|||
|
A number of children classes can be made under this class, each of which
|
|||
|
can be allocated some amount of the available bandwidth from the parent
|
|||
|
class. In these children classes, the rate and ceil parameter values need not
|
|||
|
be the same as suggested for the parent class. This allows you to reserve a
|
|||
|
specified amount of bandwidth to a particular class. It also allows HTB to
|
|||
|
calculate the ratio of distribution of available bandwidth to the ratios of
|
|||
|
the classes themselves. This should be more apparent in the examples below.
|
|||
|
|
|||
|
Hierarchical Token Bucket implements a classful queuing mechanism for the
|
|||
|
linux traffic control system, and provides rate and ceil to allow the user to
|
|||
|
control the absolute bandwidth to particular classes of traffic as well as
|
|||
|
indicate the ratio of distribution of bandwidth when extra bandwidth becomes
|
|||
|
available (up to ceil).
|
|||
|
|
|||
|
Keep in mind when choosing the bandwidth for your top-level class that
|
|||
|
traffic shaping only helps if you are the bottleneck between your LAN and the
|
|||
|
Internet. Typically, this is the case in home and office network
|
|||
|
environments, where an entire LAN is serviced by a DSL or T1 connection.
|
|||
|
|
|||
|
In practice, this means that you should probably set the bandwidth for your
|
|||
|
top-level class to your available bandwidth minus a fraction of that
|
|||
|
bandwidth.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
1.3. What is tcng?
|
|||
|
|
|||
|
Traffic Control Next Generation (tcng) is a project by Werner Almesberger
|
|||
|
to provide a powerful, abstract, and uniform language in which to describe
|
|||
|
traffic control structures. The tcc parser in the tcng distribution
|
|||
|
transforms tcng the language into a number of output formats. By default, tcc
|
|||
|
will read a file (specified as an argument or as STDIN) and print to STDOUT
|
|||
|
the series of tc commands (see iproute2 below) required to create the desired
|
|||
|
traffic control structure in the kernel.
|
|||
|
|
|||
|
Consult the parameter reference for tcng to see the supported queuing
|
|||
|
disciplines. Jacob Teplitsky, active on the [http://lartc.org/#mailinglist]
|
|||
|
LARTC mailing list and a contributor to the tcng project, wrote the htb
|
|||
|
support for tcng.
|
|||
|
|
|||
|
The tcc tool can produce a number of different types of output, but this
|
|||
|
document will only consider the conventional and default output. Consult the
|
|||
|
[http://linux-ip.net/gl/tcng/] TCNG manual for more detailed information
|
|||
|
about the use of tcng.
|
|||
|
|
|||
|
The tcsim tool is a traffic control simulator which accepts tcng
|
|||
|
configuration files and reads a control language to simulate the behaviour of
|
|||
|
a kernel sending and receiving packets with the specified control structures.
|
|||
|
Although tcsim is a significant portion of the tcng project, tcsim will not
|
|||
|
be covered here at all.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2. Requirements
|
|||
|
|
|||
|
There are a few requirements in order for the kernel to support HTB and
|
|||
|
DSMARK, tc to support HTB and DSMARK, and tcng itself.
|
|||
|
|
|||
|
Specifically, support for HTB in the kernel and tc is absolutely required
|
|||
|
in order for this tutorial to be remotely useful (refer to the title if htere
|
|||
|
is any doubt in your mind). DSMARK support is, strictly speaking, optional,
|
|||
|
although some examples (class selection path, in particular, but maybe
|
|||
|
others) may not operate without dsmark support.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2.1. kernel requirements
|
|||
|
|
|||
|
The kernel requirements are very easy to meet. Kernel 2.4.20 and newer
|
|||
|
include support for HTB and dsmark, so simply be certain that these options
|
|||
|
are turned on in the QoS/Fair Queuing portion of your kernel configuration.
|
|||
|
For a brief summary of the options to select in kernel configuration, visit
|
|||
|
the DiffServ project kernel configuration notes.
|
|||
|
|
|||
|
For kernels older than 2.4.20, the following tarball containing a patch
|
|||
|
should be applied to your 2.4.17 or newer kernel tree.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2.2. tc requirements
|
|||
|
|
|||
|
The tc command is a part of the iproute2 utility suite. For general
|
|||
|
documentation on iproute2, see [http://linux-ip.net/] http://linux-ip.net/
|
|||
|
and the iproute2 manual. The software itself is available directly from
|
|||
|
Alexey Kuznetsov'z FTP archive but commonly also via packages supplied with
|
|||
|
your linux distribution. If your distribution can make use of RPMS, you can
|
|||
|
download this [http://linux-ip.net/traffic-control/iproute-2.4.7-7.src.rpm]
|
|||
|
SRPM and compile it on your own system.
|
|||
|
|
|||
|
If you need to compile iproute2 yourself, use the patch to tc from this
|
|||
|
tarball at Martin Devera's HTB site in order to provide support for HTB in tc
|
|||
|
.
|
|||
|
|
|||
|
Your tc will also need to support dsmark, the diffserv marking mechanism.
|
|||
|
Fortunately, this is a simple change to the Config file from the iproute2
|
|||
|
source package. Simply change TC_CONFIG_DIFFSERV=n to TC_CONFIG_DIFFSERV=y
|
|||
|
and recompile.
|
|||
|
|
|||
|
The [http://linux-ip.net/traffic-control/iproute-2.4.7-7.src.rpm] SRPM
|
|||
|
creates a tc binary with support for dsmark and for HTB, both of which are
|
|||
|
required for this example.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
2.3. tcng requirements
|
|||
|
|
|||
|
Support for tcng is the easiest part of the process. Simply untar the tcng
|
|||
|
source and run ./configure --no-tcsim before compiling.
|
|||
|
|
|||
|
If you are on an RPM-based system, you can use the SPEC file in tcng/build/
|
|||
|
tcng.spec to build for your distribution, or you can download and compile
|
|||
|
this [http://linux-ip.net/traffic-control/tcng-9d-1.src.rpm] SRPM. The SRPM
|
|||
|
produces two packages, tcc and tcc-devel. You need only tcc to create
|
|||
|
configurations.
|
|||
|
|
|||
|
In order to run the tcc parser, you will also need to have the cpp package
|
|||
|
installed. tcc uses cpp.
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3. Configuration examples
|
|||
|
|
|||
|
Examples shown here will be modified examples of downloadable
|
|||
|
configurations available in [http://linux-ip.net/code/tcng/] this directory.
|
|||
|
|
|||
|
These examples can be used as standalone configuration files to be fed into
|
|||
|
a tcc parser, or they can be used in conjunction with the example SysV
|
|||
|
startup script. The startup script is a modification of a script posted on
|
|||
|
the LARTC mailing list by raptor.
|
|||
|
|
|||
|
If you are going to use the above startup script, take a look at this
|
|||
|
example /etc/sysconfig/tcng:
|
|||
|
|
|||
|
|
|||
|
Example 1. /etc/sysconfig/tcng
|
|||
|
# - tcng meta-configuration file
|
|||
|
# (I never meta-configuration file I didn't like)
|
|||
|
#
|
|||
|
# -- 2003-03-15 created; -MAB
|
|||
|
# -- 2003-03-31 modified to allow ENVAR override; -MAB
|
|||
|
#
|
|||
|
# -- this directory will hold all of the tcng configurations
|
|||
|
# used on this host
|
|||
|
#
|
|||
|
TCCONFBASEDIR=${TCCONFBASEDIR:-/etc/sysconfig/tcng-configs}
|
|||
|
|
|||
|
# -- this is the active, desired tcng configuration
|
|||
|
# note, that, because tcng provides the #include construct,
|
|||
|
# the modularity of configuration can be built into the
|
|||
|
# configuration files in $TCCONFBASEDIR
|
|||
|
#
|
|||
|
TCCONF=${TCCONF:-$TCCONFBASEDIR/global.tcc}
|
|||
|
|
|||
|
tcstats=${tcstats:-no} # -- will suppress statistical output
|
|||
|
tcstats=${tcstats:-yes} # -- will throw the "-s" option to tc
|
|||
|
|
|||
|
tcdebug=${tcdebug:-0} # -- for typical startup script usage
|
|||
|
tcdebug=${tcdebug:-1} # -- for a bit of information about what's happening
|
|||
|
tcdebug=${tcdebug:-2} # -- for debugging information
|
|||
|
#
|
|||
|
#
|
|||
|
# -- an additional measure to take, you can override the default tc and tcc
|
|||
|
# command line utilities by specifying their pathnames here, for example:
|
|||
|
#
|
|||
|
# tc=/usr/local/bin/tc
|
|||
|
# tcc=/usr/local/tcng/bin/tcc
|
|||
|
#
|
|||
|
#
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3.1. Using tcng to shape download only
|
|||
|
|
|||
|
Many general concepts will be introduced with this example. This example
|
|||
|
can be compiled to its tc output with the command tcc
|
|||
|
class-selection-path.tcc.
|
|||
|
|
|||
|
|
|||
|
Example 2. /etc/sysconfig/tcng/class-selection-path.tcc
|
|||
|
/*
|
|||
|
* Simply commented example of a tcng traffic control file.
|
|||
|
*
|
|||
|
* Martin A. Brown <martin@linux-ip.net>
|
|||
|
*
|
|||
|
* Example: Using class selection path.
|
|||
|
*
|
|||
|
* (If you are reading the processed output in HTML, the callouts are
|
|||
|
* clickable links to the description text.)
|
|||
|
*
|
|||
|
*/
|
|||
|
|
|||
|
#include "fields.tc" (1)
|
|||
|
#include "ports.tc"
|
|||
|
|
|||
|
#define INTERFACE eth0 (2)
|
|||
|
|
|||
|
dev INTERFACE {
|
|||
|
egress { (3)
|
|||
|
|
|||
|
/* In class selection path, the filters come first! DSmark */ (4)
|
|||
|
|
|||
|
class ( <$ssh> ) if tcp_sport == 22 && ip_tos_delay == 1 ;
|
|||
|
class ( <$audio> ) if tcp_sport == 554 || tcp_dport == 7070 ;
|
|||
|
class ( <$bulk> ) \
|
|||
|
if tcp_sport == PORT_SSH || tcp_dport == PORT_HTTP ; (5)
|
|||
|
class ( <$other> ) if 1 ; (6)
|
|||
|
|
|||
|
/* section in which we configure the qdiscs and classes */
|
|||
|
|
|||
|
htb () { (7)
|
|||
|
class ( rate 600kbps, ceil 600kbps ) { (8)
|
|||
|
$ssh = class ( rate 64kbps, ceil 128kbps ) { sfq; } ;
|
|||
|
(9) $audio = class ( rate 128kbps, ceil 128kbps ) { sfq; } ;
|
|||
|
$bulk = class ( rate 256kbps, ceil 512kbps ) { sfq; } ;
|
|||
|
$other = class ( rate 128kbps, ceil 384kbps ) { sfq; } ; (10)
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
|
|||
|
|
|||
|
(1) The tcng language provides support for C-style include directives which
|
|||
|
can include any file. Files are included relative to the current
|
|||
|
directory or the tcng library (normally /usr/lib/tcng/include). Strictly
|
|||
|
speaking, it is not necessary to #include ports.tc and fields.tc, because
|
|||
|
tcc will include these by default.
|
|||
|
The use of #include can allow for flexible definition of variables and
|
|||
|
inclusion of common traffic control elements.
|
|||
|
See also the tcng manual on includes.
|
|||
|
|
|||
|
(2) These are CPP directives. The #define can be used to create macros or
|
|||
|
constants. For more on their use, you should see the tcng manual on
|
|||
|
variables.
|
|||
|
(3) The egress keyword is synonymous with the dsmark keyword. The example
|
|||
|
here uses class selection path. It is the use of the egress keyword in
|
|||
|
this configuration which requires dsmark support in the kernel and tc.
|
|||
|
(4) Class selection path is one approach to traffic shaping. In class
|
|||
|
selection path, the packet is marked (DiffServ mark) upon entry into the
|
|||
|
router. The router may take any number of actions or apply any number of
|
|||
|
policing, scheduling or shaping actions on the packet as a result of this
|
|||
|
initial classification.
|
|||
|
Consult the tcng manual on class selection path for further details.
|
|||
|
|
|||
|
(5) This example shows the use of names for the ports instead of numbers.
|
|||
|
This is one of the conveniences of tcng afforded by the automatic
|
|||
|
inclusion of ports.tc. The ports are named in accordance with IANA port
|
|||
|
names. See IANA's registered ports for these names or examine the file
|
|||
|
ports.tc.
|
|||
|
Names and numbers are equally acceptable and valid.
|
|||
|
|
|||
|
(6) Note this peculiar construct which classifies any packet which have not
|
|||
|
yet been classified. Any packet which has not been classified by the
|
|||
|
above classifiers is put into the class "$other" here. The if 1 construct
|
|||
|
can be used to classify the remainder of unclassified traffic.
|
|||
|
(7) This is the creation of the root qdisc which is attached to device,
|
|||
|
eth0 in this case. Consult the reference material in the tcng appendix on
|
|||
|
queuing discipline parameters for valid parameters to each qdisc. Any
|
|||
|
qdisc parameters can be inserted into the parentheses in the same fashion
|
|||
|
as the class parameters further below in the example. If no parameters
|
|||
|
need be specified, the parentheses are optional.
|
|||
|
(8) The top level class in this example sets the maximum bandwidth allowed
|
|||
|
through this class. Let's assume that eth0 is the inside network
|
|||
|
interface of a machine. This limits the total bandwidth to 600 kilobits
|
|||
|
per second transmitted to the internal network.
|
|||
|
The parameters rate and ceil should be familiar to anybody who has used
|
|||
|
HTB. These are HTB specific parameters and are translated properly by the
|
|||
|
tcc utility. See the table on tcng rate and speed specification.
|
|||
|
|
|||
|
(9) This is the assignment of a class to a variable. This is commonly done
|
|||
|
as part of class selection path.
|
|||
|
(10)
|
|||
|
As suggested by Martin Devera on the HTB homepage, an embedded SFQ
|
|||
|
gives each class a fair queuing algorithm for distribution of resources
|
|||
|
to the contenders passing packets through that class. Note the absence of
|
|||
|
any parameters to the embedded queuing discipline.
|
|||
|
If no queuing discipline is specified for leaf classes, they contain
|
|||
|
the default, a pfifo_fast qdisc. The inclusion of a stochastic fair
|
|||
|
queuing qdisc in the leaf classes inhibits the ability of a single
|
|||
|
connection to dominate in a given class.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
3.2. Using a two-rate three-color meter
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Example 3. /etc/sysconfig/tcng/two-rate-three-color-meter.tcc
|
|||
|
/*
|
|||
|
* Simply commented example of a tcng traffic control file.
|
|||
|
*
|
|||
|
* Martin A. Brown <martin@linux-ip.net>
|
|||
|
*
|
|||
|
* Example: Using a meter.
|
|||
|
*
|
|||
|
* (If you are reading the processed output in HTML, the callouts are
|
|||
|
* clickable links to the description text.)
|
|||
|
*
|
|||
|
*/
|
|||
|
|
|||
|
#define EXCEPTION 192.168.137.50
|
|||
|
#define INTERFACE eth0
|
|||
|
|
|||
|
$meter = trTCM( cir 128kbps, cbs 10kB, pir 256kbps, pbs 10kB ); (1)
|
|||
|
|
|||
|
dev eth0 {
|
|||
|
egress {
|
|||
|
class ( <$full> ) if ip_src == EXCEPTION ; (2)
|
|||
|
class ( <$fast> ) if trTCM_green( $meter ) ; (3)
|
|||
|
class ( <$slow> ) if trTCM_yellow( $meter ) ; (4)
|
|||
|
drop if trTCM_red( $meter ) ; (5)
|
|||
|
htb {
|
|||
|
class ( rate 600kbps, ceil 600kbps ) {
|
|||
|
$fast = class ( rate 256kbps, ceil 256kbps ) { sfq; } ;
|
|||
|
$slow = class ( rate 128kbps, ceil 128kbps ) { sfq; } ;
|
|||
|
$full = class ( rate 600kbps, ceil 600kbps ) { sfq; } ;
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
|
|||
|
|
|||
|
(1) This is the declaration of the meter to be used for classifying
|
|||
|
traffic. The underlying technology used to implement this meter is
|
|||
|
policing. See the tcng manual on meters for the different types of
|
|||
|
meters.
|
|||
|
This meter is a two-rate three-color meter, the most complex meter
|
|||
|
available in the tcng language. This meter returns the colors green,
|
|||
|
yellow and red, based on the rates offered in the committed and peak
|
|||
|
buckets. If the metered rate exceeds the committed rate, this meter will
|
|||
|
turn yellow, and if the metered rate exceeds the peak rate, this meter
|
|||
|
will turn red.
|
|||
|
The variable $meter can be operated on by functions applicable to the
|
|||
|
meter type. In this case, there are three functions available for testing
|
|||
|
$meter's state, trTCM_green, trTCM_yellow, and trTCM_red. For efficiency,
|
|||
|
consider also the accelerated counterparts.
|
|||
|
|
|||
|
(2) In this example, the IP 192.168.137.50 is specifically excluded from
|
|||
|
the policing control applied to traffic departing on eth0.
|
|||
|
(3) Up to the committed information rate (cir), packets will pass through
|
|||
|
this class. Tokens will be removed from the cir/cbs bucket.
|
|||
|
The meter is green.
|
|||
|
|
|||
|
(4) Traffic flow exceeding the cir/cbs bucket will be classified here. The
|
|||
|
pir/pbs bucket (pir is peak information rate, pbs is peak burst size).
|
|||
|
This allows a particular flow to be guaranteed one class of service up to
|
|||
|
a given rate, and then be reclassified above that rate.
|
|||
|
The meter is yellow.
|
|||
|
|
|||
|
(5) Traffic flow exceeding the pir/pbs bucket will be classified here. A
|
|||
|
common configuration causes traffic to be dropped above peak rate,
|
|||
|
although traffic could be re-classified into a best-effort class from a
|
|||
|
guaranteed class.
|
|||
|
The meter is red.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
4. Miscellaneous Notes
|
|||
|
|
|||
|
Thankfully, tcng does away with one of the minor annoyances of tc. The
|
|||
|
following table maps the syntax and convention of these tools with English
|
|||
|
equivalents.
|
|||
|
|
|||
|
|
|||
|
Table 1. Speed/Rate syntax: tcng vs. tc
|
|||
|
+----+-----------------------+------------+
|
|||
|
|tcng|English |tc |
|
|||
|
+----+-----------------------+------------+
|
|||
|
|bps |bit(s) per second |bit |
|
|||
|
+----+-----------------------+------------+
|
|||
|
|Bps |byte(s) per second |bps (argh!) |
|
|||
|
+----+-----------------------+------------+
|
|||
|
|kbps|kilobit(s) per second |kbit |
|
|||
|
+----+-----------------------+------------+
|
|||
|
|kBps|kilobyte(s) per second |kbps |
|
|||
|
+----+-----------------------+------------+
|
|||
|
|Mbps|megabit(s) per second |mbit or Mbit|
|
|||
|
+----+-----------------------+------------+
|
|||
|
|MBps|megabyte(s) per second |mbps or Mbps|
|
|||
|
+----+-----------------------+------------+
|
|||
|
|pps |packet per second |?? |
|
|||
|
+----+-----------------------+------------+
|
|||
|
|
|||
|
Note that this means a slight adjustment for longtime users of tc, but a
|
|||
|
much better choice for intuitive usablity for English speakers.
|
|||
|
|
|||
|
For example, we can use conventional expressions of rate in tcng
|
|||
|
configurations: 100Mbps, 128kbps, and even 2Gpps. See also the tcng manual
|
|||
|
[http://linux-ip.net/gl/tcng/node21.html] on units.
|
|||
|
|
|||
|
In order for traffic control to be effective, it is important to understand
|
|||
|
where the bottlenecks are. In most cases, you'll want to perform the traffic
|
|||
|
control at or near the bottleneck.
|
|||
|
|
|||
|
|
|||
|
-----------------------------------------------------------------------------
|
|||
|
|
|||
|
5. Links and Further documentation
|
|||
|
|
|||
|
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> the linux DiffServ project
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> HTB site (Martin "devik" Devera)
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> Traffic Control Next Generation (tcng)
|
|||
|
|
|||
|
TCNG manual (Werner Almesberger)
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> iproute2 (Alexey Kuznetsov)
|
|||
|
|
|||
|
iproute2 manual (Alexey Kuznetsov)
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> Research and documentation on traffic control under linux (Stef Coene)
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> LARTC HOWTO (bert hubert, et. al.)
|
|||
|
|
|||
|
<EFBFBD><EFBFBD>*<2A> guide to IP networking with linux (Martin A. Brown)
|
|||
|
|
|||
|
|