1 diff -Naur iproute2-orig/Makefile iproute2/Makefile
2 --- iproute2-orig/Makefile 2002-01-15 15:30:32.000000000 -0800
3 +++ iproute2/Makefile 2004-05-21 00:16:36.000000000 -0700
6 DOCDIR=/usr/doc/iproute2
8 -KERNEL_INCLUDE=/usr/src/linux/include
9 -LIBC_INCLUDE=/usr/include
11 DEFINES= -DRESOLVE_HOSTNAMES
15 ADDLIB+=ipx_ntop.o ipx_pton.o
17 -ifeq ($(LIBC_INCLUDE)/socketbits.h,$(wildcard $(LIBC_INCLUDE)/socketbits.h))
18 - ifeq ($(LIBC_INCLUDE)/net/if_packet.h,$(wildcard $(LIBC_INCLUDE)/net/if_packet.h))
19 - GLIBCFIX=-I../include-glibc -include ../include-glibc/glibc-bugs.h
22 -ifeq ($(LIBC_INCLUDE)/bits/socket.h,$(wildcard $(LIBC_INCLUDE)/bits/socket.h))
23 - GLIBCFIX=-I../include-glibc -I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
28 CCOPTS = -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g
29 -CFLAGS = $(CCOPTS) $(GLIBCFIX) -I$(KERNEL_INCLUDE) -I../include $(DEFINES)
30 +CFLAGS = $(CCOPTS) -I../include $(DEFINES)
32 LDLIBS += -L../lib -lnetlink -lutil
36 LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a
41 for i in $(SUBDIRS); \
42 do $(MAKE) -C $$i; done
45 -ifeq ($(KERNEL_INCLUDE),)
46 - @echo "Please, set correct KERNEL_INCLUDE"; false
49 - if [ ! -r $(KERNEL_INCLUDE)/linux/autoconf.h ]; then \
50 - echo "Please, compile the kernel first"; false; fi
54 install -m 0755 -d $(DESTDIR)$(SBINDIR)
55 diff -Naur iproute2-orig/Makefile~ iproute2/Makefile~
56 --- iproute2-orig/Makefile~ 1969-12-31 16:00:00.000000000 -0800
57 +++ iproute2/Makefile~ 2002-01-15 15:30:32.000000000 -0800
59 +# Path to parent kernel include files directory
62 +CONFDIR=/etc/iproute2
63 +DOCDIR=/usr/doc/iproute2
65 +KERNEL_INCLUDE=/usr/src/linux/include
66 +LIBC_INCLUDE=/usr/include
68 +DEFINES= -DRESOLVE_HOSTNAMES
70 +#options if you have a bind>=4.9.4 libresolv (or, maybe, glibc)
74 +#options if you compile with libc5, and without a bind>=4.9.4 libresolv
76 +#ADDLIB=inet_ntop.o inet_pton.o
79 +ADDLIB+=dnet_ntop.o dnet_pton.o
82 +ADDLIB+=ipx_ntop.o ipx_pton.o
84 +ifeq ($(LIBC_INCLUDE)/socketbits.h,$(wildcard $(LIBC_INCLUDE)/socketbits.h))
85 + ifeq ($(LIBC_INCLUDE)/net/if_packet.h,$(wildcard $(LIBC_INCLUDE)/net/if_packet.h))
86 + GLIBCFIX=-I../include-glibc -include ../include-glibc/glibc-bugs.h
89 +ifeq ($(LIBC_INCLUDE)/bits/socket.h,$(wildcard $(LIBC_INCLUDE)/bits/socket.h))
90 + GLIBCFIX=-I../include-glibc -I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
95 +CCOPTS = -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g
96 +CFLAGS = $(CCOPTS) $(GLIBCFIX) -I$(KERNEL_INCLUDE) -I../include $(DEFINES)
98 +LDLIBS += -L../lib -lnetlink -lutil
100 +SUBDIRS=lib ip tc misc
102 +LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a
106 + for i in $(SUBDIRS); \
107 + do $(MAKE) -C $$i; done
110 +ifeq ($(KERNEL_INCLUDE),)
111 + @echo "Please, set correct KERNEL_INCLUDE"; false
114 + if [ ! -r $(KERNEL_INCLUDE)/linux/autoconf.h ]; then \
115 + echo "Please, compile the kernel first"; false; fi
119 + install -m 0755 -d $(DESTDIR)$(SBINDIR)
120 + install -m 0755 -d $(DESTDIR)$(CONFDIR)
121 + install -m 0755 -d $(DESTDIR)$(DOCDIR)/examples
122 + install -m 0755 -d $(DESTDIR)$(DOCDIR)/examples/diffserv
123 + install -m 0644 README.iproute2+tc $(shell find examples -type f -maxdepth 1) $(DESTDIR)$(DOCDIR)/examples
124 + install -m 0644 $(shell echo examples/diffserv/*) $(DESTDIR)$(DOCDIR)/examples/diffserv
125 + @for i in $(SUBDIRS) doc; do $(MAKE) -C $$i install; done
126 + @cd etc/iproute2; for i in *; do \
127 + if [ ! -e $(DESTDIR)$(CONFDIR)/$$i ]; then \
128 + echo install -m 0644 $$i $(DESTDIR)$(CONFDIR); \
129 + install -m 0644 $$i $(DESTDIR)$(CONFDIR); fi; done
132 + for i in $(SUBDIRS) doc; \
133 + do $(MAKE) -C $$i clean; done
135 +.EXPORT_ALL_VARIABLES:
136 diff -Naur iproute2-orig/debian/README.Debian iproute2/debian/README.Debian
137 --- iproute2-orig/debian/README.Debian 1969-12-31 16:00:00.000000000 -0800
138 +++ iproute2/debian/README.Debian 2004-05-21 00:09:38.000000000 -0700
140 +This version of "iproute" includes the HTB Linux queuing discipline
141 +explained in http://luxik.cdi.cz/~devik/qos/htb/
143 +You need kernel version 2.4.21 or newer in order to use it.
144 diff -Naur iproute2-orig/debian/changelog iproute2/debian/changelog
145 --- iproute2-orig/debian/changelog 1969-12-31 16:00:00.000000000 -0800
146 +++ iproute2/debian/changelog 2004-05-21 00:09:38.000000000 -0700
148 +iproute (20010824-13) unstable; urgency=low
150 + * debian/rules: Run dpkg-shlibdeps with all the executables,
151 + to fix dependency problem (closes: Bug#224063)
152 + * Really removed references to obsolete include files
153 + (Bug#223165 was not fixed properly)
155 + -- Juan Cespedes <cespedes@debian.org> Sun, 25 Jan 2004 23:04:20 +0100
157 +iproute (20010824-12) unstable; urgency=low
159 + * Updated README.Debian and copyright file
160 + * Added two new manpages from http://lartc.org/manpages/:
161 + ip(8) and tc-cbq-details(8).
162 + * Removed references to obsolete include files which made
163 + compilation fail (closes: Bug#223165)
165 + -- Juan Cespedes <cespedes@debian.org> Sun, 14 Dec 2003 00:40:10 +0100
167 +iproute (20010824-11) unstable; urgency=low
169 + * Changed priority to "optional"
170 + * Fixed "tc -s qdisc" on sparc (patch by "Nicolas S. Dade"
171 + <ndade@nsd.dyndns.org>) (closes: Bug#194128)
173 + -- Juan Cespedes <cespedes@debian.org> Sun, 17 Aug 2003 00:22:47 +0200
175 +iproute (20010824-10) unstable; urgency=low
177 + * Updated manual pages from http://www.lartc.org/manpages/
178 + (closes: Bug#156353, Bug#175313, Bug#176989, Bug#189095)
179 + * New Standards-Version
180 + * Don't "rm -rf /etc/iproute2" on purge (closes: Bug#202862)
181 + * Include "iproute2" in the description (closes: Bug#182999)
183 + -- Juan Cespedes <cespedes@debian.org> Sat, 16 Aug 2003 18:29:27 +0200
185 +iproute (20010824-9) unstable; urgency=medium
187 + * Added patch for HTB v3.6 to be able to work with kernel 2.4.20
188 + (from http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz)
189 + (closes: Bug#147550, Bug#167149, Bug#167597, Bug#171277)
191 + -- Juan Cespedes <cespedes@debian.org> Thu, 05 Dec 2002 13:44:10 +0100
193 +iproute (20010824-8) unstable; urgency=medium
195 + * Added support for HTB queuing discipline (closes: Bug#133381)
196 + NOTE: you need a patched kernel in order to use it
198 + -- Juan Cespedes <cespedes@debian.org> Tue, 2 Apr 2002 20:29:40 +0200
200 +iproute (20010824-7) unstable; urgency=medium
202 + * Move `ip' binary to /bin to fix FHS violation (closes: Bug#134812)
204 + -- Juan Cespedes <cespedes@debian.org> Mon, 4 Mar 2002 00:20:30 +0100
206 +iproute (20010824-6) unstable; urgency=low
208 + * Added a couple of #ifdef's to be able to compile with older
209 + kernel headers (needed for arm) (closes: Bug#131695)
211 + -- Juan Cespedes <cespedes@debian.org> Sat, 16 Feb 2002 19:27:15 +0100
213 +iproute (20010824-5) unstable; urgency=low
215 + * Really fix Bug#121589 (dead gateway bug); apparently I
216 + forgot to include the patch in 20010824-2
218 + -- Juan Cespedes <cespedes@debian.org> Tue, 29 Jan 2002 23:22:24 +0100
220 +iproute (20010824-4) unstable; urgency=low
222 + * Added support for DIFFSERV and ATM in tc
224 + -- Juan Cespedes <cespedes@debian.org> Sun, 13 Jan 2002 03:01:47 +0100
226 +iproute (20010824-3) unstable; urgency=low
228 + * Updated tc* man pages (thanks to bert hubert <ahu@ds9a.nl>)
229 + * Fixed spurious space in `tc -s qdisc' output (closes: Bug#128501)
231 + -- Juan Cespedes <cespedes@debian.org> Thu, 10 Jan 2002 22:18:25 +0100
233 +iproute (20010824-2) unstable; urgency=low
235 + * Fixed the following important and serious bugs:
236 + + iproute doesn't compile on Alpha (closes: Bug#118113, Bug#123224)
237 + + iproute doesn't compile on MIPS (closes: Bug#118424)
238 + + iproute doesn't compile on powerpc (closes: Bug#119601)
239 + * Added man pages for tc (closes: Bug#124230), tc-cbq, tc-red, tc-tbf,
241 + * Removed references to old programs from iproute(7) (closes: Bug#99536)
242 + * Fixed bug which presented first hop as dead in equal cost multipath
243 + (closes: Bug#121589)
244 + * Do not process .ps with through `psnup' (closes: Bug#119820)
246 + -- Juan Cespedes <cespedes@debian.org> Tue, 8 Jan 2002 16:07:27 +0100
248 +iproute (20010824-1) unstable; urgency=low
250 + * New upstream version
251 + * Make ingress qdisc work again with tc (closes: Bug#84444)
252 + * Make it compile properly with new include files (closes: Bug#113112)
254 + -- Juan Cespedes <cespedes@debian.org> Sun, 28 Oct 2001 16:38:00 +0100
256 +iproute (20001007-1) unstable; urgency=low
258 + * New upstream version (closes: Bug#63701)
259 + * Remove /etc/iproute2 on purge (closes: Bug#72743)
260 + * Fixed Lintian warnings (no-priority-field and no-section-field)
262 + -- Juan Cespedes <cespedes@debian.org> Sat, 14 Oct 2000 19:27:12 +0200
264 +iproute (991023-2) unstable; urgency=low
266 + * New Standards-Version (3.1.1) (closes: Bug#47923)
267 + * Modified description of package to show which kernel options are
268 + necessary to use the package (closes: Bug#47922)
269 + * Updated manual page to point at /usr/share/doc/iproute (closes: Bug#47924)
271 + -- Juan Cespedes <cespedes@debian.org> Sun, 19 Dec 1999 04:00:21 +0100
273 +iproute (991023-1) unstable; urgency=low
275 + * New upstream version (closes: Bug#48733)
277 + -- Juan Cespedes <cespedes@debian.org> Tue, 2 Nov 1999 16:29:37 +0100
279 +iproute (990824-1) unstable; urgency=low
282 + * New upstream version
283 + * New Standards-Version: 3.1.0
284 + * Minor fix in "ip rule list": mask in "from" address was not shown
286 + * Removed obsoleted documentation from "debian/" directory
288 + -- Juan Cespedes <cespedes@debian.org> Sun, 24 Oct 1999 19:02:56 +0200
290 +iproute (990630-1) unstable; urgency=low
292 + * New upstream version.
293 + * FHS and standards 3.0.1.0.
295 + -- Roberto Lumbreras <rover@debian.org> Tue, 3 Aug 1999 02:49:28 +0200
297 +iproute (990530-1) unstable; urgency=low
299 + * New upstream version.
300 + * Build with 2.2.10 kernel headers.
301 + * Install new scripts ip/routef ip/routel, but not ip/ifcfg ip/rtpr by
302 + now, I don't know who/what needs rtpr; ifcfg uses arping, and it isn't
303 + available in debian for now.
305 + -- Roberto Lumbreras <rover@debian.org> Tue, 22 Jun 1999 02:28:53 +0200
307 +iproute (990329-1) unstable; urgency=low
309 + * New upstream version.
310 + * Build with 2.2.5 kernel headers.
312 + -- Roberto Lumbreras <rover@debian.org> Sun, 4 Apr 1999 18:50:39 +0200
314 +iproute (980630-1) unstable; urgency=low
316 + * New upstream version.
317 + * Build with 2.1.112 kernel headers.
318 + * Rewrote the rules file.
320 + -- Roberto Lumbreras <rover@debian.org> Wed, 29 Jul 1998 23:37:52 +0200
322 +iproute (980119-1) unstable; urgency=low
324 + * Outdated documentation. Upstream docs are scarce.
325 + * Non-Maintainer release
326 + * This package has no correct copyright file!
327 + * Include all the README.* docs from the upstream site.
328 + * Modified to build under glibc
329 + * Build with 2.1.85 kernel headers.
330 + * produce a correct diff.
331 + * Reworked the rules file to utilize debmake fully
332 + * Newest upstream release
333 + * glibc compilation
335 + -- Christoph Lameter <christoph@lameter.com> Wed, 4 Feb 1998 13:37:28 -0800
337 +iproute (961225-2) unstable frozen; urgency=low
339 + * Added a man page for iproute. (Fixes #8080).
340 + * Removed out-of-date patches.
341 + * Added routing.txt from /usr/src/linux/Documentation/networking/routing.txt
342 + * Newer version of debmake.
344 + -- Tom Lees <tom@lpsg.demon.co.uk> Mon, 17 Apr 1997 17:00:36 +0100
346 +iproute (961225-1) unstable; urgency=low
350 + -- Tom Lees <tom@lpsg.demon.co.uk> Mon, 30 Dec 1996 11:12:23 +0000
353 +mode: debian-changelog
355 diff -Naur iproute2-orig/debian/conffiles iproute2/debian/conffiles
356 --- iproute2-orig/debian/conffiles 1969-12-31 16:00:00.000000000 -0800
357 +++ iproute2/debian/conffiles 2004-05-21 00:09:38.000000000 -0700
359 +/etc/iproute2/rt_dsfield
360 +/etc/iproute2/rt_protos
361 +/etc/iproute2/rt_realms
362 +/etc/iproute2/rt_scopes
363 +/etc/iproute2/rt_tables
364 diff -Naur iproute2-orig/debian/control iproute2/debian/control
365 --- iproute2-orig/debian/control 1969-12-31 16:00:00.000000000 -0800
366 +++ iproute2/debian/control 2004-05-21 00:09:38.000000000 -0700
371 +Maintainer: Juan Cespedes <cespedes@debian.org>
372 +Standards-Version: 3.6.0
373 +Build-Depends: tetex-bin, atm-dev
377 +Depends: ${shlibs:Depends}
378 +Description: Professional tools to control the networking in Linux kernels
379 + This is `iproute', the professional set of tools to control the
380 + networking behavior in kernels 2.2.x and later.
382 + At least, the options CONFIG_NETLINK and CONFIG_RTNETLINK must
383 + be compiled in the running kernel
385 + This package is also known as iproute2 upstream and in some
387 diff -Naur iproute2-orig/debian/copyright iproute2/debian/copyright
388 --- iproute2-orig/debian/copyright 1969-12-31 16:00:00.000000000 -0800
389 +++ iproute2/debian/copyright 2004-05-21 00:09:38.000000000 -0700
391 +This is the Debian GNU/Linux's prepackaged version of the
392 +Linux Traffic Control engine and related utils, "iproute"
394 +This package was put together from sources obtained from:
395 + ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss010824.tar.gz
398 + * added Debian GNU/Linux package maintenance system files
399 + * Added HTB v3.6 from
400 + <http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz>
405 +Copyright (C) 1996-2001 Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
407 +Modifications for Debian:
408 + Copyright (C) 1996 Tom Lees <tom@lpsg.demon.co.uk>
409 + Copyright (C) 1998 Christoph Lameter <christoph@lameter.com>
410 + Copyright (C) 1998-1999 Roberto Lumbreras <rover@debian.org>
411 + Copyright (C) 1999-2003 Juan Cespedes <cespedes@debian.org>
417 +This program is free software; you can redistribute it and/or modify
418 +it under the terms of the GNU General Public License as published by
419 +the Free Software Foundation; either version 2, or (at your option)
422 +This program is distributed in the hope that it will be useful, but
423 +WITHOUT ANY WARRANTY; without even the implied warranty of
424 +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
425 +General Public License for more details.
427 +A copy of the GNU General Public License is available as
428 +`/usr/share/common-licenses/GPL' in the Debian GNU/Linux distribution
429 +or on the World Wide Web at `http://www.gnu.org/copyleft/gpl.html'.
430 +You can also obtain it by writing to the Free Software Foundation,
431 +Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
433 diff -Naur iproute2-orig/debian/manpages/ip.8 iproute2/debian/manpages/ip.8
434 --- iproute2-orig/debian/manpages/ip.8 1969-12-31 16:00:00.000000000 -0800
435 +++ iproute2/debian/manpages/ip.8 2004-05-21 00:09:38.000000000 -0700
437 +.TH IP 8 "17 January 2002" "iproute2" "Linux"
439 +ip \- show / manipulate routing, devices, policy routing and tunnels
446 +.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
452 +.BR link " | " addr " | " route " | " rule " | " neigh " | " tunnel " | "\
453 +maddr " | " mroute " | " monitor " }"
457 +.IR OPTIONS " := { "
458 +\fB\-V\fR[\fIersion\fR] |
459 +\fB\-s\fR[\fItatistics\fR] |
460 +\fB\-r\fR[\fIesolve\fR] |
461 +\fB\-f\fR[\fIamily\fR] {
462 +.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
463 +\fB\-o\fR[\fIneline\fR] }
466 +.BI "ip link set " DEVICE
467 +.RB "{ " up " | " down " | " arp " { " on " | " off " } |"
469 +.BR promisc " { " on " | " off " } |"
471 +.BR allmulti " { " on " | " off " } |"
473 +.BR dynamic " { " on " | " off " } |"
475 +.BR multicast " { " on " | " off " } |"
493 +.RI "[ " DEVICE " ]"
496 +.BR "ip addr" " { " add " | " del " } "
497 +.IB IFADDR " dev " STRING
500 +.BR "ip addr" " { " show " | " flush " } [ " dev
503 +.IR SCOPE-ID " ] [ "
505 +.IR PREFIX " ] [ " FLAG-LIST " ] [ "
510 +.IR IFADDR " := " PREFIX " | " ADDR
524 +.RB "[ " host " | " link " | " global " | "
528 +.IR FLAG-LIST " := [ " FLAG-LIST " ] " FLAG
532 +.RB "[ " permanent " | " dynamic " | " secondary " | " primary " | "\
533 +tentative " | " deprecated " ]"
536 +.BR "ip route" " { "
537 +.BR list " | " flush " } "
543 +.BI from " ADDRESS " iif " STRING"
550 +.BR "ip route" " { " add " | " del " | " change " | " append " | "\
551 +replace " | " monitor " } "
563 +.IR TABLE_ID " ] [ "
572 +.IR ROUTE " := " NODE_SPEC " [ " INFO_SPEC " ]"
575 +.IR NODE_SPEC " := [ " TYPE " ] " PREFIX " ["
579 +.IR TABLE_ID " ] [ "
588 +.IR INFO_SPEC " := " "NH OPTIONS FLAGS" " ["
599 +.IR NUMBER " ] " NHFLAGS
602 +.IR OPTIONS " := " FLAGS " [ "
622 +.BR unicast " | " local " | " broadcast " | " multicast " | "\
623 +throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
626 +.IR TABLE_ID " := [ "
627 +.BR local "| " main " | " default " | " all " |"
632 +.BR host " | " link " | " global " |"
640 +.IR NHFLAGS " := [ "
641 +.BR onlink " | " pervasive " ]"
644 +.IR RTPROTO " := [ "
645 +.BR kernel " | " boot " | " static " |"
650 +.RB " [ " list " | " add " | " del " ]"
654 +.IR SELECTOR " := [ "
671 +.IR TABLE_ID " ] [ "
674 +.BR prohibit " | " reject " | " unreachable " ] [ " realms
675 +.RI "[" SRCREALM "/]" DSTREALM " ]"
678 +.IR TABLE_ID " := [ "
679 +.BR local " | " main " | " default " |"
683 +.BR "ip neigh" " { " add " | " del " | " change " | " replace " } { "
687 +.BR nud " { " permanent " | " noarp " | " stale " | " reachable " } ] | " proxy
693 +.BR "ip neigh" " { " show " | " flush " } [ " to
701 +.BR "ip tunnel" " { " add " | " change " | " del " | " show " }"
704 +.RB "[ " mode " { " ipip " | " gre " | " sit " } ]"
711 +.RB "[ [" i "|" o "]" seq " ] [ [" i "|" o "]" key
713 +.RB "[" i "|" o "]" csum " ] ]"
719 +.RB "[" no "]" pmtudisc " ]"
725 +.IR ADDR " := { " IP_ADDRESS " |"
729 +.IR TOS " := { " NUMBER " |"
733 +.IR TTL " := { " 1 ".." 255 " | "
737 +.IR KEY " := { " DOTTED_QUAD " | " NUMBER " }"
740 +.BR "ip maddr" " [ " add " | " del " ]"
741 +.IB MULTIADDR " dev " STRING
744 +.BR "ip maddr show" " [ " dev
748 +.BR "ip mroute show" " ["
756 +.BR "ip monitor" " [ " all " |"
757 +.IR LISTofOBJECTS " ]"
764 +.BR "\-V" , " -Version"
765 +print the version of the
770 +.BR "\-s" , " \-stats", " \-statistics"
771 +output more information. If the option
772 +appears twice or more, the amount of information increases.
773 +As a rule, the information is statistics or some time values.
776 +.BR "\-f" , " \-family"
777 +followed by protocol family identifier:
778 +.BR "inet" , " inet6"
781 +,enforce the protocol family to use. If the option is not present,
782 +the protocol family is guessed from other arguments. If the rest
783 +of the command line does not give enough information to guess the
786 +falls back to the default one, usually
791 +is a special family identifier meaning that no networking protocol
797 +.BR "-family inet" .
802 +.BR "\-family inet6" .
807 +.BR "\-family link" .
810 +.BR "\-o" , " \-oneline"
811 +output each record on a single line, replacing line feeds
814 +character. This is convenient when you want to count records
822 +.BR "\-r" , " \-resolve"
823 +use the system's name resolver to print DNS names instead of
826 +.SH IP - COMMAND SYNTAX
837 +- protocol (IP or IPv6) address on a device.
840 +- ARP or NDISC cache entry.
844 +- routing table entry.
848 +- rule in routing policy database.
852 +- multicast address.
856 +- multicast routing cache entry.
863 +The names of all objects may be written in full or
864 +abbreviated form, f.e.
874 +Specifies the action to perform on the object.
875 +The set of possible actions depends on the object type.
876 +As a rule, it is possible to
877 +.BR "add" , " delete"
882 +) objects, but some objects do not allow all of these operations
883 +or have some additional commands. The
885 +command is available for all objects. It prints
886 +out a list of available commands and argument syntax conventions.
888 +If no command is given, some default command is assumed.
891 +or, if the objects of this class cannot be listed,
894 +.SH ip link - network device configuration
897 +is a network device and the corresponding commands
898 +display and change the state of devices.
900 +.SS ip link set - change device attributes
903 +.BI dev " NAME " (default)
905 +specifies network device to operate on.
909 +change the state of the device to
915 +.BR "arp on " or " arp off"
921 +.BR "multicast on " or " multicast off"
927 +.BR "dynamic on " or " dynamic off"
934 +change the name of the device. This operation is not
935 +recommended if the device is running or has some addresses
939 +.BI txqueuelen " NUMBER"
941 +.BI txqlen " NUMBER"
942 +change the transmit queue length of the device.
951 +.BI address " LLADDRESS"
952 +change the station address of the interface.
955 +.BI broadcast " LLADDRESS"
957 +.BI brd " LLADDRESS"
959 +.BI peer " LLADDRESS"
960 +change the link layer broadcast address or the peer address when
966 +If multiple parameter changes are requested,
968 +aborts immediately after any of the changes have failed.
969 +This is the only case when
971 +can move the system to an unpredictable state. The solution
972 +is to avoid changing several parameters with one
976 +.SS ip link show - display device attributes
979 +.BI dev " NAME " (default)
981 +specifies the network device to show.
982 +If this argument is omitted all devices are listed.
986 +only display running interfaces.
988 +.SH ip address - protocol address management.
992 +is a protocol (IP or IPv6) address attached
993 +to a network device. Each device must have at least one address
994 +to use the corresponding protocol. It is possible to have several
995 +different addresses attached to one device. These addresses are not
996 +discriminated, so that the term
998 +is not quite appropriate for them and we do not use it in this document.
1002 +command displays addresses and their properties, adds new addresses
1003 +and deletes old ones.
1005 +.SS ip address add - add new protocol address.
1009 +the name of the device to add the address to.
1012 +.BI local " ADDRESS " (default)
1013 +the address of the interface. The format of the address depends
1014 +on the protocol. It is a dotted quad for IP and a sequence of
1015 +hexadecimal halfwords separated by colons for IPv6. The
1017 +may be followed by a slash and a decimal number which encodes
1018 +the network prefix length.
1021 +.BI peer " ADDRESS"
1022 +the address of the remote endpoint for pointopoint interfaces.
1025 +may be followed by a slash and a decimal number, encoding the network
1026 +prefix length. If a peer address is specified, the local address
1027 +cannot have a prefix length. The network prefix is associated
1028 +with the peer rather than with the local address.
1031 +.BI broadcast " ADDRESS"
1032 +the broadcast address on the interface.
1034 +It is possible to use the special symbols
1038 +instead of the broadcast address. In this case, the broadcast address
1039 +is derived by setting/resetting the host bits of the interface prefix.
1043 +Each address may be tagged with a label string.
1044 +In order to preserve compatibility with Linux-2.0 net aliases,
1045 +this string must coincide with the name of the device or must be prefixed
1046 +with the device name followed by colon.
1049 +.BI scope " SCOPE_VALUE"
1050 +the scope of the area where this address is valid.
1051 +The available scopes are listed in file
1052 +.BR "/etc/iproute2/rt_scopes" .
1053 +Predefined scope values are:
1057 +- the address is globally valid.
1060 +- (IPv6 only) the address is site local, i.e. it is
1061 +valid inside this site.
1064 +- the address is link local, i.e. it is valid only on this device.
1067 +- the address is valid only inside this host.
1070 +.SS ip address delete - delete protocol address
1072 +coincide with the arguments of
1074 +The device name is a required argument. The rest are optional.
1075 +If no arguments are given, the first address is deleted.
1077 +.SS ip address show - look at protocol addresses
1080 +.BI dev " NAME " (default)
1084 +.BI scope " SCOPE_VAL"
1085 +only list addresses with this scope.
1089 +only list addresses matching this prefix.
1092 +.BI label " PATTERN"
1093 +only list addresses with labels matching the
1096 +is a usual shell style pattern.
1099 +.BR dynamic " and " permanent
1100 +(IPv6 only) only list addresses installed due to stateless
1101 +address configuration or only list permanent (not dynamic)
1106 +(IPv6 only) only list addresses which did not pass duplicate
1111 +(IPv6 only) only list deprecated addresses.
1114 +.BR primary " and " secondary
1115 +only list primary (or secondary) addresses.
1117 +.SS ip address flush - flush protocol addresses
1118 +This command flushes the protocol addresses selected by some criteria.
1121 +This command has the same arguments as
1123 +The difference is that it does not run when no arguments are given.
1127 +This command (and other
1129 +commands described below) is pretty dangerous. If you make a mistake,
1130 +it will not forgive it, but will cruelly purge all the addresses.
1135 +option, the command becomes verbose. It prints out the number of deleted
1136 +addresses and the number of rounds made to flush the address list. If
1137 +this option is given twice,
1139 +also dumps all the deleted addresses in the format described in the
1140 +previous subsection.
1142 +.SH ip neighbour - neighbour/arp tables management.
1145 +objects establish bindings between protocol addresses and
1146 +link layer addresses for hosts sharing the same link.
1147 +Neighbour entries are organized into tables. The IPv4 neighbour table
1148 +is known by another name - the ARP table.
1151 +The corresponding commands display neighbour bindings
1152 +and their properties, add new neighbour entries and delete old ones.
1154 +.SS ip neighbour add - add a new neighbour entry
1155 +.SS ip neighbour change - change an existing entry
1156 +.SS ip neighbour replace - add a new entry or change an existing one
1158 +These commands create new neighbour records or update existing ones.
1161 +.BI to " ADDRESS " (default)
1162 +the protocol address of the neighbour. It is either an IPv4 or IPv6 address.
1166 +the interface to which this neighbour is attached.
1169 +.BI lladdr " LLADDRESS"
1170 +the link layer address of the neighbour.
1176 +.BI nud " NUD_STATE"
1177 +the state of the neighbour entry.
1179 +is an abbreviation for 'Neigh bour Unreachability Detection'.
1180 +The state can take one of the following values:
1184 +- the neighbour entry is valid forever and can be only
1185 +be removed administratively.
1189 +- the neighbour entry is valid. No attempts to validate
1190 +this entry will be made but it can be removed when its lifetime expires.
1194 +- the neighbour entry is valid until the reachability
1199 +- the neighbour entry is valid but suspicious.
1202 +does not change the neighbour state if it was valid and the address
1203 +is not changed by this command.
1206 +.SS ip neighbour delete - delete a neighbour entry
1207 +This command invalidates a neighbour entry.
1210 +The arguments are the same as with
1211 +.BR "ip neigh add" ,
1220 +Attempts to delete or manually change a
1222 +entry created by the kernel may result in unpredictable behaviour.
1223 +Particularly, the kernel may try to resolve this address even
1226 +interface or if the address is multicast or broadcast.
1228 +.SS ip neighbour show - list neighbour entries
1230 +This commands displays neighbour tables.
1233 +.BI to " ADDRESS " (default)
1234 +the prefix selecting the neighbours to list.
1238 +only list the neighbours attached to this device.
1242 +only list neighbours which are not currently in use.
1245 +.BI nud " NUD_STATE"
1246 +only list neighbour entries in this state.
1248 +takes values listed below or the special value
1250 +which means all states. This option may occur more than once.
1251 +If this option is absent,
1253 +lists all entries except for
1258 +.SS ip neighbour flush - flush neighbour entries
1259 +This command flushes neighbour tables, selecting
1260 +entries to flush by some criteria.
1263 +This command has the same arguments as
1265 +The differences are that it does not run when no arguments are given,
1266 +and that the default neighbour states to be flushed do not include
1274 +option, the command becomes verbose. It prints out the number of
1275 +deleted neighbours and the number of rounds made to flush the
1276 +neighbour table. If the option is given
1279 +also dumps all the deleted neighbours.
1281 +.SH ip route - routing table management
1282 +Manipulate route entries in the kernel routing tables keep
1283 +information about paths to other networked nodes.
1289 +- the route entry describes real paths to the destinations covered
1290 +by the route prefix.
1294 +- these destinations are unreachable. Packets are discarded and the
1296 +.I host unreachable
1298 +The local senders get an
1304 +- these destinations are unreachable. Packets are discarded silently.
1305 +The local senders get an
1311 +- these destinations are unreachable. Packets are discarded and the
1313 +.I communication administratively prohibited
1314 +is generated. The local senders get an
1320 +- the destinations are assigned to this host. The packets are looped
1321 +back and delivered locally.
1325 +- the destinations are broadcast addresses. The packets are sent as
1330 +- a special control route used together with policy rules. If such a
1331 +route is selected, lookup in this table is terminated pretending that
1332 +no route was found. Without policy routing it is equivalent to the
1333 +absence of the route in the routing table. The packets are dropped
1334 +and the ICMP message
1336 +is generated. The local senders get an
1342 +- a special NAT route. Destinations covered by the prefix
1343 +are considered to be dummy (or external) addresses which require translation
1344 +to real (or internal) ones before forwarding. The addresses to translate to
1345 +are selected with the attribute
1350 +.RI "- " "not implemented"
1351 +the destinations are
1353 +addresses assigned to this host. They are mainly equivalent
1356 +with one difference: such addresses are invalid when used
1357 +as the source address of any packet.
1361 +- a special type used for multicast routing. It is not present in
1362 +normal routing tables.
1367 +Linux-2.x can pack routes into several routing
1368 +tables identified by a number in the range from 1 to 255 or by
1370 +.B /etc/iproute2/rt_tables
1371 +. By default all normal routes are inserted into the
1373 +table (ID 254) and the kernel only uses this table when calculating routes.
1376 +Actually, one other table always exists, which is invisible but
1377 +even more important. It is the
1379 +table (ID 255). This table
1380 +consists of routes for local and broadcast addresses. The kernel maintains
1381 +this table automatically and the administrator usually need not modify it
1382 +or even look at it.
1384 +The multiple routing tables enter the game when
1388 +.SS ip route add - add new route
1389 +.SS ip route change - change route
1390 +.SS ip route replace - change or add new one
1393 +.BI to " TYPE PREFIX " (default)
1394 +the destination prefix of the route. If
1404 +is an IP or IPv6 address optionally followed by a slash and the
1405 +prefix length. If the length of the prefix is missing,
1407 +assumes a full-length host route. There is also a special
1410 +- which is equivalent to IP
1419 +the Type Of Service (TOS) key. This key has no associated mask and
1420 +the longest match is understood as: First, compare the TOS
1421 +of the route and of the packet. If they are not equal, then the packet
1422 +may still match a route with a zero TOS.
1424 +is either an 8 bit hexadecimal number or an identifier
1426 +.BR "/etc/iproute2/rt_dsfield" .
1429 +.BI metric " NUMBER"
1431 +.BI preference " NUMBER"
1432 +the preference value of the route.
1434 +is an arbitrary 32bit number.
1437 +.BI table " TABLEID"
1438 +the table to add this route to.
1440 +may be a number or a string from the file
1441 +.BR "/etc/iproute2/rt_tables" .
1442 +If this parameter is omitted,
1446 +table, with the exception of
1447 +.BR local " , " broadcast " and " nat
1448 +routes, which are put into the
1454 +the output device name.
1458 +the address of the nexthop router. Actually, the sense of this field
1459 +depends on the route type. For normal
1461 +routes it is either the true next hop router or, if it is a direct
1462 +route installed in BSD compatibility mode, it can be a local address
1463 +of the interface. For NAT routes it is the first address of the block
1464 +of translated IP destinations.
1468 +the source address to prefer when sending to the destinations
1469 +covered by the route prefix.
1472 +.BI realm " REALMID"
1473 +the realm to which this route is assigned.
1475 +may be a number or a string from the file
1476 +.BR "/etc/iproute2/rt_realms" .
1481 +.BI "mtu lock" " MTU"
1482 +the MTU along the path to the destination. If the modifier
1484 +is not used, the MTU may be updated by the kernel due to
1485 +Path MTU Discovery. If the modifier
1487 +is used, no path MTU discovery will be tried, all packets
1488 +will be sent without the DF bit in IPv4 case or fragmented
1492 +.BI window " NUMBER"
1493 +the maximal window for TCP to advertise to these destinations,
1494 +measured in bytes. It limits maximal data bursts that our TCP
1495 +peers are allowed to send to us.
1499 +the initial RTT ('Round Trip Time') estimate.
1502 +.BI rttvar " NUMBER " "(2.3.15+ only)"
1503 +the initial RTT variance estimate.
1506 +.BI ssthresh " NUMBER " "(2.3.15+ only)"
1507 +an estimate for the initial slow start threshold.
1510 +.BI cwnd " NUMBER " "(2.3.15+ only)"
1511 +the clamp for congestion window. It is ignored if the
1516 +.BI advmss " NUMBER " "(2.3.15+ only)"
1517 +the MSS ('Maximal Segment Size') to advertise to these
1518 +destinations when establishing TCP connections. If it is not given,
1519 +Linux uses a default value calculated from the first hop device MTU.
1520 +(If the path to these destination is asymmetric, this guess may be wrong.)
1523 +.BI reordering " NUMBER " "(2.3.15+ only)"
1524 +Maximal reordering on the path to this destination.
1525 +If it is not given, Linux uses the value selected with
1528 +.BR "net/ipv4/tcp_reordering" .
1531 +.BI nexthop " NEXTHOP"
1532 +the nexthop of a multipath route.
1534 +is a complex value with its own syntax similar to the top level
1539 +- is the nexthop router.
1543 +- is the output device.
1546 +.BI weight " NUMBER"
1547 +- is a weight for this element of a multipath
1548 +route reflecting its relative bandwidth or quality.
1552 +.BI scope " SCOPE_VAL"
1553 +the scope of the destinations covered by the route prefix.
1555 +may be a number or a string from the file
1556 +.BR "/etc/iproute2/rt_scopes" .
1557 +If this parameter is omitted,
1566 +.BR unicast " and " broadcast
1568 +.BR host " for " local
1572 +.BI protocol " RTPROTO"
1573 +the routing protocol identifier of this route.
1575 +may be a number or a string from the file
1576 +.BR "/etc/iproute2/rt_protos" .
1577 +If the routing protocol ID is not given,
1578 +.B ip assumes protocol
1580 +(i.e. it assumes the route was added by someone who doesn't
1581 +understand what they are doing). Several protocol values have
1582 +a fixed interpretation.
1587 +- the route was installed due to an ICMP redirect.
1591 +- the route was installed by the kernel during autoconfiguration.
1595 +- the route was installed during the bootup sequence.
1596 +If a routing daemon starts, it will purge all of them.
1600 +- the route was installed by the administrator
1601 +to override dynamic routing. Routing daemon will respect them
1602 +and, probably, even advertise them to its peers.
1606 +- the route was installed by Router Discovery protocol.
1610 +The rest of the values are not reserved and the administrator is free
1611 +to assign (or not to assign) protocol tags.
1615 +pretend that the nexthop is directly attached to this link,
1616 +even if it does not match any interface prefix.
1620 +allow packet by packet randomization on multipath routes.
1621 +Without this modifier, the route will be frozen to one selected
1622 +nexthop, so that load splitting will only occur on per-flow base.
1624 +only works if the kernel is patched.
1626 +.SS ip route delete - delete route
1629 +has the same arguments as
1630 +.BR "ip route add" ,
1631 +but their semantics are a bit different.
1634 +.RB "(" to ", " tos ", " preference " and " table ")"
1635 +select the route to delete. If optional attributes are present,
1637 +verifies that they coincide with the attributes of the route to delete.
1638 +If no route with the given key and attributes was found,
1642 +.SS ip route show - list routes
1643 +the command displays the contents of the routing tables or the route(s)
1644 +selected by some criteria.
1647 +.BI to " SELECTOR " (default)
1648 +only select routes from the given range of destinations.
1650 +consists of an optional modifier
1651 +.RB "(" root ", " match " or " exact ")"
1654 +selects routes with prefixes not shorter than
1658 +selects the entire routing table.
1659 +.BI match " PREFIX"
1660 +selects routes with prefixes not longer than
1663 +.BI match " 10.0/16"
1666 +.IR 10/8 " and " 0/0 ,
1667 +but it does not select
1668 +.IR 10.1/16 " and " 10.0.0/24 .
1670 +.BI exact " PREFIX"
1673 +selects routes with this exact prefix. If neither of these options
1678 +i.e. it lists the entire table.
1683 +only select routes with the given TOS.
1686 +.BI table " TABLEID"
1687 +show the routes from this table(s). The default setting is to show
1690 +may either be the ID of a real table or one of the special values:
1694 +- list all of the tables.
1697 +- dump the routing cache.
1704 +list cloned routes i.e. routes which were dynamically forked from
1705 +other routes because some route attribute (f.e. MTU) was updated.
1706 +Actually, it is equivalent to
1707 +.BR "table cache" "."
1710 +.BI from " SELECTOR"
1711 +the same syntax as for
1713 +but it binds the source address range rather than destinations.
1716 +option only works with cloned routes.
1719 +.BI protocol " RTPROTO"
1720 +only list routes of this protocol.
1723 +.BI scope " SCOPE_VAL"
1724 +only list routes with this scope.
1728 +only list routes of this type.
1732 +only list routes going via this device.
1736 +only list routes going via the nexthop routers selected by
1741 +only list routes with preferred source addresses selected
1746 +.BI realm " REALMID"
1748 +.BI realms " FROMREALM/TOREALM"
1749 +only list routes with these realms.
1751 +.SS ip route flush - flush routing tables
1752 +this command flushes routes selected by some criteria.
1755 +The arguments have the same syntax and semantics as the arguments of
1756 +.BR "ip route show" ,
1757 +but routing tables are not listed but purged. The only difference is
1758 +the default action:
1760 +dumps all the IP main routing table but
1762 +prints the helper page.
1767 +option, the command becomes verbose. It prints out the number of
1768 +deleted routes and the number of rounds made to flush the routing
1769 +table. If the option is given
1772 +also dumps all the deleted routes in the format described in the
1773 +previous subsection.
1775 +.SS ip route get - get a single route
1776 +this command gets a single route to a destination and prints its
1777 +contents exactly as the kernel sees it.
1780 +.BI to " ADDRESS " (default)
1781 +the destination address.
1784 +.BI from " ADDRESS"
1785 +the source address.
1791 +the Type Of Service.
1795 +the device from which this packet is expected to arrive.
1799 +force the output device on which this packet will be routed.
1803 +if no source address
1804 +.RB "(option " from ")"
1805 +was given, relookup the route with the source set to the preferred
1806 +address received from the first lookup.
1807 +If policy routing is used, it may be a different route.
1810 +Note that this operation is not equivalent to
1811 +.BR "ip route show" .
1813 +shows existing routes.
1815 +resolves them and creates new clones if necessary. Essentially,
1817 +is equivalent to sending a packet along this path.
1820 +argument is not given, the kernel creates a route
1821 +to output packets towards the requested destination.
1822 +This is equivalent to pinging the destination
1824 +.BR "ip route ls cache" ,
1825 +however, no packets are actually sent. With the
1827 +argument, the kernel pretends that a packet arrived from this interface
1828 +and searches for a path to forward the packet.
1830 +.SH ip rule - routing policy database management
1833 +in the routing policy database control the route selection algorithm.
1836 +Classic routing algorithms used in the Internet make routing decisions
1837 +based only on the destination address of packets (and in theory,
1838 +but not in practice, on the TOS field).
1841 +In some circumstances we want to route packets differently depending not only
1842 +on destination addresses, but also on other packet fields: source address,
1843 +IP protocol, transport protocol ports or even packet payload.
1844 +This task is called 'policy routing'.
1847 +To solve this task, the conventional destination based routing table, ordered
1848 +according to the longest match rule, is replaced with a 'routing policy
1849 +database' (or RPDB), which selects routes by executing some set of rules.
1852 +Each policy routing rule consists of a
1855 +.B action predicate.
1856 +The RPDB is scanned in the order of increasing priority. The selector
1857 +of each rule is applied to {source address, destination address, incoming
1858 +interface, tos, fwmark} and, if the selector matches the packet,
1859 +the action is performed. The action predicate may return with success.
1860 +In this case, it will either give a route or failure indication
1861 +and the RPDB lookup is terminated. Otherwise, the RPDB program
1862 +continues on the next rule.
1865 +Semantically, natural action is to select the nexthop and the output device.
1868 +At startup time the kernel configures the default RPDB consisting of three
1873 +Priority: 0, Selector: match anything, Action: lookup routing
1879 +table is a special routing table containing
1880 +high priority control routes for local and broadcast addresses.
1882 +Rule 0 is special. It cannot be deleted or overridden.
1886 +Priority: 32766, Selector: match anything, Action: lookup routing
1892 +table is the normal routing table containing all non-policy
1893 +routes. This rule may be deleted and/or overridden with other
1894 +ones by the administrator.
1898 +Priority: 32767, Selector: match anything, Action: lookup routing
1904 +table is empty. It is reserved for some post-processing if no previous
1905 +default rules selected the packet.
1906 +This rule may also be deleted.
1909 +Each RPDB entry has additional
1910 +attributes. F.e. each rule has a pointer to some routing
1911 +table. NAT and masquerading rules have an attribute to select new IP
1912 +address to translate/masquerade. Besides that, rules have some
1913 +optional attributes, which routes have, namely
1915 +These values do not override those contained in the routing tables. They
1916 +are only used if the route did not select any attributes.
1919 +The RPDB may contain rules of the following types:
1923 +- the rule prescribes to return the route found
1924 +in the routing table referenced by the rule.
1927 +- the rule prescribes to silently drop the packet.
1930 +- the rule prescribes to generate a 'Network is unreachable' error.
1933 +- the rule prescribes to generate 'Communication is administratively
1937 +- the rule prescribes to translate the source address
1938 +of the IP packet into some other value.
1941 +.SS ip rule add - insert a new rule
1942 +.SS ip rule delete - delete a rule
1945 +.BI type " TYPE " (default)
1946 +the type of this rule. The list of valid types was given in the previous
1951 +select the source prefix to match.
1955 +select the destination prefix to match.
1959 +select the incoming device to match. If the interface is loopback,
1960 +the rule only matches packets originating from this host. This means
1961 +that you may create separate routing tables for forwarded and local
1962 +packets and, hence, completely segregate them.
1968 +select the TOS value to match.
1977 +.BI priority " PREFERENCE"
1978 +the priority of this rule. Each rule should have an explicitly
1984 +.BI table " TABLEID"
1985 +the routing table identifier to lookup if the rule selector matches.
1988 +.BI realms " FROM/TO"
1989 +Realms to select if the rule matched and the routing table lookup
1992 +is only used if the route did not select any realm.
1996 +The base of the IP address block to translate (for source addresses).
1999 +may be either the start of the block of NAT addresses (selected by NAT
2000 +routes) or a local host address (or even zero).
2001 +In the last case the router does not translate the packets, but
2002 +masquerades them to this address.
2005 +Changes to the RPDB made with these commands do not become active
2006 +immediately. It is assumed that after a script finishes a batch of
2007 +updates, it flushes the routing cache with
2008 +.BR "ip route flush cache" .
2010 +.SS ip rule show - list rules
2011 +This command has no arguments.
2013 +.SH ip maddress - multicast addresses management
2016 +objects are multicast addresses.
2018 +.SS ip maddress show - list multicast addresses
2021 +.BI dev " NAME " (default)
2024 +.SS ip maddress add - add a multicast address
2025 +.SS ip maddress delete - delete a multicast address
2026 +these commands attach/detach a static link layer multicast address
2027 +to listen on the interface.
2028 +Note that it is impossible to join protocol multicast groups
2029 +statically. This command only manages link layer addresses.
2032 +.BI address " LLADDRESS " (default)
2033 +the link layer multicast address.
2037 +the device to join/leave this multicast address.
2039 +.SH ip mroute - multicast routing cache management
2041 +objects are multicast routing cache entries created by a user level
2042 +mrouting daemon (f.e.
2048 +Due to the limitations of the current interface to the multicast routing
2049 +engine, it is impossible to change
2051 +objects administratively, so we may only display them. This limitation
2052 +will be removed in the future.
2054 +.SS ip mroute show - list mroute cache entries
2057 +.BI to " PREFIX " (default)
2058 +the prefix selecting the destination multicast addresses to list.
2062 +the interface on which multicast packets are received.
2066 +the prefix selecting the IP source addresses of the multicast route.
2068 +.SH ip tunnel - tunnel configuration
2070 +objects are tunnels, encapsulating packets in IPv4 packets and then
2071 +sending them over the IP infrastructure.
2073 +.SS ip tunnel add - add a new tunnel
2074 +.SS ip tunnel change - change an existing tunnel
2075 +.SS ip tunnel delete - destroy a tunnel
2078 +.BI name " NAME " (default)
2079 +select the tunnel device name.
2083 +set the tunnel mode. Three modes are currently available:
2084 +.BR ipip ", " sit " and " gre "."
2087 +.BI remote " ADDRESS"
2088 +set the remote endpoint of the tunnel.
2091 +.BI local " ADDRESS"
2092 +set the fixed local address for tunneled packets.
2093 +It must be an address on another interface of this host.
2099 +on tunneled packets.
2101 +is a number in the range 1--255. 0 is a special value
2102 +meaning that packets inherit the TTL value.
2103 +The default value is:
2112 +on tunneled packets.
2113 +The default value is:
2118 +bind the tunnel to the device
2120 +so that tunneled packets will only be routed via this device and will
2121 +not be able to escape to another device when the route to endpoint
2126 +disable Path MTU Discovery on this tunnel.
2127 +It is enabled by default. Note that a fixed ttl is incompatible
2128 +with this option: tunnelling with a fixed ttl always makes pmtu
2137 +.RB ( " only GRE tunnels " )
2138 +use keyed GRE with key
2140 +is either a number or an IP address-like dotted quad.
2143 +parameter sets the key to use in both directions.
2145 +.BR ikey " and " okey
2146 +parameters set different keys for input and output.
2149 +.BR csum ", " icsum ", " ocsum
2150 +.RB ( " only GRE tunnels " )
2151 +generate/require checksums for tunneled packets.
2154 +flag calculates checksums for outgoing packets.
2157 +flag requires that all input packets have the correct
2160 +flag is equivalent to the combination
2161 +.BR "icsum ocsum" .
2164 +.BR seq ", " iseq ", " oseq
2165 +.RB ( " only GRE tunnels " )
2169 +flag enables sequencing of outgoing packets.
2172 +flag requires that all input packets are serialized.
2175 +flag is equivalent to the combination
2177 +.B It isn't work. Don't use it.
2179 +.SS ip tunnel show - list tunnels
2180 +This command has no arguments.
2182 +.SH ip monitor and rtmon - state monitoring
2186 +utility can monitor the state of devices, addresses
2187 +and routes continuously. This option has a slightly different format.
2190 +command is the first in the command line and then the object list follows:
2192 +.BR "ip monitor" " [ " all " |"
2193 +.IR LISTofOBJECTS " ]"
2196 +is the list of object types that we want to monitor.
2198 +.BR link ", " address " and " route "."
2203 +opens RTNETLINK, listens on it and dumps state changes in the format
2204 +described in previous sections.
2207 +If a file name is given, it does not listen on RTNETLINK,
2208 +but opens the file containing RTNETLINK messages saved in binary format
2209 +and dumps them. Such a history file can be generated with the
2211 +utility. This utility has a command line syntax similar to
2215 +should be started before the first network configuration command
2216 +is issued. F.e. if you insert:
2219 +rtmon file /var/log/rtmon.log
2222 +in a startup script, you will be able to view the full history
2226 +Certainly, it is possible to start
2229 +It prepends the history with the state snapshot dumped at the moment
2235 +was written by Alexey N. Kuznetsov and added in Linux 2.2.
2239 +.RB "IP Command reference " ip-cref.ps
2241 +.RB "IP tunnels " ip-cref.ps
2245 +Manpage maintained by Michail Litvak <mci@owl.openwall.com>
2246 diff -Naur iproute2-orig/debian/manpages/old/ip.8 iproute2/debian/manpages/old/ip.8
2247 --- iproute2-orig/debian/manpages/old/ip.8 1969-12-31 16:00:00.000000000 -0800
2248 +++ iproute2/debian/manpages/old/ip.8 2004-05-21 00:09:38.000000000 -0700
2250 +.TH IP 8 "17 January 2002" "iproute2" "Linux"
2252 +ip \- show / manipulate routing, devices, policy routing and tunnels
2259 +.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
2264 +.IR OBJECT " := { "
2265 +.BR link " | " addr " | " route " | " rule " | " neigh " | " tunnel " | "\
2266 +maddr " | " mroute " | " monitor " }"
2270 +.IR OPTIONS " := { "
2271 +\fB\-V\fR[\fIersion\fR] |
2272 +\fB\-s\fR[\fItatistics\fR] |
2273 +\fB\-r\fR[\fIesolve\fR] |
2274 +\fB\-f\fR[\fIamily\fR] {
2275 +.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
2276 +\fB\-o\fR[\fIneline\fR] }
2279 +.BI "ip link set " DEVICE
2280 +.RB "{ " up " | " down " | " arp " { " on " | " off " } |"
2282 +.BR promisc " { " on " | " off " } |"
2284 +.BR allmulti " { " on " | " off " } |"
2286 +.BR dynamic " { " on " | " off " } |"
2288 +.BR multicast " { " on " | " off " } |"
2306 +.RI "[ " DEVICE " ]"
2309 +.BR "ip addr" " { " add " | " del " } "
2310 +.IB IFADDR " dev " STRING
2313 +.BR "ip addr" " { " show " | " flush " } [ " dev
2316 +.IR SCOPE-ID " ] [ "
2318 +.IR PREFIX " ] [ " FLAG-LIST " ] [ "
2323 +.IR IFADDR " := " PREFIX " | " ADDR
2336 +.IR SCOPE-ID " := "
2337 +.RB "[ " host " | " link " | " global " | "
2341 +.IR FLAG-LIST " := [ " FLAG-LIST " ] " FLAG
2345 +.RB "[ " permanent " | " dynamic " | " secondary " | " primary " | "\
2346 +tentative " | " deprecated " ]"
2349 +.BR "ip route" " { "
2350 +.BR list " | " flush " } "
2356 +.BI from " ADDRESS " iif " STRING"
2363 +.BR "ip route" " { " add " | " del " | " change " | " append " | "\
2364 +replace " | " monitor " } "
2368 +.IR SELECTOR " := "
2376 +.IR TABLE_ID " ] [ "
2378 +.IR RTPROTO " ] [ "
2385 +.IR ROUTE " := " NODE_SPEC " [ " INFO_SPEC " ]"
2388 +.IR NODE_SPEC " := [ " TYPE " ] " PREFIX " ["
2392 +.IR TABLE_ID " ] [ "
2394 +.IR RTPROTO " ] [ "
2401 +.IR INFO_SPEC " := " "NH OPTIONS FLAGS" " ["
2408 +.IR ADDRESS " ] [ "
2412 +.IR NUMBER " ] " NHFLAGS
2415 +.IR OPTIONS " := " FLAGS " [ "
2435 +.BR unicast " | " local " | " broadcast " | " multicast " | "\
2436 +throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
2439 +.IR TABLE_ID " := [ "
2440 +.BR local "| " main " | " default " | " all " |"
2445 +.BR host " | " link " | " global " |"
2453 +.IR NHFLAGS " := [ "
2454 +.BR onlink " | " pervasive " ]"
2457 +.IR RTPROTO " := [ "
2458 +.BR kernel " | " boot " | " static " |"
2463 +.RB " [ " list " | " add " | " del " ]"
2467 +.IR SELECTOR " := [ "
2482 +.IR ACTION " := [ "
2484 +.IR TABLE_ID " ] [ "
2486 +.IR ADDRESS " ] [ "
2487 +.BR prohibit " | " reject " | " unreachable " ] [ " realms
2488 +.RI "[" SRCREALM "/]" DSTREALM " ]"
2491 +.IR TABLE_ID " := [ "
2492 +.BR local " | " main " | " default " |"
2496 +.BR "ip neigh" " { " add " | " del " | " change " | " replace " } { "
2500 +.BR nud " { " permanent " | " noarp " | " stale " | " reachable " } ] | " proxy
2506 +.BR "ip neigh" " { " show " | " flush " } [ " to
2514 +.BR "ip tunnel" " { " add " | " change " | " del " | " show " }"
2517 +.RB "[ " mode " { " ipip " | " gre " | " sit " } ]"
2524 +.RB "[ [" i "|" o "]" seq " ] [ [" i "|" o "]" key
2526 +.RB "[" i "|" o "]" csum " ] ]"
2532 +.RB "[" no "]" pmtudisc " ]"
2538 +.IR ADDR " := { " IP_ADDRESS " |"
2542 +.IR TOS " := { " NUMBER " |"
2546 +.IR TTL " := { " 1 ".." 255 " | "
2550 +.IR KEY " := { " DOTTED_QUAD " | " NUMBER " }"
2553 +.BR "ip maddr" " [ " add " | " del " ]"
2554 +.IB MULTIADDR " dev " STRING
2557 +.BR "ip maddr show" " [ " dev
2561 +.BR "ip mroute show" " ["
2569 +.BR "ip monitor" " [ " all " |"
2570 +.IR LISTofOBJECTS " ]"
2577 +.BR "\-V" , " -Version"
2578 +print the version of the
2583 +.BR "\-s" , " \-stats", " \-statistics"
2584 +output more information. If the option
2585 +appears twice or more, the amount of information increases.
2586 +As a rule, the information is statistics or some time values.
2589 +.BR "\-f" , " \-family"
2590 +followed by protocol family identifier:
2591 +.BR "inet" , " inet6"
2594 +,enforce the protocol family to use. If the option is not present,
2595 +the protocol family is guessed from other arguments. If the rest
2596 +of the command line does not give enough information to guess the
2599 +falls back to the default one, usually
2604 +is a special family identifier meaning that no networking protocol
2610 +.BR "-family inet" .
2615 +.BR "\-family inet6" .
2620 +.BR "\-family link" .
2623 +.BR "\-o" , " \-oneline"
2624 +output each record on a single line, replacing line feeds
2627 +character. This is convenient when you want to count records
2635 +.BR "\-r" , " \-resolve"
2636 +use the system's name resolver to print DNS names instead of
2639 +.SH IP - COMMAND SYNTAX
2650 +- protocol (IP or IPv6) address on a device.
2653 +- ARP or NDISC cache entry.
2657 +- routing table entry.
2661 +- rule in routing policy database.
2665 +- multicast address.
2669 +- multicast routing cache entry.
2676 +The names of all objects may be written in full or
2677 +abbreviated form, f.e.
2687 +Specifies the action to perform on the object.
2688 +The set of possible actions depends on the object type.
2689 +As a rule, it is possible to
2690 +.BR "add" , " delete"
2695 +) objects, but some objects do not allow all of these operations
2696 +or have some additional commands. The
2698 +command is available for all objects. It prints
2699 +out a list of available commands and argument syntax conventions.
2701 +If no command is given, some default command is assumed.
2704 +or, if the objects of this class cannot be listed,
2707 +.SH ip link - network device configuration
2710 +is a network device and the corresponding commands
2711 +display and change the state of devices.
2713 +.SS ip link set - change device attributes
2716 +.BI dev " NAME " (default)
2718 +specifies network device to operate on.
2721 +.BR up " and " down
2722 +change the state of the device to
2728 +.BR "arp on " or " arp off"
2731 +flag on the device.
2734 +.BR "multicast on " or " multicast off"
2737 +flag on the device.
2740 +.BR "dynamic on " or " dynamic off"
2743 +flag on the device.
2747 +change the name of the device. This operation is not
2748 +recommended if the device is running or has some addresses
2749 +already configured.
2752 +.BI txqueuelen " NUMBER"
2754 +.BI txqlen " NUMBER"
2755 +change the transmit queue length of the device.
2764 +.BI address " LLADDRESS"
2765 +change the station address of the interface.
2768 +.BI broadcast " LLADDRESS"
2770 +.BI brd " LLADDRESS"
2772 +.BI peer " LLADDRESS"
2773 +change the link layer broadcast address or the peer address when
2775 +.IR "POINTOPOINT" .
2779 +If multiple parameter changes are requested,
2781 +aborts immediately after any of the changes have failed.
2782 +This is the only case when
2784 +can move the system to an unpredictable state. The solution
2785 +is to avoid changing several parameters with one
2789 +.SS ip link show - display device attributes
2792 +.BI dev " NAME " (default)
2794 +specifies the network device to show.
2795 +If this argument is omitted all devices are listed.
2799 +only display running interfaces.
2801 +.SH ip address - protocol address management.
2805 +is a protocol (IP or IPv6) address attached
2806 +to a network device. Each device must have at least one address
2807 +to use the corresponding protocol. It is possible to have several
2808 +different addresses attached to one device. These addresses are not
2809 +discriminated, so that the term
2811 +is not quite appropriate for them and we do not use it in this document.
2815 +command displays addresses and their properties, adds new addresses
2816 +and deletes old ones.
2818 +.SS ip address add - add new protocol address.
2822 +the name of the device to add the address to.
2825 +.BI local " ADDRESS " (default)
2826 +the address of the interface. The format of the address depends
2827 +on the protocol. It is a dotted quad for IP and a sequence of
2828 +hexadecimal halfwords separated by colons for IPv6. The
2830 +may be followed by a slash and a decimal number which encodes
2831 +the network prefix length.
2834 +.BI peer " ADDRESS"
2835 +the address of the remote endpoint for pointopoint interfaces.
2838 +may be followed by a slash and a decimal number, encoding the network
2839 +prefix length. If a peer address is specified, the local address
2840 +cannot have a prefix length. The network prefix is associated
2841 +with the peer rather than with the local address.
2844 +.BI broadcast " ADDRESS"
2845 +the broadcast address on the interface.
2847 +It is possible to use the special symbols
2851 +instead of the broadcast address. In this case, the broadcast address
2852 +is derived by setting/resetting the host bits of the interface prefix.
2856 +Each address may be tagged with a label string.
2857 +In order to preserve compatibility with Linux-2.0 net aliases,
2858 +this string must coincide with the name of the device or must be prefixed
2859 +with the device name followed by colon.
2862 +.BI scope " SCOPE_VALUE"
2863 +the scope of the area where this address is valid.
2864 +The available scopes are listed in file
2865 +.BR "/etc/iproute2/rt_scopes" .
2866 +Predefined scope values are:
2870 +- the address is globally valid.
2873 +- (IPv6 only) the address is site local, i.e. it is
2874 +valid inside this site.
2877 +- the address is link local, i.e. it is valid only on this device.
2880 +- the address is valid only inside this host.
2883 +.SS ip address delete - delete protocol address
2885 +coincide with the arguments of
2887 +The device name is a required argument. The rest are optional.
2888 +If no arguments are given, the first address is deleted.
2890 +.SS ip address show - look at protocol addresses
2893 +.BI dev " NAME " (default)
2897 +.BI scope " SCOPE_VAL"
2898 +only list addresses with this scope.
2902 +only list addresses matching this prefix.
2905 +.BI label " PATTERN"
2906 +only list addresses with labels matching the
2909 +is a usual shell style pattern.
2912 +.BR dynamic " and " permanent
2913 +(IPv6 only) only list addresses installed due to stateless
2914 +address configuration or only list permanent (not dynamic)
2919 +(IPv6 only) only list addresses which did not pass duplicate
2924 +(IPv6 only) only list deprecated addresses.
2927 +.BR primary " and " secondary
2928 +only list primary (or secondary) addresses.
2930 +.SS ip address flush - flush protocol addresses
2931 +This command flushes the protocol addresses selected by some criteria.
2934 +This command has the same arguments as
2936 +The difference is that it does not run when no arguments are given.
2940 +This command (and other
2942 +commands described below) is pretty dangerous. If you make a mistake,
2943 +it will not forgive it, but will cruelly purge all the addresses.
2948 +option, the command becomes verbose. It prints out the number of deleted
2949 +addresses and the number of rounds made to flush the address list. If
2950 +this option is given twice,
2952 +also dumps all the deleted addresses in the format described in the
2953 +previous subsection.
2955 +.SH ip neighbour - neighbour/arp tables management.
2958 +objects establish bindings between protocol addresses and
2959 +link layer addresses for hosts sharing the same link.
2960 +Neighbour entries are organized into tables. The IPv4 neighbour table
2961 +is known by another name - the ARP table.
2964 +The corresponding commands display neighbour bindings
2965 +and their properties, add new neighbour entries and delete old ones.
2967 +.SS ip neighbour add - add a new neighbour entry
2968 +.SS ip neighbour change - change an existing entry
2969 +.SS ip neighbour replace - add a new entry or change an existing one
2971 +These commands create new neighbour records or update existing ones.
2974 +.BI to " ADDRESS " (default)
2975 +the protocol address of the neighbour. It is either an IPv4 or IPv6 address.
2979 +the interface to which this neighbour is attached.
2982 +.BI lladdr " LLADDRESS"
2983 +the link layer address of the neighbour.
2989 +.BI nud " NUD_STATE"
2990 +the state of the neighbour entry.
2992 +is an abbreviation for 'Neigh bour Unreachability Detection'.
2993 +The state can take one of the following values:
2997 +- the neighbour entry is valid forever and can be only
2998 +be removed administratively.
3002 +- the neighbour entry is valid. No attempts to validate
3003 +this entry will be made but it can be removed when its lifetime expires.
3007 +- the neighbour entry is valid until the reachability
3012 +- the neighbour entry is valid but suspicious.
3015 +does not change the neighbour state if it was valid and the address
3016 +is not changed by this command.
3019 +.SS ip neighbour delete - delete a neighbour entry
3020 +This command invalidates a neighbour entry.
3023 +The arguments are the same as with
3024 +.BR "ip neigh add" ,
3033 +Attempts to delete or manually change a
3035 +entry created by the kernel may result in unpredictable behaviour.
3036 +Particularly, the kernel may try to resolve this address even
3039 +interface or if the address is multicast or broadcast.
3041 +.SS ip neighbour show - list neighbour entries
3043 +This commands displays neighbour tables.
3046 +.BI to " ADDRESS " (default)
3047 +the prefix selecting the neighbours to list.
3051 +only list the neighbours attached to this device.
3055 +only list neighbours which are not currently in use.
3058 +.BI nud " NUD_STATE"
3059 +only list neighbour entries in this state.
3061 +takes values listed below or the special value
3063 +which means all states. This option may occur more than once.
3064 +If this option is absent,
3066 +lists all entries except for
3071 +.SS ip neighbour flush - flush neighbour entries
3072 +This command flushes neighbour tables, selecting
3073 +entries to flush by some criteria.
3076 +This command has the same arguments as
3078 +The differences are that it does not run when no arguments are given,
3079 +and that the default neighbour states to be flushed do not include
3087 +option, the command becomes verbose. It prints out the number of
3088 +deleted neighbours and the number of rounds made to flush the
3089 +neighbour table. If the option is given
3092 +also dumps all the deleted neighbours.
3094 +.SH ip route - routing table management
3095 +Manipulate route entries in the kernel routing tables keep
3096 +information about paths to other networked nodes.
3102 +- the route entry describes real paths to the destinations covered
3103 +by the route prefix.
3107 +- these destinations are unreachable. Packets are discarded and the
3109 +.I host unreachable
3111 +The local senders get an
3117 +- these destinations are unreachable. Packets are discarded silently.
3118 +The local senders get an
3124 +- these destinations are unreachable. Packets are discarded and the
3126 +.I communication administratively prohibited
3127 +is generated. The local senders get an
3133 +- the destinations are assigned to this host. The packets are looped
3134 +back and delivered locally.
3138 +- the destinations are broadcast addresses. The packets are sent as
3143 +- a special control route used together with policy rules. If such a
3144 +route is selected, lookup in this table is terminated pretending that
3145 +no route was found. Without policy routing it is equivalent to the
3146 +absence of the route in the routing table. The packets are dropped
3147 +and the ICMP message
3149 +is generated. The local senders get an
3155 +- a special NAT route. Destinations covered by the prefix
3156 +are considered to be dummy (or external) addresses which require translation
3157 +to real (or internal) ones before forwarding. The addresses to translate to
3158 +are selected with the attribute
3163 +.RI "- " "not implemented"
3164 +the destinations are
3166 +addresses assigned to this host. They are mainly equivalent
3169 +with one difference: such addresses are invalid when used
3170 +as the source address of any packet.
3174 +- a special type used for multicast routing. It is not present in
3175 +normal routing tables.
3180 +Linux-2.x can pack routes into several routing
3181 +tables identified by a number in the range from 1 to 255 or by
3183 +.B /etc/iproute2/rt_tables
3184 +. By default all normal routes are inserted into the
3186 +table (ID 254) and the kernel only uses this table when calculating routes.
3189 +Actually, one other table always exists, which is invisible but
3190 +even more important. It is the
3192 +table (ID 255). This table
3193 +consists of routes for local and broadcast addresses. The kernel maintains
3194 +this table automatically and the administrator usually need not modify it
3195 +or even look at it.
3197 +The multiple routing tables enter the game when
3201 +.SS ip route add - add new route
3202 +.SS ip route change - change route
3203 +.SS ip route replace - change or add new one
3206 +.BI to " TYPE PREFIX " (default)
3207 +the destination prefix of the route. If
3217 +is an IP or IPv6 address optionally followed by a slash and the
3218 +prefix length. If the length of the prefix is missing,
3220 +assumes a full-length host route. There is also a special
3223 +- which is equivalent to IP
3232 +the Type Of Service (TOS) key. This key has no associated mask and
3233 +the longest match is understood as: First, compare the TOS
3234 +of the route and of the packet. If they are not equal, then the packet
3235 +may still match a route with a zero TOS.
3237 +is either an 8 bit hexadecimal number or an identifier
3239 +.BR "/etc/iproute2/rt_dsfield" .
3242 +.BI metric " NUMBER"
3244 +.BI preference " NUMBER"
3245 +the preference value of the route.
3247 +is an arbitrary 32bit number.
3250 +.BI table " TABLEID"
3251 +the table to add this route to.
3253 +may be a number or a string from the file
3254 +.BR "/etc/iproute2/rt_tables" .
3255 +If this parameter is omitted,
3259 +table, with the exception of
3260 +.BR local " , " broadcast " and " nat
3261 +routes, which are put into the
3267 +the output device name.
3271 +the address of the nexthop router. Actually, the sense of this field
3272 +depends on the route type. For normal
3274 +routes it is either the true next hop router or, if it is a direct
3275 +route installed in BSD compatibility mode, it can be a local address
3276 +of the interface. For NAT routes it is the first address of the block
3277 +of translated IP destinations.
3281 +the source address to prefer when sending to the destinations
3282 +covered by the route prefix.
3285 +.BI realm " REALMID"
3286 +the realm to which this route is assigned.
3288 +may be a number or a string from the file
3289 +.BR "/etc/iproute2/rt_realms" .
3294 +.BI "mtu lock" " MTU"
3295 +the MTU along the path to the destination. If the modifier
3297 +is not used, the MTU may be updated by the kernel due to
3298 +Path MTU Discovery. If the modifier
3300 +is used, no path MTU discovery will be tried, all packets
3301 +will be sent without the DF bit in IPv4 case or fragmented
3305 +.BI window " NUMBER"
3306 +the maximal window for TCP to advertise to these destinations,
3307 +measured in bytes. It limits maximal data bursts that our TCP
3308 +peers are allowed to send to us.
3312 +the initial RTT ('Round Trip Time') estimate.
3315 +.BI rttvar " NUMBER " "(2.3.15+ only)"
3316 +the initial RTT variance estimate.
3319 +.BI ssthresh " NUMBER " "(2.3.15+ only)"
3320 +an estimate for the initial slow start threshold.
3323 +.BI cwnd " NUMBER " "(2.3.15+ only)"
3324 +the clamp for congestion window. It is ignored if the
3329 +.BI advmss " NUMBER " "(2.3.15+ only)"
3330 +the MSS ('Maximal Segment Size') to advertise to these
3331 +destinations when establishing TCP connections. If it is not given,
3332 +Linux uses a default value calculated from the first hop device MTU.
3333 +(If the path to these destination is asymmetric, this guess may be wrong.)
3336 +.BI reordering " NUMBER " "(2.3.15+ only)"
3337 +Maximal reordering on the path to this destination.
3338 +If it is not given, Linux uses the value selected with
3341 +.BR "net/ipv4/tcp_reordering" .
3344 +.BI nexthop " NEXTHOP"
3345 +the nexthop of a multipath route.
3347 +is a complex value with its own syntax similar to the top level
3352 +- is the nexthop router.
3356 +- is the output device.
3359 +.BI weight " NUMBER"
3360 +- is a weight for this element of a multipath
3361 +route reflecting its relative bandwidth or quality.
3365 +.BI scope " SCOPE_VAL"
3366 +the scope of the destinations covered by the route prefix.
3368 +may be a number or a string from the file
3369 +.BR "/etc/iproute2/rt_scopes" .
3370 +If this parameter is omitted,
3379 +.BR unicast " and " broadcast
3381 +.BR host " for " local
3385 +.BI protocol " RTPROTO"
3386 +the routing protocol identifier of this route.
3388 +may be a number or a string from the file
3389 +.BR "/etc/iproute2/rt_protos" .
3390 +If the routing protocol ID is not given,
3391 +.B ip assumes protocol
3393 +(i.e. it assumes the route was added by someone who doesn't
3394 +understand what they are doing). Several protocol values have
3395 +a fixed interpretation.
3400 +- the route was installed due to an ICMP redirect.
3404 +- the route was installed by the kernel during autoconfiguration.
3408 +- the route was installed during the bootup sequence.
3409 +If a routing daemon starts, it will purge all of them.
3413 +- the route was installed by the administrator
3414 +to override dynamic routing. Routing daemon will respect them
3415 +and, probably, even advertise them to its peers.
3419 +- the route was installed by Router Discovery protocol.
3423 +The rest of the values are not reserved and the administrator is free
3424 +to assign (or not to assign) protocol tags.
3428 +pretend that the nexthop is directly attached to this link,
3429 +even if it does not match any interface prefix.
3433 +allow packet by packet randomization on multipath routes.
3434 +Without this modifier, the route will be frozen to one selected
3435 +nexthop, so that load splitting will only occur on per-flow base.
3437 +only works if the kernel is patched.
3439 +.SS ip route delete - delete route
3442 +has the same arguments as
3443 +.BR "ip route add" ,
3444 +but their semantics are a bit different.
3447 +.RB "(" to ", " tos ", " preference " and " table ")"
3448 +select the route to delete. If optional attributes are present,
3450 +verifies that they coincide with the attributes of the route to delete.
3451 +If no route with the given key and attributes was found,
3455 +.SS ip route show - list routes
3456 +the command displays the contents of the routing tables or the route(s)
3457 +selected by some criteria.
3460 +.BI to " SELECTOR " (default)
3461 +only select routes from the given range of destinations.
3463 +consists of an optional modifier
3464 +.RB "(" root ", " match " or " exact ")"
3467 +selects routes with prefixes not shorter than
3471 +selects the entire routing table.
3472 +.BI match " PREFIX"
3473 +selects routes with prefixes not longer than
3476 +.BI match " 10.0/16"
3479 +.IR 10/8 " and " 0/0 ,
3480 +but it does not select
3481 +.IR 10.1/16 " and " 10.0.0/24 .
3483 +.BI exact " PREFIX"
3486 +selects routes with this exact prefix. If neither of these options
3491 +i.e. it lists the entire table.
3496 +only select routes with the given TOS.
3499 +.BI table " TABLEID"
3500 +show the routes from this table(s). The default setting is to show
3503 +may either be the ID of a real table or one of the special values:
3507 +- list all of the tables.
3510 +- dump the routing cache.
3517 +list cloned routes i.e. routes which were dynamically forked from
3518 +other routes because some route attribute (f.e. MTU) was updated.
3519 +Actually, it is equivalent to
3520 +.BR "table cache" "."
3523 +.BI from " SELECTOR"
3524 +the same syntax as for
3526 +but it binds the source address range rather than destinations.
3529 +option only works with cloned routes.
3532 +.BI protocol " RTPROTO"
3533 +only list routes of this protocol.
3536 +.BI scope " SCOPE_VAL"
3537 +only list routes with this scope.
3541 +only list routes of this type.
3545 +only list routes going via this device.
3549 +only list routes going via the nexthop routers selected by
3554 +only list routes with preferred source addresses selected
3559 +.BI realm " REALMID"
3561 +.BI realms " FROMREALM/TOREALM"
3562 +only list routes with these realms.
3564 +.SS ip route flush - flush routing tables
3565 +this command flushes routes selected by some criteria.
3568 +The arguments have the same syntax and semantics as the arguments of
3569 +.BR "ip route show" ,
3570 +but routing tables are not listed but purged. The only difference is
3571 +the default action:
3573 +dumps all the IP main routing table but
3575 +prints the helper page.
3580 +option, the command becomes verbose. It prints out the number of
3581 +deleted routes and the number of rounds made to flush the routing
3582 +table. If the option is given
3585 +also dumps all the deleted routes in the format described in the
3586 +previous subsection.
3588 +.SS ip route get - get a single route
3589 +this command gets a single route to a destination and prints its
3590 +contents exactly as the kernel sees it.
3593 +.BI to " ADDRESS " (default)
3594 +the destination address.
3597 +.BI from " ADDRESS"
3598 +the source address.
3604 +the Type Of Service.
3608 +the device from which this packet is expected to arrive.
3612 +force the output device on which this packet will be routed.
3616 +if no source address
3617 +.RB "(option " from ")"
3618 +was given, relookup the route with the source set to the preferred
3619 +address received from the first lookup.
3620 +If policy routing is used, it may be a different route.
3623 +Note that this operation is not equivalent to
3624 +.BR "ip route show" .
3626 +shows existing routes.
3628 +resolves them and creates new clones if necessary. Essentially,
3630 +is equivalent to sending a packet along this path.
3633 +argument is not given, the kernel creates a route
3634 +to output packets towards the requested destination.
3635 +This is equivalent to pinging the destination
3637 +.BR "ip route ls cache" ,
3638 +however, no packets are actually sent. With the
3640 +argument, the kernel pretends that a packet arrived from this interface
3641 +and searches for a path to forward the packet.
3643 +.SH ip rule - routing policy database management
3646 +in the routing policy database control the route selection algorithm.
3649 +Classic routing algorithms used in the Internet make routing decisions
3650 +based only on the destination address of packets (and in theory,
3651 +but not in practice, on the TOS field).
3654 +In some circumstances we want to route packets differently depending not only
3655 +on destination addresses, but also on other packet fields: source address,
3656 +IP protocol, transport protocol ports or even packet payload.
3657 +This task is called 'policy routing'.
3660 +To solve this task, the conventional destination based routing table, ordered
3661 +according to the longest match rule, is replaced with a 'routing policy
3662 +database' (or RPDB), which selects routes by executing some set of rules.
3665 +Each policy routing rule consists of a
3668 +.B action predicate.
3669 +The RPDB is scanned in the order of increasing priority. The selector
3670 +of each rule is applied to {source address, destination address, incoming
3671 +interface, tos, fwmark} and, if the selector matches the packet,
3672 +the action is performed. The action predicate may return with success.
3673 +In this case, it will either give a route or failure indication
3674 +and the RPDB lookup is terminated. Otherwise, the RPDB program
3675 +continues on the next rule.
3678 +Semantically, natural action is to select the nexthop and the output device.
3681 +At startup time the kernel configures the default RPDB consisting of three
3686 +Priority: 0, Selector: match anything, Action: lookup routing
3692 +table is a special routing table containing
3693 +high priority control routes for local and broadcast addresses.
3695 +Rule 0 is special. It cannot be deleted or overridden.
3699 +Priority: 32766, Selector: match anything, Action: lookup routing
3705 +table is the normal routing table containing all non-policy
3706 +routes. This rule may be deleted and/or overridden with other
3707 +ones by the administrator.
3711 +Priority: 32767, Selector: match anything, Action: lookup routing
3717 +table is empty. It is reserved for some post-processing if no previous
3718 +default rules selected the packet.
3719 +This rule may also be deleted.
3722 +Each RPDB entry has additional
3723 +attributes. F.e. each rule has a pointer to some routing
3724 +table. NAT and masquerading rules have an attribute to select new IP
3725 +address to translate/masquerade. Besides that, rules have some
3726 +optional attributes, which routes have, namely
3728 +These values do not override those contained in the routing tables. They
3729 +are only used if the route did not select any attributes.
3732 +The RPDB may contain rules of the following types:
3736 +- the rule prescribes to return the route found
3737 +in the routing table referenced by the rule.
3740 +- the rule prescribes to silently drop the packet.
3743 +- the rule prescribes to generate a 'Network is unreachable' error.
3746 +- the rule prescribes to generate 'Communication is administratively
3750 +- the rule prescribes to translate the source address
3751 +of the IP packet into some other value.
3754 +.SS ip rule add - insert a new rule
3755 +.SS ip rule delete - delete a rule
3758 +.BI type " TYPE " (default)
3759 +the type of this rule. The list of valid types was given in the previous
3764 +select the source prefix to match.
3768 +select the destination prefix to match.
3772 +select the incoming device to match. If the interface is loopback,
3773 +the rule only matches packets originating from this host. This means
3774 +that you may create separate routing tables for forwarded and local
3775 +packets and, hence, completely segregate them.
3781 +select the TOS value to match.
3790 +.BI priority " PREFERENCE"
3791 +the priority of this rule. Each rule should have an explicitly
3797 +.BI table " TABLEID"
3798 +the routing table identifier to lookup if the rule selector matches.
3801 +.BI realms " FROM/TO"
3802 +Realms to select if the rule matched and the routing table lookup
3805 +is only used if the route did not select any realm.
3809 +The base of the IP address block to translate (for source addresses).
3812 +may be either the start of the block of NAT addresses (selected by NAT
3813 +routes) or a local host address (or even zero).
3814 +In the last case the router does not translate the packets, but
3815 +masquerades them to this address.
3818 +Changes to the RPDB made with these commands do not become active
3819 +immediately. It is assumed that after a script finishes a batch of
3820 +updates, it flushes the routing cache with
3821 +.BR "ip route flush cache" .
3823 +.SS ip rule show - list rules
3824 +This command has no arguments.
3826 +.SH ip maddress - multicast addresses management
3829 +objects are multicast addresses.
3831 +.SS ip maddress show - list multicast addresses
3834 +.BI dev " NAME " (default)
3837 +.SS ip maddress add - add a multicast address
3838 +.SS ip maddress delete - delete a multicast address
3839 +these commands attach/detach a static link layer multicast address
3840 +to listen on the interface.
3841 +Note that it is impossible to join protocol multicast groups
3842 +statically. This command only manages link layer addresses.
3845 +.BI address " LLADDRESS " (default)
3846 +the link layer multicast address.
3850 +the device to join/leave this multicast address.
3852 +.SH ip mroute - multicast routing cache management
3854 +objects are multicast routing cache entries created by a user level
3855 +mrouting daemon (f.e.
3861 +Due to the limitations of the current interface to the multicast routing
3862 +engine, it is impossible to change
3864 +objects administratively, so we may only display them. This limitation
3865 +will be removed in the future.
3867 +.SS ip mroute show - list mroute cache entries
3870 +.BI to " PREFIX " (default)
3871 +the prefix selecting the destination multicast addresses to list.
3875 +the interface on which multicast packets are received.
3879 +the prefix selecting the IP source addresses of the multicast route.
3881 +.SH ip tunnel - tunnel configuration
3883 +objects are tunnels, encapsulating packets in IPv4 packets and then
3884 +sending them over the IP infrastructure.
3886 +.SS ip tunnel add - add a new tunnel
3887 +.SS ip tunnel change - change an existing tunnel
3888 +.SS ip tunnel delete - destroy a tunnel
3891 +.BI name " NAME " (default)
3892 +select the tunnel device name.
3896 +set the tunnel mode. Three modes are currently available:
3897 +.BR ipip ", " sit " and " gre "."
3900 +.BI remote " ADDRESS"
3901 +set the remote endpoint of the tunnel.
3904 +.BI local " ADDRESS"
3905 +set the fixed local address for tunneled packets.
3906 +It must be an address on another interface of this host.
3912 +on tunneled packets.
3914 +is a number in the range 1--255. 0 is a special value
3915 +meaning that packets inherit the TTL value.
3916 +The default value is:
3925 +on tunneled packets.
3926 +The default value is:
3931 +bind the tunnel to the device
3933 +so that tunneled packets will only be routed via this device and will
3934 +not be able to escape to another device when the route to endpoint
3939 +disable Path MTU Discovery on this tunnel.
3940 +It is enabled by default. Note that a fixed ttl is incompatible
3941 +with this option: tunnelling with a fixed ttl always makes pmtu
3950 +.RB ( " only GRE tunnels " )
3951 +use keyed GRE with key
3953 +is either a number or an IP address-like dotted quad.
3956 +parameter sets the key to use in both directions.
3958 +.BR ikey " and " okey
3959 +parameters set different keys for input and output.
3962 +.BR csum ", " icsum ", " ocsum
3963 +.RB ( " only GRE tunnels " )
3964 +generate/require checksums for tunneled packets.
3967 +flag calculates checksums for outgoing packets.
3970 +flag requires that all input packets have the correct
3973 +flag is equivalent to the combination
3974 +.BR "icsum ocsum" .
3977 +.BR seq ", " iseq ", " oseq
3978 +.RB ( " only GRE tunnels " )
3982 +flag enables sequencing of outgoing packets.
3985 +flag requires that all input packets are serialized.
3988 +flag is equivalent to the combination
3990 +.B It isn't work. Don't use it.
3992 +.SS ip tunnel show - list tunnels
3993 +This command has no arguments.
3995 +.SH ip monitor and rtmon - state monitoring
3999 +utility can monitor the state of devices, addresses
4000 +and routes continuously. This option has a slightly different format.
4003 +command is the first in the command line and then the object list follows:
4005 +.BR "ip monitor" " [ " all " |"
4006 +.IR LISTofOBJECTS " ]"
4009 +is the list of object types that we want to monitor.
4011 +.BR link ", " address " and " route "."
4016 +opens RTNETLINK, listens on it and dumps state changes in the format
4017 +described in previous sections.
4020 +If a file name is given, it does not listen on RTNETLINK,
4021 +but opens the file containing RTNETLINK messages saved in binary format
4022 +and dumps them. Such a history file can be generated with the
4024 +utility. This utility has a command line syntax similar to
4028 +should be started before the first network configuration command
4029 +is issued. F.e. if you insert:
4032 +rtmon file /var/log/rtmon.log
4035 +in a startup script, you will be able to view the full history
4039 +Certainly, it is possible to start
4042 +It prepends the history with the state snapshot dumped at the moment
4048 +was written by Alexey N. Kuznetsov and added in Linux 2.2.
4052 +.RB "IP Command reference " ip-cref.ps
4054 +.RB "IP tunnels " ip-cref.ps
4058 +Manpage maintained by Michail Litvak <mci@owl.openwall.com>
4059 diff -Naur iproute2-orig/debian/manpages/old/tc-cbq-details.8 iproute2/debian/manpages/old/tc-cbq-details.8
4060 --- iproute2-orig/debian/manpages/old/tc-cbq-details.8 1969-12-31 16:00:00.000000000 -0800
4061 +++ iproute2/debian/manpages/old/tc-cbq-details.8 2004-05-21 00:09:38.000000000 -0700
4063 +.TH CBQ 8 "8 December 2001" "iproute2" "Linux"
4065 +CBQ \- Class Based Queueing
4067 +.B tc qdisc ... dev
4071 +.B | root) [ handle
4085 +.B tc class ... dev
4113 +.B ] [ bounded isolated ] [ split
4118 +interval timeconstant
4122 +Class Based Queueing is a classful qdisc that implements a rich
4123 +linksharing hierarchy of classes. It contains shaping elements as
4124 +well as prioritizing capabilities. Shaping is performed using link
4125 +idle time calculations based on the timing of dequeue events and
4126 +underlying link bandwidth.
4128 +.SH SHAPING ALGORITHM
4129 +Shaping is done using link idle time calculations, and actions taken if
4130 +these calculations deviate from set limits.
4132 +When shaping a 10mbit/s connection to 1mbit/s, the link will
4133 +be idle 90% of the time. If it isn't, it needs to be throttled so that it
4134 +IS idle 90% of the time.
4136 +From the kernel's perspective, this is hard to measure, so CBQ instead
4137 +derives the idle time from the number of microseconds (in fact, jiffies)
4138 +that elapse between requests from the device driver for more data. Combined
4139 +with the knowledge of packet sizes, this is used to approximate how full or
4142 +This is rather circumspect and doesn't always arrive at proper
4143 +results. For example, what is the actual link speed of an interface
4144 +that is not really able to transmit the full 100mbit/s of data,
4145 +perhaps because of a badly implemented driver? A PCMCIA network card
4146 +will also never achieve 100mbit/s because of the way the bus is
4147 +designed - again, how do we calculate the idle time?
4149 +The physical link bandwidth may be ill defined in case of not-quite-real
4150 +network devices like PPP over Ethernet or PPTP over TCP/IP. The effective
4151 +bandwidth in that case is probably determined by the efficiency of pipes
4152 +to userspace - which not defined.
4154 +During operations, the effective idletime is measured using an
4155 +exponential weighted moving average (EWMA), which considers recent
4156 +packets to be exponentially more important than past ones. The Unix
4157 +loadaverage is calculated in the same way.
4159 +The calculated idle time is subtracted from the EWMA measured one,
4160 +the resulting number is called 'avgidle'. A perfectly loaded link has
4161 +an avgidle of zero: packets arrive exactly at the calculated
4164 +An overloaded link has a negative avgidle and if it gets too negative,
4165 +CBQ throttles and is then 'overlimit'.
4167 +Conversely, an idle link might amass a huge avgidle, which would then
4168 +allow infinite bandwidths after a few hours of silence. To prevent
4169 +this, avgidle is capped at
4172 +If overlimit, in theory, the CBQ could throttle itself for exactly the
4173 +amount of time that was calculated to pass between packets, and then
4174 +pass one packet, and throttle again. Due to timer resolution constraints,
4175 +this may not be feasible, see the
4180 +Within the one CBQ instance many classes may exist. Each of these classes
4181 +contains another qdisc, by default
4184 +When enqueueing a packet, CBQ starts at the root and uses various methods to
4185 +determine which class should receive the data. If a verdict is reached, this
4186 +process is repeated for the recipient class which might have further
4187 +means of classifying traffic to its children, if any.
4189 +CBQ has the following methods available to classify a packet to any child
4193 +.B skb->priority class encoding.
4194 +Can be set from userspace by an application with the
4198 +.B skb->priority class encoding
4199 +only applies if the skb->priority holds a major:minor handle of an existing
4200 +class within this qdisc.
4203 +tc filters attached to the class.
4206 +The defmap of a class, as set with the
4208 +parameters. The defmap may contain instructions for each possible Linux packet
4212 +Each class also has a
4214 +Leaf nodes, attached to the bottom of the class hierarchy, have a level of 0.
4215 +.SH CLASSIFICATION ALGORITHM
4217 +Classification is a loop, which terminates when a leaf class is found. At any
4218 +point the loop may jump to the fallback algorithm.
4220 +The loop consists of the following steps:
4223 +If the packet is generated locally and has a valid classid encoded within its
4225 +choose it and terminate.
4229 +Consult the tc filters, if any, attached to this child. If these return
4230 +a class which is not a leaf class, restart loop from the class returned.
4231 +If it is a leaf, choose it and terminate.
4234 +If the tc filters did not return a class, but did return a classid,
4235 +try to find a class with that id within this qdisc.
4236 +Check if the found class is of a lower
4238 +than the current class. If so, and the returned class is not a leaf node,
4239 +restart the loop at the found class. If it is a leaf node, terminate.
4240 +If we found an upward reference to a higher level, enter the fallback
4244 +If the tc filters did not return a class, nor a valid reference to one,
4245 +consider the minor number of the reference to be the priority. Retrieve
4246 +a class from the defmap of this class for the priority. If this did not
4247 +contain a class, consult the defmap of this class for the
4249 +class. If this is an upward reference, or no
4252 +enter the fallback algorithm. If a valid class was found, and it is not a
4253 +leaf node, restart the loop at this class. If it is a leaf, choose it and
4255 +neither the priority distilled from the classid, nor the
4257 +priority yielded a class, enter the fallback algorithm.
4259 +The fallback algorithm resides outside of the loop and is as follows.
4262 +Consult the defmap of the class at which the jump to fallback occured. If
4263 +the defmap contains a class for the
4266 +of the class (which is related to the TOS field), choose this class and
4270 +Consult the map for a class for the
4272 +priority. If found, choose it, and terminate.
4275 +Choose the class at which break out to the fallback algorithm occured. Terminate.
4277 +The packet is enqueued to the class which was chosen when either algorithm
4278 +terminated. It is therefore possible for a packet to be enqueued *not* at a
4279 +leaf node, but in the middle of the hierarchy.
4281 +.SH LINK SHARING ALGORITHM
4282 +When dequeuing for sending to the network device, CBQ decides which of its
4283 +classes will be allowed to send. It does so with a Weighted Round Robin process
4284 +in which each class with packets gets a chance to send in turn. The WRR process
4285 +starts by asking the highest priority classes (lowest numerically -
4286 +highest semantically) for packets, and will continue to do so until they
4287 +have no more data to offer, in which case the process repeats for lower
4290 +.B CERTAINTY ENDS HERE, ANK PLEASE HELP
4292 +Each class is not allowed to send at length though - they can only dequeue a
4293 +configurable amount of data during each round.
4295 +If a class is about to go overlimit, and it is not
4297 +it will try to borrow avgidle from siblings that are not
4299 +This process is repeated from the bottom upwards. If a class is unable
4300 +to borrow enough avgidle to send a packet, it is throttled and not asked
4301 +for a packet for enough time for the avgidle to increase above zero.
4303 +.B I REALLY NEED HELP FIGURING THIS OUT. REST OF DOCUMENT IS PRETTY CERTAIN
4307 +The root qdisc of a CBQ class tree has the following parameters:
4310 +parent major:minor | root
4311 +This mandatory parameter determines the place of the CBQ instance, either at the
4313 +of an interface or within an existing class.
4316 +Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
4317 +of a major number, followed by a colon. Optional.
4320 +For calculations, the average packet size must be known. It is silently capped
4321 +at a minimum of 2/3 of the interface MTU. Mandatory.
4324 +To determine the idle time, CBQ must know the bandwidth of your underlying
4325 +physical interface, or parent qdisc. This is a vital parameter, more about it
4329 +The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
4332 +A zero sized packet may still take time to transmit. This value is the lower
4333 +cap for packet transmission time calculations - packets smaller than this value
4334 +are still deemed to have this size. Defaults to zero.
4337 +When CBQ needs to measure the average idle time, it does so using an
4338 +Exponentially Weighted Moving Average which smoothes out measurements into
4339 +a moving average. The EWMA LOG determines how much smoothing occurs. Defaults
4340 +to 5. Lower values imply greater sensitivity. Must be between 0 and 31.
4342 +A CBQ qdisc does not shape out of its own accord. It only needs to know certain
4343 +parameters about the underlying link. Actual shaping is done in classes.
4346 +Classes have a host of parameters to configure their operation.
4350 +Place of this class within the hierarchy. If attached directly to a qdisc
4351 +and not to another class, minor can be omitted. Mandatory.
4353 +classid major:minor
4354 +Like qdiscs, classes can be named. The major number must be equal to the
4355 +major number of the qdisc to which it belongs. Optional, but needed if this
4356 +class is going to have children.
4359 +When dequeuing to the interface, classes are tried for traffic in a
4360 +round-robin fashion. Classes with a higher configured qdisc will generally
4361 +have more traffic to offer during each round, so it makes sense to allow
4362 +it to dequeue more traffic. All weights under a class are normalized, so
4363 +only the ratios matter. Defaults to the configured rate, unless the priority
4364 +of this class is maximal, in which case it is set to 1.
4367 +Allot specifies how many bytes a qdisc can dequeue
4368 +during each round of the process. This parameter is weighted using the
4369 +renormalized class weight described above.
4373 +In the round-robin process, classes with the lowest priority field are tried
4374 +for packets first. Mandatory.
4378 +Maximum rate this class and all its children combined can send at. Mandatory.
4382 +This is different from the bandwidth specified when creating a CBQ disc. Only
4383 +used to determine maxidle and offtime, which are only calculated when
4384 +specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
4388 +This number of packets is used to calculate maxidle so that when
4389 +avgidle is at maxidle, this number of average packets can be burst
4390 +before avgidle drops to 0. Set it higher to be more tolerant of
4391 +bursts. You can't set maxidle directly, only via this parameter.
4395 +As mentioned before, CBQ needs to throttle in case of
4396 +overlimit. The ideal solution is to do so for exactly the calculated
4397 +idle time, and pass 1 packet. However, Unix kernels generally have a
4398 +hard time scheduling events shorter than 10ms, so it is better to
4399 +throttle for a longer period, and then pass minburst packets in one
4400 +go, and then sleep minburst times longer.
4402 +The time to wait is called the offtime. Higher values of minburst lead
4403 +to more accurate shaping in the long term, but to bigger bursts at
4404 +millisecond timescales.
4408 +If avgidle is below 0, we are overlimits and need to wait until
4409 +avgidle will be big enough to send one packet. To prevent a sudden
4410 +burst from shutting down the link for a prolonged period of time,
4411 +avgidle is reset to minidle if it gets too low.
4413 +Minidle is specified in negative microseconds, so 10 means that
4414 +avgidle is capped at -10us.
4418 +Signifies that this class will not borrow bandwidth from its siblings.
4421 +Means that this class will not borrow bandwidth to its siblings
4424 +split major:minor & defmap bitmap[/bitmap]
4425 +If consulting filters attached to a class did not give a verdict,
4426 +CBQ can also classify based on the packet's priority. There are 16
4427 +priorities available, numbered from 0 to 15.
4429 +The defmap specifies which priorities this class wants to receive,
4430 +specified as a bitmap. The Least Significant Bit corresponds to priority
4433 +parameter tells CBQ at which class the decision must be made, which should
4434 +be a (grand)parent of the class you are adding.
4436 +As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
4437 +configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
4439 +The complimentary configuration would then
4440 +be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
4441 +Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
4443 +estimator interval timeconstant
4444 +CBQ can measure how much bandwidth each class is using, which tc filters
4445 +can use to classify packets with. In order to determine the bandwidth
4446 +it uses a very simple estimator that measures once every
4448 +microseconds how much traffic has passed. This again is a EWMA, for which
4449 +the time constant can be specified, also in microseconds. The
4451 +corresponds to the sluggishness of the measurement or, conversely, to the
4452 +sensitivity of the average to short bursts. Higher values mean less
4460 +Sally Floyd and Van Jacobson, "Link-sharing and Resource
4461 +Management Models for Packet Networks",
4462 +IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
4466 +Sally Floyd, "Notes on CBQ and Guarantee Service", 1995
4470 +Sally Floyd, "Notes on Class-Based Queueing: Setting
4475 +Sally Floyd and Michael Speer, "Experimental Results
4476 +for Class-Based Queueing", 1998, not published.
4484 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
4485 +bert hubert <ahu@ds9a.nl>
4488 diff -Naur iproute2-orig/debian/manpages/old/tc-cbq.8 iproute2/debian/manpages/old/tc-cbq.8
4489 --- iproute2-orig/debian/manpages/old/tc-cbq.8 1969-12-31 16:00:00.000000000 -0800
4490 +++ iproute2/debian/manpages/old/tc-cbq.8 2004-05-21 00:09:38.000000000 -0700
4492 +.TH CBQ 8 "16 December 2001" "iproute2" "Linux"
4494 +CBQ \- Class Based Queueing
4496 +.B tc qdisc ... dev
4500 +.B | root) [ handle
4516 +.B tc class ... dev
4544 +.B ] [ bounded isolated ] [ split
4549 +interval timeconstant
4553 +Class Based Queueing is a classful qdisc that implements a rich
4554 +linksharing hierarchy of classes. It contains shaping elements as
4555 +well as prioritizing capabilities. Shaping is performed using link
4556 +idle time calculations based on the timing of dequeue events and
4557 +underlying link bandwidth.
4559 +.SH SHAPING ALGORITHM
4560 +When shaping a 10mbit/s connection to 1mbit/s, the link will
4561 +be idle 90% of the time. If it isn't, it needs to be throttled so that it
4562 +IS idle 90% of the time.
4564 +During operations, the effective idletime is measured using an
4565 +exponential weighted moving average (EWMA), which considers recent
4566 +packets to be exponentially more important than past ones. The Unix
4567 +loadaverage is calculated in the same way.
4569 +The calculated idle time is subtracted from the EWMA measured one,
4570 +the resulting number is called 'avgidle'. A perfectly loaded link has
4571 +an avgidle of zero: packets arrive exactly at the calculated
4574 +An overloaded link has a negative avgidle and if it gets too negative,
4575 +CBQ throttles and is then 'overlimit'.
4577 +Conversely, an idle link might amass a huge avgidle, which would then
4578 +allow infinite bandwidths after a few hours of silence. To prevent
4579 +this, avgidle is capped at
4582 +If overlimit, in theory, the CBQ could throttle itself for exactly the
4583 +amount of time that was calculated to pass between packets, and then
4584 +pass one packet, and throttle again. Due to timer resolution constraints,
4585 +this may not be feasible, see the
4590 +Within the one CBQ instance many classes may exist. Each of these classes
4591 +contains another qdisc, by default
4594 +When enqueueing a packet, CBQ starts at the root and uses various methods to
4595 +determine which class should receive the data.
4597 +In the absence of uncommon configuration options, the process is rather easy.
4598 +At each node we look for an instruction, and then go to the class the
4599 +instruction refers us to. If the class found is a barren leaf-node (without
4600 +children), we enqueue the packet there. If it is not yet a leaf node, we do
4601 +the whole thing over again starting from that node.
4603 +The following actions are performed, in order at each node we visit, until one
4604 +sends us to another node, or terminates the process.
4607 +Consult filters attached to the class. If sent to a leafnode, we are done.
4608 +Otherwise, restart.
4611 +Consult the defmap for the priority assigned to this packet, which depends
4612 +on the TOS bits. Check if the referral is leafless, otherwise restart.
4615 +Ask the defmap for instructions for the 'best effort' priority. Check the
4616 +answer for leafness, otherwise restart.
4619 +If none of the above returned with an instruction, enqueue at this node.
4621 +This algorithm makes sure that a packet always ends up somewhere, even while
4622 +you are busy building your configuration.
4624 +For more details, see
4625 +.BR tc-cbq-details(8).
4627 +.SH LINK SHARING ALGORITHM
4628 +When dequeuing for sending to the network device, CBQ decides which of its
4629 +classes will be allowed to send. It does so with a Weighted Round Robin process
4630 +in which each class with packets gets a chance to send in turn. The WRR process
4631 +starts by asking the highest priority classes (lowest numerically -
4632 +highest semantically) for packets, and will continue to do so until they
4633 +have no more data to offer, in which case the process repeats for lower
4636 +Classes by default borrow bandwidth from their siblings. A class can be
4637 +prevented from doing so by declaring it 'bounded'. A class can also indicate
4638 +its unwillingness to lend out bandwidth by being 'isolated'.
4641 +The root of a CBQ qdisc class tree has the following parameters:
4644 +parent major:minor | root
4645 +This mandatory parameter determines the place of the CBQ instance, either at the
4647 +of an interface or within an existing class.
4650 +Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
4651 +of a major number, followed by a colon. Optional, but very useful if classes
4652 +will be generated within this qdisc.
4655 +This allotment is the 'chunkiness' of link sharing and is used for determining packet
4656 +transmission time tables. The qdisc allot differs slightly from the class allot discussed
4657 +below. Optional. Defaults to a reasonable value, related to avpkt.
4660 +The average size of a packet is needed for calculating maxidle, and is also used
4661 +for making sure 'allot' has a safe value. Mandatory.
4664 +To determine the idle time, CBQ must know the bandwidth of your underlying
4665 +physical interface, or parent qdisc. This is a vital parameter, more about it
4669 +The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
4672 +A zero sized packet may still take time to transmit. This value is the lower
4673 +cap for packet transmission time calculations - packets smaller than this value
4674 +are still deemed to have this size. Defaults to zero.
4677 +When CBQ needs to measure the average idle time, it does so using an
4678 +Exponentially Weighted Moving Average which smoothes out measurements into
4679 +a moving average. The EWMA LOG determines how much smoothing occurs. Lower
4680 +values imply greater sensitivity. Must be between 0 and 31. Defaults
4683 +A CBQ qdisc does not shape out of its own accord. It only needs to know certain
4684 +parameters about the underlying link. Actual shaping is done in classes.
4687 +Classes have a host of parameters to configure their operation.
4691 +Place of this class within the hierarchy. If attached directly to a qdisc
4692 +and not to another class, minor can be omitted. Mandatory.
4694 +classid major:minor
4695 +Like qdiscs, classes can be named. The major number must be equal to the
4696 +major number of the qdisc to which it belongs. Optional, but needed if this
4697 +class is going to have children.
4700 +When dequeuing to the interface, classes are tried for traffic in a
4701 +round-robin fashion. Classes with a higher configured qdisc will generally
4702 +have more traffic to offer during each round, so it makes sense to allow
4703 +it to dequeue more traffic. All weights under a class are normalized, so
4704 +only the ratios matter. Defaults to the configured rate, unless the priority
4705 +of this class is maximal, in which case it is set to 1.
4708 +Allot specifies how many bytes a qdisc can dequeue
4709 +during each round of the process. This parameter is weighted using the
4710 +renormalized class weight described above. Silently capped at a minimum of
4711 +3/2 avpkt. Mandatory.
4715 +In the round-robin process, classes with the lowest priority field are tried
4716 +for packets first. Mandatory.
4720 +See the QDISC section.
4724 +Maximum rate this class and all its children combined can send at. Mandatory.
4728 +This is different from the bandwidth specified when creating a CBQ disc! Only
4729 +used to determine maxidle and offtime, which are only calculated when
4730 +specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
4734 +This number of packets is used to calculate maxidle so that when
4735 +avgidle is at maxidle, this number of average packets can be burst
4736 +before avgidle drops to 0. Set it higher to be more tolerant of
4737 +bursts. You can't set maxidle directly, only via this parameter.
4741 +As mentioned before, CBQ needs to throttle in case of
4742 +overlimit. The ideal solution is to do so for exactly the calculated
4743 +idle time, and pass 1 packet. However, Unix kernels generally have a
4744 +hard time scheduling events shorter than 10ms, so it is better to
4745 +throttle for a longer period, and then pass minburst packets in one
4746 +go, and then sleep minburst times longer.
4748 +The time to wait is called the offtime. Higher values of minburst lead
4749 +to more accurate shaping in the long term, but to bigger bursts at
4750 +millisecond timescales. Optional.
4754 +If avgidle is below 0, we are overlimits and need to wait until
4755 +avgidle will be big enough to send one packet. To prevent a sudden
4756 +burst from shutting down the link for a prolonged period of time,
4757 +avgidle is reset to minidle if it gets too low.
4759 +Minidle is specified in negative microseconds, so 10 means that
4760 +avgidle is capped at -10us. Optional.
4764 +Signifies that this class will not borrow bandwidth from its siblings.
4767 +Means that this class will not borrow bandwidth to its siblings
4770 +split major:minor & defmap bitmap[/bitmap]
4771 +If consulting filters attached to a class did not give a verdict,
4772 +CBQ can also classify based on the packet's priority. There are 16
4773 +priorities available, numbered from 0 to 15.
4775 +The defmap specifies which priorities this class wants to receive,
4776 +specified as a bitmap. The Least Significant Bit corresponds to priority
4779 +parameter tells CBQ at which class the decision must be made, which should
4780 +be a (grand)parent of the class you are adding.
4782 +As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
4783 +configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
4785 +The complimentary configuration would then
4786 +be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
4787 +Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
4789 +estimator interval timeconstant
4790 +CBQ can measure how much bandwidth each class is using, which tc filters
4791 +can use to classify packets with. In order to determine the bandwidth
4792 +it uses a very simple estimator that measures once every
4794 +microseconds how much traffic has passed. This again is a EWMA, for which
4795 +the time constant can be specified, also in microseconds. The
4797 +corresponds to the sluggishness of the measurement or, conversely, to the
4798 +sensitivity of the average to short bursts. Higher values mean less
4802 +The actual bandwidth of the underlying link may not be known, for example
4803 +in the case of PPoE or PPTP connections which in fact may send over a
4804 +pipe, instead of over a physical device. CBQ is quite resilient to major
4805 +errors in the configured bandwidth, probably a the cost of coarser shaping.
4807 +Default kernels rely on coarse timing information for making decisions. These
4808 +may make shaping precise in the long term, but inaccurate on second long scales.
4811 +.BR tc-cbq-details(8)
4812 +for hints on how to improve this.
4817 +Sally Floyd and Van Jacobson, "Link-sharing and Resource
4818 +Management Models for Packet Networks",
4819 +IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
4823 +Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
4827 +Sally Floyd, "Notes on Class-Based Queueing: Setting
4832 +Sally Floyd and Michael Speer, "Experimental Results
4833 +for Class-Based Queueing", 1998, not published.
4841 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
4842 +bert hubert <ahu@ds9a.nl>
4845 diff -Naur iproute2-orig/debian/manpages/old/tc-htb.8 iproute2/debian/manpages/old/tc-htb.8
4846 --- iproute2-orig/debian/manpages/old/tc-htb.8 1969-12-31 16:00:00.000000000 -0800
4847 +++ iproute2/debian/manpages/old/tc-htb.8 2004-05-21 00:09:38.000000000 -0700
4849 +.TH HTB 8 "10 January 2002" "iproute2" "Linux"
4851 +HTB \- Hierarchy Token Bucket
4853 +.B tc qdisc ... dev
4857 +.B | root) [ handle
4863 +.B tc class ... dev
4882 +HTB is meant as a more understandable and intuitive replacement for
4883 +the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
4884 +of the outbound bandwidth on a given link. Both allow you to use one
4885 +physical link to simulate several slower links and to send different
4886 +kinds of traffic on different simulated links. In both cases, you have
4887 +to specify how to divide the physical link into simulated links and
4888 +how to decide which simulated link to use for a given packet to be sent.
4890 +Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm
4891 +which does not depend on interface characteristics and so does not need to
4892 +know the underlying bandwidth of the outgoing interface.
4894 +.SH SHAPING ALGORITHM
4895 +Shaping works as documented in
4899 +Within the one HRB instance many classes may exist. Each of these classes
4900 +contains another qdisc, by default
4903 +When enqueueing a packet, HTB starts at the root and uses various methods to
4904 +determine which class should receive the data.
4906 +In the absence of uncommon configuration options, the process is rather easy.
4907 +At each node we look for an instruction, and then go to the class the
4908 +instruction refers us to. If the class found is a barren leaf-node (without
4909 +children), we enqueue the packet there. If it is not yet a leaf node, we do
4910 +the whole thing over again starting from that node.
4912 +The following actions are performed, in order at each node we visit, until one
4913 +sends us to another node, or terminates the process.
4916 +Consult filters attached to the class. If sent to a leafnode, we are done.
4917 +Otherwise, restart.
4920 +If none of the above returned with an instruction, enqueue at this node.
4922 +This algorithm makes sure that a packet always ends up somewhere, even while
4923 +you are busy building your configuration.
4925 +.SH LINK SHARING ALGORITHM
4929 +The root of a HTB qdisc class tree has the following parameters:
4932 +parent major:minor | root
4933 +This mandatory parameter determines the place of the HTB instance, either at the
4935 +of an interface or within an existing class.
4938 +Like all other qdiscs, the HTB can be assigned a handle. Should consist only
4939 +of a major number, followed by a colon. Optional, but very useful if classes
4940 +will be generated within this qdisc.
4943 +Unclassified traffic gets sent to the class with this minor-id.
4946 +Classes have a host of parameters to configure their operation.
4950 +Place of this class within the hierarchy. If attached directly to a qdisc
4951 +and not to another class, minor can be omitted. Mandatory.
4953 +classid major:minor
4954 +Like qdiscs, classes can be named. The major number must be equal to the
4955 +major number of the qdisc to which it belongs. Optional, but needed if this
4956 +class is going to have children.
4959 +In the round-robin process, classes with the lowest priority field are tried
4960 +for packets first. Mandatory.
4964 +Maximum rate this class and all its children are guaranteed. Mandatory.
4968 +Maximum rate at which a class can send, if its parent has bandwidth to spare.
4969 +Defaults to the configured rate, which implies no borrowing
4973 +Amount of bytes that can be burst at
4975 +speed, in excess of the configured
4977 +Should be at least as high as the highest burst of all children.
4981 +Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
4982 +as the interface can transmit them. For perfect evening out, should be equal to at most one average
4983 +packet. Should be at least as high as the highest cburst of all children.
4986 +Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel,
4987 +there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
4988 +From this, the mininum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte
4989 +burst as 100*12kb*8 equals 10mbit.
4994 +HTB website: http://luxik.cdi.cz/~devik/qos/htb/
4996 +Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
4999 diff -Naur iproute2-orig/debian/manpages/old/tc-pbfifo.8 iproute2/debian/manpages/old/tc-pbfifo.8
5000 --- iproute2-orig/debian/manpages/old/tc-pbfifo.8 1969-12-31 16:00:00.000000000 -0800
5001 +++ iproute2/debian/manpages/old/tc-pbfifo.8 2004-05-21 00:09:38.000000000 -0700
5003 +.TH PBFIFO 8 "10 January 2002" "iproute2" "Linux"
5005 +pfifo \- Packet limited First In, First Out queue
5007 +bfifo \- Byte limited First In, First Out queue
5010 +.B tc qdisc ... add pfifo
5015 +.B tc qdisc ... add bfifo
5021 +The pfifo and bfifo qdiscs are unadorned First In, First Out queues. They are the
5022 +simplest queues possible and therefore have no overhead.
5024 +constrains the queue size as measured in packets.
5026 +does so as measured in bytes.
5028 +Like all non-default qdiscs, they maintain statistics. This might be a reason to prefer
5029 +pfifo or bfifo over the default.
5032 +A list of packets is maintained, when a packet is enqueued it gets inserted at the tail of
5033 +a list. When a packet needs to be sent out to the network, it is taken from the head of the list.
5035 +If the list is too long, no further packets are allowed on. This is called 'tail drop'.
5040 +Maximum queue size. Specified in bytes for bfifo, in packets for pfifo. For pfifo, defaults
5041 +to the interface txqueuelen, as specified with
5046 +For bfifo, it defaults to the txqueuelen multiplied by the interface MTU.
5051 +contains the limit, either in packets or in bytes, and the number of bytes
5052 +and packets actually sent. An unsent and dropped packet only appears between braces
5053 +and is not counted as 'Sent'.
5055 +In this example, the queue length is 100 packets, 45894 bytes were sent over 681 packets.
5056 +No packets were dropped, and as the pfifo queue does not slow down packets, there were also no
5060 +# tc -s qdisc ls dev eth0
5061 +qdisc pfifo 8001: dev eth0 limit 100p
5062 + Sent 45894 bytes 681 pkts (dropped 0, overlimits 0)
5065 +If a backlog occurs, this is displayed as well.
5070 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
5072 +This manpage maintained by bert hubert <ahu@ds9a.nl>
5075 diff -Naur iproute2-orig/debian/manpages/old/tc-pfifo_fast.8 iproute2/debian/manpages/old/tc-pfifo_fast.8
5076 --- iproute2-orig/debian/manpages/old/tc-pfifo_fast.8 1969-12-31 16:00:00.000000000 -0800
5077 +++ iproute2/debian/manpages/old/tc-pfifo_fast.8 2004-05-21 00:09:38.000000000 -0700
5079 +.TH PFIFO_FAST 8 "10 January 2002" "iproute2" "Linux"
5081 +pfifo_fast \- three-band first in, first out queue
5084 +pfifo_fast is the default qdisc of each interface.
5086 +Whenever an interface is created, the pfifo_fast qdisc is automatically used
5087 +as a queue. If another qdisc is attached, it preempts the default
5088 +pfifo_fast, which automatically returns to function when an existing qdisc
5091 +In this sense this qdisc is magic, and unlike other qdiscs.
5094 +The algorithm is very similar to that of the classful
5100 +queues side by side, where packets can be enqueued in any of the three bands
5101 +based on their Type of Service bits or assigned priority.
5103 +Not all three bands are dequeued simultaneously - as long as lower bands
5104 +have traffic, higher bands are never dequeued. This can be used to
5105 +prioritize interactive traffic or penalize 'lowest cost' traffic.
5107 +Each band can be txqueuelen packets long, as configured with
5111 +Additional packets coming in are not enqueued but are instead dropped.
5115 +for complete details on how TOS bits are translated into bands.
5119 +The length of the three bands depends on the interface txqueuelen, as
5126 +Does not maintain statistics and does not show up in tc qdisc ls. This is because
5127 +it is the automatic default in the absence of a configured qdisc.
5133 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
5135 +This manpage maintained by bert hubert <ahu@ds9a.nl>
5138 diff -Naur iproute2-orig/debian/manpages/old/tc-prio.8 iproute2/debian/manpages/old/tc-prio.8
5139 --- iproute2-orig/debian/manpages/old/tc-prio.8 1969-12-31 16:00:00.000000000 -0800
5140 +++ iproute2/debian/manpages/old/tc-prio.8 2004-05-21 00:09:38.000000000 -0700
5142 +.TH PRIO 8 "16 December 2001" "iproute2" "Linux"
5144 +PRIO \- Priority qdisc
5146 +.B tc qdisc ... dev
5150 +.B | root) [ handle
5157 +interval timeconstant
5161 +The PRIO qdisc is a simple classful queueing discipline that contains
5162 +an arbitrary number of classes of differing priority. The classes are
5163 +dequeued in numerical descending order of priority. PRIO is a scheduler
5164 +and never delays packets - it is a work-conserving qdisc, though the qdiscs
5165 +contained in the classes may not be.
5167 +Very useful for lowering latency when there is no need for slowing down
5171 +On creation with 'tc qdisc add', a fixed number of bands is created. Each
5172 +band is a class, although is not possible to add classes with 'tc qdisc
5173 +add', the number of bands to be created must instead be specified on the
5174 +commandline attaching PRIO to its root.
5176 +When dequeueing, band 0 is tried first and only if it did not deliver a
5177 +packet does PRIO try band 1, and so onwards. Maximum reliability packets
5178 +should therefore go to band 0, minimum delay to band 1 and the rest to band
5181 +As the PRIO qdisc itself will have minor number 0, band 0 is actually
5182 +major:1, band 1 is major:2, etc. For major, substitute the major number
5183 +assigned to the qdisc on 'tc qdisc add' with the
5188 +Three methods are available to PRIO to determine in which band a packet will
5192 +A process with sufficient privileges can encode the destination class
5193 +directly with SO_PRIORITY, see
5197 +A tc filter attached to the root qdisc can point traffic directly to a class
5200 +Based on the packet priority, which in turn is derived from the Type of
5201 +Service assigned to the packet.
5203 +Only the priomap is specific to this qdisc.
5204 +.SH QDISC PARAMETERS
5207 +Number of bands. If changed from the default of 3,
5209 +must be updated as well.
5212 +The priomap maps the priority of
5213 +a packet to a class. The priority can either be set directly from userspace,
5214 +or be derived from the Type of Service of the packet.
5216 +Determines how packet priorities, as assigned by the kernel, map to
5217 +bands. Mapping occurs based on the TOS octet of the packet, which looks like
5222 ++---+---+---+---+---+---+---+---+
5224 +|PRECEDENCE | TOS |MBZ|
5226 ++---+---+---+---+---+---+---+---+
5229 +The four TOS bits (the 'TOS field') are defined as:
5232 +Binary Decimcal Meaning
5233 +-----------------------------------------
5234 +1000 8 Minimize delay (md)
5235 +0100 4 Maximize throughput (mt)
5236 +0010 2 Maximize reliability (mr)
5237 +0001 1 Minimize monetary cost (mmc)
5238 +0000 0 Normal Service
5241 +As there is 1 bit to the right of these four bits, the actual value of the
5242 +TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the
5243 +value of the entire TOS field, not just the four bits. It is the value you
5244 +see in the first column of this table:
5247 +TOS Bits Means Linux Priority Band
5248 +------------------------------------------------------------
5249 +0x0 0 Normal Service 0 Best Effort 1
5250 +0x2 1 Minimize Monetary Cost 1 Filler 2
5251 +0x4 2 Maximize Reliability 0 Best Effort 1
5252 +0x6 3 mmc+mr 0 Best Effort 1
5253 +0x8 4 Maximize Throughput 2 Bulk 2
5254 +0xa 5 mmc+mt 2 Bulk 2
5255 +0xc 6 mr+mt 2 Bulk 2
5256 +0xe 7 mmc+mr+mt 2 Bulk 2
5257 +0x10 8 Minimize Delay 6 Interactive 0
5258 +0x12 9 mmc+md 6 Interactive 0
5259 +0x14 10 mr+md 6 Interactive 0
5260 +0x16 11 mmc+mr+md 6 Interactive 0
5261 +0x18 12 mt+md 4 Int. Bulk 1
5262 +0x1a 13 mmc+mt+md 4 Int. Bulk 1
5263 +0x1c 14 mr+mt+md 4 Int. Bulk 1
5264 +0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1
5267 +The second column contains the value of the relevant
5268 +four TOS bits, followed by their translated meaning. For example, 15 stands
5269 +for a packet wanting Minimal Montetary Cost, Maximum Reliability, Maximum
5270 +Throughput AND Minimum Delay.
5272 +The fourth column lists the way the Linux kernel interprets the TOS bits, by
5273 +showing to which Priority they are mapped.
5275 +The last column shows the result of the default priomap. On the commandline,
5276 +the default priomap looks like this:
5278 + 1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
5280 +This means that priority 4, for example, gets mapped to band number 1.
5281 +The priomap also allows you to list higher priorities (> 7) which do not
5282 +correspond to TOS mappings, but which are set by other means.
5284 +This table from RFC 1349 (read it for more details) explains how
5285 +applications might very well set their TOS bits:
5288 +TELNET 1000 (minimize delay)
5290 + Control 1000 (minimize delay)
5291 + Data 0100 (maximize throughput)
5293 +TFTP 1000 (minimize delay)
5296 + Command phase 1000 (minimize delay)
5297 + DATA phase 0100 (maximize throughput)
5299 +Domain Name Service
5300 + UDP Query 1000 (minimize delay)
5302 + Zone Transfer 0100 (maximize throughput)
5304 +NNTP 0001 (minimize monetary cost)
5308 + Requests 0000 (mostly)
5309 + Responses <same as request> (mostly)
5314 +PRIO classes cannot be configured further - they are automatically created
5315 +when the PRIO qdisc is attached. Each class however can contain yet a
5319 +Large amounts of traffic in the lower bands can cause starvation of higher
5320 +bands. Can be prevented by attaching a shaper (for example,
5322 +to these bands to make sure they cannot dominate the link.
5325 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, J Hadi Salim
5326 +<hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>
5329 diff -Naur iproute2-orig/debian/manpages/old/tc-red.8 iproute2/debian/manpages/old/tc-red.8
5330 --- iproute2-orig/debian/manpages/old/tc-red.8 1969-12-31 16:00:00.000000000 -0800
5331 +++ iproute2/debian/manpages/old/tc-red.8 2004-05-21 00:09:38.000000000 -0700
5333 +.TH RED 8 "13 December 2001" "iproute2" "Linux"
5335 +red \- Random Early Detection
5337 +.B tc qdisc ... red
5348 +.B [ ecn ] [ bandwidth
5354 +Random Early Detection is a classless qdisc which manages its queue size
5355 +smartly. Regular queues simply drop packets from the tail when they are
5356 +full, which may not be the optimal behaviour. RED also performs tail drop,
5357 +but does so in a more gradual way.
5359 +Once the queue hits a certain average length, packets enqueued have a
5360 +configurable chance of being marked (which may mean dropped). This chance
5361 +increases linearly up to a point called the
5363 +average queue length, although the queue might get bigger.
5365 +This has a host of benefits over simple taildrop, while not being processor
5366 +intensive. It prevents synchronous retransmits after a burst in traffic,
5367 +which cause further retransmits, etc.
5369 +The goal is the have a small queue size, which is good for interactivity
5370 +while not disturbing TCP/IP traffic with too many sudden drops after a burst
5373 +Depending on if ECN is configured, marking either means dropping or
5374 +purely marking a packet as overlimit.
5376 +The average queue size is used for determining the marking
5377 +probability. This is calculated using an Exponential Weighted Moving
5378 +Average, which can be more or less sensitive to bursts.
5380 +When the average queue size is below
5382 +bytes, no packet will ever be marked. When it exceeds
5384 +the probability of doing so climbs linearly up
5387 +until the average queue size hits
5391 +is normally not set to 100%, the queue size might
5392 +conceivably rise above
5396 +parameter is provided to set a hard maximum for the size of the queue.
5401 +Average queue size at which marking becomes a possibility.
5404 +At this average queue size, the marking probability is maximal. Should be at
5407 +to prevent synchronous retransmits, higher for low
5411 +Maximum probability for marking, specified as a floating point
5412 +number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
5416 +Hard limit on the real (not average) queue size in bytes. Further packets
5417 +are dropped. Should be set higher than max+burst. It is advised to set this
5418 +a few times higher than
5422 +Used for determining how fast the average queue size is influenced by the
5423 +real queue size. Larger values make the calculation more sluggish, allowing
5424 +longer bursts of traffic before marking starts. Real life experiments
5425 +support the following guideline: (min+min+max)/(3*avpkt).
5428 +Specified in bytes. Used with burst to determine the time constant for
5429 +average queue size calculations. 1000 is a good value.
5432 +This rate is used for calculating the average queue size after some
5433 +idle time. Should be set to the bandwidth of your interface. Does not mean
5434 +that RED will shape for you! Optional.
5437 +As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion
5438 +Notification allows RED to notify remote hosts that their rate exceeds the
5439 +amount of bandwidth available. Non-ECN capable hosts can only be notified by
5440 +dropping a packet. If this parameter is specified, packets which indicate
5441 +that their hosts honor ECN will only be marked and not dropped, unless the
5444 +bytes. Needs a tc binary with RED support compiled in. Recommended.
5452 +Floyd, S., and Jacobson, V., Random Early Detection gateways for
5453 +Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html
5456 +Some changes to the algorithm by Alexey N. Kuznetsov.
5459 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, Alexey Makarenko
5460 +<makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>.
5461 +This manpage maintained by bert hubert <ahu@ds9a.nl>
5464 diff -Naur iproute2-orig/debian/manpages/old/tc-sfq.8 iproute2/debian/manpages/old/tc-sfq.8
5465 --- iproute2-orig/debian/manpages/old/tc-sfq.8 1969-12-31 16:00:00.000000000 -0800
5466 +++ iproute2/debian/manpages/old/tc-sfq.8 2004-05-21 00:09:38.000000000 -0700
5468 +.TH TC 8 "8 December 2001" "iproute2" "Linux"
5470 +sfq \- Stochastic Fairness Queueing
5472 +.B tc qdisc ... perturb
5479 +Stochastic Fairness Queueing is a classless queueing discipline available for
5480 +traffic control with the
5484 +SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'.
5485 +The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing
5486 +any single flow from drowning out the rest.
5488 +This may in fact have some effect in mitigating a Denial of Service attempt.
5490 +SFQ is work-conserving and therefore always delivers a packet if it has one available.
5492 +On enqueueing, each packet is assigned to a hash bucket, based on
5498 +Destination address
5503 +If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP.
5504 +Packets with other protocols are hashed based on the 32bits representation of their
5505 +destination and the socket they belong to. A flow corresponds mostly to a TCP/IP
5508 +Each of these buckets should represent a unique flow. Because multiple flows may
5509 +get hashed to the same bucket, the hashing algorithm is perturbed at configurable
5510 +intervals so that the unfairness lasts only for a short while. Perturbation may
5511 +however cause some inadvertent packet reordering to occur.
5513 +When dequeuing, each hashbucket with data is queried in a round robin fashion.
5515 +The compile time maximum length of the SFQ is 128 packets, which can be spread over
5516 +at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed
5517 +on the fullest bucket, thus maintaining fairness.
5522 +Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that
5523 +no perturbation occurs. Do not set too low for each perturbation may cause some packet
5524 +reordering. Advised value: 10
5527 +Amount of bytes a flow is allowed to dequeue during a round of the round robin process.
5528 +Defaults to the MTU of the interface which is also the advised value and the minimum value.
5530 +.SH EXAMPLE & USAGE
5532 +To attach to device ppp0:
5534 +# tc qdisc add dev ppp0 root sfq perturb 10
5536 +Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful
5537 +if it owns the queue.
5538 +This is the case when the link speed equals the actually available bandwidth. This holds
5539 +for regular phone modems, ISDN connections and direct non-switched ethernet links.
5541 +Most often, cable modems and DSL devices do not fall into this category. The same holds
5542 +for when connected to a switch and trying to send data to a congested segment also
5543 +connected to the switch.
5545 +In this case, the effective queue does not reside within Linux and is therefore not
5546 +available for scheduling.
5548 +Embed SFQ in a classful qdisc to make sure it owns the queue.
5553 +Paul E. McKenney "Stochastic Fairness Queuing",
5554 +IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.
5558 +Paul E. McKenney "Stochastic Fairness Queuing",
5559 +"Interworking: Research and Experience", v.2, 1991, p.113-131.
5564 +M. Shreedhar and George Varghese "Efficient Fair
5565 +Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
5571 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
5572 +bert hubert <ahu@ds9a.nl>
5575 diff -Naur iproute2-orig/debian/manpages/old/tc-tbf.8 iproute2/debian/manpages/old/tc-tbf.8
5576 --- iproute2-orig/debian/manpages/old/tc-tbf.8 1969-12-31 16:00:00.000000000 -0800
5577 +++ iproute2/debian/manpages/old/tc-tbf.8 2004-05-21 00:09:38.000000000 -0700
5579 +.TH TC 8 "13 December 2001" "iproute2" "Linux"
5581 +tbf \- Token Bucket Filter
5583 +.B tc qdisc ... tbf rate
5599 +burst is also known as buffer and maxburst. mtu is also known as minburst.
5602 +The Token Bucket Filter is a classless queueing discipline available for
5603 +traffic control with the
5607 +TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle
5608 +itself, although packets are available, to ensure that the configured rate is not exceeded.
5609 +On all platforms except for Alpha,
5610 +it is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness,
5611 +sending out data exactly at the configured rates.
5613 +Much higher rates are possible but at the cost of losing the minimal burstiness. In that
5614 +case, data is on average dequeued at the configured rate but may be sent much faster at millisecond
5615 +timescales. Because of further queues living in network adaptors, this is often not a problem.
5617 +Kernels with a higher 'HZ' can achieve higher rates with perfect burstiness. On Alpha, HZ is ten
5618 +times higher, leading to a 10mbit/s limit to perfection. These calculations hold for packets of on
5619 +average 1000 bytes.
5622 +As the name implies, traffic is filtered based on the expenditure of
5624 +Tokens roughly correspond to bytes, with the additional constraint that each packet consumes
5625 +some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies
5626 +the link for some time.
5628 +On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst
5629 +in one go. Tokens arrive at a steady rate, until the bucket is full.
5631 +If no tokens are available, packets are queued, up to a configured limit. The TBF now
5632 +calculates the token deficit, and throttles until the first packet in the queue can be sent.
5634 +If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured
5635 +to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF
5636 +with a very small bucket, so that it doesn't burst.
5638 +To achieve perfection, the second bucket may contain only a single packet, which leads to
5639 +the earlier mentioned 1mbit/s limit.
5641 +This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends
5642 +on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100
5643 +packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.
5648 +for how to specify the units of these values.
5651 +Limit is the number of bytes that can be queued waiting for tokens to become
5652 +available. You can also specify this the other way around by setting the
5653 +latency parameter, which specifies the maximum amount of time a packet can
5654 +sit in the TBF. The latter calculation takes into account the size of the
5655 +bucket, the rate and possibly the peakrate (if set). These two parameters
5656 +are mutually exclusive.
5659 +Also known as buffer or maxburst.
5660 +Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously.
5661 +In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer
5662 +if you want to reach your configured rate!
5664 +If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
5665 +The minimum buffer size can be calculated by dividing the rate by HZ.
5667 +Token usage calculations are performed using a table which by default has a resolution of 8 packets.
5668 +This resolution can be changed by specifying the
5670 +size with the burst. For example, to specify a 6000 byte buffer with a 16
5671 +byte cell size, set a burst of 6000/16. You will probably never have to set
5672 +this. Must be an integral power of 2.
5675 +A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit
5676 +determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
5679 +The speed knob. See remarks above about limits! See
5683 +Furthermore, if a peakrate is desired, the following parameters are available:
5687 +Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does
5688 +not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
5692 +Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
5693 +If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
5694 +allows around 3mbit/s of peakrate, given 1000 byte packets.
5696 +Like the regular burstsize you can also specify a
5699 +.SH EXAMPLE & USAGE
5701 +To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s,
5702 +a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes
5703 +at most 70ms of latency, with perfect peakrate behaviour, issue:
5705 +# tc qdisc add dev eth0 root tbf rate 0.5mbit \\
5706 + burst 5kb latency 70ms peakrate 1mbit \\
5713 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
5714 +bert hubert <ahu@ds9a.nl>
5717 diff -Naur iproute2-orig/debian/manpages/old/tc.8 iproute2/debian/manpages/old/tc.8
5718 --- iproute2-orig/debian/manpages/old/tc.8 1969-12-31 16:00:00.000000000 -0800
5719 +++ iproute2/debian/manpages/old/tc.8 2004-05-21 00:09:38.000000000 -0700
5721 +.TH TC 8 "16 December 2001" "iproute2" "Linux"
5723 +tc \- show / manipulate traffic control settings
5725 +.B tc qdisc [ add | change | replace | link ] dev
5733 +[ qdisc specific parameters ]
5736 +.B tc class [ add | change | replace ] dev
5742 +[ qdisc specific parameters ]
5745 +.B tc filter [ add | change | replace ] dev
5749 +.B | root ] protocol
5752 +priority filtertype
5753 +[ filtertype specific parameters ]
5757 +.B tc [-s | -d ] qdisc show [ dev
5761 +.B tc [-s | -d ] class show dev
5764 +.B tc filter show dev
5769 +is used to configure Traffic Control in the Linux kernel. Traffic Control consists
5774 +When traffic is shaped, its rate of transmission is under control. Shaping may
5775 +be more than lowering the available bandwidth - it is also used to smooth out
5776 +bursts in traffic for better network behaviour. Shaping occurs on egress.
5780 +By scheduling the transmission of packets it is possible to improve interactivity
5781 +for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
5782 +is also called prioritizing, and happens only on egress.
5786 +Where shaping deals with transmission of traffic, policing pertains to traffic
5787 +arriving. Policing thus occurs on ingress.
5791 +Traffic exceeding a set bandwidth may also be dropped forthwith, both on
5792 +ingress and on egress.
5795 +Processing of traffic is controlled by three kinds of objects: qdiscs,
5796 +classes and filters.
5800 +is short for 'queueing discipline' and it is elementary to
5801 +understanding traffic control. Whenever the kernel needs to send a
5802 +packet to an interface, it is
5804 +to the qdisc configured for that interface. Immediately afterwards, the kernel
5805 +tries to get as many packets as possible from the qdisc, for giving them
5806 +to the network adaptor driver.
5808 +A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure
5809 +First In, First Out queue. It does however store traffic when the network interface
5810 +can't handle it momentarily.
5813 +Some qdiscs can contain classes, which contain further qdiscs - traffic may
5814 +then be enqueued in any of the inner qdiscs, which are within the
5816 +When the kernel tries to dequeue a packet from such a
5818 +it can come from any of the classes. A qdisc may for example prioritize
5819 +certain kinds of traffic by trying to dequeue from certain classes
5825 +is used by a classful qdisc to determine in which class a packet will
5826 +be enqueued. Whenever traffic arrives at a class with subclasses, it needs
5827 +to be classified. Various methods may be employed to do so, one of these
5828 +are the filters. All filters attached to the class are called, until one of
5829 +them returns with a verdict. If no verdict was made, other criteria may be
5830 +available. This differs per qdisc.
5832 +It is important to notice that filters reside
5834 +qdiscs - they are not masters of what happens.
5836 +.SH CLASSLESS QDISCS
5837 +The classless qdiscs are:
5840 +Simplest usable qdisc, pure First In, First Out behaviour. Limited in
5841 +packets or in bytes.
5844 +Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
5845 +queue which honors Type of Service flags, as well as the priority that may be
5846 +assigned to a packet.
5849 +Random Early Detection simulates physical congestion by randomly dropping
5850 +packets when nearing configured bandwidth allocation. Well suited to very
5851 +large bandwidth applications.
5854 +Stochastic Fairness Queueing reorders queued traffic so each 'session'
5855 +gets to send a packet in turn.
5858 +The Token Bucket Filter is suited for slowing traffic down to a precisely
5859 +configured rate. Scales well to large bandwidths.
5860 +.SH CONFIGURING CLASSLESS QDISCS
5861 +In the absence of classful qdiscs, classless qdiscs can only be attached at
5862 +the root of a device. Full syntax:
5864 +.B tc qdisc add dev
5867 +QDISC QDISC-PARAMETERS
5871 +.B tc qdisc del dev
5877 +qdisc is the automatic default in the absence of a configured qdisc.
5879 +.SH CLASSFUL QDISCS
5880 +The classful qdiscs are:
5883 +Class Based Queueing implements a rich linksharing hierarchy of classes.
5884 +It contains shaping elements as well as prioritizing capabilities. Shaping is
5885 +performed using link idle time calculations based on average packet size and
5886 +underlying link bandwidth. The latter may be ill-defined for some interfaces.
5889 +The Hierarchy Token Bucket implements a rich linksharing hierarchy of
5890 +classes with an emphasis on conforming to existing practices. HTB facilitates
5891 +guaranteeing bandwidth to classes, while also allowing specification of upper
5892 +limits to inter-class sharing. It contains shaping elements, based on TBF and
5893 +can prioritize classes.
5896 +The PRIO qdisc is a non-shaping container for a configurable number of
5897 +classes which are dequeued in order. This allows for easy prioritization
5898 +of traffic, where lower classes are only able to send if higher ones have
5899 +no packets available. To facilitate configuration, Type Of Service bits are
5900 +honored by default.
5901 +.SH THEORY OF OPERATION
5902 +Classes form a tree, where each class has a single parent.
5903 +A class may have multiple children. Some qdiscs allow for runtime addition
5904 +of classes (CBQ, HTB) while others (PRIO) are created with a static number of
5907 +Qdiscs which allow dynamic addition of classes can have zero or more
5908 +subclasses to which traffic may be enqueued.
5910 +Furthermore, each class contains a
5912 +which by default has
5914 +behaviour though another qdisc can be attached in place. This qdisc may again
5915 +contain classes, but each class can have only one leaf qdisc.
5917 +When a packet enters a classful qdisc it can be
5919 +to one of the classes within. Three criteria are available, although not all
5920 +qdiscs will use all three:
5923 +If tc filters are attached to a class, they are consulted first
5924 +for relevant instructions. Filters can match on all fields of a packet header,
5925 +as well as on the firewall mark applied by ipchains or iptables. See
5926 +.BR tc-filters (8).
5929 +Some qdiscs have built in rules for classifying packets based on the TOS field.
5932 +Userspace programs can encode a class-id in the 'skb->priority' field using
5933 +the SO_PRIORITY option.
5935 +Each node within the tree can have its own filters but higher level filters
5936 +may also point directly to lower classes.
5938 +If classification did not succeed, packets are enqueued to the leaf qdisc
5939 +attached to that class. Check qdisc specific manpages for details, however.
5942 +All qdiscs, classes and filters have IDs, which can either be specified
5943 +or be automatically assigned.
5945 +IDs consist of a major number and a minor number, separated by a colon.
5949 +A qdisc, which potentially can have children,
5950 +gets assigned a major number, called a 'handle', leaving the minor
5951 +number namespace available for classes. The handle is expressed as '10:'.
5952 +It is customary to explicitly assign a handle to qdiscs expected to have
5957 +Classes residing under a qdisc share their qdisc major number, but each have
5958 +a separate minor number called a 'classid' that has no relation to their
5959 +parent classes, only to their parent qdisc. The same naming custom as for
5964 +Filters have a three part ID, which is only needed when using a hashed
5965 +filter hierarchy, for which see
5966 +.BR tc-filters (8).
5968 +All parameters accept a floating point number, possibly followed by a unit.
5970 +Bandwidths or rates can be specified in:
5973 +Kilobytes per second
5976 +Megabytes per second
5979 +Kilobits per second
5982 +Megabits per second
5984 +bps or a bare number
5987 +Amounts of data can be specified in:
6004 +Lengths of time can be specified in:
6012 +us, usec, usecs or a bare number
6016 +The following commands are available for qdiscs, classes and filter:
6019 +Add a qdisc, class or filter to a node. For all entities, a
6021 +must be passed, either by passing its ID or by attaching directly to the root of a device.
6022 +When creating a qdisc or a filter, it can be named with the
6024 +parameter. A class is named with the
6030 +A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs
6031 +are automatically deleted, as well as any filters attached to them.
6035 +Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
6036 +that the handle cannot be changed and neither can the parent. In other words,
6039 +cannot move a node.
6043 +Performs a nearly atomic remove/add on an existing node id. If the node does not exist yet
6048 +Only available for qdiscs and performs a replace where the node
6049 +must exist already.
6054 +was written by Alexey N. Kuznetsov and added in Linux 2.2.
6063 +.BR tc-pfifo_fast (8),
6067 +Manpage maintained by bert hubert (ahu@ds9a.nl)
6069 diff -Naur iproute2-orig/debian/manpages/tc-cbq-details.8 iproute2/debian/manpages/tc-cbq-details.8
6070 --- iproute2-orig/debian/manpages/tc-cbq-details.8 1969-12-31 16:00:00.000000000 -0800
6071 +++ iproute2/debian/manpages/tc-cbq-details.8 2004-05-21 00:09:38.000000000 -0700
6073 +.TH CBQ 8 "8 December 2001" "iproute2" "Linux"
6075 +CBQ \- Class Based Queueing
6077 +.B tc qdisc ... dev
6081 +.B | root) [ handle
6095 +.B tc class ... dev
6123 +.B ] [ bounded isolated ] [ split
6128 +interval timeconstant
6132 +Class Based Queueing is a classful qdisc that implements a rich
6133 +linksharing hierarchy of classes. It contains shaping elements as
6134 +well as prioritizing capabilities. Shaping is performed using link
6135 +idle time calculations based on the timing of dequeue events and
6136 +underlying link bandwidth.
6138 +.SH SHAPING ALGORITHM
6139 +Shaping is done using link idle time calculations, and actions taken if
6140 +these calculations deviate from set limits.
6142 +When shaping a 10mbit/s connection to 1mbit/s, the link will
6143 +be idle 90% of the time. If it isn't, it needs to be throttled so that it
6144 +IS idle 90% of the time.
6146 +From the kernel's perspective, this is hard to measure, so CBQ instead
6147 +derives the idle time from the number of microseconds (in fact, jiffies)
6148 +that elapse between requests from the device driver for more data. Combined
6149 +with the knowledge of packet sizes, this is used to approximate how full or
6152 +This is rather circumspect and doesn't always arrive at proper
6153 +results. For example, what is the actual link speed of an interface
6154 +that is not really able to transmit the full 100mbit/s of data,
6155 +perhaps because of a badly implemented driver? A PCMCIA network card
6156 +will also never achieve 100mbit/s because of the way the bus is
6157 +designed - again, how do we calculate the idle time?
6159 +The physical link bandwidth may be ill defined in case of not-quite-real
6160 +network devices like PPP over Ethernet or PPTP over TCP/IP. The effective
6161 +bandwidth in that case is probably determined by the efficiency of pipes
6162 +to userspace - which not defined.
6164 +During operations, the effective idletime is measured using an
6165 +exponential weighted moving average (EWMA), which considers recent
6166 +packets to be exponentially more important than past ones. The Unix
6167 +loadaverage is calculated in the same way.
6169 +The calculated idle time is subtracted from the EWMA measured one,
6170 +the resulting number is called 'avgidle'. A perfectly loaded link has
6171 +an avgidle of zero: packets arrive exactly at the calculated
6174 +An overloaded link has a negative avgidle and if it gets too negative,
6175 +CBQ throttles and is then 'overlimit'.
6177 +Conversely, an idle link might amass a huge avgidle, which would then
6178 +allow infinite bandwidths after a few hours of silence. To prevent
6179 +this, avgidle is capped at
6182 +If overlimit, in theory, the CBQ could throttle itself for exactly the
6183 +amount of time that was calculated to pass between packets, and then
6184 +pass one packet, and throttle again. Due to timer resolution constraints,
6185 +this may not be feasible, see the
6190 +Within the one CBQ instance many classes may exist. Each of these classes
6191 +contains another qdisc, by default
6194 +When enqueueing a packet, CBQ starts at the root and uses various methods to
6195 +determine which class should receive the data. If a verdict is reached, this
6196 +process is repeated for the recipient class which might have further
6197 +means of classifying traffic to its children, if any.
6199 +CBQ has the following methods available to classify a packet to any child
6203 +.B skb->priority class encoding.
6204 +Can be set from userspace by an application with the
6208 +.B skb->priority class encoding
6209 +only applies if the skb->priority holds a major:minor handle of an existing
6210 +class within this qdisc.
6213 +tc filters attached to the class.
6216 +The defmap of a class, as set with the
6218 +parameters. The defmap may contain instructions for each possible Linux packet
6222 +Each class also has a
6224 +Leaf nodes, attached to the bottom of the class hierarchy, have a level of 0.
6225 +.SH CLASSIFICATION ALGORITHM
6227 +Classification is a loop, which terminates when a leaf class is found. At any
6228 +point the loop may jump to the fallback algorithm.
6230 +The loop consists of the following steps:
6233 +If the packet is generated locally and has a valid classid encoded within its
6235 +choose it and terminate.
6239 +Consult the tc filters, if any, attached to this child. If these return
6240 +a class which is not a leaf class, restart loop from the class returned.
6241 +If it is a leaf, choose it and terminate.
6244 +If the tc filters did not return a class, but did return a classid,
6245 +try to find a class with that id within this qdisc.
6246 +Check if the found class is of a lower
6248 +than the current class. If so, and the returned class is not a leaf node,
6249 +restart the loop at the found class. If it is a leaf node, terminate.
6250 +If we found an upward reference to a higher level, enter the fallback
6254 +If the tc filters did not return a class, nor a valid reference to one,
6255 +consider the minor number of the reference to be the priority. Retrieve
6256 +a class from the defmap of this class for the priority. If this did not
6257 +contain a class, consult the defmap of this class for the
6259 +class. If this is an upward reference, or no
6262 +enter the fallback algorithm. If a valid class was found, and it is not a
6263 +leaf node, restart the loop at this class. If it is a leaf, choose it and
6265 +neither the priority distilled from the classid, nor the
6267 +priority yielded a class, enter the fallback algorithm.
6269 +The fallback algorithm resides outside of the loop and is as follows.
6272 +Consult the defmap of the class at which the jump to fallback occured. If
6273 +the defmap contains a class for the
6276 +of the class (which is related to the TOS field), choose this class and
6280 +Consult the map for a class for the
6282 +priority. If found, choose it, and terminate.
6285 +Choose the class at which break out to the fallback algorithm occured. Terminate.
6287 +The packet is enqueued to the class which was chosen when either algorithm
6288 +terminated. It is therefore possible for a packet to be enqueued *not* at a
6289 +leaf node, but in the middle of the hierarchy.
6291 +.SH LINK SHARING ALGORITHM
6292 +When dequeuing for sending to the network device, CBQ decides which of its
6293 +classes will be allowed to send. It does so with a Weighted Round Robin process
6294 +in which each class with packets gets a chance to send in turn. The WRR process
6295 +starts by asking the highest priority classes (lowest numerically -
6296 +highest semantically) for packets, and will continue to do so until they
6297 +have no more data to offer, in which case the process repeats for lower
6300 +.B CERTAINTY ENDS HERE, ANK PLEASE HELP
6302 +Each class is not allowed to send at length though - they can only dequeue a
6303 +configurable amount of data during each round.
6305 +If a class is about to go overlimit, and it is not
6307 +it will try to borrow avgidle from siblings that are not
6309 +This process is repeated from the bottom upwards. If a class is unable
6310 +to borrow enough avgidle to send a packet, it is throttled and not asked
6311 +for a packet for enough time for the avgidle to increase above zero.
6313 +.B I REALLY NEED HELP FIGURING THIS OUT. REST OF DOCUMENT IS PRETTY CERTAIN
6317 +The root qdisc of a CBQ class tree has the following parameters:
6320 +parent major:minor | root
6321 +This mandatory parameter determines the place of the CBQ instance, either at the
6323 +of an interface or within an existing class.
6326 +Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
6327 +of a major number, followed by a colon. Optional.
6330 +For calculations, the average packet size must be known. It is silently capped
6331 +at a minimum of 2/3 of the interface MTU. Mandatory.
6334 +To determine the idle time, CBQ must know the bandwidth of your underlying
6335 +physical interface, or parent qdisc. This is a vital parameter, more about it
6339 +The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
6342 +A zero sized packet may still take time to transmit. This value is the lower
6343 +cap for packet transmission time calculations - packets smaller than this value
6344 +are still deemed to have this size. Defaults to zero.
6347 +When CBQ needs to measure the average idle time, it does so using an
6348 +Exponentially Weighted Moving Average which smoothes out measurements into
6349 +a moving average. The EWMA LOG determines how much smoothing occurs. Defaults
6350 +to 5. Lower values imply greater sensitivity. Must be between 0 and 31.
6352 +A CBQ qdisc does not shape out of its own accord. It only needs to know certain
6353 +parameters about the underlying link. Actual shaping is done in classes.
6356 +Classes have a host of parameters to configure their operation.
6360 +Place of this class within the hierarchy. If attached directly to a qdisc
6361 +and not to another class, minor can be omitted. Mandatory.
6363 +classid major:minor
6364 +Like qdiscs, classes can be named. The major number must be equal to the
6365 +major number of the qdisc to which it belongs. Optional, but needed if this
6366 +class is going to have children.
6369 +When dequeuing to the interface, classes are tried for traffic in a
6370 +round-robin fashion. Classes with a higher configured qdisc will generally
6371 +have more traffic to offer during each round, so it makes sense to allow
6372 +it to dequeue more traffic. All weights under a class are normalized, so
6373 +only the ratios matter. Defaults to the configured rate, unless the priority
6374 +of this class is maximal, in which case it is set to 1.
6377 +Allot specifies how many bytes a qdisc can dequeue
6378 +during each round of the process. This parameter is weighted using the
6379 +renormalized class weight described above.
6383 +In the round-robin process, classes with the lowest priority field are tried
6384 +for packets first. Mandatory.
6388 +Maximum rate this class and all its children combined can send at. Mandatory.
6392 +This is different from the bandwidth specified when creating a CBQ disc. Only
6393 +used to determine maxidle and offtime, which are only calculated when
6394 +specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
6398 +This number of packets is used to calculate maxidle so that when
6399 +avgidle is at maxidle, this number of average packets can be burst
6400 +before avgidle drops to 0. Set it higher to be more tolerant of
6401 +bursts. You can't set maxidle directly, only via this parameter.
6405 +As mentioned before, CBQ needs to throttle in case of
6406 +overlimit. The ideal solution is to do so for exactly the calculated
6407 +idle time, and pass 1 packet. However, Unix kernels generally have a
6408 +hard time scheduling events shorter than 10ms, so it is better to
6409 +throttle for a longer period, and then pass minburst packets in one
6410 +go, and then sleep minburst times longer.
6412 +The time to wait is called the offtime. Higher values of minburst lead
6413 +to more accurate shaping in the long term, but to bigger bursts at
6414 +millisecond timescales.
6418 +If avgidle is below 0, we are overlimits and need to wait until
6419 +avgidle will be big enough to send one packet. To prevent a sudden
6420 +burst from shutting down the link for a prolonged period of time,
6421 +avgidle is reset to minidle if it gets too low.
6423 +Minidle is specified in negative microseconds, so 10 means that
6424 +avgidle is capped at -10us.
6428 +Signifies that this class will not borrow bandwidth from its siblings.
6431 +Means that this class will not borrow bandwidth to its siblings
6434 +split major:minor & defmap bitmap[/bitmap]
6435 +If consulting filters attached to a class did not give a verdict,
6436 +CBQ can also classify based on the packet's priority. There are 16
6437 +priorities available, numbered from 0 to 15.
6439 +The defmap specifies which priorities this class wants to receive,
6440 +specified as a bitmap. The Least Significant Bit corresponds to priority
6443 +parameter tells CBQ at which class the decision must be made, which should
6444 +be a (grand)parent of the class you are adding.
6446 +As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
6447 +configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
6449 +The complimentary configuration would then
6450 +be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
6451 +Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
6453 +estimator interval timeconstant
6454 +CBQ can measure how much bandwidth each class is using, which tc filters
6455 +can use to classify packets with. In order to determine the bandwidth
6456 +it uses a very simple estimator that measures once every
6458 +microseconds how much traffic has passed. This again is a EWMA, for which
6459 +the time constant can be specified, also in microseconds. The
6461 +corresponds to the sluggishness of the measurement or, conversely, to the
6462 +sensitivity of the average to short bursts. Higher values mean less
6470 +Sally Floyd and Van Jacobson, "Link-sharing and Resource
6471 +Management Models for Packet Networks",
6472 +IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
6476 +Sally Floyd, "Notes on CBQ and Guarantee Service", 1995
6480 +Sally Floyd, "Notes on Class-Based Queueing: Setting
6485 +Sally Floyd and Michael Speer, "Experimental Results
6486 +for Class-Based Queueing", 1998, not published.
6494 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
6495 +bert hubert <ahu@ds9a.nl>
6498 diff -Naur iproute2-orig/debian/manpages/tc-cbq.8 iproute2/debian/manpages/tc-cbq.8
6499 --- iproute2-orig/debian/manpages/tc-cbq.8 1969-12-31 16:00:00.000000000 -0800
6500 +++ iproute2/debian/manpages/tc-cbq.8 2004-05-21 00:09:38.000000000 -0700
6502 +.TH CBQ 8 "16 December 2001" "iproute2" "Linux"
6504 +CBQ \- Class Based Queueing
6506 +.B tc qdisc ... dev
6510 +.B | root) [ handle
6526 +.B tc class ... dev
6554 +.B ] [ bounded isolated ] [ split
6559 +interval timeconstant
6563 +Class Based Queueing is a classful qdisc that implements a rich
6564 +linksharing hierarchy of classes. It contains shaping elements as
6565 +well as prioritizing capabilities. Shaping is performed using link
6566 +idle time calculations based on the timing of dequeue events and
6567 +underlying link bandwidth.
6569 +.SH SHAPING ALGORITHM
6570 +When shaping a 10mbit/s connection to 1mbit/s, the link will
6571 +be idle 90% of the time. If it isn't, it needs to be throttled so that it
6572 +IS idle 90% of the time.
6574 +During operations, the effective idletime is measured using an
6575 +exponential weighted moving average (EWMA), which considers recent
6576 +packets to be exponentially more important than past ones. The Unix
6577 +loadaverage is calculated in the same way.
6579 +The calculated idle time is subtracted from the EWMA measured one,
6580 +the resulting number is called 'avgidle'. A perfectly loaded link has
6581 +an avgidle of zero: packets arrive exactly at the calculated
6584 +An overloaded link has a negative avgidle and if it gets too negative,
6585 +CBQ throttles and is then 'overlimit'.
6587 +Conversely, an idle link might amass a huge avgidle, which would then
6588 +allow infinite bandwidths after a few hours of silence. To prevent
6589 +this, avgidle is capped at
6592 +If overlimit, in theory, the CBQ could throttle itself for exactly the
6593 +amount of time that was calculated to pass between packets, and then
6594 +pass one packet, and throttle again. Due to timer resolution constraints,
6595 +this may not be feasible, see the
6600 +Within the one CBQ instance many classes may exist. Each of these classes
6601 +contains another qdisc, by default
6604 +When enqueueing a packet, CBQ starts at the root and uses various methods to
6605 +determine which class should receive the data.
6607 +In the absence of uncommon configuration options, the process is rather easy.
6608 +At each node we look for an instruction, and then go to the class the
6609 +instruction refers us to. If the class found is a barren leaf-node (without
6610 +children), we enqueue the packet there. If it is not yet a leaf node, we do
6611 +the whole thing over again starting from that node.
6613 +The following actions are performed, in order at each node we visit, until one
6614 +sends us to another node, or terminates the process.
6617 +Consult filters attached to the class. If sent to a leafnode, we are done.
6618 +Otherwise, restart.
6621 +Consult the defmap for the priority assigned to this packet, which depends
6622 +on the TOS bits. Check if the referral is leafless, otherwise restart.
6625 +Ask the defmap for instructions for the 'best effort' priority. Check the
6626 +answer for leafness, otherwise restart.
6629 +If none of the above returned with an instruction, enqueue at this node.
6631 +This algorithm makes sure that a packet always ends up somewhere, even while
6632 +you are busy building your configuration.
6634 +For more details, see
6635 +.BR tc-cbq-details(8).
6637 +.SH LINK SHARING ALGORITHM
6638 +When dequeuing for sending to the network device, CBQ decides which of its
6639 +classes will be allowed to send. It does so with a Weighted Round Robin process
6640 +in which each class with packets gets a chance to send in turn. The WRR process
6641 +starts by asking the highest priority classes (lowest numerically -
6642 +highest semantically) for packets, and will continue to do so until they
6643 +have no more data to offer, in which case the process repeats for lower
6646 +Classes by default borrow bandwidth from their siblings. A class can be
6647 +prevented from doing so by declaring it 'bounded'. A class can also indicate
6648 +its unwillingness to lend out bandwidth by being 'isolated'.
6651 +The root of a CBQ qdisc class tree has the following parameters:
6654 +parent major:minor | root
6655 +This mandatory parameter determines the place of the CBQ instance, either at the
6657 +of an interface or within an existing class.
6660 +Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
6661 +of a major number, followed by a colon. Optional, but very useful if classes
6662 +will be generated within this qdisc.
6665 +This allotment is the 'chunkiness' of link sharing and is used for determining packet
6666 +transmission time tables. The qdisc allot differs slightly from the class allot discussed
6667 +below. Optional. Defaults to a reasonable value, related to avpkt.
6670 +The average size of a packet is needed for calculating maxidle, and is also used
6671 +for making sure 'allot' has a safe value. Mandatory.
6674 +To determine the idle time, CBQ must know the bandwidth of your underlying
6675 +physical interface, or parent qdisc. This is a vital parameter, more about it
6679 +The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
6682 +A zero sized packet may still take time to transmit. This value is the lower
6683 +cap for packet transmission time calculations - packets smaller than this value
6684 +are still deemed to have this size. Defaults to zero.
6687 +When CBQ needs to measure the average idle time, it does so using an
6688 +Exponentially Weighted Moving Average which smoothes out measurements into
6689 +a moving average. The EWMA LOG determines how much smoothing occurs. Lower
6690 +values imply greater sensitivity. Must be between 0 and 31. Defaults
6693 +A CBQ qdisc does not shape out of its own accord. It only needs to know certain
6694 +parameters about the underlying link. Actual shaping is done in classes.
6697 +Classes have a host of parameters to configure their operation.
6701 +Place of this class within the hierarchy. If attached directly to a qdisc
6702 +and not to another class, minor can be omitted. Mandatory.
6704 +classid major:minor
6705 +Like qdiscs, classes can be named. The major number must be equal to the
6706 +major number of the qdisc to which it belongs. Optional, but needed if this
6707 +class is going to have children.
6710 +When dequeuing to the interface, classes are tried for traffic in a
6711 +round-robin fashion. Classes with a higher configured qdisc will generally
6712 +have more traffic to offer during each round, so it makes sense to allow
6713 +it to dequeue more traffic. All weights under a class are normalized, so
6714 +only the ratios matter. Defaults to the configured rate, unless the priority
6715 +of this class is maximal, in which case it is set to 1.
6718 +Allot specifies how many bytes a qdisc can dequeue
6719 +during each round of the process. This parameter is weighted using the
6720 +renormalized class weight described above. Silently capped at a minimum of
6721 +3/2 avpkt. Mandatory.
6725 +In the round-robin process, classes with the lowest priority field are tried
6726 +for packets first. Mandatory.
6730 +See the QDISC section.
6734 +Maximum rate this class and all its children combined can send at. Mandatory.
6738 +This is different from the bandwidth specified when creating a CBQ disc! Only
6739 +used to determine maxidle and offtime, which are only calculated when
6740 +specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
6744 +This number of packets is used to calculate maxidle so that when
6745 +avgidle is at maxidle, this number of average packets can be burst
6746 +before avgidle drops to 0. Set it higher to be more tolerant of
6747 +bursts. You can't set maxidle directly, only via this parameter.
6751 +As mentioned before, CBQ needs to throttle in case of
6752 +overlimit. The ideal solution is to do so for exactly the calculated
6753 +idle time, and pass 1 packet. However, Unix kernels generally have a
6754 +hard time scheduling events shorter than 10ms, so it is better to
6755 +throttle for a longer period, and then pass minburst packets in one
6756 +go, and then sleep minburst times longer.
6758 +The time to wait is called the offtime. Higher values of minburst lead
6759 +to more accurate shaping in the long term, but to bigger bursts at
6760 +millisecond timescales. Optional.
6764 +If avgidle is below 0, we are overlimits and need to wait until
6765 +avgidle will be big enough to send one packet. To prevent a sudden
6766 +burst from shutting down the link for a prolonged period of time,
6767 +avgidle is reset to minidle if it gets too low.
6769 +Minidle is specified in negative microseconds, so 10 means that
6770 +avgidle is capped at -10us. Optional.
6774 +Signifies that this class will not borrow bandwidth from its siblings.
6777 +Means that this class will not borrow bandwidth to its siblings
6780 +split major:minor & defmap bitmap[/bitmap]
6781 +If consulting filters attached to a class did not give a verdict,
6782 +CBQ can also classify based on the packet's priority. There are 16
6783 +priorities available, numbered from 0 to 15.
6785 +The defmap specifies which priorities this class wants to receive,
6786 +specified as a bitmap. The Least Significant Bit corresponds to priority
6789 +parameter tells CBQ at which class the decision must be made, which should
6790 +be a (grand)parent of the class you are adding.
6792 +As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
6793 +configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
6795 +The complimentary configuration would then
6796 +be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
6797 +Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
6799 +estimator interval timeconstant
6800 +CBQ can measure how much bandwidth each class is using, which tc filters
6801 +can use to classify packets with. In order to determine the bandwidth
6802 +it uses a very simple estimator that measures once every
6804 +microseconds how much traffic has passed. This again is a EWMA, for which
6805 +the time constant can be specified, also in microseconds. The
6807 +corresponds to the sluggishness of the measurement or, conversely, to the
6808 +sensitivity of the average to short bursts. Higher values mean less
6812 +The actual bandwidth of the underlying link may not be known, for example
6813 +in the case of PPoE or PPTP connections which in fact may send over a
6814 +pipe, instead of over a physical device. CBQ is quite resilient to major
6815 +errors in the configured bandwidth, probably a the cost of coarser shaping.
6817 +Default kernels rely on coarse timing information for making decisions. These
6818 +may make shaping precise in the long term, but inaccurate on second long scales.
6821 +.BR tc-cbq-details(8)
6822 +for hints on how to improve this.
6827 +Sally Floyd and Van Jacobson, "Link-sharing and Resource
6828 +Management Models for Packet Networks",
6829 +IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
6833 +Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
6837 +Sally Floyd, "Notes on Class-Based Queueing: Setting
6842 +Sally Floyd and Michael Speer, "Experimental Results
6843 +for Class-Based Queueing", 1998, not published.
6851 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
6852 +bert hubert <ahu@ds9a.nl>
6855 diff -Naur iproute2-orig/debian/manpages/tc-htb.8 iproute2/debian/manpages/tc-htb.8
6856 --- iproute2-orig/debian/manpages/tc-htb.8 1969-12-31 16:00:00.000000000 -0800
6857 +++ iproute2/debian/manpages/tc-htb.8 2004-05-21 00:09:38.000000000 -0700
6859 +.TH HTB 8 "10 January 2002" "iproute2" "Linux"
6861 +HTB \- Hierarchy Token Bucket
6863 +.B tc qdisc ... dev
6867 +.B | root) [ handle
6873 +.B tc class ... dev
6892 +HTB is meant as a more understandable and intuitive replacement for
6893 +the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
6894 +of the outbound bandwidth on a given link. Both allow you to use one
6895 +physical link to simulate several slower links and to send different
6896 +kinds of traffic on different simulated links. In both cases, you have
6897 +to specify how to divide the physical link into simulated links and
6898 +how to decide which simulated link to use for a given packet to be sent.
6900 +Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm
6901 +which does not depend on interface characteristics and so does not need to
6902 +know the underlying bandwidth of the outgoing interface.
6904 +.SH SHAPING ALGORITHM
6905 +Shaping works as documented in
6909 +Within the one HRB instance many classes may exist. Each of these classes
6910 +contains another qdisc, by default
6913 +When enqueueing a packet, HTB starts at the root and uses various methods to
6914 +determine which class should receive the data.
6916 +In the absence of uncommon configuration options, the process is rather easy.
6917 +At each node we look for an instruction, and then go to the class the
6918 +instruction refers us to. If the class found is a barren leaf-node (without
6919 +children), we enqueue the packet there. If it is not yet a leaf node, we do
6920 +the whole thing over again starting from that node.
6922 +The following actions are performed, in order at each node we visit, until one
6923 +sends us to another node, or terminates the process.
6926 +Consult filters attached to the class. If sent to a leafnode, we are done.
6927 +Otherwise, restart.
6930 +If none of the above returned with an instruction, enqueue at this node.
6932 +This algorithm makes sure that a packet always ends up somewhere, even while
6933 +you are busy building your configuration.
6935 +.SH LINK SHARING ALGORITHM
6939 +The root of a HTB qdisc class tree has the following parameters:
6942 +parent major:minor | root
6943 +This mandatory parameter determines the place of the HTB instance, either at the
6945 +of an interface or within an existing class.
6948 +Like all other qdiscs, the HTB can be assigned a handle. Should consist only
6949 +of a major number, followed by a colon. Optional, but very useful if classes
6950 +will be generated within this qdisc.
6953 +Unclassified traffic gets sent to the class with this minor-id.
6956 +Classes have a host of parameters to configure their operation.
6960 +Place of this class within the hierarchy. If attached directly to a qdisc
6961 +and not to another class, minor can be omitted. Mandatory.
6963 +classid major:minor
6964 +Like qdiscs, classes can be named. The major number must be equal to the
6965 +major number of the qdisc to which it belongs. Optional, but needed if this
6966 +class is going to have children.
6969 +In the round-robin process, classes with the lowest priority field are tried
6970 +for packets first. Mandatory.
6974 +Maximum rate this class and all its children are guaranteed. Mandatory.
6978 +Maximum rate at which a class can send, if its parent has bandwidth to spare.
6979 +Defaults to the configured rate, which implies no borrowing
6983 +Amount of bytes that can be burst at
6985 +speed, in excess of the configured
6987 +Should be at least as high as the highest burst of all children.
6991 +Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
6992 +as the interface can transmit them. For perfect evening out, should be equal to at most one average
6993 +packet. Should be at least as high as the highest cburst of all children.
6996 +Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel,
6997 +there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
6998 +From this, the mininum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte
6999 +burst as 100*12kb*8 equals 10mbit.
7004 +HTB website: http://luxik.cdi.cz/~devik/qos/htb/
7006 +Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
7009 diff -Naur iproute2-orig/debian/manpages/tc-pbfifo.8 iproute2/debian/manpages/tc-pbfifo.8
7010 --- iproute2-orig/debian/manpages/tc-pbfifo.8 1969-12-31 16:00:00.000000000 -0800
7011 +++ iproute2/debian/manpages/tc-pbfifo.8 2004-05-21 00:09:38.000000000 -0700
7013 +.TH PBFIFO 8 "10 January 2002" "iproute2" "Linux"
7015 +pfifo \- Packet limited First In, First Out queue
7017 +bfifo \- Byte limited First In, First Out queue
7020 +.B tc qdisc ... add pfifo
7025 +.B tc qdisc ... add bfifo
7031 +The pfifo and bfifo qdiscs are unadorned First In, First Out queues. They are the
7032 +simplest queues possible and therefore have no overhead.
7034 +constrains the queue size as measured in packets.
7036 +does so as measured in bytes.
7038 +Like all non-default qdiscs, they maintain statistics. This might be a reason to prefer
7039 +pfifo or bfifo over the default.
7042 +A list of packets is maintained, when a packet is enqueued it gets inserted at the tail of
7043 +a list. When a packet needs to be sent out to the network, it is taken from the head of the list.
7045 +If the list is too long, no further packets are allowed on. This is called 'tail drop'.
7050 +Maximum queue size. Specified in bytes for bfifo, in packets for pfifo. For pfifo, defaults
7051 +to the interface txqueuelen, as specified with
7056 +For bfifo, it defaults to the txqueuelen multiplied by the interface MTU.
7061 +contains the limit, either in packets or in bytes, and the number of bytes
7062 +and packets actually sent. An unsent and dropped packet only appears between braces
7063 +and is not counted as 'Sent'.
7065 +In this example, the queue length is 100 packets, 45894 bytes were sent over 681 packets.
7066 +No packets were dropped, and as the pfifo queue does not slow down packets, there were also no
7070 +# tc -s qdisc ls dev eth0
7071 +qdisc pfifo 8001: dev eth0 limit 100p
7072 + Sent 45894 bytes 681 pkts (dropped 0, overlimits 0)
7075 +If a backlog occurs, this is displayed as well.
7080 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
7082 +This manpage maintained by bert hubert <ahu@ds9a.nl>
7085 diff -Naur iproute2-orig/debian/manpages/tc-pfifo_fast.8 iproute2/debian/manpages/tc-pfifo_fast.8
7086 --- iproute2-orig/debian/manpages/tc-pfifo_fast.8 1969-12-31 16:00:00.000000000 -0800
7087 +++ iproute2/debian/manpages/tc-pfifo_fast.8 2004-05-21 00:09:38.000000000 -0700
7089 +.TH PFIFO_FAST 8 "10 January 2002" "iproute2" "Linux"
7091 +pfifo_fast \- three-band first in, first out queue
7094 +pfifo_fast is the default qdisc of each interface.
7096 +Whenever an interface is created, the pfifo_fast qdisc is automatically used
7097 +as a queue. If another qdisc is attached, it preempts the default
7098 +pfifo_fast, which automatically returns to function when an existing qdisc
7101 +In this sense this qdisc is magic, and unlike other qdiscs.
7104 +The algorithm is very similar to that of the classful
7110 +queues side by side, where packets can be enqueued in any of the three bands
7111 +based on their Type of Service bits or assigned priority.
7113 +Not all three bands are dequeued simultaneously - as long as lower bands
7114 +have traffic, higher bands are never dequeued. This can be used to
7115 +prioritize interactive traffic or penalize 'lowest cost' traffic.
7117 +Each band can be txqueuelen packets long, as configured with
7121 +Additional packets coming in are not enqueued but are instead dropped.
7125 +for complete details on how TOS bits are translated into bands.
7129 +The length of the three bands depends on the interface txqueuelen, as
7136 +Does not maintain statistics and does not show up in tc qdisc ls. This is because
7137 +it is the automatic default in the absence of a configured qdisc.
7143 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
7145 +This manpage maintained by bert hubert <ahu@ds9a.nl>
7148 diff -Naur iproute2-orig/debian/manpages/tc-prio.8 iproute2/debian/manpages/tc-prio.8
7149 --- iproute2-orig/debian/manpages/tc-prio.8 1969-12-31 16:00:00.000000000 -0800
7150 +++ iproute2/debian/manpages/tc-prio.8 2004-05-21 00:09:38.000000000 -0700
7152 +.TH PRIO 8 "16 December 2001" "iproute2" "Linux"
7154 +PRIO \- Priority qdisc
7156 +.B tc qdisc ... dev
7160 +.B | root) [ handle
7167 +interval timeconstant
7171 +The PRIO qdisc is a simple classful queueing discipline that contains
7172 +an arbitrary number of classes of differing priority. The classes are
7173 +dequeued in numerical descending order of priority. PRIO is a scheduler
7174 +and never delays packets - it is a work-conserving qdisc, though the qdiscs
7175 +contained in the classes may not be.
7177 +Very useful for lowering latency when there is no need for slowing down
7181 +On creation with 'tc qdisc add', a fixed number of bands is created. Each
7182 +band is a class, although is not possible to add classes with 'tc qdisc
7183 +add', the number of bands to be created must instead be specified on the
7184 +commandline attaching PRIO to its root.
7186 +When dequeueing, band 0 is tried first and only if it did not deliver a
7187 +packet does PRIO try band 1, and so onwards. Maximum reliability packets
7188 +should therefore go to band 0, minimum delay to band 1 and the rest to band
7191 +As the PRIO qdisc itself will have minor number 0, band 0 is actually
7192 +major:1, band 1 is major:2, etc. For major, substitute the major number
7193 +assigned to the qdisc on 'tc qdisc add' with the
7198 +Three methods are available to PRIO to determine in which band a packet will
7202 +A process with sufficient privileges can encode the destination class
7203 +directly with SO_PRIORITY, see
7207 +A tc filter attached to the root qdisc can point traffic directly to a class
7210 +Based on the packet priority, which in turn is derived from the Type of
7211 +Service assigned to the packet.
7213 +Only the priomap is specific to this qdisc.
7214 +.SH QDISC PARAMETERS
7217 +Number of bands. If changed from the default of 3,
7219 +must be updated as well.
7222 +The priomap maps the priority of
7223 +a packet to a class. The priority can either be set directly from userspace,
7224 +or be derived from the Type of Service of the packet.
7226 +Determines how packet priorities, as assigned by the kernel, map to
7227 +bands. Mapping occurs based on the TOS octet of the packet, which looks like
7232 ++---+---+---+---+---+---+---+---+
7234 +|PRECEDENCE | TOS |MBZ|
7236 ++---+---+---+---+---+---+---+---+
7239 +The four TOS bits (the 'TOS field') are defined as:
7242 +Binary Decimcal Meaning
7243 +-----------------------------------------
7244 +1000 8 Minimize delay (md)
7245 +0100 4 Maximize throughput (mt)
7246 +0010 2 Maximize reliability (mr)
7247 +0001 1 Minimize monetary cost (mmc)
7248 +0000 0 Normal Service
7251 +As there is 1 bit to the right of these four bits, the actual value of the
7252 +TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the
7253 +value of the entire TOS field, not just the four bits. It is the value you
7254 +see in the first column of this table:
7257 +TOS Bits Means Linux Priority Band
7258 +------------------------------------------------------------
7259 +0x0 0 Normal Service 0 Best Effort 1
7260 +0x2 1 Minimize Monetary Cost 1 Filler 2
7261 +0x4 2 Maximize Reliability 0 Best Effort 1
7262 +0x6 3 mmc+mr 0 Best Effort 1
7263 +0x8 4 Maximize Throughput 2 Bulk 2
7264 +0xa 5 mmc+mt 2 Bulk 2
7265 +0xc 6 mr+mt 2 Bulk 2
7266 +0xe 7 mmc+mr+mt 2 Bulk 2
7267 +0x10 8 Minimize Delay 6 Interactive 0
7268 +0x12 9 mmc+md 6 Interactive 0
7269 +0x14 10 mr+md 6 Interactive 0
7270 +0x16 11 mmc+mr+md 6 Interactive 0
7271 +0x18 12 mt+md 4 Int. Bulk 1
7272 +0x1a 13 mmc+mt+md 4 Int. Bulk 1
7273 +0x1c 14 mr+mt+md 4 Int. Bulk 1
7274 +0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1
7277 +The second column contains the value of the relevant
7278 +four TOS bits, followed by their translated meaning. For example, 15 stands
7279 +for a packet wanting Minimal Montetary Cost, Maximum Reliability, Maximum
7280 +Throughput AND Minimum Delay.
7282 +The fourth column lists the way the Linux kernel interprets the TOS bits, by
7283 +showing to which Priority they are mapped.
7285 +The last column shows the result of the default priomap. On the commandline,
7286 +the default priomap looks like this:
7288 + 1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
7290 +This means that priority 4, for example, gets mapped to band number 1.
7291 +The priomap also allows you to list higher priorities (> 7) which do not
7292 +correspond to TOS mappings, but which are set by other means.
7294 +This table from RFC 1349 (read it for more details) explains how
7295 +applications might very well set their TOS bits:
7298 +TELNET 1000 (minimize delay)
7300 + Control 1000 (minimize delay)
7301 + Data 0100 (maximize throughput)
7303 +TFTP 1000 (minimize delay)
7306 + Command phase 1000 (minimize delay)
7307 + DATA phase 0100 (maximize throughput)
7309 +Domain Name Service
7310 + UDP Query 1000 (minimize delay)
7312 + Zone Transfer 0100 (maximize throughput)
7314 +NNTP 0001 (minimize monetary cost)
7318 + Requests 0000 (mostly)
7319 + Responses <same as request> (mostly)
7324 +PRIO classes cannot be configured further - they are automatically created
7325 +when the PRIO qdisc is attached. Each class however can contain yet a
7329 +Large amounts of traffic in the lower bands can cause starvation of higher
7330 +bands. Can be prevented by attaching a shaper (for example,
7332 +to these bands to make sure they cannot dominate the link.
7335 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, J Hadi Salim
7336 +<hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>
7339 diff -Naur iproute2-orig/debian/manpages/tc-red.8 iproute2/debian/manpages/tc-red.8
7340 --- iproute2-orig/debian/manpages/tc-red.8 1969-12-31 16:00:00.000000000 -0800
7341 +++ iproute2/debian/manpages/tc-red.8 2004-05-21 00:09:38.000000000 -0700
7343 +.TH RED 8 "13 December 2001" "iproute2" "Linux"
7345 +red \- Random Early Detection
7347 +.B tc qdisc ... red
7358 +.B [ ecn ] [ bandwidth
7364 +Random Early Detection is a classless qdisc which manages its queue size
7365 +smartly. Regular queues simply drop packets from the tail when they are
7366 +full, which may not be the optimal behaviour. RED also performs tail drop,
7367 +but does so in a more gradual way.
7369 +Once the queue hits a certain average length, packets enqueued have a
7370 +configurable chance of being marked (which may mean dropped). This chance
7371 +increases linearly up to a point called the
7373 +average queue length, although the queue might get bigger.
7375 +This has a host of benefits over simple taildrop, while not being processor
7376 +intensive. It prevents synchronous retransmits after a burst in traffic,
7377 +which cause further retransmits, etc.
7379 +The goal is the have a small queue size, which is good for interactivity
7380 +while not disturbing TCP/IP traffic with too many sudden drops after a burst
7383 +Depending on if ECN is configured, marking either means dropping or
7384 +purely marking a packet as overlimit.
7386 +The average queue size is used for determining the marking
7387 +probability. This is calculated using an Exponential Weighted Moving
7388 +Average, which can be more or less sensitive to bursts.
7390 +When the average queue size is below
7392 +bytes, no packet will ever be marked. When it exceeds
7394 +the probability of doing so climbs linearly up
7397 +until the average queue size hits
7401 +is normally not set to 100%, the queue size might
7402 +conceivably rise above
7406 +parameter is provided to set a hard maximum for the size of the queue.
7411 +Average queue size at which marking becomes a possibility.
7414 +At this average queue size, the marking probability is maximal. Should be at
7417 +to prevent synchronous retransmits, higher for low
7421 +Maximum probability for marking, specified as a floating point
7422 +number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
7426 +Hard limit on the real (not average) queue size in bytes. Further packets
7427 +are dropped. Should be set higher than max+burst. It is advised to set this
7428 +a few times higher than
7432 +Used for determining how fast the average queue size is influenced by the
7433 +real queue size. Larger values make the calculation more sluggish, allowing
7434 +longer bursts of traffic before marking starts. Real life experiments
7435 +support the following guideline: (min+min+max)/(3*avpkt).
7438 +Specified in bytes. Used with burst to determine the time constant for
7439 +average queue size calculations. 1000 is a good value.
7442 +This rate is used for calculating the average queue size after some
7443 +idle time. Should be set to the bandwidth of your interface. Does not mean
7444 +that RED will shape for you! Optional.
7447 +As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion
7448 +Notification allows RED to notify remote hosts that their rate exceeds the
7449 +amount of bandwidth available. Non-ECN capable hosts can only be notified by
7450 +dropping a packet. If this parameter is specified, packets which indicate
7451 +that their hosts honor ECN will only be marked and not dropped, unless the
7454 +bytes. Needs a tc binary with RED support compiled in. Recommended.
7462 +Floyd, S., and Jacobson, V., Random Early Detection gateways for
7463 +Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html
7466 +Some changes to the algorithm by Alexey N. Kuznetsov.
7469 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, Alexey Makarenko
7470 +<makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>.
7471 +This manpage maintained by bert hubert <ahu@ds9a.nl>
7474 diff -Naur iproute2-orig/debian/manpages/tc-sfq.8 iproute2/debian/manpages/tc-sfq.8
7475 --- iproute2-orig/debian/manpages/tc-sfq.8 1969-12-31 16:00:00.000000000 -0800
7476 +++ iproute2/debian/manpages/tc-sfq.8 2004-05-21 00:09:38.000000000 -0700
7478 +.TH TC 8 "8 December 2001" "iproute2" "Linux"
7480 +sfq \- Stochastic Fairness Queueing
7482 +.B tc qdisc ... perturb
7489 +Stochastic Fairness Queueing is a classless queueing discipline available for
7490 +traffic control with the
7494 +SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'.
7495 +The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing
7496 +any single flow from drowning out the rest.
7498 +This may in fact have some effect in mitigating a Denial of Service attempt.
7500 +SFQ is work-conserving and therefore always delivers a packet if it has one available.
7502 +On enqueueing, each packet is assigned to a hash bucket, based on
7508 +Destination address
7513 +If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP.
7514 +Packets with other protocols are hashed based on the 32bits representation of their
7515 +destination and the socket they belong to. A flow corresponds mostly to a TCP/IP
7518 +Each of these buckets should represent a unique flow. Because multiple flows may
7519 +get hashed to the same bucket, the hashing algorithm is perturbed at configurable
7520 +intervals so that the unfairness lasts only for a short while. Perturbation may
7521 +however cause some inadvertent packet reordering to occur.
7523 +When dequeuing, each hashbucket with data is queried in a round robin fashion.
7525 +The compile time maximum length of the SFQ is 128 packets, which can be spread over
7526 +at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed
7527 +on the fullest bucket, thus maintaining fairness.
7532 +Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that
7533 +no perturbation occurs. Do not set too low for each perturbation may cause some packet
7534 +reordering. Advised value: 10
7537 +Amount of bytes a flow is allowed to dequeue during a round of the round robin process.
7538 +Defaults to the MTU of the interface which is also the advised value and the minimum value.
7540 +.SH EXAMPLE & USAGE
7542 +To attach to device ppp0:
7544 +# tc qdisc add dev ppp0 root sfq perturb 10
7546 +Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful
7547 +if it owns the queue.
7548 +This is the case when the link speed equals the actually available bandwidth. This holds
7549 +for regular phone modems, ISDN connections and direct non-switched ethernet links.
7551 +Most often, cable modems and DSL devices do not fall into this category. The same holds
7552 +for when connected to a switch and trying to send data to a congested segment also
7553 +connected to the switch.
7555 +In this case, the effective queue does not reside within Linux and is therefore not
7556 +available for scheduling.
7558 +Embed SFQ in a classful qdisc to make sure it owns the queue.
7563 +Paul E. McKenney "Stochastic Fairness Queuing",
7564 +IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.
7568 +Paul E. McKenney "Stochastic Fairness Queuing",
7569 +"Interworking: Research and Experience", v.2, 1991, p.113-131.
7574 +M. Shreedhar and George Varghese "Efficient Fair
7575 +Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
7581 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
7582 +bert hubert <ahu@ds9a.nl>
7585 diff -Naur iproute2-orig/debian/manpages/tc-tbf.8 iproute2/debian/manpages/tc-tbf.8
7586 --- iproute2-orig/debian/manpages/tc-tbf.8 1969-12-31 16:00:00.000000000 -0800
7587 +++ iproute2/debian/manpages/tc-tbf.8 2004-05-21 00:09:38.000000000 -0700
7589 +.TH TC 8 "13 December 2001" "iproute2" "Linux"
7591 +tbf \- Token Bucket Filter
7593 +.B tc qdisc ... tbf rate
7609 +burst is also known as buffer and maxburst. mtu is also known as minburst.
7612 +The Token Bucket Filter is a classless queueing discipline available for
7613 +traffic control with the
7617 +TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle
7618 +itself, although packets are available, to ensure that the configured rate is not exceeded.
7619 +On all platforms except for Alpha,
7620 +it is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness,
7621 +sending out data exactly at the configured rates.
7623 +Much higher rates are possible but at the cost of losing the minimal burstiness. In that
7624 +case, data is on average dequeued at the configured rate but may be sent much faster at millisecond
7625 +timescales. Because of further queues living in network adaptors, this is often not a problem.
7627 +Kernels with a higher 'HZ' can achieve higher rates with perfect burstiness. On Alpha, HZ is ten
7628 +times higher, leading to a 10mbit/s limit to perfection. These calculations hold for packets of on
7629 +average 1000 bytes.
7632 +As the name implies, traffic is filtered based on the expenditure of
7634 +Tokens roughly correspond to bytes, with the additional constraint that each packet consumes
7635 +some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies
7636 +the link for some time.
7638 +On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst
7639 +in one go. Tokens arrive at a steady rate, until the bucket is full.
7641 +If no tokens are available, packets are queued, up to a configured limit. The TBF now
7642 +calculates the token deficit, and throttles until the first packet in the queue can be sent.
7644 +If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured
7645 +to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF
7646 +with a very small bucket, so that it doesn't burst.
7648 +To achieve perfection, the second bucket may contain only a single packet, which leads to
7649 +the earlier mentioned 1mbit/s limit.
7651 +This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends
7652 +on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100
7653 +packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.
7658 +for how to specify the units of these values.
7661 +Limit is the number of bytes that can be queued waiting for tokens to become
7662 +available. You can also specify this the other way around by setting the
7663 +latency parameter, which specifies the maximum amount of time a packet can
7664 +sit in the TBF. The latter calculation takes into account the size of the
7665 +bucket, the rate and possibly the peakrate (if set). These two parameters
7666 +are mutually exclusive.
7669 +Also known as buffer or maxburst.
7670 +Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously.
7671 +In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer
7672 +if you want to reach your configured rate!
7674 +If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
7675 +The minimum buffer size can be calculated by dividing the rate by HZ.
7677 +Token usage calculations are performed using a table which by default has a resolution of 8 packets.
7678 +This resolution can be changed by specifying the
7680 +size with the burst. For example, to specify a 6000 byte buffer with a 16
7681 +byte cell size, set a burst of 6000/16. You will probably never have to set
7682 +this. Must be an integral power of 2.
7685 +A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit
7686 +determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
7689 +The speed knob. See remarks above about limits! See
7693 +Furthermore, if a peakrate is desired, the following parameters are available:
7697 +Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does
7698 +not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
7702 +Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
7703 +If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
7704 +allows around 3mbit/s of peakrate, given 1000 byte packets.
7706 +Like the regular burstsize you can also specify a
7709 +.SH EXAMPLE & USAGE
7711 +To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s,
7712 +a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes
7713 +at most 70ms of latency, with perfect peakrate behaviour, issue:
7715 +# tc qdisc add dev eth0 root tbf rate 0.5mbit \\
7716 + burst 5kb latency 70ms peakrate 1mbit \\
7723 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
7724 +bert hubert <ahu@ds9a.nl>
7727 diff -Naur iproute2-orig/debian/manpages/tc.8 iproute2/debian/manpages/tc.8
7728 --- iproute2-orig/debian/manpages/tc.8 1969-12-31 16:00:00.000000000 -0800
7729 +++ iproute2/debian/manpages/tc.8 2004-05-21 00:09:38.000000000 -0700
7731 +.TH TC 8 "16 December 2001" "iproute2" "Linux"
7733 +tc \- show / manipulate traffic control settings
7735 +.B tc qdisc [ add | change | replace | link ] dev
7743 +[ qdisc specific parameters ]
7746 +.B tc class [ add | change | replace ] dev
7752 +[ qdisc specific parameters ]
7755 +.B tc filter [ add | change | replace ] dev
7759 +.B | root ] protocol
7762 +priority filtertype
7763 +[ filtertype specific parameters ]
7767 +.B tc [-s | -d ] qdisc show [ dev
7771 +.B tc [-s | -d ] class show dev
7774 +.B tc filter show dev
7779 +is used to configure Traffic Control in the Linux kernel. Traffic Control consists
7784 +When traffic is shaped, its rate of transmission is under control. Shaping may
7785 +be more than lowering the available bandwidth - it is also used to smooth out
7786 +bursts in traffic for better network behaviour. Shaping occurs on egress.
7790 +By scheduling the transmission of packets it is possible to improve interactivity
7791 +for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
7792 +is also called prioritizing, and happens only on egress.
7796 +Where shaping deals with transmission of traffic, policing pertains to traffic
7797 +arriving. Policing thus occurs on ingress.
7801 +Traffic exceeding a set bandwidth may also be dropped forthwith, both on
7802 +ingress and on egress.
7805 +Processing of traffic is controlled by three kinds of objects: qdiscs,
7806 +classes and filters.
7810 +is short for 'queueing discipline' and it is elementary to
7811 +understanding traffic control. Whenever the kernel needs to send a
7812 +packet to an interface, it is
7814 +to the qdisc configured for that interface. Immediately afterwards, the kernel
7815 +tries to get as many packets as possible from the qdisc, for giving them
7816 +to the network adaptor driver.
7818 +A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure
7819 +First In, First Out queue. It does however store traffic when the network interface
7820 +can't handle it momentarily.
7823 +Some qdiscs can contain classes, which contain further qdiscs - traffic may
7824 +then be enqueued in any of the inner qdiscs, which are within the
7826 +When the kernel tries to dequeue a packet from such a
7828 +it can come from any of the classes. A qdisc may for example prioritize
7829 +certain kinds of traffic by trying to dequeue from certain classes
7835 +is used by a classful qdisc to determine in which class a packet will
7836 +be enqueued. Whenever traffic arrives at a class with subclasses, it needs
7837 +to be classified. Various methods may be employed to do so, one of these
7838 +are the filters. All filters attached to the class are called, until one of
7839 +them returns with a verdict. If no verdict was made, other criteria may be
7840 +available. This differs per qdisc.
7842 +It is important to notice that filters reside
7844 +qdiscs - they are not masters of what happens.
7846 +.SH CLASSLESS QDISCS
7847 +The classless qdiscs are:
7850 +Simplest usable qdisc, pure First In, First Out behaviour. Limited in
7851 +packets or in bytes.
7854 +Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
7855 +queue which honors Type of Service flags, as well as the priority that may be
7856 +assigned to a packet.
7859 +Random Early Detection simulates physical congestion by randomly dropping
7860 +packets when nearing configured bandwidth allocation. Well suited to very
7861 +large bandwidth applications.
7864 +Stochastic Fairness Queueing reorders queued traffic so each 'session'
7865 +gets to send a packet in turn.
7868 +The Token Bucket Filter is suited for slowing traffic down to a precisely
7869 +configured rate. Scales well to large bandwidths.
7870 +.SH CONFIGURING CLASSLESS QDISCS
7871 +In the absence of classful qdiscs, classless qdiscs can only be attached at
7872 +the root of a device. Full syntax:
7874 +.B tc qdisc add dev
7877 +QDISC QDISC-PARAMETERS
7881 +.B tc qdisc del dev
7887 +qdisc is the automatic default in the absence of a configured qdisc.
7889 +.SH CLASSFUL QDISCS
7890 +The classful qdiscs are:
7893 +Class Based Queueing implements a rich linksharing hierarchy of classes.
7894 +It contains shaping elements as well as prioritizing capabilities. Shaping is
7895 +performed using link idle time calculations based on average packet size and
7896 +underlying link bandwidth. The latter may be ill-defined for some interfaces.
7899 +The Hierarchy Token Bucket implements a rich linksharing hierarchy of
7900 +classes with an emphasis on conforming to existing practices. HTB facilitates
7901 +guaranteeing bandwidth to classes, while also allowing specification of upper
7902 +limits to inter-class sharing. It contains shaping elements, based on TBF and
7903 +can prioritize classes.
7906 +The PRIO qdisc is a non-shaping container for a configurable number of
7907 +classes which are dequeued in order. This allows for easy prioritization
7908 +of traffic, where lower classes are only able to send if higher ones have
7909 +no packets available. To facilitate configuration, Type Of Service bits are
7910 +honored by default.
7911 +.SH THEORY OF OPERATION
7912 +Classes form a tree, where each class has a single parent.
7913 +A class may have multiple children. Some qdiscs allow for runtime addition
7914 +of classes (CBQ, HTB) while others (PRIO) are created with a static number of
7917 +Qdiscs which allow dynamic addition of classes can have zero or more
7918 +subclasses to which traffic may be enqueued.
7920 +Furthermore, each class contains a
7922 +which by default has
7924 +behaviour though another qdisc can be attached in place. This qdisc may again
7925 +contain classes, but each class can have only one leaf qdisc.
7927 +When a packet enters a classful qdisc it can be
7929 +to one of the classes within. Three criteria are available, although not all
7930 +qdiscs will use all three:
7933 +If tc filters are attached to a class, they are consulted first
7934 +for relevant instructions. Filters can match on all fields of a packet header,
7935 +as well as on the firewall mark applied by ipchains or iptables. See
7936 +.BR tc-filters (8).
7939 +Some qdiscs have built in rules for classifying packets based on the TOS field.
7942 +Userspace programs can encode a class-id in the 'skb->priority' field using
7943 +the SO_PRIORITY option.
7945 +Each node within the tree can have its own filters but higher level filters
7946 +may also point directly to lower classes.
7948 +If classification did not succeed, packets are enqueued to the leaf qdisc
7949 +attached to that class. Check qdisc specific manpages for details, however.
7952 +All qdiscs, classes and filters have IDs, which can either be specified
7953 +or be automatically assigned.
7955 +IDs consist of a major number and a minor number, separated by a colon.
7959 +A qdisc, which potentially can have children,
7960 +gets assigned a major number, called a 'handle', leaving the minor
7961 +number namespace available for classes. The handle is expressed as '10:'.
7962 +It is customary to explicitly assign a handle to qdiscs expected to have
7967 +Classes residing under a qdisc share their qdisc major number, but each have
7968 +a separate minor number called a 'classid' that has no relation to their
7969 +parent classes, only to their parent qdisc. The same naming custom as for
7974 +Filters have a three part ID, which is only needed when using a hashed
7975 +filter hierarchy, for which see
7976 +.BR tc-filters (8).
7978 +All parameters accept a floating point number, possibly followed by a unit.
7980 +Bandwidths or rates can be specified in:
7983 +Kilobytes per second
7986 +Megabytes per second
7989 +Kilobits per second
7992 +Megabits per second
7994 +bps or a bare number
7997 +Amounts of data can be specified in:
8014 +Lengths of time can be specified in:
8022 +us, usec, usecs or a bare number
8026 +The following commands are available for qdiscs, classes and filter:
8029 +Add a qdisc, class or filter to a node. For all entities, a
8031 +must be passed, either by passing its ID or by attaching directly to the root of a device.
8032 +When creating a qdisc or a filter, it can be named with the
8034 +parameter. A class is named with the
8040 +A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs
8041 +are automatically deleted, as well as any filters attached to them.
8045 +Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
8046 +that the handle cannot be changed and neither can the parent. In other words,
8049 +cannot move a node.
8053 +Performs a nearly atomic remove/add on an existing node id. If the node does not exist yet
8058 +Only available for qdiscs and performs a replace where the node
8059 +must exist already.
8064 +was written by Alexey N. Kuznetsov and added in Linux 2.2.
8073 +.BR tc-pfifo_fast (8),
8077 +Manpage maintained by bert hubert (ahu@ds9a.nl)
8079 diff -Naur iproute2-orig/debian/postinst iproute2/debian/postinst
8080 --- iproute2-orig/debian/postinst 1969-12-31 16:00:00.000000000 -0800
8081 +++ iproute2/debian/postinst 2004-05-21 00:09:38.000000000 -0700
8086 +if [ "$1" = "configure" -a -d /usr/doc -a ! -e /usr/doc/iproute ]; then
8087 + ln -sf ../share/doc/iproute /usr/doc/iproute
8089 diff -Naur iproute2-orig/debian/postrm iproute2/debian/postrm
8090 --- iproute2-orig/debian/postrm 1969-12-31 16:00:00.000000000 -0800
8091 +++ iproute2/debian/postrm 2004-05-21 00:09:38.000000000 -0700
8095 +if [ "$1" = "purge" ]
8097 + rm -rf /etc/iproute2
8099 diff -Naur iproute2-orig/debian/prerm iproute2/debian/prerm
8100 --- iproute2-orig/debian/prerm 1969-12-31 16:00:00.000000000 -0800
8101 +++ iproute2/debian/prerm 2004-05-21 00:09:38.000000000 -0700
8105 +if [ \( "$1" = "upgrade" -o "$1" = "remove" \) -a -L /usr/doc/iproute ]; then
8106 + rm -f /usr/doc/iproute
8108 diff -Naur iproute2-orig/debian/rules iproute2/debian/rules
8109 --- iproute2-orig/debian/rules 1969-12-31 16:00:00.000000000 -0800
8110 +++ iproute2/debian/rules 2004-05-21 00:09:38.000000000 -0700
8114 +# Copyright (C) 1999 Roberto Lumbreras <rover@debian.org>
8115 +# Copyright (C) 1999-2002 Juan Cespedes <cespedes@debian.org>
8120 +PACKAGE = $(shell perl -e 'print <> =~ /^(.*) \(.*\)/' debian/changelog)
8121 +PKG_VER = $(shell perl -e 'print <> =~ /\((.*)\)/' debian/changelog)
8122 +PKG_UPVER= $(shell perl -e 'print <> =~ /\((.*)-[^-]*\)/' debian/changelog)
8125 +SBINS = ip/rtmon ip/rtacct tc/tc
8126 +SHBINS = ip/routef ip/routel # ip/ifcfg ip/rtpr
8127 +DOCS = README* doc/Plan debian/README.Debian
8128 +MAN8 = debian/manpages/*.8
8129 +MANLINKS= rtmon rtacct routef routel
8130 +TEXDOCS = ip-cref ip-tunnels api-ip6-flowlabels
8135 + test -f include-glibc/netinet/in.h.orig || \
8136 + mv include-glibc/netinet/in.h \
8137 + include-glibc/netinet/in.h.orig
8138 + $(MAKE) KERNEL_INCLUDE=/usr/include
8142 +binary: binary-indep binary-arch
8146 +binary-arch: checkroot stamp-build
8147 + $(RM) -r debian/tmp
8148 + install -d -m0755 debian/tmp/{DEBIAN,bin,sbin,usr/{bin,share/doc/$(PACKAGE),share/man/man{7,8}}}
8149 + install -s -m0755 $(BINS) debian/tmp/bin/
8150 + install -s -m0755 $(SBINS) debian/tmp/sbin/
8151 + ln -s /bin/ip debian/tmp/sbin/ip
8152 + install -m0755 $(SHBINS) debian/tmp/usr/bin/
8153 + cp -p $(DOCS) debian/tmp/usr/share/doc/$(PACKAGE)/
8154 + cp -rp examples debian/tmp/usr/share/doc/$(PACKAGE)/
8155 + find debian/tmp/usr/share/doc/$(PACKAGE)/examples -type f -exec chmod -x {} \;
8156 + install -m0644 debian/changelog debian/tmp/usr/share/doc/$(PACKAGE)/changelog.Debian
8157 + cp -p RELNOTES debian/tmp/usr/share/doc/$(PACKAGE)/changelog
8158 + for i in $(TEXDOCS); do \
8159 + install -m0644 doc/$$i.tex debian/tmp/usr/share/doc/$(PACKAGE)/; \
8160 + install -m0644 doc/$$i.dvi debian/tmp/usr/share/doc/$(PACKAGE)/; \
8161 + install -m0644 doc/$$i.ps debian/tmp/usr/share/doc/$(PACKAGE)/; \
8163 + install -m0644 $(MAN8) debian/tmp/usr/share/man/man8/
8164 + gzip -9fr debian/tmp/usr/share || true
8165 + ln -s tc-pbfifo.8.gz debian/tmp/usr/share/man/man8/tc-pfifo.8.gz
8166 + ln -s tc-pbfifo.8.gz debian/tmp/usr/share/man/man8/tc-bfifo.8.gz
8167 + for i in $(MANLINKS); do \
8168 + ln -s ../man7/undocumented.7.gz debian/tmp/usr/share/man/man8/$$i.8.gz; \
8170 + cp -p debian/copyright debian/tmp/usr/share/doc/$(PACKAGE)/
8171 + cp -rp etc debian/tmp/
8172 + install -m0644 debian/conffiles debian/tmp/DEBIAN/
8174 + dpkg-shlibdeps $(BINS) $(SBINS)
8175 + dpkg-gencontrol -isp
8176 + chown -R root.root debian/tmp
8177 + chmod -R u=rwX,go=rX debian/tmp
8178 + dpkg --build debian/tmp ..
8181 + @test -f debian/rules
8183 +checkroot: checkdir
8184 + @test 0 = `id -u` || { echo "Error: not super-user"; exit 1; }
8186 +clean: checkdir debian/control
8187 + $(RM) stamp-build debian/files debian/substvars
8189 + $(MAKE) -C doc clean
8190 + $(RM) `find . -name "*~" -o -name core`
8191 + $(RM) -r debian/tmp
8192 + test -f include-glibc/netinet/in.h.orig && \
8193 + mv include-glibc/netinet/in.h.orig \
8194 + include-glibc/netinet/in.h || true
8196 +.PHONY: build binary binary-arch binary-indep checkdir checkroot clean
8197 diff -Naur iproute2-orig/debian/tc-cbq.8 iproute2/debian/tc-cbq.8
8198 --- iproute2-orig/debian/tc-cbq.8 1969-12-31 16:00:00.000000000 -0800
8199 +++ iproute2/debian/tc-cbq.8 2004-05-21 00:09:38.000000000 -0700
8201 +.TH CBQ 8 "16 December 2001" "iproute2" "Linux"
8203 +CBQ \- Class Based Queueing
8205 +.B tc qdisc ... dev
8209 +.B | root) [ handle
8225 +.B tc class ... dev
8253 +.B ] [ bounded isolated ] [ split
8258 +interval timeconstant
8262 +Class Based Queueing is a classful qdisc that implements a rich
8263 +linksharing hierarchy of classes. It contains shaping elements as
8264 +well as prioritizing capabilities. Shaping is performed using link
8265 +idle time calculations based on the timing of dequeue events and
8266 +underlying link bandwidth.
8268 +.SH SHAPING ALGORITHM
8269 +When shaping a 10mbit/s connection to 1mbit/s, the link will
8270 +be idle 90% of the time. If it isn't, it needs to be throttled so that it
8271 +IS idle 90% of the time.
8273 +During operations, the effective idletime is measured using an
8274 +exponential weighted moving average (EWMA), which considers recent
8275 +packets to be exponentially more important than past ones. The Unix
8276 +loadaverage is calculated in the same way.
8278 +The calculated idle time is subtracted from the EWMA measured one,
8279 +the resulting number is called 'avgidle'. A perfectly loaded link has
8280 +an avgidle of zero: packets arrive exactly at the calculated
8283 +An overloaded link has a negative avgidle and if it gets too negative,
8284 +CBQ throttles and is then 'overlimit'.
8286 +Conversely, an idle link might amass a huge avgidle, which would then
8287 +allow infinite bandwidths after a few hours of silence. To prevent
8288 +this, avgidle is capped at
8291 +If overlimit, in theory, the CBQ could throttle itself for exactly the
8292 +amount of time that was calculated to pass between packets, and then
8293 +pass one packet, and throttle again. Due to timer resolution constraints,
8294 +this may not be feasible, see the
8299 +Within the one CBQ instance many classes may exist. Each of these classes
8300 +contains another qdisc, by default
8303 +When enqueueing a packet, CBQ starts at the root and uses various methods to
8304 +determine which class should receive the data.
8306 +In the absence of uncommon configuration options, the process is rather easy.
8307 +At each node we look for an instruction, and then go to the class the
8308 +instruction refers us to. If the class found is a barren leaf-node (without
8309 +children), we enqueue the packet there. If it is not yet a leaf node, we do
8310 +the whole thing over again starting from that node.
8312 +The following actions are performed, in order at each node we visit, until one
8313 +sends us to another node, or terminates the process.
8316 +Consult filters attached to the class. If sent to a leafnode, we are done.
8317 +Otherwise, restart.
8320 +Consult the defmap for the priority assigned to this packet, which depends
8321 +on the TOS bits. Check if the referral is leafless, otherwise restart.
8324 +Ask the defmap for instructions for the 'best effort' priority. Check the
8325 +answer for leafness, otherwise restart.
8328 +If none of the above returned with an instruction, enqueue at this node.
8330 +This algorithm makes sure that a packet always ends up somewhere, even while
8331 +you are busy building your configuration.
8333 +For more details, see
8334 +.BR tc-cbq-details(8).
8336 +.SH LINK SHARING ALGORITHM
8337 +When dequeuing for sending to the network device, CBQ decides which of its
8338 +classes will be allowed to send. It does so with a Weighted Round Robin process
8339 +in which each class with packets gets a chance to send in turn. The WRR process
8340 +starts by asking the highest priority classes (lowest numerically -
8341 +highest semantically) for packets, and will continue to do so until they
8342 +have no more data to offer, in which case the process repeats for lower
8345 +Classes by default borrow bandwidth from their siblings. A class can be
8346 +prevented from doing so by declaring it 'bounded'. A class can also indicate
8347 +its unwillingness to lend out bandwidth by being 'isolated'.
8350 +The root of a CBQ qdisc class tree has the following parameters:
8353 +parent major:minor | root
8354 +This mandatory parameter determines the place of the CBQ instance, either at the
8356 +of an interface or within an existing class.
8359 +Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
8360 +of a major number, followed by a colon. Optional, but very useful if classes
8361 +will be generated within this qdisc.
8364 +This allotment is the 'chunkiness' of link sharing and is used for determining packet
8365 +transmission time tables. The qdisc allot differs slightly from the class allot discussed
8366 +below. Optional. Defaults to a reasonable value, related to avpkt.
8369 +The average size of a packet is needed for calculating maxidle, and is also used
8370 +for making sure 'allot' has a safe value. Mandatory.
8373 +To determine the idle time, CBQ must know the bandwidth of your underlying
8374 +physical interface, or parent qdisc. This is a vital parameter, more about it
8378 +The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
8381 +A zero sized packet may still take time to transmit. This value is the lower
8382 +cap for packet transmission time calculations - packets smaller than this value
8383 +are still deemed to have this size. Defaults to zero.
8386 +When CBQ needs to measure the average idle time, it does so using an
8387 +Exponentially Weighted Moving Average which smoothes out measurements into
8388 +a moving average. The EWMA LOG determines how much smoothing occurs. Lower
8389 +values imply greater sensitivity. Must be between 0 and 31. Defaults
8392 +A CBQ qdisc does not shape out of its own accord. It only needs to know certain
8393 +parameters about the underlying link. Actual shaping is done in classes.
8396 +Classes have a host of parameters to configure their operation.
8400 +Place of this class within the hierarchy. If attached directly to a qdisc
8401 +and not to another class, minor can be omitted. Mandatory.
8403 +classid major:minor
8404 +Like qdiscs, classes can be named. The major number must be equal to the
8405 +major number of the qdisc to which it belongs. Optional, but needed if this
8406 +class is going to have children.
8409 +When dequeuing to the interface, classes are tried for traffic in a
8410 +round-robin fashion. Classes with a higher configured qdisc will generally
8411 +have more traffic to offer during each round, so it makes sense to allow
8412 +it to dequeue more traffic. All weights under a class are normalized, so
8413 +only the ratios matter. Defaults to the configured rate, unless the priority
8414 +of this class is maximal, in which case it is set to 1.
8417 +Allot specifies how many bytes a qdisc can dequeue
8418 +during each round of the process. This parameter is weighted using the
8419 +renormalized class weight described above. Silently capped at a minimum of
8420 +3/2 avpkt. Mandatory.
8424 +In the round-robin process, classes with the lowest priority field are tried
8425 +for packets first. Mandatory.
8429 +See the QDISC section.
8433 +Maximum rate this class and all its children combined can send at. Mandatory.
8437 +This is different from the bandwidth specified when creating a CBQ disc! Only
8438 +used to determine maxidle and offtime, which are only calculated when
8439 +specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
8443 +This number of packets is used to calculate maxidle so that when
8444 +avgidle is at maxidle, this number of average packets can be burst
8445 +before avgidle drops to 0. Set it higher to be more tolerant of
8446 +bursts. You can't set maxidle directly, only via this parameter.
8450 +As mentioned before, CBQ needs to throttle in case of
8451 +overlimit. The ideal solution is to do so for exactly the calculated
8452 +idle time, and pass 1 packet. However, Unix kernels generally have a
8453 +hard time scheduling events shorter than 10ms, so it is better to
8454 +throttle for a longer period, and then pass minburst packets in one
8455 +go, and then sleep minburst times longer.
8457 +The time to wait is called the offtime. Higher values of minburst lead
8458 +to more accurate shaping in the long term, but to bigger bursts at
8459 +millisecond timescales. Optional.
8463 +If avgidle is below 0, we are overlimits and need to wait until
8464 +avgidle will be big enough to send one packet. To prevent a sudden
8465 +burst from shutting down the link for a prolonged period of time,
8466 +avgidle is reset to minidle if it gets too low.
8468 +Minidle is specified in negative microseconds, so 10 means that
8469 +avgidle is capped at -10us. Optional.
8473 +Signifies that this class will not borrow bandwidth from its siblings.
8476 +Means that this class will not borrow bandwidth to its siblings
8479 +split major:minor & defmap bitmap[/bitmap]
8480 +If consulting filters attached to a class did not give a verdict,
8481 +CBQ can also classify based on the packet's priority. There are 16
8482 +priorities available, numbered from 0 to 15.
8484 +The defmap specifies which priorities this class wants to receive,
8485 +specified as a bitmap. The Least Significant Bit corresponds to priority
8488 +parameter tells CBQ at which class the decision must be made, which should
8489 +be a (grand)parent of the class you are adding.
8491 +As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
8492 +configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
8494 +The complimentary configuration would then
8495 +be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
8496 +Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
8498 +estimator interval timeconstant
8499 +CBQ can measure how much bandwidth each class is using, which tc filters
8500 +can use to classify packets with. In order to determine the bandwidth
8501 +it uses a very simple estimator that measures once every
8503 +microseconds how much traffic has passed. This again is a EWMA, for which
8504 +the time constant can be specified, also in microseconds. The
8506 +corresponds to the sluggishness of the measurement or, conversely, to the
8507 +sensitivity of the average to short bursts. Higher values mean less
8511 +The actual bandwidth of the underlying link may not be known, for example
8512 +in the case of PPoE or PPTP connections which in fact may send over a
8513 +pipe, instead of over a physical device. CBQ is quite resilient to major
8514 +errors in the configured bandwidth, probably a the cost of coarser shaping.
8516 +Default kernels rely on coarse timing information for making decisions. These
8517 +may make shaping precise in the long term, but inaccurate on second long scales.
8520 +.BR tc-cbq-details(8)
8521 +for hints on how to improve this.
8526 +Sally Floyd and Van Jacobson, "Link-sharing and Resource
8527 +Management Models for Packet Networks",
8528 +IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
8532 +Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
8536 +Sally Floyd, "Notes on Class-Based Queueing: Setting
8541 +Sally Floyd and Michael Speer, "Experimental Results
8542 +for Class-Based Queueing", 1998, not published.
8550 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
8551 +bert hubert <ahu@ds9a.nl>
8554 diff -Naur iproute2-orig/debian/tc-htb.8 iproute2/debian/tc-htb.8
8555 --- iproute2-orig/debian/tc-htb.8 1969-12-31 16:00:00.000000000 -0800
8556 +++ iproute2/debian/tc-htb.8 2004-05-21 00:09:38.000000000 -0700
8558 +.TH HTB 8 "10 January 2002" "iproute2" "Linux"
8560 +HTB \- Hierarchy Token Bucket
8562 +.B tc qdisc ... dev
8566 +.B | root) [ handle
8572 +.B tc class ... dev
8591 +HTB is meant as a more understandable and intuitive replacement for
8592 +the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
8593 +of the outbound bandwidth on a given link. Both allow you to use one
8594 +physical link to simulate several slower links and to send different
8595 +kinds of traffic on different simulated links. In both cases, you have
8596 +to specify how to divide the physical link into simulated links and
8597 +how to decide which simulated link to use for a given packet to be sent.
8599 +Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm
8600 +which does not depend on interface characteristics and so does not need to
8601 +know the underlying bandwidth of the outgoing interface.
8603 +.SH SHAPING ALGORITHM
8604 +Shaping works as documented in
8608 +Within the one HRB instance many classes may exist. Each of these classes
8609 +contains another qdisc, by default
8612 +When enqueueing a packet, HTB starts at the root and uses various methods to
8613 +determine which class should receive the data.
8615 +In the absence of uncommon configuration options, the process is rather easy.
8616 +At each node we look for an instruction, and then go to the class the
8617 +instruction refers us to. If the class found is a barren leaf-node (without
8618 +children), we enqueue the packet there. If it is not yet a leaf node, we do
8619 +the whole thing over again starting from that node.
8621 +The following actions are performed, in order at each node we visit, until one
8622 +sends us to another node, or terminates the process.
8625 +Consult filters attached to the class. If sent to a leafnode, we are done.
8626 +Otherwise, restart.
8629 +If none of the above returned with an instruction, enqueue at this node.
8631 +This algorithm makes sure that a packet always ends up somewhere, even while
8632 +you are busy building your configuration.
8634 +.SH LINK SHARING ALGORITHM
8638 +The root of a CBQ qdisc class tree has the following parameters:
8641 +parent major:minor | root
8642 +This mandatory parameter determines the place of the CBQ instance, either at the
8644 +of an interface or within an existing class.
8647 +Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
8648 +of a major number, followed by a colon. Optional, but very useful if classes
8649 +will be generated within this qdisc.
8652 +Unclassified traffic gets sent to the class with this minor-id.
8655 +Classes have a host of parameters to configure their operation.
8659 +Place of this class within the hierarchy. If attached directly to a qdisc
8660 +and not to another class, minor can be omitted. Mandatory.
8662 +classid major:minor
8663 +Like qdiscs, classes can be named. The major number must be equal to the
8664 +major number of the qdisc to which it belongs. Optional, but needed if this
8665 +class is going to have children.
8668 +In the round-robin process, classes with the lowest priority field are tried
8669 +for packets first. Mandatory.
8673 +Maximum rate this class and all its children are guaranteed. Mandatory.
8677 +Maximum rate at which a class can send, if its parent has bandwidth to spare.
8678 +Defaults to the configured rate, which implies no borrowing
8682 +Amount of bytes that can be burst at
8684 +speed, in excess of the configured
8686 +Should be at least as high as the highest burst of all children.
8690 +Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
8691 +as the interface can transmit them. For perfect evening out, should be equal to at most one average
8692 +packet. Should be at least as high as the highest cburst of all children.
8695 +Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel,
8696 +there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
8697 +From this, the mininum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte
8698 +burst as 100*12kb*8 equals 10mbit.
8701 +Not in the stock kernel yet.
8706 +HTB website: http://luxik.cdi.cz/~devik/qos/htb/
8708 +Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
8711 diff -Naur iproute2-orig/debian/tc-pbfifo.8 iproute2/debian/tc-pbfifo.8
8712 --- iproute2-orig/debian/tc-pbfifo.8 1969-12-31 16:00:00.000000000 -0800
8713 +++ iproute2/debian/tc-pbfifo.8 2004-05-21 00:09:38.000000000 -0700
8715 +.TH PBFIFO 8 "10 January 2002" "iproute2" "Linux"
8717 +pfifo \- Packet limited First In, First Out queue
8719 +bfifo \- Byte limited First In, First Out queue
8722 +.B tc qdisc ... add pfifo
8727 +.B tc qdisc ... add bfifo
8733 +The pfifo and bfifo qdiscs are unadorned First In, First Out queues. They are the
8734 +simplest queues possible and therefore have no overhead.
8736 +constrains the queue size as measured in packets.
8738 +does so as measured in bytes.
8740 +Like all non-default qdiscs, they maintain statistics. This might be a reason to prefer
8741 +pfifo or bfifo over the default.
8744 +A list of packets is maintained, when a packet is enqueued it gets inserted at the tail of
8745 +a list. When a packet needs to be sent out to the network, it is taken from the head of the list.
8747 +If the list is too long, no further packets are allowed on. This is called 'tail drop'.
8752 +Maximum queue size. Specified in bytes for bfifo, in packets for pfifo. For pfifo, defaults
8753 +to the interface txqueuelen, as specified with
8758 +For bfifo, it defaults to the txqueuelen multiplied by the interface MTU.
8763 +contains the limit, either in packets or in bytes, and the number of bytes
8764 +and packets actually sent. An unsent and dropped packet only appears between braces
8765 +and is not counted as 'Sent'.
8767 +In this example, the queue length is 100 packets, 45894 bytes were sent over 681 packets.
8768 +No packets were dropped, and as the pfifo queue does not slow down packets, there were also no
8772 +# tc -s qdisc ls dev eth0
8773 +qdisc pfifo 8001: dev eth0 limit 100p
8774 + Sent 45894 bytes 681 pkts (dropped 0, overlimits 0)
8777 +If a backlog occurs, this is displayed as well.
8782 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
8784 +This manpage maintained by bert hubert <ahu@ds9a.nl>
8787 diff -Naur iproute2-orig/debian/tc-pfifo_fast.8 iproute2/debian/tc-pfifo_fast.8
8788 --- iproute2-orig/debian/tc-pfifo_fast.8 1969-12-31 16:00:00.000000000 -0800
8789 +++ iproute2/debian/tc-pfifo_fast.8 2004-05-21 00:09:38.000000000 -0700
8791 +.TH PFIFO_FAST 8 "10 January 2002" "iproute2" "Linux"
8793 +pfifo_fast \- three-band first in, first out queue
8796 +pfifo_fast is the default qdisc of each interface.
8798 +Whenever an interface is created, the pfifo_fast qdisc is automatically used
8799 +as a queue. If another qdisc is attached, it preempts the default
8800 +pfifo_fast, which automatically returns to function when an existing qdisc
8803 +In this sense this qdisc is magic, and unlike other qdiscs.
8806 +The algorithm is very similar to that of the classful
8812 +queues side by side, where packets can be enqueued in any of the three bands
8813 +based on their Type of Service bits or assigned priority.
8815 +Not all three bands are dequeued simultaneously - as long as lower bands
8816 +have traffic, higher bands are never dequeued. This can be used to
8817 +prioritize interactive traffic or penalize 'lowest cost' traffic.
8819 +Each band can be txqueuelen packets long, as configured with
8823 +Additional packets coming in are not enqueued but are instead dropped.
8827 +for complete details on how TOS bits are translated into bands.
8831 +The length of the three bands depends on the interface txqueuelen, as
8838 +Does not maintain statistics and does not show up in tc qdisc ls. This is because
8839 +it is the automatic default in the absence of a configured qdisc.
8845 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
8847 +This manpage maintained by bert hubert <ahu@ds9a.nl>
8850 diff -Naur iproute2-orig/debian/tc-prio.8 iproute2/debian/tc-prio.8
8851 --- iproute2-orig/debian/tc-prio.8 1969-12-31 16:00:00.000000000 -0800
8852 +++ iproute2/debian/tc-prio.8 2004-05-21 00:09:38.000000000 -0700
8854 +.TH PRIO 8 "16 December 2001" "iproute2" "Linux"
8856 +PRIO \- Priority qdisc
8858 +.B tc qdisc ... dev
8862 +.B | root) [ handle
8869 +interval timeconstant
8873 +The PRIO qdisc is a simple classful queueing discipline that contains
8874 +an arbitrary number of classes of differing priority. The classes are
8875 +dequeued in numerical descending order of priority. PRIO is a scheduler
8876 +and never delays packets - it is a work-conserving qdisc, though the qdiscs
8877 +contained in the classes may not be.
8879 +Very useful for lowering latency when there is no need for slowing down
8883 +On creation with 'tc qdisc add', a fixed number of bands is created. Each
8884 +band is a class, although is not possible to add classes with 'tc qdisc
8885 +add', the number of bands to be created must instead be specified on the
8886 +commandline attaching PRIO to its root.
8888 +When dequeueing, band 0 is tried first and only if it did not deliver a
8889 +packet does PRIO try band 1, and so onwards. Maximum reliability packets
8890 +should therefore go to band 0, minimum delay to band 1 and the rest to band
8893 +As the PRIO qdisc itself will have minor number 0, band 0 is actually
8894 +major:1, band 1 is major:2, etc. For major, substitute the major number
8895 +assigned to the qdisc on 'tc qdisc add' with the
8900 +Three methods are available to PRIO to determine in which band a packet will
8904 +A process with sufficient privileges can encode the destination class
8905 +directly with SO_PRIORITY, see
8909 +A tc filter attached to the root qdisc can point traffic directly to a class
8912 +Based on the packet priority, which in turn is derived from the Type of
8913 +Service assigned to the packet.
8915 +Only the priomap is specific to this qdisc.
8916 +.SH QDISC PARAMETERS
8919 +Number of bands. If changed from the default of 3,
8921 +must be updated as well.
8924 +The priomap maps the priority of
8925 +a packet to a class. The priority can either be set directly from userspace,
8926 +or be derived from the Type of Service of the packet.
8928 +Determines how packet priorities, as assigned by the kernel, map to
8929 +bands. Mapping occurs based on the TOS octet of the packet, which looks like
8934 ++---+---+---+---+---+---+---+---+
8936 +|PRECEDENCE | TOS |MBZ|
8938 ++---+---+---+---+---+---+---+---+
8941 +The four TOS bits (the 'TOS field') are defined as:
8944 +Binary Decimcal Meaning
8945 +-----------------------------------------
8946 +1000 8 Minimize delay (md)
8947 +0100 4 Maximize throughput (mt)
8948 +0010 2 Maximize reliability (mr)
8949 +0001 1 Minimize monetary cost (mmc)
8950 +0000 0 Normal Service
8953 +As there is 1 bit to the right of these four bits, the actual value of the
8954 +TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the
8955 +value of the entire TOS field, not just the four bits. It is the value you
8956 +see in the first column of this table:
8959 +TOS Bits Means Linux Priority Band
8960 +------------------------------------------------------------
8961 +0x0 0 Normal Service 0 Best Effort 1
8962 +0x2 1 Minimize Monetary Cost 1 Filler 2
8963 +0x4 2 Maximize Reliability 0 Best Effort 1
8964 +0x6 3 mmc+mr 0 Best Effort 1
8965 +0x8 4 Maximize Throughput 2 Bulk 2
8966 +0xa 5 mmc+mt 2 Bulk 2
8967 +0xc 6 mr+mt 2 Bulk 2
8968 +0xe 7 mmc+mr+mt 2 Bulk 2
8969 +0x10 8 Minimize Delay 6 Interactive 0
8970 +0x12 9 mmc+md 6 Interactive 0
8971 +0x14 10 mr+md 6 Interactive 0
8972 +0x16 11 mmc+mr+md 6 Interactive 0
8973 +0x18 12 mt+md 4 Int. Bulk 1
8974 +0x1a 13 mmc+mt+md 4 Int. Bulk 1
8975 +0x1c 14 mr+mt+md 4 Int. Bulk 1
8976 +0x1e 15 mmc+mr+mt+md 4 Int. Bulk 1
8979 +The second column contains the value of the relevant
8980 +four TOS bits, followed by their translated meaning. For example, 15 stands
8981 +for a packet wanting Minimal Montetary Cost, Maximum Reliability, Maximum
8982 +Throughput AND Minimum Delay.
8984 +The fourth column lists the way the Linux kernel interprets the TOS bits, by
8985 +showing to which Priority they are mapped.
8987 +The last column shows the result of the default priomap. On the commandline,
8988 +the default priomap looks like this:
8990 + 1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
8992 +This means that priority 4, for example, gets mapped to band number 1.
8993 +The priomap also allows you to list higher priorities (> 7) which do not
8994 +correspond to TOS mappings, but which are set by other means.
8996 +This table from RFC 1349 (read it for more details) explains how
8997 +applications might very well set their TOS bits:
9000 +TELNET 1000 (minimize delay)
9002 + Control 1000 (minimize delay)
9003 + Data 0100 (maximize throughput)
9005 +TFTP 1000 (minimize delay)
9008 + Command phase 1000 (minimize delay)
9009 + DATA phase 0100 (maximize throughput)
9011 +Domain Name Service
9012 + UDP Query 1000 (minimize delay)
9014 + Zone Transfer 0100 (maximize throughput)
9016 +NNTP 0001 (minimize monetary cost)
9020 + Requests 0000 (mostly)
9021 + Responses <same as request> (mostly)
9026 +PRIO classes cannot be configured further - they are automatically created
9027 +when the PRIO qdisc is attached. Each class however can contain yet a
9031 +Large amounts of traffic in the lower bands can cause starvation of higher
9032 +bands. Can be prevented by attaching a shaper (for example,
9034 +to these bands to make sure they cannot dominate the link.
9037 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, J Hadi Salim
9038 +<hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>
9041 diff -Naur iproute2-orig/debian/tc-red.8 iproute2/debian/tc-red.8
9042 --- iproute2-orig/debian/tc-red.8 1969-12-31 16:00:00.000000000 -0800
9043 +++ iproute2/debian/tc-red.8 2004-05-21 00:09:38.000000000 -0700
9045 +.TH RED 8 "13 December 2001" "iproute2" "Linux"
9047 +red \- Random Early Detection
9049 +.B tc qdisc ... red
9060 +.B [ ecn ] [ bandwidth
9066 +Random Early Detection is a classless qdisc which manages its queue size
9067 +smartly. Regular queues simply drop packets from the tail when they are
9068 +full, which may not be the optimal behaviour. RED also performs tail drop,
9069 +but does so in a more gradual way.
9071 +Once the queue hits a certain average length, packets enqueued have a
9072 +configurable chance of being marked (which may mean dropped). This chance
9073 +increases linearly up to a point called the
9075 +average queue length, although the queue might get bigger.
9077 +This has a host of benefits over simple taildrop, while not being processor
9078 +intensive. It prevents synchronous retransmits after a burst in traffic,
9079 +which cause further retransmits, etc.
9081 +The goal is the have a small queue size, which is good for interactivity
9082 +while not disturbing TCP/IP traffic with too many sudden drops after a burst
9085 +Depending on 08 ECN is configured, marking either means dropping or
9086 +purely marking a packet as overlimit.
9088 +The average queue size is used for determining the marking
9089 +probability. This is calculated using an Exponential Weighted Moving
9090 +Average, which can be more or less sensitive to bursts.
9092 +When the average queue size is below
9094 +bytes, no packet will ever be marked. When it exceeds
9096 +the probability of doing so climbs linearly up
9099 +until the average queue size hits
9103 +is normally not set to 100%, the queue size might
9104 +conceivably rise above
9108 +parameter is provided to set a hard maximum for the size of the queue.
9113 +Average queue size at which marking becomes a possibility.
9116 +At this average queue size, the marking probability is maximal. Should be at
9119 +to prevent synchronous retransmits, higher for low
9123 +Maximum probability for marking, specified as a floating point
9124 +number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
9128 +Hard limit on the real (not average) queue size in bytes. Further packets
9129 +are dropped. Should be set higher than max+burst. It is advised to set this
9130 +a few times higher than
9134 +Used for determining how fast the average queue size is influenced by the
9135 +real queue size. Larger values make the calculation more sluggish, allowing
9136 +longer bursts of traffic before marking starts. Real life experiments
9137 +support the following guideline: (min+min+max)/(3*avpkt).
9140 +Specified in bytes. Used with burst to determine the time constant for
9141 +average queue size calculations. 1000 is a good value.
9144 +This rate is used for calculating the average queue size after some
9145 +idle time. Should be set to the bandwidth of your interface. Does not mean
9146 +that RED will shape for you! Optional.
9149 +As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion
9150 +Notification allows RED to notify remote hosts that their rate exceeds the
9151 +amount of bandwidth available. Non-ECN capable hosts can only be notified by
9152 +dropping a packet. If this parameter is specified, packets which indicate
9153 +that their hosts honor ECN will only be marked and not dropped, unless the
9156 +bytes. Needs a tc binary with RED support compiled in. Recommended.
9164 +Floyd, S., and Jacobson, V., Random Early Detection gateways for
9165 +Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html
9168 +Some changes to the algorithm by Alexey N. Kuznetsov.
9171 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>, Alexey Makarenko
9172 +<makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>.
9173 +This manpage maintained by bert hubert <ahu@ds9a.nl>
9176 diff -Naur iproute2-orig/debian/tc-sfq.8 iproute2/debian/tc-sfq.8
9177 --- iproute2-orig/debian/tc-sfq.8 1969-12-31 16:00:00.000000000 -0800
9178 +++ iproute2/debian/tc-sfq.8 2004-05-21 00:09:38.000000000 -0700
9180 +.TH TC 8 "8 December 2001" "iproute2" "Linux"
9182 +sfq \- Stochastic Fairness Queueing
9184 +.B tc qdisc ... perturb
9191 +Stochastic Fairness Queueing is a classless queueing discipline available for
9192 +traffic control with the
9196 +SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'.
9197 +The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing
9198 +any single flow from drowning out the rest.
9200 +This may in fact have some effect in mitigating a Denial of Service attempt.
9202 +SFQ is work-conserving and therefore always delivers a packet if it has one available.
9204 +On enqueueing, each packet is assigned to a hash bucket, based on
9210 +Destination address
9215 +If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP.
9216 +Packets with other protocols are hashed based on the 32bits representation of their
9217 +destination and the socket they belong to. A flow corresponds mostly to a TCP/IP
9220 +Each of these buckets should represent a unique flow. Because multiple flows may
9221 +get hashed to the same bucket, the hashing algorithm is perturbed at configurable
9222 +intervals so that the unfairness lasts only for a short while. Perturbation may
9223 +however cause some inadvertent packet reordering to occur.
9225 +When dequeuing, each hashbucket with data is queried in a round robin fashion.
9227 +The compile time maximum length of the SFQ is 128 packets, which can be spread over
9228 +at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed
9229 +on the fullest bucket, thus maintaining fairness.
9234 +Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that
9235 +no perturbation occurs. Do not set too low for each perturbation may cause some packet
9236 +reordering. Advised value: 10
9239 +Amount of bytes a flow is allowed to dequeue during a round of the round robin process.
9240 +Defaults to the MTU of the interface which is also the advised value and the minimum value.
9242 +.SH EXAMPLE & USAGE
9244 +To attach to device ppp0:
9246 +# tc qdisc add dev ppp0 root sfq perturb 10
9248 +Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful
9249 +if it owns the queue.
9250 +This is the case when the link speed equals the actually available bandwidth. This holds
9251 +for regular phone modems, ISDN connections and direct non-switched ethernet links.
9253 +Most often, cable modems and DSL devices do not fall into this category. The same holds
9254 +for when connected to a switch and trying to send data to a congested segment also
9255 +connected to the switch.
9257 +In this case, the effective queue does not reside within Linux and is therefore not
9258 +available for scheduling.
9260 +Embed SFQ in a classful qdisc to make sure it owns the queue.
9265 +Paul E. McKenney "Stochastic Fairness Queuing",
9266 +IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.
9270 +Paul E. McKenney "Stochastic Fairness Queuing",
9271 +"Interworking: Research and Experience", v.2, 1991, p.113-131.
9276 +M. Shreedhar and George Varghese "Efficient Fair
9277 +Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
9283 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
9284 +bert hubert <ahu@ds9a.nl>
9287 diff -Naur iproute2-orig/debian/tc-tbf.8 iproute2/debian/tc-tbf.8
9288 --- iproute2-orig/debian/tc-tbf.8 1969-12-31 16:00:00.000000000 -0800
9289 +++ iproute2/debian/tc-tbf.8 2004-05-21 00:09:38.000000000 -0700
9291 +.TH TC 8 "13 December 2001" "iproute2" "Linux"
9293 +tbf \- Token Bucket Filter
9295 +.B tc qdisc ... tbf rate
9311 +burst is also known as buffer and maxburst. mtu is also known as minburst.
9314 +The Token Bucket Filter is a classless queueing discipline available for
9315 +traffic control with the
9319 +TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle
9320 +itself, although packets are available, to ensure that the configured rate is not exceeded.
9321 +On all platforms except for Alpha,
9322 +it is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness,
9323 +sending out data exactly at the configured rates.
9325 +Much higher rates are possible but at the cost of losing the minimal burstiness. In that
9326 +case, data is on average dequeued at the configured rate but may be sent much faster at millisecond
9327 +timescales. Because of further queues living in network adaptors, this is often not a problem.
9329 +Kernels with a higher 'HZ' can achieve higher rates with perfect burstiness. On Alpha, HZ is ten
9330 +times higher, leading to a 10mbit/s limit to perfection. These calculations hold for packets of on
9331 +average 1000 bytes.
9334 +As the name implies, traffic is filtered based on the expenditure of
9336 +Tokens roughly correspond to bytes, with the additional constraint that each packet consumes
9337 +some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies
9338 +the link for some time.
9340 +On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst
9341 +in one go. Tokens arrive at a steady rate, until the bucket is full.
9343 +If no tokens are available, packets are queued, up to a configured limit. The TBF now
9344 +calculates the token deficit, and throttles until the first packet in the queue can be sent.
9346 +If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured
9347 +to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF
9348 +with a very small bucket, so that it doesn't burst.
9350 +To achieve perfection, the second bucket may contain only a single packet, which leads to
9351 +the earlier mentioned 1mbit/s limit.
9353 +This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends
9354 +on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100
9355 +packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.
9360 +for how to specify the units of these values.
9363 +Limit is the number of bytes that can be queued waiting for tokens to become
9364 +available. You can also specify this the other way around by setting the
9365 +latency parameter, which specifies the maximum amount of time a packet can
9366 +sit in the TBF. The latter calculation takes into account the size of the
9367 +bucket, the rate and possibly the peakrate (if set). These two parameters
9368 +are mutually exclusive.
9371 +Also known as buffer or maxburst.
9372 +Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously.
9373 +In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer
9374 +if you want to reach your configured rate!
9376 +If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
9377 +The minimum buffer size can be calculated by dividing the rate by HZ.
9379 +Token usage calculations are performed using a table which by default has a resolution of 8 packets.
9380 +This resolution can be changed by specifying the
9382 +size with the burst. For example, to specify a 6000 byte buffer with a 16
9383 +byte cell size, set a burst of 6000/16. You will probably never have to set
9384 +this. Must be an integral power of 2.
9387 +A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit
9388 +determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
9391 +The speed knob. See remarks above about limits! See
9395 +Furthermore, if a peakrate is desired, the following parameters are available:
9399 +Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does
9400 +not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
9404 +Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
9405 +If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
9406 +allows around 3mbit/s of peakrate, given 1000 byte packets.
9408 +Like the regular burstsize you can also specify a
9411 +.SH EXAMPLE & USAGE
9413 +To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s,
9414 +a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes
9415 +at most 70ms of latency, with perfect peakrate behaviour, issue:
9417 +# tc qdisc add dev eth0 root tbf rate 0.5mbit \\
9418 + burst 5kb latency 70ms peakrate 1mbit \\
9425 +Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
9426 +bert hubert <ahu@ds9a.nl>
9429 diff -Naur iproute2-orig/debian/tc.8 iproute2/debian/tc.8
9430 --- iproute2-orig/debian/tc.8 1969-12-31 16:00:00.000000000 -0800
9431 +++ iproute2/debian/tc.8 2004-05-21 00:09:38.000000000 -0700
9433 +.TH TC 8 "16 December 2001" "iproute2" "Linux"
9435 +tc \- show / manipulate traffic control settings
9437 +.B tc qdisc [ add | change | replace | link ] dev
9445 +[ qdisc specific parameters ]
9448 +.B tc class [ add | change | replace ] dev
9454 +[ qdisc specific parameters ]
9457 +.B tc filter [ add | change | replace ] dev
9461 +.B | root ] protocol
9464 +priority filtertype
9465 +[ filtertype specific parameters ]
9469 +.B tc [-s | -d ] qdisc show [ dev
9473 +.B tc [-s | -d ] class show dev
9476 +.B tc filter show dev
9481 +is used to configure Traffic Control in the Linux kernel. Traffic Control consists
9486 +When traffic is shaped, its rate of transmission is under control. Shaping may
9487 +be more than lowering the available bandwidth - it is also used to smooth out
9488 +bursts in traffic for better network behaviour. Shaping occurs on egress.
9492 +By scheduling the transmission of packets it is possible to improve interactivity
9493 +for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
9494 +is also called prioritizing, and happens only on egress.
9498 +Where shaping deals with transmission of traffic, policing pertains to traffic
9499 +arriving. Policing thus occurs on ingress.
9503 +Traffic exceeding a set bandwidth may also be dropped forthwith, both on
9504 +ingress and on egress.
9507 +Processing of traffic is controlled by three kinds of objects: qdiscs,
9508 +classes and filters.
9512 +is short for 'queueing discipline' and it is elementary to
9513 +understanding traffic control. Whenever the kernel needs to send a
9514 +packet to an interface, it is
9516 +to the qdisc configured for that interface. Immediately afterwards, the kernel
9517 +tries to get as many packets as possible from the qdisc, for giving them
9518 +to the network adaptor driver.
9520 +A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure
9521 +First In, First Out queue. It does however store traffic when the network interface
9522 +can't handle it momentarily.
9525 +Some qdiscs can contain classes, which contain further qdiscs - traffic may
9526 +then be enqueued in any of the inner qdiscs, which are within the
9528 +When the kernel tries to dequeue a packet from such a
9530 +it can come from any of the classes. A qdisc may for example prioritize
9531 +certain kinds of traffic by trying to dequeue from certain classes
9537 +is used by a classful qdisc to determine in which class a packet will
9538 +be enqueued. Whenever traffic arrives at a class with subclasses, it needs
9539 +to be classified. Various methods may be employed to do so, one of these
9540 +are the filters. All filters attached to the class are called, until one of
9541 +them returns with a verdict. If no verdict was made, other criteria may be
9542 +available. This differs per qdisc.
9544 +It is important to notice that filters reside
9546 +qdiscs - they are not masters of what happens.
9548 +.SH CLASSLESS QDISCS
9549 +The classless qdiscs are:
9552 +Simplest usable qdisc, pure First In, First Out behaviour. Limited in
9553 +packets or in bytes.
9556 +Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
9557 +queue which honors Type of Service flags, as well as the priority that may be
9558 +assigned to a packet.
9561 +Random Early Detection simulates physical congestion by randomly dropping
9562 +packets when nearing configured bandwidth allocation. Well suited to very
9563 +large bandwidth applications.
9566 +Stochastic Fairness Queueing reorders queued traffic so each 'session'
9567 +gets to send a packet in turn.
9570 +The Token Bucket Filter is suited for slowing traffic down to a precisely
9571 +configured rate. Scales well to large bandwidths.
9572 +.SH CONFIGURING CLASSLESS QDISCS
9573 +In the absence of classful qdiscs, classless qdiscs can only be attached at
9574 +the root of a device. Full syntax:
9576 +.B tc qdisc add dev
9579 +QDISC QDISC-PARAMETERS
9583 +.B tc qdisc del dev
9589 +qdisc is the automatic default in the absence of a configured qdisc.
9591 +.SH CLASSFUL QDISCS
9592 +The classful qdiscs are:
9595 +Class Based Queueing implements a rich linksharing hierarchy of classes.
9596 +It contains shaping elements as well as prioritizing capabilities. Shaping is
9597 +performed using link idle time calculations based on average packet size and
9598 +underlying link bandwidth. The latter may be ill-defined for some interfaces.
9601 +The Hierarchy Token Bucket implements a rich linksharing hierarchy of
9602 +classes with an emphasis on conforming to existing practices. HTB facilitates
9603 +guaranteeing bandwidth to classes, while also allowing specification of upper
9604 +limits to inter-class sharing. It contains shaping elements, based on TBF and
9605 +can prioritize classes.
9608 +The PRIO qdisc is a non-shaping container for a configurable number of
9609 +classes which are dequeued in order. This allows for easy prioritization
9610 +of traffic, where lower classes are only able to send if higher ones have
9611 +no packets available. To facilitate configuration, Type Of Service bits are
9612 +honored by default.
9613 +.SH THEORY OF OPERATION
9614 +Classes form a tree, where each class has a single parent.
9615 +A class may have multiple children. Some qdiscs allow for runtime addition
9616 +of classes (CBQ, HTB) while others (PRIO) are created with a static number of
9619 +Qdiscs which allow dynamic addition of classes can have zero or more
9620 +subclasses to which traffic may be enqueued.
9622 +Furthermore, each class contains a
9624 +which by default has
9626 +behaviour though another qdisc can be attached in place. This qdisc may again
9627 +contain classes, but each class can have only one leaf qdisc.
9629 +When a packet enters a classful qdisc it can be
9631 +to one of the classes within. Three criteria are available, although not all
9632 +qdiscs will use all three:
9635 +If tc filters are attached to a class, they are consulted first
9636 +for relevant instructions. Filters can match on all fields of a packet header,
9637 +as well as on the firewall mark applied by ipchains or iptables. See
9638 +.BR tc-filters (8).
9641 +Some qdiscs have built in rules for classifying packets based on the TOS field.
9644 +Userspace programs can encode a class-id in the 'skb->priority' field using
9645 +the SO_PRIORITY option.
9647 +Each node within the tree can have its own filters but higher level filters
9648 +may also point directly to lower classes.
9650 +If classification did not succeed, packets are enqueued to the leaf qdisc
9651 +attached to that class. Check qdisc specific manpages for details, however.
9654 +All qdiscs, classes and filters have IDs, which can either be specified
9655 +or be automatically assigned.
9657 +IDs consist of a major number and a minor number, separated by a colon.
9661 +A qdisc, which potentially can have children,
9662 +gets assigned a major number, called a 'handle', leaving the minor
9663 +number namespace available for classes. The handle is expressed as '10:'.
9664 +It is customary to explicitly assign a handle to qdiscs expected to have
9669 +Classes residing under a qdisc share their qdisc major number, but each have
9670 +a separate minor number called a 'classid' that has no relation to their
9671 +parent classes, only to their parent qdisc. The same naming custom as for
9676 +Filters have a three part ID, which is only needed when using a hashed
9677 +filter hierarchy, for which see
9678 +.BR tc-filters (8).
9680 +All parameters accept a floating point number, possibly followed by a unit.
9682 +Bandwidths or rates can be specified in:
9685 +Kilobytes per second
9688 +Megabytes per second
9691 +Kilobits per second
9694 +Megabits per second
9696 +bps or a bare number
9699 +Amounts of data can be specified in:
9716 +Lengths of time can be specified in:
9724 +us, usec, usecs or a bare number
9728 +The following commands are available for qdiscs, classes and filter:
9731 +Add a qdisc, class or filter to a node. For all entities, a
9733 +must be passed, either by passing its ID or by attaching directly to the root of a device.
9734 +When creating a qdisc or a filter, it can be named with the
9736 +parameter. A class is named with the
9742 +A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs
9743 +are automatically deleted, as well as any filters attached to them.
9747 +Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
9748 +that the handle cannot be changed and neither can the parent. In other words,
9751 +cannot move a node.
9755 +Performs a nearly atomic remove/add on an existing node id. If the node does not exist yet
9760 +Only available for qdiscs and performs a replace where the node
9761 +must exist already.
9766 +was written by Alexey N. Kuznetsov and added in Linux 2.2.
9775 +.BR tc-pfifo_fast (8),
9779 +Manpage maintained by bert hubert (ahu@ds9a.nl)
9781 diff -Naur iproute2-orig/include/rt_names.h iproute2/include/rt_names.h
9782 --- iproute2-orig/include/rt_names.h 2000-04-16 10:42:50.000000000 -0700
9783 +++ iproute2/include/rt_names.h 2004-05-21 00:16:36.000000000 -0700
9786 #define RT_NAMES_H_ 1
9788 +#include <asm/byteorder.h>
9790 const char* rtnl_rtprot_n2a(int id, char *buf, int len);
9791 const char* rtnl_rtscope_n2a(int id, char *buf, int len);
9792 const char* rtnl_rttable_n2a(int id, char *buf, int len);
9793 diff -Naur iproute2-orig/lib/rt_names.c iproute2/lib/rt_names.c
9794 --- iproute2-orig/lib/rt_names.c 2000-04-16 10:42:52.000000000 -0700
9795 +++ iproute2/lib/rt_names.c 2004-05-21 00:16:36.000000000 -0700
9799 #include <sys/time.h>
9800 +#include <asm/byteorder.h>
9802 static void rtnl_tab_initialize(char *file, char **tab, int size)
9804 diff -Naur iproute2-orig/misc/arpd.c iproute2/misc/arpd.c
9805 --- iproute2-orig/misc/arpd.c 2002-01-09 20:02:26.000000000 -0800
9806 +++ iproute2/misc/arpd.c 2004-05-21 00:16:36.000000000 -0700
9812 +#include <db_185.h>
9813 #include <sys/ioctl.h>
9814 #include <sys/poll.h>
9818 #include <linux/if.h>
9819 #include <linux/if_arp.h>
9820 +#include <linux/if_ether.h>
9821 #include <netinet/in.h>
9822 #include <arpa/inet.h>
9823 #include <linux/if_packet.h>