Removed to sync with upstream which is now using iproute2.

1 files changed, 0 insertions, 9823 deletions

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
deleted file mode 100644
index 0e37865..0000000
--- a/abs/core-testing/iproute/iproute2-2.4.7-now-ss020116.patch
+++ /dev/null
@@ -1,9823 +0,0 @@
-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>