initial import

2 files changed, 9849 insertions, 0 deletions

diff --git a/abs/core-testing/iproute/PKGBUILD b/abs/core-testing/iproute/PKGBUILD
new file mode 100644
index 0000000..ae0f9f0
--- /dev/null
+++ b/abs/core-testing/iproute/PKGBUILD
@@ -0,0 +1,26 @@
+# $Id: PKGBUILD 3746 2008-06-30 20:09:01Z andyrtr $
+# Maintainer: Judd Vinet <jvinet@zeroflux.org>
+pkgname=iproute
+#_dlver=2.6.24-rc7
+#pkgver=$(echo ${_dlver} | sed 's|-|_|g')
+pkgver=2.6.25
+pkgrel=1
+pkgdesc="IP Routing Utilities"
+arch=(i686 x86_64)
+license=('GPL')
+url="http://www.linux-foundation.org/en/Net:Iproute2"
+depends=('db>=4.7')
+source=(#http://devresources.linux-foundation.org/dev/iproute2/download/iproute2-${_dlver}.tar.bz2
+	http://devresources.linux-foundation.org/dev/iproute2/download/iproute2-${pkgver}.tar.bz2)
+options=('force')
+md5sums=('5737bade2f5e03fad0e2c81da91e551e')
+
+build() {
+  #cd $srcdir/iproute2-${_dlver}
+  cd $srcdir/iproute2-${pkgver}
+  sed -i 's|/usr/local/lib/iptables|/usr/lib/iptables|' include/iptables.h || return 1
+  ./configure 
+  make || return 1
+  make DESTDIR=$pkgdir install || return 1
+  chmod 755 $pkgdir/usr/sbin/ifcfg
+}
diff --git a/abs/core-testing/iproute/iproute2-2.4.7-now-ss020116.patch b/abs/core-testing/iproute/iproute2-2.4.7-now-ss020116.patch
new file mode 100644
index 0000000..0e37865
--- /dev/null
+++ b/abs/core-testing/iproute/iproute2-2.4.7-now-ss020116.patch
@@ -0,0 +1,9823 @@
+diff -Naur iproute2-orig/Makefile iproute2/Makefile
+--- iproute2-orig/Makefile	2002-01-15 15:30:32.000000000 -0800
++++ iproute2/Makefile	2004-05-21 00:16:36.000000000 -0700
+@@ -4,8 +4,6 @@
+ CONFDIR=/etc/iproute2
+ DOCDIR=/usr/doc/iproute2
+ 
+-KERNEL_INCLUDE=/usr/src/linux/include
+-LIBC_INCLUDE=/usr/include
+ 
+ DEFINES= -DRESOLVE_HOSTNAMES
+ 
+@@ -23,19 +21,11 @@
+ #options for ipx
+ ADDLIB+=ipx_ntop.o ipx_pton.o
+ 
+-ifeq ($(LIBC_INCLUDE)/socketbits.h,$(wildcard $(LIBC_INCLUDE)/socketbits.h))
+-  ifeq ($(LIBC_INCLUDE)/net/if_packet.h,$(wildcard $(LIBC_INCLUDE)/net/if_packet.h))
+-    GLIBCFIX=-I../include-glibc -include ../include-glibc/glibc-bugs.h
+-  endif
+-endif
+-ifeq ($(LIBC_INCLUDE)/bits/socket.h,$(wildcard $(LIBC_INCLUDE)/bits/socket.h))
+-  GLIBCFIX=-I../include-glibc -I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
+-endif
+ 
+ 
+ CC = gcc
+ CCOPTS = -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g
+-CFLAGS = $(CCOPTS) $(GLIBCFIX) -I$(KERNEL_INCLUDE) -I../include $(DEFINES)
++CFLAGS = $(CCOPTS) -I../include $(DEFINES)
+ 
+ LDLIBS += -L../lib -lnetlink -lutil
+ 
+@@ -43,19 +33,11 @@
+ 
+ LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a
+ 
+-all: check-kernel
++all:
+ 	@set -e; \
+ 	for i in $(SUBDIRS); \
+ 	do $(MAKE) -C $$i; done
+ 
+-check-kernel:
+-ifeq ($(KERNEL_INCLUDE),)
+-	@echo "Please, set correct KERNEL_INCLUDE"; false
+-else
+-	@set -e; \
+-	if [ ! -r $(KERNEL_INCLUDE)/linux/autoconf.h ]; then \
+-		echo "Please, compile the kernel first"; false; fi
+-endif
+ 
+ install: all
+ 	install -m 0755 -d $(DESTDIR)$(SBINDIR)
+diff -Naur iproute2-orig/Makefile~ iproute2/Makefile~
+--- iproute2-orig/Makefile~	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/Makefile~	2002-01-15 15:30:32.000000000 -0800
+@@ -0,0 +1,77 @@
++# Path to parent kernel include files directory
++DESTDIR=
++SBINDIR=/sbin
++CONFDIR=/etc/iproute2
++DOCDIR=/usr/doc/iproute2
++
++KERNEL_INCLUDE=/usr/src/linux/include
++LIBC_INCLUDE=/usr/include
++
++DEFINES= -DRESOLVE_HOSTNAMES
++
++#options if you have a bind>=4.9.4 libresolv (or, maybe, glibc)
++LDLIBS=-lresolv
++ADDLIB=
++
++#options if you compile with libc5, and without a bind>=4.9.4 libresolv
++#LDLIBS=
++#ADDLIB=inet_ntop.o inet_pton.o
++
++#options for decnet
++ADDLIB+=dnet_ntop.o dnet_pton.o
++
++#options for ipx
++ADDLIB+=ipx_ntop.o ipx_pton.o
++
++ifeq ($(LIBC_INCLUDE)/socketbits.h,$(wildcard $(LIBC_INCLUDE)/socketbits.h))
++  ifeq ($(LIBC_INCLUDE)/net/if_packet.h,$(wildcard $(LIBC_INCLUDE)/net/if_packet.h))
++    GLIBCFIX=-I../include-glibc -include ../include-glibc/glibc-bugs.h
++  endif
++endif
++ifeq ($(LIBC_INCLUDE)/bits/socket.h,$(wildcard $(LIBC_INCLUDE)/bits/socket.h))
++  GLIBCFIX=-I../include-glibc -I/usr/include/db3 -include ../include-glibc/glibc-bugs.h
++endif
++
++
++CC = gcc
++CCOPTS = -D_GNU_SOURCE -O2 -Wstrict-prototypes -Wall -g
++CFLAGS = $(CCOPTS) $(GLIBCFIX) -I$(KERNEL_INCLUDE) -I../include $(DEFINES)
++
++LDLIBS += -L../lib -lnetlink -lutil
++
++SUBDIRS=lib ip tc misc
++
++LIBNETLINK=../lib/libnetlink.a ../lib/libutil.a
++
++all: check-kernel
++	@set -e; \
++	for i in $(SUBDIRS); \
++	do $(MAKE) -C $$i; done
++
++check-kernel:
++ifeq ($(KERNEL_INCLUDE),)
++	@echo "Please, set correct KERNEL_INCLUDE"; false
++else
++	@set -e; \
++	if [ ! -r $(KERNEL_INCLUDE)/linux/autoconf.h ]; then \
++		echo "Please, compile the kernel first"; false; fi
++endif
++
++install: all
++	install -m 0755 -d $(DESTDIR)$(SBINDIR)
++	install -m 0755 -d $(DESTDIR)$(CONFDIR)
++	install -m 0755 -d $(DESTDIR)$(DOCDIR)/examples
++	install -m 0755 -d $(DESTDIR)$(DOCDIR)/examples/diffserv
++	install -m 0644 README.iproute2+tc $(shell find examples -type f -maxdepth 1) $(DESTDIR)$(DOCDIR)/examples
++	install -m 0644 $(shell echo examples/diffserv/*) $(DESTDIR)$(DOCDIR)/examples/diffserv
++	@for i in $(SUBDIRS) doc; do $(MAKE) -C $$i install; done
++	@cd etc/iproute2; for i in *; do \
++		if [ ! -e $(DESTDIR)$(CONFDIR)/$$i ]; then \
++			echo install -m 0644 $$i $(DESTDIR)$(CONFDIR); \
++			install -m 0644 $$i $(DESTDIR)$(CONFDIR); fi; done
++
++clean:
++	for i in $(SUBDIRS) doc; \
++	do $(MAKE) -C $$i clean; done
++
++.EXPORT_ALL_VARIABLES:
+diff -Naur iproute2-orig/debian/README.Debian iproute2/debian/README.Debian
+--- iproute2-orig/debian/README.Debian	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/README.Debian	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,4 @@
++This version of "iproute" includes the HTB Linux queuing discipline
++explained in http://luxik.cdi.cz/~devik/qos/htb/
++
++You need kernel version 2.4.21 or newer in order to use it.
+diff -Naur iproute2-orig/debian/changelog iproute2/debian/changelog
+--- iproute2-orig/debian/changelog	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/changelog	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,207 @@
++iproute (20010824-13) unstable; urgency=low
++
++  * debian/rules: Run dpkg-shlibdeps with all the executables,
++    to fix dependency problem                      (closes: Bug#224063)
++  * Really removed references to obsolete include files
++    (Bug#223165 was not fixed properly)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sun, 25 Jan 2004 23:04:20 +0100
++
++iproute (20010824-12) unstable; urgency=low
++
++  * Updated README.Debian and copyright file
++  * Added two new manpages from http://lartc.org/manpages/:
++    ip(8) and tc-cbq-details(8).
++  * Removed references to obsolete include files which made
++    compilation fail (closes: Bug#223165)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sun, 14 Dec 2003 00:40:10 +0100
++
++iproute (20010824-11) unstable; urgency=low
++
++  * Changed priority to "optional"
++  * Fixed "tc -s qdisc" on sparc (patch by "Nicolas S. Dade"
++    <ndade@nsd.dyndns.org>) (closes: Bug#194128)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sun, 17 Aug 2003 00:22:47 +0200
++
++iproute (20010824-10) unstable; urgency=low
++
++  * Updated manual pages from http://www.lartc.org/manpages/
++                (closes: Bug#156353, Bug#175313, Bug#176989, Bug#189095)
++  * New Standards-Version
++  * Don't "rm -rf /etc/iproute2" on purge (closes: Bug#202862)
++  * Include "iproute2" in the description (closes: Bug#182999)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sat, 16 Aug 2003 18:29:27 +0200
++
++iproute (20010824-9) unstable; urgency=medium
++
++  * Added patch for HTB v3.6 to be able to work with kernel 2.4.20
++    (from http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz)
++                (closes: Bug#147550, Bug#167149, Bug#167597, Bug#171277)
++
++ -- Juan Cespedes <cespedes@debian.org>  Thu, 05 Dec 2002 13:44:10 +0100
++
++iproute (20010824-8) unstable; urgency=medium
++
++  * Added support for HTB queuing discipline        (closes: Bug#133381)
++    NOTE: you need a patched kernel in order to use it
++
++ -- Juan Cespedes <cespedes@debian.org>  Tue,  2 Apr 2002 20:29:40 +0200
++
++iproute (20010824-7) unstable; urgency=medium
++
++  * Move `ip' binary to /bin to fix FHS violation   (closes: Bug#134812)
++
++ -- Juan Cespedes <cespedes@debian.org>  Mon,  4 Mar 2002 00:20:30 +0100
++
++iproute (20010824-6) unstable; urgency=low
++
++  * Added a couple of #ifdef's to be able to compile with older
++    kernel headers (needed for arm)                 (closes: Bug#131695)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sat, 16 Feb 2002 19:27:15 +0100
++
++iproute (20010824-5) unstable; urgency=low
++
++  * Really fix Bug#121589 (dead gateway bug); apparently I
++    forgot to include the patch in 20010824-2
++
++ -- Juan Cespedes <cespedes@debian.org>  Tue, 29 Jan 2002 23:22:24 +0100
++
++iproute (20010824-4) unstable; urgency=low
++
++  * Added support for DIFFSERV and ATM in tc
++
++ -- Juan Cespedes <cespedes@debian.org>  Sun, 13 Jan 2002 03:01:47 +0100
++
++iproute (20010824-3) unstable; urgency=low
++
++  * Updated tc* man pages (thanks to bert hubert <ahu@ds9a.nl>)
++  * Fixed spurious space in `tc -s qdisc' output (closes: Bug#128501)
++
++ -- Juan Cespedes <cespedes@debian.org>  Thu, 10 Jan 2002 22:18:25 +0100
++
++iproute (20010824-2) unstable; urgency=low
++
++  * Fixed the following important and serious bugs:
++    + iproute doesn't compile on Alpha (closes: Bug#118113, Bug#123224)
++    + iproute doesn't compile on MIPS (closes: Bug#118424)
++    + iproute doesn't compile on powerpc (closes: Bug#119601)
++  * Added man pages for tc (closes: Bug#124230), tc-cbq, tc-red, tc-tbf,
++    tc-prio and tc-sfq
++  * Removed references to old programs from iproute(7) (closes: Bug#99536)
++  * Fixed bug which presented first hop as dead in equal cost multipath
++                                                      (closes: Bug#121589)
++  * Do not process .ps with through `psnup' (closes: Bug#119820)
++
++ -- Juan Cespedes <cespedes@debian.org>  Tue,  8 Jan 2002 16:07:27 +0100
++
++iproute (20010824-1) unstable; urgency=low
++
++  * New upstream version
++  * Make ingress qdisc work again with tc           (closes: Bug#84444)
++  * Make it compile properly with new include files (closes: Bug#113112)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sun, 28 Oct 2001 16:38:00 +0100
++
++iproute (20001007-1) unstable; urgency=low
++
++  * New upstream version                             (closes: Bug#63701)
++  * Remove /etc/iproute2 on purge                    (closes: Bug#72743)
++  * Fixed Lintian warnings (no-priority-field and no-section-field)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sat, 14 Oct 2000 19:27:12 +0200
++
++iproute (991023-2) unstable; urgency=low
++
++  * New Standards-Version (3.1.1) (closes: Bug#47923)
++  * Modified description of package to show which kernel options are
++    necessary to use the package (closes: Bug#47922)
++  * Updated manual page to point at /usr/share/doc/iproute (closes: Bug#47924)
++
++ -- Juan Cespedes <cespedes@debian.org>  Sun, 19 Dec 1999 04:00:21 +0100
++
++iproute (991023-1) unstable; urgency=low
++
++  * New upstream version (closes: Bug#48733)
++
++ -- Juan Cespedes <cespedes@debian.org>  Tue,  2 Nov 1999 16:29:37 +0100
++
++iproute (990824-1) unstable; urgency=low
++
++  * New maintainer
++  * New upstream version
++  * New Standards-Version: 3.1.0
++  * Minor fix in "ip rule list": mask in "from" address was not shown
++    correctly
++  * Removed obsoleted documentation from "debian/" directory
++
++ -- Juan Cespedes <cespedes@debian.org>  Sun, 24 Oct 1999 19:02:56 +0200
++
++iproute (990630-1) unstable; urgency=low
++
++  * New upstream version.
++  * FHS and standards 3.0.1.0.
++
++ -- Roberto Lumbreras <rover@debian.org>  Tue,  3 Aug 1999 02:49:28 +0200
++
++iproute (990530-1) unstable; urgency=low
++
++  * New upstream version.
++  * Build with 2.2.10 kernel headers.
++  * Install new scripts ip/routef ip/routel, but not ip/ifcfg ip/rtpr by
++    now, I don't know who/what needs rtpr; ifcfg uses arping, and it isn't
++    available in debian for now.
++
++ -- Roberto Lumbreras <rover@debian.org>  Tue, 22 Jun 1999 02:28:53 +0200
++
++iproute (990329-1) unstable; urgency=low
++
++  * New upstream version.
++  * Build with 2.2.5 kernel headers.
++
++ -- Roberto Lumbreras <rover@debian.org>  Sun,  4 Apr 1999 18:50:39 +0200
++
++iproute (980630-1) unstable; urgency=low
++
++  * New upstream version.
++  * Build with 2.1.112 kernel headers.
++  * Rewrote the rules file.
++
++ -- Roberto Lumbreras <rover@debian.org>  Wed, 29 Jul 1998 23:37:52 +0200
++
++iproute (980119-1) unstable; urgency=low
++
++  * Outdated documentation. Upstream docs are scarce.
++  * Non-Maintainer release
++  * This package has no correct copyright file!
++  * Include all the README.* docs from the upstream site.
++  * Modified to build under glibc
++  * Build with 2.1.85 kernel headers.
++  * produce a correct diff.
++  * Reworked the rules file to utilize debmake fully
++  * Newest upstream release
++  * glibc compilation
++
++ -- Christoph Lameter <christoph@lameter.com>  Wed,  4 Feb 1998 13:37:28 -0800
++
++iproute (961225-2) unstable frozen; urgency=low
++
++  * Added a man page for iproute. (Fixes #8080).
++  * Removed out-of-date patches.
++  * Added routing.txt from /usr/src/linux/Documentation/networking/routing.txt
++  * Newer version of debmake.
++
++ -- Tom Lees <tom@lpsg.demon.co.uk>  Mon, 17 Apr 1997 17:00:36 +0100
++
++iproute (961225-1) unstable; urgency=low
++
++  * Initial Release.
++
++ -- Tom Lees <tom@lpsg.demon.co.uk>  Mon, 30 Dec 1996 11:12:23 +0000
++
++Local variables:
++mode: debian-changelog
++End:
+diff -Naur iproute2-orig/debian/conffiles iproute2/debian/conffiles
+--- iproute2-orig/debian/conffiles	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/conffiles	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,5 @@
++/etc/iproute2/rt_dsfield
++/etc/iproute2/rt_protos
++/etc/iproute2/rt_realms
++/etc/iproute2/rt_scopes
++/etc/iproute2/rt_tables
+diff -Naur iproute2-orig/debian/control iproute2/debian/control
+--- iproute2-orig/debian/control	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/control	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,19 @@
++Source: iproute
++Section: net
++Priority: optional
++Maintainer: Juan Cespedes <cespedes@debian.org>
++Standards-Version: 3.6.0
++Build-Depends: tetex-bin, atm-dev
++
++Package: iproute
++Architecture: any
++Depends: ${shlibs:Depends}
++Description: Professional tools to control the networking in Linux kernels
++ This is `iproute', the professional set of tools to control the
++ networking behavior in kernels 2.2.x and later.
++ .
++ At least, the options CONFIG_NETLINK and CONFIG_RTNETLINK must
++ be compiled in the running kernel
++ .
++ This package is also known as iproute2 upstream and in some
++ documentation.
+diff -Naur iproute2-orig/debian/copyright iproute2/debian/copyright
+--- iproute2-orig/debian/copyright	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/copyright	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,42 @@
++This is the Debian GNU/Linux's prepackaged version of the
++Linux Traffic Control engine and related utils, "iproute"
++
++This package was put together from sources obtained from:
++  ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.4.7-now-ss010824.tar.gz
++
++Changes for Debian:
++  * added Debian GNU/Linux package maintenance system files
++  * Added HTB v3.6 from
++    <http://luxik.cdi.cz/~devik/qos/htb/v3/htb3.6-020525.tgz>
++
++
++Copyrights
++----------
++Copyright (C) 1996-2001 Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
++
++Modifications for Debian:
++  Copyright (C) 1996 Tom Lees <tom@lpsg.demon.co.uk>
++  Copyright (C) 1998 Christoph Lameter <christoph@lameter.com>
++  Copyright (C) 1998-1999 Roberto Lumbreras <rover@debian.org>
++  Copyright (C) 1999-2003 Juan Cespedes <cespedes@debian.org>
++
++
++License
++-------
++
++This program is free software; you can redistribute it and/or modify
++it under the terms of the GNU General Public License as published by
++the Free Software Foundation; either version 2, or (at your option)
++any later version.
++
++This program is distributed in the hope that it will be useful, but
++WITHOUT ANY WARRANTY; without even the implied warranty of
++MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++General Public License for more details.
++
++A copy of the GNU General Public License is available as
++`/usr/share/common-licenses/GPL' in the Debian GNU/Linux distribution
++or on the World Wide Web at `http://www.gnu.org/copyleft/gpl.html'.
++You can also obtain it by writing to the Free Software Foundation,
++Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
++
+diff -Naur iproute2-orig/debian/manpages/ip.8 iproute2/debian/manpages/ip.8
+--- iproute2-orig/debian/manpages/ip.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/ip.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,1809 @@
++.TH IP 8 "17 January 2002" "iproute2" "Linux"
++.SH NAME
++ip \- show / manipulate routing, devices, policy routing and tunnels
++.SH SYNOPSIS
++
++.ad l
++.in +8
++.ti -8
++.B ip
++.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
++.BR help " }"
++.sp
++
++.ti -8
++.IR OBJECT " := { "
++.BR link " | " addr " | " route " | " rule " | " neigh " | " tunnel " | "\
++maddr " | "  mroute " | " monitor " }"
++.sp
++
++.ti -8
++.IR OPTIONS " := { " 
++\fB\-V\fR[\fIersion\fR] |
++\fB\-s\fR[\fItatistics\fR] |
++\fB\-r\fR[\fIesolve\fR] |
++\fB\-f\fR[\fIamily\fR] {
++.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
++\fB\-o\fR[\fIneline\fR] }
++
++.ti -8
++.BI "ip link set " DEVICE
++.RB "{ " up " | " down " | " arp " { " on " | " off " } |"
++.br
++.BR promisc " { " on " | " off " } |"
++.br
++.BR allmulti " { " on " | " off " } |"
++.br
++.BR dynamic " { " on " | " off " } |"
++.br
++.BR multicast " { " on " | " off " } |"
++.br
++.B  txqueuelen
++.IR PACKETS " |"
++.br
++.B  name
++.IR NEWNAME " |"
++.br
++.B  address
++.IR LLADDR " |"
++.B  broadcast 
++.IR LLADDR " |"
++.br
++.B  mtu
++.IR MTU " }"
++
++.ti -8
++.B ip link show
++.RI "[ " DEVICE " ]"
++
++.ti -8
++.BR "ip addr" " { " add " | " del " } " 
++.IB IFADDR " dev " STRING
++
++.ti -8
++.BR "ip addr" " { " show " | " flush " } [ " dev
++.IR STRING " ] [ "
++.B  scope
++.IR SCOPE-ID " ] [ "
++.B  to 
++.IR PREFIX " ] [ " FLAG-LIST " ] [ "
++.B  label
++.IR PATTERN " ]"
++
++.ti -8
++.IR IFADDR " := " PREFIX " | " ADDR
++.B  peer
++.IR PREFIX " [ "
++.B  broadcast
++.IR ADDR " ] [ "
++.B  anycast
++.IR ADDR " ] [ "
++.B  label
++.IR STRING " ] [ "
++.B  scope
++.IR SCOPE-ID " ]"
++
++.ti -8
++.IR SCOPE-ID " := "
++.RB "[ " host " | " link " | " global " | "
++.IR NUMBER " ]"
++
++.ti -8
++.IR FLAG-LIST " := [ "  FLAG-LIST " ] " FLAG
++
++.ti -8
++.IR FLAG " := "
++.RB "[ " permanent " | " dynamic " | " secondary " | " primary " | "\
++tentative " | " deprecated " ]"
++
++.ti -8
++.BR "ip route" " { "
++.BR list " | " flush " } "
++.I  SELECTOR
++
++.ti -8
++.B  ip route get 
++.IR ADDRESS " [ "
++.BI from " ADDRESS " iif " STRING"
++.RB " ] [ " oif 
++.IR STRING " ] [ "
++.B  tos
++.IR TOS " ]"
++
++.ti -8
++.BR "ip route" " { " add " | " del " | " change " | " append " | "\
++replace " | " monitor " } "
++.I  ROUTE
++
++.ti -8
++.IR SELECTOR " := "
++.RB "[ " root
++.IR PREFIX " ] [ "
++.B  match
++.IR PREFIX " ] [ "
++.B  exact
++.IR PREFIX " ] [ "
++.B  table
++.IR TABLE_ID " ] [ "
++.B  proto
++.IR RTPROTO " ] [ "
++.B  type
++.IR TYPE " ] [ "
++.B  scope
++.IR SCOPE " ]"
++
++.ti -8
++.IR ROUTE " := " NODE_SPEC " [ " INFO_SPEC " ]"
++
++.ti -8
++.IR NODE_SPEC " := [ " TYPE " ] " PREFIX " ["
++.B  tos
++.IR TOS " ] [ "
++.B  table
++.IR TABLE_ID " ] [ "
++.B  proto
++.IR RTPROTO " ] [ "
++.B  scope
++.IR SCOPE " ] [ "
++.B  metric
++.IR METRIC " ]"
++
++.ti -8
++.IR INFO_SPEC " := " "NH OPTIONS FLAGS" " ["
++.B  nexthop
++.IR NH " ] ..."
++
++.ti -8
++.IR NH " := [ "
++.B  via
++.IR ADDRESS " ] [ "
++.B  dev
++.IR STRING " ] [ "
++.B  weight
++.IR NUMBER " ] " NHFLAGS
++
++.ti -8
++.IR OPTIONS " := " FLAGS " [ "
++.B  mtu
++.IR NUMBER " ] [ "
++.B  advmss
++.IR NUMBER " ] [ "
++.B  rtt
++.IR NUMBER " ] [ "
++.B  rttvar
++.IR NUMBER " ] [ "
++.B  window
++.IR NUMBER " ] [ "
++.B  cwnd
++.IR NUMBER " ] [ "
++.B  ssthresh
++.IR REALM " ] [ "
++.B  realms
++.IR REALM " ]"
++
++.ti -8
++.IR TYPE " := [ "
++.BR unicast " | " local " | " broadcast " | " multicast " | "\
++throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
++
++.ti -8
++.IR TABLE_ID " := [ "
++.BR local "| " main " | " default " | " all " |"
++.IR NUMBER " ]"
++
++.ti -8
++.IR SCOPE " := [ "
++.BR host " | " link " | " global " |"
++.IR NUMBER " ]"
++
++.ti -8
++.IR FLAGS " := [ "
++.BR equalize " ]"
++
++.ti -8
++.IR NHFLAGS " := [ "
++.BR onlink " | " pervasive " ]"
++
++.ti -8
++.IR RTPROTO " := [ "
++.BR kernel " | " boot " | " static " |"
++.IR NUMBER " ]"
++
++.ti -8
++.B  ip rule
++.RB " [ " list " | " add " | " del " ]"
++.I  SELECTOR ACTION
++
++.ti -8
++.IR SELECTOR " := [ "
++.B  from
++.IR PREFIX " ] [ "
++.B  to
++.IR PREFIX " ] [ "
++.B  tos
++.IR TOS " ] [ "
++.B  fwmark
++.IR FWMARK " ] [ "
++.B  dev
++.IR STRING " ] [ "
++.B  pref
++.IR NUMBER " ]"
++
++.ti -8
++.IR ACTION " := [ "
++.B  table
++.IR TABLE_ID " ] [ "
++.B  nat
++.IR ADDRESS " ] [ "
++.BR prohibit " | " reject " | " unreachable " ] [ " realms
++.RI "[" SRCREALM "/]" DSTREALM " ]"
++
++.ti -8
++.IR TABLE_ID " := [ "
++.BR local " | " main " | " default " |"
++.IR NUMBER " ]"
++
++.ti -8
++.BR "ip neigh" " { " add " | " del " | " change " | " replace " } { "
++.IR ADDR " [ "
++.B  lladdr
++.IR LLADDR " ] [ "
++.BR nud " { " permanent " | " noarp " | " stale " | " reachable " } ] | " proxy
++.IR ADDR " } [ "
++.B  dev
++.IR DEV " ]"
++
++.ti -8
++.BR "ip neigh" " { " show " | " flush " } [ " to
++.IR PREFIX " ] [ "
++.B  dev
++.IR DEV " ] [ "
++.B  nud
++.IR STATE " ]"
++
++.ti -8
++.BR "ip tunnel" " { " add " | " change " | " del " | " show " }"
++.RI "[ " NAME " ]"
++.br
++.RB "[ " mode " { " ipip " | " gre " | " sit " } ]"
++.br
++.RB "[ " remote
++.IR ADDR " ] [ "
++.B  local
++.IR ADDR " ]"
++.br
++.RB "[ [" i "|" o "]" seq " ] [ [" i "|" o "]" key
++.IR KEY " ] [ "
++.RB "[" i "|" o "]" csum " ] ]"
++.br
++.RB "[ " ttl
++.IR TTL " ] [ "
++.B  tos
++.IR TOS " ] [ "
++.RB "[" no "]" pmtudisc " ]"
++.br
++.RB "[ " dev
++.IR PHYS_DEV " ]"
++
++.ti -8
++.IR ADDR " := { " IP_ADDRESS " |"
++.BR any " }"
++
++.ti -8
++.IR TOS " := { " NUMBER " |"
++.BR inherit " }"
++
++.ti -8
++.IR TTL " := { " 1 ".." 255 " | "
++.BR inherit " }"
++
++.ti -8
++.IR KEY " := { " DOTTED_QUAD " | " NUMBER " }"
++
++.ti -8
++.BR "ip maddr" " [ " add " | " del " ]"
++.IB MULTIADDR " dev " STRING
++
++.ti -8
++.BR "ip maddr show" " [ " dev
++.IR STRING " ]"
++
++.ti -8
++.BR "ip mroute show" " ["
++.IR PREFIX " ] [ "
++.B  from
++.IR PREFIX " ] [ "
++.B  iif
++.IR DEVICE " ]"
++
++.ti -8
++.BR "ip monitor" " [ " all " |"
++.IR LISTofOBJECTS " ]"
++.in -8
++.ad b
++
++.SH OPTIONS
++
++.TP
++.BR "\-V" , " -Version"
++print the version of the
++.B ip
++utility and exit.
++
++.TP
++.BR "\-s" , " \-stats", " \-statistics"
++output more information.  If the option
++appears twice or more, the amount of information increases.
++As a rule, the information is statistics or some time values.
++
++.TP
++.BR "\-f" , " \-family"
++followed by protocol family identifier:
++.BR "inet" , " inet6"
++or
++.B link
++,enforce the protocol family to use.  If the option is not present,
++the protocol family is guessed from other arguments.  If the rest 
++of the command line does not give enough information to guess the
++family,
++.B ip
++falls back to the default one, usually
++.B inet
++or
++.BR "any" .
++.B link
++is a special family identifier meaning that no networking protocol
++is involved.
++
++.TP
++.B \-4
++shortcut for
++.BR "-family inet" .
++
++.TP
++.B \-6
++shortcut for
++.BR "\-family inet6" .
++
++.TP
++.B \-0
++shortcut for
++.BR "\-family link" .
++
++.TP
++.BR "\-o" , " \-oneline"
++output each record on a single line, replacing line feeds
++with the
++.B '\'
++character. This is convenient when you want to count records 
++with
++.BR wc (1)
++ or to
++.BR grep (1)
++the output.
++
++.TP
++.BR "\-r" , " \-resolve"
++use the system's name resolver to print DNS names instead of
++host addresses.
++
++.SH IP - COMMAND SYNTAX
++
++.SS
++.I OBJECT
++
++.TP
++.B link
++- network device.
++
++.TP
++.B address
++- protocol (IP or IPv6) address on a device.
++.TP
++.B neighbour
++- ARP or NDISC cache entry.
++
++.TP
++.B route
++- routing table entry.
++
++.TP
++.B rule
++- rule in routing policy database.
++
++.TP
++.B maddress
++- multicast address.
++
++.TP
++.B mroute
++- multicast routing cache entry.
++
++.TP
++.B tunnel
++- tunnel over IP.
++
++.PP
++The names of all objects may be written in full or
++abbreviated form, f.e.
++.B address
++is abbreviated as
++.B addr
++or just
++.B a.
++
++.SS
++.I COMMAND
++
++Specifies the action to perform on the object.
++The set of possible actions depends on the object type.
++As a rule, it is possible to
++.BR "add" , " delete"
++and
++.B show
++(or
++.B list
++) objects, but some objects do not allow all of these operations
++or have some additional commands.  The
++.B help
++command is available for all objects.  It prints
++out a list of available commands and argument syntax conventions.
++.sp
++If no command is given, some default command is assumed.
++Usually it is
++.B list
++or, if the objects of this class cannot be listed,
++.BR "help" .
++
++.SH ip link - network device configuration
++
++.B link
++is a network device and the corresponding commands
++display and change the state of devices.
++
++.SS ip link set - change device attributes
++
++.TP
++.BI dev " NAME " (default)
++.I NAME
++specifies network device to operate on.
++
++.TP
++.BR up " and " down
++change the state of the device to
++.B UP
++or
++.BR "DOWN" .
++
++.TP
++.BR "arp on " or " arp off"
++change the
++.B NOARP
++flag on the device.
++
++.TP
++.BR "multicast on " or " multicast off"
++change the
++.B MULTICAST
++flag on the device.
++
++.TP
++.BR "dynamic on " or " dynamic off"
++change the
++.B DYNAMIC
++flag on the device.
++
++.TP
++.BI name " NAME"
++change the name of the device.  This operation is not
++recommended if the device is running or has some addresses
++already configured.
++
++.TP
++.BI txqueuelen " NUMBER"
++.TP 
++.BI txqlen " NUMBER"
++change the transmit queue length of the device.
++
++.TP
++.BI mtu " NUMBER"
++change the 
++.I MTU
++of the device.
++
++.TP
++.BI address " LLADDRESS"
++change the station address of the interface.
++
++.TP
++.BI broadcast " LLADDRESS"
++.TP
++.BI brd " LLADDRESS"
++.TP
++.BI peer " LLADDRESS"
++change the link layer broadcast address or the peer address when
++the interface is
++.IR "POINTOPOINT" .
++
++.PP
++.B Warning:
++If multiple parameter changes are requested,
++.B ip
++aborts immediately after any of the changes have failed.
++This is the only case when
++.B ip
++can move the system to an unpredictable state.  The solution
++is to avoid changing several parameters with one
++.B ip link set
++call.
++
++.SS  ip link show - display device attributes
++
++.TP
++.BI dev " NAME " (default)
++.I NAME
++specifies the network device to show.
++If this argument is omitted all devices are listed.
++
++.TP
++.B up
++only display running interfaces.
++
++.SH ip address - protocol address management.
++
++The
++.B address
++is a protocol (IP or IPv6) address attached
++to a network device.  Each device must have at least one address
++to use the corresponding protocol.  It is possible to have several
++different addresses attached to one device.  These addresses are not
++discriminated, so that the term
++.B alias
++is not quite appropriate for them and we do not use it in this document.
++.sp
++The
++.B ip addr
++command displays addresses and their properties, adds new addresses
++and deletes old ones.
++
++.SS ip address add - add new protocol address.
++
++.TP
++.BI dev " NAME"
++the name of the device to add the address to.
++
++.TP
++.BI local " ADDRESS " (default)
++the address of the interface. The format of the address depends
++on the protocol. It is a dotted quad for IP and a sequence of
++hexadecimal halfwords separated by colons for IPv6.  The
++.I ADDRESS
++may be followed by a slash and a decimal number which encodes
++the network prefix length.
++
++.TP
++.BI peer " ADDRESS"
++the address of the remote endpoint for pointopoint interfaces.
++Again, the
++.I ADDRESS
++may be followed by a slash and a decimal number, encoding the network
++prefix length.  If a peer address is specified, the local address
++cannot have a prefix length.  The network prefix is associated
++with the peer rather than with the local address.
++
++.TP
++.BI broadcast " ADDRESS"
++the broadcast address on the interface.
++.sp
++It is possible to use the special symbols
++.B '+'
++and
++.B '-'
++instead of the broadcast address.  In this case, the broadcast address
++is derived by setting/resetting the host bits of the interface prefix.
++
++.TP
++.BI label " NAME"
++Each address may be tagged with a label string.
++In order to preserve compatibility with Linux-2.0 net aliases,
++this string must coincide with the name of the device or must be prefixed
++with the device name followed by colon.
++
++.TP
++.BI scope " SCOPE_VALUE"
++the scope of the area where this address is valid.
++The available scopes are listed in file
++.BR "/etc/iproute2/rt_scopes" .
++Predefined scope values are:
++
++.in +8
++.B global
++- the address is globally valid.
++.sp
++.B site
++- (IPv6 only) the address is site local, i.e. it is
++valid inside this site.
++.sp
++.B link
++- the address is link local, i.e. it is valid only on this device.
++.sp
++.B host
++- the address is valid only inside this host.
++.in -8
++
++.SS ip address delete - delete protocol address
++.B Arguments:
++coincide with the arguments of
++.B ip addr add.
++The device name is a required argument.  The rest are optional.
++If no arguments are given, the first address is deleted.
++
++.SS ip address show - look at protocol addresses
++
++.TP
++.BI dev " NAME " (default)
++name of device.
++
++.TP
++.BI scope " SCOPE_VAL"
++only list addresses with this scope.
++
++.TP
++.BI to " PREFIX"
++only list addresses matching this prefix.
++
++.TP
++.BI label " PATTERN"
++only list addresses with labels matching the
++.IR "PATTERN" .
++.I PATTERN
++is a usual shell style pattern.
++
++.TP
++.BR dynamic " and " permanent
++(IPv6 only) only list addresses installed due to stateless
++address configuration or only list permanent (not dynamic)
++addresses.
++
++.TP
++.B tentative
++(IPv6 only) only list addresses which did not pass duplicate
++address detection.
++
++.TP
++.B deprecated
++(IPv6 only) only list deprecated addresses.
++
++.TP
++.BR primary " and " secondary
++only list primary (or secondary) addresses.
++
++.SS ip address flush - flush protocol addresses
++This command flushes the protocol addresses selected by some criteria.
++
++.PP
++This command has the same arguments as
++.B show.
++The difference is that it does not run when no arguments are given.
++
++.PP
++.B Warning:
++This command (and other
++.B flush
++commands described below) is pretty dangerous.  If you make a mistake,
++it will not forgive it, but will cruelly purge all the addresses.
++
++.PP
++With the
++.B -statistics
++option, the command becomes verbose. It prints out the number of deleted
++addresses and the number of rounds made to flush the address list.  If
++this option is given twice,
++.B ip addr flush
++also dumps all the deleted addresses in the format described in the
++previous subsection.
++
++.SH ip neighbour - neighbour/arp tables management.
++
++.B neighbour
++objects establish bindings between protocol addresses and
++link layer addresses for hosts sharing the same link.
++Neighbour entries are organized into tables. The IPv4 neighbour table
++is known by another name - the ARP table.
++
++.P
++The corresponding commands display neighbour bindings
++and their properties, add new neighbour entries and delete old ones.
++
++.SS ip neighbour add - add a new neighbour entry
++.SS ip neighbour change - change an existing entry
++.SS ip neighbour replace - add a new entry or change an existing one
++
++These commands create new neighbour records or update existing ones.
++
++.TP
++.BI to " ADDRESS " (default)
++the protocol address of the neighbour. It is either an IPv4 or IPv6 address.
++
++.TP
++.BI dev " NAME"
++the interface to which this neighbour is attached.
++
++.TP
++.BI lladdr " LLADDRESS"
++the link layer address of the neighbour.
++.I LLADDRESS
++can also be
++.BR "null" .
++
++.TP
++.BI nud " NUD_STATE"
++the state of the neighbour entry.
++.B nud
++is an abbreviation for 'Neigh bour Unreachability Detection'.
++The state can take one of the following values:
++
++.in +8
++.B permanent
++- the neighbour entry is valid forever and can be only
++be removed administratively.
++.sp
++
++.B noarp
++- the neighbour entry is valid. No attempts to validate
++this entry will be made but it can be removed when its lifetime expires.
++.sp
++
++.B reachable
++- the neighbour entry is valid until the reachability
++timeout expires.
++.sp
++
++.B stale
++- the neighbour entry is valid but suspicious.
++This option to
++.B ip neigh
++does not change the neighbour state if it was valid and the address
++is not changed by this command.
++.in -8
++
++.SS ip neighbour delete - delete a neighbour entry
++This command invalidates a neighbour entry.
++
++.PP
++The arguments are the same as with
++.BR "ip neigh add" ,
++except that
++.B lladdr
++and
++.B nud
++are ignored.
++
++.PP
++.B Warning:
++Attempts to delete or manually change a
++.B noarp
++entry created by the kernel may result in unpredictable behaviour.
++Particularly, the kernel may try to resolve this address even
++on a
++.B NOARP
++interface or if the address is multicast or broadcast.
++
++.SS ip neighbour show - list neighbour entries
++
++This commands displays neighbour tables.
++
++.TP
++.BI to " ADDRESS " (default)
++the prefix selecting the neighbours to list.
++
++.TP
++.BI dev " NAME"
++only list the neighbours attached to this device.
++
++.TP
++.B unused
++only list neighbours which are not currently in use.
++
++.TP
++.BI nud " NUD_STATE"
++only list neighbour entries in this state.
++.I NUD_STATE
++takes values listed below or the special value
++.B all
++which means all states.  This option may occur more than once.
++If this option is absent,
++.B ip
++lists all entries except for
++.B none
++and
++.BR "noarp" .
++
++.SS ip neighbour flush - flush neighbour entries
++This command flushes neighbour tables, selecting
++entries to flush by some criteria.
++
++.PP
++This command has the same arguments as
++.B show.
++The differences are that it does not run when no arguments are given,
++and that the default neighbour states to be flushed do not include
++.B permanent
++and
++.BR "noarp" .
++
++.PP
++With the
++.B -statistics
++option, the command becomes verbose.  It prints out the number of
++deleted neighbours and the number of rounds made to flush the
++neighbour table.  If the option is given
++twice,
++.B ip neigh flush
++also dumps all the deleted neighbours.
++
++.SH ip route - routing table management
++Manipulate route entries in the kernel routing tables keep
++information about paths to other networked nodes.
++.sp
++.B Route types:
++
++.in +8
++.B unicast
++- the route entry describes real paths to the destinations covered
++by the route prefix.
++
++.sp
++.B unreachable
++- these destinations are unreachable.  Packets are discarded and the
++ICMP message
++.I host unreachable
++is generated.
++The local senders get an
++.I EHOSTUNREACH
++error.
++
++.sp
++.B blackhole
++- these destinations are unreachable.  Packets are discarded silently.
++The local senders get an
++.I EINVAL
++error.
++
++.sp
++.B prohibit
++- these destinations are unreachable.  Packets are discarded and the
++ICMP message
++.I communication administratively prohibited
++is generated.  The local senders get an
++.I EACCES
++error.
++
++.sp
++.B local
++- the destinations are assigned to this host.  The packets are looped
++back and delivered locally.
++
++.sp
++.B broadcast
++- the destinations are broadcast addresses.  The packets are sent as
++link broadcasts.
++
++.sp
++.B throw
++- a special control route used together with policy rules. If such a
++route is selected, lookup in this table is terminated pretending that
++no route was found.  Without policy routing it is equivalent to the
++absence of the route in the routing table.  The packets are dropped
++and the ICMP message
++.I net unreachable
++is generated.  The local senders get an
++.I ENETUNREACH
++error.
++
++.sp
++.B nat
++- a special NAT route.  Destinations covered by the prefix
++are considered to be dummy (or external) addresses which require translation
++to real (or internal) ones before forwarding.  The addresses to translate to
++are selected with the attribute
++.BR "via" .
++
++.sp
++.B anycast
++.RI "- " "not implemented"
++the destinations are
++.I anycast
++addresses assigned to this host.  They are mainly equivalent
++to
++.B local
++with one difference: such addresses are invalid when used
++as the source address of any packet.
++
++.sp
++.B multicast
++- a special type used for multicast routing.  It is not present in
++normal routing tables.
++.in -8
++
++.P
++.B Route tables:
++Linux-2.x can pack routes into several routing
++tables identified by a number in the range from 1 to 255 or by
++name from the file
++.B /etc/iproute2/rt_tables
++. By default all normal routes are inserted into the
++.B main
++table (ID 254) and the kernel only uses this table when calculating routes.
++
++.sp
++Actually, one other table always exists, which is invisible but
++even more important.  It is the
++.B local
++table (ID 255).  This table
++consists of routes for local and broadcast addresses.  The kernel maintains
++this table automatically and the administrator usually need not modify it
++or even look at it.
++
++The multiple routing tables enter the game when
++.I policy routing
++is used.
++
++.SS ip route add - add new route
++.SS ip route change - change route
++.SS ip route replace - change or add new one
++
++.TP
++.BI to " TYPE PREFIX " (default)
++the destination prefix of the route.  If
++.I TYPE
++is omitted,
++.B ip
++assumes type
++.BR "unicast" .
++Other values of
++.I TYPE
++are listed above.
++.I PREFIX
++is an IP or IPv6 address optionally followed by a slash and the
++prefix length.  If the length of the prefix is missing,
++.B ip
++assumes a full-length host route.  There is also a special
++.I PREFIX
++.B default
++- which is equivalent to IP
++.B 0/0
++or to IPv6
++.BR "::/0" .
++
++.TP
++.BI tos " TOS"
++.TP
++.BI dsfield " TOS"
++the Type Of Service (TOS) key.  This key has no associated mask and
++the longest match is understood as: First, compare the TOS
++of the route and of the packet.  If they are not equal, then the packet
++may still match a route with a zero TOS.
++.I TOS
++is either an 8 bit hexadecimal number or an identifier
++from
++.BR "/etc/iproute2/rt_dsfield" .
++
++.TP
++.BI metric " NUMBER"
++.TP
++.BI preference " NUMBER"
++the preference value of the route.
++.I NUMBER
++is an arbitrary 32bit number.
++
++.TP
++.BI table " TABLEID"
++the table to add this route to.
++.I TABLEID
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_tables" .
++If this parameter is omitted,
++.B ip
++assumes the
++.B main
++table, with the exception of
++.BR local " , " broadcast " and " nat
++routes, which are put into the
++.B local
++table by default.
++
++.TP
++.BI dev " NAME"
++the output device name.
++
++.TP
++.BI via " ADDRESS"
++the address of the nexthop router.  Actually, the sense of this field
++depends on the route type.  For normal
++.B unicast
++routes it is either the true next hop router or, if it is a direct
++route installed in BSD compatibility mode, it can be a local address
++of the interface.  For NAT routes it is the first address of the block
++of translated IP destinations.
++
++.TP
++.BI src " ADDRESS"
++the source address to prefer when sending to the destinations
++covered by the route prefix.
++
++.TP
++.BI realm " REALMID"
++the realm to which this route is assigned.
++.I REALMID
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_realms" .
++
++.TP
++.BI mtu " MTU"
++.TP
++.BI "mtu lock" " MTU"
++the MTU along the path to the destination.  If the modifier
++.B lock
++is not used, the MTU may be updated by the kernel due to
++Path MTU Discovery.  If the modifier
++.B lock
++is used, no path MTU discovery will be tried, all packets
++will be sent without the DF bit in IPv4 case or fragmented
++to MTU for IPv6.
++
++.TP
++.BI window " NUMBER"
++the maximal window for TCP to advertise to these destinations,
++measured in bytes.  It limits maximal data bursts that our TCP
++peers are allowed to send to us.
++
++.TP
++.BI rtt " NUMBER"
++the initial RTT ('Round Trip Time') estimate.
++
++.TP
++.BI rttvar " NUMBER " "(2.3.15+ only)"
++the initial RTT variance estimate.
++
++.TP
++.BI ssthresh " NUMBER " "(2.3.15+ only)"
++an estimate for the initial slow start threshold.
++
++.TP
++.BI cwnd " NUMBER " "(2.3.15+ only)"
++the clamp for congestion window.  It is ignored if the
++.B lock
++flag is not used.
++
++.TP
++.BI advmss " NUMBER " "(2.3.15+ only)"
++the MSS ('Maximal Segment Size') to advertise to these
++destinations when establishing TCP connections.  If it is not given,
++Linux uses a default value calculated from the first hop device MTU.
++(If the path to these destination is asymmetric, this guess may be wrong.)
++
++.TP
++.BI reordering " NUMBER " "(2.3.15+ only)"
++Maximal reordering on the path to this destination.
++If it is not given, Linux uses the value selected with
++.B sysctl
++variable
++.BR "net/ipv4/tcp_reordering" .
++
++.TP
++.BI nexthop " NEXTHOP"
++the nexthop of a multipath route.
++.I NEXTHOP
++is a complex value with its own syntax similar to the top level
++argument lists:
++
++.in +8
++.BI via " ADDRESS"
++- is the nexthop router.
++.sp
++
++.BI dev " NAME"
++- is the output device.
++.sp
++
++.BI weight " NUMBER"
++- is a weight for this element of a multipath
++route reflecting its relative bandwidth or quality.
++.in -8
++
++.TP
++.BI scope " SCOPE_VAL"
++the scope of the destinations covered by the route prefix.
++.I SCOPE_VAL
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_scopes" .
++If this parameter is omitted,
++.B ip
++assumes scope
++.B global
++for all gatewayed
++.B unicast
++routes, scope
++.B link
++for direct
++.BR unicast " and " broadcast
++routes and scope
++.BR host " for " local
++routes.
++
++.TP
++.BI protocol " RTPROTO"
++the routing protocol identifier of this route.
++.I RTPROTO
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_protos" .
++If the routing protocol ID is not given,
++.B ip assumes protocol
++.B boot
++(i.e. it assumes the route was added by someone who doesn't
++understand what they are doing).  Several protocol values have
++a fixed interpretation.
++Namely:
++
++.in +8
++.B redirect
++- the route was installed due to an ICMP redirect.
++.sp
++
++.B kernel
++- the route was installed by the kernel during autoconfiguration.
++.sp
++
++.B boot
++- the route was installed during the bootup sequence.
++If a routing daemon starts, it will purge all of them.
++.sp
++
++.B static
++- the route was installed by the administrator
++to override dynamic routing. Routing daemon will respect them
++and, probably, even advertise them to its peers.
++.sp
++
++.B ra
++- the route was installed by Router Discovery protocol.
++.in -8
++
++.sp
++The rest of the values are not reserved and the administrator is free
++to assign (or not to assign) protocol tags.
++
++.TP
++.B onlink
++pretend that the nexthop is directly attached to this link,
++even if it does not match any interface prefix.
++
++.TP
++.B equalize
++allow packet by packet randomization on multipath routes.
++Without this modifier, the route will be frozen to one selected
++nexthop, so that load splitting will only occur on per-flow base.
++.B equalize
++only works if the kernel is patched.
++
++.SS ip route delete - delete route
++
++.B ip route del
++has the same arguments as
++.BR "ip route add" ,
++but their semantics are a bit different.
++
++Key values
++.RB "(" to ", " tos ", " preference " and " table ")"
++select the route to delete.  If optional attributes are present,
++.B ip
++verifies that they coincide with the attributes of the route to delete.
++If no route with the given key and attributes was found,
++.B ip route del
++fails.
++
++.SS ip route show - list routes
++the command displays the contents of the routing tables or the route(s)
++selected by some criteria.
++
++.TP
++.BI to " SELECTOR " (default)
++only select routes from the given range of destinations.
++.I SELECTOR
++consists of an optional modifier
++.RB "(" root ", " match " or " exact ")"
++and a prefix.
++.BI root " PREFIX"
++selects routes with prefixes not shorter than
++.IR PREFIX "."
++F.e.
++.BI root " 0/0"
++selects the entire routing table.
++.BI match " PREFIX"
++selects routes with prefixes not longer than
++.IR PREFIX "."
++F.e.
++.BI match " 10.0/16"
++selects
++.IR 10.0/16 ","
++.IR 10/8 " and " 0/0 ,
++but it does not select
++.IR 10.1/16 " and " 10.0.0/24 .
++And
++.BI exact " PREFIX"
++(or just
++.IR PREFIX ")"
++selects routes with this exact prefix. If neither of these options
++are present,
++.B ip
++assumes
++.BI root " 0/0"
++i.e. it lists the entire table.
++
++.TP
++.BI tos " TOS"
++.BI dsfield " TOS"
++only select routes with the given TOS.
++
++.TP
++.BI table " TABLEID"
++show the routes from this table(s).  The default setting is to show
++.BR table main "."
++.I TABLEID
++may either be the ID of a real table or one of the special values:
++.sp
++.in +8
++.B all
++- list all of the tables.
++.sp
++.B cache
++- dump the routing cache.
++.in -8
++
++.TP
++.B cloned
++.TP
++.B cached
++list cloned routes i.e. routes which were dynamically forked from
++other routes because some route attribute (f.e. MTU) was updated.
++Actually, it is equivalent to
++.BR "table cache" "."
++
++.TP
++.BI from " SELECTOR"
++the same syntax as for
++.BR to ","
++but it binds the source address range rather than destinations.
++Note that the
++.B from
++option only works with cloned routes.
++
++.TP
++.BI protocol " RTPROTO"
++only list routes of this protocol.
++
++.TP
++.BI scope " SCOPE_VAL"
++only list routes with this scope.
++
++.TP
++.BI type " TYPE"
++only list routes of this type.
++
++.TP
++.BI dev " NAME"
++only list routes going via this device.
++
++.TP
++.BI via " PREFIX"
++only list routes going via the nexthop routers selected by
++.IR PREFIX "."
++
++.TP
++.BI src " PREFIX"
++only list routes with preferred source addresses selected
++by
++.IR PREFIX "."
++
++.TP
++.BI realm " REALMID"
++.TP
++.BI realms " FROMREALM/TOREALM"
++only list routes with these realms.
++
++.SS ip route flush - flush routing tables
++this command flushes routes selected by some criteria.
++
++.sp
++The arguments have the same syntax and semantics as the arguments of
++.BR "ip route show" ,
++but routing tables are not listed but purged.  The only difference is
++the default action:
++.B show
++dumps all the IP main routing table but
++.B flush
++prints the helper page.
++
++.sp
++With the
++.B -statistics
++option, the command becomes verbose. It prints out the number of
++deleted routes and the number of rounds made to flush the routing
++table. If the option is given
++twice,
++.B ip route flush
++also dumps all the deleted routes in the format described in the
++previous subsection.
++
++.SS ip route get - get a single route
++this command gets a single route to a destination and prints its
++contents exactly as the kernel sees it.
++
++.TP
++.BI to " ADDRESS " (default)
++the destination address.
++
++.TP
++.BI from " ADDRESS"
++the source address.
++
++.TP
++.BI tos " TOS"
++.TP
++.BI dsfield " TOS"
++the Type Of Service.
++
++.TP
++.BI iif " NAME"
++the device from which this packet is expected to arrive.
++
++.TP
++.BI oif " NAME"
++force the output device on which this packet will be routed.
++
++.TP
++.B connected
++if no source address 
++.RB "(option " from ")"
++was given, relookup the route with the source set to the preferred
++address received from the first lookup.
++If policy routing is used, it may be a different route.
++
++.P
++Note that this operation is not equivalent to
++.BR "ip route show" .
++.B show
++shows existing routes.
++.B get
++resolves them and creates new clones if necessary.  Essentially,
++.B get
++is equivalent to sending a packet along this path.
++If the
++.B iif
++argument is not given, the kernel creates a route
++to output packets towards the requested destination.
++This is equivalent to pinging the destination
++with a subsequent
++.BR "ip route ls cache" ,
++however, no packets are actually sent.  With the
++.B iif
++argument, the kernel pretends that a packet arrived from this interface
++and searches for a path to forward the packet.
++
++.SH ip rule - routing policy database management
++
++.BR "Rule" s
++in the routing policy database control the route selection algorithm.
++
++.P
++Classic routing algorithms used in the Internet make routing decisions
++based only on the destination address of packets (and in theory,
++but not in practice, on the TOS field).
++
++.P
++In some circumstances we want to route packets differently depending not only
++on destination addresses, but also on other packet fields: source address,
++IP protocol, transport protocol ports or even packet payload.
++This task is called 'policy routing'.
++
++.P
++To solve this task, the conventional destination based routing table, ordered
++according to the longest match rule, is replaced with a 'routing policy
++database' (or RPDB), which selects routes by executing some set of rules.
++
++.P
++Each policy routing rule consists of a
++.B selector
++and an
++.B action predicate.
++The RPDB is scanned in the order of increasing priority. The selector
++of each rule is applied to {source address, destination address, incoming
++interface, tos, fwmark} and, if the selector matches the packet,
++the action is performed.  The action predicate may return with success.
++In this case, it will either give a route or failure indication
++and the RPDB lookup is terminated. Otherwise, the RPDB program
++continues on the next rule.
++
++.P
++Semantically, natural action is to select the nexthop and the output device.
++
++.P
++At startup time the kernel configures the default RPDB consisting of three
++rules:
++
++.TP
++1.
++Priority: 0, Selector: match anything, Action: lookup routing
++table
++.B local
++(ID 255).
++The
++.B local
++table is a special routing table containing
++high priority control routes for local and broadcast addresses.
++.sp
++Rule 0 is special. It cannot be deleted or overridden.
++
++.TP
++2.
++Priority: 32766, Selector: match anything, Action: lookup routing
++table
++.B main
++(ID 254).
++The
++.B main
++table is the normal routing table containing all non-policy
++routes. This rule may be deleted and/or overridden with other
++ones by the administrator.
++
++.TP
++3.
++Priority: 32767, Selector: match anything, Action: lookup routing
++table
++.B default
++(ID 253).
++The
++.B default
++table is empty.  It is reserved for some post-processing if no previous
++default rules selected the packet.
++This rule may also be deleted.
++
++.P
++Each RPDB entry has additional
++attributes.  F.e. each rule has a pointer to some routing
++table.  NAT and masquerading rules have an attribute to select new IP
++address to translate/masquerade.  Besides that, rules have some
++optional attributes, which routes have, namely
++.BR "realms" .
++These values do not override those contained in the routing tables.  They
++are only used if the route did not select any attributes.
++
++.sp
++The RPDB may contain rules of the following types:
++
++.in +8
++.B unicast
++- the rule prescribes to return the route found
++in the routing table referenced by the rule.
++
++.B blackhole
++- the rule prescribes to silently drop the packet.
++
++.B unreachable
++- the rule prescribes to generate a 'Network is unreachable' error.
++
++.B prohibit
++- the rule prescribes to generate 'Communication is administratively
++prohibited' error.
++
++.B nat
++- the rule prescribes to translate the source address
++of the IP packet into some other value.
++.in -8
++
++.SS ip rule add - insert a new rule
++.SS ip rule delete - delete a rule
++
++.TP
++.BI type " TYPE " (default)
++the type of this rule.  The list of valid types was given in the previous
++subsection.
++
++.TP
++.BI from " PREFIX"
++select the source prefix to match.
++
++.TP
++.BI to " PREFIX"
++select the destination prefix to match.
++
++.TP
++.BI iif " NAME"
++select the incoming device to match.  If the interface is loopback,
++the rule only matches packets originating from this host.  This means
++that you may create separate routing tables for forwarded and local
++packets and, hence, completely segregate them.
++
++.TP
++.BI tos " TOS"
++.TP
++.BI dsfield " TOS"
++select the TOS value to match.
++
++.TP
++.BI fwmark " MARK"
++select the
++.B fwmark
++value to match.
++
++.TP
++.BI priority " PREFERENCE"
++the priority of this rule.  Each rule should have an explicitly
++set
++.I unique
++priority value.
++
++.TP
++.BI table " TABLEID"
++the routing table identifier to lookup if the rule selector matches.
++
++.TP
++.BI realms " FROM/TO"
++Realms to select if the rule matched and the routing table lookup
++succeeded.  Realm 
++.I TO
++is only used if the route did not select any realm.
++
++.TP
++.BI nat " ADDRESS"
++The base of the IP address block to translate (for source addresses).
++The 
++.I ADDRESS
++may be either the start of the block of NAT addresses (selected by NAT
++routes) or a local host address (or even zero).
++In the last case the router does not translate the packets, but
++masquerades them to this address.
++
++.B Warning:
++Changes to the RPDB made with these commands do not become active
++immediately.  It is assumed that after a script finishes a batch of
++updates, it flushes the routing cache with
++.BR "ip route flush cache" .
++
++.SS ip rule show - list rules
++This command has no arguments.
++
++.SH ip maddress - multicast addresses management
++
++.B maddress
++objects are multicast addresses.
++
++.SS ip maddress show - list multicast addresses
++
++.TP
++.BI dev " NAME " (default)
++the device name.
++
++.SS ip maddress add - add a multicast address
++.SS ip maddress delete - delete a multicast address
++these commands attach/detach a static link layer multicast address
++to listen on the interface.
++Note that it is impossible to join protocol multicast groups
++statically.  This command only manages link layer addresses.
++
++.TP
++.BI address " LLADDRESS " (default)
++the link layer multicast address.
++
++.TP
++.BI dev " NAME"
++the device to join/leave this multicast address.
++
++.SH ip mroute - multicast routing cache management
++.B mroute
++objects are multicast routing cache entries created by a user level
++mrouting daemon (f.e.
++.B pimd
++or
++.B mrouted
++).
++
++Due to the limitations of the current interface to the multicast routing
++engine, it is impossible to change
++.B mroute
++objects administratively, so we may only display them.  This limitation
++will be removed in the future.
++
++.SS ip mroute show - list mroute cache entries
++
++.TP
++.BI to " PREFIX " (default)
++the prefix selecting the destination multicast addresses to list.
++
++.TP
++.BI iif " NAME"
++the interface on which multicast packets are received.
++
++.TP
++.BI from " PREFIX"
++the prefix selecting the IP source addresses of the multicast route.
++
++.SH ip tunnel - tunnel configuration
++.B tunnel
++objects are tunnels, encapsulating packets in IPv4 packets and then
++sending them over the IP infrastructure.
++
++.SS ip tunnel add - add a new tunnel
++.SS ip tunnel change - change an existing tunnel
++.SS ip tunnel delete - destroy a tunnel
++
++.TP
++.BI name " NAME " (default)
++select the tunnel device name.
++
++.TP
++.BI mode " MODE"
++set the tunnel mode.  Three modes are currently available:
++.BR ipip ", " sit " and " gre "."
++
++.TP
++.BI remote " ADDRESS"
++set the remote endpoint of the tunnel.
++
++.TP
++.BI local " ADDRESS"
++set the fixed local address for tunneled packets.
++It must be an address on another interface of this host.
++
++.TP
++.BI ttl " N"
++set a fixed TTL 
++.I N
++on tunneled packets.
++.I N
++is a number in the range 1--255. 0 is a special value
++meaning that packets inherit the TTL value. 
++The default value is:
++.BR "inherit" .
++
++.TP
++.BI tos " T"
++.TP
++.BI dsfield " T"
++set a fixed TOS
++.I T
++on tunneled packets.
++The default value is:
++.BR "inherit" .
++
++.TP
++.BI dev " NAME" 
++bind the tunnel to the device
++.I NAME
++so that tunneled packets will only be routed via this device and will
++not be able to escape to another device when the route to endpoint
++changes.
++
++.TP
++.B nopmtudisc
++disable Path MTU Discovery on this tunnel.
++It is enabled by default.  Note that a fixed ttl is incompatible
++with this option: tunnelling with a fixed ttl always makes pmtu
++discovery.
++
++.TP
++.BI key " K"
++.TP
++.BI ikey " K"
++.TP
++.BI okey " K"
++.RB ( " only GRE tunnels " )
++use keyed GRE with key
++.IR K ". " K
++is either a number or an IP address-like dotted quad.
++The
++.B key
++parameter sets the key to use in both directions.
++The
++.BR ikey " and " okey
++parameters set different keys for input and output.
++   
++.TP
++.BR csum ", " icsum ", " ocsum
++.RB ( " only GRE tunnels " )
++generate/require checksums for tunneled packets.
++The 
++.B ocsum
++flag calculates checksums for outgoing packets.
++The
++.B icsum
++flag requires that all input packets have the correct
++checksum.  The
++.B csum
++flag is equivalent to the combination
++.BR "icsum ocsum" .
++
++.TP
++.BR seq ", " iseq ", " oseq
++.RB ( " only GRE tunnels " )
++serialize packets.
++The
++.B oseq
++flag enables sequencing of outgoing packets.
++The
++.B iseq
++flag requires that all input packets are serialized.
++The
++.B  seq
++flag is equivalent to the combination 
++.BR "iseq oseq" .
++.B It isn't work. Don't use it.
++
++.SS ip tunnel show - list tunnels
++This command has no arguments.
++
++.SH ip monitor and rtmon - state monitoring
++
++The
++.B ip
++utility can monitor the state of devices, addresses
++and routes continuously.  This option has a slightly different format.
++Namely, the
++.B monitor
++command is the first in the command line and then the object list follows:
++
++.BR "ip monitor" " [ " all " |"
++.IR LISTofOBJECTS " ]"
++
++.I OBJECT-LIST
++is the list of object types that we want to monitor.
++It may contain
++.BR link ", " address " and " route "."
++If no
++.B file
++argument is given,
++.B ip
++opens RTNETLINK, listens on it and dumps state changes in the format
++described in previous sections.
++
++.P
++If a file name is given, it does not listen on RTNETLINK,
++but opens the file containing RTNETLINK messages saved in binary format
++and dumps them.  Such a history file can be generated with the
++.B rtmon
++utility.  This utility has a command line syntax similar to
++.BR "ip monitor" .
++Ideally,
++.B rtmon
++should be started before the first network configuration command
++is issued. F.e. if you insert:
++.sp
++.in +8
++rtmon file /var/log/rtmon.log
++.in -8
++.sp
++in a startup script, you will be able to view the full history
++later.
++
++.P
++Certainly, it is possible to start
++.B rtmon
++at any time.
++It prepends the history with the state snapshot dumped at the moment
++of starting.
++
++.SH HISTORY
++
++.B ip
++was written by Alexey N. Kuznetsov and added in Linux 2.2.
++.SH SEE ALSO
++.BR tc (8)
++.br
++.RB "IP Command reference " ip-cref.ps
++.br
++.RB "IP tunnels " ip-cref.ps
++
++.SH AUTHOR
++
++Manpage maintained by Michail Litvak <mci@owl.openwall.com>
+diff -Naur iproute2-orig/debian/manpages/old/ip.8 iproute2/debian/manpages/old/ip.8
+--- iproute2-orig/debian/manpages/old/ip.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/ip.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,1809 @@
++.TH IP 8 "17 January 2002" "iproute2" "Linux"
++.SH NAME
++ip \- show / manipulate routing, devices, policy routing and tunnels
++.SH SYNOPSIS
++
++.ad l
++.in +8
++.ti -8
++.B ip
++.RI "[ " OPTIONS " ] " OBJECT " { " COMMAND " | "
++.BR help " }"
++.sp
++
++.ti -8
++.IR OBJECT " := { "
++.BR link " | " addr " | " route " | " rule " | " neigh " | " tunnel " | "\
++maddr " | "  mroute " | " monitor " }"
++.sp
++
++.ti -8
++.IR OPTIONS " := { " 
++\fB\-V\fR[\fIersion\fR] |
++\fB\-s\fR[\fItatistics\fR] |
++\fB\-r\fR[\fIesolve\fR] |
++\fB\-f\fR[\fIamily\fR] {
++.BR inet " | " inet6 " | " ipx " | " dnet " | " link " } | "
++\fB\-o\fR[\fIneline\fR] }
++
++.ti -8
++.BI "ip link set " DEVICE
++.RB "{ " up " | " down " | " arp " { " on " | " off " } |"
++.br
++.BR promisc " { " on " | " off " } |"
++.br
++.BR allmulti " { " on " | " off " } |"
++.br
++.BR dynamic " { " on " | " off " } |"
++.br
++.BR multicast " { " on " | " off " } |"
++.br
++.B  txqueuelen
++.IR PACKETS " |"
++.br
++.B  name
++.IR NEWNAME " |"
++.br
++.B  address
++.IR LLADDR " |"
++.B  broadcast 
++.IR LLADDR " |"
++.br
++.B  mtu
++.IR MTU " }"
++
++.ti -8
++.B ip link show
++.RI "[ " DEVICE " ]"
++
++.ti -8
++.BR "ip addr" " { " add " | " del " } " 
++.IB IFADDR " dev " STRING
++
++.ti -8
++.BR "ip addr" " { " show " | " flush " } [ " dev
++.IR STRING " ] [ "
++.B  scope
++.IR SCOPE-ID " ] [ "
++.B  to 
++.IR PREFIX " ] [ " FLAG-LIST " ] [ "
++.B  label
++.IR PATTERN " ]"
++
++.ti -8
++.IR IFADDR " := " PREFIX " | " ADDR
++.B  peer
++.IR PREFIX " [ "
++.B  broadcast
++.IR ADDR " ] [ "
++.B  anycast
++.IR ADDR " ] [ "
++.B  label
++.IR STRING " ] [ "
++.B  scope
++.IR SCOPE-ID " ]"
++
++.ti -8
++.IR SCOPE-ID " := "
++.RB "[ " host " | " link " | " global " | "
++.IR NUMBER " ]"
++
++.ti -8
++.IR FLAG-LIST " := [ "  FLAG-LIST " ] " FLAG
++
++.ti -8
++.IR FLAG " := "
++.RB "[ " permanent " | " dynamic " | " secondary " | " primary " | "\
++tentative " | " deprecated " ]"
++
++.ti -8
++.BR "ip route" " { "
++.BR list " | " flush " } "
++.I  SELECTOR
++
++.ti -8
++.B  ip route get 
++.IR ADDRESS " [ "
++.BI from " ADDRESS " iif " STRING"
++.RB " ] [ " oif 
++.IR STRING " ] [ "
++.B  tos
++.IR TOS " ]"
++
++.ti -8
++.BR "ip route" " { " add " | " del " | " change " | " append " | "\
++replace " | " monitor " } "
++.I  ROUTE
++
++.ti -8
++.IR SELECTOR " := "
++.RB "[ " root
++.IR PREFIX " ] [ "
++.B  match
++.IR PREFIX " ] [ "
++.B  exact
++.IR PREFIX " ] [ "
++.B  table
++.IR TABLE_ID " ] [ "
++.B  proto
++.IR RTPROTO " ] [ "
++.B  type
++.IR TYPE " ] [ "
++.B  scope
++.IR SCOPE " ]"
++
++.ti -8
++.IR ROUTE " := " NODE_SPEC " [ " INFO_SPEC " ]"
++
++.ti -8
++.IR NODE_SPEC " := [ " TYPE " ] " PREFIX " ["
++.B  tos
++.IR TOS " ] [ "
++.B  table
++.IR TABLE_ID " ] [ "
++.B  proto
++.IR RTPROTO " ] [ "
++.B  scope
++.IR SCOPE " ] [ "
++.B  metric
++.IR METRIC " ]"
++
++.ti -8
++.IR INFO_SPEC " := " "NH OPTIONS FLAGS" " ["
++.B  nexthop
++.IR NH " ] ..."
++
++.ti -8
++.IR NH " := [ "
++.B  via
++.IR ADDRESS " ] [ "
++.B  dev
++.IR STRING " ] [ "
++.B  weight
++.IR NUMBER " ] " NHFLAGS
++
++.ti -8
++.IR OPTIONS " := " FLAGS " [ "
++.B  mtu
++.IR NUMBER " ] [ "
++.B  advmss
++.IR NUMBER " ] [ "
++.B  rtt
++.IR NUMBER " ] [ "
++.B  rttvar
++.IR NUMBER " ] [ "
++.B  window
++.IR NUMBER " ] [ "
++.B  cwnd
++.IR NUMBER " ] [ "
++.B  ssthresh
++.IR REALM " ] [ "
++.B  realms
++.IR REALM " ]"
++
++.ti -8
++.IR TYPE " := [ "
++.BR unicast " | " local " | " broadcast " | " multicast " | "\
++throw " | " unreachable " | " prohibit " | " blackhole " | " nat " ]"
++
++.ti -8
++.IR TABLE_ID " := [ "
++.BR local "| " main " | " default " | " all " |"
++.IR NUMBER " ]"
++
++.ti -8
++.IR SCOPE " := [ "
++.BR host " | " link " | " global " |"
++.IR NUMBER " ]"
++
++.ti -8
++.IR FLAGS " := [ "
++.BR equalize " ]"
++
++.ti -8
++.IR NHFLAGS " := [ "
++.BR onlink " | " pervasive " ]"
++
++.ti -8
++.IR RTPROTO " := [ "
++.BR kernel " | " boot " | " static " |"
++.IR NUMBER " ]"
++
++.ti -8
++.B  ip rule
++.RB " [ " list " | " add " | " del " ]"
++.I  SELECTOR ACTION
++
++.ti -8
++.IR SELECTOR " := [ "
++.B  from
++.IR PREFIX " ] [ "
++.B  to
++.IR PREFIX " ] [ "
++.B  tos
++.IR TOS " ] [ "
++.B  fwmark
++.IR FWMARK " ] [ "
++.B  dev
++.IR STRING " ] [ "
++.B  pref
++.IR NUMBER " ]"
++
++.ti -8
++.IR ACTION " := [ "
++.B  table
++.IR TABLE_ID " ] [ "
++.B  nat
++.IR ADDRESS " ] [ "
++.BR prohibit " | " reject " | " unreachable " ] [ " realms
++.RI "[" SRCREALM "/]" DSTREALM " ]"
++
++.ti -8
++.IR TABLE_ID " := [ "
++.BR local " | " main " | " default " |"
++.IR NUMBER " ]"
++
++.ti -8
++.BR "ip neigh" " { " add " | " del " | " change " | " replace " } { "
++.IR ADDR " [ "
++.B  lladdr
++.IR LLADDR " ] [ "
++.BR nud " { " permanent " | " noarp " | " stale " | " reachable " } ] | " proxy
++.IR ADDR " } [ "
++.B  dev
++.IR DEV " ]"
++
++.ti -8
++.BR "ip neigh" " { " show " | " flush " } [ " to
++.IR PREFIX " ] [ "
++.B  dev
++.IR DEV " ] [ "
++.B  nud
++.IR STATE " ]"
++
++.ti -8
++.BR "ip tunnel" " { " add " | " change " | " del " | " show " }"
++.RI "[ " NAME " ]"
++.br
++.RB "[ " mode " { " ipip " | " gre " | " sit " } ]"
++.br
++.RB "[ " remote
++.IR ADDR " ] [ "
++.B  local
++.IR ADDR " ]"
++.br
++.RB "[ [" i "|" o "]" seq " ] [ [" i "|" o "]" key
++.IR KEY " ] [ "
++.RB "[" i "|" o "]" csum " ] ]"
++.br
++.RB "[ " ttl
++.IR TTL " ] [ "
++.B  tos
++.IR TOS " ] [ "
++.RB "[" no "]" pmtudisc " ]"
++.br
++.RB "[ " dev
++.IR PHYS_DEV " ]"
++
++.ti -8
++.IR ADDR " := { " IP_ADDRESS " |"
++.BR any " }"
++
++.ti -8
++.IR TOS " := { " NUMBER " |"
++.BR inherit " }"
++
++.ti -8
++.IR TTL " := { " 1 ".." 255 " | "
++.BR inherit " }"
++
++.ti -8
++.IR KEY " := { " DOTTED_QUAD " | " NUMBER " }"
++
++.ti -8
++.BR "ip maddr" " [ " add " | " del " ]"
++.IB MULTIADDR " dev " STRING
++
++.ti -8
++.BR "ip maddr show" " [ " dev
++.IR STRING " ]"
++
++.ti -8
++.BR "ip mroute show" " ["
++.IR PREFIX " ] [ "
++.B  from
++.IR PREFIX " ] [ "
++.B  iif
++.IR DEVICE " ]"
++
++.ti -8
++.BR "ip monitor" " [ " all " |"
++.IR LISTofOBJECTS " ]"
++.in -8
++.ad b
++
++.SH OPTIONS
++
++.TP
++.BR "\-V" , " -Version"
++print the version of the
++.B ip
++utility and exit.
++
++.TP
++.BR "\-s" , " \-stats", " \-statistics"
++output more information.  If the option
++appears twice or more, the amount of information increases.
++As a rule, the information is statistics or some time values.
++
++.TP
++.BR "\-f" , " \-family"
++followed by protocol family identifier:
++.BR "inet" , " inet6"
++or
++.B link
++,enforce the protocol family to use.  If the option is not present,
++the protocol family is guessed from other arguments.  If the rest 
++of the command line does not give enough information to guess the
++family,
++.B ip
++falls back to the default one, usually
++.B inet
++or
++.BR "any" .
++.B link
++is a special family identifier meaning that no networking protocol
++is involved.
++
++.TP
++.B \-4
++shortcut for
++.BR "-family inet" .
++
++.TP
++.B \-6
++shortcut for
++.BR "\-family inet6" .
++
++.TP
++.B \-0
++shortcut for
++.BR "\-family link" .
++
++.TP
++.BR "\-o" , " \-oneline"
++output each record on a single line, replacing line feeds
++with the
++.B '\'
++character. This is convenient when you want to count records 
++with
++.BR wc (1)
++ or to
++.BR grep (1)
++the output.
++
++.TP
++.BR "\-r" , " \-resolve"
++use the system's name resolver to print DNS names instead of
++host addresses.
++
++.SH IP - COMMAND SYNTAX
++
++.SS
++.I OBJECT
++
++.TP
++.B link
++- network device.
++
++.TP
++.B address
++- protocol (IP or IPv6) address on a device.
++.TP
++.B neighbour
++- ARP or NDISC cache entry.
++
++.TP
++.B route
++- routing table entry.
++
++.TP
++.B rule
++- rule in routing policy database.
++
++.TP
++.B maddress
++- multicast address.
++
++.TP
++.B mroute
++- multicast routing cache entry.
++
++.TP
++.B tunnel
++- tunnel over IP.
++
++.PP
++The names of all objects may be written in full or
++abbreviated form, f.e.
++.B address
++is abbreviated as
++.B addr
++or just
++.B a.
++
++.SS
++.I COMMAND
++
++Specifies the action to perform on the object.
++The set of possible actions depends on the object type.
++As a rule, it is possible to
++.BR "add" , " delete"
++and
++.B show
++(or
++.B list
++) objects, but some objects do not allow all of these operations
++or have some additional commands.  The
++.B help
++command is available for all objects.  It prints
++out a list of available commands and argument syntax conventions.
++.sp
++If no command is given, some default command is assumed.
++Usually it is
++.B list
++or, if the objects of this class cannot be listed,
++.BR "help" .
++
++.SH ip link - network device configuration
++
++.B link
++is a network device and the corresponding commands
++display and change the state of devices.
++
++.SS ip link set - change device attributes
++
++.TP
++.BI dev " NAME " (default)
++.I NAME
++specifies network device to operate on.
++
++.TP
++.BR up " and " down
++change the state of the device to
++.B UP
++or
++.BR "DOWN" .
++
++.TP
++.BR "arp on " or " arp off"
++change the
++.B NOARP
++flag on the device.
++
++.TP
++.BR "multicast on " or " multicast off"
++change the
++.B MULTICAST
++flag on the device.
++
++.TP
++.BR "dynamic on " or " dynamic off"
++change the
++.B DYNAMIC
++flag on the device.
++
++.TP
++.BI name " NAME"
++change the name of the device.  This operation is not
++recommended if the device is running or has some addresses
++already configured.
++
++.TP
++.BI txqueuelen " NUMBER"
++.TP 
++.BI txqlen " NUMBER"
++change the transmit queue length of the device.
++
++.TP
++.BI mtu " NUMBER"
++change the 
++.I MTU
++of the device.
++
++.TP
++.BI address " LLADDRESS"
++change the station address of the interface.
++
++.TP
++.BI broadcast " LLADDRESS"
++.TP
++.BI brd " LLADDRESS"
++.TP
++.BI peer " LLADDRESS"
++change the link layer broadcast address or the peer address when
++the interface is
++.IR "POINTOPOINT" .
++
++.PP
++.B Warning:
++If multiple parameter changes are requested,
++.B ip
++aborts immediately after any of the changes have failed.
++This is the only case when
++.B ip
++can move the system to an unpredictable state.  The solution
++is to avoid changing several parameters with one
++.B ip link set
++call.
++
++.SS  ip link show - display device attributes
++
++.TP
++.BI dev " NAME " (default)
++.I NAME
++specifies the network device to show.
++If this argument is omitted all devices are listed.
++
++.TP
++.B up
++only display running interfaces.
++
++.SH ip address - protocol address management.
++
++The
++.B address
++is a protocol (IP or IPv6) address attached
++to a network device.  Each device must have at least one address
++to use the corresponding protocol.  It is possible to have several
++different addresses attached to one device.  These addresses are not
++discriminated, so that the term
++.B alias
++is not quite appropriate for them and we do not use it in this document.
++.sp
++The
++.B ip addr
++command displays addresses and their properties, adds new addresses
++and deletes old ones.
++
++.SS ip address add - add new protocol address.
++
++.TP
++.BI dev " NAME"
++the name of the device to add the address to.
++
++.TP
++.BI local " ADDRESS " (default)
++the address of the interface. The format of the address depends
++on the protocol. It is a dotted quad for IP and a sequence of
++hexadecimal halfwords separated by colons for IPv6.  The
++.I ADDRESS
++may be followed by a slash and a decimal number which encodes
++the network prefix length.
++
++.TP
++.BI peer " ADDRESS"
++the address of the remote endpoint for pointopoint interfaces.
++Again, the
++.I ADDRESS
++may be followed by a slash and a decimal number, encoding the network
++prefix length.  If a peer address is specified, the local address
++cannot have a prefix length.  The network prefix is associated
++with the peer rather than with the local address.
++
++.TP
++.BI broadcast " ADDRESS"
++the broadcast address on the interface.
++.sp
++It is possible to use the special symbols
++.B '+'
++and
++.B '-'
++instead of the broadcast address.  In this case, the broadcast address
++is derived by setting/resetting the host bits of the interface prefix.
++
++.TP
++.BI label " NAME"
++Each address may be tagged with a label string.
++In order to preserve compatibility with Linux-2.0 net aliases,
++this string must coincide with the name of the device or must be prefixed
++with the device name followed by colon.
++
++.TP
++.BI scope " SCOPE_VALUE"
++the scope of the area where this address is valid.
++The available scopes are listed in file
++.BR "/etc/iproute2/rt_scopes" .
++Predefined scope values are:
++
++.in +8
++.B global
++- the address is globally valid.
++.sp
++.B site
++- (IPv6 only) the address is site local, i.e. it is
++valid inside this site.
++.sp
++.B link
++- the address is link local, i.e. it is valid only on this device.
++.sp
++.B host
++- the address is valid only inside this host.
++.in -8
++
++.SS ip address delete - delete protocol address
++.B Arguments:
++coincide with the arguments of
++.B ip addr add.
++The device name is a required argument.  The rest are optional.
++If no arguments are given, the first address is deleted.
++
++.SS ip address show - look at protocol addresses
++
++.TP
++.BI dev " NAME " (default)
++name of device.
++
++.TP
++.BI scope " SCOPE_VAL"
++only list addresses with this scope.
++
++.TP
++.BI to " PREFIX"
++only list addresses matching this prefix.
++
++.TP
++.BI label " PATTERN"
++only list addresses with labels matching the
++.IR "PATTERN" .
++.I PATTERN
++is a usual shell style pattern.
++
++.TP
++.BR dynamic " and " permanent
++(IPv6 only) only list addresses installed due to stateless
++address configuration or only list permanent (not dynamic)
++addresses.
++
++.TP
++.B tentative
++(IPv6 only) only list addresses which did not pass duplicate
++address detection.
++
++.TP
++.B deprecated
++(IPv6 only) only list deprecated addresses.
++
++.TP
++.BR primary " and " secondary
++only list primary (or secondary) addresses.
++
++.SS ip address flush - flush protocol addresses
++This command flushes the protocol addresses selected by some criteria.
++
++.PP
++This command has the same arguments as
++.B show.
++The difference is that it does not run when no arguments are given.
++
++.PP
++.B Warning:
++This command (and other
++.B flush
++commands described below) is pretty dangerous.  If you make a mistake,
++it will not forgive it, but will cruelly purge all the addresses.
++
++.PP
++With the
++.B -statistics
++option, the command becomes verbose. It prints out the number of deleted
++addresses and the number of rounds made to flush the address list.  If
++this option is given twice,
++.B ip addr flush
++also dumps all the deleted addresses in the format described in the
++previous subsection.
++
++.SH ip neighbour - neighbour/arp tables management.
++
++.B neighbour
++objects establish bindings between protocol addresses and
++link layer addresses for hosts sharing the same link.
++Neighbour entries are organized into tables. The IPv4 neighbour table
++is known by another name - the ARP table.
++
++.P
++The corresponding commands display neighbour bindings
++and their properties, add new neighbour entries and delete old ones.
++
++.SS ip neighbour add - add a new neighbour entry
++.SS ip neighbour change - change an existing entry
++.SS ip neighbour replace - add a new entry or change an existing one
++
++These commands create new neighbour records or update existing ones.
++
++.TP
++.BI to " ADDRESS " (default)
++the protocol address of the neighbour. It is either an IPv4 or IPv6 address.
++
++.TP
++.BI dev " NAME"
++the interface to which this neighbour is attached.
++
++.TP
++.BI lladdr " LLADDRESS"
++the link layer address of the neighbour.
++.I LLADDRESS
++can also be
++.BR "null" .
++
++.TP
++.BI nud " NUD_STATE"
++the state of the neighbour entry.
++.B nud
++is an abbreviation for 'Neigh bour Unreachability Detection'.
++The state can take one of the following values:
++
++.in +8
++.B permanent
++- the neighbour entry is valid forever and can be only
++be removed administratively.
++.sp
++
++.B noarp
++- the neighbour entry is valid. No attempts to validate
++this entry will be made but it can be removed when its lifetime expires.
++.sp
++
++.B reachable
++- the neighbour entry is valid until the reachability
++timeout expires.
++.sp
++
++.B stale
++- the neighbour entry is valid but suspicious.
++This option to
++.B ip neigh
++does not change the neighbour state if it was valid and the address
++is not changed by this command.
++.in -8
++
++.SS ip neighbour delete - delete a neighbour entry
++This command invalidates a neighbour entry.
++
++.PP
++The arguments are the same as with
++.BR "ip neigh add" ,
++except that
++.B lladdr
++and
++.B nud
++are ignored.
++
++.PP
++.B Warning:
++Attempts to delete or manually change a
++.B noarp
++entry created by the kernel may result in unpredictable behaviour.
++Particularly, the kernel may try to resolve this address even
++on a
++.B NOARP
++interface or if the address is multicast or broadcast.
++
++.SS ip neighbour show - list neighbour entries
++
++This commands displays neighbour tables.
++
++.TP
++.BI to " ADDRESS " (default)
++the prefix selecting the neighbours to list.
++
++.TP
++.BI dev " NAME"
++only list the neighbours attached to this device.
++
++.TP
++.B unused
++only list neighbours which are not currently in use.
++
++.TP
++.BI nud " NUD_STATE"
++only list neighbour entries in this state.
++.I NUD_STATE
++takes values listed below or the special value
++.B all
++which means all states.  This option may occur more than once.
++If this option is absent,
++.B ip
++lists all entries except for
++.B none
++and
++.BR "noarp" .
++
++.SS ip neighbour flush - flush neighbour entries
++This command flushes neighbour tables, selecting
++entries to flush by some criteria.
++
++.PP
++This command has the same arguments as
++.B show.
++The differences are that it does not run when no arguments are given,
++and that the default neighbour states to be flushed do not include
++.B permanent
++and
++.BR "noarp" .
++
++.PP
++With the
++.B -statistics
++option, the command becomes verbose.  It prints out the number of
++deleted neighbours and the number of rounds made to flush the
++neighbour table.  If the option is given
++twice,
++.B ip neigh flush
++also dumps all the deleted neighbours.
++
++.SH ip route - routing table management
++Manipulate route entries in the kernel routing tables keep
++information about paths to other networked nodes.
++.sp
++.B Route types:
++
++.in +8
++.B unicast
++- the route entry describes real paths to the destinations covered
++by the route prefix.
++
++.sp
++.B unreachable
++- these destinations are unreachable.  Packets are discarded and the
++ICMP message
++.I host unreachable
++is generated.
++The local senders get an
++.I EHOSTUNREACH
++error.
++
++.sp
++.B blackhole
++- these destinations are unreachable.  Packets are discarded silently.
++The local senders get an
++.I EINVAL
++error.
++
++.sp
++.B prohibit
++- these destinations are unreachable.  Packets are discarded and the
++ICMP message
++.I communication administratively prohibited
++is generated.  The local senders get an
++.I EACCES
++error.
++
++.sp
++.B local
++- the destinations are assigned to this host.  The packets are looped
++back and delivered locally.
++
++.sp
++.B broadcast
++- the destinations are broadcast addresses.  The packets are sent as
++link broadcasts.
++
++.sp
++.B throw
++- a special control route used together with policy rules. If such a
++route is selected, lookup in this table is terminated pretending that
++no route was found.  Without policy routing it is equivalent to the
++absence of the route in the routing table.  The packets are dropped
++and the ICMP message
++.I net unreachable
++is generated.  The local senders get an
++.I ENETUNREACH
++error.
++
++.sp
++.B nat
++- a special NAT route.  Destinations covered by the prefix
++are considered to be dummy (or external) addresses which require translation
++to real (or internal) ones before forwarding.  The addresses to translate to
++are selected with the attribute
++.BR "via" .
++
++.sp
++.B anycast
++.RI "- " "not implemented"
++the destinations are
++.I anycast
++addresses assigned to this host.  They are mainly equivalent
++to
++.B local
++with one difference: such addresses are invalid when used
++as the source address of any packet.
++
++.sp
++.B multicast
++- a special type used for multicast routing.  It is not present in
++normal routing tables.
++.in -8
++
++.P
++.B Route tables:
++Linux-2.x can pack routes into several routing
++tables identified by a number in the range from 1 to 255 or by
++name from the file
++.B /etc/iproute2/rt_tables
++. By default all normal routes are inserted into the
++.B main
++table (ID 254) and the kernel only uses this table when calculating routes.
++
++.sp
++Actually, one other table always exists, which is invisible but
++even more important.  It is the
++.B local
++table (ID 255).  This table
++consists of routes for local and broadcast addresses.  The kernel maintains
++this table automatically and the administrator usually need not modify it
++or even look at it.
++
++The multiple routing tables enter the game when
++.I policy routing
++is used.
++
++.SS ip route add - add new route
++.SS ip route change - change route
++.SS ip route replace - change or add new one
++
++.TP
++.BI to " TYPE PREFIX " (default)
++the destination prefix of the route.  If
++.I TYPE
++is omitted,
++.B ip
++assumes type
++.BR "unicast" .
++Other values of
++.I TYPE
++are listed above.
++.I PREFIX
++is an IP or IPv6 address optionally followed by a slash and the
++prefix length.  If the length of the prefix is missing,
++.B ip
++assumes a full-length host route.  There is also a special
++.I PREFIX
++.B default
++- which is equivalent to IP
++.B 0/0
++or to IPv6
++.BR "::/0" .
++
++.TP
++.BI tos " TOS"
++.TP
++.BI dsfield " TOS"
++the Type Of Service (TOS) key.  This key has no associated mask and
++the longest match is understood as: First, compare the TOS
++of the route and of the packet.  If they are not equal, then the packet
++may still match a route with a zero TOS.
++.I TOS
++is either an 8 bit hexadecimal number or an identifier
++from
++.BR "/etc/iproute2/rt_dsfield" .
++
++.TP
++.BI metric " NUMBER"
++.TP
++.BI preference " NUMBER"
++the preference value of the route.
++.I NUMBER
++is an arbitrary 32bit number.
++
++.TP
++.BI table " TABLEID"
++the table to add this route to.
++.I TABLEID
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_tables" .
++If this parameter is omitted,
++.B ip
++assumes the
++.B main
++table, with the exception of
++.BR local " , " broadcast " and " nat
++routes, which are put into the
++.B local
++table by default.
++
++.TP
++.BI dev " NAME"
++the output device name.
++
++.TP
++.BI via " ADDRESS"
++the address of the nexthop router.  Actually, the sense of this field
++depends on the route type.  For normal
++.B unicast
++routes it is either the true next hop router or, if it is a direct
++route installed in BSD compatibility mode, it can be a local address
++of the interface.  For NAT routes it is the first address of the block
++of translated IP destinations.
++
++.TP
++.BI src " ADDRESS"
++the source address to prefer when sending to the destinations
++covered by the route prefix.
++
++.TP
++.BI realm " REALMID"
++the realm to which this route is assigned.
++.I REALMID
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_realms" .
++
++.TP
++.BI mtu " MTU"
++.TP
++.BI "mtu lock" " MTU"
++the MTU along the path to the destination.  If the modifier
++.B lock
++is not used, the MTU may be updated by the kernel due to
++Path MTU Discovery.  If the modifier
++.B lock
++is used, no path MTU discovery will be tried, all packets
++will be sent without the DF bit in IPv4 case or fragmented
++to MTU for IPv6.
++
++.TP
++.BI window " NUMBER"
++the maximal window for TCP to advertise to these destinations,
++measured in bytes.  It limits maximal data bursts that our TCP
++peers are allowed to send to us.
++
++.TP
++.BI rtt " NUMBER"
++the initial RTT ('Round Trip Time') estimate.
++
++.TP
++.BI rttvar " NUMBER " "(2.3.15+ only)"
++the initial RTT variance estimate.
++
++.TP
++.BI ssthresh " NUMBER " "(2.3.15+ only)"
++an estimate for the initial slow start threshold.
++
++.TP
++.BI cwnd " NUMBER " "(2.3.15+ only)"
++the clamp for congestion window.  It is ignored if the
++.B lock
++flag is not used.
++
++.TP
++.BI advmss " NUMBER " "(2.3.15+ only)"
++the MSS ('Maximal Segment Size') to advertise to these
++destinations when establishing TCP connections.  If it is not given,
++Linux uses a default value calculated from the first hop device MTU.
++(If the path to these destination is asymmetric, this guess may be wrong.)
++
++.TP
++.BI reordering " NUMBER " "(2.3.15+ only)"
++Maximal reordering on the path to this destination.
++If it is not given, Linux uses the value selected with
++.B sysctl
++variable
++.BR "net/ipv4/tcp_reordering" .
++
++.TP
++.BI nexthop " NEXTHOP"
++the nexthop of a multipath route.
++.I NEXTHOP
++is a complex value with its own syntax similar to the top level
++argument lists:
++
++.in +8
++.BI via " ADDRESS"
++- is the nexthop router.
++.sp
++
++.BI dev " NAME"
++- is the output device.
++.sp
++
++.BI weight " NUMBER"
++- is a weight for this element of a multipath
++route reflecting its relative bandwidth or quality.
++.in -8
++
++.TP
++.BI scope " SCOPE_VAL"
++the scope of the destinations covered by the route prefix.
++.I SCOPE_VAL
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_scopes" .
++If this parameter is omitted,
++.B ip
++assumes scope
++.B global
++for all gatewayed
++.B unicast
++routes, scope
++.B link
++for direct
++.BR unicast " and " broadcast
++routes and scope
++.BR host " for " local
++routes.
++
++.TP
++.BI protocol " RTPROTO"
++the routing protocol identifier of this route.
++.I RTPROTO
++may be a number or a string from the file
++.BR "/etc/iproute2/rt_protos" .
++If the routing protocol ID is not given,
++.B ip assumes protocol
++.B boot
++(i.e. it assumes the route was added by someone who doesn't
++understand what they are doing).  Several protocol values have
++a fixed interpretation.
++Namely:
++
++.in +8
++.B redirect
++- the route was installed due to an ICMP redirect.
++.sp
++
++.B kernel
++- the route was installed by the kernel during autoconfiguration.
++.sp
++
++.B boot
++- the route was installed during the bootup sequence.
++If a routing daemon starts, it will purge all of them.
++.sp
++
++.B static
++- the route was installed by the administrator
++to override dynamic routing. Routing daemon will respect them
++and, probably, even advertise them to its peers.
++.sp
++
++.B ra
++- the route was installed by Router Discovery protocol.
++.in -8
++
++.sp
++The rest of the values are not reserved and the administrator is free
++to assign (or not to assign) protocol tags.
++
++.TP
++.B onlink
++pretend that the nexthop is directly attached to this link,
++even if it does not match any interface prefix.
++
++.TP
++.B equalize
++allow packet by packet randomization on multipath routes.
++Without this modifier, the route will be frozen to one selected
++nexthop, so that load splitting will only occur on per-flow base.
++.B equalize
++only works if the kernel is patched.
++
++.SS ip route delete - delete route
++
++.B ip route del
++has the same arguments as
++.BR "ip route add" ,
++but their semantics are a bit different.
++
++Key values
++.RB "(" to ", " tos ", " preference " and " table ")"
++select the route to delete.  If optional attributes are present,
++.B ip
++verifies that they coincide with the attributes of the route to delete.
++If no route with the given key and attributes was found,
++.B ip route del
++fails.
++
++.SS ip route show - list routes
++the command displays the contents of the routing tables or the route(s)
++selected by some criteria.
++
++.TP
++.BI to " SELECTOR " (default)
++only select routes from the given range of destinations.
++.I SELECTOR
++consists of an optional modifier
++.RB "(" root ", " match " or " exact ")"
++and a prefix.
++.BI root " PREFIX"
++selects routes with prefixes not shorter than
++.IR PREFIX "."
++F.e.
++.BI root " 0/0"
++selects the entire routing table.
++.BI match " PREFIX"
++selects routes with prefixes not longer than
++.IR PREFIX "."
++F.e.
++.BI match " 10.0/16"
++selects
++.IR 10.0/16 ","
++.IR 10/8 " and " 0/0 ,
++but it does not select
++.IR 10.1/16 " and " 10.0.0/24 .
++And
++.BI exact " PREFIX"
++(or just
++.IR PREFIX ")"
++selects routes with this exact prefix. If neither of these options
++are present,
++.B ip
++assumes
++.BI root " 0/0"
++i.e. it lists the entire table.
++
++.TP
++.BI tos " TOS"
++.BI dsfield " TOS"
++only select routes with the given TOS.
++
++.TP
++.BI table " TABLEID"
++show the routes from this table(s).  The default setting is to show
++.BR table main "."
++.I TABLEID
++may either be the ID of a real table or one of the special values:
++.sp
++.in +8
++.B all
++- list all of the tables.
++.sp
++.B cache
++- dump the routing cache.
++.in -8
++
++.TP
++.B cloned
++.TP
++.B cached
++list cloned routes i.e. routes which were dynamically forked from
++other routes because some route attribute (f.e. MTU) was updated.
++Actually, it is equivalent to
++.BR "table cache" "."
++
++.TP
++.BI from " SELECTOR"
++the same syntax as for
++.BR to ","
++but it binds the source address range rather than destinations.
++Note that the
++.B from
++option only works with cloned routes.
++
++.TP
++.BI protocol " RTPROTO"
++only list routes of this protocol.
++
++.TP
++.BI scope " SCOPE_VAL"
++only list routes with this scope.
++
++.TP
++.BI type " TYPE"
++only list routes of this type.
++
++.TP
++.BI dev " NAME"
++only list routes going via this device.
++
++.TP
++.BI via " PREFIX"
++only list routes going via the nexthop routers selected by
++.IR PREFIX "."
++
++.TP
++.BI src " PREFIX"
++only list routes with preferred source addresses selected
++by
++.IR PREFIX "."
++
++.TP
++.BI realm " REALMID"
++.TP
++.BI realms " FROMREALM/TOREALM"
++only list routes with these realms.
++
++.SS ip route flush - flush routing tables
++this command flushes routes selected by some criteria.
++
++.sp
++The arguments have the same syntax and semantics as the arguments of
++.BR "ip route show" ,
++but routing tables are not listed but purged.  The only difference is
++the default action:
++.B show
++dumps all the IP main routing table but
++.B flush
++prints the helper page.
++
++.sp
++With the
++.B -statistics
++option, the command becomes verbose. It prints out the number of
++deleted routes and the number of rounds made to flush the routing
++table. If the option is given
++twice,
++.B ip route flush
++also dumps all the deleted routes in the format described in the
++previous subsection.
++
++.SS ip route get - get a single route
++this command gets a single route to a destination and prints its
++contents exactly as the kernel sees it.
++
++.TP
++.BI to " ADDRESS " (default)
++the destination address.
++
++.TP
++.BI from " ADDRESS"
++the source address.
++
++.TP
++.BI tos " TOS"
++.TP
++.BI dsfield " TOS"
++the Type Of Service.
++
++.TP
++.BI iif " NAME"
++the device from which this packet is expected to arrive.
++
++.TP
++.BI oif " NAME"
++force the output device on which this packet will be routed.
++
++.TP
++.B connected
++if no source address 
++.RB "(option " from ")"
++was given, relookup the route with the source set to the preferred
++address received from the first lookup.
++If policy routing is used, it may be a different route.
++
++.P
++Note that this operation is not equivalent to
++.BR "ip route show" .
++.B show
++shows existing routes.
++.B get
++resolves them and creates new clones if necessary.  Essentially,
++.B get
++is equivalent to sending a packet along this path.
++If the
++.B iif
++argument is not given, the kernel creates a route
++to output packets towards the requested destination.
++This is equivalent to pinging the destination
++with a subsequent
++.BR "ip route ls cache" ,
++however, no packets are actually sent.  With the
++.B iif
++argument, the kernel pretends that a packet arrived from this interface
++and searches for a path to forward the packet.
++
++.SH ip rule - routing policy database management
++
++.BR "Rule" s
++in the routing policy database control the route selection algorithm.
++
++.P
++Classic routing algorithms used in the Internet make routing decisions
++based only on the destination address of packets (and in theory,
++but not in practice, on the TOS field).
++
++.P
++In some circumstances we want to route packets differently depending not only
++on destination addresses, but also on other packet fields: source address,
++IP protocol, transport protocol ports or even packet payload.
++This task is called 'policy routing'.
++
++.P
++To solve this task, the conventional destination based routing table, ordered
++according to the longest match rule, is replaced with a 'routing policy
++database' (or RPDB), which selects routes by executing some set of rules.
++
++.P
++Each policy routing rule consists of a
++.B selector
++and an
++.B action predicate.
++The RPDB is scanned in the order of increasing priority. The selector
++of each rule is applied to {source address, destination address, incoming
++interface, tos, fwmark} and, if the selector matches the packet,
++the action is performed.  The action predicate may return with success.
++In this case, it will either give a route or failure indication
++and the RPDB lookup is terminated. Otherwise, the RPDB program
++continues on the next rule.
++
++.P
++Semantically, natural action is to select the nexthop and the output device.
++
++.P
++At startup time the kernel configures the default RPDB consisting of three
++rules:
++
++.TP
++1.
++Priority: 0, Selector: match anything, Action: lookup routing
++table
++.B local
++(ID 255).
++The
++.B local
++table is a special routing table containing
++high priority control routes for local and broadcast addresses.
++.sp
++Rule 0 is special. It cannot be deleted or overridden.
++
++.TP
++2.
++Priority: 32766, Selector: match anything, Action: lookup routing
++table
++.B main
++(ID 254).
++The
++.B main
++table is the normal routing table containing all non-policy
++routes. This rule may be deleted and/or overridden with other
++ones by the administrator.
++
++.TP
++3.
++Priority: 32767, Selector: match anything, Action: lookup routing
++table
++.B default
++(ID 253).
++The
++.B default
++table is empty.  It is reserved for some post-processing if no previous
++default rules selected the packet.
++This rule may also be deleted.
++
++.P
++Each RPDB entry has additional
++attributes.  F.e. each rule has a pointer to some routing
++table.  NAT and masquerading rules have an attribute to select new IP
++address to translate/masquerade.  Besides that, rules have some
++optional attributes, which routes have, namely
++.BR "realms" .
++These values do not override those contained in the routing tables.  They
++are only used if the route did not select any attributes.
++
++.sp
++The RPDB may contain rules of the following types:
++
++.in +8
++.B unicast
++- the rule prescribes to return the route found
++in the routing table referenced by the rule.
++
++.B blackhole
++- the rule prescribes to silently drop the packet.
++
++.B unreachable
++- the rule prescribes to generate a 'Network is unreachable' error.
++
++.B prohibit
++- the rule prescribes to generate 'Communication is administratively
++prohibited' error.
++
++.B nat
++- the rule prescribes to translate the source address
++of the IP packet into some other value.
++.in -8
++
++.SS ip rule add - insert a new rule
++.SS ip rule delete - delete a rule
++
++.TP
++.BI type " TYPE " (default)
++the type of this rule.  The list of valid types was given in the previous
++subsection.
++
++.TP
++.BI from " PREFIX"
++select the source prefix to match.
++
++.TP
++.BI to " PREFIX"
++select the destination prefix to match.
++
++.TP
++.BI iif " NAME"
++select the incoming device to match.  If the interface is loopback,
++the rule only matches packets originating from this host.  This means
++that you may create separate routing tables for forwarded and local
++packets and, hence, completely segregate them.
++
++.TP
++.BI tos " TOS"
++.TP
++.BI dsfield " TOS"
++select the TOS value to match.
++
++.TP
++.BI fwmark " MARK"
++select the
++.B fwmark
++value to match.
++
++.TP
++.BI priority " PREFERENCE"
++the priority of this rule.  Each rule should have an explicitly
++set
++.I unique
++priority value.
++
++.TP
++.BI table " TABLEID"
++the routing table identifier to lookup if the rule selector matches.
++
++.TP
++.BI realms " FROM/TO"
++Realms to select if the rule matched and the routing table lookup
++succeeded.  Realm 
++.I TO
++is only used if the route did not select any realm.
++
++.TP
++.BI nat " ADDRESS"
++The base of the IP address block to translate (for source addresses).
++The 
++.I ADDRESS
++may be either the start of the block of NAT addresses (selected by NAT
++routes) or a local host address (or even zero).
++In the last case the router does not translate the packets, but
++masquerades them to this address.
++
++.B Warning:
++Changes to the RPDB made with these commands do not become active
++immediately.  It is assumed that after a script finishes a batch of
++updates, it flushes the routing cache with
++.BR "ip route flush cache" .
++
++.SS ip rule show - list rules
++This command has no arguments.
++
++.SH ip maddress - multicast addresses management
++
++.B maddress
++objects are multicast addresses.
++
++.SS ip maddress show - list multicast addresses
++
++.TP
++.BI dev " NAME " (default)
++the device name.
++
++.SS ip maddress add - add a multicast address
++.SS ip maddress delete - delete a multicast address
++these commands attach/detach a static link layer multicast address
++to listen on the interface.
++Note that it is impossible to join protocol multicast groups
++statically.  This command only manages link layer addresses.
++
++.TP
++.BI address " LLADDRESS " (default)
++the link layer multicast address.
++
++.TP
++.BI dev " NAME"
++the device to join/leave this multicast address.
++
++.SH ip mroute - multicast routing cache management
++.B mroute
++objects are multicast routing cache entries created by a user level
++mrouting daemon (f.e.
++.B pimd
++or
++.B mrouted
++).
++
++Due to the limitations of the current interface to the multicast routing
++engine, it is impossible to change
++.B mroute
++objects administratively, so we may only display them.  This limitation
++will be removed in the future.
++
++.SS ip mroute show - list mroute cache entries
++
++.TP
++.BI to " PREFIX " (default)
++the prefix selecting the destination multicast addresses to list.
++
++.TP
++.BI iif " NAME"
++the interface on which multicast packets are received.
++
++.TP
++.BI from " PREFIX"
++the prefix selecting the IP source addresses of the multicast route.
++
++.SH ip tunnel - tunnel configuration
++.B tunnel
++objects are tunnels, encapsulating packets in IPv4 packets and then
++sending them over the IP infrastructure.
++
++.SS ip tunnel add - add a new tunnel
++.SS ip tunnel change - change an existing tunnel
++.SS ip tunnel delete - destroy a tunnel
++
++.TP
++.BI name " NAME " (default)
++select the tunnel device name.
++
++.TP
++.BI mode " MODE"
++set the tunnel mode.  Three modes are currently available:
++.BR ipip ", " sit " and " gre "."
++
++.TP
++.BI remote " ADDRESS"
++set the remote endpoint of the tunnel.
++
++.TP
++.BI local " ADDRESS"
++set the fixed local address for tunneled packets.
++It must be an address on another interface of this host.
++
++.TP
++.BI ttl " N"
++set a fixed TTL 
++.I N
++on tunneled packets.
++.I N
++is a number in the range 1--255. 0 is a special value
++meaning that packets inherit the TTL value. 
++The default value is:
++.BR "inherit" .
++
++.TP
++.BI tos " T"
++.TP
++.BI dsfield " T"
++set a fixed TOS
++.I T
++on tunneled packets.
++The default value is:
++.BR "inherit" .
++
++.TP
++.BI dev " NAME" 
++bind the tunnel to the device
++.I NAME
++so that tunneled packets will only be routed via this device and will
++not be able to escape to another device when the route to endpoint
++changes.
++
++.TP
++.B nopmtudisc
++disable Path MTU Discovery on this tunnel.
++It is enabled by default.  Note that a fixed ttl is incompatible
++with this option: tunnelling with a fixed ttl always makes pmtu
++discovery.
++
++.TP
++.BI key " K"
++.TP
++.BI ikey " K"
++.TP
++.BI okey " K"
++.RB ( " only GRE tunnels " )
++use keyed GRE with key
++.IR K ". " K
++is either a number or an IP address-like dotted quad.
++The
++.B key
++parameter sets the key to use in both directions.
++The
++.BR ikey " and " okey
++parameters set different keys for input and output.
++   
++.TP
++.BR csum ", " icsum ", " ocsum
++.RB ( " only GRE tunnels " )
++generate/require checksums for tunneled packets.
++The 
++.B ocsum
++flag calculates checksums for outgoing packets.
++The
++.B icsum
++flag requires that all input packets have the correct
++checksum.  The
++.B csum
++flag is equivalent to the combination
++.BR "icsum ocsum" .
++
++.TP
++.BR seq ", " iseq ", " oseq
++.RB ( " only GRE tunnels " )
++serialize packets.
++The
++.B oseq
++flag enables sequencing of outgoing packets.
++The
++.B iseq
++flag requires that all input packets are serialized.
++The
++.B  seq
++flag is equivalent to the combination 
++.BR "iseq oseq" .
++.B It isn't work. Don't use it.
++
++.SS ip tunnel show - list tunnels
++This command has no arguments.
++
++.SH ip monitor and rtmon - state monitoring
++
++The
++.B ip
++utility can monitor the state of devices, addresses
++and routes continuously.  This option has a slightly different format.
++Namely, the
++.B monitor
++command is the first in the command line and then the object list follows:
++
++.BR "ip monitor" " [ " all " |"
++.IR LISTofOBJECTS " ]"
++
++.I OBJECT-LIST
++is the list of object types that we want to monitor.
++It may contain
++.BR link ", " address " and " route "."
++If no
++.B file
++argument is given,
++.B ip
++opens RTNETLINK, listens on it and dumps state changes in the format
++described in previous sections.
++
++.P
++If a file name is given, it does not listen on RTNETLINK,
++but opens the file containing RTNETLINK messages saved in binary format
++and dumps them.  Such a history file can be generated with the
++.B rtmon
++utility.  This utility has a command line syntax similar to
++.BR "ip monitor" .
++Ideally,
++.B rtmon
++should be started before the first network configuration command
++is issued. F.e. if you insert:
++.sp
++.in +8
++rtmon file /var/log/rtmon.log
++.in -8
++.sp
++in a startup script, you will be able to view the full history
++later.
++
++.P
++Certainly, it is possible to start
++.B rtmon
++at any time.
++It prepends the history with the state snapshot dumped at the moment
++of starting.
++
++.SH HISTORY
++
++.B ip
++was written by Alexey N. Kuznetsov and added in Linux 2.2.
++.SH SEE ALSO
++.BR tc (8)
++.br
++.RB "IP Command reference " ip-cref.ps
++.br
++.RB "IP tunnels " ip-cref.ps
++
++.SH AUTHOR
++
++Manpage maintained by Michail Litvak <mci@owl.openwall.com>
+diff -Naur iproute2-orig/debian/manpages/old/tc-cbq-details.8 iproute2/debian/manpages/old/tc-cbq-details.8
+--- iproute2-orig/debian/manpages/old/tc-cbq-details.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-cbq-details.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,425 @@
++.TH CBQ 8 "8 December 2001" "iproute2" "Linux"
++.SH NAME
++CBQ \- Class Based Queueing
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] cbq avpkt
++bytes
++.B bandwidth
++rate
++.B [ cell 
++bytes
++.B ] [ ewma
++log
++.B ] [ mpu
++bytes
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] cbq allot
++bytes
++.B [ bandwidth 
++rate 
++.B ] [ rate 
++rate
++.B ] prio
++priority
++.B [ weight
++weight
++.B ] [ minburst 
++packets
++.B ] [ maxburst 
++packets 
++.B ] [ ewma 
++log
++.B ] [ cell
++bytes
++.B ] avpkt
++bytes
++.B [ mpu
++bytes 
++.B ] [ bounded isolated ] [ split
++handle
++.B & defmap
++defmap
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++Class Based Queueing is a classful qdisc that implements a rich
++linksharing hierarchy of classes.  It contains shaping elements as
++well as prioritizing capabilities.  Shaping is performed using link
++idle time calculations based on the timing of dequeue events and 
++underlying link bandwidth.
++
++.SH SHAPING ALGORITHM
++Shaping is done using link idle time calculations, and actions taken if
++these calculations deviate from set limits.
++
++When shaping a 10mbit/s connection to 1mbit/s, the link will
++be idle 90% of the time. If it isn't, it needs to be throttled so that it
++IS idle 90% of the time.
++
++From the kernel's perspective, this is hard to measure, so CBQ instead 
++derives the idle time from the number of microseconds (in fact, jiffies) 
++that elapse between  requests from the device driver for more data. Combined 
++with the  knowledge of packet sizes, this is used to approximate how full or 
++empty the link is.
++
++This is rather circumspect and doesn't always arrive at proper
++results. For example, what is the actual link speed of an interface
++that is not really able to transmit the full 100mbit/s of data,
++perhaps because of a badly implemented driver? A PCMCIA network card
++will also never achieve 100mbit/s because of the way the bus is
++designed - again, how do we calculate the idle time?
++
++The physical link bandwidth may be ill defined in case of not-quite-real 
++network devices like PPP over Ethernet or PPTP over TCP/IP. The effective 
++bandwidth in that case is probably determined by the efficiency of pipes 
++to userspace - which not defined.
++
++During operations, the effective idletime is measured using an
++exponential weighted moving average (EWMA), which considers recent
++packets to be exponentially more important than past ones. The Unix
++loadaverage is calculated in the same way.
++
++The calculated idle time is subtracted from the EWMA measured one,
++the resulting number is called 'avgidle'. A perfectly loaded link has
++an avgidle of zero: packets arrive exactly at the calculated
++interval.
++
++An overloaded link has a negative avgidle and if it gets too negative,
++CBQ throttles and is then 'overlimit'.
++
++Conversely, an idle link might amass a huge avgidle, which would then
++allow infinite bandwidths after a few hours of silence. To prevent
++this, avgidle is capped at 
++.B maxidle.
++
++If overlimit, in theory, the CBQ could throttle itself for exactly the
++amount of time that was calculated to pass between packets, and then
++pass one packet, and throttle again. Due to timer resolution constraints,
++this may not be feasible, see the 
++.B minburst
++parameter below.
++
++.SH CLASSIFICATION
++Within the one CBQ instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, CBQ starts at the root and uses various methods to 
++determine which class should receive the data. If a verdict is reached, this
++process is repeated for the recipient class which might have further
++means of classifying traffic to its children, if any.
++
++CBQ has the following methods available to classify a packet to any child 
++classes.
++.TP
++(i)
++.B skb->priority class encoding.
++Can be set from userspace by an application with the 
++.B SO_PRIORITY
++setsockopt.
++The 
++.B skb->priority class encoding
++only applies if the skb->priority holds a major:minor handle of an existing 
++class within  this qdisc.
++.TP
++(ii)
++tc filters attached to the class.
++.TP
++(iii)
++The defmap of a class, as set with the 
++.B split & defmap
++parameters. The defmap may contain instructions for each possible Linux packet
++priority.
++
++.P
++Each class also has a 
++.B level.
++Leaf nodes, attached to the bottom of the class hierarchy, have a level of 0.
++.SH CLASSIFICATION ALGORITHM
++
++Classification is a loop, which terminates when a leaf class is found. At any 
++point the loop may jump to the fallback algorithm.
++
++The loop consists of the following steps:
++.TP 
++(i)
++If the packet is generated locally and has a valid classid encoded within its
++.B skb->priority,
++choose it and terminate.
++
++.TP
++(ii)
++Consult the tc filters, if any, attached to this child. If these return
++a class which is not a leaf class, restart loop from the class returned.
++If it is a leaf, choose it and terminate.
++.TP
++(iii)
++If the tc filters did not return a class, but did return a classid, 
++try to find a class with that id within this qdisc. 
++Check if the found class is of a lower
++.B level
++than the current class. If so, and the returned class is not a leaf node,
++restart the loop at the found class. If it is a leaf node, terminate.
++If we found an upward reference to a higher level, enter the fallback 
++algorithm.
++.TP
++(iv)
++If the tc filters did not return a class, nor a valid reference to one,
++consider the minor number of the reference to be the priority. Retrieve
++a class from the defmap of this class for the priority. If this did not
++contain a class, consult the defmap of this class for the 
++.B BEST_EFFORT
++class. If this is an upward reference, or no 
++.B BEST_EFFORT 
++class was defined,
++enter the fallback algorithm. If a valid class was found, and it is not a
++leaf node, restart the loop at this class. If it is a leaf, choose it and 
++terminate. If
++neither the priority distilled from the classid, nor the 
++.B BEST_EFFORT 
++priority yielded a class, enter the fallback algorithm.
++.P
++The fallback algorithm resides outside of the loop and is as follows.
++.TP
++(i)
++Consult the defmap of the class at which the jump to fallback occured. If 
++the defmap contains a class for the 
++.B
++priority
++of the class (which is related to the TOS field), choose this class and 
++terminate. 
++.TP
++(ii)
++Consult the map for a class for the
++.B BEST_EFFORT
++priority. If found, choose it, and terminate.
++.TP
++(iii)
++Choose the class at which break out to the fallback algorithm occured. Terminate.
++.P
++The packet is enqueued to the class which was chosen when either algorithm 
++terminated. It is therefore possible for a packet to be enqueued *not* at a
++leaf node, but in the middle of the hierarchy.
++
++.SH LINK SHARING ALGORITHM
++When dequeuing for sending to the network device, CBQ decides which of its 
++classes will be allowed to send. It does so with a Weighted Round Robin process
++in which each class with packets gets a chance to send in turn. The WRR process
++starts by asking the highest priority classes (lowest numerically - 
++highest semantically) for packets, and will continue to do so until they
++have no more data to offer, in which case the process repeats for lower 
++priorities.
++
++.B CERTAINTY ENDS HERE, ANK PLEASE HELP
++
++Each class is not allowed to send at length though - they can only dequeue a
++configurable amount of data during each round. 
++
++If a class is about to go overlimit, and it is not
++.B bounded
++it will try to borrow avgidle from siblings that are not
++.B isolated. 
++This process is repeated from the bottom upwards. If a class is unable
++to borrow enough avgidle to send a packet, it is throttled and not asked
++for a packet for enough time for the avgidle to increase above zero.
++
++.B I REALLY NEED HELP FIGURING THIS OUT. REST OF DOCUMENT IS PRETTY CERTAIN
++.B AGAIN.
++
++.SH QDISC
++The root qdisc of a CBQ class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the CBQ instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional.
++.TP
++avpkt bytes
++For calculations, the average packet size must be known. It is silently capped
++at a minimum of 2/3 of the interface MTU. Mandatory.
++.TP
++bandwidth rate
++To determine the idle time, CBQ must know the bandwidth of your underlying 
++physical interface, or parent qdisc. This is a vital parameter, more about it
++later. Mandatory.
++.TP
++cell
++The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
++.TP 
++mpu
++A zero sized packet may still take time to transmit. This value is the lower
++cap for packet transmission time calculations - packets smaller than this value
++are still deemed to have this size. Defaults to zero.
++.TP
++ewma log
++When CBQ needs to measure the average idle time, it does so using an 
++Exponentially Weighted Moving Average which smoothes out measurements into
++a moving average. The EWMA LOG determines how much smoothing occurs. Defaults 
++to 5. Lower values imply greater sensitivity. Must be between 0 and 31.
++.P
++A CBQ qdisc does not shape out of its own accord. It only needs to know certain
++parameters about the underlying link. Actual shaping is done in classes.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++weight weight
++When dequeuing to the interface, classes are tried for traffic in a 
++round-robin fashion. Classes with a higher configured qdisc will generally
++have more traffic to offer during each round, so it makes sense to allow
++it to dequeue more traffic. All weights under a class are normalized, so
++only the ratios matter. Defaults to the configured rate, unless the priority 
++of this class is maximal, in which case it is set to 1.
++.TP 
++allot bytes
++Allot specifies how many bytes a qdisc can dequeue
++during each round of the process. This parameter is weighted using the 
++renormalized class weight described above.
++
++.TP 
++priority priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++rate rate
++Maximum rate this class and all its children combined can send at. Mandatory.
++
++.TP
++bandwidth rate
++This is different from the bandwidth specified when creating a CBQ disc. Only
++used to determine maxidle and offtime, which are only calculated when
++specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
++
++.TP 
++maxburst
++This number of packets is used to calculate maxidle so that when
++avgidle is at maxidle, this number of average packets can be burst
++before avgidle drops to 0. Set it higher to be more tolerant of
++bursts. You can't set maxidle directly, only via this parameter.
++
++.TP
++minburst 
++As mentioned before, CBQ needs to throttle in case of
++overlimit. The ideal solution is to do so for exactly the calculated
++idle time, and pass 1 packet. However, Unix kernels generally have a
++hard time scheduling events shorter than 10ms, so it is better to
++throttle for a longer period, and then pass minburst packets in one
++go, and then sleep minburst times longer.
++
++The time to wait is called the offtime. Higher values of minburst lead
++to more accurate shaping in the long term, but to bigger bursts at
++millisecond timescales.
++
++.TP
++minidle
++If avgidle is below 0, we are overlimits and need to wait until
++avgidle will be big enough to send one packet. To prevent a sudden
++burst from shutting down the link for a prolonged period of time,
++avgidle is reset to minidle if it gets too low.
++
++Minidle is specified in negative microseconds, so 10 means that
++avgidle is capped at -10us.
++
++.TP
++bounded 
++Signifies that this class will not borrow bandwidth from its siblings.
++.TP 
++isolated
++Means that this class will not borrow bandwidth to its siblings
++
++.TP 
++split major:minor & defmap bitmap[/bitmap]
++If consulting filters attached to a class did not give a verdict, 
++CBQ can also classify based on the packet's priority. There are 16
++priorities available, numbered from 0 to 15. 
++
++The defmap specifies which priorities this class wants to receive, 
++specified as a bitmap. The Least Significant Bit corresponds to priority 
++zero. The 
++.B split
++parameter tells CBQ at which class the decision must be made, which should
++be a (grand)parent of the class you are adding.
++
++As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
++configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
++
++The complimentary configuration would then 
++be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
++Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
++.TP
++estimator interval timeconstant
++CBQ can measure how much bandwidth each class is using, which tc filters
++can use to classify packets with. In order to determine the bandwidth
++it uses a very simple estimator that measures once every
++.B interval
++microseconds how much traffic has passed. This again is a EWMA, for which
++the time constant can be specified, also in microseconds. The 
++.B time constant
++corresponds to the sluggishness of the measurement or, conversely, to the 
++sensitivity of the average to short bursts. Higher values mean less
++sensitivity. 
++
++
++
++.SH SOURCES
++.TP
++o
++Sally Floyd and Van Jacobson, "Link-sharing and Resource
++Management Models for Packet Networks",
++IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
++
++.TP 
++o
++Sally Floyd, "Notes on CBQ and Guarantee Service", 1995
++
++.TP
++o
++Sally Floyd, "Notes on Class-Based Queueing: Setting
++Parameters", 1996
++
++.TP 
++o
++Sally Floyd and Michael Speer, "Experimental Results
++for Class-Based Queueing", 1998, not published.
++
++
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-cbq.8 iproute2/debian/manpages/old/tc-cbq.8
+--- iproute2-orig/debian/manpages/old/tc-cbq.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-cbq.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,353 @@
++.TH CBQ 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++CBQ \- Class Based Queueing
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] cbq [ allot 
++bytes
++.B ] avpkt
++bytes
++.B bandwidth
++rate
++.B [ cell 
++bytes
++.B ] [ ewma
++log
++.B ] [ mpu
++bytes
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] cbq allot
++bytes
++.B [ bandwidth 
++rate 
++.B ] [ rate 
++rate
++.B ] prio
++priority
++.B [ weight
++weight
++.B ] [ minburst 
++packets
++.B ] [ maxburst 
++packets 
++.B ] [ ewma 
++log
++.B ] [ cell
++bytes
++.B ] avpkt
++bytes
++.B [ mpu
++bytes 
++.B ] [ bounded isolated ] [ split
++handle
++.B & defmap
++defmap
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++Class Based Queueing is a classful qdisc that implements a rich
++linksharing hierarchy of classes.  It contains shaping elements as
++well as prioritizing capabilities.  Shaping is performed using link
++idle time calculations based on the timing of dequeue events and 
++underlying link bandwidth.
++
++.SH SHAPING ALGORITHM
++When shaping a 10mbit/s connection to 1mbit/s, the link will
++be idle 90% of the time. If it isn't, it needs to be throttled so that it
++IS idle 90% of the time.
++
++During operations, the effective idletime is measured using an
++exponential weighted moving average (EWMA), which considers recent
++packets to be exponentially more important than past ones. The Unix
++loadaverage is calculated in the same way.
++
++The calculated idle time is subtracted from the EWMA measured one,
++the resulting number is called 'avgidle'. A perfectly loaded link has
++an avgidle of zero: packets arrive exactly at the calculated
++interval.
++
++An overloaded link has a negative avgidle and if it gets too negative,
++CBQ throttles and is then 'overlimit'.
++
++Conversely, an idle link might amass a huge avgidle, which would then
++allow infinite bandwidths after a few hours of silence. To prevent
++this, avgidle is capped at 
++.B maxidle.
++
++If overlimit, in theory, the CBQ could throttle itself for exactly the
++amount of time that was calculated to pass between packets, and then
++pass one packet, and throttle again. Due to timer resolution constraints,
++this may not be feasible, see the 
++.B minburst
++parameter below.
++
++.SH CLASSIFICATION
++Within the one CBQ instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, CBQ starts at the root and uses various methods to 
++determine which class should receive the data. 
++
++In the absence of uncommon configuration options, the process is rather easy. 
++At each node we look for an instruction, and then go to the class the 
++instruction refers us to. If the class found is a barren leaf-node (without 
++children), we enqueue the packet there. If it is not yet a leaf node, we do 
++the whole thing over again starting from that node. 
++
++The following actions are performed, in order at each node we visit, until one 
++sends us to another node, or terminates the process.
++.TP
++(i)
++Consult filters attached to the class. If sent to a leafnode, we are done. 
++Otherwise, restart.
++.TP
++(ii)
++Consult the defmap for the priority assigned to this packet, which depends 
++on the TOS bits. Check if the referral is leafless, otherwise restart.
++.TP
++(iii)
++Ask the defmap for instructions for the 'best effort' priority. Check the 
++answer for leafness, otherwise restart.
++.TP
++(iv)
++If none of the above returned with an instruction, enqueue at this node.
++.P
++This algorithm makes sure that a packet always ends up somewhere, even while
++you are busy building your configuration. 
++
++For more details, see
++.BR tc-cbq-details(8).
++
++.SH LINK SHARING ALGORITHM
++When dequeuing for sending to the network device, CBQ decides which of its 
++classes will be allowed to send. It does so with a Weighted Round Robin process
++in which each class with packets gets a chance to send in turn. The WRR process
++starts by asking the highest priority classes (lowest numerically - 
++highest semantically) for packets, and will continue to do so until they
++have no more data to offer, in which case the process repeats for lower 
++priorities.
++
++Classes by default borrow bandwidth from their siblings. A class can be 
++prevented from doing so by declaring it 'bounded'. A class can also indicate 
++its unwillingness to lend out bandwidth by being 'isolated'.
++
++.SH QDISC
++The root of a CBQ qdisc class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the CBQ instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional, but very useful if classes
++will be generated within this qdisc.
++.TP 
++allot bytes
++This allotment is the 'chunkiness' of link sharing and is used for determining packet
++transmission time tables. The qdisc allot differs slightly from the class allot discussed
++below. Optional. Defaults to a reasonable value, related to avpkt.
++.TP
++avpkt bytes
++The average size of a packet is needed for calculating maxidle, and is also used
++for making sure 'allot' has a safe value. Mandatory.
++.TP
++bandwidth rate
++To determine the idle time, CBQ must know the bandwidth of your underlying 
++physical interface, or parent qdisc. This is a vital parameter, more about it
++later. Mandatory.
++.TP
++cell
++The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
++.TP 
++mpu
++A zero sized packet may still take time to transmit. This value is the lower
++cap for packet transmission time calculations - packets smaller than this value
++are still deemed to have this size. Defaults to zero.
++.TP
++ewma log
++When CBQ needs to measure the average idle time, it does so using an 
++Exponentially Weighted Moving Average which smoothes out measurements into
++a moving average. The EWMA LOG determines how much smoothing occurs. Lower 
++values imply greater sensitivity. Must be between 0 and 31. Defaults 
++to 5.
++.P
++A CBQ qdisc does not shape out of its own accord. It only needs to know certain
++parameters about the underlying link. Actual shaping is done in classes.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++weight weight
++When dequeuing to the interface, classes are tried for traffic in a 
++round-robin fashion. Classes with a higher configured qdisc will generally
++have more traffic to offer during each round, so it makes sense to allow
++it to dequeue more traffic. All weights under a class are normalized, so
++only the ratios matter. Defaults to the configured rate, unless the priority 
++of this class is maximal, in which case it is set to 1.
++.TP 
++allot bytes
++Allot specifies how many bytes a qdisc can dequeue
++during each round of the process. This parameter is weighted using the 
++renormalized class weight described above. Silently capped at a minimum of
++3/2 avpkt. Mandatory.
++
++.TP 
++prio priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++avpkt
++See the QDISC section.
++
++.TP 
++rate rate
++Maximum rate this class and all its children combined can send at. Mandatory.
++
++.TP
++bandwidth rate
++This is different from the bandwidth specified when creating a CBQ disc! Only
++used to determine maxidle and offtime, which are only calculated when
++specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
++
++.TP 
++maxburst
++This number of packets is used to calculate maxidle so that when
++avgidle is at maxidle, this number of average packets can be burst
++before avgidle drops to 0. Set it higher to be more tolerant of
++bursts. You can't set maxidle directly, only via this parameter.
++
++.TP
++minburst 
++As mentioned before, CBQ needs to throttle in case of
++overlimit. The ideal solution is to do so for exactly the calculated
++idle time, and pass 1 packet. However, Unix kernels generally have a
++hard time scheduling events shorter than 10ms, so it is better to
++throttle for a longer period, and then pass minburst packets in one
++go, and then sleep minburst times longer.
++
++The time to wait is called the offtime. Higher values of minburst lead
++to more accurate shaping in the long term, but to bigger bursts at
++millisecond timescales. Optional.
++
++.TP
++minidle
++If avgidle is below 0, we are overlimits and need to wait until
++avgidle will be big enough to send one packet. To prevent a sudden
++burst from shutting down the link for a prolonged period of time,
++avgidle is reset to minidle if it gets too low.
++
++Minidle is specified in negative microseconds, so 10 means that
++avgidle is capped at -10us. Optional.
++
++.TP
++bounded 
++Signifies that this class will not borrow bandwidth from its siblings.
++.TP 
++isolated
++Means that this class will not borrow bandwidth to its siblings
++
++.TP 
++split major:minor & defmap bitmap[/bitmap]
++If consulting filters attached to a class did not give a verdict, 
++CBQ can also classify based on the packet's priority. There are 16
++priorities available, numbered from 0 to 15. 
++
++The defmap specifies which priorities this class wants to receive, 
++specified as a bitmap. The Least Significant Bit corresponds to priority 
++zero. The 
++.B split
++parameter tells CBQ at which class the decision must be made, which should
++be a (grand)parent of the class you are adding.
++
++As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
++configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
++
++The complimentary configuration would then 
++be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
++Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
++.TP
++estimator interval timeconstant
++CBQ can measure how much bandwidth each class is using, which tc filters
++can use to classify packets with. In order to determine the bandwidth
++it uses a very simple estimator that measures once every
++.B interval
++microseconds how much traffic has passed. This again is a EWMA, for which
++the time constant can be specified, also in microseconds. The 
++.B time constant
++corresponds to the sluggishness of the measurement or, conversely, to the 
++sensitivity of the average to short bursts. Higher values mean less
++sensitivity. 
++
++.SH BUGS
++The actual bandwidth of the underlying link may not be known, for example 
++in the case of PPoE or PPTP connections which in fact may send over a 
++pipe, instead of over a physical device. CBQ is quite resilient to major
++errors in the configured bandwidth, probably a the cost of coarser shaping.
++
++Default kernels rely on coarse timing information for making decisions. These 
++may make shaping precise in the long term, but inaccurate on second long scales.
++
++See 
++.BR tc-cbq-details(8)
++for hints on how to improve this.
++
++.SH SOURCES
++.TP
++o
++Sally Floyd and Van Jacobson, "Link-sharing and Resource
++Management Models for Packet Networks",
++IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
++
++.TP 
++o
++Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
++
++.TP
++o
++Sally Floyd, "Notes on Class-Based Queueing: Setting
++Parameters", 1996
++
++.TP 
++o
++Sally Floyd and Michael Speer, "Experimental Results
++for Class-Based Queueing", 1998, not published.
++
++
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-htb.8 iproute2/debian/manpages/old/tc-htb.8
+--- iproute2-orig/debian/manpages/old/tc-htb.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-htb.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,150 @@
++.TH HTB 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++HTB \- Hierarchy Token Bucket
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] htb [ default 
++minor-id
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] htb rate
++rate
++.B [ ceil
++rate 
++.B ] burst 
++bytes
++.B [ cburst
++bytes
++.B ] [ prio
++priority
++.B ] 
++
++.SH DESCRIPTION
++HTB is meant as a more understandable and intuitive replacement for
++the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
++of the outbound bandwidth on a given link. Both allow you to use one
++physical link to simulate several slower links and to send different
++kinds of traffic on different simulated links. In both cases, you have
++to specify how to divide the physical link into simulated links and
++how to decide which simulated link to use for a given packet to be sent. 
++
++Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm 
++which does not depend on interface characteristics and so does not need to
++know the underlying bandwidth of the outgoing interface.
++
++.SH SHAPING ALGORITHM
++Shaping works as documented in
++.B tc-tbf (8).
++
++.SH CLASSIFICATION
++Within the one HRB instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, HTB starts at the root and uses various methods to 
++determine which class should receive the data. 
++
++In the absence of uncommon configuration options, the process is rather easy. 
++At each node we look for an instruction, and then go to the class the 
++instruction refers us to. If the class found is a barren leaf-node (without 
++children), we enqueue the packet there. If it is not yet a leaf node, we do 
++the whole thing over again starting from that node. 
++
++The following actions are performed, in order at each node we visit, until one 
++sends us to another node, or terminates the process.
++.TP
++(i)
++Consult filters attached to the class. If sent to a leafnode, we are done. 
++Otherwise, restart.
++.TP
++(ii)
++If none of the above returned with an instruction, enqueue at this node.
++.P
++This algorithm makes sure that a packet always ends up somewhere, even while
++you are busy building your configuration. 
++
++.SH LINK SHARING ALGORITHM
++FIXME
++
++.SH QDISC
++The root of a HTB qdisc class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the HTB instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the HTB can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional, but very useful if classes
++will be generated within this qdisc.
++.TP 
++default minor-id
++Unclassified traffic gets sent to the class with this minor-id.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++prio priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++rate rate
++Maximum rate this class and all its children are guaranteed. Mandatory.
++
++.TP
++ceil rate
++Maximum rate at which a class can send, if its parent has bandwidth to spare. 
++Defaults to the configured rate, which implies no borrowing
++
++.TP 
++burst bytes
++Amount of bytes that can be burst at 
++.B ceil
++speed, in excess of the configured
++.B rate. 
++Should be at least as high as the highest burst of all children.
++
++.TP 
++cburst bytes
++Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
++as the interface can transmit them. For perfect evening out, should be equal to at most one average
++packet. Should be at least as high as the highest cburst of all children.
++
++.SH NOTES
++Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel, 
++there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
++From this, the mininum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte 
++burst as 100*12kb*8 equals 10mbit.
++
++.SH SEE ALSO
++.BR tc (8)
++.P
++HTB website: http://luxik.cdi.cz/~devik/qos/htb/
++.SH AUTHOR
++Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-pbfifo.8 iproute2/debian/manpages/old/tc-pbfifo.8
+--- iproute2-orig/debian/manpages/old/tc-pbfifo.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-pbfifo.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,72 @@
++.TH PBFIFO 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++pfifo \- Packet limited First In, First Out queue
++.P
++bfifo \- Byte limited First In, First Out queue
++
++.SH SYNOPSIS
++.B tc qdisc ... add pfifo
++.B [ limit 
++packets
++.B ]
++.P
++.B tc qdisc ... add bfifo
++.B [ limit 
++bytes
++.B ]
++
++.SH DESCRIPTION
++The pfifo and bfifo qdiscs are unadorned First In, First Out queues. They are the
++simplest queues possible and therefore have no overhead. 
++.B pfifo
++constrains the queue size as measured in packets. 
++.B bfifo
++does so as measured in bytes.
++
++Like all non-default qdiscs, they maintain statistics. This might be a reason to prefer 
++pfifo or bfifo over the default.
++
++.SH ALGORITHM
++A list of packets is maintained, when a packet is enqueued it gets inserted at the tail of
++a list. When a packet needs to be sent out to the network, it is taken from the head of the list. 
++
++If the list is too long, no further packets are allowed on. This is called 'tail drop'.
++
++.SH PARAMETERS
++.TP 
++limit
++Maximum queue size. Specified in bytes for bfifo, in packets for pfifo. For pfifo, defaults 
++to the interface txqueuelen, as specified with 
++.BR ifconfig (8)
++or
++.BR ip (8).
++
++For bfifo, it defaults to the txqueuelen multiplied by the interface MTU.
++
++.SH OUTPUT
++The output of 
++.B tc -s qdisc ls
++contains the limit, either in packets or in bytes, and the number of bytes 
++and packets actually sent. An unsent and dropped packet only appears between braces 
++and is not counted as 'Sent'.
++
++In this example, the queue length is 100 packets, 45894 bytes were sent over 681 packets. 
++No packets were dropped, and as the pfifo queue does not slow down packets, there were also no
++overlimits:
++.P
++.nf
++# tc -s qdisc ls dev eth0 
++qdisc pfifo 8001: dev eth0 limit 100p
++ Sent 45894 bytes 681 pkts (dropped 0, overlimits 0) 
++.fi
++
++If a backlog occurs, this is displayed as well.
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
++
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-pfifo_fast.8 iproute2/debian/manpages/old/tc-pfifo_fast.8
+--- iproute2-orig/debian/manpages/old/tc-pfifo_fast.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-pfifo_fast.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,59 @@
++.TH PFIFO_FAST 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++pfifo_fast \- three-band first in, first out queue
++
++.SH DESCRIPTION
++pfifo_fast is the default qdisc of each interface.
++
++Whenever an interface is created, the pfifo_fast qdisc is automatically used
++as a queue. If another qdisc is attached, it preempts the default
++pfifo_fast, which automatically returns to function when an existing qdisc
++is detached.
++
++In this sense this qdisc is magic, and unlike other qdiscs.
++
++.SH ALGORITHM
++The algorithm is very similar to that of the classful 
++.BR tc-prio (8)
++qdisc. 
++.B pfifo_fast
++is like three
++.BR tc-pfifo (8)
++queues side by side, where packets can be enqueued in any of the three bands
++based on their Type of Service bits or assigned priority. 
++
++Not all three bands are dequeued simultaneously - as long as lower bands
++have traffic, higher bands are never dequeued. This can be used to
++prioritize interactive traffic or penalize 'lowest cost' traffic.
++
++Each band can be txqueuelen packets long, as configured with
++.BR ifconfig (8)
++or 
++.BR ip (8).
++Additional packets coming in are not enqueued but are instead dropped.
++
++See
++.BR tc-prio (8)
++for complete details on how TOS bits are translated into bands.
++.SH PARAMETERS
++.TP 
++txqueuelen
++The length of the three bands depends on the interface txqueuelen, as
++specified with
++.BR ifconfig (8)
++or
++.BR ip (8).
++
++.SH BUGS
++Does not maintain statistics and does not show up in tc qdisc ls. This is because
++it is the automatic default in the absence of a configured qdisc. 
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
++
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-prio.8 iproute2/debian/manpages/old/tc-prio.8
+--- iproute2-orig/debian/manpages/old/tc-prio.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-prio.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,187 @@
++.TH PRIO 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++PRIO \- Priority qdisc
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] prio [ bands 
++bands
++.B ] [ priomap
++band,band,band... 
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++The PRIO qdisc is a simple classful queueing discipline that contains
++an arbitrary number of classes of differing priority. The classes are
++dequeued in numerical descending order of priority. PRIO is a scheduler 
++and never delays packets - it is a work-conserving qdisc, though the qdiscs
++contained in the classes may not be.
++
++Very useful for lowering latency when there is no need for slowing down
++traffic.
++
++.SH ALGORITHM
++On creation with 'tc qdisc add', a fixed number of bands is created. Each
++band is a class, although is not possible to add classes with 'tc qdisc
++add', the number of bands to be created must instead be specified on the
++commandline attaching PRIO to its root.
++
++When dequeueing, band 0 is tried first and only if it did not deliver a
++packet does PRIO try band 1, and so onwards. Maximum reliability packets
++should therefore go to band 0, minimum delay to band 1 and the rest to band
++2.
++
++As the PRIO qdisc itself will have minor number 0, band 0 is actually
++major:1, band 1 is major:2, etc. For major, substitute the major number
++assigned to the qdisc on 'tc qdisc add' with the
++.B handle
++parameter.
++
++.SH CLASSIFICATION
++Three methods are available to PRIO to determine in which band a packet will
++be enqueued.
++.TP
++From userspace
++A process with sufficient privileges can encode the destination class
++directly with SO_PRIORITY, see
++.BR tc(7).
++.TP 
++with a tc filter
++A tc filter attached to the root qdisc can point traffic directly to a class
++.TP 
++with the priomap
++Based on the packet priority, which in turn is derived from the Type of
++Service assigned to the packet.
++.P
++Only the priomap is specific to this qdisc. 
++.SH QDISC PARAMETERS
++.TP
++bands
++Number of bands. If changed from the default of 3,
++.B priomap
++must be updated as well.
++.TP 
++priomap
++The priomap maps the priority of
++a packet to a class. The priority can either be set directly from userspace,
++or be derived from the Type of Service of the packet.
++
++Determines how packet priorities, as assigned by the kernel, map to
++bands. Mapping occurs based on the TOS octet of the packet, which looks like
++this:
++
++.nf
++0   1   2   3   4   5   6   7
+++---+---+---+---+---+---+---+---+
++|           |               |   |
++|PRECEDENCE |      TOS      |MBZ|
++|           |               |   |
+++---+---+---+---+---+---+---+---+
++.fi
++
++The four TOS bits (the 'TOS field') are defined as:
++
++.nf
++Binary Decimcal  Meaning
++-----------------------------------------
++1000   8         Minimize delay (md)
++0100   4         Maximize throughput (mt)
++0010   2         Maximize reliability (mr)
++0001   1         Minimize monetary cost (mmc)
++0000   0         Normal Service
++.fi
++
++As there is 1 bit to the right of these four bits, the actual value of the
++TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the
++value of the entire TOS field, not just the four bits. It is the value you
++see in the first column of this table:
++
++.nf
++TOS     Bits  Means                    Linux Priority    Band
++------------------------------------------------------------
++0x0     0     Normal Service           0 Best Effort     1
++0x2     1     Minimize Monetary Cost   1 Filler          2
++0x4     2     Maximize Reliability     0 Best Effort     1
++0x6     3     mmc+mr                   0 Best Effort     1
++0x8     4     Maximize Throughput      2 Bulk            2
++0xa     5     mmc+mt                   2 Bulk            2
++0xc     6     mr+mt                    2 Bulk            2
++0xe     7     mmc+mr+mt                2 Bulk            2
++0x10    8     Minimize Delay           6 Interactive     0
++0x12    9     mmc+md                   6 Interactive     0
++0x14    10    mr+md                    6 Interactive     0
++0x16    11    mmc+mr+md                6 Interactive     0
++0x18    12    mt+md                    4 Int. Bulk       1
++0x1a    13    mmc+mt+md                4 Int. Bulk       1
++0x1c    14    mr+mt+md                 4 Int. Bulk       1
++0x1e    15    mmc+mr+mt+md             4 Int. Bulk       1
++.fi
++
++The second column contains the value of the relevant
++four TOS bits, followed by their translated meaning. For example, 15 stands
++for a packet wanting Minimal Montetary Cost, Maximum Reliability, Maximum
++Throughput AND Minimum Delay. 
++
++The fourth column lists the way the Linux kernel interprets the TOS bits, by
++showing to which Priority they are mapped.
++
++The last column shows the result of the default priomap. On the commandline,
++the default priomap looks like this:
++
++    1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
++
++This means that priority 4, for example, gets mapped to band number 1.
++The priomap also allows you to list higher priorities (> 7) which do not
++correspond to TOS mappings, but which are set by other means.
++
++This table from RFC 1349 (read it for more details) explains how
++applications might very well set their TOS bits:
++
++.nf
++TELNET                   1000           (minimize delay)
++FTP
++        Control          1000           (minimize delay)
++        Data             0100           (maximize throughput)
++
++TFTP                     1000           (minimize delay)
++
++SMTP 
++        Command phase    1000           (minimize delay)
++        DATA phase       0100           (maximize throughput)
++
++Domain Name Service
++        UDP Query        1000           (minimize delay)
++        TCP Query        0000
++        Zone Transfer    0100           (maximize throughput)
++
++NNTP                     0001           (minimize monetary cost)
++
++ICMP
++        Errors           0000
++        Requests         0000 (mostly)
++        Responses        <same as request> (mostly)
++.fi
++
++
++.SH CLASSES
++PRIO classes cannot be configured further - they are automatically created
++when the PRIO qdisc is attached. Each class however can contain yet a
++further qdisc.
++
++.SH BUGS
++Large amounts of traffic in the lower bands can cause starvation of higher
++bands. Can be prevented by attaching a shaper (for example, 
++.BR tc-tbf(8)
++to these bands to make sure they cannot dominate the link.
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>,  J Hadi Salim
++<hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-red.8 iproute2/debian/manpages/old/tc-red.8
+--- iproute2-orig/debian/manpages/old/tc-red.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-red.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,131 @@
++.TH RED 8 "13 December 2001" "iproute2" "Linux"
++.SH NAME
++red \- Random Early Detection 
++.SH SYNOPSIS
++.B tc qdisc ... red
++.B limit 
++bytes
++.B min 
++bytes 
++.B max 
++bytes 
++.B avpkt
++bytes
++.B burst 
++packets
++.B [ ecn ] [ bandwidth
++rate
++.B ] probability
++chance
++
++.SH DESCRIPTION
++Random Early Detection is a classless qdisc which manages its queue size
++smartly. Regular queues simply drop packets from the tail when they are
++full, which may not be the optimal behaviour. RED also performs tail drop,
++but does so in a more gradual way.
++
++Once the queue hits a certain average length, packets enqueued have a
++configurable chance of being marked (which may mean dropped). This chance
++increases linearly up to a point called the
++.B max
++average queue length, although the queue might get bigger.
++
++This has a host of benefits over simple taildrop, while not being processor
++intensive. It prevents synchronous retransmits after a burst in traffic,
++which cause further retransmits, etc.
++
++The goal is the have a small queue size, which is good for interactivity
++while not disturbing TCP/IP traffic with too many sudden drops after a burst
++of traffic.
++
++Depending on if ECN is configured, marking either means dropping or
++purely marking a packet as overlimit.
++.SH ALGORITHM
++The average queue size is used for determining the marking
++probability. This is calculated using an Exponential Weighted Moving
++Average, which can be more or less sensitive to bursts.
++
++When the average queue size is below 
++.B min
++bytes, no packet will ever be marked. When it exceeds 
++.B min, 
++the probability of doing so climbs linearly up
++to 
++.B probability, 
++until the average queue size hits
++.B max
++bytes. Because 
++.B probability 
++is normally not set to 100%, the queue size might
++conceivably rise above 
++.B max
++bytes, so the 
++.B limit
++parameter is provided to set a hard maximum for the size of the queue.
++
++.SH PARAMETERS
++.TP 
++min
++Average queue size at which marking becomes a possibility.
++.TP 
++max
++At this average queue size, the marking probability is maximal. Should be at
++least twice
++.B min
++to prevent synchronous retransmits, higher for low 
++.B min.
++.TP 
++probability
++Maximum probability for marking, specified as a floating point
++number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
++respectively).
++.TP 
++limit
++Hard limit on the real (not average) queue size in bytes. Further packets
++are dropped. Should be set higher than max+burst. It is advised to set this
++a few times higher than 
++.B max.
++.TP
++burst
++Used for determining how fast the average queue size is influenced by the
++real queue size. Larger values make the calculation more sluggish, allowing
++longer bursts of traffic before marking starts. Real life experiments
++support the following guideline: (min+min+max)/(3*avpkt).
++.TP 
++avpkt
++Specified in bytes. Used with burst to determine the time constant for
++average queue size calculations. 1000 is a good value.
++.TP
++bandwidth
++This rate is used for calculating the average queue size after some
++idle time. Should be set to the bandwidth of your interface. Does not mean
++that RED will shape for you! Optional.
++.TP
++ecn
++As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion
++Notification allows RED to notify remote hosts that their rate exceeds the
++amount of bandwidth available. Non-ECN capable hosts can only be notified by
++dropping a packet.  If this parameter is specified, packets which indicate
++that their hosts honor ECN will only be marked and not dropped, unless the
++queue size hits
++.B limit
++bytes. Needs a tc binary with RED support compiled in. Recommended.
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH SOURCES
++.TP 
++o
++Floyd, S., and Jacobson, V., Random Early Detection gateways for
++Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html
++.TP 
++o
++Some changes to the algorithm by Alexey N. Kuznetsov.
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>,  Alexey Makarenko
++<makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>.  
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-sfq.8 iproute2/debian/manpages/old/tc-sfq.8
+--- iproute2-orig/debian/manpages/old/tc-sfq.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-sfq.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,107 @@
++.TH TC 8 "8 December 2001" "iproute2" "Linux"
++.SH NAME
++sfq \- Stochastic Fairness Queueing
++.SH SYNOPSIS
++.B tc qdisc ... perturb
++seconds
++.B quantum
++bytes
++
++.SH DESCRIPTION
++
++Stochastic Fairness Queueing is a classless queueing discipline available for
++traffic control with the 
++.BR tc (8)
++command.
++
++SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'. 
++The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing
++any single flow from drowning out the rest.
++
++This may in fact have some effect in mitigating a Denial of Service attempt.
++
++SFQ is work-conserving and therefore always delivers a packet if it has one available.
++.SH ALGORITHM
++On enqueueing, each packet is assigned to a hash bucket, based on
++.TP
++(i)
++Source address
++.TP
++(ii)
++Destination address
++.TP
++(iii)
++Source port
++.P
++If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP. 
++Packets with other protocols are hashed based on the 32bits representation of their 
++destination and the socket they belong to. A flow corresponds mostly to a TCP/IP 
++connection.
++
++Each of these buckets should represent a unique flow. Because multiple flows may
++get hashed to the same bucket, the hashing algorithm is perturbed at configurable 
++intervals so that the unfairness lasts only for a short while. Perturbation may 
++however cause some inadvertent packet reordering to occur.
++
++When dequeuing, each hashbucket with data is queried in a round robin fashion.
++
++The compile time maximum length of the SFQ is 128 packets, which can be spread over
++at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed
++on the fullest bucket, thus maintaining fairness.
++
++.SH PARAMETERS
++.TP 
++perturb
++Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that 
++no perturbation occurs. Do not set too low for each perturbation may cause some packet
++reordering. Advised value: 10
++.TP 
++quantum
++Amount of bytes a flow is allowed to dequeue during a round of the round robin process.
++Defaults to the MTU of the interface which is also the advised value and the minimum value.
++
++.SH EXAMPLE & USAGE
++
++To attach to device ppp0:
++.P
++# tc qdisc add dev ppp0 root sfq perturb 10
++.P
++Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful 
++if it owns the queue.
++This is the case when the link speed equals the actually available bandwidth. This holds 
++for regular phone modems, ISDN connections and direct non-switched ethernet links. 
++.P
++Most often, cable modems and DSL devices do not fall into this category. The same holds 
++for when connected to a switch  and trying to send data to a congested segment also 
++connected to the switch.
++.P
++In this case, the effective queue does not reside within Linux and is therefore not 
++available for scheduling.
++.P
++Embed SFQ in a classful qdisc to make sure it owns the queue.
++
++.SH SOURCE
++.TP 
++o
++Paul E. McKenney "Stochastic Fairness Queuing",
++IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.
++
++.TP
++o
++Paul E. McKenney "Stochastic Fairness Queuing",
++"Interworking: Research and Experience", v.2, 1991, p.113-131.
++
++.TP 
++o
++See also:
++M. Shreedhar and George Varghese "Efficient Fair
++Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc-tbf.8 iproute2/debian/manpages/old/tc-tbf.8
+--- iproute2-orig/debian/manpages/old/tc-tbf.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc-tbf.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,138 @@
++.TH TC 8 "13 December 2001" "iproute2" "Linux"
++.SH NAME
++tbf \- Token Bucket Filter
++.SH SYNOPSIS
++.B tc qdisc ... tbf rate
++rate
++.B burst
++bytes/cell
++.B ( latency 
++ms 
++.B | limit
++bytes
++.B ) [ mpu 
++bytes
++.B [ peakrate
++rate
++.B mtu
++bytes/cell
++.B ] ]
++.P
++burst is also known as buffer and maxburst. mtu is also known as minburst.
++.SH DESCRIPTION
++
++The Token Bucket Filter is a classless queueing discipline available for
++traffic control with the 
++.BR tc (8)
++command.
++
++TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle
++itself, although packets are available, to ensure that the configured rate is not exceeded. 
++On all platforms except for Alpha,
++it is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness, 
++sending out  data exactly at the configured rates. 
++
++Much higher rates are possible but at the cost of losing the minimal burstiness. In that
++case, data is on average dequeued at the configured rate but may be sent much faster at millisecond 
++timescales. Because of further queues living in network adaptors, this is often not a problem.
++
++Kernels with a higher 'HZ' can achieve higher rates with perfect burstiness. On Alpha, HZ is ten
++times higher, leading to a 10mbit/s limit to perfection. These calculations hold for packets of on 
++average 1000 bytes.
++
++.SH ALGORITHM
++As the name implies, traffic is filtered based on the expenditure of 
++.B tokens.
++Tokens roughly correspond to bytes, with the additional constraint that each packet consumes
++some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies
++the link for some time.
++
++On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst 
++in one go. Tokens arrive at a steady rate, until the bucket is full.
++
++If no tokens are available, packets are queued, up to a configured limit. The TBF now 
++calculates the token deficit, and throttles until the first packet in the queue can be sent.
++
++If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured 
++to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF
++with a very small bucket, so that it doesn't burst.
++
++To achieve perfection, the second bucket may contain only a single packet, which leads to 
++the earlier mentioned 1mbit/s limit. 
++
++This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends
++on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100 
++packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.
++
++.SH PARAMETERS
++See 
++.BR tc (8)
++for how to specify the units of these values.
++.TP
++limit or latency
++Limit is the number of bytes that can be queued waiting for tokens to become
++available. You can also specify this the other way around by setting the
++latency parameter, which specifies the maximum amount of time a packet can
++sit in the TBF. The latter calculation takes into account the size of the
++bucket, the rate and possibly the peakrate (if set). These two parameters
++are mutually exclusive. 
++.TP
++burst
++Also known as buffer or maxburst.
++Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously. 
++In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer 
++if you want to reach your configured rate!
++
++If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
++The minimum buffer size can be calculated by dividing the rate by HZ.
++
++Token usage calculations are performed using a table which by default has a resolution of 8 packets. 
++This resolution can be changed by specifying the 
++.B cell
++size with the burst. For example, to specify a 6000 byte buffer with a 16
++byte cell size, set a burst of 6000/16. You will probably never have to set
++this. Must be an integral power of 2.
++.TP
++mpu
++A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit 
++determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
++.TP
++rate
++The speed knob. See remarks above about limits! See 
++.BR tc (8)
++for units.
++.PP
++Furthermore, if a peakrate is desired, the following parameters are available:
++
++.TP
++peakrate
++Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does 
++not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
++
++.TP
++mtu/minburst
++Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
++If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
++allows around 3mbit/s of peakrate, given 1000 byte packets.
++
++Like the regular burstsize you can also specify a 
++.B cell
++size.
++.SH EXAMPLE & USAGE
++
++To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s,
++a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes
++at most 70ms of latency, with perfect peakrate behaviour, issue:
++.P
++# tc qdisc add dev eth0 root tbf rate 0.5mbit \\
++  burst 5kb latency 70ms peakrate 1mbit       \\
++  minburst 1540
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/old/tc.8 iproute2/debian/manpages/old/tc.8
+--- iproute2-orig/debian/manpages/old/tc.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/old/tc.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,348 @@
++.TH TC 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++tc \- show / manipulate traffic control settings
++.SH SYNOPSIS
++.B tc qdisc [ add | change | replace | link ] dev 
++DEV 
++.B 
++[ parent 
++qdisc-id 
++.B | root ] 
++.B [ handle 
++qdisc-id ] qdisc
++[ qdisc specific parameters ]
++.P
++
++.B tc class [ add | change | replace ] dev
++DEV
++.B parent 
++qdisc-id 
++.B [ classid 
++class-id ] qdisc
++[ qdisc specific parameters ]
++.P
++
++.B tc filter [ add | change | replace ] dev
++DEV
++.B  [ parent
++qdisc-id
++.B | root ] protocol
++protocol
++.B prio
++priority filtertype
++[ filtertype specific parameters ]
++.B flowid
++flow-id
++
++.B tc [-s | -d ] qdisc show [ dev 
++DEV 
++.B  ]
++.P
++.B tc [-s | -d ] class show dev 
++DEV 
++.P
++.B tc filter show dev 
++DEV 
++
++.SH DESCRIPTION
++.B Tc
++is used to configure Traffic Control in the Linux kernel. Traffic Control consists 
++of the following:
++
++.TP 
++SHAPING
++When traffic is shaped, its rate of transmission is under control. Shaping may 
++be more than lowering the available bandwidth - it is also used to smooth out 
++bursts in traffic for better network behaviour. Shaping occurs on egress.
++
++.TP 
++SCHEDULING
++By scheduling the transmission of packets it is possible to improve interactivity
++for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
++is also called prioritizing, and happens only on egress.
++
++.TP
++POLICING
++Where shaping deals with transmission of traffic, policing pertains to traffic
++arriving. Policing thus occurs on ingress.
++
++.TP
++DROPPING
++Traffic exceeding a set bandwidth may also be dropped forthwith, both on 
++ingress and on egress.
++
++.P
++Processing of traffic is controlled by three kinds of objects: qdiscs, 
++classes and filters. 
++
++.SH QDISCS
++.B qdisc 
++is short for 'queueing discipline' and it is elementary to 
++understanding traffic control. Whenever the kernel needs to send a 
++packet to an interface, it is 
++.B enqueued
++to the qdisc configured for that interface. Immediately afterwards, the kernel
++tries to get as many packets as possible from the qdisc, for giving them
++to the network adaptor driver.
++
++A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure 
++First In, First Out queue. It does however store traffic when the network interface
++can't handle it momentarily.
++
++.SH CLASSES
++Some qdiscs can contain classes, which contain further qdiscs - traffic may 
++then be enqueued in any of the inner qdiscs, which are within the
++.B classes.
++When the kernel tries to dequeue a packet from such a 
++.B classful qdisc
++it can come from any of the classes. A qdisc may for example prioritize 
++certain kinds of traffic by trying to dequeue from certain classes
++before others.
++
++.SH FILTERS
++A
++.B filter
++is used by a classful qdisc to determine in which class a packet will
++be enqueued. Whenever traffic arrives at a class with subclasses, it needs
++to be classified. Various methods may be employed to do so, one of these
++are the filters. All filters attached to the class are called, until one of 
++them returns with a verdict. If no verdict was made, other criteria may be 
++available. This differs per qdisc.
++
++It is important to notice that filters reside 
++.B within
++qdiscs - they are not masters of what happens.
++
++.SH CLASSLESS QDISCS
++The classless qdiscs are:
++.TP 
++[p|b]fifo
++Simplest usable qdisc, pure First In, First Out behaviour. Limited in 
++packets or in bytes.
++.TP
++pfifo_fast
++Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
++queue which honors Type of Service flags, as well as the priority that may be 
++assigned to a packet.
++.TP
++red
++Random Early Detection simulates physical congestion by randomly dropping
++packets when nearing configured bandwidth allocation. Well suited to very
++large bandwidth applications.
++.TP 
++sfq
++Stochastic Fairness Queueing reorders queued traffic so each 'session'
++gets to send a packet in turn.
++.TP
++tbf
++The Token Bucket Filter is suited for slowing traffic down to a precisely
++configured rate. Scales well to large bandwidths. 
++.SH CONFIGURING CLASSLESS QDISCS
++In the absence of classful qdiscs, classless qdiscs can only be attached at 
++the root of a device. Full syntax:
++.P
++.B tc qdisc add dev 
++DEV 
++.B root 
++QDISC QDISC-PARAMETERS
++
++To remove, issue
++.P
++.B tc qdisc del dev
++DEV
++.B root
++
++The  
++.B pfifo_fast
++qdisc is the automatic default in the absence of a configured qdisc.
++
++.SH CLASSFUL QDISCS
++The classful qdiscs are:
++.TP
++CBQ
++Class Based Queueing implements a rich linksharing hierarchy of classes. 
++It contains shaping elements as well as prioritizing capabilities. Shaping is
++performed using link idle time calculations based on average packet size and
++underlying link bandwidth. The latter may be ill-defined for some interfaces.
++.TP
++HTB
++The Hierarchy Token Bucket implements a rich linksharing hierarchy of 
++classes with an emphasis on conforming to existing practices. HTB facilitates
++guaranteeing bandwidth to classes, while also allowing specification of upper
++limits to inter-class sharing. It contains shaping elements, based on TBF and
++can prioritize classes.	
++.TP 
++PRIO
++The PRIO qdisc is a non-shaping container for a configurable number of 
++classes which are dequeued in order. This allows for easy prioritization 
++of traffic, where lower classes are only able to send if higher ones have 
++no packets available. To facilitate configuration, Type Of Service bits are 
++honored by default.
++.SH THEORY OF OPERATION
++Classes form a tree, where each class has a single parent. 
++A class may have multiple children. Some qdiscs allow for runtime addition
++of classes (CBQ, HTB) while others (PRIO) are created with a static number of 
++children.
++
++Qdiscs which allow dynamic addition of classes can have zero or more 
++subclasses to which traffic may be enqueued. 
++
++Furthermore, each class contains a
++.B leaf qdisc
++which by default has 
++.B pfifo 
++behaviour though another qdisc can be attached in place. This qdisc may again 
++contain classes, but each class can have only one leaf qdisc. 
++
++When a packet enters a classful qdisc it can be 
++.B classified
++to one of the classes within. Three criteria are available, although not all 
++qdiscs will use all three:
++.TP 
++tc filters
++If tc filters are attached to a class, they are consulted first 
++for relevant instructions. Filters can match on all fields of a packet header, 
++as well as on the firewall mark applied by ipchains or iptables. See 
++.BR tc-filters (8).
++.TP
++Type of Service
++Some qdiscs have built in rules for classifying packets based on the TOS field.
++.TP
++skb->priority
++Userspace programs can encode a class-id in the 'skb->priority' field using 
++the SO_PRIORITY option.
++.P
++Each node within the tree can have its own filters but higher level filters
++may also point directly to lower classes.
++
++If classification did not succeed, packets are enqueued to the leaf qdisc 
++attached to that class. Check qdisc specific manpages for details, however.
++
++.SH NAMING
++All qdiscs, classes and filters have IDs, which can either be specified
++or be automatically assigned. 
++
++IDs consist of a major number and a minor number, separated by a colon.
++
++.TP 
++QDISCS
++A qdisc, which potentially can have children, 
++gets assigned a major number, called a 'handle', leaving the minor 
++number namespace available for classes. The handle is expressed as '10:'. 
++It is customary to explicitly assign a handle to qdiscs expected to have 
++children.
++
++.TP 
++CLASSES
++Classes residing under a qdisc share their qdisc major number, but each have
++a separate minor number called a 'classid' that has no relation to their 
++parent classes, only to their parent qdisc. The same naming custom as for 
++qdiscs applies.
++
++.TP 
++FILTERS
++Filters have a three part ID, which is only needed when using a hashed
++filter hierarchy, for which see
++.BR tc-filters (8).
++.SH UNITS
++All parameters accept a floating point number, possibly followed by a unit.
++.P
++Bandwidths or rates can be specified in:
++.TP 
++kbps
++Kilobytes per second
++.TP
++mbps
++Megabytes per second
++.TP
++kbit
++Kilobits per second
++.TP
++mbit
++Megabits per second
++.TP
++bps or a bare number
++Bytes per second
++.P
++Amounts of data can be specified in:
++.TP
++kb or k
++Kilobytes
++.TP
++mb or m
++Megabytes
++.TP
++mbit
++Megabits
++.TP
++kbit
++Kilobits
++.TP
++b or a bare number
++Bytes.
++.P
++Lengths of time can be specified in:
++.TP
++s, sec or secs
++Whole seconds
++.TP
++ms, msec or msecs
++Milliseconds
++.TP
++us, usec, usecs or a bare number
++Microseconds.
++
++.SH TC COMMANDS
++The following commands are available for qdiscs, classes and filter:
++.TP
++add
++Add a qdisc, class or filter to a node. For all entities, a 
++.B parent
++must be passed, either by passing its ID or by attaching directly to the root of a device. 
++When creating a qdisc or a filter, it can be named with the
++.B handle
++parameter. A class is named with the
++.B classid
++parameter.
++
++.TP
++remove
++A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs 
++are automatically deleted, as well as any filters attached to them.
++
++.TP
++change
++Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
++that the handle cannot be changed and neither can the parent. In other words, 
++.B
++change 
++cannot move a node.
++
++.TP
++replace
++Performs a nearly atomic remove/add on an existing node id. If the node does not exist yet
++it is created.
++
++.TP
++link
++Only available for qdiscs and performs a replace where the node 
++must exist already.
++
++
++.SH HISTORY
++.B tc
++was written by Alexey N. Kuznetsov and added in Linux 2.2.
++.SH SEE ALSO
++.BR tc-cbq (8),
++.BR tc-htb (8),
++.BR tc-sfq (8),
++.BR tc-red (8),
++.BR tc-tbf (8),
++.BR tc-pfifo (8),
++.BR tc-bfifo (8),
++.BR tc-pfifo_fast (8),
++.BR tc-filters (8)
++
++.SH AUTHOR
++Manpage maintained by bert hubert (ahu@ds9a.nl)
++
+diff -Naur iproute2-orig/debian/manpages/tc-cbq-details.8 iproute2/debian/manpages/tc-cbq-details.8
+--- iproute2-orig/debian/manpages/tc-cbq-details.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-cbq-details.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,425 @@
++.TH CBQ 8 "8 December 2001" "iproute2" "Linux"
++.SH NAME
++CBQ \- Class Based Queueing
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] cbq avpkt
++bytes
++.B bandwidth
++rate
++.B [ cell 
++bytes
++.B ] [ ewma
++log
++.B ] [ mpu
++bytes
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] cbq allot
++bytes
++.B [ bandwidth 
++rate 
++.B ] [ rate 
++rate
++.B ] prio
++priority
++.B [ weight
++weight
++.B ] [ minburst 
++packets
++.B ] [ maxburst 
++packets 
++.B ] [ ewma 
++log
++.B ] [ cell
++bytes
++.B ] avpkt
++bytes
++.B [ mpu
++bytes 
++.B ] [ bounded isolated ] [ split
++handle
++.B & defmap
++defmap
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++Class Based Queueing is a classful qdisc that implements a rich
++linksharing hierarchy of classes.  It contains shaping elements as
++well as prioritizing capabilities.  Shaping is performed using link
++idle time calculations based on the timing of dequeue events and 
++underlying link bandwidth.
++
++.SH SHAPING ALGORITHM
++Shaping is done using link idle time calculations, and actions taken if
++these calculations deviate from set limits.
++
++When shaping a 10mbit/s connection to 1mbit/s, the link will
++be idle 90% of the time. If it isn't, it needs to be throttled so that it
++IS idle 90% of the time.
++
++From the kernel's perspective, this is hard to measure, so CBQ instead 
++derives the idle time from the number of microseconds (in fact, jiffies) 
++that elapse between  requests from the device driver for more data. Combined 
++with the  knowledge of packet sizes, this is used to approximate how full or 
++empty the link is.
++
++This is rather circumspect and doesn't always arrive at proper
++results. For example, what is the actual link speed of an interface
++that is not really able to transmit the full 100mbit/s of data,
++perhaps because of a badly implemented driver? A PCMCIA network card
++will also never achieve 100mbit/s because of the way the bus is
++designed - again, how do we calculate the idle time?
++
++The physical link bandwidth may be ill defined in case of not-quite-real 
++network devices like PPP over Ethernet or PPTP over TCP/IP. The effective 
++bandwidth in that case is probably determined by the efficiency of pipes 
++to userspace - which not defined.
++
++During operations, the effective idletime is measured using an
++exponential weighted moving average (EWMA), which considers recent
++packets to be exponentially more important than past ones. The Unix
++loadaverage is calculated in the same way.
++
++The calculated idle time is subtracted from the EWMA measured one,
++the resulting number is called 'avgidle'. A perfectly loaded link has
++an avgidle of zero: packets arrive exactly at the calculated
++interval.
++
++An overloaded link has a negative avgidle and if it gets too negative,
++CBQ throttles and is then 'overlimit'.
++
++Conversely, an idle link might amass a huge avgidle, which would then
++allow infinite bandwidths after a few hours of silence. To prevent
++this, avgidle is capped at 
++.B maxidle.
++
++If overlimit, in theory, the CBQ could throttle itself for exactly the
++amount of time that was calculated to pass between packets, and then
++pass one packet, and throttle again. Due to timer resolution constraints,
++this may not be feasible, see the 
++.B minburst
++parameter below.
++
++.SH CLASSIFICATION
++Within the one CBQ instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, CBQ starts at the root and uses various methods to 
++determine which class should receive the data. If a verdict is reached, this
++process is repeated for the recipient class which might have further
++means of classifying traffic to its children, if any.
++
++CBQ has the following methods available to classify a packet to any child 
++classes.
++.TP
++(i)
++.B skb->priority class encoding.
++Can be set from userspace by an application with the 
++.B SO_PRIORITY
++setsockopt.
++The 
++.B skb->priority class encoding
++only applies if the skb->priority holds a major:minor handle of an existing 
++class within  this qdisc.
++.TP
++(ii)
++tc filters attached to the class.
++.TP
++(iii)
++The defmap of a class, as set with the 
++.B split & defmap
++parameters. The defmap may contain instructions for each possible Linux packet
++priority.
++
++.P
++Each class also has a 
++.B level.
++Leaf nodes, attached to the bottom of the class hierarchy, have a level of 0.
++.SH CLASSIFICATION ALGORITHM
++
++Classification is a loop, which terminates when a leaf class is found. At any 
++point the loop may jump to the fallback algorithm.
++
++The loop consists of the following steps:
++.TP 
++(i)
++If the packet is generated locally and has a valid classid encoded within its
++.B skb->priority,
++choose it and terminate.
++
++.TP
++(ii)
++Consult the tc filters, if any, attached to this child. If these return
++a class which is not a leaf class, restart loop from the class returned.
++If it is a leaf, choose it and terminate.
++.TP
++(iii)
++If the tc filters did not return a class, but did return a classid, 
++try to find a class with that id within this qdisc. 
++Check if the found class is of a lower
++.B level
++than the current class. If so, and the returned class is not a leaf node,
++restart the loop at the found class. If it is a leaf node, terminate.
++If we found an upward reference to a higher level, enter the fallback 
++algorithm.
++.TP
++(iv)
++If the tc filters did not return a class, nor a valid reference to one,
++consider the minor number of the reference to be the priority. Retrieve
++a class from the defmap of this class for the priority. If this did not
++contain a class, consult the defmap of this class for the 
++.B BEST_EFFORT
++class. If this is an upward reference, or no 
++.B BEST_EFFORT 
++class was defined,
++enter the fallback algorithm. If a valid class was found, and it is not a
++leaf node, restart the loop at this class. If it is a leaf, choose it and 
++terminate. If
++neither the priority distilled from the classid, nor the 
++.B BEST_EFFORT 
++priority yielded a class, enter the fallback algorithm.
++.P
++The fallback algorithm resides outside of the loop and is as follows.
++.TP
++(i)
++Consult the defmap of the class at which the jump to fallback occured. If 
++the defmap contains a class for the 
++.B
++priority
++of the class (which is related to the TOS field), choose this class and 
++terminate. 
++.TP
++(ii)
++Consult the map for a class for the
++.B BEST_EFFORT
++priority. If found, choose it, and terminate.
++.TP
++(iii)
++Choose the class at which break out to the fallback algorithm occured. Terminate.
++.P
++The packet is enqueued to the class which was chosen when either algorithm 
++terminated. It is therefore possible for a packet to be enqueued *not* at a
++leaf node, but in the middle of the hierarchy.
++
++.SH LINK SHARING ALGORITHM
++When dequeuing for sending to the network device, CBQ decides which of its 
++classes will be allowed to send. It does so with a Weighted Round Robin process
++in which each class with packets gets a chance to send in turn. The WRR process
++starts by asking the highest priority classes (lowest numerically - 
++highest semantically) for packets, and will continue to do so until they
++have no more data to offer, in which case the process repeats for lower 
++priorities.
++
++.B CERTAINTY ENDS HERE, ANK PLEASE HELP
++
++Each class is not allowed to send at length though - they can only dequeue a
++configurable amount of data during each round. 
++
++If a class is about to go overlimit, and it is not
++.B bounded
++it will try to borrow avgidle from siblings that are not
++.B isolated. 
++This process is repeated from the bottom upwards. If a class is unable
++to borrow enough avgidle to send a packet, it is throttled and not asked
++for a packet for enough time for the avgidle to increase above zero.
++
++.B I REALLY NEED HELP FIGURING THIS OUT. REST OF DOCUMENT IS PRETTY CERTAIN
++.B AGAIN.
++
++.SH QDISC
++The root qdisc of a CBQ class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the CBQ instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional.
++.TP
++avpkt bytes
++For calculations, the average packet size must be known. It is silently capped
++at a minimum of 2/3 of the interface MTU. Mandatory.
++.TP
++bandwidth rate
++To determine the idle time, CBQ must know the bandwidth of your underlying 
++physical interface, or parent qdisc. This is a vital parameter, more about it
++later. Mandatory.
++.TP
++cell
++The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
++.TP 
++mpu
++A zero sized packet may still take time to transmit. This value is the lower
++cap for packet transmission time calculations - packets smaller than this value
++are still deemed to have this size. Defaults to zero.
++.TP
++ewma log
++When CBQ needs to measure the average idle time, it does so using an 
++Exponentially Weighted Moving Average which smoothes out measurements into
++a moving average. The EWMA LOG determines how much smoothing occurs. Defaults 
++to 5. Lower values imply greater sensitivity. Must be between 0 and 31.
++.P
++A CBQ qdisc does not shape out of its own accord. It only needs to know certain
++parameters about the underlying link. Actual shaping is done in classes.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++weight weight
++When dequeuing to the interface, classes are tried for traffic in a 
++round-robin fashion. Classes with a higher configured qdisc will generally
++have more traffic to offer during each round, so it makes sense to allow
++it to dequeue more traffic. All weights under a class are normalized, so
++only the ratios matter. Defaults to the configured rate, unless the priority 
++of this class is maximal, in which case it is set to 1.
++.TP 
++allot bytes
++Allot specifies how many bytes a qdisc can dequeue
++during each round of the process. This parameter is weighted using the 
++renormalized class weight described above.
++
++.TP 
++priority priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++rate rate
++Maximum rate this class and all its children combined can send at. Mandatory.
++
++.TP
++bandwidth rate
++This is different from the bandwidth specified when creating a CBQ disc. Only
++used to determine maxidle and offtime, which are only calculated when
++specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
++
++.TP 
++maxburst
++This number of packets is used to calculate maxidle so that when
++avgidle is at maxidle, this number of average packets can be burst
++before avgidle drops to 0. Set it higher to be more tolerant of
++bursts. You can't set maxidle directly, only via this parameter.
++
++.TP
++minburst 
++As mentioned before, CBQ needs to throttle in case of
++overlimit. The ideal solution is to do so for exactly the calculated
++idle time, and pass 1 packet. However, Unix kernels generally have a
++hard time scheduling events shorter than 10ms, so it is better to
++throttle for a longer period, and then pass minburst packets in one
++go, and then sleep minburst times longer.
++
++The time to wait is called the offtime. Higher values of minburst lead
++to more accurate shaping in the long term, but to bigger bursts at
++millisecond timescales.
++
++.TP
++minidle
++If avgidle is below 0, we are overlimits and need to wait until
++avgidle will be big enough to send one packet. To prevent a sudden
++burst from shutting down the link for a prolonged period of time,
++avgidle is reset to minidle if it gets too low.
++
++Minidle is specified in negative microseconds, so 10 means that
++avgidle is capped at -10us.
++
++.TP
++bounded 
++Signifies that this class will not borrow bandwidth from its siblings.
++.TP 
++isolated
++Means that this class will not borrow bandwidth to its siblings
++
++.TP 
++split major:minor & defmap bitmap[/bitmap]
++If consulting filters attached to a class did not give a verdict, 
++CBQ can also classify based on the packet's priority. There are 16
++priorities available, numbered from 0 to 15. 
++
++The defmap specifies which priorities this class wants to receive, 
++specified as a bitmap. The Least Significant Bit corresponds to priority 
++zero. The 
++.B split
++parameter tells CBQ at which class the decision must be made, which should
++be a (grand)parent of the class you are adding.
++
++As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
++configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
++
++The complimentary configuration would then 
++be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
++Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
++.TP
++estimator interval timeconstant
++CBQ can measure how much bandwidth each class is using, which tc filters
++can use to classify packets with. In order to determine the bandwidth
++it uses a very simple estimator that measures once every
++.B interval
++microseconds how much traffic has passed. This again is a EWMA, for which
++the time constant can be specified, also in microseconds. The 
++.B time constant
++corresponds to the sluggishness of the measurement or, conversely, to the 
++sensitivity of the average to short bursts. Higher values mean less
++sensitivity. 
++
++
++
++.SH SOURCES
++.TP
++o
++Sally Floyd and Van Jacobson, "Link-sharing and Resource
++Management Models for Packet Networks",
++IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
++
++.TP 
++o
++Sally Floyd, "Notes on CBQ and Guarantee Service", 1995
++
++.TP
++o
++Sally Floyd, "Notes on Class-Based Queueing: Setting
++Parameters", 1996
++
++.TP 
++o
++Sally Floyd and Michael Speer, "Experimental Results
++for Class-Based Queueing", 1998, not published.
++
++
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-cbq.8 iproute2/debian/manpages/tc-cbq.8
+--- iproute2-orig/debian/manpages/tc-cbq.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-cbq.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,353 @@
++.TH CBQ 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++CBQ \- Class Based Queueing
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] cbq [ allot 
++bytes
++.B ] avpkt
++bytes
++.B bandwidth
++rate
++.B [ cell 
++bytes
++.B ] [ ewma
++log
++.B ] [ mpu
++bytes
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] cbq allot
++bytes
++.B [ bandwidth 
++rate 
++.B ] [ rate 
++rate
++.B ] prio
++priority
++.B [ weight
++weight
++.B ] [ minburst 
++packets
++.B ] [ maxburst 
++packets 
++.B ] [ ewma 
++log
++.B ] [ cell
++bytes
++.B ] avpkt
++bytes
++.B [ mpu
++bytes 
++.B ] [ bounded isolated ] [ split
++handle
++.B & defmap
++defmap
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++Class Based Queueing is a classful qdisc that implements a rich
++linksharing hierarchy of classes.  It contains shaping elements as
++well as prioritizing capabilities.  Shaping is performed using link
++idle time calculations based on the timing of dequeue events and 
++underlying link bandwidth.
++
++.SH SHAPING ALGORITHM
++When shaping a 10mbit/s connection to 1mbit/s, the link will
++be idle 90% of the time. If it isn't, it needs to be throttled so that it
++IS idle 90% of the time.
++
++During operations, the effective idletime is measured using an
++exponential weighted moving average (EWMA), which considers recent
++packets to be exponentially more important than past ones. The Unix
++loadaverage is calculated in the same way.
++
++The calculated idle time is subtracted from the EWMA measured one,
++the resulting number is called 'avgidle'. A perfectly loaded link has
++an avgidle of zero: packets arrive exactly at the calculated
++interval.
++
++An overloaded link has a negative avgidle and if it gets too negative,
++CBQ throttles and is then 'overlimit'.
++
++Conversely, an idle link might amass a huge avgidle, which would then
++allow infinite bandwidths after a few hours of silence. To prevent
++this, avgidle is capped at 
++.B maxidle.
++
++If overlimit, in theory, the CBQ could throttle itself for exactly the
++amount of time that was calculated to pass between packets, and then
++pass one packet, and throttle again. Due to timer resolution constraints,
++this may not be feasible, see the 
++.B minburst
++parameter below.
++
++.SH CLASSIFICATION
++Within the one CBQ instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, CBQ starts at the root and uses various methods to 
++determine which class should receive the data. 
++
++In the absence of uncommon configuration options, the process is rather easy. 
++At each node we look for an instruction, and then go to the class the 
++instruction refers us to. If the class found is a barren leaf-node (without 
++children), we enqueue the packet there. If it is not yet a leaf node, we do 
++the whole thing over again starting from that node. 
++
++The following actions are performed, in order at each node we visit, until one 
++sends us to another node, or terminates the process.
++.TP
++(i)
++Consult filters attached to the class. If sent to a leafnode, we are done. 
++Otherwise, restart.
++.TP
++(ii)
++Consult the defmap for the priority assigned to this packet, which depends 
++on the TOS bits. Check if the referral is leafless, otherwise restart.
++.TP
++(iii)
++Ask the defmap for instructions for the 'best effort' priority. Check the 
++answer for leafness, otherwise restart.
++.TP
++(iv)
++If none of the above returned with an instruction, enqueue at this node.
++.P
++This algorithm makes sure that a packet always ends up somewhere, even while
++you are busy building your configuration. 
++
++For more details, see
++.BR tc-cbq-details(8).
++
++.SH LINK SHARING ALGORITHM
++When dequeuing for sending to the network device, CBQ decides which of its 
++classes will be allowed to send. It does so with a Weighted Round Robin process
++in which each class with packets gets a chance to send in turn. The WRR process
++starts by asking the highest priority classes (lowest numerically - 
++highest semantically) for packets, and will continue to do so until they
++have no more data to offer, in which case the process repeats for lower 
++priorities.
++
++Classes by default borrow bandwidth from their siblings. A class can be 
++prevented from doing so by declaring it 'bounded'. A class can also indicate 
++its unwillingness to lend out bandwidth by being 'isolated'.
++
++.SH QDISC
++The root of a CBQ qdisc class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the CBQ instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional, but very useful if classes
++will be generated within this qdisc.
++.TP 
++allot bytes
++This allotment is the 'chunkiness' of link sharing and is used for determining packet
++transmission time tables. The qdisc allot differs slightly from the class allot discussed
++below. Optional. Defaults to a reasonable value, related to avpkt.
++.TP
++avpkt bytes
++The average size of a packet is needed for calculating maxidle, and is also used
++for making sure 'allot' has a safe value. Mandatory.
++.TP
++bandwidth rate
++To determine the idle time, CBQ must know the bandwidth of your underlying 
++physical interface, or parent qdisc. This is a vital parameter, more about it
++later. Mandatory.
++.TP
++cell
++The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
++.TP 
++mpu
++A zero sized packet may still take time to transmit. This value is the lower
++cap for packet transmission time calculations - packets smaller than this value
++are still deemed to have this size. Defaults to zero.
++.TP
++ewma log
++When CBQ needs to measure the average idle time, it does so using an 
++Exponentially Weighted Moving Average which smoothes out measurements into
++a moving average. The EWMA LOG determines how much smoothing occurs. Lower 
++values imply greater sensitivity. Must be between 0 and 31. Defaults 
++to 5.
++.P
++A CBQ qdisc does not shape out of its own accord. It only needs to know certain
++parameters about the underlying link. Actual shaping is done in classes.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++weight weight
++When dequeuing to the interface, classes are tried for traffic in a 
++round-robin fashion. Classes with a higher configured qdisc will generally
++have more traffic to offer during each round, so it makes sense to allow
++it to dequeue more traffic. All weights under a class are normalized, so
++only the ratios matter. Defaults to the configured rate, unless the priority 
++of this class is maximal, in which case it is set to 1.
++.TP 
++allot bytes
++Allot specifies how many bytes a qdisc can dequeue
++during each round of the process. This parameter is weighted using the 
++renormalized class weight described above. Silently capped at a minimum of
++3/2 avpkt. Mandatory.
++
++.TP 
++prio priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++avpkt
++See the QDISC section.
++
++.TP 
++rate rate
++Maximum rate this class and all its children combined can send at. Mandatory.
++
++.TP
++bandwidth rate
++This is different from the bandwidth specified when creating a CBQ disc! Only
++used to determine maxidle and offtime, which are only calculated when
++specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
++
++.TP 
++maxburst
++This number of packets is used to calculate maxidle so that when
++avgidle is at maxidle, this number of average packets can be burst
++before avgidle drops to 0. Set it higher to be more tolerant of
++bursts. You can't set maxidle directly, only via this parameter.
++
++.TP
++minburst 
++As mentioned before, CBQ needs to throttle in case of
++overlimit. The ideal solution is to do so for exactly the calculated
++idle time, and pass 1 packet. However, Unix kernels generally have a
++hard time scheduling events shorter than 10ms, so it is better to
++throttle for a longer period, and then pass minburst packets in one
++go, and then sleep minburst times longer.
++
++The time to wait is called the offtime. Higher values of minburst lead
++to more accurate shaping in the long term, but to bigger bursts at
++millisecond timescales. Optional.
++
++.TP
++minidle
++If avgidle is below 0, we are overlimits and need to wait until
++avgidle will be big enough to send one packet. To prevent a sudden
++burst from shutting down the link for a prolonged period of time,
++avgidle is reset to minidle if it gets too low.
++
++Minidle is specified in negative microseconds, so 10 means that
++avgidle is capped at -10us. Optional.
++
++.TP
++bounded 
++Signifies that this class will not borrow bandwidth from its siblings.
++.TP 
++isolated
++Means that this class will not borrow bandwidth to its siblings
++
++.TP 
++split major:minor & defmap bitmap[/bitmap]
++If consulting filters attached to a class did not give a verdict, 
++CBQ can also classify based on the packet's priority. There are 16
++priorities available, numbered from 0 to 15. 
++
++The defmap specifies which priorities this class wants to receive, 
++specified as a bitmap. The Least Significant Bit corresponds to priority 
++zero. The 
++.B split
++parameter tells CBQ at which class the decision must be made, which should
++be a (grand)parent of the class you are adding.
++
++As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
++configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
++
++The complimentary configuration would then 
++be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
++Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
++.TP
++estimator interval timeconstant
++CBQ can measure how much bandwidth each class is using, which tc filters
++can use to classify packets with. In order to determine the bandwidth
++it uses a very simple estimator that measures once every
++.B interval
++microseconds how much traffic has passed. This again is a EWMA, for which
++the time constant can be specified, also in microseconds. The 
++.B time constant
++corresponds to the sluggishness of the measurement or, conversely, to the 
++sensitivity of the average to short bursts. Higher values mean less
++sensitivity. 
++
++.SH BUGS
++The actual bandwidth of the underlying link may not be known, for example 
++in the case of PPoE or PPTP connections which in fact may send over a 
++pipe, instead of over a physical device. CBQ is quite resilient to major
++errors in the configured bandwidth, probably a the cost of coarser shaping.
++
++Default kernels rely on coarse timing information for making decisions. These 
++may make shaping precise in the long term, but inaccurate on second long scales.
++
++See 
++.BR tc-cbq-details(8)
++for hints on how to improve this.
++
++.SH SOURCES
++.TP
++o
++Sally Floyd and Van Jacobson, "Link-sharing and Resource
++Management Models for Packet Networks",
++IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
++
++.TP 
++o
++Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
++
++.TP
++o
++Sally Floyd, "Notes on Class-Based Queueing: Setting
++Parameters", 1996
++
++.TP 
++o
++Sally Floyd and Michael Speer, "Experimental Results
++for Class-Based Queueing", 1998, not published.
++
++
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-htb.8 iproute2/debian/manpages/tc-htb.8
+--- iproute2-orig/debian/manpages/tc-htb.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-htb.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,150 @@
++.TH HTB 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++HTB \- Hierarchy Token Bucket
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] htb [ default 
++minor-id
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] htb rate
++rate
++.B [ ceil
++rate 
++.B ] burst 
++bytes
++.B [ cburst
++bytes
++.B ] [ prio
++priority
++.B ] 
++
++.SH DESCRIPTION
++HTB is meant as a more understandable and intuitive replacement for
++the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
++of the outbound bandwidth on a given link. Both allow you to use one
++physical link to simulate several slower links and to send different
++kinds of traffic on different simulated links. In both cases, you have
++to specify how to divide the physical link into simulated links and
++how to decide which simulated link to use for a given packet to be sent. 
++
++Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm 
++which does not depend on interface characteristics and so does not need to
++know the underlying bandwidth of the outgoing interface.
++
++.SH SHAPING ALGORITHM
++Shaping works as documented in
++.B tc-tbf (8).
++
++.SH CLASSIFICATION
++Within the one HRB instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, HTB starts at the root and uses various methods to 
++determine which class should receive the data. 
++
++In the absence of uncommon configuration options, the process is rather easy. 
++At each node we look for an instruction, and then go to the class the 
++instruction refers us to. If the class found is a barren leaf-node (without 
++children), we enqueue the packet there. If it is not yet a leaf node, we do 
++the whole thing over again starting from that node. 
++
++The following actions are performed, in order at each node we visit, until one 
++sends us to another node, or terminates the process.
++.TP
++(i)
++Consult filters attached to the class. If sent to a leafnode, we are done. 
++Otherwise, restart.
++.TP
++(ii)
++If none of the above returned with an instruction, enqueue at this node.
++.P
++This algorithm makes sure that a packet always ends up somewhere, even while
++you are busy building your configuration. 
++
++.SH LINK SHARING ALGORITHM
++FIXME
++
++.SH QDISC
++The root of a HTB qdisc class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the HTB instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the HTB can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional, but very useful if classes
++will be generated within this qdisc.
++.TP 
++default minor-id
++Unclassified traffic gets sent to the class with this minor-id.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++prio priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++rate rate
++Maximum rate this class and all its children are guaranteed. Mandatory.
++
++.TP
++ceil rate
++Maximum rate at which a class can send, if its parent has bandwidth to spare. 
++Defaults to the configured rate, which implies no borrowing
++
++.TP 
++burst bytes
++Amount of bytes that can be burst at 
++.B ceil
++speed, in excess of the configured
++.B rate. 
++Should be at least as high as the highest burst of all children.
++
++.TP 
++cburst bytes
++Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
++as the interface can transmit them. For perfect evening out, should be equal to at most one average
++packet. Should be at least as high as the highest cburst of all children.
++
++.SH NOTES
++Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel, 
++there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
++From this, the mininum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte 
++burst as 100*12kb*8 equals 10mbit.
++
++.SH SEE ALSO
++.BR tc (8)
++.P
++HTB website: http://luxik.cdi.cz/~devik/qos/htb/
++.SH AUTHOR
++Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-pbfifo.8 iproute2/debian/manpages/tc-pbfifo.8
+--- iproute2-orig/debian/manpages/tc-pbfifo.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-pbfifo.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,72 @@
++.TH PBFIFO 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++pfifo \- Packet limited First In, First Out queue
++.P
++bfifo \- Byte limited First In, First Out queue
++
++.SH SYNOPSIS
++.B tc qdisc ... add pfifo
++.B [ limit 
++packets
++.B ]
++.P
++.B tc qdisc ... add bfifo
++.B [ limit 
++bytes
++.B ]
++
++.SH DESCRIPTION
++The pfifo and bfifo qdiscs are unadorned First In, First Out queues. They are the
++simplest queues possible and therefore have no overhead. 
++.B pfifo
++constrains the queue size as measured in packets. 
++.B bfifo
++does so as measured in bytes.
++
++Like all non-default qdiscs, they maintain statistics. This might be a reason to prefer 
++pfifo or bfifo over the default.
++
++.SH ALGORITHM
++A list of packets is maintained, when a packet is enqueued it gets inserted at the tail of
++a list. When a packet needs to be sent out to the network, it is taken from the head of the list. 
++
++If the list is too long, no further packets are allowed on. This is called 'tail drop'.
++
++.SH PARAMETERS
++.TP 
++limit
++Maximum queue size. Specified in bytes for bfifo, in packets for pfifo. For pfifo, defaults 
++to the interface txqueuelen, as specified with 
++.BR ifconfig (8)
++or
++.BR ip (8).
++
++For bfifo, it defaults to the txqueuelen multiplied by the interface MTU.
++
++.SH OUTPUT
++The output of 
++.B tc -s qdisc ls
++contains the limit, either in packets or in bytes, and the number of bytes 
++and packets actually sent. An unsent and dropped packet only appears between braces 
++and is not counted as 'Sent'.
++
++In this example, the queue length is 100 packets, 45894 bytes were sent over 681 packets. 
++No packets were dropped, and as the pfifo queue does not slow down packets, there were also no
++overlimits:
++.P
++.nf
++# tc -s qdisc ls dev eth0 
++qdisc pfifo 8001: dev eth0 limit 100p
++ Sent 45894 bytes 681 pkts (dropped 0, overlimits 0) 
++.fi
++
++If a backlog occurs, this is displayed as well.
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
++
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-pfifo_fast.8 iproute2/debian/manpages/tc-pfifo_fast.8
+--- iproute2-orig/debian/manpages/tc-pfifo_fast.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-pfifo_fast.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,59 @@
++.TH PFIFO_FAST 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++pfifo_fast \- three-band first in, first out queue
++
++.SH DESCRIPTION
++pfifo_fast is the default qdisc of each interface.
++
++Whenever an interface is created, the pfifo_fast qdisc is automatically used
++as a queue. If another qdisc is attached, it preempts the default
++pfifo_fast, which automatically returns to function when an existing qdisc
++is detached.
++
++In this sense this qdisc is magic, and unlike other qdiscs.
++
++.SH ALGORITHM
++The algorithm is very similar to that of the classful 
++.BR tc-prio (8)
++qdisc. 
++.B pfifo_fast
++is like three
++.BR tc-pfifo (8)
++queues side by side, where packets can be enqueued in any of the three bands
++based on their Type of Service bits or assigned priority. 
++
++Not all three bands are dequeued simultaneously - as long as lower bands
++have traffic, higher bands are never dequeued. This can be used to
++prioritize interactive traffic or penalize 'lowest cost' traffic.
++
++Each band can be txqueuelen packets long, as configured with
++.BR ifconfig (8)
++or 
++.BR ip (8).
++Additional packets coming in are not enqueued but are instead dropped.
++
++See
++.BR tc-prio (8)
++for complete details on how TOS bits are translated into bands.
++.SH PARAMETERS
++.TP 
++txqueuelen
++The length of the three bands depends on the interface txqueuelen, as
++specified with
++.BR ifconfig (8)
++or
++.BR ip (8).
++
++.SH BUGS
++Does not maintain statistics and does not show up in tc qdisc ls. This is because
++it is the automatic default in the absence of a configured qdisc. 
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
++
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-prio.8 iproute2/debian/manpages/tc-prio.8
+--- iproute2-orig/debian/manpages/tc-prio.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-prio.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,187 @@
++.TH PRIO 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++PRIO \- Priority qdisc
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] prio [ bands 
++bands
++.B ] [ priomap
++band,band,band... 
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++The PRIO qdisc is a simple classful queueing discipline that contains
++an arbitrary number of classes of differing priority. The classes are
++dequeued in numerical descending order of priority. PRIO is a scheduler 
++and never delays packets - it is a work-conserving qdisc, though the qdiscs
++contained in the classes may not be.
++
++Very useful for lowering latency when there is no need for slowing down
++traffic.
++
++.SH ALGORITHM
++On creation with 'tc qdisc add', a fixed number of bands is created. Each
++band is a class, although is not possible to add classes with 'tc qdisc
++add', the number of bands to be created must instead be specified on the
++commandline attaching PRIO to its root.
++
++When dequeueing, band 0 is tried first and only if it did not deliver a
++packet does PRIO try band 1, and so onwards. Maximum reliability packets
++should therefore go to band 0, minimum delay to band 1 and the rest to band
++2.
++
++As the PRIO qdisc itself will have minor number 0, band 0 is actually
++major:1, band 1 is major:2, etc. For major, substitute the major number
++assigned to the qdisc on 'tc qdisc add' with the
++.B handle
++parameter.
++
++.SH CLASSIFICATION
++Three methods are available to PRIO to determine in which band a packet will
++be enqueued.
++.TP
++From userspace
++A process with sufficient privileges can encode the destination class
++directly with SO_PRIORITY, see
++.BR tc(7).
++.TP 
++with a tc filter
++A tc filter attached to the root qdisc can point traffic directly to a class
++.TP 
++with the priomap
++Based on the packet priority, which in turn is derived from the Type of
++Service assigned to the packet.
++.P
++Only the priomap is specific to this qdisc. 
++.SH QDISC PARAMETERS
++.TP
++bands
++Number of bands. If changed from the default of 3,
++.B priomap
++must be updated as well.
++.TP 
++priomap
++The priomap maps the priority of
++a packet to a class. The priority can either be set directly from userspace,
++or be derived from the Type of Service of the packet.
++
++Determines how packet priorities, as assigned by the kernel, map to
++bands. Mapping occurs based on the TOS octet of the packet, which looks like
++this:
++
++.nf
++0   1   2   3   4   5   6   7
+++---+---+---+---+---+---+---+---+
++|           |               |   |
++|PRECEDENCE |      TOS      |MBZ|
++|           |               |   |
+++---+---+---+---+---+---+---+---+
++.fi
++
++The four TOS bits (the 'TOS field') are defined as:
++
++.nf
++Binary Decimcal  Meaning
++-----------------------------------------
++1000   8         Minimize delay (md)
++0100   4         Maximize throughput (mt)
++0010   2         Maximize reliability (mr)
++0001   1         Minimize monetary cost (mmc)
++0000   0         Normal Service
++.fi
++
++As there is 1 bit to the right of these four bits, the actual value of the
++TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the
++value of the entire TOS field, not just the four bits. It is the value you
++see in the first column of this table:
++
++.nf
++TOS     Bits  Means                    Linux Priority    Band
++------------------------------------------------------------
++0x0     0     Normal Service           0 Best Effort     1
++0x2     1     Minimize Monetary Cost   1 Filler          2
++0x4     2     Maximize Reliability     0 Best Effort     1
++0x6     3     mmc+mr                   0 Best Effort     1
++0x8     4     Maximize Throughput      2 Bulk            2
++0xa     5     mmc+mt                   2 Bulk            2
++0xc     6     mr+mt                    2 Bulk            2
++0xe     7     mmc+mr+mt                2 Bulk            2
++0x10    8     Minimize Delay           6 Interactive     0
++0x12    9     mmc+md                   6 Interactive     0
++0x14    10    mr+md                    6 Interactive     0
++0x16    11    mmc+mr+md                6 Interactive     0
++0x18    12    mt+md                    4 Int. Bulk       1
++0x1a    13    mmc+mt+md                4 Int. Bulk       1
++0x1c    14    mr+mt+md                 4 Int. Bulk       1
++0x1e    15    mmc+mr+mt+md             4 Int. Bulk       1
++.fi
++
++The second column contains the value of the relevant
++four TOS bits, followed by their translated meaning. For example, 15 stands
++for a packet wanting Minimal Montetary Cost, Maximum Reliability, Maximum
++Throughput AND Minimum Delay. 
++
++The fourth column lists the way the Linux kernel interprets the TOS bits, by
++showing to which Priority they are mapped.
++
++The last column shows the result of the default priomap. On the commandline,
++the default priomap looks like this:
++
++    1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
++
++This means that priority 4, for example, gets mapped to band number 1.
++The priomap also allows you to list higher priorities (> 7) which do not
++correspond to TOS mappings, but which are set by other means.
++
++This table from RFC 1349 (read it for more details) explains how
++applications might very well set their TOS bits:
++
++.nf
++TELNET                   1000           (minimize delay)
++FTP
++        Control          1000           (minimize delay)
++        Data             0100           (maximize throughput)
++
++TFTP                     1000           (minimize delay)
++
++SMTP 
++        Command phase    1000           (minimize delay)
++        DATA phase       0100           (maximize throughput)
++
++Domain Name Service
++        UDP Query        1000           (minimize delay)
++        TCP Query        0000
++        Zone Transfer    0100           (maximize throughput)
++
++NNTP                     0001           (minimize monetary cost)
++
++ICMP
++        Errors           0000
++        Requests         0000 (mostly)
++        Responses        <same as request> (mostly)
++.fi
++
++
++.SH CLASSES
++PRIO classes cannot be configured further - they are automatically created
++when the PRIO qdisc is attached. Each class however can contain yet a
++further qdisc.
++
++.SH BUGS
++Large amounts of traffic in the lower bands can cause starvation of higher
++bands. Can be prevented by attaching a shaper (for example, 
++.BR tc-tbf(8)
++to these bands to make sure they cannot dominate the link.
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>,  J Hadi Salim
++<hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-red.8 iproute2/debian/manpages/tc-red.8
+--- iproute2-orig/debian/manpages/tc-red.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-red.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,131 @@
++.TH RED 8 "13 December 2001" "iproute2" "Linux"
++.SH NAME
++red \- Random Early Detection 
++.SH SYNOPSIS
++.B tc qdisc ... red
++.B limit 
++bytes
++.B min 
++bytes 
++.B max 
++bytes 
++.B avpkt
++bytes
++.B burst 
++packets
++.B [ ecn ] [ bandwidth
++rate
++.B ] probability
++chance
++
++.SH DESCRIPTION
++Random Early Detection is a classless qdisc which manages its queue size
++smartly. Regular queues simply drop packets from the tail when they are
++full, which may not be the optimal behaviour. RED also performs tail drop,
++but does so in a more gradual way.
++
++Once the queue hits a certain average length, packets enqueued have a
++configurable chance of being marked (which may mean dropped). This chance
++increases linearly up to a point called the
++.B max
++average queue length, although the queue might get bigger.
++
++This has a host of benefits over simple taildrop, while not being processor
++intensive. It prevents synchronous retransmits after a burst in traffic,
++which cause further retransmits, etc.
++
++The goal is the have a small queue size, which is good for interactivity
++while not disturbing TCP/IP traffic with too many sudden drops after a burst
++of traffic.
++
++Depending on if ECN is configured, marking either means dropping or
++purely marking a packet as overlimit.
++.SH ALGORITHM
++The average queue size is used for determining the marking
++probability. This is calculated using an Exponential Weighted Moving
++Average, which can be more or less sensitive to bursts.
++
++When the average queue size is below 
++.B min
++bytes, no packet will ever be marked. When it exceeds 
++.B min, 
++the probability of doing so climbs linearly up
++to 
++.B probability, 
++until the average queue size hits
++.B max
++bytes. Because 
++.B probability 
++is normally not set to 100%, the queue size might
++conceivably rise above 
++.B max
++bytes, so the 
++.B limit
++parameter is provided to set a hard maximum for the size of the queue.
++
++.SH PARAMETERS
++.TP 
++min
++Average queue size at which marking becomes a possibility.
++.TP 
++max
++At this average queue size, the marking probability is maximal. Should be at
++least twice
++.B min
++to prevent synchronous retransmits, higher for low 
++.B min.
++.TP 
++probability
++Maximum probability for marking, specified as a floating point
++number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
++respectively).
++.TP 
++limit
++Hard limit on the real (not average) queue size in bytes. Further packets
++are dropped. Should be set higher than max+burst. It is advised to set this
++a few times higher than 
++.B max.
++.TP
++burst
++Used for determining how fast the average queue size is influenced by the
++real queue size. Larger values make the calculation more sluggish, allowing
++longer bursts of traffic before marking starts. Real life experiments
++support the following guideline: (min+min+max)/(3*avpkt).
++.TP 
++avpkt
++Specified in bytes. Used with burst to determine the time constant for
++average queue size calculations. 1000 is a good value.
++.TP
++bandwidth
++This rate is used for calculating the average queue size after some
++idle time. Should be set to the bandwidth of your interface. Does not mean
++that RED will shape for you! Optional.
++.TP
++ecn
++As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion
++Notification allows RED to notify remote hosts that their rate exceeds the
++amount of bandwidth available. Non-ECN capable hosts can only be notified by
++dropping a packet.  If this parameter is specified, packets which indicate
++that their hosts honor ECN will only be marked and not dropped, unless the
++queue size hits
++.B limit
++bytes. Needs a tc binary with RED support compiled in. Recommended.
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH SOURCES
++.TP 
++o
++Floyd, S., and Jacobson, V., Random Early Detection gateways for
++Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html
++.TP 
++o
++Some changes to the algorithm by Alexey N. Kuznetsov.
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>,  Alexey Makarenko
++<makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>.  
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-sfq.8 iproute2/debian/manpages/tc-sfq.8
+--- iproute2-orig/debian/manpages/tc-sfq.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-sfq.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,107 @@
++.TH TC 8 "8 December 2001" "iproute2" "Linux"
++.SH NAME
++sfq \- Stochastic Fairness Queueing
++.SH SYNOPSIS
++.B tc qdisc ... perturb
++seconds
++.B quantum
++bytes
++
++.SH DESCRIPTION
++
++Stochastic Fairness Queueing is a classless queueing discipline available for
++traffic control with the 
++.BR tc (8)
++command.
++
++SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'. 
++The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing
++any single flow from drowning out the rest.
++
++This may in fact have some effect in mitigating a Denial of Service attempt.
++
++SFQ is work-conserving and therefore always delivers a packet if it has one available.
++.SH ALGORITHM
++On enqueueing, each packet is assigned to a hash bucket, based on
++.TP
++(i)
++Source address
++.TP
++(ii)
++Destination address
++.TP
++(iii)
++Source port
++.P
++If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP. 
++Packets with other protocols are hashed based on the 32bits representation of their 
++destination and the socket they belong to. A flow corresponds mostly to a TCP/IP 
++connection.
++
++Each of these buckets should represent a unique flow. Because multiple flows may
++get hashed to the same bucket, the hashing algorithm is perturbed at configurable 
++intervals so that the unfairness lasts only for a short while. Perturbation may 
++however cause some inadvertent packet reordering to occur.
++
++When dequeuing, each hashbucket with data is queried in a round robin fashion.
++
++The compile time maximum length of the SFQ is 128 packets, which can be spread over
++at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed
++on the fullest bucket, thus maintaining fairness.
++
++.SH PARAMETERS
++.TP 
++perturb
++Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that 
++no perturbation occurs. Do not set too low for each perturbation may cause some packet
++reordering. Advised value: 10
++.TP 
++quantum
++Amount of bytes a flow is allowed to dequeue during a round of the round robin process.
++Defaults to the MTU of the interface which is also the advised value and the minimum value.
++
++.SH EXAMPLE & USAGE
++
++To attach to device ppp0:
++.P
++# tc qdisc add dev ppp0 root sfq perturb 10
++.P
++Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful 
++if it owns the queue.
++This is the case when the link speed equals the actually available bandwidth. This holds 
++for regular phone modems, ISDN connections and direct non-switched ethernet links. 
++.P
++Most often, cable modems and DSL devices do not fall into this category. The same holds 
++for when connected to a switch  and trying to send data to a congested segment also 
++connected to the switch.
++.P
++In this case, the effective queue does not reside within Linux and is therefore not 
++available for scheduling.
++.P
++Embed SFQ in a classful qdisc to make sure it owns the queue.
++
++.SH SOURCE
++.TP 
++o
++Paul E. McKenney "Stochastic Fairness Queuing",
++IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.
++
++.TP
++o
++Paul E. McKenney "Stochastic Fairness Queuing",
++"Interworking: Research and Experience", v.2, 1991, p.113-131.
++
++.TP 
++o
++See also:
++M. Shreedhar and George Varghese "Efficient Fair
++Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc-tbf.8 iproute2/debian/manpages/tc-tbf.8
+--- iproute2-orig/debian/manpages/tc-tbf.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc-tbf.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,138 @@
++.TH TC 8 "13 December 2001" "iproute2" "Linux"
++.SH NAME
++tbf \- Token Bucket Filter
++.SH SYNOPSIS
++.B tc qdisc ... tbf rate
++rate
++.B burst
++bytes/cell
++.B ( latency 
++ms 
++.B | limit
++bytes
++.B ) [ mpu 
++bytes
++.B [ peakrate
++rate
++.B mtu
++bytes/cell
++.B ] ]
++.P
++burst is also known as buffer and maxburst. mtu is also known as minburst.
++.SH DESCRIPTION
++
++The Token Bucket Filter is a classless queueing discipline available for
++traffic control with the 
++.BR tc (8)
++command.
++
++TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle
++itself, although packets are available, to ensure that the configured rate is not exceeded. 
++On all platforms except for Alpha,
++it is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness, 
++sending out  data exactly at the configured rates. 
++
++Much higher rates are possible but at the cost of losing the minimal burstiness. In that
++case, data is on average dequeued at the configured rate but may be sent much faster at millisecond 
++timescales. Because of further queues living in network adaptors, this is often not a problem.
++
++Kernels with a higher 'HZ' can achieve higher rates with perfect burstiness. On Alpha, HZ is ten
++times higher, leading to a 10mbit/s limit to perfection. These calculations hold for packets of on 
++average 1000 bytes.
++
++.SH ALGORITHM
++As the name implies, traffic is filtered based on the expenditure of 
++.B tokens.
++Tokens roughly correspond to bytes, with the additional constraint that each packet consumes
++some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies
++the link for some time.
++
++On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst 
++in one go. Tokens arrive at a steady rate, until the bucket is full.
++
++If no tokens are available, packets are queued, up to a configured limit. The TBF now 
++calculates the token deficit, and throttles until the first packet in the queue can be sent.
++
++If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured 
++to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF
++with a very small bucket, so that it doesn't burst.
++
++To achieve perfection, the second bucket may contain only a single packet, which leads to 
++the earlier mentioned 1mbit/s limit. 
++
++This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends
++on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100 
++packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.
++
++.SH PARAMETERS
++See 
++.BR tc (8)
++for how to specify the units of these values.
++.TP
++limit or latency
++Limit is the number of bytes that can be queued waiting for tokens to become
++available. You can also specify this the other way around by setting the
++latency parameter, which specifies the maximum amount of time a packet can
++sit in the TBF. The latter calculation takes into account the size of the
++bucket, the rate and possibly the peakrate (if set). These two parameters
++are mutually exclusive. 
++.TP
++burst
++Also known as buffer or maxburst.
++Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously. 
++In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer 
++if you want to reach your configured rate!
++
++If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
++The minimum buffer size can be calculated by dividing the rate by HZ.
++
++Token usage calculations are performed using a table which by default has a resolution of 8 packets. 
++This resolution can be changed by specifying the 
++.B cell
++size with the burst. For example, to specify a 6000 byte buffer with a 16
++byte cell size, set a burst of 6000/16. You will probably never have to set
++this. Must be an integral power of 2.
++.TP
++mpu
++A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit 
++determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
++.TP
++rate
++The speed knob. See remarks above about limits! See 
++.BR tc (8)
++for units.
++.PP
++Furthermore, if a peakrate is desired, the following parameters are available:
++
++.TP
++peakrate
++Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does 
++not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
++
++.TP
++mtu/minburst
++Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
++If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
++allows around 3mbit/s of peakrate, given 1000 byte packets.
++
++Like the regular burstsize you can also specify a 
++.B cell
++size.
++.SH EXAMPLE & USAGE
++
++To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s,
++a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes
++at most 70ms of latency, with perfect peakrate behaviour, issue:
++.P
++# tc qdisc add dev eth0 root tbf rate 0.5mbit \\
++  burst 5kb latency 70ms peakrate 1mbit       \\
++  minburst 1540
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/manpages/tc.8 iproute2/debian/manpages/tc.8
+--- iproute2-orig/debian/manpages/tc.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/manpages/tc.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,348 @@
++.TH TC 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++tc \- show / manipulate traffic control settings
++.SH SYNOPSIS
++.B tc qdisc [ add | change | replace | link ] dev 
++DEV 
++.B 
++[ parent 
++qdisc-id 
++.B | root ] 
++.B [ handle 
++qdisc-id ] qdisc
++[ qdisc specific parameters ]
++.P
++
++.B tc class [ add | change | replace ] dev
++DEV
++.B parent 
++qdisc-id 
++.B [ classid 
++class-id ] qdisc
++[ qdisc specific parameters ]
++.P
++
++.B tc filter [ add | change | replace ] dev
++DEV
++.B  [ parent
++qdisc-id
++.B | root ] protocol
++protocol
++.B prio
++priority filtertype
++[ filtertype specific parameters ]
++.B flowid
++flow-id
++
++.B tc [-s | -d ] qdisc show [ dev 
++DEV 
++.B  ]
++.P
++.B tc [-s | -d ] class show dev 
++DEV 
++.P
++.B tc filter show dev 
++DEV 
++
++.SH DESCRIPTION
++.B Tc
++is used to configure Traffic Control in the Linux kernel. Traffic Control consists 
++of the following:
++
++.TP 
++SHAPING
++When traffic is shaped, its rate of transmission is under control. Shaping may 
++be more than lowering the available bandwidth - it is also used to smooth out 
++bursts in traffic for better network behaviour. Shaping occurs on egress.
++
++.TP 
++SCHEDULING
++By scheduling the transmission of packets it is possible to improve interactivity
++for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
++is also called prioritizing, and happens only on egress.
++
++.TP
++POLICING
++Where shaping deals with transmission of traffic, policing pertains to traffic
++arriving. Policing thus occurs on ingress.
++
++.TP
++DROPPING
++Traffic exceeding a set bandwidth may also be dropped forthwith, both on 
++ingress and on egress.
++
++.P
++Processing of traffic is controlled by three kinds of objects: qdiscs, 
++classes and filters. 
++
++.SH QDISCS
++.B qdisc 
++is short for 'queueing discipline' and it is elementary to 
++understanding traffic control. Whenever the kernel needs to send a 
++packet to an interface, it is 
++.B enqueued
++to the qdisc configured for that interface. Immediately afterwards, the kernel
++tries to get as many packets as possible from the qdisc, for giving them
++to the network adaptor driver.
++
++A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure 
++First In, First Out queue. It does however store traffic when the network interface
++can't handle it momentarily.
++
++.SH CLASSES
++Some qdiscs can contain classes, which contain further qdiscs - traffic may 
++then be enqueued in any of the inner qdiscs, which are within the
++.B classes.
++When the kernel tries to dequeue a packet from such a 
++.B classful qdisc
++it can come from any of the classes. A qdisc may for example prioritize 
++certain kinds of traffic by trying to dequeue from certain classes
++before others.
++
++.SH FILTERS
++A
++.B filter
++is used by a classful qdisc to determine in which class a packet will
++be enqueued. Whenever traffic arrives at a class with subclasses, it needs
++to be classified. Various methods may be employed to do so, one of these
++are the filters. All filters attached to the class are called, until one of 
++them returns with a verdict. If no verdict was made, other criteria may be 
++available. This differs per qdisc.
++
++It is important to notice that filters reside 
++.B within
++qdiscs - they are not masters of what happens.
++
++.SH CLASSLESS QDISCS
++The classless qdiscs are:
++.TP 
++[p|b]fifo
++Simplest usable qdisc, pure First In, First Out behaviour. Limited in 
++packets or in bytes.
++.TP
++pfifo_fast
++Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
++queue which honors Type of Service flags, as well as the priority that may be 
++assigned to a packet.
++.TP
++red
++Random Early Detection simulates physical congestion by randomly dropping
++packets when nearing configured bandwidth allocation. Well suited to very
++large bandwidth applications.
++.TP 
++sfq
++Stochastic Fairness Queueing reorders queued traffic so each 'session'
++gets to send a packet in turn.
++.TP
++tbf
++The Token Bucket Filter is suited for slowing traffic down to a precisely
++configured rate. Scales well to large bandwidths. 
++.SH CONFIGURING CLASSLESS QDISCS
++In the absence of classful qdiscs, classless qdiscs can only be attached at 
++the root of a device. Full syntax:
++.P
++.B tc qdisc add dev 
++DEV 
++.B root 
++QDISC QDISC-PARAMETERS
++
++To remove, issue
++.P
++.B tc qdisc del dev
++DEV
++.B root
++
++The  
++.B pfifo_fast
++qdisc is the automatic default in the absence of a configured qdisc.
++
++.SH CLASSFUL QDISCS
++The classful qdiscs are:
++.TP
++CBQ
++Class Based Queueing implements a rich linksharing hierarchy of classes. 
++It contains shaping elements as well as prioritizing capabilities. Shaping is
++performed using link idle time calculations based on average packet size and
++underlying link bandwidth. The latter may be ill-defined for some interfaces.
++.TP
++HTB
++The Hierarchy Token Bucket implements a rich linksharing hierarchy of 
++classes with an emphasis on conforming to existing practices. HTB facilitates
++guaranteeing bandwidth to classes, while also allowing specification of upper
++limits to inter-class sharing. It contains shaping elements, based on TBF and
++can prioritize classes.	
++.TP 
++PRIO
++The PRIO qdisc is a non-shaping container for a configurable number of 
++classes which are dequeued in order. This allows for easy prioritization 
++of traffic, where lower classes are only able to send if higher ones have 
++no packets available. To facilitate configuration, Type Of Service bits are 
++honored by default.
++.SH THEORY OF OPERATION
++Classes form a tree, where each class has a single parent. 
++A class may have multiple children. Some qdiscs allow for runtime addition
++of classes (CBQ, HTB) while others (PRIO) are created with a static number of 
++children.
++
++Qdiscs which allow dynamic addition of classes can have zero or more 
++subclasses to which traffic may be enqueued. 
++
++Furthermore, each class contains a
++.B leaf qdisc
++which by default has 
++.B pfifo 
++behaviour though another qdisc can be attached in place. This qdisc may again 
++contain classes, but each class can have only one leaf qdisc. 
++
++When a packet enters a classful qdisc it can be 
++.B classified
++to one of the classes within. Three criteria are available, although not all 
++qdiscs will use all three:
++.TP 
++tc filters
++If tc filters are attached to a class, they are consulted first 
++for relevant instructions. Filters can match on all fields of a packet header, 
++as well as on the firewall mark applied by ipchains or iptables. See 
++.BR tc-filters (8).
++.TP
++Type of Service
++Some qdiscs have built in rules for classifying packets based on the TOS field.
++.TP
++skb->priority
++Userspace programs can encode a class-id in the 'skb->priority' field using 
++the SO_PRIORITY option.
++.P
++Each node within the tree can have its own filters but higher level filters
++may also point directly to lower classes.
++
++If classification did not succeed, packets are enqueued to the leaf qdisc 
++attached to that class. Check qdisc specific manpages for details, however.
++
++.SH NAMING
++All qdiscs, classes and filters have IDs, which can either be specified
++or be automatically assigned. 
++
++IDs consist of a major number and a minor number, separated by a colon.
++
++.TP 
++QDISCS
++A qdisc, which potentially can have children, 
++gets assigned a major number, called a 'handle', leaving the minor 
++number namespace available for classes. The handle is expressed as '10:'. 
++It is customary to explicitly assign a handle to qdiscs expected to have 
++children.
++
++.TP 
++CLASSES
++Classes residing under a qdisc share their qdisc major number, but each have
++a separate minor number called a 'classid' that has no relation to their 
++parent classes, only to their parent qdisc. The same naming custom as for 
++qdiscs applies.
++
++.TP 
++FILTERS
++Filters have a three part ID, which is only needed when using a hashed
++filter hierarchy, for which see
++.BR tc-filters (8).
++.SH UNITS
++All parameters accept a floating point number, possibly followed by a unit.
++.P
++Bandwidths or rates can be specified in:
++.TP 
++kbps
++Kilobytes per second
++.TP
++mbps
++Megabytes per second
++.TP
++kbit
++Kilobits per second
++.TP
++mbit
++Megabits per second
++.TP
++bps or a bare number
++Bytes per second
++.P
++Amounts of data can be specified in:
++.TP
++kb or k
++Kilobytes
++.TP
++mb or m
++Megabytes
++.TP
++mbit
++Megabits
++.TP
++kbit
++Kilobits
++.TP
++b or a bare number
++Bytes.
++.P
++Lengths of time can be specified in:
++.TP
++s, sec or secs
++Whole seconds
++.TP
++ms, msec or msecs
++Milliseconds
++.TP
++us, usec, usecs or a bare number
++Microseconds.
++
++.SH TC COMMANDS
++The following commands are available for qdiscs, classes and filter:
++.TP
++add
++Add a qdisc, class or filter to a node. For all entities, a 
++.B parent
++must be passed, either by passing its ID or by attaching directly to the root of a device. 
++When creating a qdisc or a filter, it can be named with the
++.B handle
++parameter. A class is named with the
++.B classid
++parameter.
++
++.TP
++remove
++A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs 
++are automatically deleted, as well as any filters attached to them.
++
++.TP
++change
++Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
++that the handle cannot be changed and neither can the parent. In other words, 
++.B
++change 
++cannot move a node.
++
++.TP
++replace
++Performs a nearly atomic remove/add on an existing node id. If the node does not exist yet
++it is created.
++
++.TP
++link
++Only available for qdiscs and performs a replace where the node 
++must exist already.
++
++
++.SH HISTORY
++.B tc
++was written by Alexey N. Kuznetsov and added in Linux 2.2.
++.SH SEE ALSO
++.BR tc-cbq (8),
++.BR tc-htb (8),
++.BR tc-sfq (8),
++.BR tc-red (8),
++.BR tc-tbf (8),
++.BR tc-pfifo (8),
++.BR tc-bfifo (8),
++.BR tc-pfifo_fast (8),
++.BR tc-filters (8)
++
++.SH AUTHOR
++Manpage maintained by bert hubert (ahu@ds9a.nl)
++
+diff -Naur iproute2-orig/debian/postinst iproute2/debian/postinst
+--- iproute2-orig/debian/postinst	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/postinst	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,6 @@
++#!/bin/sh -e
++
++# FHS:
++if [ "$1" = "configure" -a -d /usr/doc -a ! -e /usr/doc/iproute ]; then
++  ln -sf ../share/doc/iproute /usr/doc/iproute
++fi
+diff -Naur iproute2-orig/debian/postrm iproute2/debian/postrm
+--- iproute2-orig/debian/postrm	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/postrm	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,6 @@
++#!/bin/sh
++
++if [ "$1" = "purge" ]
++then
++  rm -rf /etc/iproute2
++fi
+diff -Naur iproute2-orig/debian/prerm iproute2/debian/prerm
+--- iproute2-orig/debian/prerm	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/prerm	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,5 @@
++#!/bin/sh -e
++
++if [ \( "$1" = "upgrade" -o "$1" = "remove" \) -a -L /usr/doc/iproute ]; then
++  rm -f /usr/doc/iproute
++fi
+diff -Naur iproute2-orig/debian/rules iproute2/debian/rules
+--- iproute2-orig/debian/rules	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/rules	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,85 @@
++#!/usr/bin/make -f
++#
++# Copyright (C) 1999 Roberto Lumbreras <rover@debian.org>
++# Copyright (C) 1999-2002 Juan Cespedes <cespedes@debian.org>
++# Copying: GPL
++
++SHELL	=	bash
++
++PACKAGE	=	$(shell perl -e 'print <> =~ /^(.*) \(.*\)/' debian/changelog)
++PKG_VER	=	$(shell perl -e 'print <> =~ /\((.*)\)/' debian/changelog)
++PKG_UPVER=	$(shell perl -e 'print <> =~ /\((.*)-[^-]*\)/' debian/changelog)
++
++BINS	=	ip/ip
++SBINS	=	ip/rtmon ip/rtacct tc/tc
++SHBINS	=	ip/routef ip/routel # ip/ifcfg ip/rtpr
++DOCS	=	README* doc/Plan debian/README.Debian
++MAN8	=	debian/manpages/*.8
++MANLINKS=	rtmon rtacct routef routel
++TEXDOCS	=	ip-cref ip-tunnels api-ip6-flowlabels
++
++build:		stamp-build
++
++stamp-build:
++		test -f include-glibc/netinet/in.h.orig || \
++			mv include-glibc/netinet/in.h \
++				include-glibc/netinet/in.h.orig
++		$(MAKE) KERNEL_INCLUDE=/usr/include
++		$(MAKE) -C doc
++		touch stamp-build
++
++binary:		binary-indep binary-arch
++
++binary-indep:
++
++binary-arch:	checkroot stamp-build
++		$(RM) -r debian/tmp
++		install -d -m0755 debian/tmp/{DEBIAN,bin,sbin,usr/{bin,share/doc/$(PACKAGE),share/man/man{7,8}}}
++		install -s -m0755 $(BINS) debian/tmp/bin/
++		install -s -m0755 $(SBINS) debian/tmp/sbin/
++		ln -s /bin/ip debian/tmp/sbin/ip
++		install -m0755 $(SHBINS) debian/tmp/usr/bin/
++		cp -p $(DOCS) debian/tmp/usr/share/doc/$(PACKAGE)/
++		cp -rp examples debian/tmp/usr/share/doc/$(PACKAGE)/
++		find debian/tmp/usr/share/doc/$(PACKAGE)/examples -type f -exec chmod -x {} \;
++		install -m0644 debian/changelog debian/tmp/usr/share/doc/$(PACKAGE)/changelog.Debian
++		cp -p RELNOTES debian/tmp/usr/share/doc/$(PACKAGE)/changelog
++		for i in $(TEXDOCS); do \
++			install -m0644 doc/$$i.tex debian/tmp/usr/share/doc/$(PACKAGE)/; \
++			install -m0644 doc/$$i.dvi debian/tmp/usr/share/doc/$(PACKAGE)/; \
++			install -m0644 doc/$$i.ps debian/tmp/usr/share/doc/$(PACKAGE)/; \
++		done
++		install -m0644 $(MAN8) debian/tmp/usr/share/man/man8/
++		gzip -9fr debian/tmp/usr/share || true
++		ln -s tc-pbfifo.8.gz debian/tmp/usr/share/man/man8/tc-pfifo.8.gz
++		ln -s tc-pbfifo.8.gz debian/tmp/usr/share/man/man8/tc-bfifo.8.gz
++		for i in $(MANLINKS); do \
++			ln -s ../man7/undocumented.7.gz debian/tmp/usr/share/man/man8/$$i.8.gz; \
++		done
++		cp -p debian/copyright debian/tmp/usr/share/doc/$(PACKAGE)/
++		cp -rp etc debian/tmp/
++		install -m0644 debian/conffiles debian/tmp/DEBIAN/
++
++		dpkg-shlibdeps $(BINS) $(SBINS)
++		dpkg-gencontrol -isp
++		chown -R root.root debian/tmp
++		chmod -R u=rwX,go=rX debian/tmp
++		dpkg --build debian/tmp ..
++
++checkdir:
++		@test -f debian/rules
++
++checkroot:	checkdir
++		@test 0 = `id -u` || { echo "Error: not super-user"; exit 1; }
++
++clean:		checkdir debian/control
++		$(RM) stamp-build debian/files debian/substvars
++		$(MAKE) clean
++		$(MAKE) -C doc clean
++		$(RM) `find . -name "*~" -o -name core`
++		$(RM) -r debian/tmp
++		test -f include-glibc/netinet/in.h.orig && \
++			mv include-glibc/netinet/in.h.orig \
++				include-glibc/netinet/in.h || true
++
++.PHONY: build binary binary-arch binary-indep checkdir checkroot clean
+diff -Naur iproute2-orig/debian/tc-cbq.8 iproute2/debian/tc-cbq.8
+--- iproute2-orig/debian/tc-cbq.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-cbq.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,353 @@
++.TH CBQ 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++CBQ \- Class Based Queueing
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] cbq [ allot 
++bytes
++.B ] avpkt
++bytes
++.B bandwidth
++rate
++.B [ cell 
++bytes
++.B ] [ ewma
++log
++.B ] [ mpu
++bytes
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] cbq allot
++bytes
++.B [ bandwidth 
++rate 
++.B ] [ rate 
++rate
++.B ] prio
++priority
++.B [ weight
++weight
++.B ] [ minburst 
++packets
++.B ] [ maxburst 
++packets 
++.B ] [ ewma 
++log
++.B ] [ cell
++bytes
++.B ] avpkt
++bytes
++.B [ mpu
++bytes 
++.B ] [ bounded isolated ] [ split
++handle
++.B & defmap
++defmap
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++Class Based Queueing is a classful qdisc that implements a rich
++linksharing hierarchy of classes.  It contains shaping elements as
++well as prioritizing capabilities.  Shaping is performed using link
++idle time calculations based on the timing of dequeue events and 
++underlying link bandwidth.
++
++.SH SHAPING ALGORITHM
++When shaping a 10mbit/s connection to 1mbit/s, the link will
++be idle 90% of the time. If it isn't, it needs to be throttled so that it
++IS idle 90% of the time.
++
++During operations, the effective idletime is measured using an
++exponential weighted moving average (EWMA), which considers recent
++packets to be exponentially more important than past ones. The Unix
++loadaverage is calculated in the same way.
++
++The calculated idle time is subtracted from the EWMA measured one,
++the resulting number is called 'avgidle'. A perfectly loaded link has
++an avgidle of zero: packets arrive exactly at the calculated
++interval.
++
++An overloaded link has a negative avgidle and if it gets too negative,
++CBQ throttles and is then 'overlimit'.
++
++Conversely, an idle link might amass a huge avgidle, which would then
++allow infinite bandwidths after a few hours of silence. To prevent
++this, avgidle is capped at 
++.B maxidle.
++
++If overlimit, in theory, the CBQ could throttle itself for exactly the
++amount of time that was calculated to pass between packets, and then
++pass one packet, and throttle again. Due to timer resolution constraints,
++this may not be feasible, see the 
++.B minburst
++parameter below.
++
++.SH CLASSIFICATION
++Within the one CBQ instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, CBQ starts at the root and uses various methods to 
++determine which class should receive the data. 
++
++In the absence of uncommon configuration options, the process is rather easy. 
++At each node we look for an instruction, and then go to the class the 
++instruction refers us to. If the class found is a barren leaf-node (without 
++children), we enqueue the packet there. If it is not yet a leaf node, we do 
++the whole thing over again starting from that node. 
++
++The following actions are performed, in order at each node we visit, until one 
++sends us to another node, or terminates the process.
++.TP
++(i)
++Consult filters attached to the class. If sent to a leafnode, we are done. 
++Otherwise, restart.
++.TP
++(ii)
++Consult the defmap for the priority assigned to this packet, which depends 
++on the TOS bits. Check if the referral is leafless, otherwise restart.
++.TP
++(iii)
++Ask the defmap for instructions for the 'best effort' priority. Check the 
++answer for leafness, otherwise restart.
++.TP
++(iv)
++If none of the above returned with an instruction, enqueue at this node.
++.P
++This algorithm makes sure that a packet always ends up somewhere, even while
++you are busy building your configuration. 
++
++For more details, see
++.BR tc-cbq-details(8).
++
++.SH LINK SHARING ALGORITHM
++When dequeuing for sending to the network device, CBQ decides which of its 
++classes will be allowed to send. It does so with a Weighted Round Robin process
++in which each class with packets gets a chance to send in turn. The WRR process
++starts by asking the highest priority classes (lowest numerically - 
++highest semantically) for packets, and will continue to do so until they
++have no more data to offer, in which case the process repeats for lower 
++priorities.
++
++Classes by default borrow bandwidth from their siblings. A class can be 
++prevented from doing so by declaring it 'bounded'. A class can also indicate 
++its unwillingness to lend out bandwidth by being 'isolated'.
++
++.SH QDISC
++The root of a CBQ qdisc class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the CBQ instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional, but very useful if classes
++will be generated within this qdisc.
++.TP 
++allot bytes
++This allotment is the 'chunkiness' of link sharing and is used for determining packet
++transmission time tables. The qdisc allot differs slightly from the class allot discussed
++below. Optional. Defaults to a reasonable value, related to avpkt.
++.TP
++avpkt bytes
++The average size of a packet is needed for calculating maxidle, and is also used
++for making sure 'allot' has a safe value. Mandatory.
++.TP
++bandwidth rate
++To determine the idle time, CBQ must know the bandwidth of your underlying 
++physical interface, or parent qdisc. This is a vital parameter, more about it
++later. Mandatory.
++.TP
++cell
++The cell size determines he granularity of packet transmission time calculations. Has a sensible default.
++.TP 
++mpu
++A zero sized packet may still take time to transmit. This value is the lower
++cap for packet transmission time calculations - packets smaller than this value
++are still deemed to have this size. Defaults to zero.
++.TP
++ewma log
++When CBQ needs to measure the average idle time, it does so using an 
++Exponentially Weighted Moving Average which smoothes out measurements into
++a moving average. The EWMA LOG determines how much smoothing occurs. Lower 
++values imply greater sensitivity. Must be between 0 and 31. Defaults 
++to 5.
++.P
++A CBQ qdisc does not shape out of its own accord. It only needs to know certain
++parameters about the underlying link. Actual shaping is done in classes.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++weight weight
++When dequeuing to the interface, classes are tried for traffic in a 
++round-robin fashion. Classes with a higher configured qdisc will generally
++have more traffic to offer during each round, so it makes sense to allow
++it to dequeue more traffic. All weights under a class are normalized, so
++only the ratios matter. Defaults to the configured rate, unless the priority 
++of this class is maximal, in which case it is set to 1.
++.TP 
++allot bytes
++Allot specifies how many bytes a qdisc can dequeue
++during each round of the process. This parameter is weighted using the 
++renormalized class weight described above. Silently capped at a minimum of
++3/2 avpkt. Mandatory.
++
++.TP 
++prio priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++avpkt
++See the QDISC section.
++
++.TP 
++rate rate
++Maximum rate this class and all its children combined can send at. Mandatory.
++
++.TP
++bandwidth rate
++This is different from the bandwidth specified when creating a CBQ disc! Only
++used to determine maxidle and offtime, which are only calculated when
++specifying maxburst or minburst. Mandatory if specifying maxburst or minburst.
++
++.TP 
++maxburst
++This number of packets is used to calculate maxidle so that when
++avgidle is at maxidle, this number of average packets can be burst
++before avgidle drops to 0. Set it higher to be more tolerant of
++bursts. You can't set maxidle directly, only via this parameter.
++
++.TP
++minburst 
++As mentioned before, CBQ needs to throttle in case of
++overlimit. The ideal solution is to do so for exactly the calculated
++idle time, and pass 1 packet. However, Unix kernels generally have a
++hard time scheduling events shorter than 10ms, so it is better to
++throttle for a longer period, and then pass minburst packets in one
++go, and then sleep minburst times longer.
++
++The time to wait is called the offtime. Higher values of minburst lead
++to more accurate shaping in the long term, but to bigger bursts at
++millisecond timescales. Optional.
++
++.TP
++minidle
++If avgidle is below 0, we are overlimits and need to wait until
++avgidle will be big enough to send one packet. To prevent a sudden
++burst from shutting down the link for a prolonged period of time,
++avgidle is reset to minidle if it gets too low.
++
++Minidle is specified in negative microseconds, so 10 means that
++avgidle is capped at -10us. Optional.
++
++.TP
++bounded 
++Signifies that this class will not borrow bandwidth from its siblings.
++.TP 
++isolated
++Means that this class will not borrow bandwidth to its siblings
++
++.TP 
++split major:minor & defmap bitmap[/bitmap]
++If consulting filters attached to a class did not give a verdict, 
++CBQ can also classify based on the packet's priority. There are 16
++priorities available, numbered from 0 to 15. 
++
++The defmap specifies which priorities this class wants to receive, 
++specified as a bitmap. The Least Significant Bit corresponds to priority 
++zero. The 
++.B split
++parameter tells CBQ at which class the decision must be made, which should
++be a (grand)parent of the class you are adding.
++
++As an example, 'tc class add ... classid 10:1 cbq .. split 10:0 defmap c0'
++configures class 10:0 to send packets with priorities 6 and 7 to 10:1.
++
++The complimentary configuration would then 
++be: 'tc class add ... classid 10:2 cbq ... split 10:0 defmap 3f'
++Which would send all packets 0, 1, 2, 3, 4 and 5 to 10:1.
++.TP
++estimator interval timeconstant
++CBQ can measure how much bandwidth each class is using, which tc filters
++can use to classify packets with. In order to determine the bandwidth
++it uses a very simple estimator that measures once every
++.B interval
++microseconds how much traffic has passed. This again is a EWMA, for which
++the time constant can be specified, also in microseconds. The 
++.B time constant
++corresponds to the sluggishness of the measurement or, conversely, to the 
++sensitivity of the average to short bursts. Higher values mean less
++sensitivity. 
++
++.SH BUGS
++The actual bandwidth of the underlying link may not be known, for example 
++in the case of PPoE or PPTP connections which in fact may send over a 
++pipe, instead of over a physical device. CBQ is quite resilient to major
++errors in the configured bandwidth, probably a the cost of coarser shaping.
++
++Default kernels rely on coarse timing information for making decisions. These 
++may make shaping precise in the long term, but inaccurate on second long scales.
++
++See 
++.BR tc-cbq-details(8)
++for hints on how to improve this.
++
++.SH SOURCES
++.TP
++o
++Sally Floyd and Van Jacobson, "Link-sharing and Resource
++Management Models for Packet Networks",
++IEEE/ACM Transactions on Networking, Vol.3, No.4, 1995
++
++.TP 
++o
++Sally Floyd, "Notes on CBQ and Guaranteed Service", 1995
++
++.TP
++o
++Sally Floyd, "Notes on Class-Based Queueing: Setting
++Parameters", 1996
++
++.TP 
++o
++Sally Floyd and Michael Speer, "Experimental Results
++for Class-Based Queueing", 1998, not published.
++
++
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc-htb.8 iproute2/debian/tc-htb.8
+--- iproute2-orig/debian/tc-htb.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-htb.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,153 @@
++.TH HTB 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++HTB \- Hierarchy Token Bucket
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] htb [ default 
++minor-id
++.B ] 
++
++.B tc class ... dev
++dev
++.B parent 
++major:[minor]
++.B [ classid 
++major:minor
++.B ] htb rate
++rate
++.B [ ceil
++rate 
++.B ] burst 
++bytes
++.B [ cburst
++bytes
++.B ] [ prio
++priority
++.B ] 
++
++.SH DESCRIPTION
++HTB is meant as a more understandable and intuitive replacement for
++the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
++of the outbound bandwidth on a given link. Both allow you to use one
++physical link to simulate several slower links and to send different
++kinds of traffic on different simulated links. In both cases, you have
++to specify how to divide the physical link into simulated links and
++how to decide which simulated link to use for a given packet to be sent. 
++
++Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm 
++which does not depend on interface characteristics and so does not need to
++know the underlying bandwidth of the outgoing interface.
++
++.SH SHAPING ALGORITHM
++Shaping works as documented in
++.B tc-tbf (8).
++
++.SH CLASSIFICATION
++Within the one HRB instance many classes may exist. Each of these classes
++contains another qdisc, by default 
++.BR tc-pfifo (8).
++
++When enqueueing a packet, HTB starts at the root and uses various methods to 
++determine which class should receive the data. 
++
++In the absence of uncommon configuration options, the process is rather easy. 
++At each node we look for an instruction, and then go to the class the 
++instruction refers us to. If the class found is a barren leaf-node (without 
++children), we enqueue the packet there. If it is not yet a leaf node, we do 
++the whole thing over again starting from that node. 
++
++The following actions are performed, in order at each node we visit, until one 
++sends us to another node, or terminates the process.
++.TP
++(i)
++Consult filters attached to the class. If sent to a leafnode, we are done. 
++Otherwise, restart.
++.TP
++(ii)
++If none of the above returned with an instruction, enqueue at this node.
++.P
++This algorithm makes sure that a packet always ends up somewhere, even while
++you are busy building your configuration. 
++
++.SH LINK SHARING ALGORITHM
++FIXME
++
++.SH QDISC
++The root of a CBQ qdisc class tree has the following parameters:
++
++.TP 
++parent major:minor | root
++This mandatory parameter determines the place of the CBQ instance, either at the
++.B root
++of an interface or within an existing class.
++.TP
++handle major:
++Like all other qdiscs, the CBQ can be assigned a handle. Should consist only
++of a major number, followed by a colon. Optional, but very useful if classes
++will be generated within this qdisc.
++.TP 
++default minor-id
++Unclassified traffic gets sent to the class with this minor-id.
++
++.SH CLASSES
++Classes have a host of parameters to configure their operation.
++
++.TP 
++parent major:minor
++Place of this class within the hierarchy. If attached directly to a qdisc 
++and not to another class, minor can be omitted. Mandatory.
++.TP 
++classid major:minor
++Like qdiscs, classes can be named. The major number must be equal to the
++major number of the qdisc to which it belongs. Optional, but needed if this 
++class is going to have children.
++.TP 
++prio priority
++In the round-robin process, classes with the lowest priority field are tried 
++for packets first. Mandatory.
++
++.TP 
++rate rate
++Maximum rate this class and all its children are guaranteed. Mandatory.
++
++.TP
++ceil rate
++Maximum rate at which a class can send, if its parent has bandwidth to spare. 
++Defaults to the configured rate, which implies no borrowing
++
++.TP 
++burst bytes
++Amount of bytes that can be burst at 
++.B ceil
++speed, in excess of the configured
++.B rate. 
++Should be at least as high as the highest burst of all children.
++
++.TP 
++cburst bytes
++Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
++as the interface can transmit them. For perfect evening out, should be equal to at most one average
++packet. Should be at least as high as the highest cburst of all children.
++
++.SH NOTES
++Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel, 
++there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
++From this, the mininum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte 
++burst as 100*12kb*8 equals 10mbit.
++
++.SH BUGS
++Not in the stock kernel yet.
++
++.SH SEE ALSO
++.BR tc (8)
++.P
++HTB website: http://luxik.cdi.cz/~devik/qos/htb/
++.SH AUTHOR
++Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc-pbfifo.8 iproute2/debian/tc-pbfifo.8
+--- iproute2-orig/debian/tc-pbfifo.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-pbfifo.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,72 @@
++.TH PBFIFO 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++pfifo \- Packet limited First In, First Out queue
++.P
++bfifo \- Byte limited First In, First Out queue
++
++.SH SYNOPSIS
++.B tc qdisc ... add pfifo
++.B [ limit 
++packets
++.B ]
++.P
++.B tc qdisc ... add bfifo
++.B [ limit 
++bytes
++.B ]
++
++.SH DESCRIPTION
++The pfifo and bfifo qdiscs are unadorned First In, First Out queues. They are the
++simplest queues possible and therefore have no overhead. 
++.B pfifo
++constrains the queue size as measured in packets. 
++.B bfifo
++does so as measured in bytes.
++
++Like all non-default qdiscs, they maintain statistics. This might be a reason to prefer 
++pfifo or bfifo over the default.
++
++.SH ALGORITHM
++A list of packets is maintained, when a packet is enqueued it gets inserted at the tail of
++a list. When a packet needs to be sent out to the network, it is taken from the head of the list. 
++
++If the list is too long, no further packets are allowed on. This is called 'tail drop'.
++
++.SH PARAMETERS
++.TP 
++limit
++Maximum queue size. Specified in bytes for bfifo, in packets for pfifo. For pfifo, defaults 
++to the interface txqueuelen, as specified with 
++.BR ifconfig (8)
++or
++.BR ip (8).
++
++For bfifo, it defaults to the txqueuelen multiplied by the interface MTU.
++
++.SH OUTPUT
++The output of 
++.B tc -s qdisc ls
++contains the limit, either in packets or in bytes, and the number of bytes 
++and packets actually sent. An unsent and dropped packet only appears between braces 
++and is not counted as 'Sent'.
++
++In this example, the queue length is 100 packets, 45894 bytes were sent over 681 packets. 
++No packets were dropped, and as the pfifo queue does not slow down packets, there were also no
++overlimits:
++.P
++.nf
++# tc -s qdisc ls dev eth0 
++qdisc pfifo 8001: dev eth0 limit 100p
++ Sent 45894 bytes 681 pkts (dropped 0, overlimits 0) 
++.fi
++
++If a backlog occurs, this is displayed as well.
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
++
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc-pfifo_fast.8 iproute2/debian/tc-pfifo_fast.8
+--- iproute2-orig/debian/tc-pfifo_fast.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-pfifo_fast.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,59 @@
++.TH PFIFO_FAST 8 "10 January 2002" "iproute2" "Linux"
++.SH NAME
++pfifo_fast \- three-band first in, first out queue
++
++.SH DESCRIPTION
++pfifo_fast is the default qdisc of each interface.
++
++Whenever an interface is created, the pfifo_fast qdisc is automatically used
++as a queue. If another qdisc is attached, it preempts the default
++pfifo_fast, which automatically returns to function when an existing qdisc
++is detached.
++
++In this sense this qdisc is magic, and unlike other qdiscs.
++
++.SH ALGORITHM
++The algorithm is very similar to that of the classful 
++.BR tc-prio (8)
++qdisc. 
++.B pfifo_fast
++is like three
++.BR tc-pfifo (8)
++queues side by side, where packets can be enqueued in any of the three bands
++based on their Type of Service bits or assigned priority. 
++
++Not all three bands are dequeued simultaneously - as long as lower bands
++have traffic, higher bands are never dequeued. This can be used to
++prioritize interactive traffic or penalize 'lowest cost' traffic.
++
++Each band can be txqueuelen packets long, as configured with
++.BR ifconfig (8)
++or 
++.BR ip (8).
++Additional packets coming in are not enqueued but are instead dropped.
++
++See
++.BR tc-prio (8)
++for complete details on how TOS bits are translated into bands.
++.SH PARAMETERS
++.TP 
++txqueuelen
++The length of the three bands depends on the interface txqueuelen, as
++specified with
++.BR ifconfig (8)
++or
++.BR ip (8).
++
++.SH BUGS
++Does not maintain statistics and does not show up in tc qdisc ls. This is because
++it is the automatic default in the absence of a configured qdisc. 
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>
++
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc-prio.8 iproute2/debian/tc-prio.8
+--- iproute2-orig/debian/tc-prio.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-prio.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,187 @@
++.TH PRIO 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++PRIO \- Priority qdisc
++.SH SYNOPSIS
++.B tc qdisc ... dev
++dev
++.B  ( parent
++classid 
++.B | root) [ handle 
++major: 
++.B ] prio [ bands 
++bands
++.B ] [ priomap
++band,band,band... 
++.B ] [ estimator 
++interval timeconstant
++.B ]
++
++.SH DESCRIPTION
++The PRIO qdisc is a simple classful queueing discipline that contains
++an arbitrary number of classes of differing priority. The classes are
++dequeued in numerical descending order of priority. PRIO is a scheduler 
++and never delays packets - it is a work-conserving qdisc, though the qdiscs
++contained in the classes may not be.
++
++Very useful for lowering latency when there is no need for slowing down
++traffic.
++
++.SH ALGORITHM
++On creation with 'tc qdisc add', a fixed number of bands is created. Each
++band is a class, although is not possible to add classes with 'tc qdisc
++add', the number of bands to be created must instead be specified on the
++commandline attaching PRIO to its root.
++
++When dequeueing, band 0 is tried first and only if it did not deliver a
++packet does PRIO try band 1, and so onwards. Maximum reliability packets
++should therefore go to band 0, minimum delay to band 1 and the rest to band
++2.
++
++As the PRIO qdisc itself will have minor number 0, band 0 is actually
++major:1, band 1 is major:2, etc. For major, substitute the major number
++assigned to the qdisc on 'tc qdisc add' with the
++.B handle
++parameter.
++
++.SH CLASSIFICATION
++Three methods are available to PRIO to determine in which band a packet will
++be enqueued.
++.TP
++From userspace
++A process with sufficient privileges can encode the destination class
++directly with SO_PRIORITY, see
++.BR tc(7).
++.TP 
++with a tc filter
++A tc filter attached to the root qdisc can point traffic directly to a class
++.TP 
++with the priomap
++Based on the packet priority, which in turn is derived from the Type of
++Service assigned to the packet.
++.P
++Only the priomap is specific to this qdisc. 
++.SH QDISC PARAMETERS
++.TP
++bands
++Number of bands. If changed from the default of 3,
++.B priomap
++must be updated as well.
++.TP 
++priomap
++The priomap maps the priority of
++a packet to a class. The priority can either be set directly from userspace,
++or be derived from the Type of Service of the packet.
++
++Determines how packet priorities, as assigned by the kernel, map to
++bands. Mapping occurs based on the TOS octet of the packet, which looks like
++this:
++
++.nf
++0   1   2   3   4   5   6   7
+++---+---+---+---+---+---+---+---+
++|           |               |   |
++|PRECEDENCE |      TOS      |MBZ|
++|           |               |   |
+++---+---+---+---+---+---+---+---+
++.fi
++
++The four TOS bits (the 'TOS field') are defined as:
++
++.nf
++Binary Decimcal  Meaning
++-----------------------------------------
++1000   8         Minimize delay (md)
++0100   4         Maximize throughput (mt)
++0010   2         Maximize reliability (mr)
++0001   1         Minimize monetary cost (mmc)
++0000   0         Normal Service
++.fi
++
++As there is 1 bit to the right of these four bits, the actual value of the
++TOS field is double the value of the TOS bits. Tcpdump -v -v shows you the
++value of the entire TOS field, not just the four bits. It is the value you
++see in the first column of this table:
++
++.nf
++TOS     Bits  Means                    Linux Priority    Band
++------------------------------------------------------------
++0x0     0     Normal Service           0 Best Effort     1
++0x2     1     Minimize Monetary Cost   1 Filler          2
++0x4     2     Maximize Reliability     0 Best Effort     1
++0x6     3     mmc+mr                   0 Best Effort     1
++0x8     4     Maximize Throughput      2 Bulk            2
++0xa     5     mmc+mt                   2 Bulk            2
++0xc     6     mr+mt                    2 Bulk            2
++0xe     7     mmc+mr+mt                2 Bulk            2
++0x10    8     Minimize Delay           6 Interactive     0
++0x12    9     mmc+md                   6 Interactive     0
++0x14    10    mr+md                    6 Interactive     0
++0x16    11    mmc+mr+md                6 Interactive     0
++0x18    12    mt+md                    4 Int. Bulk       1
++0x1a    13    mmc+mt+md                4 Int. Bulk       1
++0x1c    14    mr+mt+md                 4 Int. Bulk       1
++0x1e    15    mmc+mr+mt+md             4 Int. Bulk       1
++.fi
++
++The second column contains the value of the relevant
++four TOS bits, followed by their translated meaning. For example, 15 stands
++for a packet wanting Minimal Montetary Cost, Maximum Reliability, Maximum
++Throughput AND Minimum Delay. 
++
++The fourth column lists the way the Linux kernel interprets the TOS bits, by
++showing to which Priority they are mapped.
++
++The last column shows the result of the default priomap. On the commandline,
++the default priomap looks like this:
++
++    1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1
++
++This means that priority 4, for example, gets mapped to band number 1.
++The priomap also allows you to list higher priorities (> 7) which do not
++correspond to TOS mappings, but which are set by other means.
++
++This table from RFC 1349 (read it for more details) explains how
++applications might very well set their TOS bits:
++
++.nf
++TELNET                   1000           (minimize delay)
++FTP
++        Control          1000           (minimize delay)
++        Data             0100           (maximize throughput)
++
++TFTP                     1000           (minimize delay)
++
++SMTP 
++        Command phase    1000           (minimize delay)
++        DATA phase       0100           (maximize throughput)
++
++Domain Name Service
++        UDP Query        1000           (minimize delay)
++        TCP Query        0000
++        Zone Transfer    0100           (maximize throughput)
++
++NNTP                     0001           (minimize monetary cost)
++
++ICMP
++        Errors           0000
++        Requests         0000 (mostly)
++        Responses        <same as request> (mostly)
++.fi
++
++
++.SH CLASSES
++PRIO classes cannot be configured further - they are automatically created
++when the PRIO qdisc is attached. Each class however can contain yet a
++further qdisc.
++
++.SH BUGS
++Large amounts of traffic in the lower bands can cause starvation of higher
++bands. Can be prevented by attaching a shaper (for example, 
++.BR tc-tbf(8)
++to these bands to make sure they cannot dominate the link.
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>,  J Hadi Salim
++<hadi@cyberus.ca>. This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc-red.8 iproute2/debian/tc-red.8
+--- iproute2-orig/debian/tc-red.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-red.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,131 @@
++.TH RED 8 "13 December 2001" "iproute2" "Linux"
++.SH NAME
++red \- Random Early Detection 
++.SH SYNOPSIS
++.B tc qdisc ... red
++.B limit 
++bytes
++.B min 
++bytes 
++.B max 
++bytes 
++.B avpkt
++bytes
++.B burst 
++packets
++.B [ ecn ] [ bandwidth
++rate
++.B ] probability
++chance
++
++.SH DESCRIPTION
++Random Early Detection is a classless qdisc which manages its queue size
++smartly. Regular queues simply drop packets from the tail when they are
++full, which may not be the optimal behaviour. RED also performs tail drop,
++but does so in a more gradual way.
++
++Once the queue hits a certain average length, packets enqueued have a
++configurable chance of being marked (which may mean dropped). This chance
++increases linearly up to a point called the
++.B max
++average queue length, although the queue might get bigger.
++
++This has a host of benefits over simple taildrop, while not being processor
++intensive. It prevents synchronous retransmits after a burst in traffic,
++which cause further retransmits, etc.
++
++The goal is the have a small queue size, which is good for interactivity
++while not disturbing TCP/IP traffic with too many sudden drops after a burst
++of traffic.
++
++Depending on 08 ECN is configured, marking either means dropping or
++purely marking a packet as overlimit.
++.SH ALGORITHM
++The average queue size is used for determining the marking
++probability. This is calculated using an Exponential Weighted Moving
++Average, which can be more or less sensitive to bursts.
++
++When the average queue size is below 
++.B min
++bytes, no packet will ever be marked. When it exceeds 
++.B min, 
++the probability of doing so climbs linearly up
++to 
++.B probability, 
++until the average queue size hits
++.B max
++bytes. Because 
++.B probability 
++is normally not set to 100%, the queue size might
++conceivably rise above 
++.B max
++bytes, so the 
++.B limit
++parameter is provided to set a hard maximum for the size of the queue.
++
++.SH PARAMETERS
++.TP 
++min
++Average queue size at which marking becomes a possibility.
++.TP 
++max
++At this average queue size, the marking probability is maximal. Should be at
++least twice
++.B min
++to prevent synchronous retransmits, higher for low 
++.B min.
++.TP 
++probability
++Maximum probability for marking, specified as a floating point
++number from 0.0 to 1.0. Suggested values are 0.01 or 0.02 (1 or 2%,
++respectively).
++.TP 
++limit
++Hard limit on the real (not average) queue size in bytes. Further packets
++are dropped. Should be set higher than max+burst. It is advised to set this
++a few times higher than 
++.B max.
++.TP
++burst
++Used for determining how fast the average queue size is influenced by the
++real queue size. Larger values make the calculation more sluggish, allowing
++longer bursts of traffic before marking starts. Real life experiments
++support the following guideline: (min+min+max)/(3*avpkt).
++.TP 
++avpkt
++Specified in bytes. Used with burst to determine the time constant for
++average queue size calculations. 1000 is a good value.
++.TP
++bandwidth
++This rate is used for calculating the average queue size after some
++idle time. Should be set to the bandwidth of your interface. Does not mean
++that RED will shape for you! Optional.
++.TP
++ecn
++As mentioned before, RED can either 'mark' or 'drop'. Explicit Congestion
++Notification allows RED to notify remote hosts that their rate exceeds the
++amount of bandwidth available. Non-ECN capable hosts can only be notified by
++dropping a packet.  If this parameter is specified, packets which indicate
++that their hosts honor ECN will only be marked and not dropped, unless the
++queue size hits
++.B limit
++bytes. Needs a tc binary with RED support compiled in. Recommended.
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH SOURCES
++.TP 
++o
++Floyd, S., and Jacobson, V., Random Early Detection gateways for
++Congestion Avoidance. http://www.aciri.org/floyd/papers/red/red.html
++.TP 
++o
++Some changes to the algorithm by Alexey N. Kuznetsov.
++
++.SH AUTHORS
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>,  Alexey Makarenko
++<makar@phoenix.kharkov.ua>, J Hadi Salim <hadi@nortelnetworks.com>.  
++This manpage maintained by bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc-sfq.8 iproute2/debian/tc-sfq.8
+--- iproute2-orig/debian/tc-sfq.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-sfq.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,107 @@
++.TH TC 8 "8 December 2001" "iproute2" "Linux"
++.SH NAME
++sfq \- Stochastic Fairness Queueing
++.SH SYNOPSIS
++.B tc qdisc ... perturb
++seconds
++.B quantum
++bytes
++
++.SH DESCRIPTION
++
++Stochastic Fairness Queueing is a classless queueing discipline available for
++traffic control with the 
++.BR tc (8)
++command.
++
++SFQ does not shape traffic but only schedules the transmission of packets, based on 'flows'. 
++The goal is to ensure fairness so that each flow is able to send data in turn, thus preventing
++any single flow from drowning out the rest.
++
++This may in fact have some effect in mitigating a Denial of Service attempt.
++
++SFQ is work-conserving and therefore always delivers a packet if it has one available.
++.SH ALGORITHM
++On enqueueing, each packet is assigned to a hash bucket, based on
++.TP
++(i)
++Source address
++.TP
++(ii)
++Destination address
++.TP
++(iii)
++Source port
++.P
++If these are available. SFQ knows about ipv4 and ipv6 and also UDP, TCP and ESP. 
++Packets with other protocols are hashed based on the 32bits representation of their 
++destination and the socket they belong to. A flow corresponds mostly to a TCP/IP 
++connection.
++
++Each of these buckets should represent a unique flow. Because multiple flows may
++get hashed to the same bucket, the hashing algorithm is perturbed at configurable 
++intervals so that the unfairness lasts only for a short while. Perturbation may 
++however cause some inadvertent packet reordering to occur.
++
++When dequeuing, each hashbucket with data is queried in a round robin fashion.
++
++The compile time maximum length of the SFQ is 128 packets, which can be spread over
++at most 128 buckets of 1024 available. In case of overflow, tail-drop is performed
++on the fullest bucket, thus maintaining fairness.
++
++.SH PARAMETERS
++.TP 
++perturb
++Interval in seconds for queue algorithm perturbation. Defaults to 0, which means that 
++no perturbation occurs. Do not set too low for each perturbation may cause some packet
++reordering. Advised value: 10
++.TP 
++quantum
++Amount of bytes a flow is allowed to dequeue during a round of the round robin process.
++Defaults to the MTU of the interface which is also the advised value and the minimum value.
++
++.SH EXAMPLE & USAGE
++
++To attach to device ppp0:
++.P
++# tc qdisc add dev ppp0 root sfq perturb 10
++.P
++Please note that SFQ, like all non-shaping (work-conserving) qdiscs, is only useful 
++if it owns the queue.
++This is the case when the link speed equals the actually available bandwidth. This holds 
++for regular phone modems, ISDN connections and direct non-switched ethernet links. 
++.P
++Most often, cable modems and DSL devices do not fall into this category. The same holds 
++for when connected to a switch  and trying to send data to a congested segment also 
++connected to the switch.
++.P
++In this case, the effective queue does not reside within Linux and is therefore not 
++available for scheduling.
++.P
++Embed SFQ in a classful qdisc to make sure it owns the queue.
++
++.SH SOURCE
++.TP 
++o
++Paul E. McKenney "Stochastic Fairness Queuing",
++IEEE INFOCOMM'90 Proceedings, San Francisco, 1990.
++
++.TP
++o
++Paul E. McKenney "Stochastic Fairness Queuing",
++"Interworking: Research and Experience", v.2, 1991, p.113-131.
++
++.TP 
++o
++See also:
++M. Shreedhar and George Varghese "Efficient Fair
++Queuing using Deficit Round Robin", Proc. SIGCOMM 95.
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc-tbf.8 iproute2/debian/tc-tbf.8
+--- iproute2-orig/debian/tc-tbf.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc-tbf.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,138 @@
++.TH TC 8 "13 December 2001" "iproute2" "Linux"
++.SH NAME
++tbf \- Token Bucket Filter
++.SH SYNOPSIS
++.B tc qdisc ... tbf rate
++rate
++.B burst
++bytes/cell
++.B ( latency 
++ms 
++.B | limit
++bytes
++.B ) [ mpu 
++bytes
++.B [ peakrate
++rate
++.B mtu
++bytes/cell
++.B ] ]
++.P
++burst is also known as buffer and maxburst. mtu is also known as minburst.
++.SH DESCRIPTION
++
++The Token Bucket Filter is a classless queueing discipline available for
++traffic control with the 
++.BR tc (8)
++command.
++
++TBF is a pure shaper and never schedules traffic. It is non-work-conserving and may throttle
++itself, although packets are available, to ensure that the configured rate is not exceeded. 
++On all platforms except for Alpha,
++it is able to shape up to 1mbit/s of normal traffic with ideal minimal burstiness, 
++sending out  data exactly at the configured rates. 
++
++Much higher rates are possible but at the cost of losing the minimal burstiness. In that
++case, data is on average dequeued at the configured rate but may be sent much faster at millisecond 
++timescales. Because of further queues living in network adaptors, this is often not a problem.
++
++Kernels with a higher 'HZ' can achieve higher rates with perfect burstiness. On Alpha, HZ is ten
++times higher, leading to a 10mbit/s limit to perfection. These calculations hold for packets of on 
++average 1000 bytes.
++
++.SH ALGORITHM
++As the name implies, traffic is filtered based on the expenditure of 
++.B tokens.
++Tokens roughly correspond to bytes, with the additional constraint that each packet consumes
++some tokens, no matter how small it is. This reflects the fact that even a zero-sized packet occupies
++the link for some time.
++
++On creation, the TBF is stocked with tokens which correspond to the amount of traffic that can be burst 
++in one go. Tokens arrive at a steady rate, until the bucket is full.
++
++If no tokens are available, packets are queued, up to a configured limit. The TBF now 
++calculates the token deficit, and throttles until the first packet in the queue can be sent.
++
++If it is not acceptable to burst out packets at maximum speed, a peakrate can be configured 
++to limit the speed at which the bucket empties. This peakrate is implemented as a second TBF
++with a very small bucket, so that it doesn't burst.
++
++To achieve perfection, the second bucket may contain only a single packet, which leads to 
++the earlier mentioned 1mbit/s limit. 
++
++This limit is caused by the fact that the kernel can only throttle for at minimum 1 'jiffy', which depends
++on HZ as 1/HZ. For perfect shaping, only a single packet can get sent per jiffy - for HZ=100, this means 100 
++packets of on average 1000 bytes each, which roughly corresponds to 1mbit/s.
++
++.SH PARAMETERS
++See 
++.BR tc (8)
++for how to specify the units of these values.
++.TP
++limit or latency
++Limit is the number of bytes that can be queued waiting for tokens to become
++available. You can also specify this the other way around by setting the
++latency parameter, which specifies the maximum amount of time a packet can
++sit in the TBF. The latter calculation takes into account the size of the
++bucket, the rate and possibly the peakrate (if set). These two parameters
++are mutually exclusive. 
++.TP
++burst
++Also known as buffer or maxburst.
++Size of the bucket, in bytes. This is the maximum amount of bytes that tokens can be available for instantaneously. 
++In general, larger shaping rates require a larger buffer. For 10mbit/s on Intel, you need at least 10kbyte buffer 
++if you want to reach your configured rate!
++
++If your buffer is too small, packets may be dropped because more tokens arrive per timer tick than fit in your bucket.
++The minimum buffer size can be calculated by dividing the rate by HZ.
++
++Token usage calculations are performed using a table which by default has a resolution of 8 packets. 
++This resolution can be changed by specifying the 
++.B cell
++size with the burst. For example, to specify a 6000 byte buffer with a 16
++byte cell size, set a burst of 6000/16. You will probably never have to set
++this. Must be an integral power of 2.
++.TP
++mpu
++A zero-sized packet does not use zero bandwidth. For ethernet, no packet uses less than 64 bytes. The Minimum Packet Unit 
++determines the minimal token usage (specified in bytes) for a packet. Defaults to zero.
++.TP
++rate
++The speed knob. See remarks above about limits! See 
++.BR tc (8)
++for units.
++.PP
++Furthermore, if a peakrate is desired, the following parameters are available:
++
++.TP
++peakrate
++Maximum depletion rate of the bucket. Limited to 1mbit/s on Intel, 10mbit/s on Alpha. The peakrate does 
++not need to be set, it is only necessary if perfect millisecond timescale shaping is required.
++
++.TP
++mtu/minburst
++Specifies the size of the peakrate bucket. For perfect accuracy, should be set to the MTU of the interface.
++If a peakrate is needed, but some burstiness is acceptable, this size can be raised. A 3000 byte minburst
++allows around 3mbit/s of peakrate, given 1000 byte packets.
++
++Like the regular burstsize you can also specify a 
++.B cell
++size.
++.SH EXAMPLE & USAGE
++
++To attach a TBF with a sustained maximum rate of 0.5mbit/s, a peakrate of 1.0mbit/s,
++a 5kilobyte buffer, with a pre-bucket queue size limit calculated so the TBF causes
++at most 70ms of latency, with perfect peakrate behaviour, issue:
++.P
++# tc qdisc add dev eth0 root tbf rate 0.5mbit \\
++  burst 5kb latency 70ms peakrate 1mbit       \\
++  minburst 1540
++
++.SH SEE ALSO
++.BR tc (8)
++
++.SH AUTHOR
++Alexey N. Kuznetsov, <kuznet@ms2.inr.ac.ru>. This manpage maintained by
++bert hubert <ahu@ds9a.nl>
++
++
+diff -Naur iproute2-orig/debian/tc.8 iproute2/debian/tc.8
+--- iproute2-orig/debian/tc.8	1969-12-31 16:00:00.000000000 -0800
++++ iproute2/debian/tc.8	2004-05-21 00:09:38.000000000 -0700
+@@ -0,0 +1,348 @@
++.TH TC 8 "16 December 2001" "iproute2" "Linux"
++.SH NAME
++tc \- show / manipulate traffic control settings
++.SH SYNOPSIS
++.B tc qdisc [ add | change | replace | link ] dev 
++DEV 
++.B 
++[ parent 
++qdisc-id 
++.B | root ] 
++.B [ handle 
++qdisc-id ] qdisc
++[ qdisc specific parameters ]
++.P
++
++.B tc class [ add | change | replace ] dev
++DEV
++.B parent 
++qdisc-id 
++.B [ classid 
++class-id ] qdisc
++[ qdisc specific parameters ]
++.P
++
++.B tc filter [ add | change | replace ] dev
++DEV
++.B  [ parent
++qdisc-id
++.B | root ] protocol
++protocol
++.B prio
++priority filtertype
++[ filtertype specific parameters ]
++.B flowid
++flow-id
++
++.B tc [-s | -d ] qdisc show [ dev 
++DEV 
++.B  ]
++.P
++.B tc [-s | -d ] class show dev 
++DEV 
++.P
++.B tc filter show dev 
++DEV 
++
++.SH DESCRIPTION
++.B Tc
++is used to configure Traffic Control in the Linux kernel. Traffic Control consists 
++of the following:
++
++.TP 
++SHAPING
++When traffic is shaped, its rate of transmission is under control. Shaping may 
++be more than lowering the available bandwidth - it is also used to smooth out 
++bursts in traffic for better network behaviour. Shaping occurs on egress.
++
++.TP 
++SCHEDULING
++By scheduling the transmission of packets it is possible to improve interactivity
++for traffic that needs it while still guaranteeing bandwidth to bulk transfers. Reordering
++is also called prioritizing, and happens only on egress.
++
++.TP
++POLICING
++Where shaping deals with transmission of traffic, policing pertains to traffic
++arriving. Policing thus occurs on ingress.
++
++.TP
++DROPPING
++Traffic exceeding a set bandwidth may also be dropped forthwith, both on 
++ingress and on egress.
++
++.P
++Processing of traffic is controlled by three kinds of objects: qdiscs, 
++classes and filters. 
++
++.SH QDISCS
++.B qdisc 
++is short for 'queueing discipline' and it is elementary to 
++understanding traffic control. Whenever the kernel needs to send a 
++packet to an interface, it is 
++.B enqueued
++to the qdisc configured for that interface. Immediately afterwards, the kernel
++tries to get as many packets as possible from the qdisc, for giving them
++to the network adaptor driver.
++
++A simple QDISC is the 'pfifo' one, which does no processing at all and is a pure 
++First In, First Out queue. It does however store traffic when the network interface
++can't handle it momentarily.
++
++.SH CLASSES
++Some qdiscs can contain classes, which contain further qdiscs - traffic may 
++then be enqueued in any of the inner qdiscs, which are within the
++.B classes.
++When the kernel tries to dequeue a packet from such a 
++.B classful qdisc
++it can come from any of the classes. A qdisc may for example prioritize 
++certain kinds of traffic by trying to dequeue from certain classes
++before others.
++
++.SH FILTERS
++A
++.B filter
++is used by a classful qdisc to determine in which class a packet will
++be enqueued. Whenever traffic arrives at a class with subclasses, it needs
++to be classified. Various methods may be employed to do so, one of these
++are the filters. All filters attached to the class are called, until one of 
++them returns with a verdict. If no verdict was made, other criteria may be 
++available. This differs per qdisc.
++
++It is important to notice that filters reside 
++.B within
++qdiscs - they are not masters of what happens.
++
++.SH CLASSLESS QDISCS
++The classless qdiscs are:
++.TP 
++[p|b]fifo
++Simplest usable qdisc, pure First In, First Out behaviour. Limited in 
++packets or in bytes.
++.TP
++pfifo_fast
++Standard qdisc for 'Advanced Router' enabled kernels. Consists of a three-band
++queue which honors Type of Service flags, as well as the priority that may be 
++assigned to a packet.
++.TP
++red
++Random Early Detection simulates physical congestion by randomly dropping
++packets when nearing configured bandwidth allocation. Well suited to very
++large bandwidth applications.
++.TP 
++sfq
++Stochastic Fairness Queueing reorders queued traffic so each 'session'
++gets to send a packet in turn.
++.TP
++tbf
++The Token Bucket Filter is suited for slowing traffic down to a precisely
++configured rate. Scales well to large bandwidths. 
++.SH CONFIGURING CLASSLESS QDISCS
++In the absence of classful qdiscs, classless qdiscs can only be attached at 
++the root of a device. Full syntax:
++.P
++.B tc qdisc add dev 
++DEV 
++.B root 
++QDISC QDISC-PARAMETERS
++
++To remove, issue
++.P
++.B tc qdisc del dev
++DEV
++.B root
++
++The  
++.B pfifo_fast
++qdisc is the automatic default in the absence of a configured qdisc.
++
++.SH CLASSFUL QDISCS
++The classful qdiscs are:
++.TP
++CBQ
++Class Based Queueing implements a rich linksharing hierarchy of classes. 
++It contains shaping elements as well as prioritizing capabilities. Shaping is
++performed using link idle time calculations based on average packet size and
++underlying link bandwidth. The latter may be ill-defined for some interfaces.
++.TP
++HTB
++The Hierarchy Token Bucket implements a rich linksharing hierarchy of 
++classes with an emphasis on conforming to existing practices. HTB facilitates
++guaranteeing bandwidth to classes, while also allowing specification of upper
++limits to inter-class sharing. It contains shaping elements, based on TBF and
++can prioritize classes.	
++.TP 
++PRIO
++The PRIO qdisc is a non-shaping container for a configurable number of 
++classes which are dequeued in order. This allows for easy prioritization 
++of traffic, where lower classes are only able to send if higher ones have 
++no packets available. To facilitate configuration, Type Of Service bits are 
++honored by default.
++.SH THEORY OF OPERATION
++Classes form a tree, where each class has a single parent. 
++A class may have multiple children. Some qdiscs allow for runtime addition
++of classes (CBQ, HTB) while others (PRIO) are created with a static number of 
++children.
++
++Qdiscs which allow dynamic addition of classes can have zero or more 
++subclasses to which traffic may be enqueued. 
++
++Furthermore, each class contains a
++.B leaf qdisc
++which by default has 
++.B pfifo 
++behaviour though another qdisc can be attached in place. This qdisc may again 
++contain classes, but each class can have only one leaf qdisc. 
++
++When a packet enters a classful qdisc it can be 
++.B classified
++to one of the classes within. Three criteria are available, although not all 
++qdiscs will use all three:
++.TP 
++tc filters
++If tc filters are attached to a class, they are consulted first 
++for relevant instructions. Filters can match on all fields of a packet header, 
++as well as on the firewall mark applied by ipchains or iptables. See 
++.BR tc-filters (8).
++.TP
++Type of Service
++Some qdiscs have built in rules for classifying packets based on the TOS field.
++.TP
++skb->priority
++Userspace programs can encode a class-id in the 'skb->priority' field using 
++the SO_PRIORITY option.
++.P
++Each node within the tree can have its own filters but higher level filters
++may also point directly to lower classes.
++
++If classification did not succeed, packets are enqueued to the leaf qdisc 
++attached to that class. Check qdisc specific manpages for details, however.
++
++.SH NAMING
++All qdiscs, classes and filters have IDs, which can either be specified
++or be automatically assigned. 
++
++IDs consist of a major number and a minor number, separated by a colon.
++
++.TP 
++QDISCS
++A qdisc, which potentially can have children, 
++gets assigned a major number, called a 'handle', leaving the minor 
++number namespace available for classes. The handle is expressed as '10:'. 
++It is customary to explicitly assign a handle to qdiscs expected to have 
++children.
++
++.TP 
++CLASSES
++Classes residing under a qdisc share their qdisc major number, but each have
++a separate minor number called a 'classid' that has no relation to their 
++parent classes, only to their parent qdisc. The same naming custom as for 
++qdiscs applies.
++
++.TP 
++FILTERS
++Filters have a three part ID, which is only needed when using a hashed
++filter hierarchy, for which see
++.BR tc-filters (8).
++.SH UNITS
++All parameters accept a floating point number, possibly followed by a unit.
++.P
++Bandwidths or rates can be specified in:
++.TP 
++kbps
++Kilobytes per second
++.TP
++mbps
++Megabytes per second
++.TP
++kbit
++Kilobits per second
++.TP
++mbit
++Megabits per second
++.TP
++bps or a bare number
++Bits per second
++.P
++Amounts of data can be specified in:
++.TP
++kb or k
++Kilobytes
++.TP
++mb or m
++Megabytes
++.TP
++mbit
++Megabits
++.TP
++kbit
++Kilobits
++.TP
++b or a bare number
++Bytes.
++.P
++Lengths of time can be specified in:
++.TP
++s, sec or secs
++Whole seconds
++.TP
++ms, msec or msecs
++Milliseconds
++.TP
++us, usec, usecs or a bare number
++Microseconds.
++
++.SH TC COMMANDS
++The following commands are available for qdiscs, classes and filter:
++.TP
++add
++Add a qdisc, class or filter to a node. For all entities, a 
++.B parent
++must be passed, either by passing its ID or by attaching directly to the root of a device. 
++When creating a qdisc or a filter, it can be named with the
++.B handle
++parameter. A class is named with the
++.B classid
++parameter.
++
++.TP
++remove
++A qdisc can be removed by specifying its handle, which may also be 'root'. All subclasses and their leaf qdiscs 
++are automatically deleted, as well as any filters attached to them.
++
++.TP
++change
++Some entities can be modified 'in place'. Shares the syntax of 'add', with the exception
++that the handle cannot be changed and neither can the parent. In other words, 
++.B
++change 
++cannot move a node.
++
++.TP
++replace
++Performs a nearly atomic remove/add on an existing node id. If the node does not exist yet
++it is created.
++
++.TP
++link
++Only available for qdiscs and performs a replace where the node 
++must exist already.
++
++
++.SH HISTORY
++.B tc
++was written by Alexey N. Kuznetsov and added in Linux 2.2.
++.SH SEE ALSO
++.BR tc-cbq (8),
++.BR tc-htb (8),
++.BR tc-sfq (8),
++.BR tc-red (8),
++.BR tc-tbf (8),
++.BR tc-pfifo (8),
++.BR tc-bfifo (8),
++.BR tc-pfifo_fast (8),
++.BR tc-filters (8)
++
++.SH AUTHOR
++Manpage maintained by bert hubert (ahu@ds9a.nl)
++
+diff -Naur iproute2-orig/include/rt_names.h iproute2/include/rt_names.h
+--- iproute2-orig/include/rt_names.h	2000-04-16 10:42:50.000000000 -0700
++++ iproute2/include/rt_names.h	2004-05-21 00:16:36.000000000 -0700
+@@ -1,6 +1,8 @@
+ #ifndef RT_NAMES_H_
+ #define RT_NAMES_H_ 1
+ 
++#include <asm/byteorder.h>
++
+ const char* rtnl_rtprot_n2a(int id, char *buf, int len);
+ const char* rtnl_rtscope_n2a(int id, char *buf, int len);
+ const char* rtnl_rttable_n2a(int id, char *buf, int len);
+diff -Naur iproute2-orig/lib/rt_names.c iproute2/lib/rt_names.c
+--- iproute2-orig/lib/rt_names.c	2000-04-16 10:42:52.000000000 -0700
++++ iproute2/lib/rt_names.c	2004-05-21 00:16:36.000000000 -0700
+@@ -16,6 +16,7 @@
+ #include <fcntl.h>
+ #include <string.h>
+ #include <sys/time.h>
++#include <asm/byteorder.h>
+ 
+ static void rtnl_tab_initialize(char *file, char **tab, int size)
+ {
+diff -Naur iproute2-orig/misc/arpd.c iproute2/misc/arpd.c
+--- iproute2-orig/misc/arpd.c	2002-01-09 20:02:26.000000000 -0800
++++ iproute2/misc/arpd.c	2004-05-21 00:16:36.000000000 -0700
+@@ -16,7 +16,7 @@
+ #include <unistd.h>
+ #include <stdlib.h>
+ #include <netdb.h>
+-#include <db.h>
++#include <db_185.h>
+ #include <sys/ioctl.h>
+ #include <sys/poll.h>
+ #include <errno.h>
+@@ -28,6 +28,7 @@
+ #include <signal.h>
+ #include <linux/if.h>
+ #include <linux/if_arp.h>
++#include <linux/if_ether.h>
+ #include <netinet/in.h>
+ #include <arpa/inet.h>
+ #include <linux/if_packet.h>