6711 lines
124 KiB
HTML
6711 lines
124 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|||
|
<HTML
|
|||
|
><HEAD
|
|||
|
><TITLE
|
|||
|
>Traffic Control HOWTO</TITLE
|
|||
|
><META
|
|||
|
NAME="GENERATOR"
|
|||
|
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"></HEAD
|
|||
|
><BODY
|
|||
|
CLASS="article"
|
|||
|
BGCOLOR="#FFFFFF"
|
|||
|
TEXT="#000000"
|
|||
|
LINK="#0000FF"
|
|||
|
VLINK="#840084"
|
|||
|
ALINK="#0000FF"
|
|||
|
><DIV
|
|||
|
CLASS="ARTICLE"
|
|||
|
><DIV
|
|||
|
CLASS="TITLEPAGE"
|
|||
|
><H1
|
|||
|
CLASS="title"
|
|||
|
><A
|
|||
|
NAME="AEN2"
|
|||
|
></A
|
|||
|
>Traffic Control HOWTO</H1
|
|||
|
><H2
|
|||
|
CLASS="subtitle"
|
|||
|
>Version 1.0.2</H2
|
|||
|
><H3
|
|||
|
CLASS="author"
|
|||
|
><A
|
|||
|
NAME="AEN5"
|
|||
|
>Martin A. Brown</A
|
|||
|
></H3
|
|||
|
><DIV
|
|||
|
CLASS="affiliation"
|
|||
|
><SPAN
|
|||
|
CLASS="orgname"
|
|||
|
> <A
|
|||
|
HREF="http://linux-ip.net/"
|
|||
|
TARGET="_top"
|
|||
|
>linux-ip.net</A
|
|||
|
>
|
|||
|
<BR></SPAN
|
|||
|
><DIV
|
|||
|
CLASS="address"
|
|||
|
><P
|
|||
|
CLASS="address"
|
|||
|
><TT
|
|||
|
CLASS="email"
|
|||
|
><<A
|
|||
|
HREF="mailto:martin@linux-ip.net"
|
|||
|
>martin@linux-ip.net</A
|
|||
|
>></TT
|
|||
|
></P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
CLASS="pubdate"
|
|||
|
>"Oct 2006"
|
|||
|
<BR></P
|
|||
|
><DIV
|
|||
|
CLASS="revhistory"
|
|||
|
><TABLE
|
|||
|
WIDTH="100%"
|
|||
|
BORDER="0"
|
|||
|
><TR
|
|||
|
><TH
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
COLSPAN="3"
|
|||
|
><B
|
|||
|
>Revision History</B
|
|||
|
></TH
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 1.0.2</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2006-10-28</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>Add references to HFSC, alter author email addresses</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 1.0.1</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-11-17</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>Added link to Leonardo Balliache's documentation</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 1.0</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-09-24</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>reviewed and approved by TLDP</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 0.7</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-09-14</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>incremental revisions, proofreading, ready for TLDP</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 0.6</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-09-09</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>minor editing, corrections from Stef Coene</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 0.5</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-09-01</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>HTB section mostly complete, more diagrams, LARTC pre-release</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 0.4</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-08-30</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>added diagram</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 0.3</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-08-29</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>substantial completion of classless, software, rules,
|
|||
|
elements and components sections</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 0.2</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-08-23</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>major work on overview, elements, components and
|
|||
|
software sections</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revision 0.1</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>2003-08-15</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
>Revised by: MAB</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
COLSPAN="3"
|
|||
|
>initial revision (outline complete)</TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
><DIV
|
|||
|
CLASS="abstract"
|
|||
|
><A
|
|||
|
NAME="AEN71"
|
|||
|
></A
|
|||
|
><P
|
|||
|
></P
|
|||
|
><P
|
|||
|
> Traffic control encompasses the sets of mechanisms and operations by
|
|||
|
which packets are queued for transmission/reception on a network
|
|||
|
interface. The operations include enqueuing, policing, classifying,
|
|||
|
scheduling, shaping and dropping. This HOWTO provides an introduction
|
|||
|
and overview of the capabilities and implementation of traffic control
|
|||
|
under Linux.
|
|||
|
</P
|
|||
|
><P
|
|||
|
></P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="legalnotice"
|
|||
|
><A
|
|||
|
NAME="legalnotice"
|
|||
|
></A
|
|||
|
><P
|
|||
|
></P
|
|||
|
><P
|
|||
|
><3E> 2006, Martin A. Brown</P
|
|||
|
><A
|
|||
|
NAME="AEN17"
|
|||
|
></A
|
|||
|
><BLOCKQUOTE
|
|||
|
CLASS="BLOCKQUOTE"
|
|||
|
><P
|
|||
|
> 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
|
|||
|
<A
|
|||
|
HREF="http://www.gnu.org/licenses/fdl.html"
|
|||
|
TARGET="_top"
|
|||
|
>http://www.gnu.org/licenses/fdl.html</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></BLOCKQUOTE
|
|||
|
><P
|
|||
|
></P
|
|||
|
></DIV
|
|||
|
><HR></DIV
|
|||
|
><DIV
|
|||
|
CLASS="TOC"
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
><B
|
|||
|
>Table of Contents</B
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>1. <A
|
|||
|
HREF="#intro"
|
|||
|
>Introduction to Linux Traffic Control</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>1.1. <A
|
|||
|
HREF="#i-assumptions"
|
|||
|
>Target audience and assumptions about the reader</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>1.2. <A
|
|||
|
HREF="#i-conventions"
|
|||
|
>Conventions</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>1.3. <A
|
|||
|
HREF="#i-recommendation"
|
|||
|
>Recommended approach</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>1.4. <A
|
|||
|
HREF="#i-missing"
|
|||
|
>Missing content, corrections and feedback</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>2. <A
|
|||
|
HREF="#overview"
|
|||
|
>Overview of Concepts</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>2.1. <A
|
|||
|
HREF="#o-what-is"
|
|||
|
>What is it?</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>2.2. <A
|
|||
|
HREF="#o-why-use"
|
|||
|
>Why use it?</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>2.3. <A
|
|||
|
HREF="#o-advantages"
|
|||
|
>Advantages</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>2.4. <A
|
|||
|
HREF="#o-disadvantages"
|
|||
|
>Disdvantages</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>2.5. <A
|
|||
|
HREF="#o-queues"
|
|||
|
>Queues</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>2.6. <A
|
|||
|
HREF="#o-flows"
|
|||
|
>Flows</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>2.7. <A
|
|||
|
HREF="#o-tokens"
|
|||
|
>Tokens and buckets</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>2.8. <A
|
|||
|
HREF="#o-packets"
|
|||
|
>Packets and frames</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>3. <A
|
|||
|
HREF="#elements"
|
|||
|
>Traditional Elements of Traffic Control</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>3.1. <A
|
|||
|
HREF="#e-shaping"
|
|||
|
>Shaping</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>3.2. <A
|
|||
|
HREF="#e-scheduling"
|
|||
|
>Scheduling</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>3.3. <A
|
|||
|
HREF="#e-classifying"
|
|||
|
>Classifying</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>3.4. <A
|
|||
|
HREF="#e-policing"
|
|||
|
>Policing</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>3.5. <A
|
|||
|
HREF="#e-dropping"
|
|||
|
>Dropping</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>3.6. <A
|
|||
|
HREF="#e-marking"
|
|||
|
>Marking</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>4. <A
|
|||
|
HREF="#components"
|
|||
|
>Components of Linux Traffic Control</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>4.1. <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>4.2. <A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>4.3. <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>4.4. <A
|
|||
|
HREF="#c-classifier"
|
|||
|
>classifier</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>4.5. <A
|
|||
|
HREF="#c-police"
|
|||
|
>policer</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>4.6. <A
|
|||
|
HREF="#c-drop"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>drop</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>4.7. <A
|
|||
|
HREF="#c-handle"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>handle</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>5. <A
|
|||
|
HREF="#software"
|
|||
|
>Software and Tools</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>5.1. <A
|
|||
|
HREF="#s-kernel"
|
|||
|
>Kernel requirements</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>5.2. <A
|
|||
|
HREF="#s-iproute2"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> tools (<B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
>)</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>5.3. <A
|
|||
|
HREF="#s-tcng"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
>, Traffic Control Next Generation</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>5.4. <A
|
|||
|
HREF="#s-imq"
|
|||
|
>IMQ, Intermediate Queuing device</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>6. <A
|
|||
|
HREF="#classless-qdiscs"
|
|||
|
>Classless Queuing Disciplines (<A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s)</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>6.1. <A
|
|||
|
HREF="#qs-fifo"
|
|||
|
>FIFO, First-In First-Out (<TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo</TT
|
|||
|
> and <TT
|
|||
|
CLASS="constant"
|
|||
|
>bfifo</TT
|
|||
|
>)</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>6.2. <A
|
|||
|
HREF="#qs-pfifo_fast"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
>, the default Linux qdisc</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>6.3. <A
|
|||
|
HREF="#qs-sfq"
|
|||
|
>SFQ, Stochastic Fair Queuing</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>6.4. <A
|
|||
|
HREF="#qs-esfq"
|
|||
|
>ESFQ, Extended Stochastic Fair Queuing</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>6.5. <A
|
|||
|
HREF="#qs-gred"
|
|||
|
>GRED, Generic Random Early Drop</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>6.6. <A
|
|||
|
HREF="#qs-tbf"
|
|||
|
>TBF, Token Bucket Filter</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>7. <A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>Classful Queuing Disciplines (<A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s)</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>7.1. <A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB, Hierarchical Token Bucket</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>7.2. <A
|
|||
|
HREF="#qc-hfsc"
|
|||
|
>HFSC, Hierarchical Fair Service Curve</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>7.3. <A
|
|||
|
HREF="#qc-prio"
|
|||
|
>PRIO, priority scheduler</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>7.4. <A
|
|||
|
HREF="#qc-cbq"
|
|||
|
>CBQ, Class Based Queuing</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>8. <A
|
|||
|
HREF="#rules"
|
|||
|
>Rules, Guidelines and Approaches</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>8.1. <A
|
|||
|
HREF="#r-general"
|
|||
|
>General Rules of Linux Traffic Control</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>8.2. <A
|
|||
|
HREF="#r-known-bandwidth"
|
|||
|
>Handling a link with a known bandwidth</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>8.3. <A
|
|||
|
HREF="#r-unknown-bandwidth"
|
|||
|
>Handling a link with a variable (or unknown) bandwidth</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>8.4. <A
|
|||
|
HREF="#r-sharing-flows"
|
|||
|
>Sharing/splitting bandwidth based on flows</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>8.5. <A
|
|||
|
HREF="#r-sharing-ips"
|
|||
|
>Sharing/splitting bandwidth based on IP</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>9. <A
|
|||
|
HREF="#scripts"
|
|||
|
>Scripts for use with QoS/Traffic Control</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>9.1. <A
|
|||
|
HREF="#sc-wondershaper"
|
|||
|
>wondershaper</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>9.2. <A
|
|||
|
HREF="#sc-myshaper"
|
|||
|
>ADSL Bandwidth HOWTO script (<TT
|
|||
|
CLASS="filename"
|
|||
|
>myshaper</TT
|
|||
|
>)</A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>9.3. <A
|
|||
|
HREF="#sc-htb.init"
|
|||
|
><TT
|
|||
|
CLASS="filename"
|
|||
|
>htb.init</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>9.4. <A
|
|||
|
HREF="#sc-tcng.init"
|
|||
|
><TT
|
|||
|
CLASS="filename"
|
|||
|
>tcng.init</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DT
|
|||
|
>9.5. <A
|
|||
|
HREF="#sc-cbq.init"
|
|||
|
><TT
|
|||
|
CLASS="filename"
|
|||
|
>cbq.init</TT
|
|||
|
></A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>10. <A
|
|||
|
HREF="#diagram"
|
|||
|
>Diagram</A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
>10.1. <A
|
|||
|
HREF="#d-general"
|
|||
|
>General diagram</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
>11. <A
|
|||
|
HREF="#links"
|
|||
|
>Annotated Traffic Control Links</A
|
|||
|
></DT
|
|||
|
></DL
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="intro"
|
|||
|
></A
|
|||
|
>1. Introduction to Linux Traffic Control</H1
|
|||
|
><P
|
|||
|
> Linux offers a very rich set of tools for managing and manipulating the
|
|||
|
transmission of packets. The larger Linux community is very familiar with
|
|||
|
the tools available under Linux for packet mangling and firewalling
|
|||
|
(netfilter, and before that, ipchains) as well as hundreds of network
|
|||
|
services which can run on the operating system. Few inside the community
|
|||
|
and fewer outside the Linux community are aware of the tremendous power of
|
|||
|
the traffic control subsystem which has grown and matured under kernels
|
|||
|
2.2 and 2.4.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> This HOWTO purports to introduce the
|
|||
|
<A
|
|||
|
HREF="#overview"
|
|||
|
>concepts of traffic control</A
|
|||
|
>,
|
|||
|
<A
|
|||
|
HREF="#elements"
|
|||
|
>the traditional elements (in general)</A
|
|||
|
>,
|
|||
|
<A
|
|||
|
HREF="#components"
|
|||
|
>the components of the Linux traffic control
|
|||
|
implementation</A
|
|||
|
> and provide some
|
|||
|
<A
|
|||
|
HREF="#rules"
|
|||
|
>guidelines</A
|
|||
|
>
|
|||
|
.
|
|||
|
This HOWTO represents the collection, amalgamation and synthesis of the
|
|||
|
<A
|
|||
|
HREF="http://lartc.org/howto/"
|
|||
|
TARGET="_top"
|
|||
|
>LARTC HOWTO</A
|
|||
|
>, documentation from individual projects and importantly
|
|||
|
the <A
|
|||
|
HREF="http://mailman.ds9a.nl/mailman/listinfo/lartc/"
|
|||
|
TARGET="_top"
|
|||
|
>LARTC
|
|||
|
mailing list</A
|
|||
|
> over a period of study.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The impatient soul, who simply wishes to experiment right now, is
|
|||
|
recommended to the <A
|
|||
|
HREF="http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/"
|
|||
|
TARGET="_top"
|
|||
|
> Traffic Control using tcng and HTB HOWTO</A
|
|||
|
> and <A
|
|||
|
HREF="http://lartc.org/howto/"
|
|||
|
TARGET="_top"
|
|||
|
>LARTC HOWTO</A
|
|||
|
> for
|
|||
|
immediate satisfaction.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="i-assumptions"
|
|||
|
></A
|
|||
|
>1.1. Target audience and assumptions about the reader</H2
|
|||
|
><P
|
|||
|
> The target audience for this HOWTO is the network administrator or savvy
|
|||
|
home user who desires an introduction to the field of traffic control
|
|||
|
and an overview of the tools available under Linux for implementing
|
|||
|
traffic control.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> I assume that the reader is comfortable with UNIX concepts and the
|
|||
|
command line and has a basic knowledge of IP networking. Users who wish
|
|||
|
to implement traffic control may require the ability to patch, compile
|
|||
|
and install a kernel or software package
|
|||
|
<A
|
|||
|
NAME="AEN91"
|
|||
|
HREF="#FTN.AEN91"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[1]</SPAN
|
|||
|
></A
|
|||
|
>. For users with newer kernels
|
|||
|
(2.4.20+, see also
|
|||
|
<A
|
|||
|
HREF="#s-kernel"
|
|||
|
>Section 5.1</A
|
|||
|
>), however, the ability to install and use
|
|||
|
software may be all that is required.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Broadly speaking, this HOWTO was written with a sophisticated user in
|
|||
|
mind, perhaps one who has already had experience with traffic control
|
|||
|
under Linux. I assume that the reader may have
|
|||
|
no prior traffic control experience.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="i-conventions"
|
|||
|
></A
|
|||
|
>1.2. Conventions</H2
|
|||
|
><P
|
|||
|
> This text was written in
|
|||
|
<A
|
|||
|
HREF="http://www.docbook.org/"
|
|||
|
TARGET="_top"
|
|||
|
>DocBook</A
|
|||
|
>
|
|||
|
(<A
|
|||
|
HREF="http://www.docbook.org/xml/4.2/index.html"
|
|||
|
TARGET="_top"
|
|||
|
>version 4.2</A
|
|||
|
>)
|
|||
|
with
|
|||
|
<A
|
|||
|
HREF="http://vim.sourceforge.net/"
|
|||
|
TARGET="_top"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>vim</B
|
|||
|
></A
|
|||
|
>.
|
|||
|
All formatting has been applied by
|
|||
|
<A
|
|||
|
HREF="http://xmlsoft.org/XSLT/"
|
|||
|
TARGET="_top"
|
|||
|
>xsltproc</A
|
|||
|
> based on
|
|||
|
<A
|
|||
|
HREF="http://docbook.sourceforge.net/projects/xsl/"
|
|||
|
TARGET="_top"
|
|||
|
>DocBook
|
|||
|
XSL</A
|
|||
|
> and
|
|||
|
<A
|
|||
|
HREF="http://www.tldp.org/LDP/LDP-Author-Guide/usingldpxsl.html"
|
|||
|
TARGET="_top"
|
|||
|
>LDP
|
|||
|
XSL</A
|
|||
|
> stylesheets. Typeface formatting and display conventions
|
|||
|
are similar to most printed and electronically distributed technical
|
|||
|
documentation.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="i-recommendation"
|
|||
|
></A
|
|||
|
>1.3. Recommended approach</H2
|
|||
|
><P
|
|||
|
> I strongly recommend to the eager reader making a first foray into the
|
|||
|
discipline of traffic control, to become only casually familiar with the
|
|||
|
<A
|
|||
|
HREF="#s-iproute2-tc"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
></A
|
|||
|
> command line utility, before concentrating on <A
|
|||
|
HREF="#s-tcng"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
></A
|
|||
|
>. The
|
|||
|
<B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> software package defines an entire language for describing
|
|||
|
traffic control structures.
|
|||
|
At first, this language may seem daunting, but mastery of these basics
|
|||
|
will quickly provide the user with a much wider ability to employ (and
|
|||
|
deploy) traffic control configurations than the direct use of <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
>
|
|||
|
would afford.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Where possible, I'll try to prefer describing the behaviour of
|
|||
|
the Linux traffic control system in an abstract manner, although in
|
|||
|
many cases I'll need to supply the syntax of one or the other common
|
|||
|
systems for defining these structures. I may not supply examples in
|
|||
|
both the <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> language and the <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> command line, so the wise user
|
|||
|
will have some familiarity with both.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="i-missing"
|
|||
|
></A
|
|||
|
>1.4. Missing content, corrections and feedback</H2
|
|||
|
><P
|
|||
|
> There is content yet missing from this HOWTO. In particular, the
|
|||
|
following items will be added at some point to this documentation.
|
|||
|
</P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><UL
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A description and diagram of GRED, WRR, PRIO
|
|||
|
and CBQ.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A section of examples.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A section detailing the classifiers.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A section discussing the techniques for measuring traffic.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A section covering meters.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> More details on <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
></UL
|
|||
|
><P
|
|||
|
> I welcome suggestions, corrections and feedback at <TT
|
|||
|
CLASS="email"
|
|||
|
><<A
|
|||
|
HREF="mailto:martin@linux-ip.net"
|
|||
|
>martin@linux-ip.net</A
|
|||
|
>></TT
|
|||
|
>. All errors
|
|||
|
and omissions are strictly my fault. Although I have made every effort
|
|||
|
to verify the factual correctness of the content presented herein, I
|
|||
|
cannot accept any responsibility for actions taken under the influence
|
|||
|
of this documentation.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="overview"
|
|||
|
></A
|
|||
|
>2. Overview of Concepts</H1
|
|||
|
><P
|
|||
|
> This section will
|
|||
|
<A
|
|||
|
HREF="#o-what-is"
|
|||
|
>introduce traffic control</A
|
|||
|
> and
|
|||
|
<A
|
|||
|
HREF="#o-why-use"
|
|||
|
>examine reasons for it</A
|
|||
|
>,
|
|||
|
identify a few
|
|||
|
<A
|
|||
|
HREF="#o-advantages"
|
|||
|
>advantages</A
|
|||
|
> and
|
|||
|
<A
|
|||
|
HREF="#o-disadvantages"
|
|||
|
>disadvantages</A
|
|||
|
> and
|
|||
|
introduce key concepts used in traffic control.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-what-is"
|
|||
|
></A
|
|||
|
>2.1. What is it?</H2
|
|||
|
><P
|
|||
|
> Traffic control is the name given to the sets of queuing systems and
|
|||
|
mechanisms by which packets are received and transmitted on a router.
|
|||
|
This includes deciding which (and whether) packets to accept at what
|
|||
|
rate on the input of an interface and determining which packets to
|
|||
|
transmit in what order at what rate on the output of an interface.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> In the overwhelming majority of situations, traffic control consists of
|
|||
|
a single queue which collects entering packets and dequeues them as
|
|||
|
quickly as the hardware (or underlying device) can accept them. This
|
|||
|
sort of queue is a FIFO.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="note"
|
|||
|
><P
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
CLASS="note"
|
|||
|
WIDTH="100%"
|
|||
|
BORDER="0"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25"
|
|||
|
ALIGN="CENTER"
|
|||
|
VALIGN="TOP"
|
|||
|
><IMG
|
|||
|
SRC="../images/note.gif"
|
|||
|
HSPACE="5"
|
|||
|
ALT="Note"></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
>The default qdisc under Linux is the <A
|
|||
|
HREF="#qs-pfifo_fast"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
></A
|
|||
|
>, which is
|
|||
|
slightly more complex than the <A
|
|||
|
HREF="#qs-fifo"
|
|||
|
>FIFO</A
|
|||
|
>.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> There are examples of queues in all sorts of software. The queue is a
|
|||
|
way of organizing the pending tasks or data (see also
|
|||
|
<A
|
|||
|
HREF="#o-queues"
|
|||
|
>Section 2.5</A
|
|||
|
>). Because network links typically carry data
|
|||
|
in a serialized fashion, a queue is required to manage the outbound
|
|||
|
data packets.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> In the case of a desktop machine and an efficient webserver sharing the
|
|||
|
same uplink to the Internet, the following contention for bandwidth may
|
|||
|
occur. The web server may be able to fill up the output queue on the
|
|||
|
router faster than the data can be transmitted across the link, at which
|
|||
|
point the router starts to drop packets (its buffer is full!). Now, the
|
|||
|
desktop machine (with an interactive application user) may be faced with
|
|||
|
packet loss and high latency. Note that high latency sometimes leads to
|
|||
|
screaming users! By separating the internal queues used to service
|
|||
|
these two different classes of application, there can be better sharing
|
|||
|
of the network resource between the two applications.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Traffic control is the set of tools which allows the user to have
|
|||
|
granular control over these queues and the queuing mechanisms of a
|
|||
|
networked device. The power to rearrange traffic flows and packets with
|
|||
|
these tools is tremendous and can be complicated, but is no substitute
|
|||
|
for adequate bandwidth.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The term Quality of Service (QoS) is often used as a synonym for traffic
|
|||
|
control.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-why-use"
|
|||
|
></A
|
|||
|
>2.2. Why use it?</H2
|
|||
|
><P
|
|||
|
> Packet-switched networks differ from circuit based networks in one very
|
|||
|
important regard. A packet-switched network itself is stateless. A
|
|||
|
circuit-based network (such as a telephone network) must hold state
|
|||
|
within the network. IP networks are stateless and packet-switched
|
|||
|
networks by design; in fact, this statelessness is one of the
|
|||
|
fundamental strengths of IP.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The weakness of this statelessness is the lack of differentiation
|
|||
|
between types of flows. In simplest terms, traffic control allows an
|
|||
|
administrator to queue packets differently based on attributes of the
|
|||
|
packet. It can even be used to simulate the behaviour of a
|
|||
|
circuit-based network. This introduces statefulness into the stateless
|
|||
|
network.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> There are many practical reasons to consider traffic control, and many
|
|||
|
scenarios in which using traffic control makes sense. Below are some
|
|||
|
examples of common problems which can be solved or at least ameliorated
|
|||
|
with these tools.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The list below is not an exhaustive list of the sorts of solutions
|
|||
|
available to users of traffic control, but introduces the
|
|||
|
types of problems that can be solved by using traffic control to
|
|||
|
maximize the usability of a network connection.
|
|||
|
</P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Common traffic control solutions</B
|
|||
|
></P
|
|||
|
><UL
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Limit total bandwidth to a known rate; <A
|
|||
|
HREF="#qs-tbf"
|
|||
|
>TBF</A
|
|||
|
>,
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
> with child class(es).
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Limit the bandwidth of a particular user, service or client;
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
> classes and <A
|
|||
|
HREF="#e-classifying"
|
|||
|
>classifying</A
|
|||
|
> with a
|
|||
|
<A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>. traffic.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Maximize TCP throughput on an asymmetric link; prioritize
|
|||
|
transmission of ACK packets, <A
|
|||
|
HREF="#sc-wondershaper"
|
|||
|
>wondershaper</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Reserve bandwidth for a particular application or user;
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
> with children classes and <A
|
|||
|
HREF="#e-classifying"
|
|||
|
>classifying</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Prefer latency sensitive traffic; <A
|
|||
|
HREF="#qc-prio"
|
|||
|
>PRIO</A
|
|||
|
> inside an
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
> class.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Managed oversubscribed bandwidth; <A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
> with borrowing.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Allow equitable distribution of unreserved bandwidth; <A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
>
|
|||
|
with borrowing.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Ensure that a particular type of traffic is dropped; <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
>
|
|||
|
attached to a <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> with a <A
|
|||
|
HREF="#c-drop"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>drop</TT
|
|||
|
></A
|
|||
|
> action.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
></UL
|
|||
|
><P
|
|||
|
> Remember, too that sometimes, it is simply better to purchase more
|
|||
|
bandwidth. Traffic control does not solve all problems!
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-advantages"
|
|||
|
></A
|
|||
|
>2.3. Advantages</H2
|
|||
|
><P
|
|||
|
> When properly employed, traffic control should lead to more predictable
|
|||
|
usage of network resources and less volatile contention for these
|
|||
|
resources. The network then meets the goals of the traffic control
|
|||
|
configuration. Bulk download traffic can be allocated a reasonable
|
|||
|
amount of bandwidth even as higher priority interactive traffic is
|
|||
|
simultaneously
|
|||
|
serviced. Even low priority data transfer such as mail can
|
|||
|
be allocated bandwidth without tremendously affecting the other classes
|
|||
|
of traffic.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> In a larger picture, if the traffic control configuration represents
|
|||
|
policy which has been communicated to the users, then users (and,
|
|||
|
by extension, applications) know what to expect from the network.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-disadvantages"
|
|||
|
></A
|
|||
|
>2.4. Disdvantages</H2
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> Complexity is easily one of the most significant disadvantages of using
|
|||
|
traffic control. There are ways to become familiar with traffic control
|
|||
|
tools which ease the learning curve about traffic control and its
|
|||
|
mechanisms, but identifying a traffic control misconfiguration can be
|
|||
|
quite a challenge.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Traffic control when used appropriately can lead to more equitable
|
|||
|
distribution of network resources. It can just as easily be installed
|
|||
|
in an inappropriate manner leading to further and more divisive
|
|||
|
contention for resources.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The computing resources required on a router to support a traffic
|
|||
|
control scenario need to be capable of handling the increased cost of
|
|||
|
maintaining the traffic control structures. Fortunately, this is a
|
|||
|
small incremental cost, but can become more significant as the
|
|||
|
configuration grows in size and complexity.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> For personal use, there's no training cost associated with the use of
|
|||
|
traffic control, but a company may find that purchasing more bandwidth
|
|||
|
is a simpler solution than employing traffic control. Training
|
|||
|
employees and ensuring depth of knowledge may be more costly than
|
|||
|
investing in more bandwidth.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Although
|
|||
|
traffic control on packet-switched networks covers a larger conceptual
|
|||
|
area, you can think of traffic control as a way to provide [some of] the
|
|||
|
statefulness of a circuit-based network to a packet-switched network.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-queues"
|
|||
|
></A
|
|||
|
>2.5. Queues</H2
|
|||
|
><P
|
|||
|
> Queues form the backdrop for all of traffic control and are the integral
|
|||
|
concept behind scheduling. A queue is a location (or buffer) containing
|
|||
|
a finite number of items waiting for an action or service. In
|
|||
|
networking, a queue is the place where packets (our units) wait to be
|
|||
|
transmitted by the hardware (the service). In the simplest model,
|
|||
|
packets are transmitted in a first-come first-serve basis
|
|||
|
<A
|
|||
|
NAME="AEN220"
|
|||
|
HREF="#FTN.AEN220"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[2]</SPAN
|
|||
|
></A
|
|||
|
>.
|
|||
|
In the discipline of computer networking (and more generally
|
|||
|
computer science), this sort of a queue is known as a FIFO.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Without any other mechanisms, a queue doesn't offer any promise for
|
|||
|
traffic control. There are only two interesting actions in a queue.
|
|||
|
Anything entering a queue is enqueued into the queue. To remove an item
|
|||
|
from a queue is to dequeue that item.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> A queue becomes much more interesting when coupled with other mechanisms
|
|||
|
which can delay packets, rearrange, drop and prioritize packets in
|
|||
|
multiple queues. A queue can also use subqueues, which allow for
|
|||
|
complexity of behaviour in a scheduling operation.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> From the perspective of the higher layer software, a packet is simply
|
|||
|
enqueued for transmission, and the manner and order in which the
|
|||
|
enqueued packets are transmitted is immaterial to the higher layer. So,
|
|||
|
to the higher layer, the entire traffic control system may appear as a
|
|||
|
single queue
|
|||
|
<A
|
|||
|
NAME="AEN225"
|
|||
|
HREF="#FTN.AEN225"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[3]</SPAN
|
|||
|
></A
|
|||
|
>.
|
|||
|
It is only by examining the internals of this layer that
|
|||
|
the traffic control structures become exposed and available.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-flows"
|
|||
|
></A
|
|||
|
>2.6. Flows</H2
|
|||
|
><P
|
|||
|
> A flow is a distinct connection or conversation between two hosts. Any
|
|||
|
unique set of packets between two hosts can be regarded as a flow.
|
|||
|
Under TCP the concept of a connection with a source IP and port and
|
|||
|
destination IP and port represents a flow. A UDP flow can be similarly
|
|||
|
defined.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Traffic control mechanisms frequently separate traffic into classes of
|
|||
|
flows which can be aggregated and transmitted as an aggregated flow
|
|||
|
(consider DiffServ). Alternate mechanisms may attempt to divide
|
|||
|
bandwidth equally based on the individual flows.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Flows become important when attempting to divide bandwidth equally among
|
|||
|
a set of competing flows, especially when some applications deliberately
|
|||
|
build a large number of flows.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-tokens"
|
|||
|
></A
|
|||
|
>2.7. Tokens and buckets</H2
|
|||
|
><A
|
|||
|
NAME="o-buckets"
|
|||
|
></A
|
|||
|
><P
|
|||
|
> Two of the key underpinnings of a <A
|
|||
|
HREF="#e-shaping"
|
|||
|
>shaping</A
|
|||
|
> mechanisms are
|
|||
|
the interrelated concepts of tokens and buckets.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> In order to control the rate of dequeuing, an implementation can count
|
|||
|
the number of packets or bytes dequeued as each item is dequeued,
|
|||
|
although this requires complex usage of timers and measurements to limit
|
|||
|
accurately. Instead of calculating the current usage and time, one
|
|||
|
method, used widely in traffic control, is to generate tokens at a
|
|||
|
desired rate, and only dequeue packets or bytes if a token is available.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Consider the analogy of an amusement park ride with a queue of people
|
|||
|
waiting to experience the ride. Let's imagine a track on which carts
|
|||
|
traverse a fixed track. The carts arrive at the head of the queue at a
|
|||
|
fixed rate. In order to enjoy the ride, each person must wait for an
|
|||
|
available cart. The cart is analogous to a token and the person is
|
|||
|
analogous to a packet. Again, this mechanism is a rate-limiting or
|
|||
|
<A
|
|||
|
HREF="#e-shaping"
|
|||
|
>shaping</A
|
|||
|
> mechanism. Only a certain number of people can
|
|||
|
experience the ride in a particular period.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> To extend the analogy, imagine an empty line for the amusement park
|
|||
|
ride and a large number of carts sitting on the track ready to carry
|
|||
|
people. If a large number of people entered the line together many
|
|||
|
(maybe all) of them could experience the ride because of the carts
|
|||
|
available and waiting. The number of carts available is a concept
|
|||
|
analogous to the bucket. A bucket contains a number of tokens and can
|
|||
|
use all of the tokens in bucket without regard for passage of time.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> And to complete the analogy, the carts on the amusement park ride (our
|
|||
|
tokens) arrive at a fixed rate and are only kept available up to the
|
|||
|
size of the bucket. So, the bucket is filled with tokens according to
|
|||
|
the rate, and if the tokens are not used, the bucket can fill up. If
|
|||
|
tokens are used the bucket will not fill up. Buckets are a key concept
|
|||
|
in supporting bursty traffic such as HTTP.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The <A
|
|||
|
HREF="#qs-tbf"
|
|||
|
>TBF</A
|
|||
|
> qdisc is a classical example of a shaper (the section
|
|||
|
on TBF includes a diagram which may help to visualize the token
|
|||
|
and bucket concepts). The TBF generates <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
> tokens and
|
|||
|
only transmits packets when a token is available. Tokens are a generic
|
|||
|
shaping concept.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> In the case that a queue does not need tokens immediately, the tokens
|
|||
|
can be collected until they are needed. To collect tokens indefinitely
|
|||
|
would negate any benefit of shaping so tokens are collected until a
|
|||
|
certain number of tokens has been reached. Now, the queue has tokens
|
|||
|
available for a large number of packets or bytes which need to be
|
|||
|
dequeued. These intangible tokens are stored in an intangible bucket,
|
|||
|
and the number of tokens that can be stored depends on the size of the
|
|||
|
bucket.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> This also means that a bucket full of tokens may be available at any
|
|||
|
instant. Very predictable regular traffic can be handled by small
|
|||
|
buckets. Larger buckets may be required for burstier traffic, unless
|
|||
|
one of the desired goals is to reduce the burstiness of the
|
|||
|
<A
|
|||
|
HREF="#o-flows"
|
|||
|
>flows</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> In summary, tokens are generated at rate, and a maximum of a bucket's
|
|||
|
worth of tokens may be collected. This allows bursty traffic to be
|
|||
|
handled, while smoothing and shaping the transmitted traffic.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The concepts of tokens and buckets are closely interrelated and are used
|
|||
|
in both <A
|
|||
|
HREF="#qs-tbf"
|
|||
|
>TBF</A
|
|||
|
> (one of the <A
|
|||
|
HREF="#classless-qdiscs"
|
|||
|
>classless qdiscs</A
|
|||
|
>) and
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
> (one of the <A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>classful qdiscs</A
|
|||
|
>).
|
|||
|
Within the <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> language, the use of two- and three-color meters is
|
|||
|
indubitably a token and bucket concept.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="o-packets"
|
|||
|
></A
|
|||
|
>2.8. Packets and frames</H2
|
|||
|
><A
|
|||
|
NAME="o-frames"
|
|||
|
></A
|
|||
|
><P
|
|||
|
> The terms for data sent across network changes depending on the layer
|
|||
|
the user is examining. This document will rather impolitely (and
|
|||
|
incorrectly) gloss over the technical distinction between
|
|||
|
packets and frames although they are outlined here.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The word frame is typically used to describe a layer 2 (data link) unit
|
|||
|
of data to be forwarded to the next recipient. Ethernet interfaces, PPP
|
|||
|
interfaces, and T1 interfaces all name their layer 2 data unit a frame.
|
|||
|
The frame is actually the unit on which traffic control is performed.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> A packet, on the other hand, is a higher layer concept, representing
|
|||
|
layer 3 (network) units. The term packet is preferred in this
|
|||
|
documentation, although it is slightly inaccurate.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="elements"
|
|||
|
></A
|
|||
|
>3. Traditional Elements of Traffic Control</H1
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="e-shaping"
|
|||
|
></A
|
|||
|
>3.1. Shaping</H2
|
|||
|
><P
|
|||
|
> Shapers delay packets to meet a desired rate.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Shaping is the mechanism by which packets are delayed before
|
|||
|
transmission in an output queue to meet a desired output rate. This is
|
|||
|
one of the most common desires of users seeking bandwidth control
|
|||
|
solutions. The act of delaying a packet as part of a traffic control
|
|||
|
solution makes every shaping mechanism into a non-work-conserving
|
|||
|
mechanism, meaning roughly: "Work is required in order to delay
|
|||
|
packets."
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Viewed in reverse, a non-work-conserving queuing mechanism is performing
|
|||
|
a shaping function. A work-conserving queuing mechanism (see
|
|||
|
<A
|
|||
|
HREF="#qc-prio"
|
|||
|
>PRIO</A
|
|||
|
>) would not be capable of delaying a packet.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Shapers attempt to limit or ration traffic to meet but not exceed a
|
|||
|
configured rate (frequently measured in packets per second or bits/bytes
|
|||
|
per second). As a side effect, shapers can smooth out bursty traffic
|
|||
|
<A
|
|||
|
NAME="AEN271"
|
|||
|
HREF="#FTN.AEN271"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[4]</SPAN
|
|||
|
></A
|
|||
|
>.
|
|||
|
One of the advantages of shaping bandwidth is the ability to control
|
|||
|
latency of packets. The underlying mechanism for shaping to a rate is
|
|||
|
typically a token and bucket mechanism. See also
|
|||
|
<A
|
|||
|
HREF="#o-tokens"
|
|||
|
>Section 2.7</A
|
|||
|
> for further detail on tokens and buckets.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="e-scheduling"
|
|||
|
></A
|
|||
|
>3.2. Scheduling</H2
|
|||
|
><P
|
|||
|
> Schedulers arrange and/or rearrange packets for output.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Scheduling is the mechanism by which packets are arranged (or
|
|||
|
rearranged) between input and output of a particular queue. The
|
|||
|
overwhelmingly most common scheduler is the FIFO (first-in first-out)
|
|||
|
scheduler. From a larger perspective, any set of traffic control
|
|||
|
mechanisms on an output queue can be regarded as a scheduler, because
|
|||
|
packets are arranged for output.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Other generic scheduling mechanisms attempt to compensate for various
|
|||
|
networking conditions. A fair queuing algorithm (see <A
|
|||
|
HREF="#qs-sfq"
|
|||
|
>SFQ</A
|
|||
|
>)
|
|||
|
attempts to prevent any single client or flow from dominating the
|
|||
|
network usage. A round-robin algorithm (see WRR) gives each
|
|||
|
flow or client a turn to dequeue packets. Other sophisticated
|
|||
|
scheduling algorithms attempt to prevent backbone overload (see
|
|||
|
<A
|
|||
|
HREF="#qs-gred"
|
|||
|
>GRED</A
|
|||
|
>) or refine other scheduling mechanisms (see
|
|||
|
<A
|
|||
|
HREF="#qs-esfq"
|
|||
|
>ESFQ</A
|
|||
|
>).
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="e-classifying"
|
|||
|
></A
|
|||
|
>3.3. Classifying</H2
|
|||
|
><P
|
|||
|
> Classifiers sort or separate traffic into queues.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Classifying is the mechanism by which packets are separated for
|
|||
|
different treatment, possibly different output queues. During the
|
|||
|
process of accepting, routing and transmitting a packet, a networking
|
|||
|
device can classify the packet a number of different ways.
|
|||
|
Classification can include
|
|||
|
<A
|
|||
|
HREF="#e-marking"
|
|||
|
>marking</A
|
|||
|
> the packet, which usually
|
|||
|
happens on the boundary of a network under a single administrative
|
|||
|
control or classification can occur on each hop individually.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The Linux model (see
|
|||
|
<A
|
|||
|
HREF="#c-filter"
|
|||
|
>Section 4.3</A
|
|||
|
>) allows for a packet to cascade across a
|
|||
|
series of classifiers in a traffic control structure and to be
|
|||
|
classified in conjunction with
|
|||
|
<A
|
|||
|
HREF="#e-policing"
|
|||
|
>policers</A
|
|||
|
> (see also
|
|||
|
<A
|
|||
|
HREF="#c-police"
|
|||
|
>Section 4.5</A
|
|||
|
>).
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="e-policing"
|
|||
|
></A
|
|||
|
>3.4. Policing</H2
|
|||
|
><P
|
|||
|
> Policers measure and limit traffic in a particular queue.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Policing, as an element of traffic control, is simply
|
|||
|
a mechanism by which traffic can be limited. Policing is most
|
|||
|
frequently used on the network border to ensure that a peer is not
|
|||
|
consuming more than its allocated bandwidth. A policer will accept
|
|||
|
traffic to a certain rate, and then perform an action on traffic
|
|||
|
exceeding this rate. A rather harsh solution is to
|
|||
|
<A
|
|||
|
HREF="#e-dropping"
|
|||
|
>drop</A
|
|||
|
> the traffic, although the
|
|||
|
traffic could be
|
|||
|
<A
|
|||
|
HREF="#e-classifying"
|
|||
|
>reclassified</A
|
|||
|
> instead of being
|
|||
|
dropped.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> A policer is a yes/no question about the rate at which traffic is
|
|||
|
entering a queue. If the packet is about to enter a queue below a given
|
|||
|
rate, take one action (allow the enqueuing). If the packet is about to
|
|||
|
enter a queue above a given rate, take another action. Although the
|
|||
|
policer uses a token bucket mechanism internally, it does not have the
|
|||
|
capability to delay a packet as a <A
|
|||
|
HREF="#e-shaping"
|
|||
|
>shaping</A
|
|||
|
> mechanism does.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="e-dropping"
|
|||
|
></A
|
|||
|
>3.5. Dropping</H2
|
|||
|
><P
|
|||
|
> Dropping discards an entire packet, flow or classification.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Dropping a packet is a mechanism by which a packet is discarded.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="e-marking"
|
|||
|
></A
|
|||
|
>3.6. Marking</H2
|
|||
|
><P
|
|||
|
> Marking is a mechanism by which the packet is altered.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="note"
|
|||
|
><P
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
CLASS="note"
|
|||
|
WIDTH="100%"
|
|||
|
BORDER="0"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25"
|
|||
|
ALIGN="CENTER"
|
|||
|
VALIGN="TOP"
|
|||
|
><IMG
|
|||
|
SRC="../images/note.gif"
|
|||
|
HSPACE="5"
|
|||
|
ALT="Note"></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
>This is not <TT
|
|||
|
CLASS="constant"
|
|||
|
>fwmark</TT
|
|||
|
>. The <B
|
|||
|
CLASS="command"
|
|||
|
>iptables</B
|
|||
|
>target <TT
|
|||
|
CLASS="constant"
|
|||
|
>MARK</TT
|
|||
|
>and the
|
|||
|
<B
|
|||
|
CLASS="command"
|
|||
|
>ipchains</B
|
|||
|
><TT
|
|||
|
CLASS="option"
|
|||
|
>--mark</TT
|
|||
|
>are used to modify packet metadata, not the packet
|
|||
|
itself.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> Traffic control marking mechanisms install a DSCP on the packet
|
|||
|
itself, which is then used and respected by other routers inside an
|
|||
|
administrative domain (usually for DiffServ).
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="components"
|
|||
|
></A
|
|||
|
>4. Components of Linux Traffic Control</H1
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="table"
|
|||
|
><A
|
|||
|
NAME="tb-c-components-correlation"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Table 1. Correlation between traffic control elements and Linux
|
|||
|
components</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="1"
|
|||
|
CLASS="CALSTABLE"
|
|||
|
><THEAD
|
|||
|
><TR
|
|||
|
><TH
|
|||
|
WIDTH="25%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>traditional element</TH
|
|||
|
><TH
|
|||
|
WIDTH="75%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>Linux component</TH
|
|||
|
></TR
|
|||
|
></THEAD
|
|||
|
><TBODY
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><A
|
|||
|
HREF="#e-shaping"
|
|||
|
>shaping</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="75%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>The <A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
> offers shaping capabilities.</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><A
|
|||
|
HREF="#e-scheduling"
|
|||
|
>scheduling</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="75%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>A <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> is a scheduler. Schedulers
|
|||
|
can be simple such as the FIFO or
|
|||
|
complex, containing classes and other
|
|||
|
qdiscs, such as HTB.</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><A
|
|||
|
HREF="#e-classifying"
|
|||
|
>classifying</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="75%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>The <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> object performs the
|
|||
|
classification through the agency of a
|
|||
|
<A
|
|||
|
HREF="#c-classifier"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>classifier</TT
|
|||
|
></A
|
|||
|
> object. Strictly speaking,
|
|||
|
Linux classifiers cannot exist outside
|
|||
|
of a filter.</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><A
|
|||
|
HREF="#e-policing"
|
|||
|
>policing</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="75%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>A <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
> exists in the Linux traffic
|
|||
|
control implementation only as part of a
|
|||
|
<A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>.</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><A
|
|||
|
HREF="#e-dropping"
|
|||
|
>dropping</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="75%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>To <A
|
|||
|
HREF="#c-drop"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>drop</TT
|
|||
|
></A
|
|||
|
> traffic requires a
|
|||
|
<A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> with a <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
> which
|
|||
|
uses <SPAN
|
|||
|
CLASS="QUOTE"
|
|||
|
>"drop"</SPAN
|
|||
|
> as an action.</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><A
|
|||
|
HREF="#e-marking"
|
|||
|
>marking</A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
WIDTH="75%"
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>The <TT
|
|||
|
CLASS="constant"
|
|||
|
>dsmark</TT
|
|||
|
> <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> is used for
|
|||
|
marking.</TD
|
|||
|
></TR
|
|||
|
></TBODY
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="c-qdisc"
|
|||
|
></A
|
|||
|
>4.1. <TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> Simply put, a qdisc is a scheduler
|
|||
|
(<A
|
|||
|
HREF="#e-scheduling"
|
|||
|
>Section 3.2</A
|
|||
|
>). Every output interface needs a
|
|||
|
scheduler of some kind, and the default scheduler is a FIFO.
|
|||
|
Other qdiscs available under Linux will rearrange the packets entering
|
|||
|
the scheduler's queue in accordance with that scheduler's rules.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The qdisc is the major building block on which all of Linux traffic
|
|||
|
control is built, and is also called a queuing discipline.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The <A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>classful qdiscs</A
|
|||
|
> can contain <A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
>es, and provide a handle
|
|||
|
to which to attach <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>s. There is no prohibition on using a
|
|||
|
classful qdisc without child classes, although this will usually consume
|
|||
|
cycles and other system resources for no benefit.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The <A
|
|||
|
HREF="#classless-qdiscs"
|
|||
|
>classless qdiscs</A
|
|||
|
> can contain no classes, nor is it possible to
|
|||
|
attach filter to a classless qdisc. Because a classless qdisc contains
|
|||
|
no children of any kind, there is no utility to <A
|
|||
|
HREF="#e-classifying"
|
|||
|
>classifying</A
|
|||
|
>.
|
|||
|
This means that no filter can be attached to a classless qdisc.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> A source of terminology confusion is the usage of the terms
|
|||
|
<TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc and <TT
|
|||
|
CLASS="constant"
|
|||
|
>ingress</TT
|
|||
|
> qdisc. These are not
|
|||
|
really queuing disciplines, but rather locations onto which traffic
|
|||
|
control structures can be attached for egress (outbound traffic) and
|
|||
|
ingress (inbound traffic).
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Each interface contains both. The primary and more common is the
|
|||
|
egress qdisc, known as the <TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc. It can contain any
|
|||
|
of the queuing disciplines (<A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s) with potential
|
|||
|
<A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
>es and class structures. The overwhelming majority of
|
|||
|
documentation applies to the <TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc and its children. Traffic
|
|||
|
transmitted on an interface traverses the egress or <TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> For traffic accepted on an interface, the <TT
|
|||
|
CLASS="constant"
|
|||
|
>ingress</TT
|
|||
|
> qdisc is traversed.
|
|||
|
With its limited utility, it allows no child <A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
> to be
|
|||
|
created, and only exists as an object onto which a <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> can be
|
|||
|
attached. For practical purposes, the <TT
|
|||
|
CLASS="constant"
|
|||
|
>ingress</TT
|
|||
|
> qdisc is merely a
|
|||
|
convenient object onto which to attach a <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
> to limit the
|
|||
|
amount of traffic accepted on a network interface.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> In short, you can do much more with an egress qdisc because it contains
|
|||
|
a real qdisc and the full power of the traffic control system. An
|
|||
|
<TT
|
|||
|
CLASS="constant"
|
|||
|
>ingress</TT
|
|||
|
> qdisc can only support a policer. The remainder of the
|
|||
|
documentation will concern itself with traffic control structures
|
|||
|
attached to the <TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc unless otherwise specified.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="c-class"
|
|||
|
></A
|
|||
|
>4.2. <TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> Classes only exist inside a classful <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> (<I
|
|||
|
CLASS="foreignphrase"
|
|||
|
>e.g.</I
|
|||
|
>, <A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
>
|
|||
|
and <A
|
|||
|
HREF="#qc-cbq"
|
|||
|
>CBQ</A
|
|||
|
>). Classes are immensely flexible and can always
|
|||
|
contain either multiple children classes or a single child qdisc
|
|||
|
<A
|
|||
|
NAME="AEN422"
|
|||
|
HREF="#FTN.AEN422"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[5]</SPAN
|
|||
|
></A
|
|||
|
>.
|
|||
|
There is no prohibition against a class containing a classful qdisc
|
|||
|
itself, which facilitates tremendously complex traffic control
|
|||
|
scenarios.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Any class can also have an arbitrary number of <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>s attached
|
|||
|
to it, which allows the selection of a child class or the use of a
|
|||
|
filter to reclassify or drop traffic entering a particular class.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> A leaf class is a terminal class in a qdisc. It contains a qdisc
|
|||
|
(default <A
|
|||
|
HREF="#qs-fifo"
|
|||
|
>FIFO</A
|
|||
|
>) and will never contain a child class. Any
|
|||
|
class which contains a child class is an inner class (or root class) and
|
|||
|
not a leaf class.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="c-filter"
|
|||
|
></A
|
|||
|
>4.3. <TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> The filter is the most complex component in the Linux
|
|||
|
traffic control system. The filter provides a convenient mechanism for
|
|||
|
gluing together several of the key elements of traffic control. The
|
|||
|
simplest and most obvious role of the filter is to classify
|
|||
|
(see <A
|
|||
|
HREF="#e-classifying"
|
|||
|
>Section 3.3</A
|
|||
|
>) packets. Linux filters allow the
|
|||
|
user to classify packets into an output queue with either several
|
|||
|
different filters or a single filter.
|
|||
|
</P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><UL
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A filter must contain a <A
|
|||
|
HREF="#c-classifier"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>classifier</TT
|
|||
|
></A
|
|||
|
> phrase.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A filter may contain a <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
> phrase.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
></UL
|
|||
|
><P
|
|||
|
> Filters can be attached either to classful <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s or to
|
|||
|
<A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
>es, however the enqueued packet always enters the root
|
|||
|
qdisc first. After the filter attached to the root qdisc has been
|
|||
|
traversed, the packet may be directed to any subclasses (which can have
|
|||
|
their own filters) where the packet may undergo further classification.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="c-classifier"
|
|||
|
></A
|
|||
|
>4.4. classifier</H2
|
|||
|
><P
|
|||
|
> Filter objects, which can be manipulated using <A
|
|||
|
HREF="#s-iproute2-tc"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
></A
|
|||
|
>, can use several
|
|||
|
different classifying mechanisms, the most common of which is the
|
|||
|
<TT
|
|||
|
CLASS="constant"
|
|||
|
>u32</TT
|
|||
|
> classifier. The <TT
|
|||
|
CLASS="constant"
|
|||
|
>u32</TT
|
|||
|
> classifier allows the user to
|
|||
|
select packets based on attributes of the packet.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The classifiers are tools which can be used as part of a <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>
|
|||
|
to identify characteristics of a packet or a packet's metadata. The
|
|||
|
Linux classfier object is a direct analogue to the basic operation and
|
|||
|
elemental mechanism of traffic control <A
|
|||
|
HREF="#e-classifying"
|
|||
|
>classifying</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="c-police"
|
|||
|
></A
|
|||
|
>4.5. policer</H2
|
|||
|
><P
|
|||
|
> This elemental mechanism is only used in Linux traffic control as part
|
|||
|
of a <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>. A policer calls one action above and another
|
|||
|
action below the specified rate. Clever use of policers can simulate
|
|||
|
a three-color meter. See also
|
|||
|
<A
|
|||
|
HREF="#diagram"
|
|||
|
>Section 10</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Although both <A
|
|||
|
HREF="#e-policing"
|
|||
|
>policing</A
|
|||
|
> and <A
|
|||
|
HREF="#e-shaping"
|
|||
|
>shaping</A
|
|||
|
> are basic
|
|||
|
elements of traffic control for limiting bandwidth usage a policer will
|
|||
|
never delay traffic. It can only perform an action based on specified
|
|||
|
criteria. See also
|
|||
|
<A
|
|||
|
HREF="#ex-s-iproute2-tc-filter"
|
|||
|
>Example 5</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="c-drop"
|
|||
|
></A
|
|||
|
>4.6. <TT
|
|||
|
CLASS="constant"
|
|||
|
>drop</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> This basic traffic control mechanism is only used in Linux traffic
|
|||
|
control as part of a <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
>. Any policer attached to
|
|||
|
any <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> could have a <A
|
|||
|
HREF="#c-drop"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>drop</TT
|
|||
|
></A
|
|||
|
> action.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="note"
|
|||
|
><P
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
CLASS="note"
|
|||
|
WIDTH="100%"
|
|||
|
BORDER="0"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25"
|
|||
|
ALIGN="CENTER"
|
|||
|
VALIGN="TOP"
|
|||
|
><IMG
|
|||
|
SRC="../images/note.gif"
|
|||
|
HSPACE="5"
|
|||
|
ALT="Note"></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
>The only place in the Linux traffic control system where a packet can be
|
|||
|
explicitly dropped is a policer. A policer can limit packets enqueued
|
|||
|
at a specific rate, or it can be configured to drop all traffic matching
|
|||
|
a particular pattern
|
|||
|
<A
|
|||
|
NAME="AEN483"
|
|||
|
HREF="#FTN.AEN483"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[6]</SPAN
|
|||
|
></A
|
|||
|
>.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> There are, however, places within the traffic control system where a
|
|||
|
packet may be dropped as a side effect. For example, a packet will be
|
|||
|
dropped if the scheduler employed uses this method to control flows as
|
|||
|
the <A
|
|||
|
HREF="#qs-gred"
|
|||
|
>GRED</A
|
|||
|
> does.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Also, a shaper or scheduler which runs out of its allocated buffer space
|
|||
|
may have to drop a packet during a particularly bursty or overloaded
|
|||
|
period.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="c-handle"
|
|||
|
></A
|
|||
|
>4.7. <TT
|
|||
|
CLASS="constant"
|
|||
|
>handle</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> Every <A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
> and classful <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> (see also
|
|||
|
<A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>Section 7</A
|
|||
|
>) requires a unique identifier within
|
|||
|
the traffic control structure. This unique identifier is known as a
|
|||
|
handle and has two constituent members, a major number and a minor
|
|||
|
number. These numbers can be assigned arbitrarily by the user in
|
|||
|
accordance with the following rules
|
|||
|
<A
|
|||
|
NAME="AEN505"
|
|||
|
HREF="#FTN.AEN505"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[7]</SPAN
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><DIV
|
|||
|
CLASS="variablelist"
|
|||
|
><P
|
|||
|
><B
|
|||
|
>The numbering of handles for classes and qdiscs</B
|
|||
|
></P
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>major</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> This parameter is completely free of meaning to the kernel. The
|
|||
|
user may use an arbitrary numbering scheme, however all objects in
|
|||
|
the traffic control structure with the same parent must share a
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>major</I
|
|||
|
></TT
|
|||
|
> handle number. Conventional
|
|||
|
numbering schemes start at 1 for objects attached directly to the
|
|||
|
<TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>minor</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> This parameter unambiguously identifies the object as a qdisc if
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>minor</I
|
|||
|
></TT
|
|||
|
> is 0. Any other value identifies the
|
|||
|
object as a class. All classes sharing a parent must have unique
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>minor</I
|
|||
|
></TT
|
|||
|
> numbers.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
></DL
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> The special handle ffff:0 is reserved for the <TT
|
|||
|
CLASS="constant"
|
|||
|
>ingress</TT
|
|||
|
> qdisc.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The handle is used as the target in <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>classid</I
|
|||
|
></TT
|
|||
|
> and
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>flowid</I
|
|||
|
></TT
|
|||
|
> phrases of <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> statements.
|
|||
|
These handles are external identifiers for the objects, usable by
|
|||
|
userland applications. The kernel maintains internal identifiers for
|
|||
|
each object.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="software"
|
|||
|
></A
|
|||
|
>5. Software and Tools</H1
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="s-kernel"
|
|||
|
></A
|
|||
|
>5.1. Kernel requirements</H2
|
|||
|
><P
|
|||
|
> 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.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The user who has little or no experience compiling a kernel is
|
|||
|
recommended to <A
|
|||
|
HREF="http://tldp.org/HOWTO/Kernel-HOWTO/"
|
|||
|
TARGET="_top"
|
|||
|
>Kernel
|
|||
|
HOWTO</A
|
|||
|
>. 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.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-s-kernel-options"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 1. Kernel compilation options
|
|||
|
<A
|
|||
|
NAME="AEN542"
|
|||
|
HREF="#FTN.AEN542"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[8]</SPAN
|
|||
|
></A
|
|||
|
>
|
|||
|
</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> #
|
|||
|
# 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
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> 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 <B
|
|||
|
CLASS="command"
|
|||
|
>modprobe
|
|||
|
<TT
|
|||
|
CLASS="replaceable"
|
|||
|
><I
|
|||
|
>module</I
|
|||
|
></TT
|
|||
|
></B
|
|||
|
> before using a given
|
|||
|
feature. Again, the confused user is recommended to the
|
|||
|
<A
|
|||
|
HREF="http://tldp.org/HOWTO/Kernel-HOWTO/"
|
|||
|
TARGET="_top"
|
|||
|
>Kernel
|
|||
|
HOWTO</A
|
|||
|
>, as this document cannot adequately address questions
|
|||
|
about the use of the Linux kernel.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="s-iproute2"
|
|||
|
></A
|
|||
|
>5.2. <B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> tools (<B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
>)</H2
|
|||
|
><P
|
|||
|
> <B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> 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 <A
|
|||
|
HREF="http://linux-ip.net/gl/ip-cref/"
|
|||
|
TARGET="_top"
|
|||
|
>iproute2
|
|||
|
documentation</A
|
|||
|
> and for a more expository discussion, the
|
|||
|
documentation at <A
|
|||
|
HREF="http://linux-ip.net/"
|
|||
|
TARGET="_top"
|
|||
|
>linux-ip.net</A
|
|||
|
>. Of the tools in the <B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
>
|
|||
|
package, the binary <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> is the only one used for traffic control. This
|
|||
|
HOWTO will ignore the other tools in the suite.
|
|||
|
</P
|
|||
|
><A
|
|||
|
NAME="s-iproute2-tc"
|
|||
|
></A
|
|||
|
><P
|
|||
|
> Because it interacts with the kernel to direct the creation, deletion
|
|||
|
and modification of traffic control structures, the <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> binary needs to
|
|||
|
be compiled with support for all of the <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s you wish to use.
|
|||
|
In particular, the HTB qdisc is not supported yet in the upstream
|
|||
|
<B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> package. See
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>Section 7.1</A
|
|||
|
> for more information.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> 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, <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>, <A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
> or <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-s-iproute2-tc"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 2. <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> command usage</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> <TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
>Usage: tc [ OPTIONS ] OBJECT { COMMAND | help }
|
|||
|
where OBJECT := { qdisc | class | filter }
|
|||
|
OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] }</TT
|
|||
|
>
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> 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 <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> command line
|
|||
|
syntax. For more examples, consult the <A
|
|||
|
HREF="http://lartc.org/howto/"
|
|||
|
TARGET="_top"
|
|||
|
>LARTC HOWTO</A
|
|||
|
>. For even
|
|||
|
better understanding, consult the kernel and <B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> code.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-s-iproute2-tc-qdisc"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 3. <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
></B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> <TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tc qdisc add \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcq-tc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/1.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(1)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> dev eth0 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcq-dev"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/2.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(2)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> root \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcq-root"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/3.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(3)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> handle 1:0 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcq-handle"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/4.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(4)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> htb</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcq-qdisc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/5.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(5)"></A
|
|||
|
>
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
><DIV
|
|||
|
CLASS="calloutlist"
|
|||
|
><DL
|
|||
|
COMPACT="COMPACT"
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcq-tc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/1.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(1)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Add a queuing discipline. The verb could also be
|
|||
|
<TT
|
|||
|
CLASS="constant"
|
|||
|
>del</TT
|
|||
|
>.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcq-dev"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/2.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(2)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Specify the device onto which we are attaching the new queuing
|
|||
|
discipline.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcq-root"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/3.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(3)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> This means <SPAN
|
|||
|
CLASS="QUOTE"
|
|||
|
>"egress"</SPAN
|
|||
|
> to <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
>. The word
|
|||
|
<TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> must be used, however. Another
|
|||
|
qdisc with limited functionality, the <TT
|
|||
|
CLASS="constant"
|
|||
|
>ingress</TT
|
|||
|
> qdisc can be
|
|||
|
attached to the same device.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcq-handle"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/4.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(4)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> The <A
|
|||
|
HREF="#c-handle"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>handle</TT
|
|||
|
></A
|
|||
|
> is a user-specified number of the form
|
|||
|
<TT
|
|||
|
CLASS="replaceable"
|
|||
|
><I
|
|||
|
>major</I
|
|||
|
></TT
|
|||
|
>:<TT
|
|||
|
CLASS="replaceable"
|
|||
|
><I
|
|||
|
>minor</I
|
|||
|
></TT
|
|||
|
>.
|
|||
|
The minor number for any queueing discipline handle must always be
|
|||
|
zero (0). An acceptable shorthand for a <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> handle is
|
|||
|
the syntax "1:", where the minor number is assumed to be zero (0)
|
|||
|
if not specified.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcq-qdisc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/5.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(5)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> 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.
|
|||
|
</DD
|
|||
|
></DL
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> Above was the simplest use of the <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> utility for adding a queuing
|
|||
|
discipline to a device. Here's an example of the use of <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> to add a
|
|||
|
class to an existing parent class.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-s-iproute2-tc-class"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 4. <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> <A
|
|||
|
HREF="#c-class"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>class</TT
|
|||
|
></A
|
|||
|
></B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> <TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tc class add \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcc-tc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/1.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(1)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> dev eth0 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcc-dev"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/2.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(2)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> parent 1:1 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcc-parent"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/3.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(3)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> classid 1:6 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcc-classid"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/4.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(4)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> htb \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcc-classtype"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/5.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(5)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> rate 256kbit \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcc-htb-rate"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/6.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(6)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> ceil 512kbit</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcc-htb-ceil"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/7.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(7)"></A
|
|||
|
>
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
><DIV
|
|||
|
CLASS="calloutlist"
|
|||
|
><DL
|
|||
|
COMPACT="COMPACT"
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcc-tc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/1.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(1)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Add a class. The verb could also be <TT
|
|||
|
CLASS="constant"
|
|||
|
>del</TT
|
|||
|
>.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcc-dev"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/2.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(2)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Specify the device onto which we are attaching the new class.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcc-parent"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/3.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(3)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Specify the parent <A
|
|||
|
HREF="#c-handle"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>handle</TT
|
|||
|
></A
|
|||
|
> to which we are attaching the new class.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcc-classid"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/4.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(4)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> This is a unique <A
|
|||
|
HREF="#c-handle"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>handle</TT
|
|||
|
></A
|
|||
|
>
|
|||
|
(<TT
|
|||
|
CLASS="replaceable"
|
|||
|
><I
|
|||
|
>major</I
|
|||
|
></TT
|
|||
|
>:<TT
|
|||
|
CLASS="replaceable"
|
|||
|
><I
|
|||
|
>minor</I
|
|||
|
></TT
|
|||
|
>)
|
|||
|
identifying this class. The minor number must be any non-zero (0)
|
|||
|
number.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcc-classtype"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/5.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(5)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Both of the <A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>classful qdiscs</A
|
|||
|
> require that any children classes be
|
|||
|
classes of the same type as the parent. Thus an HTB qdisc
|
|||
|
will contain HTB classes.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcc-htb-rate"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/6.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(6)"></A
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcc-htb-ceil"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/7.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(7)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> This is a class specific parameter. Consult
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>Section 7.1</A
|
|||
|
> for more detail on these parameters.
|
|||
|
</DD
|
|||
|
></DL
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-s-iproute2-tc-filter"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 5. <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
></B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> <TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tc filter add \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-tc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/1.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(1)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> dev eth0 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-dev"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/2.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(2)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> parent 1:0 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-parent"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/3.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(3)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> protocol ip \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-protocol"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/4.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(4)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> prio 5 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-prio"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/5.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(5)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> u32 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-classifier"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/6.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(6)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> match ip port 22 0xffff \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-match-port"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/7.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(7)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> match ip tos 0x10 0xff \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-match-tos"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/8.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(8)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> flowid 1:6 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-flowid"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/9.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(9)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> police \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-police"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/10.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(10)"></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> rate 32000bps \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-prate"
|
|||
|
><B
|
|||
|
>(11)</B
|
|||
|
></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> burst 10240 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-burst"
|
|||
|
><B
|
|||
|
>(12)</B
|
|||
|
></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> mpu 0 \</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-mpu"
|
|||
|
><B
|
|||
|
>(13)</B
|
|||
|
></A
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>> </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
> action drop/continue</B
|
|||
|
></TT
|
|||
|
> <A
|
|||
|
NAME="ex-s-itcf-action"
|
|||
|
><B
|
|||
|
>(14)</B
|
|||
|
></A
|
|||
|
>
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
><DIV
|
|||
|
CLASS="calloutlist"
|
|||
|
><DL
|
|||
|
COMPACT="COMPACT"
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-tc"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/1.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(1)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Add a filter. The verb could also be <TT
|
|||
|
CLASS="constant"
|
|||
|
>del</TT
|
|||
|
>.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-dev"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/2.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(2)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Specify the device onto which we are attaching the new filter.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-parent"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/3.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(3)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> Specify the parent handle to which we are attaching the new
|
|||
|
filter.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-protocol"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/4.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(4)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> This parameter is required. It's use should be obvious, although
|
|||
|
I don't know more.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-prio"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/5.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(5)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> The <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>prio</I
|
|||
|
></TT
|
|||
|
> parameter allows a given filter to
|
|||
|
be preferred above another. The <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>pref</I
|
|||
|
></TT
|
|||
|
> is a
|
|||
|
synonym.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-classifier"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/6.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(6)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> This is a <A
|
|||
|
HREF="#c-classifier"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>classifier</TT
|
|||
|
></A
|
|||
|
>, and is a required phrase in every
|
|||
|
<B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> command.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-match-port"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/7.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(7)"></A
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-match-tos"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/8.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(8)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> 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.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-flowid"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/9.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(9)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> The <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>flowid</I
|
|||
|
></TT
|
|||
|
> specifies the <A
|
|||
|
HREF="#c-handle"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>handle</TT
|
|||
|
></A
|
|||
|
> of
|
|||
|
the target class (or qdisc) to which a matching filter should send
|
|||
|
its selected packets.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-police"
|
|||
|
><IMG
|
|||
|
SRC="../images/callouts/10.gif"
|
|||
|
HSPACE="0"
|
|||
|
VSPACE="0"
|
|||
|
BORDER="0"
|
|||
|
ALT="(10)"></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> This is the <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
>, and is an optional phrase in every
|
|||
|
<B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> command.
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-prate"
|
|||
|
><B
|
|||
|
>(11)</B
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> The policer will perform one action above this rate, and another
|
|||
|
action below (see
|
|||
|
<A
|
|||
|
HREF="#ex-s-itcf-action-text"
|
|||
|
>action parameter</A
|
|||
|
>).
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-burst"
|
|||
|
><B
|
|||
|
>(12)</B
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> The <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>burst</I
|
|||
|
></TT
|
|||
|
> is an exact analog to <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>burst</I
|
|||
|
></TT
|
|||
|
> in
|
|||
|
<A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
> (<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>burst</I
|
|||
|
></TT
|
|||
|
> is a <A
|
|||
|
HREF="#o-buckets"
|
|||
|
>buckets</A
|
|||
|
> concept).
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-mpu"
|
|||
|
><B
|
|||
|
>(13)</B
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> The minimum policed unit. To count all traffic, use an
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>mpu</I
|
|||
|
></TT
|
|||
|
> of zero (0).
|
|||
|
</DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
HREF="#ex-s-itcf-action"
|
|||
|
><B
|
|||
|
>(14)</B
|
|||
|
></A
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
> The <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>action</I
|
|||
|
></TT
|
|||
|
> indicates what should be done if
|
|||
|
the <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
> 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.
|
|||
|
</DD
|
|||
|
></DL
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> As evidenced above, the <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> 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,
|
|||
|
<A
|
|||
|
HREF="#s-tcng"
|
|||
|
>Section 5.3</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="s-tcng"
|
|||
|
></A
|
|||
|
>5.3. <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
>, Traffic Control Next Generation</H2
|
|||
|
><P
|
|||
|
> FIXME; sing the praises of tcng. See also <A
|
|||
|
HREF="http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/"
|
|||
|
TARGET="_top"
|
|||
|
> Traffic Control using tcng and HTB HOWTO</A
|
|||
|
> and
|
|||
|
<A
|
|||
|
HREF="http://linux-ip.net/gl/tcng/"
|
|||
|
TARGET="_top"
|
|||
|
>tcng
|
|||
|
documentation</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Traffic control next generation (hereafter, <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
>) provides all of the
|
|||
|
power of traffic control under Linux with twenty percent of the
|
|||
|
headache.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="s-imq"
|
|||
|
></A
|
|||
|
>5.4. IMQ, Intermediate Queuing device</H2
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> FIXME; must discuss IMQ. See also Patrick McHardy's website on
|
|||
|
<A
|
|||
|
HREF="http://trash.net/~kaber/imq/"
|
|||
|
TARGET="_top"
|
|||
|
>IMQ</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="classless-qdiscs"
|
|||
|
></A
|
|||
|
>6. Classless Queuing Disciplines (<A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s)</H1
|
|||
|
><P
|
|||
|
> Each of these queuing disciplines can be used as the primary qdisc on an
|
|||
|
interface, or can be used inside a leaf class of a <A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>classful qdiscs</A
|
|||
|
>.
|
|||
|
These are the fundamental schedulers used under Linux. Note that the
|
|||
|
default scheduler is the <A
|
|||
|
HREF="#qs-pfifo_fast"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qs-fifo"
|
|||
|
></A
|
|||
|
>6.1. FIFO, First-In First-Out (<TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo</TT
|
|||
|
> and <TT
|
|||
|
CLASS="constant"
|
|||
|
>bfifo</TT
|
|||
|
>)</H2
|
|||
|
><DIV
|
|||
|
CLASS="note"
|
|||
|
><P
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
CLASS="note"
|
|||
|
WIDTH="100%"
|
|||
|
BORDER="0"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
WIDTH="25"
|
|||
|
ALIGN="CENTER"
|
|||
|
VALIGN="TOP"
|
|||
|
><IMG
|
|||
|
SRC="../images/note.gif"
|
|||
|
HSPACE="5"
|
|||
|
ALT="Note"></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
>This is not the default qdisc on Linux interfaces. Be certain to see
|
|||
|
<A
|
|||
|
HREF="#qs-pfifo_fast"
|
|||
|
>Section 6.2</A
|
|||
|
> for the full details on the default
|
|||
|
(<TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
>) qdisc.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> The FIFO algorithm forms the basis for the default qdisc on all Linux
|
|||
|
network interfaces (<A
|
|||
|
HREF="#qs-pfifo_fast"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
></A
|
|||
|
>). It performs no shaping or
|
|||
|
rearranging of packets. It simply transmits packets as soon as it can
|
|||
|
after receiving and queuing them. This is also the qdisc used inside
|
|||
|
all newly created classes until another qdisc or a class replaces the
|
|||
|
FIFO.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="mediaobject"
|
|||
|
><P
|
|||
|
><IMG
|
|||
|
SRC="images/fifo-qdisc.png"></P
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> A real FIFO qdisc must, however, have a size limit (a buffer size) to
|
|||
|
prevent it from overflowing in case it is unable to dequeue packets as
|
|||
|
quickly as it receives them. Linux implements two basic FIFO
|
|||
|
<A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s, one based on bytes, and one on packets. Regardless of
|
|||
|
the type of FIFO used, the size of the queue is defined by the parameter
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>limit</I
|
|||
|
></TT
|
|||
|
>. For a <TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo</TT
|
|||
|
> the unit is understood
|
|||
|
to be packets and for a <TT
|
|||
|
CLASS="constant"
|
|||
|
>bfifo</TT
|
|||
|
> the unit is understood to be bytes.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-qs-fifo-limit"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 6. Specifying a <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>limit</I
|
|||
|
></TT
|
|||
|
> for a packet
|
|||
|
or byte FIFO</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> <TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>cat bfifo.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
>/*
|
|||
|
* make a FIFO on eth0 with 10kbyte queue size
|
|||
|
*
|
|||
|
*/
|
|||
|
|
|||
|
dev eth0 {
|
|||
|
egress {
|
|||
|
fifo (limit 10kB );
|
|||
|
}
|
|||
|
}</TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tcc < bfifo.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
># ================================ Device eth0 ================================
|
|||
|
|
|||
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|||
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 bfifo limit 10240</TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>cat pfifo.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
>/*
|
|||
|
* make a FIFO on eth0 with 30 packet queue size
|
|||
|
*
|
|||
|
*/
|
|||
|
|
|||
|
dev eth0 {
|
|||
|
egress {
|
|||
|
fifo (limit 30p );
|
|||
|
}
|
|||
|
}</TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tcc < pfifo.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
># ================================ Device eth0 ================================
|
|||
|
|
|||
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|||
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 pfifo limit 30</TT
|
|||
|
>
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qs-pfifo_fast"
|
|||
|
></A
|
|||
|
>6.2. <TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
>, the default Linux qdisc</H2
|
|||
|
><P
|
|||
|
> The <TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
> qdisc is the default qdisc for all interfaces under
|
|||
|
Linux. Based on a conventional <A
|
|||
|
HREF="#qs-fifo"
|
|||
|
>FIFO</A
|
|||
|
> qdisc, this qdisc also
|
|||
|
provides some prioritization. It provides three different bands
|
|||
|
(individual FIFOs) for separating traffic. The highest priority traffic
|
|||
|
(interactive flows) are placed into band 0 and are always serviced
|
|||
|
first. Similarly, band 1 is always emptied of pending packets before
|
|||
|
band 2 is dequeued.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="mediaobject"
|
|||
|
><P
|
|||
|
><IMG
|
|||
|
SRC="images/pfifo_fast-qdisc.png"></P
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> There is nothing configurable to the end user about the <TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
>
|
|||
|
qdisc. For exact details on the <TT
|
|||
|
CLASS="constant"
|
|||
|
>priomap</TT
|
|||
|
> and use of
|
|||
|
the ToS bits, see the <A
|
|||
|
HREF="http://lartc.org/howto/lartc.qdisc.classless.html"
|
|||
|
TARGET="_top"
|
|||
|
>pfifo-fast
|
|||
|
section of the LARTC HOWTO</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qs-sfq"
|
|||
|
></A
|
|||
|
>6.3. SFQ, Stochastic Fair Queuing</H2
|
|||
|
><P
|
|||
|
> The SFQ qdisc attempts to fairly distribute opportunity to
|
|||
|
transmit data to the network among an arbitrary number of
|
|||
|
<A
|
|||
|
HREF="#o-flows"
|
|||
|
>flows</A
|
|||
|
>. It accomplishes this by using a hash function to
|
|||
|
separate the traffic into separate (internally maintained) FIFOs
|
|||
|
which are dequeued in a round-robin fashion. Because there is the
|
|||
|
possibility for unfairness to manifest in the choice of hash function,
|
|||
|
this function is altered periodically. Perturbation (the parameter
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>perturb</I
|
|||
|
></TT
|
|||
|
>) sets this periodicity.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="mediaobject"
|
|||
|
><P
|
|||
|
><IMG
|
|||
|
SRC="images/sfq-qdisc.png"></P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-qs-sfq"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 7. Creating an SFQ</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> <TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>cat sfq.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
>/*
|
|||
|
* make an SFQ on eth0 with a 10 second perturbation
|
|||
|
*
|
|||
|
*/
|
|||
|
|
|||
|
dev eth0 {
|
|||
|
egress {
|
|||
|
sfq( perturb 10s );
|
|||
|
}
|
|||
|
}</TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tcc < sfq.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
># ================================ Device eth0 ================================
|
|||
|
|
|||
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|||
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 sfq perturb 10</TT
|
|||
|
>
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> Unfortunately, some clever software (<I
|
|||
|
CLASS="foreignphrase"
|
|||
|
>e.g.</I
|
|||
|
> Kazaa and eMule among others)
|
|||
|
obliterate the benefit of this attempt at fair queuing by opening as
|
|||
|
many TCP sessions (<A
|
|||
|
HREF="#o-flows"
|
|||
|
>flows</A
|
|||
|
>) as can be sustained. In many
|
|||
|
networks, with well-behaved users, SFQ can adequately distribute
|
|||
|
the network resources to the contending flows, but other measures may be
|
|||
|
called for when obnoxious applications have invaded the network.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> See also
|
|||
|
<A
|
|||
|
HREF="#qs-esfq"
|
|||
|
>Section 6.4</A
|
|||
|
> for an SFQ qdisc with more exposed
|
|||
|
parameters for the user to manipulate.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qs-esfq"
|
|||
|
></A
|
|||
|
>6.4. ESFQ, Extended Stochastic Fair Queuing</H2
|
|||
|
><P
|
|||
|
> Conceptually, this qdisc is no different than SFQ although it
|
|||
|
allows the user to control more parameters than its simpler cousin.
|
|||
|
This qdisc was conceived to overcome the shortcoming of SFQ
|
|||
|
identified above. By allowing the user to control which hashing
|
|||
|
algorithm is used for distributing access to network bandwidth, it
|
|||
|
is possible for the user to reach a fairer real distribution of
|
|||
|
bandwidth.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-qs-esfq-usage"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 8. ESFQ usage</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]
|
|||
|
[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]
|
|||
|
|
|||
|
Where:
|
|||
|
HASHTYPE := { classic | src | dst }
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> FIXME; need practical experience and/or attestation here.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qs-gred"
|
|||
|
></A
|
|||
|
>6.5. GRED, Generic Random Early Drop</H2
|
|||
|
><P
|
|||
|
> FIXME; I have never used this. Need practical experience or
|
|||
|
attestation.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Theory declares that a RED algorithm is useful on a backbone or core
|
|||
|
network, but not as useful near the end-user. See the section on
|
|||
|
<A
|
|||
|
HREF="#o-flows"
|
|||
|
>flows</A
|
|||
|
> to see a general discussion of the thirstiness of TCP.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qs-tbf"
|
|||
|
></A
|
|||
|
>6.6. TBF, Token Bucket Filter</H2
|
|||
|
><P
|
|||
|
> This qdisc is built on <A
|
|||
|
HREF="#o-tokens"
|
|||
|
>tokens</A
|
|||
|
> and <A
|
|||
|
HREF="#o-buckets"
|
|||
|
>buckets</A
|
|||
|
>. It
|
|||
|
simply shapes traffic transmitted on an interface. To limit the speed
|
|||
|
at which packets will be dequeued from a particular interface, the
|
|||
|
TBF qdisc is the perfect solution. It simply slows down
|
|||
|
transmitted traffic to the specified rate.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Packets are only transmitted if there are sufficient tokens available.
|
|||
|
Otherwise, packets are deferred. Delaying packets in this fashion will
|
|||
|
introduce an artificial latency into the packet's round trip time.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="mediaobject"
|
|||
|
><P
|
|||
|
><IMG
|
|||
|
SRC="images/tbf-qdisc.png"></P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-qs-tbf"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 9. Creating a 256kbit/s TBF</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> <TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>cat tbf.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
>/*
|
|||
|
* make a 256kbit/s TBF on eth0
|
|||
|
*
|
|||
|
*/
|
|||
|
|
|||
|
dev eth0 {
|
|||
|
egress {
|
|||
|
tbf( rate 256 kbps, burst 20 kB, limit 20 kB, mtu 1514 B );
|
|||
|
}
|
|||
|
}</TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="prompt"
|
|||
|
>[root@leander]# </TT
|
|||
|
><TT
|
|||
|
CLASS="userinput"
|
|||
|
><B
|
|||
|
>tcc < tbf.tcc</B
|
|||
|
></TT
|
|||
|
>
|
|||
|
<TT
|
|||
|
CLASS="computeroutput"
|
|||
|
># ================================ Device eth0 ================================
|
|||
|
|
|||
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|||
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 32000bps</TT
|
|||
|
>
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="classful-qdiscs"
|
|||
|
></A
|
|||
|
>7. Classful Queuing Disciplines (<A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>s)</H1
|
|||
|
><P
|
|||
|
> The flexibility and control of Linux traffic control can be unleashed
|
|||
|
through the agency of the classful qdiscs. Remember that the classful
|
|||
|
queuing disciplines can have filters attached to them, allowing packets to
|
|||
|
be directed to particular classes and subqueues.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> There are several common terms to describe classes directly attached to
|
|||
|
the <TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc and terminal classes. Classess attached to the
|
|||
|
<TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc are known as root classes, and more generically inner
|
|||
|
classes. Any terminal class in a particular queuing discipline is known
|
|||
|
as a leaf class by analogy to the tree structure of the classes. Besides
|
|||
|
the use of figurative language depicting the structure as a tree, the
|
|||
|
language of family relationships is also quite common.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-htb"
|
|||
|
></A
|
|||
|
>7.1. HTB, Hierarchical Token Bucket</H2
|
|||
|
><P
|
|||
|
> HTB uses the concepts of tokens and buckets
|
|||
|
along with the class-based system and <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
>s to allow for
|
|||
|
complex and granular control over traffic. With a complex
|
|||
|
<A
|
|||
|
HREF="#qc-htb-borrowing"
|
|||
|
>borrowing model</A
|
|||
|
>, HTB can perform a variety of sophisticated
|
|||
|
traffic control techniques. One of the easiest ways to use HTB
|
|||
|
immediately is that of <A
|
|||
|
HREF="#qc-htb-borrowing"
|
|||
|
>shaping</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> By understanding <A
|
|||
|
HREF="#o-tokens"
|
|||
|
>tokens</A
|
|||
|
> and <A
|
|||
|
HREF="#o-buckets"
|
|||
|
>buckets</A
|
|||
|
> or by grasping
|
|||
|
the function of <A
|
|||
|
HREF="#qs-tbf"
|
|||
|
>TBF</A
|
|||
|
>, HTB should be merely a logical
|
|||
|
step. This queuing discipline allows the user to define the
|
|||
|
characteristics of the tokens and bucket used and allows the user to
|
|||
|
nest these buckets in an arbitrary fashion. When coupled with a
|
|||
|
<A
|
|||
|
HREF="#e-classifying"
|
|||
|
>classifying</A
|
|||
|
> scheme, traffic can be controlled in a very
|
|||
|
granular fashion.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> Below is example output of the syntax for HTB on the command line
|
|||
|
with the <A
|
|||
|
HREF="#s-iproute2-tc"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
></A
|
|||
|
> tool. Although the syntax for <A
|
|||
|
HREF="#s-tcng"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
></A
|
|||
|
> is a
|
|||
|
language of its own, the rules for HTB are the same.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="ex-qc-htb-usage"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 10. <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> usage for HTB</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> Usage: ... qdisc add ... htb [default N] [r2q N]
|
|||
|
default minor id of class to which unclassified packets are sent {0}
|
|||
|
r2q DRR quantums are computed as rate in Bps/r2q {10}
|
|||
|
debug string of 16 numbers each 0-3 {0}
|
|||
|
|
|||
|
... class add ... htb rate R1 burst B1 [prio P] [slot S] [pslot PS]
|
|||
|
[ceil R2] [cburst B2] [mtu MTU] [quantum Q]
|
|||
|
rate rate allocated to this class (class can still borrow)
|
|||
|
burst max bytes burst which can be accumulated during idle period {computed}
|
|||
|
ceil definite upper class rate (no borrows) {rate}
|
|||
|
cburst burst but for ceil {computed}
|
|||
|
mtu max packet size we create rate map for {1600}
|
|||
|
prio priority of leaf; lower are served first {0}
|
|||
|
quantum how much bytes to serve from leaf at once {use r2q}
|
|||
|
|
|||
|
TC HTB version 3.3
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H3
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-htb-software"
|
|||
|
></A
|
|||
|
>7.1.1. Software requirements</H3
|
|||
|
><P
|
|||
|
> Unlike almost all of the other software discussed, HTB is a
|
|||
|
newer queuing discipline and your distribution may not have all of the
|
|||
|
tools and capability you need to use HTB. The kernel must
|
|||
|
support HTB; kernel version 2.4.20 and later support it in the
|
|||
|
stock distribution, although earlier kernel versions require patching.
|
|||
|
To enable userland support for HTB, see <A
|
|||
|
HREF="http://luxik.cdi.cz/~devik/qos/htb/"
|
|||
|
TARGET="_top"
|
|||
|
>HTB</A
|
|||
|
> for an
|
|||
|
<B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> patch to <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H3
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-htb-shaping"
|
|||
|
></A
|
|||
|
>7.1.2. Shaping</H3
|
|||
|
><P
|
|||
|
> One of the most common applications of HTB involves shaping
|
|||
|
transmitted traffic to a specific rate.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> All shaping occurs in leaf classes. No shaping occurs in inner or
|
|||
|
root classes as they only exist to suggest how the
|
|||
|
<A
|
|||
|
HREF="#qc-htb-borrowing"
|
|||
|
>borrowing model</A
|
|||
|
> should distribute available tokens.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H3
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-htb-borrowing"
|
|||
|
></A
|
|||
|
>7.1.3. Borrowing</H3
|
|||
|
><P
|
|||
|
> A fundamental part of the HTB qdisc is the borrowing mechanism.
|
|||
|
Children classes borrow tokens from their parents once they have
|
|||
|
exceeded <A
|
|||
|
HREF="#vl-qc-htb-params-rate"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
></A
|
|||
|
>. A child class will continue to
|
|||
|
attempt to borrow until it reaches <A
|
|||
|
HREF="#vl-qc-htb-params-ceil"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></A
|
|||
|
>, at which
|
|||
|
point it will begin to queue packets for transmission until more
|
|||
|
tokens/ctokens are available. As there are only two primary types of
|
|||
|
classes which can be created with HTB the following table and
|
|||
|
diagram identify the various possible states and the behaviour of the
|
|||
|
borrowing mechanisms.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="table"
|
|||
|
><A
|
|||
|
NAME="tb-qc-htb-borrowing"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Table 2. HTB class states and potential actions taken</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="1"
|
|||
|
CLASS="CALSTABLE"
|
|||
|
><THEAD
|
|||
|
><TR
|
|||
|
><TH
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>type of class</TH
|
|||
|
><TH
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>class state</TH
|
|||
|
><TH
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>HTB internal state</TH
|
|||
|
><TH
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>action taken</TH
|
|||
|
></TR
|
|||
|
></THEAD
|
|||
|
><TBODY
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>leaf</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>< <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>HTB_CAN_SEND</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
> Leaf class will dequeue queued bytes up
|
|||
|
to available tokens (no more than burst packets)
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>leaf</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>> <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
>, < <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>HTB_MAY_BORROW</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
> Leaf class will attempt to borrow tokens/ctokens from
|
|||
|
parent class. If tokens are available, they will be lent in
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
> increments and the leaf class will dequeue up
|
|||
|
to <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>cburst</I
|
|||
|
></TT
|
|||
|
> bytes
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>leaf</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>> <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>HTB_CANT_SEND</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
> No packets will be dequeued. This will cause packet
|
|||
|
delay and will increase latency to meet the desired
|
|||
|
rate.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>inner, root</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>< <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>HTB_CAN_SEND</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
> Inner class will lend tokens to children.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>inner, root</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>> <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
>, < <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>HTB_MAY_BORROW</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
> Inner class will attempt to borrow tokens/ctokens from
|
|||
|
parent class, lending them to competing children in
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
> increments per request.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>inner, root</TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
>> <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>HTB_CANT_SEND</I
|
|||
|
></TT
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="MIDDLE"
|
|||
|
> Inner class will not attempt to borrow from its parent
|
|||
|
and will not lend tokens/ctokens to children classes.
|
|||
|
</TD
|
|||
|
></TR
|
|||
|
></TBODY
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> This diagram identifies the flow of borrowed tokens and the manner in
|
|||
|
which tokens are charged to parent classes. In order for the
|
|||
|
borrowing model to work, each class must have an accurate count of the
|
|||
|
number of tokens used by itself and all of its children. For this
|
|||
|
reason, any token used in a child or leaf class is charged to each
|
|||
|
parent class until the root class is reached.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Any child class which wishes to borrow a token will request a token
|
|||
|
from its parent class, which if it is also over its <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
> will
|
|||
|
request to borrow from its parent class until either a token is
|
|||
|
located or the root class is reached. So the borrowing of tokens
|
|||
|
flows toward the leaf classes and the charging of the usage of tokens
|
|||
|
flows toward the root class.
|
|||
|
</P
|
|||
|
><DIV
|
|||
|
CLASS="mediaobject"
|
|||
|
><P
|
|||
|
><IMG
|
|||
|
SRC="images/htb-borrow.png"></P
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> Note in this diagram that there are several HTB root classes.
|
|||
|
Each of these root classes can simulate a virtual circuit.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H3
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-htb-params"
|
|||
|
></A
|
|||
|
>7.1.4. HTB class parameters</H3
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><DIV
|
|||
|
CLASS="variablelist"
|
|||
|
><DL
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-default"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>default</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> An optional parameter with every HTB <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> object,
|
|||
|
the default <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>default</I
|
|||
|
></TT
|
|||
|
> is 0, which cause any unclassified
|
|||
|
traffic to be dequeued at hardware speed, completely bypassing
|
|||
|
any of the classes attached to the <TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-rate"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> Used to set the minimum desired speed to which to limit
|
|||
|
transmitted traffic. This can be considered the equivalent of a
|
|||
|
committed information rate (<SPAN
|
|||
|
CLASS="acronym"
|
|||
|
>CIR</SPAN
|
|||
|
>), or the
|
|||
|
guaranteed bandwidth for a given leaf class.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-ceil"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> Used to set the maximum desired speed to which to limit the
|
|||
|
transmitted traffic. The borrowing model should illustrate how
|
|||
|
this parameter is used. This can be considered the equivalent
|
|||
|
of <SPAN
|
|||
|
CLASS="QUOTE"
|
|||
|
>"burstable bandwidth"</SPAN
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-burst"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>burst</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> This is the size of the <A
|
|||
|
HREF="#vl-qc-htb-params-rate"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
></A
|
|||
|
> bucket (see
|
|||
|
<A
|
|||
|
HREF="#o-buckets"
|
|||
|
>Tokens and buckets</A
|
|||
|
>). HTB will dequeue
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>burst</I
|
|||
|
></TT
|
|||
|
> bytes before awaiting the arrival of more
|
|||
|
tokens.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-cburst"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>cburst</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> This is the size of the <A
|
|||
|
HREF="#vl-qc-htb-params-ceil"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></A
|
|||
|
> bucket (see
|
|||
|
<A
|
|||
|
HREF="#o-buckets"
|
|||
|
>Tokens and buckets</A
|
|||
|
>). HTB will dequeue
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>cburst</I
|
|||
|
></TT
|
|||
|
> bytes before awaiting the arrival of more
|
|||
|
ctokens.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-quantum"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> This is a key parameter used by HTB to control borrowing.
|
|||
|
Normally, the correct <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
> is calculated by
|
|||
|
HTB, not specified by the user. Tweaking this parameter
|
|||
|
can have tremendous effects on borrowing and shaping under
|
|||
|
contention, because it is used both to split traffic between
|
|||
|
children classes over <A
|
|||
|
HREF="#vl-qc-htb-params-rate"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
></A
|
|||
|
> (but below
|
|||
|
<A
|
|||
|
HREF="#vl-qc-htb-params-ceil"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
></A
|
|||
|
>) and to transmit packets from these same
|
|||
|
classes.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-r2q"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>r2q</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> Also, usually calculated for the user, <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>r2q</I
|
|||
|
></TT
|
|||
|
> is a hint to
|
|||
|
HTB to help determine the optimal <A
|
|||
|
HREF="#vl-qc-htb-params-quantum"
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
></A
|
|||
|
>
|
|||
|
for a particular class.
|
|||
|
</P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-mtu"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>mtu</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DD
|
|||
|
><DT
|
|||
|
><A
|
|||
|
NAME="vl-qc-htb-params-prio"
|
|||
|
></A
|
|||
|
><TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>prio</I
|
|||
|
></TT
|
|||
|
></DT
|
|||
|
><DD
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DD
|
|||
|
></DL
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H3
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-htb-rules"
|
|||
|
></A
|
|||
|
>7.1.5. Rules</H3
|
|||
|
><P
|
|||
|
> Below are some general guidelines to using HTB culled from
|
|||
|
<A
|
|||
|
HREF="http://docum.org/"
|
|||
|
TARGET="_top"
|
|||
|
>http://docum.org/</A
|
|||
|
> and the <A
|
|||
|
HREF="http://mailman.ds9a.nl/mailman/listinfo/lartc/"
|
|||
|
TARGET="_top"
|
|||
|
>LARTC
|
|||
|
mailing list</A
|
|||
|
>. These rules are
|
|||
|
simply a recommendation for beginners to maximize the benefit of
|
|||
|
HTB until gaining a better understanding of the practical
|
|||
|
application of HTB.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><UL
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Shaping with HTB occurs only in leaf classes. See also
|
|||
|
<A
|
|||
|
HREF="#qc-htb-shaping"
|
|||
|
>Section 7.1.2</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Because HTB does not shape in any class except the leaf
|
|||
|
class, the sum of the <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
>s of leaf classes should not
|
|||
|
exceed the <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
> of a parent class. Ideally, the sum of
|
|||
|
the <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
>s of the children classes would match the
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
> of the parent class, allowing the parent class to
|
|||
|
distribute leftover bandwidth (<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
> - <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
>) among
|
|||
|
the children classes.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> This key concept in employing HTB bears repeating. Only
|
|||
|
leaf classes actually shape packets; packets are only delayed in
|
|||
|
these leaf classes. The inner classes (all the way up to the root
|
|||
|
class) exist to define how borrowing/lending occurs (see also
|
|||
|
<A
|
|||
|
HREF="#qc-htb-borrowing"
|
|||
|
>Section 7.1.3</A
|
|||
|
>).
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> The <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
> is only only used when a class is over
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>rate</I
|
|||
|
></TT
|
|||
|
> but below <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>ceil</I
|
|||
|
></TT
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> The <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
> should be set at MTU or higher. HTB
|
|||
|
will dequeue a single packet at least per service opportunity even
|
|||
|
if <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
> is too small. In such a case, it will not be
|
|||
|
able to calculate accurately the real bandwidth consumed
|
|||
|
<A
|
|||
|
NAME="AEN1146"
|
|||
|
HREF="#FTN.AEN1146"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[9]</SPAN
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Parent classes lend tokens to children in increments of
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
>, so for maximum granularity and most
|
|||
|
instantaneously evenly distributed bandwidth, <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
>
|
|||
|
should be as low as possible while still no less than MTU.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A distinction between tokens and ctokens is only meaningful in a
|
|||
|
leaf class, because non-leaf classes only lend tokens to child
|
|||
|
classes.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> HTB borrowing could more accurately be described as
|
|||
|
<SPAN
|
|||
|
CLASS="QUOTE"
|
|||
|
>"using"</SPAN
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
></UL
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-hfsc"
|
|||
|
></A
|
|||
|
>7.2. HFSC, Hierarchical Fair Service Curve</H2
|
|||
|
><P
|
|||
|
> The HFSC classful qdisc balances delay-sensitive traffic against
|
|||
|
throughput sensitive traffic. In a congested or backlogged state, the
|
|||
|
HFSC queuing discipline interleaves the delay-sensitive traffic when
|
|||
|
required according service curve definitions. Read about the Linux
|
|||
|
implementation in German, <A
|
|||
|
HREF="http://klaus.geekserver.net/hfsc/hfsc.html"
|
|||
|
TARGET="_top"
|
|||
|
>HFSC
|
|||
|
Scheduling mit Linux</A
|
|||
|
> or read a
|
|||
|
translation into English, <A
|
|||
|
HREF="http://linux-ip.net/tc/hfsc.en/"
|
|||
|
TARGET="_top"
|
|||
|
>HFSC Scheduling
|
|||
|
with Linux</A
|
|||
|
>. The original
|
|||
|
research article, <A
|
|||
|
HREF="http://acm.org/sigcomm/sigcomm97/program.html#ab011"
|
|||
|
TARGET="_top"
|
|||
|
>A
|
|||
|
Hierarchical Fair Service Curve Algorithm For Link-Sharing, Real-Time
|
|||
|
and Priority Services</A
|
|||
|
>, also remains available.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> This section will be completed at a later date.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-prio"
|
|||
|
></A
|
|||
|
>7.3. PRIO, priority scheduler</H2
|
|||
|
><P
|
|||
|
> The PRIO classful qdisc works on a very simple precept. When it
|
|||
|
is ready to dequeue a packet, the first class is checked for a packet.
|
|||
|
If there's a packet, it gets dequeued. If there's no packet, then the
|
|||
|
next class is checked, until the queuing mechanism has no more classes
|
|||
|
to check.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> This section will be completed at a later date.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="qc-cbq"
|
|||
|
></A
|
|||
|
>7.4. CBQ, Class Based Queuing</H2
|
|||
|
><P
|
|||
|
> CBQ is the classic implementation (also called venerable) of a traffic
|
|||
|
control system. This section will be completed at a later date.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="rules"
|
|||
|
></A
|
|||
|
>8. Rules, Guidelines and Approaches</H1
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="r-general"
|
|||
|
></A
|
|||
|
>8.1. General Rules of Linux Traffic Control</H2
|
|||
|
><P
|
|||
|
> There are a few general rules which ease the study of Linux traffic
|
|||
|
control.
|
|||
|
Traffic control structures under Linux are the same whether the initial
|
|||
|
configuration has been done with <A
|
|||
|
HREF="#s-tcng"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
></A
|
|||
|
> or with <A
|
|||
|
HREF="#s-iproute2-tc"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><UL
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Any router performing a shaping function should be the bottleneck on
|
|||
|
the link, and should be shaping slightly below the maximum available
|
|||
|
link bandwidth. This prevents queues from forming in other routers,
|
|||
|
affording maximum control of packet latency/deferral to the shaping
|
|||
|
device.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A device can only shape traffic it transmits
|
|||
|
<A
|
|||
|
NAME="AEN1189"
|
|||
|
HREF="#FTN.AEN1189"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[10]</SPAN
|
|||
|
></A
|
|||
|
>. Because the traffic has already been received on an
|
|||
|
input interface, the traffic cannot be shaped. A traditional
|
|||
|
solution to this problem is an ingress policer.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Every interface must have a <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
>. The default qdisc
|
|||
|
(the <A
|
|||
|
HREF="#qs-pfifo_fast"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>pfifo_fast</TT
|
|||
|
></A
|
|||
|
> qdisc) is used when another qdisc is not
|
|||
|
explicitly attached to the interface.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> One of the <A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>classful qdiscs</A
|
|||
|
> added to an interface with no children
|
|||
|
classes typically only consumes CPU for no benefit.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Any newly created class contains a <A
|
|||
|
HREF="#qs-fifo"
|
|||
|
>FIFO</A
|
|||
|
>.
|
|||
|
This qdisc can be replaced explicitly with any other qdisc. The
|
|||
|
FIFO qdisc will be removed implicitly if a child class is
|
|||
|
attached to this class.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> Classes directly attached to the <TT
|
|||
|
CLASS="constant"
|
|||
|
>root</TT
|
|||
|
> qdisc can be used to
|
|||
|
simulate virtual circuits.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> A <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> can be attached to classes or one of the
|
|||
|
<A
|
|||
|
HREF="#classful-qdiscs"
|
|||
|
>classful qdiscs</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
></UL
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="r-known-bandwidth"
|
|||
|
></A
|
|||
|
>8.2. Handling a link with a known bandwidth</H2
|
|||
|
><P
|
|||
|
> HTB is an ideal <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> to use on a link with a known
|
|||
|
bandwidth, because the innermost (root-most) class can be set to the
|
|||
|
maximum bandwidth available on a given link. Flows can be further
|
|||
|
subdivided into children classes, allowing either guaranteed bandwidth
|
|||
|
to particular classes of traffic or allowing preference to specific
|
|||
|
kinds of traffic.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="r-unknown-bandwidth"
|
|||
|
></A
|
|||
|
>8.3. Handling a link with a variable (or unknown) bandwidth</H2
|
|||
|
><P
|
|||
|
> In theory, the PRIO scheduler is an ideal match for links with
|
|||
|
variable bandwidth, because it is a work-conserving <A
|
|||
|
HREF="#c-qdisc"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>qdisc</TT
|
|||
|
></A
|
|||
|
> (which
|
|||
|
means that it provides no <A
|
|||
|
HREF="#e-shaping"
|
|||
|
>shaping</A
|
|||
|
>). In the case of a link
|
|||
|
with an unknown or fluctuating bandwidth, the PRIO scheduler
|
|||
|
simply prefers to dequeue any available packet in the highest priority
|
|||
|
band first, then falling to the lower priority queues.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="r-sharing-flows"
|
|||
|
></A
|
|||
|
>8.4. Sharing/splitting bandwidth based on flows</H2
|
|||
|
><P
|
|||
|
> Of the many types of contention for network bandwidth, this is one of
|
|||
|
the easier types of contention to address in general. By using the
|
|||
|
SFQ qdisc, traffic in a particular queue can be separated into
|
|||
|
flows, each of which will be serviced fairly (inside that queue).
|
|||
|
Well-behaved applications (and users) will find that using SFQ and
|
|||
|
ESFQ are sufficient for most sharing needs.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The Achilles heel of these fair queuing algorithms is a misbehaving user
|
|||
|
or application which opens many connections simultaneously (e.g., eMule,
|
|||
|
eDonkey, Kazaa). By creating a large number of individual flows, the
|
|||
|
application can dominate slots in the fair queuing algorithm. Restated,
|
|||
|
the fair queuing algorithm has no idea that a single application is
|
|||
|
generating the majority of the flows, and cannot penalize the user.
|
|||
|
Other methods are called for.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="r-sharing-ips"
|
|||
|
></A
|
|||
|
>8.5. Sharing/splitting bandwidth based on IP</H2
|
|||
|
><P
|
|||
|
> For many administrators this is the ideal method of dividing bandwidth
|
|||
|
amongst their users. Unfortunately, there is no easy solution, and it
|
|||
|
becomes increasingly complex with the number of machine sharing a
|
|||
|
network link.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> To divide bandwidth equitably between <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>N</I
|
|||
|
></TT
|
|||
|
> IP
|
|||
|
addresses, there must be <TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>N</I
|
|||
|
></TT
|
|||
|
> classes.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="scripts"
|
|||
|
></A
|
|||
|
>9. Scripts for use with QoS/Traffic Control</H1
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="sc-wondershaper"
|
|||
|
></A
|
|||
|
>9.1. wondershaper</H2
|
|||
|
><P
|
|||
|
> More to come, see <A
|
|||
|
HREF="http://lartc.org/wondershaper/"
|
|||
|
TARGET="_top"
|
|||
|
>wondershaper</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="sc-myshaper"
|
|||
|
></A
|
|||
|
>9.2. ADSL Bandwidth HOWTO script (<TT
|
|||
|
CLASS="filename"
|
|||
|
>myshaper</TT
|
|||
|
>)</H2
|
|||
|
><P
|
|||
|
> More to come, see <A
|
|||
|
HREF="http://www.tldp.org/HOWTO/ADSL-Bandwidth-Management-HOWTO/implementation.html"
|
|||
|
TARGET="_top"
|
|||
|
>myshaper</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="sc-htb.init"
|
|||
|
></A
|
|||
|
>9.3. <TT
|
|||
|
CLASS="filename"
|
|||
|
>htb.init</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> More to come, see <A
|
|||
|
HREF="http://sourceforge.net/projects/htbinit/"
|
|||
|
TARGET="_top"
|
|||
|
><TT
|
|||
|
CLASS="filename"
|
|||
|
>htb.init</TT
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="sc-tcng.init"
|
|||
|
></A
|
|||
|
>9.4. <TT
|
|||
|
CLASS="filename"
|
|||
|
>tcng.init</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> More to come, see <A
|
|||
|
HREF="http://linux-ip.net/code/tcng/tcng.init"
|
|||
|
TARGET="_top"
|
|||
|
><TT
|
|||
|
CLASS="filename"
|
|||
|
>tcng.init</TT
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="sc-cbq.init"
|
|||
|
></A
|
|||
|
>9.5. <TT
|
|||
|
CLASS="filename"
|
|||
|
>cbq.init</TT
|
|||
|
></H2
|
|||
|
><P
|
|||
|
> More to come, see <A
|
|||
|
HREF="http://sourceforge.net/projects/cbqinit/"
|
|||
|
TARGET="_top"
|
|||
|
><TT
|
|||
|
CLASS="filename"
|
|||
|
>cbq.init</TT
|
|||
|
></A
|
|||
|
>.
|
|||
|
</P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="diagram"
|
|||
|
></A
|
|||
|
>10. Diagram</H1
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H2
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="d-general"
|
|||
|
></A
|
|||
|
>10.1. General diagram</H2
|
|||
|
><P
|
|||
|
> Below is a general diagram of the relationships of the components of a
|
|||
|
classful queuing discipline (HTB pictured). A larger version of
|
|||
|
the diagram is
|
|||
|
<A
|
|||
|
HREF="http://linux-ip.net/traffic-control/htb-class.png"
|
|||
|
TARGET="_top"
|
|||
|
>available</A
|
|||
|
>.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> </P
|
|||
|
><DIV
|
|||
|
CLASS="example"
|
|||
|
><A
|
|||
|
NAME="d-tcng-config"
|
|||
|
></A
|
|||
|
><P
|
|||
|
><B
|
|||
|
>Example 11. An example HTB <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> configuration</B
|
|||
|
></P
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
BGCOLOR="#E0E0E0"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
><FONT
|
|||
|
COLOR="#000000"
|
|||
|
><PRE
|
|||
|
CLASS="programlisting"
|
|||
|
> /*
|
|||
|
*
|
|||
|
* possible mock up of diagram shown at
|
|||
|
* http://linux-ip.net/traffic-control/htb-class.png
|
|||
|
*
|
|||
|
*/
|
|||
|
|
|||
|
$m_web = trTCM (
|
|||
|
cir 512 kbps, /* commited information rate */
|
|||
|
cbs 10 kB, /* burst for CIR */
|
|||
|
pir 1024 kbps, /* peak information rate */
|
|||
|
pbs 10 kB /* burst for PIR */
|
|||
|
) ;
|
|||
|
|
|||
|
dev eth0 {
|
|||
|
egress {
|
|||
|
|
|||
|
class ( <$web> ) if tcp_dport == PORT_HTTP && __trTCM_green( $m_web );
|
|||
|
class ( <$bulk> ) if tcp_dport == PORT_HTTP && __trTCM_yellow( $m_web );
|
|||
|
drop if __trTCM_red( $m_web );
|
|||
|
class ( <$bulk> ) if tcp_dport == PORT_SSH ;
|
|||
|
|
|||
|
htb () { /* root qdisc */
|
|||
|
|
|||
|
class ( rate 1544kbps, ceil 1544kbps ) { /* root class */
|
|||
|
|
|||
|
$web = class ( rate 512kbps, ceil 512kbps ) { sfq ; } ;
|
|||
|
$bulk = class ( rate 512kbps, ceil 1544kbps ) { sfq ; } ;
|
|||
|
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
}
|
|||
|
</PRE
|
|||
|
></FONT
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="mediaobject"
|
|||
|
><P
|
|||
|
><IMG
|
|||
|
SRC="images/htb-class.png"></P
|
|||
|
></DIV
|
|||
|
><P
|
|||
|
> </P
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><DIV
|
|||
|
CLASS="section"
|
|||
|
><HR><H1
|
|||
|
CLASS="section"
|
|||
|
><A
|
|||
|
NAME="links"
|
|||
|
></A
|
|||
|
>11. Annotated Traffic Control Links</H1
|
|||
|
><P
|
|||
|
> This section identifies a number of links to documentation
|
|||
|
about traffic control and Linux traffic control software. Each link will
|
|||
|
be listed with a brief description of the content at that site.
|
|||
|
</P
|
|||
|
><P
|
|||
|
></P
|
|||
|
><UL
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://luxik.cdi.cz/~devik/qos/htb/"
|
|||
|
TARGET="_top"
|
|||
|
>HTB
|
|||
|
site</A
|
|||
|
>,
|
|||
|
<A
|
|||
|
HREF="http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm"
|
|||
|
TARGET="_top"
|
|||
|
>HTB
|
|||
|
user guide</A
|
|||
|
> and
|
|||
|
<A
|
|||
|
HREF="http://luxik.cdi.cz/~devik/qos/htb/manual/theory.htm"
|
|||
|
TARGET="_top"
|
|||
|
>HTB
|
|||
|
theory</A
|
|||
|
>
|
|||
|
(<EM
|
|||
|
>Martin <SPAN
|
|||
|
CLASS="QUOTE"
|
|||
|
>"devik"</SPAN
|
|||
|
> Devera</EM
|
|||
|
>)
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Hierarchical Token Bucket, <A
|
|||
|
HREF="#qc-htb"
|
|||
|
>HTB</A
|
|||
|
>, is a classful queuing
|
|||
|
discipline. Widely used and supported it is also fairly well
|
|||
|
documented in the user guide and at
|
|||
|
<A
|
|||
|
HREF="http://www.docum.org/"
|
|||
|
TARGET="_top"
|
|||
|
>Stef Coene's site</A
|
|||
|
>
|
|||
|
(see below).
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://opalsoft.net/qos/"
|
|||
|
TARGET="_top"
|
|||
|
>General Quality of
|
|||
|
Service docs</A
|
|||
|
> (<EM
|
|||
|
>Leonardo Balliache</EM
|
|||
|
>)
|
|||
|
<P
|
|||
|
> </P
|
|||
|
>
|
|||
|
There is a good deal of understandable and introductory documentation
|
|||
|
on his site, and in particular has some excellent overview material.
|
|||
|
See in particular, the detailed
|
|||
|
<A
|
|||
|
HREF="http://opalsoft.net/qos/DS.htm"
|
|||
|
TARGET="_top"
|
|||
|
>Linux QoS</A
|
|||
|
> document
|
|||
|
among others.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://tcng.sourceforge.net/"
|
|||
|
TARGET="_top"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> (Traffic Control
|
|||
|
Next Generation)</A
|
|||
|
> and
|
|||
|
<A
|
|||
|
HREF="http://linux-ip.net/gl/tcng/"
|
|||
|
TARGET="_top"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> manual</A
|
|||
|
>
|
|||
|
(<EM
|
|||
|
>Werner Almesberger</EM
|
|||
|
>)
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> software includes a language and a set of tools for
|
|||
|
creating and testing traffic control structures. In addition to
|
|||
|
generating <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> commands as output, it is also capable of providing
|
|||
|
output for non-Linux applications. A key piece of the <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> suite
|
|||
|
which is ignored in this documentation is the <B
|
|||
|
CLASS="command"
|
|||
|
>tcsim</B
|
|||
|
>
|
|||
|
traffic control simulator.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The user manual provided with the <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
> software has been converted
|
|||
|
to HTML with <B
|
|||
|
CLASS="command"
|
|||
|
>latex2html</B
|
|||
|
>. The distribution comes
|
|||
|
with the TeX documentation.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="ftp://ftp.inr.ac.ru/ip-routing/"
|
|||
|
TARGET="_top"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
></A
|
|||
|
> and
|
|||
|
<A
|
|||
|
HREF="http://linux-ip.net/gl/ip-cref/"
|
|||
|
TARGET="_top"
|
|||
|
><B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> manual</A
|
|||
|
>
|
|||
|
(<EM
|
|||
|
>Alexey Kuznetsov</EM
|
|||
|
>)
|
|||
|
</P
|
|||
|
><P
|
|||
|
> This is a the source code for the <B
|
|||
|
CLASS="command"
|
|||
|
>iproute2</B
|
|||
|
> suite, which includes the
|
|||
|
essential <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
> binary. Note, that as of
|
|||
|
iproute2-2.4.7-now-ss020116-try.tar.gz, the package did not support
|
|||
|
HTB, so a patch available from the <A
|
|||
|
HREF="http://luxik.cdi.cz/~devik/qos/htb/"
|
|||
|
TARGET="_top"
|
|||
|
>HTB</A
|
|||
|
> site will be
|
|||
|
required.
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The manual documents the entire suite of tools, although the <B
|
|||
|
CLASS="command"
|
|||
|
>tc</B
|
|||
|
>
|
|||
|
utility is not adequately documented here. The ambitious reader is
|
|||
|
recommended to the LARTC HOWTO after consuming this introduction.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://www.docum.org/"
|
|||
|
TARGET="_top"
|
|||
|
>Documentation, graphs, scripts and
|
|||
|
guidelines to traffic control under Linux</A
|
|||
|
>
|
|||
|
(<EM
|
|||
|
>Stef Coene</EM
|
|||
|
>)
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Stef Coene has been gathering statistics and test results, scripts and
|
|||
|
tips for the use of QoS under Linux. There are some particularly
|
|||
|
useful graphs and guidelines available for implementing traffic
|
|||
|
control at Stef's site.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://lartc.org/howto/"
|
|||
|
TARGET="_top"
|
|||
|
>LARTC HOWTO</A
|
|||
|
>
|
|||
|
(<EM
|
|||
|
>bert hubert, et. al.</EM
|
|||
|
>)
|
|||
|
</P
|
|||
|
><P
|
|||
|
> The Linux Advanced Routing and Traffic Control HOWTO is one of the key
|
|||
|
sources of data about the sophisticated techniques which are available
|
|||
|
for use under Linux. The Traffic Control Introduction HOWTO should
|
|||
|
provide the reader with enough background in the language and concepts
|
|||
|
of traffic control. The LARTC HOWTO is the next place the reader
|
|||
|
should look for general traffic control information.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://linux-ip.net/"
|
|||
|
TARGET="_top"
|
|||
|
>Guide to IP Networking with
|
|||
|
Linux</A
|
|||
|
> (<EM
|
|||
|
>Martin A. Brown</EM
|
|||
|
>)
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Not directly related to traffic control, this site includes articles
|
|||
|
and general documentation on the behaviour of the Linux IP layer.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://www.almesberger.net/cv/papers.html"
|
|||
|
TARGET="_top"
|
|||
|
>Werner
|
|||
|
Almesberger's Papers</A
|
|||
|
>
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Werner Almesberger is one of the main developers and champions of
|
|||
|
traffic control under Linux (he's also the author of <B
|
|||
|
CLASS="command"
|
|||
|
>tcng</B
|
|||
|
>, above).
|
|||
|
One of the key documents describing the entire traffic control
|
|||
|
architecture of the Linux kernel is his Linux Traffic Control -
|
|||
|
Implementation Overview which is available in
|
|||
|
<A
|
|||
|
HREF="http://www.almesberger.net/cv/papers/tcio8.pdf"
|
|||
|
TARGET="_top"
|
|||
|
>PDF</A
|
|||
|
>
|
|||
|
or
|
|||
|
<A
|
|||
|
HREF="http://www.almesberger.net/cv/papers/tcio8.ps.gz"
|
|||
|
TARGET="_top"
|
|||
|
>PS</A
|
|||
|
>
|
|||
|
format.
|
|||
|
</P
|
|||
|
></LI
|
|||
|
><LI
|
|||
|
><P
|
|||
|
> <A
|
|||
|
HREF="http://diffserv.sourceforge.net/"
|
|||
|
TARGET="_top"
|
|||
|
>Linux DiffServ
|
|||
|
project</A
|
|||
|
>
|
|||
|
</P
|
|||
|
><P
|
|||
|
> Mercilessly snipped from the main page of the DiffServ site...
|
|||
|
</P
|
|||
|
><A
|
|||
|
NAME="AEN1370"
|
|||
|
></A
|
|||
|
><BLOCKQUOTE
|
|||
|
CLASS="BLOCKQUOTE"
|
|||
|
>Differentiated Services (short: Diffserv) is an architecture for
|
|||
|
providing different types or levels of service for network traffic.
|
|||
|
One key characteristic of Diffserv is that flows are aggregated in
|
|||
|
the network, so that core routers only need to distinguish a
|
|||
|
comparably small number of aggregated flows, even if those flows
|
|||
|
contain thousands or millions of individual flows.
|
|||
|
</BLOCKQUOTE
|
|||
|
></LI
|
|||
|
></UL
|
|||
|
></DIV
|
|||
|
></DIV
|
|||
|
><H3
|
|||
|
CLASS="FOOTNOTES"
|
|||
|
>Notes</H3
|
|||
|
><TABLE
|
|||
|
BORDER="0"
|
|||
|
CLASS="FOOTNOTES"
|
|||
|
WIDTH="100%"
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN91"
|
|||
|
HREF="#AEN91"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[1]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> See <A
|
|||
|
HREF="#software"
|
|||
|
>Section 5</A
|
|||
|
> for more details on the use or
|
|||
|
installation of a particular traffic control mechanism, kernel or
|
|||
|
command line utility.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN220"
|
|||
|
HREF="#AEN220"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[2]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> This queueing model has long been used in civilized countries to
|
|||
|
distribute scant food or provisions equitably. William Faulkner is
|
|||
|
reputed to have walked to the front of the line for to fetch his
|
|||
|
share of ice, proving that not everybody likes the FIFO model, and
|
|||
|
providing us a model for considering priority queuing.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN225"
|
|||
|
HREF="#AEN225"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[3]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> Similarly, the entire traffic control system appears as a queue or
|
|||
|
scheduler to the higher layer which is enqueuing packets into this
|
|||
|
layer.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN271"
|
|||
|
HREF="#AEN271"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[4]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> This smoothing effect is not always desirable, hence the HTB
|
|||
|
parameters burst and cburst.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN422"
|
|||
|
HREF="#AEN422"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[5]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> A classful qdisc can only have children classes of its type. For
|
|||
|
example, an HTB qdisc can only have HTB classes as children. A CBQ
|
|||
|
qdisc cannot have HTB classes as children.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN483"
|
|||
|
HREF="#AEN483"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[6]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> In this case, you'll have a <A
|
|||
|
HREF="#c-filter"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>filter</TT
|
|||
|
></A
|
|||
|
> which uses a
|
|||
|
<A
|
|||
|
HREF="#c-classifier"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>classifier</TT
|
|||
|
></A
|
|||
|
> to select the packets you wish to drop. Then
|
|||
|
you'll use a <A
|
|||
|
HREF="#c-police"
|
|||
|
><TT
|
|||
|
CLASS="constant"
|
|||
|
>policer</TT
|
|||
|
></A
|
|||
|
> with a with a drop action like this
|
|||
|
<B
|
|||
|
CLASS="command"
|
|||
|
>police rate 1bps burst 1 action drop/drop</B
|
|||
|
>.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN505"
|
|||
|
HREF="#AEN505"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[7]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> I do not know the range nor base of these numbers. I believe they
|
|||
|
are u32 hexadecimal, but need to confirm this.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN542"
|
|||
|
HREF="#AEN542"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[8]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> The options listed in this example are taken from a 2.4.20 kernel
|
|||
|
source tree. The exact options may differ slightly from kernel
|
|||
|
release to kernel release depending on patches and new schedulers
|
|||
|
and classifiers.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN1146"
|
|||
|
HREF="#AEN1146"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[9]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> HTB will report bandwidth usage in this scenario
|
|||
|
incorrectly. It will calculate the bandwidth used by
|
|||
|
<TT
|
|||
|
CLASS="parameter"
|
|||
|
><I
|
|||
|
>quantum</I
|
|||
|
></TT
|
|||
|
> instead of the real dequeued packet size.
|
|||
|
This can skew results quickly.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
><TR
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="5%"
|
|||
|
><A
|
|||
|
NAME="FTN.AEN1189"
|
|||
|
HREF="#AEN1189"
|
|||
|
><SPAN
|
|||
|
CLASS="footnote"
|
|||
|
>[10]</SPAN
|
|||
|
></A
|
|||
|
></TD
|
|||
|
><TD
|
|||
|
ALIGN="LEFT"
|
|||
|
VALIGN="TOP"
|
|||
|
WIDTH="95%"
|
|||
|
><P
|
|||
|
> In fact, the
|
|||
|
<A
|
|||
|
HREF="#s-imq"
|
|||
|
>Intermediate Queuing Device
|
|||
|
(IMQ)</A
|
|||
|
> simulates an output device onto which traffic
|
|||
|
control structures can be attached. This clever solution allows
|
|||
|
a networking device to shape ingress traffic in the same fashion
|
|||
|
as egress traffic. Despite the apparent contradiction of the
|
|||
|
rule, IMQ appears as a device to the kernel. Thus, there has
|
|||
|
been no violation of the rule, but rather a sneaky
|
|||
|
reinterpretation of that rule.
|
|||
|
</P
|
|||
|
></TD
|
|||
|
></TR
|
|||
|
></TABLE
|
|||
|
></BODY
|
|||
|
></HTML
|
|||
|
>
|