
HOWTO du routage avanc et du contrle de trafic sous Linux

Bert Hubert

   Netherlabs BV

   <bert.hubert@netherlabs.nl>
   Gregory Maxwell

   <greg@linuxpower.cx>
   Remco van Mook

   <remco@virtu.nl>
   Martijn van Oosterhout

   <kleptog@cupid.suninternet.com>
   Paul B. Schroeder

   <paulsch@us.ibm.com>
   Jasper Spaans

   <jasper@spaans.ds9a.nl>

Laurent Foucher

   Traducteur

   <foucher@gch.iut-tlse3.fr>
   Philippe Latu
   Traducteur/Relecteur

   <philippe.latu@linux-france.org>
   Guillaume Allgre
   Relecteur

   <Guillaume.Allegre@imag.fr>
   _Historique des versions_
   Version $Revision: 1.1.1.1 $ $Date: 2003/01/03 02:38:54 $
   DocBook Edition

   Une approche pratique d'iproute2, de la mise en forme du trafic et un
   peu de netfilter.
     _________________________________________________________________

   _Table des matires_
   1. Ddicace
   2. Introduction

        2.1. Conditions de distribution et Mise en garde
        2.2. Connaissances pralables
        2.3. Ce que Linux peut faire pour vous
        2.4. Notes diverses
        2.5. Accs, CVS et propositions de mises  jour
        2.6. Liste de diffusion
        2.7. Plan du document

   3. Introduction  iproute2

        3.1. Pourquoi iproute2 ?
        3.2. Un tour d'horizon d'iproute2
        3.3. Prrequis
        3.4. Explorer votre configuration courante
        3.5. ARP

   4. Rgles - bases de donnes des politiques de routage

        4.1. Politique de routage simple par l'adresse source

   5. GRE et autres tunnels

        5.1. Quelques remarques gnrales  propos des tunnels :
        5.2. IP dans un tunnel IP
        5.3. Le tunnel GRE
        5.4. Tunnels dans l'espace utilisateur

   6. Tunnel IPv6 avec Cisco et/ou une dorsale IPv6 (6bone)

        6.1. Tunnel IPv6

   7. IPsec : IP scuris  travers l'Internet
   8. Routage multidistribution (multicast)
   9. Gestionnaires de mise en file d'attente pour l'administration de la
          bande passante

        9.1. Explication sur les files d'attente et la gestion de la mise
                en file d'attente

        9.2. Gestionnaires de mise en file d'attente simples, sans
                classes

        9.3. Conseils pour le choix de la file d'attente
        9.4. Terminologie
        9.5. Gestionnaires de file d'attente bass sur les classes
        9.6. Classifier des paquets avec des filtres

   10. quilibrage de charge sur plusieurs interfaces

        10.1. Avertissement

   11. Netfilter et iproute - marquage de paquets
   12. Filtres avancs pour la (re-)classification des paquets

        12.1. Le classificateur u32
        12.2. Le classificateur route
        12.3. Les filtres de rglementation (Policing filters)
        12.4. Filtres hachs pour un filtrage massif trs rapide

   13. Paramtres rseau du noyau

        13.1. Filtrage de Chemin Inverse (Reverse Path Filtering)
        13.2. Configurations obscures

   14. Gestionnaires de mise en file d'attente avancs & moins communs

        14.1. bfifo/pfifo
        14.2. Algorithme Clark-Shenker-Zhang (CSZ)
        14.3. DSMARK
        14.4. Gestionnaire de mise en file d'attente d'entre (Ingress
                qdisc)

        14.5. Random Early Detection (RED)
        14.6. Generic Random Early Detection
        14.7. Emulation VC/ATM
        14.8. Weighted Round Robin (WRR)

   15. Recettes de cuisine

        15.1. Faire tourner plusieurs sites avec diffrentes SLA
                (autorisations)

        15.2. Protger votre machine des inondations SYN
        15.3. Limiter le dbit ICMP pour empcher les dnis de service
        15.4. Donner la priorit au trafic interactif
        15.5. Cache web transparent utilisant netfilter, iproute2,
                ipchains et squid

        15.6. Circonvenir aux problmes de la dcouverte du MTU de chemin
                en configurant un MTU par routes

        15.7. Circonvenir aux problmes de la dcouverte du MTU de chemin
                en imposant le MSS (pour les utilisateurs de l'ADSL, du
                cble, de PPPoE & PPtP)

        15.8. Le Conditionneur de Trafic Ultime : Faible temps de
                latence, Tlchargement vers l'amont et l'aval rapide

   16. Construire des ponts et des pseudo-ponts avec du Proxy ARP

        16.1. Etat des ponts et iptables
        16.2. Pont et mise en forme
        16.3. Pseudo-pont avec du Proxy-ARP

   17. Routage Dynamique - OSPF et BGP
   18. Autres possibilits
   19. Lectures supplmentaires
   20. Remerciements
     _________________________________________________________________

Chapitre 1. Ddicace

   Ce document est ddi  beaucoup de gens ; dans ma tentative de tous
   me les rappeler, je peux en citer quelques-uns :

     * Rusty Russell
     * Alexey N. Kuznetsov
     * La fine quipe de Google
     * L'quipe de Casema Internet
     _________________________________________________________________

Chapitre 2. Introduction

   Bienvenue, cher lecteur.

   Ce document a pour but de vous clairer sur la manire de faire du
   routage avanc avec Linux 2.2/2.4. Mconnus par les utilisateurs, les
   outils standard de ces noyaux permettent de faire des choses
   spectaculaires. Les commandes comme _route_ et _ifconfig_ sont des
   interfaces vraiment pauvres par rapport  la grande puissance
   potentielle d'iproute2.

   J'espre que ce HOWTO deviendra aussi lisible que ceux de Rusty
   Russell, trs rput (parmi d'autres choses) pour son netfilter.

   Vous pouvez nous contacter en nous crivant  l'quipe HOWTO.
   Cependant, postez, s'il vous plat, vos questions sur la liste de
   diffusion (voir la section correspondante) pour celles qui ne sont pas
   directement lies  ce HOWTO.

   Avant de vous perdre dans ce HOWTO, si la seule chose que vous
   souhaitez faire est de la simple mise en forme de trafic, allez
   directement au chapitre _Autres possibilits_, et lisez ce qui
   concerne CBQ.init.
     _________________________________________________________________

2.1. Conditions de distribution et Mise en garde

   Ce document est distribu dans l'espoir qu'il sera utile et utilis,
   mais SANS AUCUNE GARANTIE ; sans mme une garantie implicite de
   qualit lgale et marchande ni aptitude  un quelconque usage.

   En un mot, si votre dorsale STM-64 est tombe ou distribue de la
   pornographie  vos estims clients, cela n'est pas de notre faute.
   Dsol.

   Copyright (c) 2001 par Bert Hubert, Gregory Maxwell et Martijn van
   Oosterhout, Remco van Mook, Paul B. Schroeder et autres. Ce document
   ne peut tre distribu qu'en respectant les termes et les conditions
   exposs dans la Open Publication License, v1.0 ou suprieure (la
   dernire version est actuellement disponible sur
   http://www.opencontent.org/openpub/).

   Copiez et distribuez (vendez ou donnez) librement ce document, dans
   n'importe quel format. Les demandes de corrections et/ou de
   commentaires sont  adresser  la personne qui maintient ce document.

   Il est aussi demand que, si vous publiez cet HOWTO sur un support
   papier, vous en envoyiez des exemplaires aux auteurs pour une
   << relecture critique >> :-)
     _________________________________________________________________

2.2. Connaissances pralables

   Comme le titre l'implique, ceci est un HOWTO << avanc >>. Bien qu'il
   ne soit pas besoin d'tre un expert rseau, certains pr-requis sont
   ncessaires.

   Voici d'autres rfrences qui pourront vous aider  en apprendre
   plus :

   Rusty Russell's networking-concepts-HOWTO
          Trs bonne introduction, expliquant ce qu'est un rseau, et
          comment on le connecte  d'autres rseaux.

   Linux Networking-HOWTO (ex Net-3 HOWTO)
          Excellent document, bien que trs bavard. Il vous apprendra
          beaucoup de choses qui sont dj configures si vous tes
          capable de vous connecter  Internet. Il peut ventuellement
          tre situ  /usr/doc/HOWTO/NET-HOWTO.txt, mais peut galement
          tre trouv en ligne
     _________________________________________________________________

2.3. Ce que Linux peut faire pour vous

   Une petite liste des choses qui sont possibles :

     * Limiter la bande passante pour certains ordinateurs
     * Limiter la bande passante VERS certains ordinateurs
     * Vous aider  partager quitablement votre bande passante
     * Protger votre rseau des attaques de type Dni de Service
     * Protger Internet de vos clients
     * Multiplexer plusieurs serveurs en un seul, pour l'quilibrage de
       charge ou une disponibilit amliore
     * Restreindre l'accs  vos ordinateurs
     * Limiter l'accs de vos utilisateurs vers d'autres htes
     * Faire du routage bas sur l'ID utilisateur (eh oui !), l'adresse
       MAC, l'adresse IP source, le port, le type de service, l'heure ou
       le contenu.

   Peu de personnes utilisent couramment ces fonctionnalits avances. Il
   y a plusieurs raisons  cela. Bien que la documentation soit fournie,
   la prise en main est difficile. Les commandes de contrle du trafic ne
   sont pratiquement pas documentes.
     _________________________________________________________________

2.4. Notes diverses

   Il y a plusieurs choses qui doivent tre notes au sujet de ce
   document. Bien que j'en ai crit la majeure partie, je ne veux
   vraiment pas qu'il reste tel quel. Je crois beaucoup  l'Open Source,
   je vous encourage donc  envoyer des remarques, des mises  jour, des
   corrections, etc. N'hsitez pas  m'avertir des coquilles ou d'erreurs
   pures et simples. Si mon anglais vous parat parfois peu naturel, ayez
   en tte, s'il vous plat, que l'anglais n'est pas ma langue natale.
   N'hsitez pas  m'envoyer vos suggestions [NdT : en anglais !]

   Si vous pensez que vous tes plus qualifi que moi pour maintenir une
   section ou si vous pensez que vous pouvez crire et maintenir de
   nouvelles sections, vous tes le bienvenu. La version SGML de ce HOWTO
   est disponible via CVS. J'envisage que d'autre personnes puissent
   travailler dessus.

   Pour vous aider, vous trouverez beaucoup de mentions FIXME (NdT : A
   CORRIGER). Les corrections sont toujours les bienvenues. Si vous
   trouvez une mention FIXME, vous saurez que vous tes en territoire
   inconnu. Cela ne veut pas dire qu'il n'y a pas d'erreurs ailleurs,
   faites donc trs attention. Si vous avez valid quelque chose,
   faites-nous le savoir, ce qui nous permettra de retirer la mention
   FIXME.

   Je prendrai quelques liberts tout au long de cet HOWTO. Par exemple,
   je pars de l'hypothse d'une connexion Internet  10 Mbits, bien que
   je sache trs bien que cela ne soit pas vraiment courant.
     _________________________________________________________________

2.5. Accs, CVS et propositions de mises  jour

   L'adresse canonique de cet HOWTO est Ici.

   Nous avons maintenant un CVS en accs anonyme disponible depuis le
   monde entier. Cela est intressant pour plusieurs raisons. Vous pouvez
   facilement tlcharger les nouvelles versions de ce HOWTO et soumettre
   des mises  jour.

   En outre, cela permet aux auteurs de travailler sur la source de faon
   indpendante, ce qui est une bonne chose aussi.
$ export CVSROOT=:pserver:anon@outpost.ds9a.nl:/var/cvsroot
$ cvs login
CVS password: [enter 'cvs' (sans les caractres ')]
$ cvs co 2.4routing
cvs server: Updating 2.4routing
U 2.4routing/2.4routing.sgml

   Si vous reprez une erreur ou voulez ajouter quelque chose, faites le
   en local, excutez cvs diff -u, et envoyez-nous le rsultat.

   Un fichier Makefile est fourni pour vous aider  crer des fichiers
   PostScript, dvi, pdf, html et texte. Vous pouvez avoir  installer les
   docbook, docbook-utils, ghostscript et tetex pour obtenir tous les
   formats de sortie.
     _________________________________________________________________

2.6. Liste de diffusion

   Les auteurs reoivent de plus en plus de courriers lectroniques 
   propos de cet HOWTO. Vu l'intrt de la communaut, il a t dcid la
   mise en place d'une liste de diffusion o les personnes pourront
   discuter du routage avanc et du contrle de trafic. Vous pouvez vous
   abonner  la liste ici.

   Il devra tre not que les auteurs sont trs hsitants  rpondre 
   des questions qui n'ont pas t poses sur la liste. Nous aimerions
   que la liste devienne une sorte de base de connaissance. Si vous avez
   une question, recherchez, s'il vous plat, d'abord dans l'archive, et
   ensuite postez-l dans la liste de diffusion.
     _________________________________________________________________

2.7. Plan du document

   Nous allons essayer de faire des manipulations intressantes ds le
   dbut, ce qui veut dire que tout ne sera pas expliqu en dtail tout
   de suite. Veuillez passer sur ces dtails, et accepter de considrer
   qu'ils deviendront clairs par la suite.

   Le routage et le filtrage sont deux choses distinctes. Le filtrage est
   trs bien document dans le HOWTO de Rusty, disponible ici :

     * Rusty's Remarkably Unreliable Guides

   Nous nous focaliserons principalement sur ce qu'il est possible de
   faire en combinant netfilter et iproute2.
     _________________________________________________________________

Chapitre 3. Introduction  iproute2

3.1. Pourquoi iproute2 ?

   La plupart des distributions Linux et des UNIX utilisent couramment
   les vnrables commandes _arp_, _ifconfig_ et _route_. Bien que ces
   outils fonctionnent, ils montrent quelques comportements inattendus
   avec les noyaux Linux des sries 2.2 et plus. Par exemple, les tunnels
   GRE font partie intgrante du routage de nos jours, mais ils
   ncessitent des outils compltement diffrents.

   Avec iproute2, les tunnels font partie intgrante des outils.

   Les noyaux Linux des sries 2.2 et plus ont un sous-systme rseau
   compltement rcrit. Ce nouveau codage de la partie rseau apporte 
   Linux des performances et des fonctionnalits qui n'ont pratiquement
   pas d'quivalent parmi les autres systmes d'exploitation. En fait, le
   nouveau logiciel de filtrage, routage et de classification possde
   plus de fonctionnalits que les logiciels fournis sur beaucoup de
   routeurs ddis, de pare-feu et de produits de mise en forme
   (_shaping_) du trafic.

   Dans les systmes d'exploitation existants, au fur et  mesure que de
   nouveaux concepts rseau apparaissaient, les dveloppeurs sont
   parvenus  les greffer sur les structures existantes. Ce travail
   constant d'empilage de couches a conduit  des codes rseau aux
   comportements tranges, un peu comme les langues humaines. Dans le
   pass, Linux mulait le mode de fonctionnement de SunOS, ce qui
   n'tait pas l'idal.

   La nouvelle structure d'iproute2 a permis de formuler clairement des
   fonctionnalits impossibles  implmenter dans le sous-systme rseau
   prcdent.
     _________________________________________________________________

3.2. Un tour d'horizon d'iproute2

   Linux possde un systme sophistiqu d'allocation de bande passante
   appel Contrle de trafic (_Traffic Control_). Ce systme supporte
   diffrentes mthodes pour classer, ranger par ordre de priorit,
   partager et limiter le trafic entrant et sortant.

   Nous commencerons par un petit tour d'horizon des possibilits
   d'iproute2.
     _________________________________________________________________

3.3. Prrequis

   Vous devez tre sr que vous avez install les outils utilisateur
   (NdT : userland tools, par opposition  la partie << noyau >>
   d'iproute2). Le paquet concern s'appelle iproute sur RedHat et
   Debian. Autrement, il peut tre trouv 
   ftp://ftp.inr.ac.ru/ip-routing/iproute2-2.2.4-now-ss??????.tar.gz.

   Vous pouvez aussi essayer iproute2-current.tar.gz pour la dernire
   version.

   Certains lments d'iproute vous imposent l'activation de certaines
   options du noyau. Il devra galement tre not que toutes les versions
   de RedHat jusqu' la version 6.2 incluse n'ont pas les fonctionnalits
   du contrle de trafic dans le noyau par dfaut.

   RedHat 7.2 contient tous les lments par dfaut.

   Soyez galement sr que vous avez le support netlink, mme si vous
   devez choisir de compiler votre propre noyau ; iproute2 en a besoin.
     _________________________________________________________________

3.4. Explorer votre configuration courante

   Cela peut vous paratre surprenant, mais iproute2 est dj configur !
   Les commandes courantes _ifconfig_ et _route_ utilisent dj les
   appels systme avancs d'iproute2, mais essentiellement avec les
   options par dfaut (c'est--dire ennuyeuses).

   L'outil _ip_ est central, et nous allons lui demander de nous montrer
   les interfaces.
     _________________________________________________________________

3.4.1. _ip_ nous montre nos liens

[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp

   La sortie peut varier, mais voici ce qui est affich pour mon routeur
   NAT (NdT : translation d'adresse) chez moi. J'expliquerai seulement
   une partie de la sortie, dans la mesure o tout n'est pas directement
   pertinent.

   La premire interface que nous voyons est l'interface loopback. Bien
   que votre ordinateur puisse fonctionner sans, je vous le dconseille.
   La taille de MTU (unit maximum de transmission) est de 3924 octets,
   et loopback n'est pas suppos tre mis en file d'attente, ce qui prend
   tout son sens dans la mesure o cette interface est le fruit de
   l'imagination de votre noyau.

   Je vais passer sur l'interface dummy pour l'instant, et il se peut
   qu'elle ne soit pas prsente sur votre ordinateur. Il y a ensuite mes
   deux interfaces physiques, l'une du ct de mon modem cble, l'autre
   servant mon segment ethernet  la maison. De plus, nous voyons une
   interface ppp0.

   Notons l'absence d'adresses IP. Iproute dconnecte les concepts de
   << liens >> et << d'adresses IP >>. Avec l'_IP aliasing_, le concept
   de l'adresse IP canonique est devenu, de toute faon, sans
   signification.

   _ip_ nous montre bien, cependant, l'adresse MAC, l'identifiant
   matriel de nos interfaces ethernet.
     _________________________________________________________________

3.4.2. _ip_ nous montre nos adresses IP

[ahu@home ahu]$ ip address show
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1400 qdisc pfifo_fast qlen 100
    link/ether 48:54:e8:2a:47:16 brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.1/8 brd 10.255.255.255 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:e0:4c:39:24:78 brd ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc pfifo_fast qlen 10
    link/ppp
    inet 212.64.94.251 peer 212.64.94.1/32 scope global ppp0

   Cela contient plus d'informations : _ip_ montre toutes nos adresses,
   et  quelles cartes elles appartiennent. inet signifie Internet
   (IPv4). Il y a beaucoup d'autres familles d'adresses, mais elles ne
   nous concernent pas pour le moment.

   Examinons l'interface eth0 de plus prs. Il est dit qu'elle est relie
    l'adresse internet 10.0.0.1/8. Qu'est-ce que cela signifie ? Le /8
   dsigne le nombre de bits rservs  l'adresse rseau. Il y a 32 bits,
   donc il reste 24 bits pour dsigner une partie de notre rseau. Les 8
   premiers bits de 10.0.0.1 correspondent  10.0.0.0, notre adresse
   rseau, et notre masque de sous-rseau est 255.0.0.0.

   Les autres bits reprent des machines directement connectes  cette
   interface. Donc, 10.250.3.13 est directement disponible sur eth0,
   comme l'est 10.0.0.1 dans notre exemple.

   Avec ppp0, le mme concept existe, bien que les nombres soient
   diffrents. Son adresse est 212.64.94.251, sans masque de sous-rseau.
   Cela signifie que vous avez une liaison point  point et que toutes
   les adresses,  l'exception de 212.64.94.251, sont distantes. Il y a
   cependant plus d'informations. En effet, on nous dit que de l'autre
   ct du lien, il n'y a encore qu'une seule adresse, 212.64.94.1. Le
   /32 nous prcise qu'il n'y a pas de << bits rseau >>.

   Il est absolument vital que vous compreniez ces concepts. Rfrez-vous
    la documentation mentionne au dbut de ce HOWTO si vous avez des
   doutes.

   Vous pouvez aussi noter qdisc, qui dsigne la gestion de la mise en
   file d'attente (_Queueing Discipline_). Cela deviendra vital plus
   tard.
     _________________________________________________________________

3.4.3. _ip_ nous montre nos routes

   Nous savons maintenant comment trouver les adresses 10.x.y.z, et nous
   sommes capables d'atteindre 212.64.94.1. Cela n'est cependant pas
   suffisant, et nous avons besoin d'instructions pour atteindre le
   monde. L'Internet est disponible via notre connexion PPP, et il se
   trouve que 212.64.94.1 est prt  propager nos paquets  travers le
   monde, et  nous renvoyer le rsultat.
[ahu@home ahu]$ ip route show
212.64.94.1 dev ppp0  proto kernel  scope link  src 212.64.94.251
10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via 212.64.94.1 dev ppp0

   Cela se comprend de soi-mme. Les 4 premires lignes donnent
   explicitement ce qui tait sous-entendu par ip address show, la
   dernire ligne nous indiquant que le reste du monde peut tre trouv
   via 212.64.94.1, notre passerelle par dfaut. Nous pouvons voir que
   c'est une passerelle  cause du mot << via >>, qui nous indique que
   nous avons besoin d'envoyer les paquets vers 212.64.94.1, et que c'est
   elle qui se chargera de tout.

   En rfrence, voici ce que l'ancien utilitaire _route_ nous propose :
[ahu@home ahu]$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
212.64.94.1     0.0.0.0         255.255.255.255 UH    0      0        0 ppp0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         212.64.94.1     0.0.0.0         UG    0      0        0 ppp0
     _________________________________________________________________

3.5. ARP

   ARP est le Protocole de Rsolution d'Adresse (_Address Resolution
   Protocol_). Il est dcrit dans le RFC 826. ARP est utilis par une
   machine d'un rseau local pour retrouver l'adresse matrielle (la
   localisation) d'une autre machine sur le mme rseau. Les machines sur
   Internet sont gnralement connues par leur nom auquel correspond une
   adresse IP. C'est ainsi qu'une machine sur le rseau foo.com est
   capable de communiquer avec une autre machine qui est sur le rseau
   bar.net. Une adresse IP, cependant, ne peut pas vous indiquer la
   localisation physique de la machine. C'est ici que le protocole ARP
   entre en jeu.

   Prenons un exemple trs simple. Supposons que j'aie un rseau compos
   de plusieurs machines, dont la machine foo d'adresse IP 10.0.0.1 et la
   machine bar qui a l'adresse IP 10.0.0.2. Maintenant, foo veut envoyer
   un _ping_ vers bar pour voir s'il est actif, mais foo n'a aucune
   indication sur la localisation de bar. Donc, si foo dcide d'envoyer
   un _ping_ vers bar, il a besoin d'envoyer une requte ARP. Cette
   requte ARP est une faon pour foo de crier sur le rseau << Bar
   (10.0.0.2) ! O es-tu ? >>. Par consquent, toutes les machines sur le
   rseau entendront foo crier, mais seul bar (10.0.0.2) rpondra. Bar
   enverra une rponse ARP directement  foo ; ce qui revient  dire :
   << Foo (10.0.0.1) ! je suis ici,  l'adresse 00:60:94:E:08:12 >>.
   Aprs cette simple transaction utilise pour localiser son ami sur le
   rseau, foo est capable de communiquer avec bar jusqu' ce qu'il (le
   cache ARP de foo) oublie o bar est situ (typiquement au bout de 15
   minutes sur Unix).

   Maintenant, voyons comment cela fonctionne. Vous pouvez consulter
   votre cache (table) ARP (_neighbor_) comme ceci :
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

   Comme vous pouvez le voir, ma machine espa041 (9.3.76.41) sait o
   trouver espa042 (9.3.76.42) et espagate (9.3.76.1). Maintenant,
   ajoutons une autre machine dans le cache ARP.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1 espa043
PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41 : 56(84) bytes of data.
64 bytes from 9.3.76.43: icmp_seq=0 ttl=255 time=0.9 ms

1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.9/0.9/0.9 ms

[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0 lladdr 00:06:29:21:80:20 nud reachable
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable

   Par consquent, lorsque espa041 a essay de contacter espa043,
   l'adresse matrielle de espa043 (sa localisation) a alors t ajoute
   dans le cache ARP. Donc, tant que la dure de vie de l'entre
   correspondant  espa043 dans le cache ARP n'est pas dpasse, espa041
   sait localiser espa043 et n'a plus besoin d'envoyer de requte ARP.

   Maintenant, effaons espa043 de notre cache ARP.
[root@espa041 /home/src/iputils]# ip neigh delete 9.3.76.43 dev eth0
[root@espa041 /home/src/iputils]# ip neigh show
9.3.76.43 dev eth0  nud failed
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud stale

   Maintenant, espa041 a  nouveau oubli la localisation d'espa043 et
   aura besoin d'envoyer une autre requte ARP la prochaine fois qu'il
   voudra communiquer avec lui. Vous pouvez aussi voir ci-dessus que
   l'tat d'espagate (9.3.76.1) est pass en _stale_. Cela signifie que
   la localisation connue est encore valide, mais qu'elle devra tre
   confirme  la premire transaction avec cette machine.
     _________________________________________________________________

Chapitre 4. Rgles - bases de donnes des politiques de routage

   Si vous avez un routeur important, il se peut que vous vouliez
   satisfaire les besoins de diffrentes personnes, qui peuvent tre
   traites diffremment. Les bases de donnes des politiques de routage
   vous aident  faire cela, en grant plusieurs ensembles de tables de
   routage.

   Si vous voulez utiliser cette fonctionnalit, assurez-vous que le
   noyau est compil avec les options IP : Advanced router et IP : policy
   routing.

   Quand le noyau doit prendre une dcision de routage, il recherche
   quelle table consulter. Par dfaut, il y a trois tables. L'ancien
   outil _route_ modifie les tables principale (_main_) et locale
   (_local_), comme le fait l'outil _ip_ (par dfaut).

   Les rgles par dfaut :
[ahu@home ahu]$ ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

   Ceci liste la priorit de toutes les rgles. Nous voyons que toutes
   les rgles sont appliques  tous les paquets (_from all_). Nous avons
   vu la table _main_ prcdemment, sa sortie s'effectuant avec ip route
   ls, mais les tables local et default sont nouvelles.

   Si nous voulons faire des choses fantaisistes, nous pouvons crer des
   rgles qui pointent vers des tables diffrentes et qui nous permettent
   de redfinir les rgles de routage du systme.

   Pour savoir exactement ce que fait le noyau en prsence d'un
   assortiment de rgles plus complet, rfrez-vous  la documentation
   ip-cref d'Alexey [NdT : dans le paquetage iproute2 de votre
   distribution].
     _________________________________________________________________

4.1. Politique de routage simple par l'adresse source

   Prenons encore une fois un exemple rel. J'ai 2 modems cble,
   connects  un routeur Linux NAT (_masquerading_). Les personnes
   habitant avec moi me paient pour avoir accs  Internet. Supposons
   qu'un de mes co-locataires consulte seulement hotmail et veuille payer
   moins. C'est d'accord pour moi, mais il utilisera le modem le plus
   lent.

   Le modem cble << rapide >> est connu sous 212.64.94.251 et est en
   liaison PPP avec 212.64.94.1. Le modem cble << lent >> est connu sous
   diverses adresses IP : 212.64.78.148 dans notre exemple avec un lien
   vers 195.96.98.253.

   La table locale :
[ahu@home ahu]$ ip route list table local
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
local 10.0.0.1 dev eth0  proto kernel  scope host  src 10.0.0.1
broadcast 10.0.0.0 dev eth0  proto kernel  scope link  src 10.0.0.1
local 212.64.94.251 dev ppp0  proto kernel  scope host  src 212.64.94.251
broadcast 10.255.255.255 dev eth0  proto kernel  scope link  src 10.0.0.1
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
local 212.64.78.148 dev ppp2  proto kernel  scope host  src 212.64.78.148
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1

   Il y a beaucoup de choses videntes, mais aussi des choses qui ont
   besoin d'tre prcises quelque peu, ce que nous allons faire. La
   table de routage par dfaut est vide.

   Regardons la table principale (_main_) :
[ahu@home ahu]$ ip route list table main
195.96.98.253 dev ppp2  proto kernel  scope link  src 212.64.78.148
212.64.94.1 dev ppp0  proto kernel  scope link  src 212.64.94.251
10.0.0.0/8 dev eth0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via 212.64.94.1 dev ppp0

   Maintenant, nous gnrons une nouvelle rgle que nous appellerons
   John, pour notre hypothtique co-locataire. Bien que nous puissions
   travailler avec des nombres IP purs, il est plus facile d'ajouter
   notre table dans le fichier /etc/iproute2/rt_tables.
# echo 200 John >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table John
# ip rule ls
0:      from all lookup local
32765:  from 10.0.0.10 lookup John
32766:  from all lookup main
32767:  from all lookup default

   Maintenant, tout ce qu'il reste  faire est de gnrer la table John,
   et de vider le cache des routes :
# ip route add default via 195.96.98.253 dev ppp2 table John
# ip route flush cache

   Et voil qui est fait. Il ne reste plus, comme exercice laiss au
   lecteur, qu' implmenter cela dans _ip-up_.
     _________________________________________________________________

Chapitre 5. GRE et autres tunnels

   Il y a trois sortes de tunnels sous Linux : l'IP dans un tunnel IP, le
   tunnel GRE et les tunnels qui existent en dehors du noyau (comme PPTP,
   par exemple).
     _________________________________________________________________

5.1. Quelques remarques gnrales  propos des tunnels :

   Les tunnels peuvent faire des choses trs inhabituelles et vraiment
   sympas. Ils peuvent aussi absolument tout dtraquer si vous ne les
   avez pas configurs correctement. Ne dfinissez pas votre route par
   dfaut sur un tunnel,  moins que vous ne sachiez _EXACTEMENT_ ce que
   vous faites.

   De plus, le passage par un tunnel augmente le poids des en-ttes
   (_overhead_), puisqu'un en-tte IP supplmentaire est ncessaire.
   Typiquement, ce surcot est de 20 octets par paquet. Donc, si la
   taille maximum de votre paquet sur votre rseau (MTU) est de 1500
   octets, un paquet qui est envoy  travers un tunnel sera limit  une
   taille de 1480 octets. Ce n'est pas ncessairement un problme, mais
   soyez sr d'avoir bien tudi la fragmentation et le rassemblage des
   paquets IP quand vous prvoyez de relier des rseaux de grande taille
   par des tunnels. Et bien sr, la manire la plus rapide de creuser un
   tunnel est de creuser des deux cts.
     _________________________________________________________________

5.2. IP dans un tunnel IP

   Ce type de tunnel est disponible dans Linux depuis un long moment. Il
   ncessite deux modules, _ipip.o_ et _new_tunnel.o_.

   Disons que vous avez trois rseaux : 2 rseaux internes A et B, et un
   rseau intermdiaire C (ou disons Internet). Les caractristiques du
   rseau A sont :
rseau 10.0.1.0
masque de sous-rseau 255.255.255.0
routeur  10.0.1.1

   Le routeur a l'adresse 172.16.17.18 sur le rseau C.

   et le rseau B :
rseau 10.0.2.0
masque de sous-rseau 255.255.255.0
routeur  10.0.2.1

   Le routeur a l'adresse 172.19.20.21 sur le rseau C.

   En ce qui concerne le rseau C, nous supposerons qu'il transmettra
   n'importe quel paquet de A vers B et vice-versa. Il est galement
   possible d'utiliser l'Internet pour cela.

   Voici ce qu'il faut faire :

   Premirement, assurez-vous que les modules soient installs :
insmod ipip.o
insmod new_tunnel.o

   Ensuite, sur le routeur du rseau A, faites la chose suivante :
ifconfig tunl0 10.0.1.1 pointopoint 172.19.20.21
route add -net 10.0.2.0 netmask 255.255.255.0 dev tunl0

   et sur le routeur du rseau B :
ifconfig tunl0 10.0.2.1 pointopoint 172.16.17.18
route add -net 10.0.1.0 netmask 255.255.255.0 dev tunl0

   Et quand vous aurez termin avec votre tunnel :
   ifconfig tunl0 down

   Vite fait, bien fait. Vous ne pouvez pas transmettre les paquets de
   diffusion (_broadcast_), ni le trafic IPv6  travers un tunnel IP-IP.
   Vous ne pouvez connecter que deux rseaux IPv4 qui, normalement, ne
   seraient pas capables de se << parler >>, c'est tout. Dans la mesure
   o la compatibilit a t conserve, ce code tourne depuis un bon
   moment, et il reste compatible depuis les noyaux 1.3. Le tunnel Linux
   IP dans IP ne fonctionne pas avec d'autres systmes d'exploitation ou
   routeurs, pour autant que je sache. C'est simple, a marche.
   Utilisez-le si vous le pouvez, autrement utilisez GRE.
     _________________________________________________________________

5.3. Le tunnel GRE

   GRE est un protocole de tunnel qui a t  l'origine dvelopp par
   Cisco, et qui peut raliser plus de choses que le tunnel IP dans IP.
   Par exemple, vous pouvez aussi transporter du trafic multi-diffusion
   (_multicast_) et de l'IPv6  travers un tunnel GRE.

   Dans Linux, vous aurez besoin du module ip_gre.o.
     _________________________________________________________________

5.3.1. Le tunnel IPv4

   Dans un premier temps, intressons-nous au tunnel IPv4 :

   Disons que vous avez trois rseaux : 2 rseaux internes A et B, et un
   rseau intermdiaire C (ou disons internet).

   Les caractristiques du rseau A sont :
rseau 10.0.1.0
masque de sous-rseau 255.255.255.0
routeur  10.0.1.1

   Le routeur a l'adresse 172.16.17.18 sur le rseau C. Appelons ce
   rseau neta.

   Et pour le rseau B :
rseau 10.0.2.0
masque de sous-rseau 255.255.255.0
routeur  10.0.2.1

   Le routeur a l'adresse 172.19.20.21 sur le rseau C. Appelons ce
   rseau netb.

   En ce qui concerne le rseau C, nous supposerons qu'il transmettra
   n'importe quels paquets de A vers B et vice-versa. Comment et
   pourquoi, on s'en moque.

   Sur le routeur du rseau A, nous faisons la chose suivante :
ip tunnel add netb mode gre remote 172.19.20.21 local 172.16.17.18 ttl 255
ip link set netb up
ip addr add 10.0.1.1 dev netb
ip route add 10.0.2.0/24 dev netb

   Discutons un peu de cela. Sur la ligne 1, nous avons ajout un
   priphrique tunnel, que nous avons appel netb (ce qui est vident,
   dans la mesure o c'est l que nous voulons aller). De plus, nous lui
   avons dit d'utiliser le protocole GRE (mode gre), que l'adresse
   distante est 172.19.20.21 (le routeur de l'autre ct), que nos
   paquets << tunnels >> devront tre gnrs  partir de 172.16.17.18
   (ce qui autorise votre serveur  avoir plusieurs adresses IP sur le
   rseau C et ainsi vous permet de choisir laquelle sera utilise pour
   votre tunnel) et que le champ TTL de vos paquets sera fix  255 (ttl
   255).

   La deuxime ligne active le priphrique.

   Sur la troisime ligne, nous avons donn  cette nouvelle interface
   l'adresse 10.0.1.1. C'est bon pour de petits rseaux, mais quand vous
   commencez une exploitation minire (_BEAUCOUP_ de tunnels !), vous
   pouvez utiliser une autre gamme d'adresses IP pour vos interfaces
   << tunnel >> (dans cet exemple, vous pourriez utiliser 10.0.3.0).

   Sur la quatrime ligne, nous positionnons une route pour le rseau B.
   Notez la notation diffrente pour le masque de sous-rseau. Si vous
   n'tes pas familiaris avec cette notation, voici comment a marche :
   vous crivez le masque de sous-rseau sous sa forme binaire, et vous
   comptez tous les 1. Si vous ne savez pas comment faire cela,
   rappelez-vous juste que 255.0.0.0 est /8, 255.255.0.0 est /16 et
   255.255.255.0 est /24. Et 255.255.254.0 est /23, au cas o a vous
   intresserait.

   Mais arrtons ici, et continuons avec le routeur du rseau B.
ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
ip link set neta up
ip addr add 10.0.2.1 dev neta
ip route add 10.0.1.0/24 dev neta

   Et quand vous voudrez retirer le tunnel sur le routeur A :
ip link set netb down
ip tunnel del netb

   Bien sr, vous pouvez remplacer netb par neta pour le routeur B.
     _________________________________________________________________

5.3.2. Le tunnel IPv6

   Voir la section 6 pour une courte description des adresses IPv6.

    propos des tunnels.

   Supposons que vous ayez le rseau IPv6 suivant, et que vous vouliez le
   connecter  une dorsale IPv6 (6bone) ou  un ami.

   Rseau 3ffe:406:5:1:5:a:2:1/96

   Votre adresse IPv4 est 172.16.17.18, et le routeur 6bone a une adresse
   IPv4 172.22.23.24.
ip tunnel add sixbone mode sit remote 172.22.23.24 local 172.16.17.18 ttl 255
ip link set sixbone up
ip addr add 3ffe:406:5:1:5:a:2:1/96 dev sixbone
ip route add 3ffe::/15 dev sixbone

   Voyons cela de plus prs. Sur la premire ligne, nous avons cr un
   priphrique tunnel appel sixbone. Nous lui avons affect le mode sit
   (qui est le tunnel IPv6 sur IPv4) et lui avons dit o l'on va (remote)
   et d'o l'on vient (local). TTL est configur  son maximum : 255.
   Ensuite, nous avons rendu le priphrique actif (up). Puis, nous avons
   ajout notre propre adresse rseau et configur une route pour
   3ffe::/15  travers le tunnel.

   Les tunnels GRE constituent actuellement le type de tunnel prfr.
   C'est un standard qui est largement adopt, mme  l'extrieur de la
   communaut Linux, ce qui constitue une bonne raison de l'utiliser.
     _________________________________________________________________

5.4. Tunnels dans l'espace utilisateur

   Il y a des dizaines d'implmentations de tunnels  l'extrieur du
   noyau. Les plus connues sont bien sr PPP et PPTP, mais il y en a bien
   plus (certaines propritaires, certaines scuriss, d'autres qui
   n'utilisent pas IP), qui dpassent le cadre de ce HOWTO.
     _________________________________________________________________

Chapitre 6. Tunnel IPv6 avec Cisco et/ou une dorsale IPv6 (6bone)

   Par Marco Davids <marco@sara.nl>

   NOTE au mainteneur :

   En ce qui me concerne, ce tunnel IPv6-IPv4 n'est pas, par dfinition,
   un tunnel GRE. Vous pouvez raliser un tunnel IPv6 sur IPv4 au moyen
   des priphriques tunnels GRE (tunnels GRE _N'IMPORTE QUOI_ vers
   IPv4), mais le priphrique utilis ici (sit) ne permet que des
   tunnels IPv6 sur IPv4, ce qui est quelque chose de diffrent.
     _________________________________________________________________

6.1. Tunnel IPv6

   Voici une autre application des possibilits de tunnels de Linux.
   Celle-ci est populaire parmi les premiers adeptes d'IPv6 ou les
   pionniers si vous prfrez. L'exemple pratique dcrit ci-dessous n'est
   certainement pas la seule manire de raliser un tunnel IPv6.
   Cependant, c'est la mthode qui est souvent utilise pour raliser un
   tunnel entre Linux et un routeur Cisco IPv6 et l'exprience m'a appris
   que c'est ce type d'quipement que beaucoup de personnes ont. Dix
   contre un que ceci s'appliquera aussi pour vous ;-).

   De petites choses  propos des adresses IPv6 :

   Les adresses IPv6 sont, en comparaison avec les adresses IPv4,
   vraiment grandes : 128 bits contre 32 bits. Et ceci nous fournit la
   chose dont nous avons besoin : beaucoup, beaucoup d'adresses IP :
   340,282,266,920,938,463,463,374,607,431,768,211,465 pour tre prcis.
   A part ceci, IPv6 (ou IPng gnration suivante (_Next Generation_))
   est suppos fournir des tables de routage plus petites sur les
   routeurs des dorsales Internet, une configuration plus simple des
   quipements, une meilleure scurit au niveau IP et un meilleur
   support pour la Qualit de Service (QoS).

   Un exemple : 2002:836b:9820:0000:0000:0000:836b:9886

   Ecrire les adresses IPv6 peut tre un peu lourd. Il existe donc des
   rgles qui rendent la vie plus facile :

     * Ne pas utiliser les zros de tte, comme dans IPv4 ;
     * Utiliser des double-points de sparation tous les 16 bits ou 2
       octets ;
     * Quand vous avez beaucoup de zros conscutifs, vous pouvez crire
       ::. Vous ne pouvez, cependant, faire cela qu'une seule fois par
       adresse et seulement pour une longueur de 16 bits.

   L'adresse 2002:836b:9820:0000:0000:0000:836b:9886 peut tre crite
   2002:836b:9820::836b:9886, ce qui est plus amical.

   Un autre exemple : l'adresse 3ffe:0000:0000:0000:0000:0000:34A1:F32C
   peut tre crite 3ffe::20:34A1:F32C, ce qui est beaucoup plus court.

   IPv6 a pour but d'tre le successeur de l'actuel IPv4. Dans la mesure
   o cette technologie est relativement rcente, il n'y a pas encore de
   rseau natif IPv6  l'chelle mondiale. Pour permettre un
   dveloppement rapide, la dorsale IPv6 (6bone) a t introduite.

   Les rseaux natifs IPv6 sont interconnects grce  l'encapsulation du
   protocole IPv6 dans des paquets IPv4, qui sont envoys  travers
   l'infrastructure IPv4 existante, d'un site IPv6  un autre.

   C'est dans cette situation que l'on monte un tunnel.

   Pour tre capable d'utiliser IPv6, vous devrez avoir un noyau qui le
   supporte. Il y a beaucoup de bons documents qui expliquent la manire
   de raliser cela. Mais, tout se rsume  quelques tapes :

     * Rcuprer une distribution Linux rcente, avec une glibc
       convenable.
     * Rcuprer alors les sources  jour du noyau.

   Si tout cela est fait, vous pouvez alors poursuivre en compilant un
   noyau supportant l'IPv6 :

     * Aller dans /usr/src/linux et tapez :
     * make menuconfig
     * Choisir Networking Options
     * Slectionner The IPv6 protocol, IPv6: enable EUI-64 token format,
       IPv6: disable provider based addresses

   ASTUCE :Ne compiler pas ces options en tant que module. Ceci ne
   marchera souvent pas bien.

   En d'autres termes, compilez IPv6 directement dans votre noyau. Vous
   pouvez alors sauvegarder votre configuration comme d'habitude et
   entreprendre la compilation de votre noyau.

   ASTUCE: Avant de faire cela, modifier votre Makefile comme suit :
   EXTRAVERSION = -x ; --> ; EXTRAVERSION = -x-IPv6

   Il y a beaucoup de bonnes documentations sur la compilation et
   l'installation d'un noyau. Cependant, ce document ne traite pas de ce
   sujet. Si vous rencontrez des problmes  ce niveau, allez et
   recherchez dans la documentation des renseignements sur la compilation
   du noyau Linux correspondant  vos propres spcifications.

   Le fichier /usr/src/linux/README peut constituer un bon dpart. Aprs
   avoir ralis tout ceci, et redmarr avec votre nouveau noyau
   flambant neuf, vous pouvez lancer la commande _/sbin/ifconfig -a_ et
   noter un nouveau priphrique sit0. SIT signifie Transition Simple
   d'Internet (_Simple Internet Transition_). Vous pouvez vous
   auto-complimenter : vous avez maintenant franchi une tape importante
   vers IP, la prochaine gnration ;-)

   Passons maintenant  l'tape suivante. Vous voulez connecter votre
   hte ou peut-tre mme tout votre rseau LAN  d'autres rseaux IPv6.
   Cela pourrait tre la dorsale IPv6 << 6bone >> qui a t spcialement
   mise en place dans ce but particulier.

   Supposons que vous avez le rseau IPv6 suivant : 3ffe:604:6:8::/64 et
   que vous vouliez le connecter  une dorsale IPv6 ou  un ami. Notez,
   s'il vous plat, que la notation sous-rseau /64 est similaire  celle
   des adresses IPv4.

   Votre adresse IPv4 est 145.100.24.181 et le routeur 6bone a l'adresse
   IPv4 145.100.1.5.
# ip tunnel add sixbone mode sit remote 145.100.1.5 [local 145.100.24.181 ttl 2
25]
# ip link set sixbone up
# ip addr add 3FFE:604:6:7::2/96 dev sixbone
# ip route add 3ffe::0/15 dev sixbone

   Discutons de ceci. Dans la premire ligne, nous avons cr un
   priphrique appel sixbone. Nous lui avons donn l'attribut sit (mode
   sit) (qui est le tunnel IPv6 dans IPv4) et nous lui avons dit o aller
   (remote) et d'o nous venions (local). TTL est configur  son
   maximum, 255.

   Ensuite, nous avons rendu le priphrique actif (up). Aprs cela, nous
   avons ajout notre propre adresse rseau et configur une route pour
   3ffe::/15 (qui est actuellement la totalit du 6bone)  travers le
   tunnel. Si la machine sur laquelle vous mettez en place tout ceci est
   votre passerelle IPv6, ajoutez alors les lignes suivantes :
# echo 1 >/proc/sys/net/ipv6/conf/all/forwarding
# /usr/local/sbin/radvd

   En dernire instruction, radvd est un dmon d'annonce comme zebra qui
   permet de supporter les fonctionnalits d'autoconfiguration d'IPv6.
   Recherchez le avec votre moteur de recherche favori. Vous pouvez
   vrifier les choses comme ceci :
   # /sbin/ip -f inet6 addr

   Si vous arrivez  avoir radvd tournant sur votre passerelle IPv6 et
   que vous dmarrez une machine avec IPv6 sur votre rseau local, vous
   serez ravi de voir les bnfices de l'autoconfiguration IPv6 :
# /sbin/ip -f inet6 addr
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue inet6 ::1/128 scope host

3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
inet6 3ffe:604:6:8:5054:4cff:fe01:e3d6/64 scope global dynamic
valid_lft forever preferred_lft 604646sec inet6 fe80::5054:4cff:fe01:e3d6/10
scope link

   Vous pouvez maintenant configurer votre serveur de noms pour les
   adresses IPv6. Le type A a un quivalent pour IPv6 : AAAA.
   L'quivalent de in-addr.arpa est : ip6.int. Il y a beaucoup
   d'informations disponibles sur ce sujet.

   Il y a un nombre croissant d'applications IPv6 disponibles, comme le
   shell scuris, telnet, inetd, le navigateur Mozilla, le serveur web
   Apache et beaucoup d'autres. Mais ceci est en dehors du sujet de ce
   document de routage ;-).

   Du ct Cisco, la configuration ressemblera  ceci :
!
interface Tunnel1
description IPv6 tunnel
no ip address
no ip directed-broadcast
ipv6 enable
ipv6 address 3FFE:604:6:7::1/96
tunnel source Serial0
tunnel destination 145.100.24.181
tunnel mode ipv6ip
!
ipv6 route 3FFE:604:6:8::/64 Tunnel1

   Si vous n'avez pas un Cisco  votre disposition, essayez un des
   prestataires de tunnel IPv6 disponible sur Internet. Ils sont prts 
   configurer leur Cisco avec un tunnel supplmentaire pour vous, le plus
   souvent au moyen d'une agrable interface web. Cherchez _ipv6 tunnel
   broker_ avec votre moteur de recherche favori.
     _________________________________________________________________

Chapitre 7. IPsec : IP scuris  travers l'Internet

   FIXME: Pas de rdacteur. En attendant, voir: Le projet FreeS/WAN.
   Cerberus du NIST est une autre implmentation de IPSec pour Linux.
   Cependant, leurs pages web n'ont pas t mis  jour depuis plus d'un
   an et leur version a tendance  tre trs nettement  la trane par
   rapport aux dernires versions du noyau. USAGI, une implmentation
   alternative d'IPv6 pour Linux, inclue galement une partie IPSec, mais
   qui n'est que pour IPv6.
     _________________________________________________________________

Chapitre 8. Routage multidistribution (_multicast_)

   FIXME: Pas de rdacteur !

   Le Multicast-HOWTO est (relativement) ancien. De ce fait, il peut tre
   imprcis ou induire en erreur  certains endroits.

   Avant que vous ne puissiez faire du routage multidistribution, le
   noyau Linux a besoin d'tre configur pour supporter le type de
   routage multidistribution que vous voulez faire. Ceci,  son tour,
   exige une dcision quant au choix du protocole de routage
   multidistribution que vous vous prparez  utiliser. Il y a
   essentiellement quatre types << communs >> de protocoles : DVMRP (la
   version multidistribution du protocole RIP unicast), MOSPF (la mme
   chose, mais pour OSPF), PIM-SM (_Protocol Independant Multicasting -
   Sparse Mode_) qui suppose que les utilisateurs de n'importe quel
   groupe de multidistribution sont disperss plutt que regroups) et
   PIM-DM (le mme, mais _Dense Mode_) qui suppose qu'il y aura un
   regroupement significatif des utilisateurs d'un mme groupe de
   multidistribution.

   On pourra noter que ces options n'apparaissent pas dans le noyau
   Linux. Ceci s'explique par le fait que le protocole lui-mme est gr
   par une application de routage, comme Zebra, mrouted ou pind.
   Cependant, vous devez avoir une bonne ide de ce que vous allez
   utiliser, de manire  slectionner les bonnes options dans le noyau.

   Pour tout routage multidistribution, vous avez forcment besoin de
   slectionner les options multicasting et multicasting routing. Ceci
   est suffisant pour DVMRP et MOSPF. Dans le cas de PIM, vous devez
   galement valider les options PIMv1 ou PIMv2 suivant que le rseau que
   vous connectez utilise la version 1 ou 2 du protocole PIM.

   Une fois que tout cela a t ralis, et que votre nouveau noyau a t
   compil, vous verrez au dmarrage que IGMP est inclus dans la liste
   des protocoles IP. Celui-ci est un protocole permettant de grer les
   groupes multidistribution. Au moment de la rdaction, Linux ne
   supportait que les versions 1 et 2 de IGMP, bien que la version 3
   existe et ait t documente. Ceci ne va pas vraiment nous affecter
   dans la mesure o IGMPv3 est encore trop rcent pour que ses
   fonctionnalits supplmentaires soient largement utilises. Puisque
   IGMP s'occupe des groupes, seules les fonctionnalits prsentes dans
   la plus simple version de IGMP grant un groupe entier seront
   utilises. IGMPv2 sera utilis dans la plupart des cas, bien que
   IGMPv1 puisse encore tre rencontr.

   Jusque-l, c'est bon. Nous avons activ la multidistribution. Nous
   devons dire au noyau de l'utiliser concrtement. Nous allons donc
   dmarrer le routage. Ceci signifie que nous ajoutons un rseau virtuel
   de multidistribution  la table du routeur :
   ip route add 224.0.0.0/4 dev eth0

   (En supposant bien sr, que vous diffusez  travers eth0 !
   Remplacez-le par le priphrique de votre choix, si ncessaire.)

   Maintenant, dire  Linux de transmettre les paquets...
   echo 1 > /proc/sys/net/ipv4/ip_forward

   Arriv ici, il se peut que vous vous demandiez si ceci va faire
   quelque chose. Donc, pour tester notre connexion, nous pinguons le
   groupe par dfaut, 224.0.0.1, pour voir si des machines sont
   prsentes. Toutes les machines du rseau local avec la
   multidistribution active _DEVRAIENT_ rpondre, et aucune autre. Vous
   remarquerez qu'aucune des machines qui rpondent ne le fait avec
   l'adresse IP 224.0.0.1. Quelle surprise ! :) Ceci est une adresse de
   groupe (une << diffusion >> pour les abonns) et tous les membres du
   groupe rpondront avec leur propre adresse, et non celle du groupe.
   ping -c 2 224.0.0.1

   Maintenant, vous tes prt  faire du vrai routage multidistribution.
   Bien, en supposant que vous ayez deux rseaux  router l'un vers
   l'autre.

   (A continuer !)
     _________________________________________________________________

Chapitre 9. Gestionnaires de mise en file d'attente pour l'administration de
la bande passante

   Quand je l'ai dcouvert, cela m'a _VRAIMENT_ souffl. Linux 2.2
   contient toutes les fonctionnalits pour la gestion de la bande
   passante, de manire comparable  un systme ddi de haut niveau.

   Linux dpasse mme ce que l'ATM et le Frame peuvent fournir.

   Afin d'viter toute confusion, voici les rgles utilises par _tc_
   pour la spcification de la bande passante :

mbps = 1024 kbps = 1024 * 1024 bps => byte/s (octets/s)
mbit = 1024 kbit => kilo bit/s.
mb = 1024 kb = 1024 * 1024 b => byte (octet)
mbit = 1024 kbit => kilo bit.

   En interne, les nombres sont stocks en bps et b.

   Mais _tc_ utilise l'unit suivante lors de l'affichage des dbits :

1Mbit = 1024 Kbit = 1024 * 1024 bps => bit/s
     _________________________________________________________________

9.1. Explication sur les files d'attente et la gestion de la mise en file
d'attente

   Avec la mise en file d'attente, nous dterminons la manire dont les
   donnes sont _ENVOYEES_. Il est important de comprendre que nous ne
   pouvons mettre en forme que les donnes que nous transmettons.

   Avec la manire dont Internet travaille, nous n'avons pas de contrle
   direct sur ce que les personnes nous envoient. C'est un peu comme
   votre bote aux lettres (physique !) chez vous. Il n'y a pas de faon
   d'influencer le nombre de lettres que vous recevez,  moins de
   contacter tout le monde.

   Cependant, l'Internet est principalement bas sur TCP/IP qui possde
   quelques fonctionnalits qui vont pouvoir nous aider. TCP/IP n'a pas
   d'aptitude  connatre les performances d'un rseau entre deux htes.
   Il envoie donc simplement des paquets de plus en plus rapidement
   (<< _slow start_ >>) et quand des paquets commencent  se perdre, il
   ralentit car il n'a plus la possibilit de les envoyer. En fait, c'est
   un peu plus lgant que cela, mais nous en dirons plus par la suite.

   C'est comme si vous ne lisiez que la moiti de votre courrier en
   esprant que vos correspondants arrteront de vous en envoyer.  la
   diffrence que a marche sur Internet :-)

   Si vous avez un routeur et que vous souhaitez viter que certains
   htes de votre rseau aient des vitesses de tlchargement trop
   grandes, vous aurez besoin de mettre en place de la mise en forme de
   trafic sur l'interface _INTERNE_ de votre routeur, celle qui envoie
   les donnes vers vos propres ordinateurs.

   Vous devez galement tre sr que vous contrlez le goulot
   d'tranglement de la liaison. Si vous avez une carte rseau  100Mbit
   et un routeur avec un lien  256kbit, vous devez vous assurer que vous
   n'envoyez pas plus de donnes que ce que le routeur peut manipuler.
   Autrement, ce sera le routeur qui contrlera le lien et qui mettra en
   forme la bande passante disponible. Nous devons pour ainsi dire
   << tre le propritaire de la file d'attente >> et tre le lien le
   plus lent de la chane. Heureusement, c'est facilement ralisable.
     _________________________________________________________________

9.2. Gestionnaires de mise en file d'attente simples, sans classes

   Comme nous l'avons dj dit, la gestion de mise en file d'attente
   permet de modifier la faon dont les donnes sont envoyes. Les
   gestionnaires de mise en file d'attente sans classes sont ceux qui, en
   gros, acceptent les donnes et qui ne font que les rordonner, les
   retarder ou les jeter.

   Ils peuvent tre utiliss pour mettre en forme le trafic d'une
   interface sans aucune subdivision. Il est primordial que vous
   compreniez cet aspect de la mise en file d'attente avant de continuer
   sur les gestionnaires de mise en files d'attente bass sur des classes
   contenant d'autres gestionnaires de mise en file d'attente.

   Le gestionnaire le plus largement utilis est de loin pfifo_fast, qui
   est celui par dfaut. Ceci explique aussi pourquoi ces fonctionnalits
   avances sont si robustes. Elles ne sont rien de plus << qu'une autre
   file d'attente >>.

   Chacune de ces files d'attente a ses forces et ses faiblesses. Toutes
   n'ont peut-tre pas t bien testes.
     _________________________________________________________________

9.2.1. pfifo_fast

   Cette file d'attente, comme son nom l'indique : premier entr, premier
   sorti (_First In First Out_), signifie que les paquets ne subissent
   pas de traitements spciaux. En fait, ce n'est pas tout  fait vrai.
   Cette file d'attente a trois << bandes >>. A l'intrieur de chacune de
   ces bandes, des rgles FIFO s'appliquent. Cependant, tant qu'il y a un
   paquet en attente dans la bande 0, la bande 1 ne sera pas traite. Il
   en va de mme pour la bande 1 et la bande 2.

   Le noyau prend en compte la valeur du champ Type de Service des
   paquets et prend soin d'insrer dans la bande 0 les paquets ayant le
   bit << dlai minimum >> activ.

   Ne pas confondre ce gestionnaire de mise en file d'attente sans
   classes avec celui bas sur des classes PRIO ! Bien qu'ils aient des
   comportements similaires, pfifo_fast ne possde pas de classes et vous
   ne pourrez pas y ajouter de nouveaux gestionnaires avec la commande
   _tc_.
     _________________________________________________________________

9.2.1.1. Paramtres & usage

   Vous ne pouvez pas configurer le gestionnaire pfifo_fast, dans la
   mesure o c'est celui par dfaut. Voici sa configuration par dfaut :

   priomap
          Dtermine comment les priorits des paquets sont relies aux
          bandes, telles que dfinies par le noyau. La relation est
          tablie en se basant sur l'octet TOS du paquet, qui ressemble 
          ceci :


   0     1     2     3     4     5     6     7
+-----+-----+-----+-----+-----+-----+-----+-----+
|                 |                       |     |
|   PRECEDENCE    |          TOS          | MBZ |
|                 |                       |     |
+-----+-----+-----+-----+-----+-----+-----+-----+

          Les quatre bits TOS (le champ TOS) sont dfinis comme suit :


Binaire Dcimal   Signification
-----------------------------------------
1000    8         Minimise le Dlai (Minimize delay) (md)
0100    4         Maximalise le Dbit (Maximize throughput) (mt)
0010    2         Maximalise la Fiabilit (Maximize reliability) (mr)
0001    1         Minimalise le Cot Montaire (Minimize monetary cost) (mmc)
0000    0         Service Normal

          Comme il y a 1 bit sur la droite de ces quatre bits, la valeur
          relle du champ TOS est le double de la valeur des bits TOS.
          tcpdump -v -v fournit la valeur de tout le champ TOS, et non
          pas seulement la valeur des quatre bits. C'est la valeur que
          l'on peut voir dans la premire colonne du tableau suivant :


TOS     Bits  Signification                     Priorit Linux    Bande
------------------------------------------------------------------------
0x0     0     Service Normal                    0 Best Effort     1
0x2     1     Minimise le Cot Montaire (mmc)  1 Filler          2
0x4     2     Maximalise la Fiabilit (mr)      0 Best Effort     1
0x6     3     mmc+mr                            0 Best Effort     1
0x8     4     Maximalise le Dbit (mt)          2 Masse           2
0xa     5     mmc+mt                            2 Masse           2
0xc     6     mr+mt                             2 Masse           2
0xe     7     mmc+mr+mt                         2 Masse           2
0x10    8     Minimise le Dlai (md)            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. Masse      1
0x1a    13    mmc+mt+md                         4 Int. Masse      1
0x1c    14    mr+mt+md                          4 Int. Masse      1
0x1e    15    mmc+mr+mt+md                      4 Int. Masse      1

          [NdT : par flux de masse (_bulk flow_), il faut entendre
          << gros flot de donnes transmises en continu >> comme un
          transfert FTP. A l'oppos, un flux interactif (_interactive
          flow_), correspond  celui gnr par des requtes SSH].

          Beaucoup de nombres. La seconde colonne contient la valeur
          correspondante des quatre bits TOS, suivi de leur
          signification. Par exemple, 15 reprsente un paquet voulant un
          cot montaire minimal, une fiabilit maximum, un dbit maximum
          _ET_ un dlai minimum. J'appellerai ceci un << paquet
          Hollandais >>.

          La quatrime colonne liste la manire dont le noyau Linux
          interprte les bits TOS, en indiquant  quelle priorit ils
          sont relis.

          La dernire colonne montre la carte des priorits par dfaut.
          Sur la ligne de commande, la carte des priorits ressemble 
          ceci :

1, 2, 2, 2, 1, 2, 0, 0 , 1, 1, 1, 1, 1, 1, 1, 1

          Ceci signifie , par exemple, que la priorit 4 sera relie  la
          bande numro 1. La carte des priorits vous permet galement de
          lister des priorits plus grandes (> 7) qui ne correspondent
          pas  une relation avec le champ TOS, mais qui sont configures
          par d'autres moyens.

          Le tableau suivant provenant de la RFC 1349 ( lire pour plus
          de dtails) indique comment les applications devraient
          configurer leurs bits TOS pour fonctionner correctement :

TELNET                    1000           (minimise le dlai)
FTP
        Contrle          1000           (minimise le dlai)
        Donnes           0100           (maximalise le dbit)

TFTP                      1000           (minimise le dlai)

SMTP
        phase de commande 1000           (minimise le dlai)
        phase DATA        0100           (maximalise le dbit)

Domain Name Service
        requte UDP       1000           (minimise le dlai)
        requte TCP       0000
        Transfert de Zone 0100           (maximalise le dbit)

NNTP                      0001           (minimise le cot montaire)

ICMP
        Erreurs           0000
        Requtes          0000 (presque)
        Rponses         <mme chose que requte> (presque)

   txqueuelen
          La longueur de cette file d'attente est fournie par la
          configuration de l'interface, que vous pouvez voir et
          configurer avec _ifconfig_ et _ip_. Pour configurer la longueur
          de la file d'attente  10, excuter : ifconfig eth0 txqueuelen
          10

          Vous ne pouvez pas configurer ce paramtre avec _tc_ !
     _________________________________________________________________

9.2.2. Filtre  seau de jetons (_Token Bucket Filter_)

   Le _Token Bucket Filter_ (TBF) est un gestionnaire de mise en file
   d'attente simple. Il ne fait que laisser passer les paquets entrants
   avec un dbit n'excdant pas une limite fixe administrativement.
   L'envoi de courtes rafales de donnes avec un dbit dpassant cette
   limite est cependant possible.

   TBF est trs prcis, et peu gourmand du point de vue rseau et
   processeur. Considrez-le en premier si vous voulez simplement
   ralentir une interface !

   L'implmentation TBF consiste en un tampon (seau), constamment rempli
   par des lments virtuels d'information appels jetons, avec un dbit
   spcifique (dbit de jeton). Le paramtre le plus important du tampon
   est sa taille, qui correspond au nombre de jetons qu'il peut stocker.

   Chaque jeton entrant laisse sortir un paquet de donnes de la file
   d'attente de donnes et ce jeton est alors supprim du seau.
   L'association de cet algorithme avec les deux flux de jetons et de
   donnes, nous conduit  trois scnarios possibles :

     * Les donnes arrivent dans TBF avec un dbit _EGAL_ au dbit des
       jetons entrants. Dans ce cas, chaque paquet entrant a son jeton
       correspondant et passe la file d'attente sans dlai.
     * Les donnes arrivent dans TBF avec un dbit _PLUS PETIT_ que le
       dbit des jetons. Seule une partie des jetons est supprime au
       moment o les paquets de donnes sortent de la file d'attente, de
       sorte que les jetons s'accumulent jusqu' atteindre la taille du
       tampon. Les jetons libres peuvent tre utiliss pour envoyer des
       donnes avec un dbit suprieur au dbit des jetons standard, si
       de courtes rafales de donnes arrivent.
     * Les donnes arrivent dans TBF avec un dbit _PLUS GRAND_ que le
       dbit des jetons. Ceci signifie que le seau sera bientt dpourvu
       de jetons, ce qui provoque l'arrt de TBF pendant un moment. Ceci
       s'appelle << une situation de dpassement de limite >> (_overlimit
       situation_). Si les paquets continuent  arriver, ils commenceront
        tre limins.

   Le dernier scnario est trs important, car il autorise la mise en
   forme administrative de la bande passante disponible pour les donnes
   traversant le filtre.

   L'accumulation de jetons autorise l'mission de courtes rafales de
   donnes sans perte en situation de dpassement de limite, mais toute
   surcharge prolonge causera systmatiquement le retard des paquets,
   puis leur rejet.

   Notez que, dans l'implmentation relle, les jetons correspondent 
   des octets, et non des paquets.
     _________________________________________________________________

9.2.2.1. Paramtres & usage

   Mme si vous n'aurez probablement pas besoin de les changer, TBF a des
   paramtres. D'abord, ceux toujours disponibles sont :

   limit or latency
          Limit est le nombre d'octets qui peuvent tre mis en file
          d'attente en attendant la disponibilit de jetons. Vous pouvez
          galement indiquer ceci d'une autre manire en configurant le
          paramtre latency, qui spcifie le temps maximal pendant lequel
          un paquet peut rester dans TBF. Ce dernier paramtre prend en
          compte la taille du seau, le dbit, et s'il est configur, le
          dbit de crte (peakrate).

   burst/buffer/maxburst
          Taille du seau, en octets. C'est la quantit maximale, en
          octets, de jetons dont on disposera simultanment. En gnral,
          plus les dbits de mise en forme sont importants, plus le
          tampon doit tre grand. Pour 10 Mbit/s sur plateforme Intel,
          vous avez besoin d'un tampon d'au moins 10 kilo-octets si vous
          voulez atteindre la limitation configure !

          Si votre tampon est trop petit, les paquets pourront tre
          rejets car il arrive plus de jetons par top d'horloge que ne
          peut en contenir le tampon.

   mpu
          Un paquet de taille nulle n'utilise pas une bande passante
          nulle. Pour ethernet, la taille minimale d'un paquet est de 64
          octets. L'Unit Minimale de Paquet (_Minimun Packet Unit_)
          dtermine le nombre minimal de jetons  utiliser pour un
          paquet.

   rate
          Le paramtre de la vitesse. Voir les remarques au-dessus 
          propos des limites !

   Si le seau contient des jetons et qu'il est autoris  se vider, alors
   il le fait par dfaut avec une vitesse infinie. Si ceci vous semble
   inacceptable, utilisez les paramtres suivants :

   peakrate
          Si des jetons sont disponibles et que des paquets arrivent, ils
          sont immdiatement envoys par dfaut ; et pour ainsi dire 
          << la vitesse de la lumire >>. Cela peut ne pas vous convenir,
          spcialement si vous avez un grand seau.

          Le dbit de crte (_peak rate_) peut tre utilis pour
          spcifier la vitesse  laquelle le seau est autoris  se
          vider. Si tout se passe comme crit dans les livres, ceci est
          ralis en librant un paquet, puis en attendant suffisamment
          longtemps, pour librer le paquet suivant. Le temps d'attente
          est calcul de manire  obtenir un dbit gal au dbit de
          crte.

          Cependant, tant donn que la rsolution du minuteur (_timer_)
          d'UNIX est de 10 ms et que les paquets ont une taille moyenne
          de 10 000 bits, nous sommes limits  un dbit de crte de
          1mbit/s !

   mtu/minburst
          Le dbit de crte de 1Mb/s ne sert pas  grand chose si votre
          dbit habituel est suprieur  cette valeur. Un dbit de crte
          plus lev peut tre atteint en mettant davantage de paquets
          par top du minuteur, ce qui a pour effet de crer un second
          seau.

          Ce second _bucket_ ne prend par dfaut qu'un seul paquet, et
          n'est donc en aucun cas un seau.

          Pour calculer le dbit de crte maximum, multipliez le _mtu_
          que vous avez configur par 100 (ou plus exactement par HZ, qui
          est gal  100 sur Intel et  1024 sur Alpha).
     _________________________________________________________________

9.2.2.2. Configuration simple

   Voici une configuration simple, mais _trs_ utile :
   # tc qdisc add dev ppp0 root tbf rate 220kbit latency 50ms burst 1540

   Pourquoi est-ce utile ? Si vous avez un priphrique rseau avec une
   grande file d'attente, comme un modem DSL ou un modem cble, et que le
   dialogue se fasse  travers une interface rapide, comme une interface
   ethernet, vous observerez que tlcharger vers l'amont (_uploading_)
   dgrade compltement l'interactivit.

   [NdT : _uploading_ dsigne une opration qui consiste  transfrer des
   donnes ou des programmes stocks dans un ordinateur local vers un
   ordinateur distant  travers un rseau. La traduction officielle pour
   ce terme est << tlchargement vers l'amont >>. On parle alors de voie
   montante. Le _downloading_ dsigne l'opration inverse (transfert d'un
   hte distant vers l'ordinateur local) et est traduit par
   << tlchargement >> ou << tlchargement vers l'aval >>. On parle
   alors de la voie descendante.]

   Le tlchargement vers l'amont va en effet remplir la file d'attente
   du modem. Celle-ci est probablement _ENORME_ car cela aide vraiment 
   obtenir de bon dbit de tlchargement vers l'amont. Cependant, ceci
   n'est pas forcment ce que voulez. Vous ne voulez pas forcment avoir
   une file d'attente importante de manire  garder l'interactivit et
   pouvoir encore faire des choses pendant que vous envoyez des donnes.

   La ligne de commande au-dessus ralentit l'envoi de donnes  un dbit
   qui ne conduit pas  une mise en file d'attente dans le modem. La file
   d'attente rside dans le noyau Linux, o nous pouvons lui imposer une
   taille limite.

   Modifier la valeur 220kbit avec votre vitesse de lien _REELLE_ moins
   un petit pourcentage. Si vous avez un modem vraiment rapide, augmenter
   un peu le paramtre burst.
     _________________________________________________________________

9.2.3. Mise en file d'attente stochastiquement quitable (_Stochastic
Fairness Queueing_)

   _Stochastic Fairness Queueing_ (SFQ) est une implmentation simple de
   la famille des algorithmes de mise en file d'attente quitable. Cette
   implmentation est moins prcise que les autres, mais elle ncessite
   aussi moins de calculs tout en tant presque parfaitement quitable.

   Le mot cl dans SFQ est conversation (ou flux), qui correspond
   principalement  une session TCP ou un flux UDP. Le trafic est alors
   divis en un grand nombre de jolies files d'attente FIFO : une par
   conversation. Le trafic est alors envoy dans un tourniquet, donnant
   une chance  chaque session d'envoyer leurs donnes tour  tour.

   Ceci conduit  un comportement trs quitable et empche qu'une seule
   conversation touffe les autres. SFQ est appel << Stochastic >> car
   il n'alloue pas vraiment une file d'attente par session, mais a un
   algorithme qui divise le trafic  travers un nombre limit de files
   d'attente en utilisant un algorithme de hachage.

   A cause de ce hachage, plusieurs sessions peuvent finir dans le mme
   seau, ce qui peut rduire de moiti les chances d'une session
   d'envoyer un paquet et donc rduire de moiti la vitesse effective
   disponible. Pour empcher que cette situation ne devienne importante,
   SFQ change trs souvent son algorithme de hachage pour que deux
   sessions entrantes en collision ne le fassent que pendant un nombre
   rduit de secondes.

   Il est important de noter que SFQ n'est seulement utile que dans le
   cas o votre interface de sortie est vraiment sature ! Si ce n'est
   pas le cas, il n'y aura pas de files d'attente sur votre machine Linux
   et donc, pas d'effets. Plus tard, nous dcrirons comment combiner SFQ
   avec d'autres gestionnaires de mise en files d'attente pour obtenir le
   meilleur des deux mondes.

   Configurer spcialement SFQ sur l'interface ethernet qui est en
   relation avec votre modem cble ou votre routeur DSL est vain sans
   d'autres mises en forme du trafic !
     _________________________________________________________________

9.2.3.1. Paramtres & usage

   SFQ est presque configur de base :

   perturb
          Reconfigure le hachage une fois toutes les pertub secondes.
          S'il n'est pas indiqu, le hachage se sera jamais reconfigur.
          Ce n'est pas recommand. 10 secondes est probablement une bonne
          valeur.

   quantum
          Nombre d'octets qu'un flux est autoris  retirer de la file
          d'attente avant que la prochaine file d'attente ne prenne son
          tour. Par dfaut, gal  la taille maximum d'un paquet (MTU).
          Ne le configurez pas en-dessous du MTU !
     _________________________________________________________________

9.2.3.2. Configuration simple

   Si vous avez un priphrique qui a une vitesse identique  celle du
   lien et un dbit rel disponible, comme un modem tlphonique, cette
   configuration aidera  promouvoir l'quit :
# tc qdisc add dev ppp0 root sfq perturb 10
# tc -s -d qdisc ls
qdisc sfq 800c: dev ppp0 quantum 1514b limit 128p flows 128/1024 perturb 10sec
 Sent 4812 bytes 62 pkts (dropped 0, overlimits 0)

   Le nombre 800c est un descripteur (_handle_) automatiquement assign
   et limit signifie que 128 paquets peuvent attendre dans la file
   d'attente. Il y a 1024 << seaux de hachage >> disponibles pour la
   comptabilit, 128 pouvant tre actifs  la fois (pas plus de paquets
   ne conviennent dans la file d'attente). Le hachage est reconfigur
   toutes les 10 secondes.
     _________________________________________________________________

9.3. Conseils pour le choix de la file d'attente

   Pour rsumer, ces files d'attente simples grent le trafic en
   rordonnant, en ralentissant ou en supprimant les paquets.

   Les astuces suivantes peuvent vous aider  choisir la file d'attente 
   utiliser. Elles mentionnent certaines files d'attente dcrites dans le
   chapitre _Gestionnaires de mise en file d'attente avancs_.

     * Pour simplement ralentir le trafic sortant, utilisez le _Token
       Bucket Filter_. Il convient bien pour les normes bandes
       passantes, si vous paramtrez en consquence le seau.
     * Si votre lien est vraiment satur et que vous voulez tre sr
       qu'aucune session ne va accaparer la bande passante vers
       l'extrieur, utilisez le _Stochastical Fairness Queueing_.
     * Si vous avez une grande dorsale et que vous voulez savoir ce que
       vous fates, considrez _Random Early Drop_ (voir le chapitre
       _Gestionnaires de mise en file d'attente avancs_).
     * Pour << mettre en forme >> le trafic entrant qui n'est pas
       transmis, utilisez la rglementation Ingress (_Ingress Policier_).
       La mise en forme du flux entrant est appele << rglementation >>
       (_policing_) et non << mise en forme >> (_shaping_).
     * Si vous transmettez le trafic, utilisez TBF sur l'interface vers
       laquelle vous transmettez les donnes. Si vous voulez mettre en
       forme un trafic pouvant sortir par plusieurs interfaces, alors le
       seul facteur commun est l'interface entrante. Dans ce cas,
       utilisez la rglementation Ingress.
     * Si vous ne voulez pas mettre en forme le trafic, mais que vous
       vouliez voir si votre interface est tellement charge qu'elle a d
       mettre en file d'attente les donnes, utilisez la file d'attente
       pfifo (pas pfifo_fast). Elle n'a pas de bandes internes, mais
       assure le comptage de la taille de son accumulateur.
     * Finalement, vous pouvez aussi faire de la << mise en forme
       sociale >>. La technologie n'est pas toujours capable de raliser
       ce que vous voulez. Les utilisateurs sont hostiles aux contraintes
       techniques. Un mot aimable peut galement vous aider  avoir votre
       bande passante correctement divise !
     _________________________________________________________________

9.4. Terminologie

   Pour comprendre correctement des configurations plus compliques, il
   est d'abord ncessaire d'expliquer quelques concepts. A cause de la
   complexit et de la relative jeunesse du sujet, beaucoup de mots
   diffrents sont utiliss par les personnes mais ils signifient en fait
   la mme chose.

   Ce qui suit est lchement inspir du texte
   draft-ietf-diffserv-model-06.txt, _An Informal Management Model for
   Diffserv Routers_. Il peut tre trouv  l'adresse
   http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-04.txt.

   Lisez-le pour les dfinitions strictes des termes utiliss.

   Gestionnaire de mise en file d'attente (_Queueing Discipline_)
          Un algorithme qui gre la file d'attente d'un priphrique,
          soit pour les donnes entrantes (_ingress_), soit pour les
          donnes sortantes (_egress_).

   Gestionnaire de mise en file d'attente sans classes (_Classless
          qdisc_)
          Un gestionnaire de mise en file d'attente qui n'a pas de
          subdivisions internes configurables.

   Gestionnaire de mise en file d'attente bas sur des classes (_Classful
          qdisc_)
          Un gestionnaire de mise en file d'attente bas sur des classes
          contient de multiples classes. Chacune de ces classes contient
          un gestionnaire de mise en file d'attente supplmentaire, qui
          peut encore tre bas sur des classes, mais ce n'est pas
          obligatoire. Si l'on s'en tient  la dfinition stricte,
          pfifo_fast _EST_ bas sur des classes, dans la mesure o il
          contient trois bandes, qui sont en fait des classes. Cependant,
          d'un point de vue des perspectives de configuration pour
          l'utilisateur, il est sans classes dans la mesure o ces
          classes ne peuvent tre modifies avec l'outil _tc_.

   Classes
          Un gestionnaire de mise en file d'attente peut avoir beaucoup
          de classes, chacune d'elles tant internes au gestionnaire.
          Chacune de ces classes peut contenir un gestionnaire de mise en
          file d'attente rel.

   Classificateur (_Classifier_)
          Chaque gestionnaire de mise en file d'attente bas sur des
          classes a besoin de dterminer vers quelles classes il doit
          envoyer un paquet. Ceci est ralis en utilisant le
          classificateur.

   Filtre (_Filter_)
          La classification peut tre ralise en utilisant des filtres.
          Un filtre est compos d'un certain nombre de conditions qui, si
          elles sont toutes vrifies, satisfait le filtre.

   Ordonnancement (_Scheduling_)
          Un gestionnaire de mise en file d'attente peut, avec l'aide
          d'un classificateur, dcider que des paquets doivent sortir
          plus tt que d'autres. Ce processus est appel ordonnancement
          (_scheduling_), et est ralis par exemple par le gestionnaire
          pfifo_fast mentionn plus tt. L'ordonnancement est aussi
          appel << reclassement >> (_reordering_), ce qui peut prter 
          confusion.

   Mise en forme (_Shaping_)
          Le processus qui consiste  retarder l'mission des paquets
          sortants pour avoir un trafic conforme  un dbit maximum
          configur. La mise en forme est ralise sur _egress_.
          Familirement, rejeter des paquets pour ralentir le trafic est
          galement souvent appel Mise en forme.

   Rglementation (_Policing_)
          Retarder ou jeter des paquets dans le but d'avoir un trafic
          restant en dessous d'une bande passante configure. Dans Linux,
          la rglementation ne peut que jeter un paquet, et non le
          retarder dans la mesure o il n'y a pas de << file d'attente
          d'entre >> (_ingress queue_).

   _Work-Conserving_
          Un gestionnaire de mise en file d'attente _work-conserving_
          dlivre toujours un paquet s'il y en a un de disponible. En
          d'autres termes, il ne retarde jamais un paquet si l'adaptateur
          rseau est prt  l'envoyer (dans le cas du gestionnaire
          _egress_).

   _non-Work-Conserving_
          Quelques gestionnaire de mise en files d'attente, comme par
          exemple le _Token Bucket Filter_, peuvent avoir besoin de
          maintenir un paquet pendant un certain temps pour limiter la
          bande passante. Ceci signifie qu'ils refusent parfois de
          librer un paquet, bien qu'ils en aient un de disponible.

   Maintenant que nous avons dfini notre terminologie, voyons o tous
   ces lements sont situs.

                Programmes Utilisateurs
                     ^
                     |
     +---------------+-------------------------------------------+
     |               Y                                           |
     |    -------> Pile IP                                       |
     |   |              |                                        |
     |   |              Y                                        |
     |   |              Y                                        |
     |   ^              |                                        |
     |   |  / ----------> Transmission ->                        |
     |   ^ /                           |                         |
     |   |/                            Y                         |
     |   |                             |                         |
     |   ^                             Y            /-qdisc1-\   |
     |   |                          Classificateur /--qdisc2--\  |
  --->->Gestionnaire de mise        de sortie      ---qdisc3---- | ->
     |  en file d'attente           (Egress)       \__qdisc4__/  |
     |  d'entre (Ingress)                          \-qdiscN_/   |
     |                                                           |
     +-----------------------------------------------------------+

   Merci  Jamal Hadi Salim pour cette reprsentation ascii.

   Le grand rectangle reprsente le noyau. La flche la plus  gauche
   reprsente le trafic du rseau entrant dans votre machine. Celui-ci
   alimente alors le gestionnaire de mise en file d'attente Ingress qui
   peut appliquer des filtres  un paquet, et dcider de le supprimer.
   Ceci est appel << rglementation >> (_Policing_).

   Ce processus a lieu trs tt, avant d'avoir beaucoup parcouru le
   noyau. C'est par consquent un trs bon endroit pour rejeter au plus
   tt du trafic, sans pour autant consommer beaucoup de ressources CPU.

   Si le paquet est autoris  continuer, il peut tre destin  une
   application locale et, dans ce cas, il entre dans la couche IP pour
   tre trait et dlivr  un programme utilisateur. Le paquet peut
   galement tre transmis sans entrer dans une application et dans ce
   cas, tre destin  _egress_. Les programmes utilisateurs peuvent
   galement dlivrer des donnes, qui sont alors transmises et examines
   par le classificateur _Egress_.

   L, il est examin et mis en file d'attente vers un certain nombre de
   gestionnaire de mise en file d'attente. Par dfaut, il n'y a qu'un
   seul gestionnaire _egress_ install, pfifo_fast, qui reoit tous les
   paquets. Ceci correspond  << la mise en file d'attente >>
   (_enqueueing_).

   Le paquet rside maintenant dans le gestionnaire de mise en file
   d'attente, attendant que le noyau le rclame pour le transmettre 
   travers l'interface rseau. Ceci correspond au << retrait de la file
   d'attente >> (_dequeueing_).

   Le schma ne montre que le cas d'un seul adaptateur rseau. Les
   flches entrantes et sortantes du noyau ne doivent pas tre trop
   prises au pied de la lettre. Chaque adaptateur rseau a un
   gestionnaire d'entre et de sortie.
     _________________________________________________________________

9.5. Gestionnaires de file d'attente bass sur les classes

   Les gestionnaires de mise en file d'attente bass sur des classes sont
   trs utiles si vous avez diffrentes sortes de trafic qui doivent tre
   traits diffremment. L'un d'entre eux est appel CBQ, pour _Class
   Based Queueing_. Il est si souvent mentionn que les personnes
   identifient les gestionnaires de mise en file d'attente bass sur des
   classes uniquement  CBQ, ce qui n'est pas le cas.

   CBQ est le mcanisme le plus ancien, ainsi que le plus compliqu. Il
   n'aura pas forcment les effets que vous recherchez. Ceci surprendra
   peut-tre ceux qui sont sous l'emprise de << l'effet Sendmail >>, qui
   nous enseigne qu'une technologie complexe, non documente est
   forcment meilleure que toute autre.

   Nous voquerons bientt, plus  propos, CBQ et ses alternatives.
     _________________________________________________________________

9.5.1. Flux  l'intrieur des gestionnaires bass sur des classes & 
l'intrieur des classes

   Quand le trafic entre dans un gestionnaire de mise en file d'attente
   bas sur des classes, il doit tre envoy vers l'une de ses classes ;
   il doit tre << classifi >>. Pour dterminer que faire d'un paquet,
   les lements appels << filtres >> sont consults. Il est important de
   savoir que les filtres sont appels de l'intrieur d'un gestionnaire,
   et pas autrement !

   Les filtres attachs  ce gestionnaire renvoient alors une dcision
   que le gestionnaire utilise pour mettre en file d'attente le paquet
   vers l'une des classes. Chaque sous-classe peut essayer d'autres
   filtres pour voir si de nouvelles instructions s'appliquent. Si ce
   n'est pas le cas, la classe met le paquet en file d'attente dans le
   gestionnaire de mise en file d'attente qu'elle contient.

   En plus de contenir d'autres gestionnaires, la plupart des
   gestionnaires de mise en file d'attente bass sur des classes
   ralisent galement de la mise en forme. Ceci est utile pour raliser
    la fois l'ordonnancement (avec SFQ, par exemple) et le contrle de
   dbit. Vous avez besoin de ceci dans les cas o vous avez une
   interface  haut dbit (ethernet, par exemple) connecte  un
   priphrique plus lent (un modem cble).

   Si vous n'utilisez que SFQ, rien ne devait se passer, dans la mesure
   o les paquets entrent et sortent du routeur sans dlai : l'interface
   de sortie est de loin beaucoup plus rapide que la vitesse relle de
   votre liaison ; il n'y a alors pas de files d'attente  rordonnancer.
     _________________________________________________________________

9.5.2. La famille des gestionnaires de mise en file d'attente : racines,
descripteurs, descendances et parents

   Chaque interface  << un gestionnaire de mise en file d'attente
   racine >> de sortie (_egress root qdisc_). Par dfaut, le gestionnaire
   de mise en file d'attente sans classes mentionn plus tt pfifo_fast.
   Chaque gestionnaire peut tre repr par un descripteur (_handle_),
   qui pourra tre utilis par les prochaines dclarations de
   configuration pour se rfrer  ce gestionnaire. En plus du
   gestionnaire de sortie, une interface peut galement avoir un
   gestionnaire d'entre (_ingress_), qui rglemente le trafic entrant.

   Ces descripteurs sont constitus de deux parties : un nombre majeur et
   un nombre mineur. Il est habituel de nommer le gestionnaire racine 1:,
   ce qui est quivalent  1:0. Le nombre mineur d'un gestionnaire de
   mise en file d'attente est toujours 0.

   Les classes doivent avoir le mme nombre majeur que leur parent.
     _________________________________________________________________

9.5.2.1. Comment les filtres sont utiliss pour classifier le trafic

   Pour rcapituler, une hirarchie typique pourrait ressembler  ceci :
                  racine 1:
                      |
                    _1:1_
                   /  |  \
                  /   |   \
                 /    |    \
               10:   11:   12:
              /   \       /   \
           10:1  10:2   12:1  12:2

   Mais ne laissez pas cet arbre vous abuser ! Vous ne devriez _pas_
   imaginer le noyau tre au sommet de l'arbre et le rseau en-dessous,
   ce qui n'est justement pas le cas. Les paquets sont mis et retirs de
   la file d'attente  la racine du gestionnaire, qui est le seul lment
   avec lequel le noyau dialogue.

   Un paquet pourrait tre classifi  travers une chane suivante :
   1: -> 1:1 -> 12: -> 12:2

   Le paquet rside maintenant dans la file d'attente du gestionnaire
   attach  la classe 12:2. Dans cet exemple, un filtre a t attach 
   chaque noeud de l'arbre, chacun choisissant la prochaine branche 
   prendre. Cela est ralisable. Cependant, ceci est galement possible :
   1: -> 12:2

   Dans ce cas, un filtre attach  la racine a dcid d'envoyer le
   paquet directement  12:2.
     _________________________________________________________________

9.5.2.2. Comment les paquets sont retirs de la file d'attente et envoys
vers le matriel

   Quand le noyau dcide qu'il doit extraire des paquets pour les envoyer
   vers l'interface, le gestionnaire racine 1: reoit une requte
   dequeue, qui est transmise  1:1 et qui,  son tour, est passe  10:,
   11: et 12:, chacune interrogeant leurs descendances qui essaient de
   retirer les paquets de leur file d'attente. Dans ce cas, le noyau doit
   parcourir l'ensemble de l'arbre, car seul 12:2 contient un paquet.

   En rsum, les classes << embotes >> parlent _uniquement_ leur
   gestionnaire de mise en file d'attente parent ; jamais  une
   interface. Seul la file d'attente du gestionnaire racine est vide par
   le noyau !

   Ceci a pour rsultat que les classes ne retirent jamais les paquets
   d'une file d'attente plus vite que ce que leur parent autorise. Et
   c'est exactement ce que nous voulons : de cette manire, nous pouvons
   avoir SFQ dans une classe interne qui ne fait pas de mise en forme,
   mais seulement de l'ordonnancement, et avoir un gestionnaire de mise
   en file d'attente extrieur qui met en forme le trafic.
     _________________________________________________________________

9.5.3. Le gestionnaire de mise en file d'attente PRIO

   Le gestionnaire de mise en file d'attente ne met pas vraiment en forme
   le trafic ; il ne fait que le subdiviser en se basant sur la manire
   dont vous avez configur vos filtres. Vous pouvez considrer les
   gestionnaires PRIO comme une sorte de super pfifo_fast dop, o chaque
   bande est une classe spare au lieu d'une simple FIFO.

   Quand un paquet est mis en file d'attente dans le gestionnaire PRIO,
   une classe est choisie en fonction des filtres que vous avez donns.
   Par dfaut, trois classes sont cres. Ces classes contiennent par
   dfaut de purs gestionnaires de mise en file d'attente FIFO sans
   structure interne, mais vous pouvez les remplacer par n'importe quels
   gestionnaires disponibles.

   Chaque fois qu'un paquet doit tre retir d'une file d'attente, la
   classe :1 est d'abord teste. Les classes plus leves ne sont
   utilises que si aucune des bandes plus faibles n'a pas fourni de
   paquets.

   Cette file d'attente est trs utile dans le cas o vous voulez donner
   la priorit  certains trafics en utilisant toute la puissance des
   filtres _tc_ et en ne se limitant pas seulemenent aux options du champ
   TOS. Il peut galement contenir n'importe quel gestionnaire de mise en
   file d'attente, tandis que pfifo_fast est limit aux gestionnaires
   simples FIFO.

   Puisqu'il ne met pas vraiment en forme, on applique le mme
   avertissement que pour SFQ. Utilisez PRIO seulement si votre lien
   physique est vraiment satur ou intgrez-le  l'intrieur d'un
   gestionnaire de mise en file d'attente bas sur des classes qui
   ralisent la mise en forme. Ce dernier cas est valable pour
   pratiquement tous les modems-cbles et les priphriques DSL.

   En termes formels, le gestionnaire de mise en file d'attente PRIO est
   un ordonnanceur _Work-Conserving_.
     _________________________________________________________________

9.5.3.1. Paramtres PRIO & usage

   Les paramtres suivants sont reconnus par _tc_ :

   bands
          Nombre de bandes  crer. Chaque bande est en fait une classe.
          Si vous changez ce nombre, vous devez galement changer :

   priomap
          Si vous ne fournissez pas de filtres _tc_ pour classifier le
          trafic, le gestionnaire PRIO regarde la priorit TC_PRIO pour
          dcider comment mettre en file d'attente le trafic.

          Ceci fonctionne comme le gestionnaire de mise en file d'attente
          pfifo_fast mentionn plus tt. Voir la section correspondante
          pour plus de dtails.

   Les bandes sont des classes et sont appeles par dfaut majeur:1 
   majeur:3. Donc, si votre gestionnaire de mise en file d'attente est
   appel 12:, _tc_ filtre le trafic vers 12:1 pour lui accorder une plus
   grande priorit.

   Par itration, la bande 0 correspond au nombre mineur 1, la bande 1 au
   nombre mineur 2, etc ...
     _________________________________________________________________

9.5.3.2. Configuration simple

   Nous allons crer cet arbre :
     racine 1: prio
         /   |   \
       1:1  1:2  1:3
        |    |    |
       10:  20:  30:
       sfq  tbf  sfq
bande   0    1    2

   Le trafic de masse ira vers 30: tandis que le trafic interactif ira
   vers 20: ou 10:.

   Les lignes de commande :
# tc qdisc add dev eth0 root handle 1: prio
## Ceci cre *instantanment* les classes 1:1, 1:2, 1:3

# tc qdisc add dev eth0 parent 1:1 handle 10: sfq
# tc qdisc add dev eth0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit
 3000
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq

   Regardons maintenant ce que nous avons cr :
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
 Sent 0 bytes 0 pkts (dropped 0, overlimits 0)

 qdisc sfq 10: quantum 1514b
 Sent 132 bytes 2 pkts (dropped 0, overlimits 0)

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 174 bytes 3 pkts (dropped 0, overlimits 0)

   Comme vous pouvez le voir, la bande 0 a dj reu du trafic, et un
   paquet a t envoy pendant l'excution de cette commande !

   Nous allons maintenant gnrer du trafic de masse avec un outil qui
   configure correctement les options TOS, et regarder de nouveau :
# scp tc ahu@10.0.0.11:./
ahu@10.0.0.11's password:
tc                   100% |*****************************|   353 KB    00:00
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0)

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0)

 qdisc sfq 10: quantum 1514b
 Sent 2230 bytes 31 pkts (dropped 0, overlimits 0)

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 389140 bytes 326 pkts (dropped 0, overlimits 0)

   Comme vous pouvez le voir, tout le trafic a t envoy comme prvu
   vers le descripteur 30:, qui est la bande de plus faible priorit.
   Maintenant, pour vrifier que le trafic interactif va vers les bandes
   de plus grande priorit, nous gnrons du trafic interactif :
# tc -s qdisc ls dev eth0
qdisc sfq 30: quantum 1514b
 Sent 384228 bytes 274 pkts (dropped 0, overlimits 0)

 qdisc tbf 20: rate 20Kbit burst 1599b lat 667.6ms
 Sent 2640 bytes 20 pkts (dropped 0, overlimits 0)

 qdisc sfq 10: quantum 1514b
 Sent 14926 bytes 193 pkts (dropped 0, overlimits 0)

 qdisc prio 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 401836 bytes 488 pkts (dropped 0, overlimits 0)

   Ca a march. Tout le trafic supplmentaire a t vers 10:, qui est
   notre gestionnaire de plus grande priorit. Aucun trafic n'a t
   envoy vers les priorits les plus faibles, qui avaient reu au
   pralable tout le trafic venant de notre _scp_.
     _________________________________________________________________

9.5.4. Le clbre gestionnaire de mise en file d'attente CBQ

   Comme dit avant, CBQ est le gestionnaire de mise en file d'attente
   disponible le plus complexe, celui qui a eu le plus de publicit, qui
   est le moins compris et qui est probablement le plus farceur lors de
   sa mise au point. Ce n'est pas parce que les auteurs sont mauvais ou
   incomptents, loin de l, mais l'algorithme CBQ n'est pas
   remarquablement prcis et il ne correspond pas vraiment  la faon
   dont Linux fonctionne.

   En plus d'tre bas sur des classes, CBQ sert galement  la mise en
   forme de trafic et c'est sur cet aspect qu'il ne fonctionne pas trs
   bien. Il travaille comme ceci : si vous essayez de mettre en forme une
   connexion de 10mbit/s  1mbits/s, le lien doit tre inactif 90% du
   temps. Si ce n'est pas le cas, nous devons limiter le taux de sorte
   qu'il _soit_ inactif 90% du temps.

   Ceci est assez dur  mesurer et c'est pour cette raison que CBQ dduit
   le temps d'inactivit du nombre de microsecondes qui s'coulent entre
   les requtes de la couche matrielle pour avoir plus de donnes. Cette
   combinaison peut tre utilise pour valuer si le lien est charg ou
   non.

   Ceci est plutt lger et l'on arrive pas toujours  des rsultats
   convenables. Par exemple, qu'en est-il de la vitesse de liaison relle
   d'une interface qui n'est pas capable de transmettre pleinement les
   donnes  100mbit/s, peut-tre  cause d'un mauvais pilote de
   priphrique ? Une carte rseau PCMCIA ne pourra jamais atteindre
   100mbit/s  cause de la conception du bus. De nouveau, comment
   calculons-nous le temps d'inactivit ?

   Cela devient mme pire quand on considre un priphrique rseau
   "pas-vraiment-rel" comme _PPP Over Ethernet_ ou _PPTP over TCP/IP_.
   La largeur de bande effective est dans ce cas probablement dtermine
   par l'efficacit des tubes vers l'espace utilisateur, qui est norme.

   Les personnes qui ont effectu des mesures ont dcouvert que CBQ n'est
   pas toujours trs exact, et parfois mme, trs loign de la
   configuration.

   Cependant, il marche bien dans de nombreuses circonstances. Avec la
   documentation fournie ici, vous devriez tre capable de le configurer
   pour qu'il fonctionne bien dans la plupart des cas.
     _________________________________________________________________

9.5.4.1. Mise en forme CBQ en dtail

   Comme dit prcdemment, CBQ fonctionne en s'assurant que le lien est
   inactif juste assez longtemps pour abaisser la bande passante relle
   au dbit configur. Pour raliser cela, il calcule le temps qui
   devrait s'couler entre des paquets de taille moyennne.

   En cours de fonctionnement, le temps d'inactivit effectif (_the
   effective idletime_) est mesur en utilisant l'algorithme EWMA
   (_Exponential Weighted Moving Average_), qui considre que les paquets
   rcents sont exponentiellement plus nombreux que ceux passs. La
   charge moyenne UNIX (_UNIX loadaverage_) est calcule de la mme
   manire.

   Le temps d'inactivit calcul est soustrait  celui mesur par EWMA et
   le nombre rsultant est appel avgidle. Un lien parfaitement charg a
   un avgidle nul : un paquet arrive  chaque intervalle calcul.

   Une liaison surcharge a un avgidle ngatif et s'il devient trop
   ngatif, CBQ s'arrte un moment et se place alors en dpassement de
   limite (_overlimit_).

   Inversement, un lien inutilis peut accumuler un avgidle norme, qui
   autoriserait alors des bandes passantes infinies aprs quelques heures
   d'inactivit. Pour viter cela, avgidle est born  maxidle.

   En situation de dpassement de limite, CBQ peut en thorie bloquer le
   dbit pour une dure quivalente au temps qui doit s'couler entre
   deux paquets moyens, puis laisser passer un paquet et bloquer de
   nouveau le dbit. Regardez cependant le paramtre minburst ci-dessous.

   Voici les paramtres que vous pouvez spcifier pour configurer la mise
   en forme :

   avpkt
          Taille moyenne d'un paquet mesure en octets. Ncessaire pour
          calculer maxidle, qui drive de maxburst, qui est spcifi en
          paquets.

   bandwidth
          La bande passante physique de votre priphrique ncessaire
          pour les calculs du temps de non utilisation (_idle time_).

   cell
          La dure de transmission d'un paquet n'augmente pas
          ncessairement de manire linaire en fonction de sa taille.
          Par exemple, un paquet de 800 octets peut tre transmis en
          exactement autant de temps qu'un paquet de 806 octets. Ceci
          dtermine la granularit. Cette valeur est gnralement
          positionne  8, et doit tre une puissance de deux.

   maxburst
          Ce nombre de paquets est utilis pour calculer maxidle de telle
          sorte que quand avgidle est gal  maxidle, le nombre de
          paquets moyens peut tre envoy en rafale avant que avgidle ne
          retombe  0. Augmentez-le pour tre plus tolrant vis  vis des
          rafales de donnes. Vous ne pouvez pas configurer maxidle
          directement, mais seulement via ce paramtre.

   minburst
          Comme nous l'avons dj indiqu, CBQ doit bloquer le dbit dans
          le cas d'un dpassement de limite. La solution idale est de le
          faire pendant exactement le temps d'inutilisation calcul, puis
          de laisser passer un paquet. Cependant, les noyaux UNIX ont
          gnralement du mal  prvoir des vnements plus courts que 10
          ms, il vaut donc mieux limiter le dbit pendant une priode
          plus longue, puis envoyer minburst paquets d'un seul coup et
          dormir pendant une dure de minburst.

          Le temps d'attente est appel _offtime_. De plus grandes
          valeurs de minburst mnent  une mise en forme plus prcise
          dans le long terme, mais provoquent de plus grandes rafales de
          donnes pendant des priodes de quelques millisecondes.

   minidle
          Si avgidle est infrieur  0, nous sommes en dpassement de
          limite et nous devons attendre jusqu' ce que avgidle devienne
          suffisamment important pour envoyer un paquet. Pour viter
          qu'une brusque rafale de donnes n'empche le lien de
          fonctionner pendant une dure prolonge, avgidle est remis 
          minidle s'il atteint une valeur trop basse.

          La valeur minidle est spcifie en microsecondes ngatives : 10
          signifie alors que avgidle est born  -10s.

   mpu
          Taille minumum d'un paquet. Ncessaire car mme un paquet de
          taille nulle est encapsul par 64 octets sur ethernet et il
          faut donc un certain temps pour le transmettre. CBQ doit
          connatre ce paramtre pour calculer prcisment le temps
          d'inutilisation.

   rate
          Dbit du trafic sortant du gestionnaire. Ceci est le
          << paramtre de vitesse >> !

   En interne, CBQ est finement optimis. Par exemple, les classes qui
   sont connues pour ne pas avoir de donnes prsentes dans leur file
   d'attente ne sont pas interroges. Les classes en situation de
   dpassement de limite sont pnalises par la diminution de leur
   priorit effective. Tout ceci est trs habile et compliqu.
     _________________________________________________________________

9.5.4.2. Le comportement _CBQ classful_

   En plus de la mise en forme, en utilisant les approximations idletime
   mentionnes ci-dessus, CBQ peut galement agir comme une file
   d'attente PRIO dans le sens o les classes peuvent avoir diffrentes
   priorits. Les priorits de plus faible valeur seront examines avant
   celles de valeur plus leves.

   Chaque fois qu'un paquet est demand par la couche matrielle pour
   tre envoy sur le rseau, un processus _weighted round robin_ (WRR)
   dmarre en commenant par les classes de plus faibles priorits.

   Celles-ci sont regroupes et interroges si elles ont des donnes
   disponibles. Aprs qu'une classe ait t autorise  retirer de la
   file d'attente un nombre d'octets, la classe de priorit suivante est
   consulte.

   Les paramtres suivants contrlent le processus WRR :

   allot
          Quand le CBQ racine reoit une demande d'envoi de paquets sur
          une interface, il va essayer tous les gestionnaires internes
          (dans les classes) tour  tour suivant l'ordre du paramtre
          priority. A chaque passage, une classe ne peut envoyer qu'une
          quantit limite de donnes. Le paramtre allot est l'unit de
          base de cette quantit. Voir le paramtre weight pour plus
          d'informations.

   prio
          CBQ peut galement agir comme un priphrique PRIO. Les classes
          internes avec les priorits les plus faibles sont consultes en
          premier et, aussi longtemps qu'elles ont du trafic, les autres
          classes ne sont pas examines.

   weight
          Le paramtre weight assiste le processus _Weighted Round
          Robin_. Chaque classe a tour  tour la possibilit d'envoyer ses
          donnes. Si vous avez des classes avec des bandes passantes
          significativement plus importantes, il est logique de les
          autoriser  envoyer plus de donnes  chaque tour que les
          autres.

          Vous pouvez utiliser des nombres arbitraires dans la mesure o
          CBQ additionne tous les paramtres weight prsents sous une
          classe et les normalise. La rgle empirique qui consiste 
          prendre rate/10 semble fonctionner correctement. Le paramtre
          weight normalis est multipli par le paramtre allot pour
          dterminer la quantit de donnes  envoyer  chaque tour.

   Notez, s'il vous plat, que toutes les classes  l'intrieur d'une
   hirarchie CBQ doivent avoir le mme nombre majeur !
     _________________________________________________________________

9.5.4.3. Paramtres CBQ qui dterminent le partage & le prt du lien

   En plus de purement limiter certains trafics, il est galement
   possible de spcifier quelles classes peuvent emprunter de la bande
   passante aux autres classes ou, rciproquement, prter sa bande
   passante.

   isolated/ sharing
          Une classe qui est configure avec isolated ne prtera pas sa
          bande passante  ses classes enfants. Utilisez ceci si vous
          avez sur votre lien deux agences concurrentes ou qui ne
          s'apprcient pas et qui ne veulent pas se prter gratuitement
          de la bande passante.

          Le programme de contrle _tc_ connait galement sharing, qui
          agit  l'inverse du paramtre isolated.

   bounded/ borrow
          Une classe peut aussi tre borne (bounded), ce qui signifie
          qu'elle n'essaiera pas d'emprunter de la bande passante  ses
          classes enfants. _tc_ connait galement borrow, qui agit 
          l'inverse de bounded.

   Une situation typique pourrait tre le cas o vous avez deux agences
   prsentes sur votre lien qui sont  la fois isolated et bounded. Ceci
   signifie qu'elles sont strictement limites  leur dbit et qu'elles
   ne prteront pas aux autres leur bande passante.

   A l'intrieur de ces classes d'agence, il pourrait y avoir d'autres
   classes qui sont autorises  changer leur bande passante.
     _________________________________________________________________

9.5.4.4. Configuration simple

   Cette configuration limite le trafic d'un serveur web  5 mbit et le
   trafic smtp  3 mbit. Il est souhaitable qu'ils n'occupent pas plus de
   6 mbit  eux deux. Nous avons une carte rseau  100 mbit et les
   classes peuvent s'emprunter mutuellement de la bande passante.
# tc qdisc add dev eth0 root handle 1:0 cbq bandwidth 100Mbit         \
  avpkt 1000 cell 8
# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 100Mbit  \
  rate 6Mbit weight 0.6Mbit prio 8 allot 1514 cell 8 maxburst 20      \
  avpkt 1000 bounded

   Cette partie installe la racine et la classe 1:0 habituelle. La classe
   1:1 est borne, la bande passante totale ne pourra donc pas excder
   6 mbit.

   Comme dit avant, CBQ a besoin de _NOMBREUX_ paramtres. Tous ces
   paramtres sont cependant expliqus au-dessus. La configuration HTB
   correspondante est beaucoup plus simple.
# tc class add dev eth0 parent 1:1 classid 1:3 cbq bandwidth 100Mbit  \
  rate 5Mbit weight 0.5Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000
# tc class add dev eth0 parent 1:1 classid 1:4 cbq bandwidth 100Mbit  \
  rate 3Mbit weight 0.3Mbit prio 5 allot 1514 cell 8 maxburst 20      \
  avpkt 1000

   Ce sont nos deux classes. Notez comment nous avons configur la valeur
   du paramtre weight en fonction du paramtre rate. La bande passante
   de l'ensemble des deux classes ne pourra jamais dpasser 6 mbit. En
   fait, les identifieurs de classe (classid) doivent avoir le mme
   numro majeur que le parent CBQ !
# tc qdisc add dev eth0 parent 1:3 handle 30: sfq
# tc qdisc add dev eth0 parent 1:4 handle 40: sfq

   Les deux classes ont par dfaut un gestionnaire de mise en file
   d'attente FIFO. Nous les remplaons par une file d'attente SFQ de
   telle sorte que chaque flux de donnes soit trait de manire gale.
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 80 0xffff flowid 1:3
# tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match ip \
  sport 25 0xffff flowid 1:4

   Ces commandes, directement attaches  la racine, envoient le trafic
   vers le bon gestionnaire de mise en file d'attente.

   Notez que nous utilisons tc class add pour _CREER_ des classes 
   l'intrieur d'un gestionnaire de mise en file d'attente, et que nous
   utilisons tc qdisc add pour vritablement configurer ces classes.

   Vous vous demandez peut-tre ce qui arrive au trafic qui n'est
   classifi par aucune des deux rgles. Dans ce cas, les donnes seront
   traites  l'intrieur de 1:0, et le dbit ne sera pas limit.

   Si le trafic smtp+web tente de dpasser la limite de 6 mbit/s, la
   bande passante sera divise selon le paramtre weight, donnant 5/8 du
   trafic au serveur web et 3/8 au serveur smtp.

   Avec cette configuration, vous pouvez galement dire que le trafic du
   serveur web sera au minimum de 5/8 * 6 mbit = 3.75 mbit.
     _________________________________________________________________

9.5.4.5. D'autres paramtres CBQ : split & defmap

   Comme prcis avant, un gestionnaire de mise en file d'attente bas
   sur des classes doit appeler des filtres pour dterminer dans quelle
   classe un paquet sera mis en file d'attente.

   En plus d'appeler les filtres, CBQ offre d'autres options : defmap &
   split. C'est plutt compliqu  comprendre et, de plus, ce n'est pas
   vital. Mais, tant donn que ceci est le seul endroit connu o defmap
   & split sont correctement expliqus, je vais faire de mon mieux.

   Etant donn que nous voulons le plus souvent raliser le filtrage en
   ne considrant que le champ TOS, une syntaxe spciale est fournie.
   Chaque fois que CBQ doit trouver o le paquet doit tre mis en file
   d'attente, il vrifie si le noeud est un noeud d'aiguillage (_split
   node_). Si c'est le cas, un de ses sous-gestionnaire a indiqu son
   souhait de recevoir tous les paquets configurs avec une certaine
   priorit. Celle ci peut tre drive du champ TOS ou des options des
   sockets positionnes par les applications.

   Les bits de priorits des paquets subissent un OU logique avec le
   champ defmap pour voir si une correspondance existe. En d'autres
   termes, c'est un moyen pratique de crer un filtre trs rapide, qui ne
   sera actif que pour certaines priorits. Un defmap de ff (en
   hexadcimal) vrifiera tout tandis qu'une valeur de 0 ne vrifiera
   rien. Une configuration simple aidera peut-tre  rendre les choses
   plus claires :
# tc qdisc add dev eth1 root handle 1: cbq bandwidth 10Mbit allot 1514 \
  cell 8 avpkt 1000 mpu 64

# tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 10Mbit    \
  rate 10Mbit allot 1514 cell 8 weight 1Mbit prio 8 maxburst 20        \
  avpkt 1000

   Prambule standard de CBQ. Je n'ai jamais pris l'habitude de la
   quantit de nombres ncessaires !

   Le paramtre defmap se rfre aux bits TC_PRIO qui sont dfinis comme
   suit :
TC_PRIO..          Num  Correspond  TOS
-------------------------------------------------
BESTEFFORT         0    Maximalise la Fiabilit
FILLER             1    Minimalise le Cot
BULK               2    Maximalise le Dbit (0x8)
INTERACTIVE_BULK   4
INTERACTIVE        6    Minimise le Dlai (0x10)
CONTROL            7

   Les nombres TC_PRIO.. correspondent aux bits compts  partir de la
   droite. Voir la section pfifo_fast pour plus de dtails sur la faon
   dont les bits TOS sont convertis en priorits.

   Maintenant, les classes interactive et de masse :
# tc class add dev eth1 parent 1:1 classid 1:2 cbq bandwidth 10Mbit     \
  rate 1Mbit allot 1514 cell 8 weight 100Kbit prio 3 maxburst 20        \
  avpkt 1000 split 1:0 defmap c0

# tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 10Mbit     \
  rate 8Mbit allot 1514 cell 8 weight 800Kbit prio 7 maxburst 20        \
  avpkt 1000 split 1:0 defmap 3f

   La gestion de mise en file d'attente d'aiguillage (_split qdisc_) est
   1:0 et c'est  ce niveau que le choix sera fait. C0 correspond au
   nombre binaire 11000000 et 3F au nombre binaire 00111111. Ces valeurs
   sont choisies de telle sorte qu' elles deux, elles vrifient tous les
   bits. La premire classe correspond aux bits 6 & 7, ce qui est
   quivalent aux trafics << interactif >> et de << contrle >>. La
   seconde classe correspond au reste.

   Le noeud 1:0 possde maintenant la table suivante :
priorit        envoyer 
0               1:3
1               1:3
2               1:3
3               1:3
4               1:3
5               1:3
6               1:2
7               1:2

   Pour d'autres amusements, vous pouvez galement donner un << masque de
   changement >> qui indique exactement les priorits que vous souhaitez
   changer. N'utilisez ceci qu'avec la commande tc class change. Par
   exemple, pour ajouter le trafic _best effort_  la classe 1:2, nous
   devrons excuter ceci :
   # tc class change dev eth1 classid 1:2 cbq defmap 01/01

   La carte des priorits au niveau de 1:0 ressemble maintenant  ceci :
priorit        envoyer 
0               1:2
1               1:3
2               1:3
3               1:3
4               1:3
5               1:3
6               1:2
7               1:2

   FIXME: tc class change n'a pas t test, mais simplement vu dans les
   sources.
     _________________________________________________________________

9.5.5. Seau de jetons  contrle hirarchique (_Hierarchical Token Bucket_)

   Martin Devera(<devik>) ralisa  juste titre que CBQ est complexe et
   qu'il ne semble pas optimis pour de nombreuses situations classiques.
   Son approche hirarchique est bien adapte dans le cas de
   configurations o il y a une largeur de bande passante fixe  diviser
   entre diffrents lments. Chacun de ces lments aura une bande
   passante garantie, avec la possibilit de spcifier la quantit de
   bande passante qui pourra tre emprunte.

   HTB travaille juste comme CBQ, mais il n'a pas recourt  des calculs
   de temps d'inoccupation pour la mise en forme. A la place, c'est un
   _Token Bucket Filter_ bas sur des classes, d'o son nom. Il n'a que
   quelques paramtres, qui sont bien documents sur ce site.

   Au fur et  mesure que votre configuration HTB se complexifie, votre
   configuration s'adapte bien. Avec CBQ, elle est dj complexe mme
   dans les cas simples ! HTB ne fait pas encore partie du noyau
   standard, mais cela devrait bientt tre le cas !

   Si vous tes sur le point de mettre  jour votre noyau, considrez HTB
   cote que cote.
     _________________________________________________________________

9.5.5.1. Configuration simple

   Fonctionnellement presque identique  la configuration simple CBQ
   prsente ci-dessus :
# tc qdisc add dev eth0 root handle 1: htb default 30

# tc class add dev eth0 parent 1: classid 1:1 htb rate 6mbit burst 15k

# tc class add dev eth0 parent 1:1 classid 1:10 htb rate 5mbit burst 15k
# tc class add dev eth0 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst
 15k
# tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst
 15k

   L'auteur recommande SFQ sous ces classes :
# tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
# tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
# tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10

   Ajouter les filtres qui dirigent le trafic vers les bonnes classes :
# U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
# $U32 match ip dport 80 0xffff flowid 1:10
# $U32 match ip sport 25 0xffff flowid 1:20

   Et, c'est tout. Pas de vilains nombres non expliqus, pas de
   paramtres non documents.

   HTB semble vraiment merveilleux. Si 10: et 20: ont atteint tous les
   deux leur bande passante garantie et qu'il en reste  partager, ils
   l'empruntent avec un rapport de 5:3, comme attendu.

   Le trafic non classifi est achemin vers 30:, qui a une petite bande
   passante, mais qui peut emprunter tout ce qui est laiss libre.
   Puisque nous avons choisi SFQ en interne, on hrite naturellement de
   l'quit.
     _________________________________________________________________

9.6. Classifier des paquets avec des filtres

   Pour dterminer quelle classe traitera un paquet, la << chane de
   classificateurs >> est appele chaque fois qu'un choix a besoin d'tre
   fait. Cette chane est constitue de tous les filtres attachs aux
   gestionnaires de mise en file d'attente bass sur des classes qui
   doivent prendre une dcision.

   On reprend l'arbre qui n'est pas un arbre :
                    root 1:
                      |
                    _1:1_
                   /  |  \
                  /   |   \
                 /    |    \
               10:   11:   12:
              /   \       /   \
           10:1  10:2   12:1  12:2

   Quand un paquet est mis en file d'attente, l'instruction approprie de
   la chane de filtre est consulte  chaque branche. Une configuration
   typique devrait avoir un filtre en 1:1 qui dirige le paquet vers 12:
   et un filtre en 12: qui l'envoie vers 12:2.

   Vous pourriez galement avoir ce dernier filtre en 1:1, mais vous
   pouvez gagner en efficacit en ayant des tests plus spcifiques plus
   bas dans la chane.

   A ce propos, vous ne pouvez pas filtrer un paquet << vers le haut >>.
   Donc, avec HTB, vous devrez attacher tous les filtres  la racine !

   Encore une fois, les paquets ne sont mis en file d'attente que vers le
   bas ! Quand ils sont retirs de la file d'attente, ils montent de
   nouveau, vers l'interface. Ils ne tombent _PAS_ vers l'extrmit de
   l'arbre en direction de l'adaptateur rseau !
     _________________________________________________________________

9.6.1. Quelques exemples simples de filtrage

   Comme expliqu dans le chapitre _Filtres avancs pour la
   classification des paquets_, vous pouvez vraiment analyser n'importe
   quoi en utilisant une syntaxe trs complique. Pour commencer, nous
   allons montrer comment raliser les choses videntes, ce qui
   heureusement est plutt facile.

   Disons que nous avons un gestionnaire de mise en file d'attente PRIO
   appel 10: qui contient trois classes, et que nous voulons assigner 
   la bande de plus haute priorit tout le trafic allant et venant du
   port 22. Les filtres seraient les suivants :
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
  ip dport 22 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 1 u32 match \
  ip sport 80 0xffff flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2 flowid 10:2

   Qu'est-ce que cela signifie ? Cela dit : attacher  eth0, au noeud 10:
   un filtre u32 de priorit 1 qui analyse le port de destination ip 22
   et qui l'envoie vers la bande 10:1. La mme chose est rpte avec le
   port source 80. La dernire commande indique que si aucune
   correspondance n'est trouve, alors le trafic devra aller vers la
   bande 10:2, la plus grande priorit suivante.

   Vous devez ajouter eth0 ou n'importe laquelle de vos interfaces, car
   chaque interface possde un espace de nommage de ses descripteurs qui
   lui est propre.

   Pour slectionner une adresse IP, utilisez ceci :
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
  match ip dst 4.3.2.1/32 flowid 10:1
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 \
  match ip src 1.2.3.4/32 flowid 10:1
# tc filter add dev eth0 protocol ip parent 10: prio 2      \
  flowid 10:2

   Ceci dirige le trafic allant vers 4.3.2.1 et venant de 1.2.3.4 vers la
   file d'attente de plus haute priorit, tandis que le reste ira vers la
   prochaine plus haute priorit.

   Vous pouvez rassembler ces deux vrifications pour rcuprer le trafic
   venant de 1.2.3.4 avec le port source 80 :
# tc filter add dev eth0 parent 10:0 protocol ip prio 1 u32 match ip src 4.3.2.
1/32
  match ip sport 80 0xffff flowid 10:1
     _________________________________________________________________

9.6.2. Toutes les commandes de filtres dont vous aurez normalement besoin

   La plupart des commandes prsentes ici commencent avec le prambule
   suivant :
   # tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 ..

   Ils sont appels filtres u32 qui analysent _N'IMPORTE QUELLE_ partie
   d'un paquet.

   Sur l'adresse source/destination
          Masque pour la source match ip src 1.2.3.0/24 et masque pour la
          destination match ip dst 4.3.2.0/24. Pour analyser un hte
          simple, employez /32 ou omettez le masque.

   Sur le port source/destination, tous les protocoles IP
          Source: match ip sport 80 0xffff et destination : match ip
          dport ?? 0xffff

   Sur le protocole ip (tcp, udp, icmp, gre, ipsec)
          Utilisez les nombres dfinis dans /etc/protocols, par exemple 1
          pour icmp : match ip protocol 1 0xff.

   Sur fwmark
          Vous pouvez marquer les paquets avec ipchains, par exemple, et
          voir cette marque prserve lors du routage  travers les
          interfaces. Ceci est vraiment utile pour mettre uniquement en
          forme le trafic sur eth1 et venant de eth0, par exemple. La
          syntaxe est la suivante :

# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid 1:1

          Notez que ce n'est pas une correspondance u32 !

          Vous pouvez positionner une marque comme ceci :

# iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6

          Le nombre 6 est arbitraire.

          Si vous ne voulez pas assimiler la syntaxe complte de _tc
          filter_, utilisez juste _iptables_ et apprenez seulement la
          slection base sur fwmark.

   Sur le champ TOS
          Pour slectionner le trafic interactif, dlai minimum :

# tc filter add dev ppp0 parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff \
     flowid 1:4

          Utilisez 0x08 0xff pour le trafic de masse.

   Pour plus de commandes de filtrage, voir le chapitre _Filtres avancs
   pour la classification des paquets_.
     _________________________________________________________________

Chapitre 10. quilibrage de charge sur plusieurs interfaces

   Il existe plusieurs manires pour le faire. Une des plus faciles et
   des plus directes est TEQL (_True (or Trivial) Link Equalizer_. Comme
   la plupart des lments en relation avec la gestion de file d'attente,
   l'quilibrage de charge est bidirectionnel. Les deux quipements
   terminaux du lien ont besoin de participer pour obtenir une efficacit
   optimale.

   Imaginez la situation suivante :
                 +-------+   eth1   +-------+
                 |       |==========|       |
 'rseau 1' -----|   A   |          |   B   |---- 'rseau 2'
                 |       |==========|       |
                 +-------+   eth2   +-------+

   A et B sont des routeurs dont nous supposerons qu'ils fonctionnent
   avec Linux pour le moment. Si le trafic va du rseau 1 vers le rseau
   2, le routeur A a besoin de distribuer les paquets sur les deux liens
   allant vers B. Le routeur B a besoin d'tre configur pour l'accepter.
   On retrouve la mme chose dans le sens inverse, pour les paquets
   allant du rseau 2 vers le rseau 1. Le routeur B a besoin d'envoyer
   les paquets  la fois sur eth1 et eth2.

   La rpartition est faite par un priphrique TEQL, comme ceci (cela ne
   pouvait pas tre plus simple) :
# tc qdisc add dev eth1 root teql0
# tc qdisc add dev eth2 root teql0
# ip link set dev teql0 up

   N'oubliez pas la commande _ip link set up_ !

   Ceci a besoin d'tre fait sur les deux htes. Le priphrique teql0
   est basiquement un distributeur tourniquet au dessus de eth1 et eth2
   pour l'envoi des paquets. Aucune donne n'arrive jamais  travers un
   priphrique teql, mais les donnes apparassent sur eth1 et eth2.

   Nous n'avons pour le moment que les priphriques et nous avons
   galement besoin d'un routage correct. L'une des possibilits pour
   raliser cela est d'assigner un rseau /31 sur chacun des liens, ainsi
   que sur le priphrique teql0 :

   FIXME: Avons nous besoin de quelque chose comme nobroadcast ? Un /31
   est trop petit pour contenir une adresse rseau et une adresse de
   diffusion. Si cela ne marche pas comme prvu, essayez un /30, et
   ajustez les adresses IP. Vous pouvez mme essayer sans attribuer
   d'adresses  eth1 et eth2.

   Sur le routeur A:
# ip addr add dev eth1 10.0.0.0/31
# ip addr add dev eth2 10.0.0.2/31
# ip addr add dev teql0 10.0.0.4/31

   Sur le routeur B:
# ip addr add dev eth1 10.0.0.1/31
# ip addr add dev eth2 10.0.0.3/31
# ip addr add dev teql0 10.0.0.5/31

   Le routeur A devrait maintenant tre capable de lancer un _ping_ vers
   10.0.0.1, 10.0.0.3 et 10.0.0.5  travers les deux liens physiques et
   le priphrique << galis >>. Le routeur B devrait maintenant tre
   capable de lancer un _ping_ vers 10.0.0.0, 10.0.0.2 et 10.0.0.4 
   travers les liens.

   Si cela marche, le routeur A peut prendre 10.0.0.5 comme route vers le
   rseau 2 et le routeur B 10.0.0.4 comme route vers le rseau 1. Pour
   le cas particulier o le rseau 1 est votre rseau personnel et o le
   rseau 2 est l'Internet, le routeur A peut prendre 10.0.0.5 comme
   passerelle par dfaut.
     _________________________________________________________________

10.1. Avertissement

   Rien n'est aussi simple qu'il y parat. Les interfaces eth1 et eth2
   sur les deux routeurs A et B ne doivent pas avoir la fonction de
   filtrage par chemin inverse active. Dans le cas contraire, ils
   rejeteront les paquets destins  des adresses autres que les leurs :
# echo 0 > /proc/net/ipv4/conf/eth1/rp_filter
# echo 0 > /proc/net/ipv4/conf/eth2/rp_filter

   Il y a un srieux problme avec le rordonnancement des paquets.
   Supposons que six paquets aient besoin d'tre envoys de A vers B. Par
   exemple, eth1 peut traiter les paquets 1, 3 et 5 et eth2 les paquets
   2, 4 et 6. Dans un monde idal, le routeur B devrait recevoir ces
   paquets dans l'ordre 1, 2, 3, 4, 5, 6. Mais il est plus probable que
   le noyau les reoive comme ceci : 2, 1, 4, 3, 6, 5. Ce problme va
   perturber TCP/IP. Alors qu'il n'y a pas de problmes pour les liens
   transportant diffrentes sessions TCP/IP, vous ne serez pas capable de
   regrouper plusieurs liens et obtenir par ftp un simple fichier
   beaucoup plus rapidement,  moins que le systme d'exploitation
   envoyant ou recevant ne soit Linux. En effet, celui-ci n'est pas
   facilement perturb par de simples rordonnancements.

   Cependant, l'quilibrage de charge est une bonne ide pour de
   nombreuses applications.
     _________________________________________________________________

Chapitre 11. Netfilter et iproute - marquage de paquets

   Jusqu' maintenant, nous avons vu comment iproute travaille, et
   netfilter a t mentionn plusieurs fois. Vous ne perdrez pas votre
   temps  consulter Rusty's Remarkably Unreliable Guides. Le logiciel
   Netfilter peut tre trouv ici.

   Netfilter nous permet de filtrer les paquets ou de dsosser leurs
   en-ttes. Une de ses fonctionnalits particulires est de pouvoir
   marquer un paquet avec un nombre, grce  l'option --set-mark.

   Comme exemple, la commande suivante marque tous les paquets destins
   au port 25, en l'occurrence le courrier sortant.
# iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 25 \
 -j MARK --set-mark 1

   Disons que nous avons plusieurs connexions, une qui est rapide (et
   chre au mgaoctet) et une qui est plus lente, mais avec un tarif
   moins lev. Nous souhaiterions que le courrier passe par la route la
   moins chre.

   Nous avons dj marqu le paquet avec un "1" et nous allons maintenant
   renseigner la base de donnes de la politique de routage pour qu'elle
   agisse sur ces paquets marqus.
# echo 201 mail.out >> /etc/iproute2/rt_tables
# ip rule add fwmark 1 table mail.out
# ip rule ls
0:      from all lookup local
32764:  from all fwmark        1 lookup mail.out
32766:  from all lookup main
32767:  from all lookup default

   Nous allons maintenant gnrer la table mail.out avec une route vers
   la ligne lente, mais peu coteuse.
   # /sbin/ip route add default via 195.96.98.253 dev ppp0 table mail.out

   Voil qui est fait. Il se peut que nous voulions mettre en place des
   exceptions, et il existe de nombreux moyens pour le faire. Nous
   pouvons modifier la configuration de netfilter pour exclure certains
   htes ou nous pouvons insrer une rgle avec une priorit plus faible
   qui pointe sur la table principale pour nos htes faisant exception.

   Nous pouvons aussi utiliser cette fonctionnalit pour nous conformer
   aux bits TOS en marquant les paquets avec diffrents types de service
   et les nombres correspondants. On cre ensuite les rgles qui agissent
   sur ces types de service. De cette faon, on peut ddier une ligne
   RNIS aux connexions interactives.

   Inutile de le dire, cela marche parfaitement sur un hte qui fait de
   la translation d'adresse (NAT), autrement dit du _masquerading_.

   IMPORTANT : Nous avons reu une information selon laquelle MASQ et
   SNAT entrent en conflit avec le marquage de paquets. Rusty Russell
   l'explique dans ce courrier.

   Dsactivez le filtrage de chemin inverse pour que cela fonctionne
   correctement.

   Note : pour marquer les paquets, vous aurez besoin de valider quelques
   options du noyau :
IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?]
IP: policy routing (CONFIG_IP_MULTIPLE_TABLES) [Y/n/?]
IP: use netfilter MARK value as routing key (CONFIG_IP_ROUTE_FWMARK) [Y/n/?]

   Voir aussi Section 15.5 dans le chapitre _Recettes de cuisine_.
     _________________________________________________________________

Chapitre 12. Filtres avancs pour la (re-)classification des paquets

   Comme expliqu dans la section sur les gestionnaires de mise en file
   d'attente bass sur des classes, les filtres sont ncessaires pour
   classifier les paquets dans n'importe laquelle des sous-files
   d'attente. Ces filtres sont appels  l'intrieur des gestionnaires de
   mise en file d'attente bass sur des classes.

   Voici une liste incomplte des classificateurs disponibles :

   fw
          Base la dcision sur la faon dont le pare-feu a marqu les
          paquets. Ceci peut tre un passage facile si vous ne voulez pas
          apprendre la syntaxe _tc_ lie aux filtres. Voir le chapitre
          sur les gestionnaires de mise en file d'attente pour plus de
          dtails.

   u32
          Base la dcision sur les champs  l'intrieur du paquet
          (c'est--dire l'adresse IP source, etc.)

   route
          Base la dcision sur la route que va emprunter le paquet.

   rsvp, rsvp6
          Route les paquets en se basant sur RSVP. Seulement utile sur
          les rseaux que vous contrlez. Internet ne respecte pas RSVP.

   tcindex
          Utilis par le gestionnaire de file d'attente DSMARK. Voir la
          section DSMARK.

   Notez qu'il y a gnralement plusieurs manires de classifier un
   paquet. Cela dpend du systme de classification que vous souhaitez
   utiliser.

   Les classificateurs acceptent en gnral quelques arguments communs.
   Ils sont lists ici pour des raisons pratiques :

   protocol
          Le protocole que ce classificateur acceptera. Gnralement, on
          n'acceptera que le trafic IP. Exig.

   parent
          Le descripteur auquel ce classificateur est attach. Ce
          descripteur doit tre une classe dj existante. Exig.

   prio
          La priorit de ce classificateur. Les plus petits nombres
          seront tests en premier.

   handle
          Cette rfrence a plusieurs significations suivant les
          diffrents filtres.

   Toutes les sections suivantes supposeront que vous essayez de mettre
   en forme le trafic allant vers HostA. Ces sections supposeront que la
   classe racine a t configure sur 1: et que la classe vers laquelle
   vous voulez envoyer le trafic slectionn est 1:1.
     _________________________________________________________________

12.1. Le classificateur u32

   Le filtre u32 est le filtre le plus avanc dans l'implmentation
   courante. Il est entirement bas sur des tables de hachage, ce qui le
   rend robuste quand il y a beaucoup de rgles de filtrage.

   Dans sa forme la plus simple, le filtre u32 est une liste
   d'enregistrements, chacun consistant en deux champs : un slecteur et
   une action. Les slecteurs, dcrits ci-dessous, sont compars avec le
   paquet IP trait jusqu' la premire correspondance, et l'action
   associe est ralise. Le type d'action le plus simple serait de
   diriger le paquet vers une classe CBQ dfinie.

   La ligne de commande du programme _tc filter_, utilise pour
   configurer le filtre, consiste en trois parties : la spcification du
   filtre, un slecteur et une action. La spcification du filtre peut
   tre dfinie comme :
tc filter add dev IF [ protocol PROTO ]
                     [ (preference|priority) PRIO ]
                     [ parent CBQ ]

   Le champ protocol dcrit le protocole sur lequel le filtre sera
   appliqu. Nous ne discuterons que du cas du protocole ip. Le champ
   preference (priority peut tre utilis comme alternative) fixe la
   priorit du filtre que l'on dfinit. C'est important dans la mesure o
   vous pouvez avoir plusieurs filtres (listes de rgles) avec des
   priorits diffrentes. Chaque liste sera scrute dans l'ordre d'ajout
   des rgles. Alors, la liste avec la priorit la plus faible (celle qui
   a le numro de prfrence le plus lev) sera traite. Le champ parent
   dfinit le sommet de l'arbre CBQ (par ex. 1:0) auquel le filtre doit
   tre attach.

   Les options dcrites s'appliquent  tous les filtres, pas seulement 
   u32.
     _________________________________________________________________

12.1.1. Le slecteur U32

   Le slecteur U32 contient la dfinition d'un modle, qui sera compar
   au paquet trait. Plus prcisment, il dfinit quels bits doivent
   correspondre dans l'en-tte du paquet, et rien de plus, mais cette
   mthode simple est trs puissante. Jetons un oeil sur l'exemple
   suivant, directement tir d'un filtre assez complexe rellement
   existant :
# tc filter parent 1: protocol ip pref 10 u32 fh 800::800 order 2048 key ht 800
 bkt 0 flowid 1:3 \
  match 00100000/00ff0000 at 0

   Pour l'instant, laissons de ct la premire ligne ; tous ces
   paramtres dcrivent les tables de hachage du filtre. Focalisons-nous
   sur la ligne de slection contenant le mot-cl match. Ce slecteur
   fera correspondre les en-ttes IP dont le second octet sera 0x10
   (0010). Comme nous pouvons le deviner, le nombre 00ff est le masque de
   correspondance, disant au filtre quels bits il doit regarder. Ici,
   c'est 0xff, donc l'octet correspondra si c'est exactement 0x10. Le
   mot-cl at signifie que la correspondance doit dmarrer au dcalage
   spcifi (en octets) - dans notre cas, c'est au dbut du paquet.
   Traduisons tout cela en langage humain : le paquet correspondra si son
   champ Type de Service (TOS) a le bit << faible dlai >> positionn.
   Analysons une autre rgle :
# tc filter parent 1: protocol ip pref 10 u32 fh 800::803 order 2051 key ht 800
 bkt 0 flowid 1:3 \
  match 00000016/0000ffff at nexthdr+0

   L'option nexthdr dsigne l'en-tte suivant encapsul dans le paquet
   IP, c'est  dire celui du protocole de la couche suprieure. La
   correspondance commencera galement au dbut du prochain en-tte. Elle
   devrait avoir lieu dans le deuxime mot de 32 bits de l'en-tte. Dans
   les protocoles TCP et UDP, ce champ contient le port de destination du
   paquet. Le nombre est donn dans le format big-endian, c'est--dire
   les bits les plus significatifs en premier. Il faut donc lire 0x0016
   comme 22 en dcimal, qui correspond au service SSH dans le cas de TCP.
   Comme vous le devinez, cette correspondance est ambigu sans un
   contexte, et nous en discuterons plus loin.

   Ayant compris tout cela, nous trouverons le slecteur suivant trs
   facile  lire : match c0a80100/ffffff00 at 16. Ce que nous avons ici,
   c'est une correspondance de trois octets au 17me octet, en comptant 
   partir du dbut de l'en-tte IP. Cela correspond aux paquets qui ont
   une adresse de destination quelconque dans le rseau 192.168.1/24.
   Aprs avoir analys les exemples, nous pouvons rsumer ce que nous
   avons appris.
     _________________________________________________________________

12.1.2. Slecteurs gnraux

   Les slecteurs gnraux dfinissent le modle, le masque et le
   dcalage qui seront compars au contenu du paquet. En utilisant les
   slecteurs gnraux, vous pouvez rechercher des correspondances sur
   n'importe quel bit de l'en-tte IP (ou des couches suprieures). Ils
   sont quand mme plus difficiles  crire et  lire que les slecteurs
   spcifiques dcrits ci-dessus. La syntaxe gnrale des slecteurs
   est :
   match [ u32 | u16 | u8 ] PATTERN MASK [ at OFFSET | nexthdr+OFFSET]

   Un des mots-cls u32, u16 ou u8 doit spcifier la longueur du modle
   en bits. PATTERN et MASK se rapporteront  la longueur dfinie par ce
   mot-cl. Le paramtre OFFSET est le dcalage, en octets, pour le
   dmarrage de la recherche de correspondance. Si le mot-clef nexthdr+
   est prsent, le dcalage sera relatif  l'en-tte de la couche rseau
   suprieure.

   Quelques exemples :
# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match u8 64 0xff at 8 \
     flowid 1:4

   Un paquet correspondra  cette rgle si sa << dure de vie >> (TTL)
   est de 64. TTL est le champ dmarrant juste aprs le 8me octet de
   l'en-tte IP.
# tc filter add dev ppp14 parent 1:0 prio 10 u32 \
     match u8 0x10 0xff at nexthdr+13 \
     protocol tcp \
     flowid 1:3 \

   FIXME: Il a t montr que cette syntaxe ne marche pas correctement.

   Utilisez ceci pour dterminer la prsence du bit ACK sur les paquets
   d'une longueur infrieure  64 octets :
## Vrifie la prsence d'un ACK,
## protocol IP 6,
## longueur de l'entte IP 0x5(mots de 32 bits),
## longueur total IP 0x34 (ACK + 12 octets d'options TCP)
## TCP ack actif (bit 5, offset 33)
# tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
            match ip protocol 6 0xff \
            match u8 0x05 0x0f at 0 \
            match u16 0x0000 0xffc0 at 2 \
            match u8 0x10 0xff at 33 \
            flowid 1:3

   Seuls les paquets TCP sans charge utile et avec le bit ACK positionn
   vrifieront cette rgle. Ici, nous pouvons voir un exemple
   d'utilisation de deux slecteurs, le rsultat final tant un ET
   logique de leur rsultat. Si nous jetons un coup d'oeil sur un schma
   de l'en-tte TCP, nous pouvons voir que le bit ACK est le second bit
   (0x10) du 14me octet de l'en-tte TCP (at nexthdr+13). Comme second
   slecteur, si nous voulons nous compliquer la vie, nous pouvons crire
   match u8 0x06 0xff at 9  la place du slecteur spcifique protocol
   tcp, puisque 6 est le numro du protocole TCP, spcifi au 10me octet
   de l'en-tte IP. D'un autre ct, dans cet exemple, nous ne pourrons
   pas utiliser de slecteur spcifique pour la premire correspondance,
   simplement parce qu'il n'y a pas de slecteur spcifique pour dsigner
   les bits TCP ACK.
     _________________________________________________________________

12.1.3. Les slecteurs spcifiques

   La table suivante contient la liste de tous les slecteurs spcifiques
   que les auteurs de cette section ont trouvs dans le code source du
   programme _tc_. Ils rendent simplement la vie plus facile en
   accroissant la lisibilit de la configuration du filtre.

   FIXME: emplacement de la table - la table est dans un fichier spar
   "selector.html"

   FIXME: C'est encore en Polonais :-( FIXME: doit tre "sgmlis"

   Quelques exemples :
# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
     match ip tos 0x10 0xff \
     flowid 1:4

   FIXME: tcp dst match ne fonctionne pas comme dcrit ci-dessous :

   La rgle ci-dessus correspondra  des paquets qui ont le champ TOS
   gal  0x10. Le champ TOS commence au deuxime octet du paquet et
   occupe 1 octet, ce qui nous permet d'crire un slecteur gnral
   quivalent : match u8 0x10 0xff at 1. Cela nous donne une indication
   sur l'implmentation du filtre u32. Les rgles spcifiques sont
   toujours traduites en rgles gnrales, et c'est sous cette forme
   qu'elles sont stockes en mmoire par le noyau. Cela amne  une autre
   conclusion : les slecteurs tcp et udp sont exactement les mmes et
   c'est la raison pour laquelle vous ne pouvez pas utiliser un simple
   slecteur match tcp dst 53 0xffff pour dsigner un paquet TCP envoy
   sur un port donn. Ce slecteur dsigne aussi les paquets UDP envoys
   sur ce port. Vous devez galement spcifier le protocole avec la rgle
   suivante :
# tc filter add dev ppp0 parent 1:0 prio 10 u32 \
        match tcp dst 53 0xffff \
        match ip protocol 0x6 0xff \
        flowid 1:2
     _________________________________________________________________

12.2. Le classificateur route

   Ce classificateur filtre en se basant sur les informations des tables
   de routage. Quand un paquet passant  travers les classes en atteint
   une qui est marque avec le filtre route, il divise le paquet en se
   basant sur l'information de la table de routage.
   # tc filter add dev eth1 parent 1:0 protocol ip prio 100 route

   Ici, nous ajoutons un classificateur route sur le noeud parent 1:0,
   avec la priorit 100. Quand un paquet atteint ce noeud (ce qui arrive
   immdiatement, puisqu'il est racine), il consulte la table de routage
   et si une entre de la table correspond, il envoie le paquet vers la
   classe donne et lui donne une priorit de 100. Ensuite, vous ajoutez
   l'entre de routage approprie pour finalement activer les choses.

   L'astuce ici est de dfinir realm en se basant soit sur la
   destination, soit sur la source. Voici la faon de procder :
   # ip route add Host/Network via Gateway dev Device realm RealmNumber

   Par exemple, nous pouvons dfinir notre rseau de destination
   192.168.10.0 avec le nombre realm gal  10 :
   # ip route add 192.168.10.0/24 via 192.168.10.1 dev eth1 realm 10

   Quand on ajoute des filtres route, on peut utiliser les nombres realm
   pour reprsenter les rseaux ou les htes et spcifier quelle est la
   correspondance entre les routes et les filtres.
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 \
  route to 10 classid 1:10

   La rgle ci-dessus indique que les paquets allant vers le rseau
   192.168.10.0 correspondent  la classe 1:10.

   Le filtre route peut aussi tre utilis avec les routes sources. Par
   exemple, il y a un sous-rseau attach  notre routeur Linux sur eth2.
# ip route add 192.168.2.0/24 dev eth2 realm 2
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 \
  route from 2 classid 1:2

   Ici, le filtre spcifie que les paquets venant du rseau 192.168.2.0
   (realm 2) correspondront  la classe 1:2.
     _________________________________________________________________

12.3. Les filtres de rglementation (_Policing filters_)

   Pour raliser des configurations encore plus compliques, vous pouvez
   avoir des filtres qui analysent le trafic  hauteur d'une certaine
   bande passante. Vous pouvez configurer un filtre pour qu'il cesse
   compltement l'analyse de tout le trafic au-dessus d'un certain dbit
   ou pour qu'il n'analyse pas la bande passante dpassant un certain
   dbit.

   Ainsi, si vous dcidez de rglementer  4mbit/s, mais qu'un trafic de
   5mbit/s est prsent, vous pouvez cesser d'analyser l'ensemble des
   5mbit/s ou seulement cesser d'analyser le 1 mbit/s supplmentaire et
   envoyer 4 mbit/s  la classe correspondante.

   Si la bande passante dpasse le dbit configur, vous pouvez rejeter
   un paquet, le reclassifier ou voir si un autre filtre y correspond.
     _________________________________________________________________

12.3.1. Techniques de rglementation

   Il y a essentiellement deux faons de rglementer. Si vous avez
   compil le noyau avec Estimators, celui-ci peut mesurer plus ou moins
   pour chaque filtre le trafic qui est pass. Ces estimations ne sont
   pas coteuses en temps CPU, tant donn qu'il ne compte que 25 fois
   par seconde le nombre de donnes qui sont passes, et qu'il calcule le
   dbit  partir de l.

   L'autre manire utilise encore le _Token Bucket Filter_ qui rside 
   l'intrieur du filtre cette fois. Le TBF analyse seulement le trafic
   _A HAUTEUR_ de la bande passante que vous avez configure. Si cette
   bande passante est dpasse, seul l'excs est trait par l'action de
   dpassement de limite configure.
     _________________________________________________________________

12.3.1.1. Avec l'estimateur du noyau

   Ceci est trs simple et il n'y a qu'un seul paramtre : avrate. Soit
   le flux demeure sous avrate et le filtre classifie le trafic vers la
   classe approprie, soit votre dbit le dpasse et l'action indique
   par dfaut, la << reclassification >>, est ralise dans ce cas.

   Le noyau utilise l'algorithme EWMA pour votre bande passante, ce qui
   la rend moins sensible aux courtes rafales de donnes.
     _________________________________________________________________

12.3.1.2. Avec le _Token Bucket Filter_

   Utilisez les paramtres suivants :

     * buffer/maxburst
     * mtu/minburst
     * mpu
     * rate

   Ceux-ci se comportent la plupart du temps de manire identique  ceux
   dcrits dans la section _Filtre  seau de jetons_. Notez cependant que
   si vous configurez le mtu du filtre de rglementation TBF trop bas,
   aucun paquet ne passera et le gestionnaire de mise en file d'attente
   de sortie TBF ne fera que les ralentir.

   Une autre diffrence est que la rglementation ne peut que laisser
   passer ou jeter un paquet. Il ne peut pas le retenir dans le but de le
   retarder.
     _________________________________________________________________

12.3.2. Actions de dpassement de limite (_Overlimit actions_)

   Si votre filtre dcide qu'un dpassement de limite est atteint, il
   peut mettre en oeuvre des << actions >>. Actuellement, trois actions
   sont disponibles :

   continue
          Provoque l'arrt de l'analyse du filtre, bien que d'autres
          filtres aient la possibilit de le faire.

   drop
          Ceci est une option trs froce qui supprime simplement le
          trafic excdant un certain dbit. Elle est souvent employe
          dans le _Ingress policer_ et a des utilisations limites. Par
          exemple, si vous avez un serveur de noms qui s'croule s'il
          traite plus de 5mbit/s de paquets, alors, vous pourrez dans ce
          cas utiliser un filtre d'entre pour tre sr qu'il ne traitera
          jamais plus de 5mbit/s.

   Pass/OK
          Transmettre le trafic. Peut tre utilis pour mettre hors
          service un filtre compliqu, tout en le laissant en place.

   reclassify
          Permet le plus souvent une reclassification vers _Best Effort_.
          Ceci est l'action par dfaut.
     _________________________________________________________________

12.3.3. Exemples

   Le seul vrai exemple connu est mentionn dans la section _Protger
   votre machine des inondations SYN_.

   FIXME: Si vous avez dj utilis ceci, partagez s'il vous plat votre
   exprience avec nous.
     _________________________________________________________________

12.4. Filtres hachs pour un filtrage massif trs rapide

   Si vous avez besoin de milliers de rgles, par exemple, dans le cas o
   vous avez beaucoup de clients ou d'ordinateurs, tous avec des
   spcifications QoS diffrentes, vous pourrez constater que le noyau
   passe beaucoup de temps  analyser toutes ces rgles.

   Par dfaut, tous les filtres rsident dans une grande chane qui est
   analyse par ordre dcroissant des priorits. Si vous avez 1000
   rgles, 1000 contrles peuvent tre ncessaires pour dterminer ce
   qu'il faut faire d'un paquet.

   La vrification irait plus vite s'il y avait 256 chanes avec chacune
   quatre rgles et si vous pouviez rpartir les paquets sur ces 256
   chanes, afin que la bonne rgle soit prsente.

   Ceci est rendu possible par le hachage. Imaginons que vous ayez sur
   votre rseau 1024 clients avec des modems cble, avec des adresses IP
   allant de 1.2.0.0  1.2.3.255, et que chacun doit avoir un classement
   particulier, par exemple << pauvre >>, << moyen >> et << bourrage >>.
   Cela vous ferait alors 1024 rgles, dans le genre :
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.1 classid 1:1
...
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.3.254 classid 1:3
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.3.255 classid 1:2

   Pour aller plus vite, nous pouvons utiliser la dernire partie de
   l'adresse IP comme << cl de hachage >>. Nous obtenons alors 256
   tables, la premire ressemblant  ceci :
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.1.0 classid 1:1
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.2.0 classid 1:3
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.3.0 classid 1:2

   La suivante commence comme ceci :
# tc filter add dev eth1 parent 1:0 protocol ip prio 100 match ip src \
  1.2.0.1 classid 1:1
...

   De cette manire, seules quatre recherches au plus sont ncessaires et
   deux en moyenne.

   La configuration est plutt complique, mais elle en vaut vraiment la
   peine du fait des nombreuses rgles. Nous crons d'abord un filtre
   racine, puis une table avec 256 entres :
# tc filter add dev eth1 parent 1:0 prio 5 protocol ip u32
# tc filter add dev eth1 parent 1:0 prio 5 handle 2: u32 divisor 256

   Nous ajoutons maintenant des rgles dans la table prcdemment cre :
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.0.123 flowid 1:1
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.1.123 flowid 1:2
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.3.123 flowid 1:3
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 2:7b: \
        match ip src 1.2.4.123 flowid 1:2

   Ceci est l'entre 123, qui contient les correspondances pour 1.2.0.13,
   1.2.1.123, 1.2.2.123 et 1.2.3.123 qui les envoient respectivement vers
   1:1, 1:2, 1:3 et 1:2. Notez que nous devons spcifier notre seau de
   hachage en hexadcimal, 0x7b pour 123.

   Nous crons ensuite un << filtre de hachage >>qui dirige le trafic
   vers la bonne entre de la table de hachage :
# tc filter add dev eth1 protocol ip parent 1:0 prio 5 u32 ht 800:: \
        match ip src 1.2.0.0/16 \
        hashkey mask 0x000000ff at 12 \
        link 2:

   Ok, certains nombres doivent tre expliqus. La table de hachage par
   dfaut est appele 800:: et tous les filtres dmarrent de l. Nous
   slectionnons alors l'adresse source qui est en position 12, 13, 14 et
   15 dans l'en-tte IP, et indiquons que seule la dernire partie nous
   intresse. Ceci est envoy vers la table de hachage 2: qui a t cre
   plus tt.

   C'est plutt compliqu, mais cela marche en pratique et les
   performances seront poustouflantes. Notez que cet exemple pourrait
   tre amlior pour que chaque chane contienne un filtre, ce qui
   reprsenterait le cas idal !
     _________________________________________________________________

Chapitre 13. Paramtres rseau du noyau

   Le noyau utilise de nombreux paramtres qui peuvent tre ajusts en
   diffrentes circonstances. Bien que, comme d'habitude, les paramtres
   par dfaut conviennent  99% des installations, nous ne pourrions pas
   appeler ce document << HOWTO avanc >> sans en dire un mot.

   Les lments intressants sont dans /proc/sys/net, jetez-y un oeil.
   Tout ne sera pas document ici au dpart, mais nous y travaillons.

   En attendant, vous pouvez jeter un oeil dans les sources du noyau
   Linux et lire le fichier Documentation/filesystems/proc.txt. La
   plupart des fonctionnalits y sont expliques.
     _________________________________________________________________

13.1. Filtrage de Chemin Inverse (_Reverse Path Filtering_)

   Par dfaut, les routeurs routent tout, mme les paquets qui
   visiblement n'appartiennent pas  votre rseau. Un exemple courant est
   l'espace des adresses IP prives s'chappant sur Internet. Si vous
   avez une interface avec une route pour 195.96.96.0/24 dessus, vous ne
   vous attendrez pas  voir arriver des paquets venant de 212.64.94.1.

   Beaucoup d'utilisateurs veulent dsactiver cette fonctionnalit. Les
   dveloppeurs du noyau ont permis de le faire facilement. Il y a des
   fichiers dans /proc o vous pouvez ordonner au noyau de le faire pour
   vous. La mthode est appele << Filtrage par Chemin Inverse >>
   (_Reverse Path Filtering_). Pour faire simple, si la rponse  ce
   paquet ne sort pas par l'interface par laquelle il est entr, alors
   c'est un paquet << bogu >> et il sera ignor.

   Les instructions suivantes vont activer cela pour toutes les
   interfaces courantes et futures.
# for i in /proc/sys/net/ipv4/conf/*/rp_filter ; do
>  echo 2 > $i
> done

   En reprenant l'exemple du dbut, si un paquet arrivant sur le routeur
   Linux par eth1 prtend venir du rseau Bureau+FAI, il sera limin. De
   mme, si un paquet arrivant du rseau Bureau prtend tre de quelque
   part  l'extrieur du pare-feu, il sera galement limin.

   Ce qui est prsent ci-dessus est le filtrage de chemin inverse
   complet. Le paramtrage par dfaut filtre seulement sur les adresses
   IP des rseaux directement connects. Ce paramtrage par dfaut est
   utilis parce que le filtrage complet choue dans le cas d'un routage
   asymtrique (o il y a des paquets arrivant par un chemin et
   ressortant par un autre, comme dans le cas du trafic satellite ou si
   vous avez des routes dynamiques (bgp, ospf, rip) dans votre rseau.
   Les donnes descendent vers la parabole satellite et les rponses
   repartent par des lignes terrestres normales).

   Si cette exception s'applique dans votre cas (vous devriez tre au
   courant), vous pouvez simplement dsactiver le rp_filter sur
   l'interface d'arrive des donnes satellite. Si vous voulez voir si
   des paquets sont limins, le fichier log_martians du mme rpertoire
   indiquera au noyau de les enregistrer dans votre syslog.
   # echo 1 >/proc/sys/net/ipv4/conf/<interfacename>/log_martians

   FIXME: Est-ce que la configuration des fichiers dans
   .../conf/{default,all} suffit ? - martijn
     _________________________________________________________________

13.2. Configurations obscures

   Bon, il y a beaucoup de paramtres qui peuvent tre modifis. Nous
   essayons de tous les lister. Voir aussi une documentation partielle
   dans Documentation/ip-sysctl.txt.

   Certaines de ces configurations ont des valeurs par dfaut diffrentes
   suivant que vous rpondez Yes ou No  la question Configure as router
   and not host lors de la compilation du noyau.
     _________________________________________________________________

13.2.1. ipv4 gnrique

   En remarque gnrale, les fonctionnalits de limitation de dbit ne
   fonctionnent pas sur l'interface loopback. N'essayez donc pas de les
   tester localement. Les limites sont exprimes en << tic-tac >>
   (_jiffies_) et elles utilisent obligatoirement le _Token Bucket Filter_
   mentionn plus tt.

   [NdT : le terme _jiffies_ dsigne un mouvement rgulier, faisant
   rfrence au << tic-tac >> d'une horloge. Dans le noyau lui-mme, une
   variable globale nomme jiffies est incrment  chaque interruption
   d'horloge]

   Le noyau a une horloge interne qui tourne  HZ impulsions (ou
   _jiffies_) par seconde. Sur intel, HZ est la plupart du temps de gale 
   100. Donc, configurer un fichier *_rate , disons 50, autorise 2
   paquets par seconde. Le _Token Bucket Filter_ est galement configur
   pour autoriser une rafale de donnes de 6 paquets au plus, si
   suffisamment de jetons ont t gagns.

   Plusieurs lments de la liste suivante proviennent du fichier
   /usr/src/linux/Documentation/networking/ip-sysctl.txt, crit par
   Alexey Kuznetsov <kuznet@ms2.inr.ac.ru> et Andi Kleen <ak@muc.de>.

   /proc/sys/net/ipv4/icmp_destunreach_rate
          Si le noyau dcide qu'il ne peut pas dlivrer un paquet, il le
          rejetera et enverra  la source du paquet un ICMP notifiant ce
          rejet.

   /proc/sys/net/ipv4/icmp_echo_ignore_all
          N'agit en aucun cas comme cho pour les paquets. Ne configurez
          pas ceci par dfaut. Cependant, si vous tes utilis comme
          relais dans une attaque de Dni de Services, cela peut tre
          utile.

   /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts [Utile]
          Si vous pinguez l'adresse de diffusion d'un rseau, tous les
          htes sont censs rpondre. Cela permet de coquettes attaques
          de dni de service. Mettez cette valeur  1 pour ignorer ces
          messages de diffusion.

   /proc/sys/net/ipv4/icmp_echoreply_rate
          Le dbit auquel les rponses echo sont envoyes aux
          destinataires.

   /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
          Configurer ceci pour ignorer les erreurs ICMP d'htes du rseau
          ragissant mal aux trames envoyes vers ce qu'ils peroivent
          comme l'adresse de diffusion.

   /proc/sys/net/ipv4/icmp_paramprob_rate
          Un message ICMP relativement peu connu, qui est envoy en
          rponse  des paquets qui ont des en-ttes IP ou TCP errons.
          Avec ce fichier, vous pouvez contrler le dbit auquel il est
          envoy.

   /proc/sys/net/ipv4/icmp_timeexceed_rate
          Voici la clbre cause des << toiles Solaris >> dans
          traceroute. Limite le nombre de messages ICMP Time Exceeded
          envoys.

   /proc/sys/net/ipv4/igmp_max_memberships
          Nombre maximal de sockets igmp (multidistribution) en coute
          sur l'hte. FIXME: Est-ce vrai ?

   /proc/sys/net/ipv4/inet_peer_gc_maxtime
          FIXME : Ajouter une petite explication sur le stockage des
          partenaires internet (inet peer) ? Intervalle de temps minimum
          entre deux passages du ramasse-miettes. Cet intervalle est pris
          en compte lors d'une faible (voire inexistante) utilisation du
          _pool_. Mesur en _jiffies_. [NdT : Le _pool_ dsigne ici la
          liste des adresses IP des partenaires internet.]

   /proc/sys/net/ipv4/inet_peer_gc_mintime
          Intervalle de temps minimum entre deux passages du
          ramasse-miettes. Cet intervalle est pris en compte lors d'une
          utilisation intensive du _pool_. Mesur en _jiffies_.

   /proc/sys/net/ipv4/inet_peer_maxttl
          Dure de conservation maximale des enregistrements. Les entres
          non utilises expireront au bout de cet intervalle de temps
          (c'est--dire quand le nombre d'entres dans le _pool_ est trs
          petit). Mesur en _jiffies_.

   /proc/sys/net/ipv4/inet_peer_minttl
          Dure de conservation minimale des enregistrements. Devrait
          tre suffisante pour prendre en compte le temps de vie des
          fragments sur l'hte qui doit rassembler les paquets. Cette
          dure minimale est garantie si le nombre d'lments dans le
          _pool_ est infrieur au seuil fix par inet_peer_threshold.

   /proc/sys/net/ipv4/inet_peer_threshold
          Taille approximative de l'espace de stockage des partenaires
          internet. A partir de ce seuil, les entres sont effaces. Ce
          seuil dtermine la dure de vie des entres, ainsi que les
          intervalles de temps entre deux dclenchements du
          ramasse-miettes. Plus il y a d'entres, plus le temps de vie
          est faible et plus l'intervalle du ramasse-miettes est faible.

   /proc/sys/net/ipv4/ip_autoconfig
          Ce fichier contient la valeur 1 si l'hte a reu sa
          configuration IP par RARP, BOOTP, DHCP ou un mcanisme
          similaire. Autrement, il contient la valeur zro.

   /proc/sys/net/ipv4/ip_default_ttl
          Dure de vie (TTL) des paquets. Fixer  la valeur sre de 64.
          Augmentez-la si vous avez un rseau immense, mais pas << pour
          s'amuser >> : les boucles sans fin d'un mauvais routage sont
          plus dangereuses si le TTL est lev. Vous pouvez mme
          envisager de diminuer la valeur dans certaines circonstances.

   /proc/sys/net/ipv4/ip_dynaddr
          Vous aurez besoin de positionner cela si vous utilisez la
          connexion  la demande avec une adresse d'interface dynamique.
          Une fois que votre interface a t configure, toutes les
          sockets TCP locaux qui n'ont pas eu de paquets de rponse
          seront retraites pour avoir la bonne adresse. Cela rsout le
          problme pos par une connexion dfectueuse ayant configur une
          interface, suivie par une deuxime tentative russie (avec une
          adresse IP diffrente).

   /proc/sys/net/ipv4/ip_forward
          Le noyau doit-il essayer de transmettre les paquets ? Dsactiv
          par dfaut.

   /proc/sys/net/ipv4/ip_local_port_range
          Intervalle des ports locaux pour les connexions sortantes. En
          fait, assez petit par dfaut, 1024  4999.

   /proc/sys/net/ipv4/ip_no_pmtu_disc
          Configurez ceci si vous voulez dsactiver la dcouverte du MTU
          de chemin, une technique pour dterminer le plus grand MTU
          possible sur votre chemin. Voir aussi la section sur la
          dcouverte du MTU de chemin dans le chapitre _Recettes de
          cuisine_.

   /proc/sys/net/ipv4/ipfrag_high_thresh
          Mmoire maximum utilise pour rassembler les fragments IP.
          Quand ipfrag_high_thresh octets de mmoire sont allous pour
          cela, le gestionnaire de fragments rejettera les paquets
          jusqu' ce que ipfrag_low_thresh soit atteint.

   /proc/sys/net/ipv4/ip_nonlocal_bind
          Configurez ceci si vous voulez que vos applications soient
          capables de se lier  une adresse qui n'appartient pas  une
          interface de votre systme. Ceci peut tre utile quand votre
          machine est sur un lien non-permanent (ou mme permanent). Vos
          services sont donc capables de dmarrer et de se lier  une
          adresse spcifique quand votre lien est inactif.

   /proc/sys/net/ipv4/ipfrag_low_thresh
          Mmoire minimale utilise pour rassembler les fragments IP.

   /proc/sys/net/ipv4/ipfrag_time
          Temps en secondes du maintien d'un fragment IP en mmoire.

   /proc/sys/net/ipv4/tcp_abort_on_overflow
          Une option boolenne contrlant le comportement dans le cas de
          nombreuses connexions entrantes. Quand celle-ci est active, le
          noyau envoie rapidement des paquets RST quand un service est
          surcharg.

   /proc/sys/net/ipv4/tcp_fin_timeout
          Temps de maintien de l'tat FIN-WAIT-2 pour un socket dans le
          cas o il a t ferm de notre ct. Le partenaire peut tre
          dfectueux et ne jamais avoir ferm son ct ou mme mourir de
          manire inattendue. La valeur par dfaut est de 60 secondes. La
          valeur usuelle utilise dans le noyau 2.2 tait de 180
          secondes. Vous pouvez la remettre, mais rappelez vous que si
          votre machine a un serveur WEB surcharg, vous risquez de
          dpasser la mmoire avec des kilotonnes de sockets morts. Les
          sockets FIN-WAIT2 sont moins dangereux que les sockets
          FIN-WAIT1 parce qu'ils consomment au maximum 1,5K de mmoire,
          mais ils ont tendance  vivre plus longtemps. Cf
          tcp_max_orphans.

   /proc/sys/net/ipv4/tcp_keepalive_time
          Dure entre l'envoi de deux messages _keepalive_ quand l'option
          _keepalive_ est active. Par dfaut : 2 heures.

   /proc/sys/net/ipv4/tcp_keepalive_intvl
          A quelle frquence les sondes sont retransmises lorsqu'il n'y a
          pas eu acquittement de sonde. Par dfaut : 75 secondes.

   /proc/sys/net/ipv4/tcp_keepalive_probes
          Combien de sondes TCP _keepalive_ seront envoyes avant de
          dcider que la connexion est brise. Par dfaut : 9. En
          multipliant par tcp_keepalive_intvl, cela donne le temps
          pendant lequel un lien peut tre actif sans donner de rponses
          aprs l'envoi d'un _keepalive_.

   /proc/sys/net/ipv4/tcp_max_orphans
          Nombre maximum de sockets TCP qui ne sont pas relis  un
          descripteur de fichier utilisateur, gr par le systme. Si ce
          nombre est dpass, les connexions orphelines sont
          immdiatement rinitialises et un avertissement est envoy.
          Cette limite existe seulement pour prvenir des attaques de
          dni de services simples. Vous ne devez pas compter sur ceci ou
          diminuer cette limite artificiellement, mais plutt l'augmenter
          (probablement aprs avoir augment la mmoire) si les
          conditions du rseau rclament plus que cette valeur par dfaut
          et rgler vos services rseau pour qu'ils dtruisent sans
          tarder ce type d'tat. Laissez-moi vous rappeler encore que
          chaque orphelin consomme jusqu' environ 64K de mmoire non
          _swappable_.

   /proc/sys/net/ipv4/tcp_orphan_retries
          Combien d'essais avant de dtruire une connexion TCP, ferme
          par notre ct. La valeur par dfaut de 7 correspond  un temps
          d'environ 50s  16 min suivant le RTO. Si votre machine
          supporte un serveur Web, vous pouvez envisager de baisser cette
          valeur, dans la mesure o de tels sockets peuvent consommer des
          ressources significatives. Cf tcp_max_orphans.

   /proc/sys/net/ipv4/tcp_max_syn_backlog
          Nombre maximum de requtes d'une connexion mmorise, qui
          n'avait pas encore reu d'accus de rception du client
          connect. La valeur par dfaut est de 1024 pour des systmes
          avec plus de 128 Mo de mmoire et 128 pour des machines avec
          moins de mmoire. Si un serveur souffre de surcharge, essayez
          d'augmenter ce nombre. Attention ! Si vous positionnez une
          valeur suprieure  1024, il serait prfrable de changer
          TCP_SYNQ_HSIZE dans le fichier include/net/tcp.h pour garder
          TCP_SYNQ_HSIZE*16 <= tcp_max_syn_backlog et de recompiler de
          noyau.

   /proc/sys/net/ipv4/tcp_max_tw_buckets
          Nombre maximum de sockets timewait gres par le systme
          simultanment. Si ce nombre est dpass, le socket timewait est
          immdiatement dtruit et un message d'avertissement est envoy.
          Cette limite n'existe que pour prvenir des attaques de dni de
          services simples. Vous ne devez pas diminuer cette limite
          artificiellement, mais plutt l'augmenter (probablement aprs
          avoir augment la mmoire) si les conditions du rseau
          rclament plus que cette valeur par dfaut.

   /proc/sys/net/ipv4/tcp_retrans_collapse
          Compatibilit bug  bug avec certaines imprimantes
          dfectueuses. Tentative d'envoi de plus gros paquets lors de la
          retransmission pour contourner le bug de certaines piles TCP.

   /proc/sys/net/ipv4/tcp_retries1
          Combien d'essais avant de dcider que quelque chose est erron
          et qu'il est ncessaire d'informer de cette suspicion la couche
          rseau. La valeur minimale du RFC est de 3. C'est la valeur par
          dfaut ; elle correspond  un temps d'environ 3 sec  8 min
          suivant le RTO.

   /proc/sys/net/ipv4/tcp_retries2
          Combien d'essais avant de dtruire une connexion TCP active. Le
          RFC 1122 prcise que la limite ne devrait pas dpasser 100
          secondes. C'est un nombre trop petit. La valeur par dfaut de
          15 correspond  un temps de environ 13  30 minutes suivant le
          RTO.

   /proc/sys/net/ipv4/tcp_rfc1337
          Ce boolen active un rectificatif pour << l'assassinat
          hasardeux des time-wait dans tcp >>, dcrit dans le RFC 1337.
          S'il est activ, le noyau rejette les paquets RST pour les
          sockets  l'tat de time-wait. Par dfaut : 0

   /proc/sys/net/ipv4/tcp_sack
          Utilise un ACK slectif qui peut tre utilis pour signifier
          que des paquets spcifiques sont manquant. Facilite ainsi une
          rcupration rapide.

   /proc/sys/net/ipv4/tcp_stdurg
          Utilise l'interprtation du RFC _Host Requirements_ du champ
          TCP pointeur urgent. La plupart des htes utilisent la vieille
          interprtation BSD. Donc, si vous activez cette option, il se
          peut que Linux ne communique plus correctement avec eux. Par
          dfaut : FALSE (FAUX)

   /proc/sys/net/ipv4/tcp_syn_retries
          Nombre de paquets SYN que le noyau enverra avant de tenter
          l'tablissement d'une nouvelle connexion.

   /proc/sys/net/ipv4/tcp_synack_retries
          Pour ouvrir l'autre ct de la connexion, le noyau envoie un
          SYN avec un ACK superpos (_piggyback_), pour accuser rception
          du SYN prcdemment envoy. C'est la deuxime partie de la
          poigne de main  trois voies (_threeway handshake_). Cette
          configuration dtermine le nombre de paquets SYN+ACK  envoyer
          avant que le noyau n'abandonne la connexion.

   /proc/sys/net/ipv4/tcp_timestamps
          Les estampillages horaires sont utiliss, entre autres, pour se
          protger du rebouclage des numros de squence. On peut
          concevoir qu'un lien  1 gigabit puisse de nouveau rencontrer
          un numro de squence prcdent avec une valeur hors-ligne
          parcequ'il tait d'une gnration prcdente. L'estampillage
          horaire permet de reconnatre cet << ancien paquet >>.

   /proc/sys/net/ipv4/tcp_tw_recycle
          Mise en place du recyclage rapide des sockets TIME-WAIT. La
          valeur par dfaut est 1. Celle-ci ne devrait pas tre change
          sans le conseil/demande d'experts techniques.

   /proc/sys/net/ipv4/tcp_window_scaling
          TCP/IP autorise normalement des fentres jusqu' une taille de
          65535 octets. Pour des rseaux vraiment rapides, cela peut ne
          pas tre assez. Les options windows scaling autorisent des
          fentres jusqu'au gigaoctet, ce qui est adapt pour les
          produits  grande bande passante.
     _________________________________________________________________

13.2.2. Configuration des priphriques

   DEV peut dsigner soit une interface relle, soit all, soit default.
   Default change galement les paramtres des interfaces qui seront
   cres par la suite.

   /proc/sys/net/ipv4/conf/DEV/accept_redirects
          Si un routeur dcide que vous l'utilisez  tort (c'est--dire
          qu'il a besoin de r-envoyer votre paquet sur la mme
          interface), il vous enverra un message ICMP Redirect. Cela
          prsente cependant un petit risque pour la scurit, et vous
          pouvez le dsactiver ou utiliser les redirections scurises.

   /proc/sys/net/ipv4/conf/DEV/accept_source_route
          Plus vraiment utilis. On l'utilisait pour tre capable de
          donner  un paquet une liste d'adresses IP  visiter. Linux
          peut tre configur pour satisfaire cette option IP.

   /proc/sys/net/ipv4/conf/DEV/bootp_relay
          Accepte les paquets avec une adresse source 0.b.c.d et des
          adresses destinations qui ne correspondent ni  cet hte, ni au
          rseau local. On suppose qu'un dmon de relais BOOTP
          interceptera et transmettra de tels paquets.

          La valeur par dfaut est 0, puique cette fonctionnalit n'est
          pas encore implmente (noyau 2.2.12).

   /proc/sys/net/ipv4/conf/DEV/forwarding
          Active ou dsactive la transmission IP sur cette interface.

   /proc/sys/net/ipv4/conf/DEV/log_martians
          Voir la section sur le _Filtrage de Chemin Inverse_.

   /proc/sys/net/ipv4/conf/DEV/mc_forwarding
          Si vous faites de la transmission multidistribution
          (_multicast_) sur cette interface.

   /proc/sys/net/ipv4/conf/DEV/proxy_arp
          Si vous configurez ceci  1, cet interface rpondra aux
          requtes ARP pour les adresses que le noyau doit router. Peut
          tre trs utile si vous mettez en place des << pseudo-ponts
          ip >>. Prenez bien garde d'avoir des masques de sous-rseau
          corrects avant d'activer cette option. Faites galement
          attention que le rp_filter agisse aussi sur le requtes ARP !

   /proc/sys/net/ipv4/conf/DEV/rp_filter
          Voir la section sur le _Filtrage de Chemin Inverse_.

   /proc/sys/net/ipv4/conf/DEV/secure_redirects
          Accepte les messages de redirection ICMP seulement pour les
          passerelles indiques dans la liste des passerelles par dfaut.
          Activ par dfaut.

   /proc/sys/net/ipv4/conf/DEV/send_redirects
          Active la possibilit d'envoyer les messages de redirections
          mentionnes ci-dessus.

   /proc/sys/net/ipv4/conf/DEV/shared_media
          Si cela n'est pas activ, le noyau ne considre pas que
          diffrents sous-rseaux peuvent communiquer directement sur
          cette interface. La configuration par dfaut est Yes.

   /proc/sys/net/ipv4/conf/DEV/tag
          FIXME:  remplir
     _________________________________________________________________

13.2.3. Politique de voisinage

   DEV peut dsigner soit une interface relle, soit all, soit default.
   Default change galement les paramtres des interfaces qui seront
   cres par la suite.

   /proc/sys/net/ipv4/neigh/DEV/anycast_delay
          Valeur maximum du dlai alatoire de rponse exprim en
          _jiffies_ (1/100 sec) aux messages de sollicitation des voisins.
          N'est pas encore implment (Linux ne possde pas encore le
          support _anycast_).

   /proc/sys/net/ipv4/neigh/DEV/app_solicit
          Dtermine le nombre de requtes  envoyer au dmon ARP de
          l'espace utilisateur. Utilisez 0 pour dsactiver.

   /proc/sys/net/ipv4/neigh/DEV/base_reachable_time
          Une valeur de base utilise pour le calcul du temps alatoire
          d'accs comme spcifi dans le RFC2461.

   /proc/sys/net/ipv4/neigh/DEV/delay_first_probe_time
          Dlai avant de tester pour la premire fois si le voisin peut
          tre atteint. (voir gc_stale_time)

   /proc/sys/net/ipv4/neigh/DEV/gc_stale_time
          Dtermine la frquence  laquelle on doit vrifier les vieilles
          entres ARP. Si une entre est obsolte, elle devra de nouveau
          tre rsolue (ce qui est utile quand une adresse IP a t
          attribue  une autre machine). Si ucast_solicit est suprieur
           0, alors on essaie d'abord d'envoyer un paquet ARP
          directement  l'hte connu. Si cela choue, et que
          mcast_solicit est suprieur  0, alors une requte ARP est
          multidiffuse.

   /proc/sys/net/ipv4/neigh/DEV/locktime
          Une entre ARP n'est remplace par une nouvelle que si
          l'ancienne est au moins prsente depuis locktime. Cela vite
          trop d'criture dans le cache.

   /proc/sys/net/ipv4/neigh/DEV/mcast_solicit
          Nombre maximum d'essais conscutifs pour une sollicitation
          _multicast_.

   /proc/sys/net/ipv4/neigh/DEV/proxy_delay
          Temps maximum (le temps rel est alatoire et compris entre 0
          et proxytime) avant de rpondre  une requte ARP pour laquelle
          nous avons une entre de proxy ARP. Peut tre utilis dans
          certains cas pour se prmunir des inondations rseaux.

   /proc/sys/net/ipv4/neigh/DEV/proxy_qlen
          Longueur maximale de la file d'attente du temporisateur de
          cache arp en attente (Voir proxy_delay).

   /proc/sys/net/ipv4/neigh/DEV/retrans_time
          Le temps, exprim en _jiffies_ (1/100 sec), entre deux requtes
          ARP. Utilis pour la rsolution d'adresses et pour dterminer
          si un voisin est inaccessible.

   /proc/sys/net/ipv4/neigh/DEV/ucast_solicit
          Nombre maximum de requtes ARP unicast.

   /proc/sys/net/ipv4/neigh/DEV/unres_qlen
          Longueur maximum de la file d'attente pour la requte ARP en
          cours : le nombre de paquets qui sont accepts des autres
          couches pendant la rsolution ARP d'une adresse.

   Internet QoS: Architectures and Mechanisms for Quality of Service,
          Zheng Wang, ISBN 1-55860-608-4
          Livre traitant des sujets lis  la qualit de service. Bien
          pour comprendre les concepts de base.
     _________________________________________________________________

13.2.4. Configuration du routage

   /proc/sys/net/ipv4/route/error_burst
          Ces paramtres sont utiliss pour limiter le nombre de messages
          d'avertissement crits dans le journal du noyau par le code de
          routage. Plus le paramtre error_burst est grand, moins il y
          aura de messages. Error_burst contrle le moment o les
          messages seront supprims. Les configurations par dfaut se
          limitent  un message d'avertissement toutes les cinq secondes.

   /proc/sys/net/ipv4/route/error_cost
          Ces paramtres sont utiliss pour limiter le nombre de messages
          d'avertissement crits dans le journal du noyau par le code de
          routage. Plus le paramtre error_cost est grand, moins il y
          aura de messages. error_burst contrle le moment o les
          messages seront jets. Les configurations par dfaut se
          limitent  un message d'avertissement toutes les cinq secondes.

   /proc/sys/net/ipv4/route/flush
          L'criture dans ce fichier provoque la vidange du cache du
          routage.

   /proc/sys/net/ipv4/route/gc_elasticity
          Valeurs qui contrlent la frquence et le comportement de
          l'algorithme _garbage collection_ du cache de routage. Ceci
          peut tre important en cas de dfaut. Au moins gc_timeout
          secondes s'couleront avant que le noyau ne passe  une autre
          route si la prcdente n'est plus oprationnelle. Configur par
          dfaut  300. Diminuez cette valeur si vous voulez passer plus
          rapidement ce type de problme.

          Voir aussi ce message par Ard van Breemen.

   /proc/sys/net/ipv4/route/gc_interval
          Voir /proc/sys/net/ipv4/route/gc_elasticity.

   /proc/sys/net/ipv4/route/gc_min_interval
          Voir /proc/sys/net/ipv4/route/gc_elasticity.

   /proc/sys/net/ipv4/route/gc_thresh
          Voir /proc/sys/net/ipv4/route/gc_elasticity.

   /proc/sys/net/ipv4/route/gc_timeout
          Voir /proc/sys/net/ipv4/route/gc_elasticity.

   /proc/sys/net/ipv4/route/max_delay
          Dlai d'attente pour la vidange du cache du routage.

   /proc/sys/net/ipv4/route/max_size
          Taille maximum du cache de routage. Les vieilles entres seront
          purges quand le cache aura atteint cette taille.

   /proc/sys/net/ipv4/route/min_adv_mss
          FIXME:  remplir

   /proc/sys/net/ipv4/route/min_delay
          Dlai d'attente pour vider le cache de routage.

   /proc/sys/net/ipv4/route/min_pmtu
          FIXME:  remplir

   /proc/sys/net/ipv4/route/mtu_expires
          FIXME:  remplir

   /proc/sys/net/ipv4/route/redirect_load
          Facteurs qui dterminent si plus de redirections ICMP doivent
          tre envoyes  un hte spcifique. Aucune redirection ne sera
          envoye une fois que la limite de charge (_load limit_) ou que
          le nombre maximum de redirections aura t atteint.

   /proc/sys/net/ipv4/route/redirect_number
          Voir /proc/sys/net/ipv4/route/redirect_load.

   /proc/sys/net/ipv4/route/redirect_silence
          Temporisation pour les redirections. Au dela de cette priode,
          les redirections seront de nouveau envoyes, mme si elles ont
          t stoppes parce que la charge ou le nombre limite a t
          atteint.
     _________________________________________________________________

Chapitre 14. Gestionnaires de mise en file d'attente avancs & moins communs

   Si vous constatez que vous avez des besoins qui ne sont pas grs par
   les files d'attente cites prcdemment, le noyau contient quelques
   autres files d'attente plus spcialises mentionnes ici.
     _________________________________________________________________

14.1. bfifo/pfifo

   Ces files d'attente sans classes sont plus simples que pfifo_fast dans
   la mesure o elles n'ont pas de bandes internes, tout le trafic tant
   vraiment quivalent. Elles ont cependant l'avantage important de
   raliser des statistiques. Donc, mme si vous n'avez pas besoin de
   mise en forme ou de donner une priorit, vous pouvez employer ce
   gestionnaire pour dterminer l'arrir (_backlog_) de votre interface.

   pfifo mesure en paquets et bfifo en octets.
     _________________________________________________________________

14.1.1. Paramtres & usage

   limit
          Spcifie la taille de la file d'attente. Mesure en octets pour
          bfifo et en paquets pour pfifo. Par dfaut, correspond  des
          paquets de taille gale au paramtre txqueuelen de l'interface
          (voir le chapitre pfifo_fast) ou txqueuelen*mtu octets pour
          bfifo.
     _________________________________________________________________

14.2. Algorithme Clark-Shenker-Zhang (CSZ)

   Ceci est si thorique que mme Alexey (l'auteur principal de CBQ)
   prtend ne pas le comprendre. De son propre avis :

     David D. Clark, Scott Shenker and Lixia Zhang _Supporting Real-Time
     Applications in an Integrated Services Packet Network: Architecture
     and Mechanism_.

     Comme je le comprends, l'ide principale est de crer des flux WFQ
     pour chaque service garanti et d'allouer le reste de la bande
     passante au flux factice, appel flow-0. Le Flux-0 inclut le trafic
     de service prdictif et le trafic _best-effort_. Il est trait par
     un ordonnanceur de priorit qui alloue la bande passante de plus
     grande priorit aux services prdictifs, et le reste aux paquets
     _best-effort_.

     Notez que dans CSZ, les flux ne sont _PAS_ limits  leur bande
     passante. On suppose que le flux a pass le contrle d'admission 
     la frontire du rseau QoS et qu'il n'a pas besoin de mises en
     forme supplmentaires. N'importe quelles autres tentatives pour
     amliorer le flux ou pour le mettre en forme grce  un seau de
     jetons lors d'tapes intermdiaires introduiront des retards non
     dsirs et augmenteront la gigue.

     A l'heure actuelle, CSZ est le seul ordonnanceur qui fournit un
     vritable service garanti. Les autres implmentations (incluant
     CBQ) n'assurent pas un dlai garanti et rendent la gigue alatoire.

     Ne semble pas actuellement un bon candidat  utiliser,  moins que
     vous n'ayez lu et compris l'article mentionn.
     _________________________________________________________________

14.3. DSMARK

   Esteve Camps

         <marvin@grn.es>
         <esteve@hades.udg.es>

   Ce texte est un extrait de ma thse sur le _support QoS dans Linux_,
   Septembre 2000.

   Documents sources :

     * Draft-almesberger-wajhak-diffserv-linux-01.txt.
     * Exemples de la distribution iproute2.
     * White Paper-QoS protocols and architectures et Foires Aux
       Questions IP QoS, les deux par _Quality of Service Forum_.
     _________________________________________________________________

14.3.1. Introduction

   Avant tout, il serait prfrable de lire les RFC crits sur ce sujet
   (RFC2474, RFC2475, RFC2597 et RFC2598) sur le site web du groupe de
   travail DiffServ IETF et sur le site web de Werner Almesberger (Il a
   crit le code permettant le support des Services Diffrencis sous
   Linux).
     _________________________________________________________________

14.3.2. A quoi DSMARK est-il reli ?

   DSMARK est un gestionnaire de mise en file d'attente qui offre les
   fonctionnalits dont ont besoin les services diffrencis
   (_Differentiated Services_) (galement appels DiffServ ou tout
   simplement DS). _DiffServ_ est l'une des deux architectures actuelles
   de la Qualit de Services (QoS : _Quality of Services_) (l'autre est
   appele _services intgrs_ (_Integrated Services_). Elle se base sur
   la valeur du champ DS contenu dans l'en-tte IP du paquet.

   Une des premires solutions dans IP pour offrir des niveaux de qualit
   de services tait le champ _Type de Service_ (octet TOS) de l'en-tte
   IP. En modifiant la valeur de ce champ, nous pouvions choisir un
   niveau lev/faible du dbit, du dlai ou de la fiabilit. Cependant,
   cela ne fournissait pas une flexibilit suffisante pour les besoins de
   nouveaux services (comme les applications temps rel, les applications
   interactives et autres). Par la suite, de nouvelles architectures sont
   apparues. L'une d'elle a t _DiffServ_ qui a gard les bits TOS et
   les a renomms champ DS.
     _________________________________________________________________

14.3.3. Guide des services diffrencis

   Les services diffrencis sont orients groupes. Cela signifie que
   nous ne savons rien des flux (ce sera le but des services intgrs
   (_integrated Services_)). Nous connaissons par contre les agrgations
   de flux et nous adopterons des comportements diffrents suivant
   l'agrgation  laquelle appartient le paquet.

   Quand un paquet arrive  un noeud frontalier (noeud d'entre du
   domaine DiffServ) et entre dans un domaine DiffServ, nous devrons
   avoir une politique, une mise en forme et/ou un marquage de ces
   paquets (le marquage fait rfrence  la mise en place d'une valeur
   dans le champ DS. Comme on le ferait pour des vaches :-)). Ce sera
   cette marque/valeur que les noeuds internes de votre domaine DiffServ
   regarderons pour dterminer quel comportement ou niveau de qualit de
   service appliquer.

   Comme vous pouvez le dduire, les Services Diffrencis impliquent un
   domaine sur lequel toutes les rgles DS devront tre appliques. Vous
   pouvez raisonner de la faon suivante : << Je classifierai tous les
   paquets entrant dans mon domaine. Une fois qu'ils seront entrs dans
   mon domaine, ils seront soumis aux rgles que ma classification impose
   et chaque noeud travers appliquera son niveau de qualit de
   service >>.

   En fait, vous pouvez appliquer vos propres politiques dans vos
   domaines locaux, mais des _autorisations au niveau service_ devront
   tre considres lors de la connexion  d'autres domaines DS.

   En ce moment, vous vous posez peut-tre beaucoup de questions.
   DiffServ est plus vaste que ce que j'ai expliqu. En fait, vous pouvez
   comprendre que je ne peux pas rsumer plus de trois RFC en 50 lignes
   :-).
     _________________________________________________________________

14.3.4. Travailler avec DSMARK

   Comme le spcifie la bibliographie concernant DiffServ, nous
   diffrencions les noeuds frontaliers et les noeuds intrieurs. Ce sont
   deux lments importants dans le chemin qu'emprunte le trafic. Les
   deux ralisent une classification quand un paquet arrive. Le rsultat
   peut tre utilis  diffrents endroits lors du processus DS avant que
   le paquet ne soit libr vers le rseau. Cela est possible car le
   nouveau code DiffServ fournit une structure appele sk_buff, incluant
   un nouveau champ appel skb->tcindex. Ce champ mmorisera le rsultat
   de la classification initiale et pourra tre utilis  plusieurs
   reprises dans le traitement DS.

   La valeur skb->tc_index sera initialement configure par le
   gestionnaire de mise en file d'attente DSMARK. Cette valeur sera
   extraite du champ DS de l'en-tte IP de tous les paquets reus. En
   outre, le classificateur cls_tcindex lira tout ou une partie de la
   valeur skb->tcindex et l'utilisera pour slectionner les classes.

   Mais, avant tout, regardons la commande _qdisc DSMARK_ et ses
   paramtres :
   ... dsmark indices INDICES [ default_index DEFAULT_INDEX ] [ set_tc_index ]

   Que signifient ces paramtres ?

     * indices : taille de la table des couples (masque,valeur). La
       valeur maximum est 2^n, o n>=0.
     * default_index : index d'entre par dfaut de la table si aucune
       correspondance n'est trouve.
     * set_tc_index : indique au gestionnaire DSMARK de rcuprer le
       champs DS et de l'enregistrer dans skb->tc_index.

   Regardons DSMARK procder.
     _________________________________________________________________

14.3.5. Comment SCH_DSMARK travaille.

   Ce gestionnaire de mise en file d'attente ralisera les tapes
   suivantes :

     * Si vous avez dclar l'option set_tc_index dans la commande
       _qdisc_, le champ DS est rcupr et mmoris dans la variable
       skb->tc_index.
     * Le classificateur est invoqu. Celui-ci sera excut et retournera
       un identificateur de classe (_class ID_) qui sera enregistr dans
       la variable skb->tc_index. Si aucun filtre correspondant n'est
       trouv, nous considrons l'option default_index comme tant
       l'identificateur de classe  enregistrer. Si, ni set_tc_index, ni
       default_index n'ont t dclars, alors les rsultats peuvent tre
       non prdictifs.
     * Aprs avoir t envoy dans le gestionnaire de file d'attente
       interne, o le rsultat du filtre peut tre rutilis,
       l'identificateur de classe retourn par le gestionnaire est stock
       dans la variable skb->tc_index. Cette valeur sera utilise plus
       tard pour indexer la table masque-valeur. Le rsultat de
       l'opration suivante sera assign au paquet :

  Nouveau_champ_DS = ( Ancien_champ_DS & masque ) | valeur


     * La nouvelle valeur rsultera donc d'un ET logique entre les
       valeurs du champ_DS et du masque, suivi d'un OU logique avec le
       paramtre valeur. Regardez la figure suivante pour comprendre tout
       ce processus :

                         skb->ihp->tos
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 - >
     |                                                       |     ^
     | -- Si vous dclarez set_tc_index, nous configurons    |     |  <-----Peu
t changer
     |    la valeur DS dans la variable skb->tc_index        |     |O       le
champ DS
     |                                                      A|     |R
   +-|-+      +------+    +---+-+  File d'attente-+     +---N|-----|----+
   | | |      |filtre|--->|   | |-->  . . .  -->| |     |   D|     |    |
   | | |----->|  tc  |--->|   | |   interne     | |---->|    v     |    |
   | | |      |index |--->| | | +---------------+ |   ---->(masque,valeur)|
-->| O |      +------+    +-|-+--------------^----+  /  |  (.  ,  .)    |
   | | |          ^         |                |       |  |  (.  ,  .)    |
   | | +----------|---------|----------------|-------|--+  (.  ,  .)    |
   | | sch_dsmark |         |                |       |                  |
   +-|------------|---------|----------------|-------|------------------+
     |            |         | <- tc_index -> |       |
     |            |(lecture)|   peut changer |       |  <--------------Index de
 la table
     |            |         |                |       |                    des c
ouples
     v            |         v                v       |                    (masq
ue,valeur)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 ->
                         skb->tc_index

   Comment faire le marquage ? Il suffit de modifier le masque et la
   valeur associs  la classe que vous voulez marquer. Regardez la ligne
   de code suivante :
   tc class change dev eth0 classid 1:1 dsmark mask 0x3 value 0xb8

   Cela modifie le couple (masque,valeur) dans la table de hachage, et
   re-marque les paquets appartenant  la classe 1:1. Vous devez
   "changer" ces valeurs en raison des valeurs par dfaut que le couple
   (masque, valeur) obtient initialement (voir le tableau ci-dessous).

   Nous allons maintenant expliquer comment le filtre TC_INDEX travaille,
   et comment il s'intgre dans tout cela. En outre, le filtre TC_INDEX
   peut tre utiliser dans des configurations autres que celles incluant
   les services DS.
     _________________________________________________________________

14.3.6. Le filtre TC_INDEX

   Voici la commande de base pour dclarer un filtre TC_INDEX :
... tcindex [ hash SIZE ] [ mask MASK ] [ shift SHIFT ]
            [ pass_on | fall_through ]
            [ classid CLASSID ] [ police POLICE_SPEC ]

   Ensuite, nous montrons l'exemple utilis pour expliquer le mode
   opratoire de TC_INDEX. Soyez attentif aux mots en gras : tc qdisc add
   dev eth0 handle 1:0 root dsmark indices 64 _set_tc_index_ tc filter
   add dev eth0 parent 1:0 protocol ip prio 1 tcindex _mask 0xfc shift 2_
   tc qdisc add dev eth0 parent 1:0 handle 2:0 cbq bandwidth 10Mbit cell
   8 avpkt 1000 mpu 64 # Classe du trafic EF tc class add dev eth0 parent
   2:0 classid 2:1 cbq bandwidth 10Mbit rate 1500Kbit avpkt 1000 prio 1
   bounded isolated allot 1514 weight 1 maxburst 10 # Gestionnaire de
   file d'attente fifo pour le trafic EF tc qdisc add dev eth0 parent 2:1
   pfifo limit 5 tc filter add dev eth0 parent 2:0 protocol ip prio 1
   _handle 0x2e_ tcindex _classid 2:1 pass_on_ (Ce code n'est pas complet.
   Ce n'est qu'un extrait de l'exemple EFCBQ inclus dans la distribution
   iproute2).

   Avant tout, supposons que nous recevons un paquet marqu comme EF. Si
   vous lisez le RFC2598, vous verrez que DSCP recommande une valeur de
   101110 pour le trafic EF. Cela signifie que le champ DS sera gal 
   10111000 (rappelez- vous que les bits les moins significatifs de
   l'octet TOS ne sont pas utiliss dans DS) ou 0xb8 en notation
   hexadcimale.

              FILTRE
              TC INDEX
   +---+      +-------+    +---+-+    +------+                +-+    +-------+
   |   |      |       |    |   | |    |FILTRE|  +-+    +-+    | |    |       |
   |   |----->| MASK  | -> |   | | -> |HANDLE|->| |    | | -> | | -> |       |
   |   |  .   | =0xfc |    |   | |    |0x2E  |  | +----+ |    | |    |       |
   |   |  .   |       |    |   | |    +------+  +--------+    | |    |       |
   |   |  .   |       |    |   | |                            | |    |       |
-->|   |  .   | SHIFT |    |   | |                            | |    |       |-
->
   |   |  .   | =2    |    |   | +----------------------------+ |    |       |
   |   |      |       |    |   |       CBQ 2:0                  |    |       |
   |   |      +-------+    +---+--------------------------------+    |       |
   |   |                                                             |       |
   |   +-------------------------------------------------------------+       |
   |                          DSMARK 1:0                                     |
   +-------------------------------------------------------------------------+

   Le paquet arrive alors avec la valeur du champ DS configure  0xb8.
   Comme je l'ai expliqu auparavant, le gestionnaire de mise en file
   d'attente dsmark, identifi par 1:0 dans cet exemple, rcupre le
   champ DS et l'enregistre dans la variable skb->tc_index. L'tape
   suivante consistera  associer un filtre  ce gestionnaire de mise en
   file d'attente (la seconde ligne dans cet exemple). Les oprations
   suivantes seront ralises :
Valeur1 = skb->tc_index & MASK
Cl = Valeur1 >> SHIFT

   Dans cet exemple, MASK=0xFC et SHIFT=2.
Valeur1 = 10111000 & 11111100 = 10111000
Cl = 10111000 >> 2 = 00101110 -> 0x2E en hexadcimal

   La valeur retourne correspondra  un identificateur de filtre du
   gestionnaire de file d'attente interne (dans l'exemple, identifier par
   2:0). Si un filtre avec cet identificateur (id) existe, les conditions
   de contrle et de performance seront vrifies (au cas o le filtre
   inclurait ceci) et l'identificateur de classe sera retourn (dans
   notre exemple, classid 2:1) et stock dans la variable skb->tc_index.

   Si aucun filtre avec cet identificateur n'est trouv, le rsultat
   dpendra de la dclaration de l'option fall_through. Si tel est le
   cas, la valeur Cl est retourne comme identificateur de classe. Si
   cela n'est pas le cas, une erreur est retourne et le traitement
   continue avec les filtres restant. Faites attention si vous utilisez
   l'option fall_through ; ceci ne peut tre fait que si une relation
   existe entre les valeurs de la variable skb->tc_index et les
   identificateurs de classe.

   Les derniers paramtres  commenter sont hash et pass_on. Le premier
   est reli  la taille de la table de hachage. Pass_on sera utilis
   pour indiquer d'essayer le filtre suivant dans le cas o aucun
   identificateur de classe gal au rsultat du filtre ne serait trouv.
   L'action par dfaut est fall_through (regarder la table suivante).

   Finalement, regardons quelles sont les valeurs possibles pour la
   configuration de tous ces paramtres TCINDEX :
Nom TC                  Valeur          Dfaut
-----------------------------------------------------------------
Hash                    1...0x10000     Dpendant de l'implmentation
Mask                    0...0xffff      0xffff
Shift                   0...15          0
Fall through / Pass_on  Flag            Fall_through
Classid                 Major:minor     Rien
Police                  .....           Rien

   Ce type de filtre est trs puissant. Il est ncessaire d'explorer
   toutes les possibilits. En outre, ce filtre n'est pas seulement
   utilis dans les configurations DiffServ. Vous pouvez l'utiliser comme
   n'importe quel autre filtre.

   Je vous recommande de regarder les exemples DiffServ inclus dans la
   distribution iproute2. Je vous promets que j'essaierai de complter ce
   texte ds que possible. Tout ce que j'ai expliqu est le rsultat de
   nombreux tests. Merci de me dire si je me suis tromp quelque part.
     _________________________________________________________________

14.4. Gestionnaire de mise en file d'attente d'entre (_Ingress qdisc_)

   Tous les gestionnaires de mise en file d'attente dont nous avons
   discut jusqu'ici sont des gestionnaires de sortie. Chaque interface
   peut galement avoir un gestionnaire de mise en file d'attente
   d'entre qui n'est pas utilis pour envoyer les paquets  l'extrieur
   du priphrique rseau. Au lieu de cela, il vous autorise  appliquer
   des filtres tc aux paquets entrants par l'interface, indpendamment de
   s'ils ont une destination locale ou s'ils sont destins  tre
   transmis.

   Etant donn que les filtres tc contiennent une implmentation complte
   du Filtre  Seau de Jetons, et qu'ils sont galement capables de
   s'appuyer sur l'estimation du flux fourni par le noyau, il y a
   beaucoup de fonctionnalits disponibles. Ceci vous permet de
   rglementer le trafic entrant de faon efficace, avant mme qu'il
   n'entre dans la pile IP.
     _________________________________________________________________

14.4.1. Paramtres & usage

   Le gestionnaire de mise en file d'attente d'entre ne ncessite pas de
   paramtres. Il diffre des autres gestionnaires dans le fait qu'il
   n'occupe pas la racine du priphrique. Attachez-le comme ceci :
   # tc qdisc add dev eth0 ingress

   Ceci vous autorise  avoir d'autres gestionnaires de sortie sur votre
   priphrique en plus du gestionnaire d'entre.

   Pour un exemple invent sur la faon dont le gestionnaire d'entre
   peut tre utilis, voir le chapitre Recettes de cuisine.
     _________________________________________________________________

14.5. _Random Early Detection_ (RED)

   Ce chapitre est conu comme une introduction au routage de dorsales
   (backbones). Ces liaisons impliquent souvent des bandes passantes
   suprieures  100 mgabits/s, ce qui ncessite une approche diffrente
   de celle de votre modem ADSL  la maison.

   Le comportement normal des files d'attente de routeurs est appel
   "tail-drop" (NdT : limine le reste). Le "tail-drop" consiste  mettre
   en file d'attente un certain volume de trafic et  liminer tout ce
   qui dborde. Ce n'est pas du tout quitable et cela conduit  des
   retransmissions de synchronisation. Quand une retransmission de
   synchronisation a lieu, la brusque rafale de rejet d'un routeur qui a
   atteint sa limite entranera une rafale de retransmissions retarde
   qui inondera  nouveau le routeur congestionn.

   Dans le but d'en finir avec les congestions occasionnelles des liens,
   les routeurs de dorsales intgrent souvent des files d'attente de
   grande taille. Malheureusement, bien que ces files d'attente offrent
   un bon dbit, elles peuvent augmenter sensiblement les temps de
   latence et entraner un comportement trs saccad des connexions TCP
   pendant la congestion.

   Ces problmes avec le "tail-drop" deviennent de plus en plus
   proccupants avec l'augmentation de l'utilisation d'applications
   hostiles au rseau. Le noyau Linux nous offre la technique RED,
   abrviation de Random Early Detect ou dtection prcoce directe.

   RED n'est pas la solution miracle  tous ces problmes. Les
   applications qui n'intgrent pas correctement la technique de
   "l'exponential backoff" obtiennent toujours une part trop grande de
   bande passante. Cependant, avec la technique RED elles ne provoquent
   pas trop de dgts sur le dbit et les temps de latence des autres
   connexions.

   RED limine statistiquement des paquets du flux avant qu'il n'atteigne
   sa limite "dure" (hard). Sur une dorsale congestionne, cela entrane
   un ralentissement en douceur de la liaison et vite les
   retransmissions de synchronisation. La technique RED aide aussi TCP 
   trouver une vitesse "quitable" plus rapidement : en permettant
   d'liminer des paquets plus tt, il conserve une file d'attente plus
   courte et des temps de latence mieux contrls. La probabilit qu'un
   paquet soit limin d'une connexion particulire est proportionnelle 
   la bande passante utilise par cette connexion plutt qu'au nombre de
   paquets qu'elle envoie.

   La technique RED est une bonne gestion de file d'attente pour les
   dorsales, o vous ne pouvez pas vous permettre le cot d'une
   mmorisation d'tat par session qui est ncessaire pour une mise en
   file d'attente vraiment quitable.

   Pour utiliser RED, vous devez rgler trois paramtres : Min, Max et
   burst. Min est la taille minimum de la file d'attente en octets avant
   que les rejets n'aient lieu, Max est le maximum "doux" (soft)
   en-dessous duquel l'algorithme s'efforcera de rester, et burst est le
   nombre maximum de paquets envoys "en rafale".

   Vous devriez configurer Min en calculant le plus grand temps de
   latence acceptable pour la mise en file d'attente, multipli par votre
   bande passante. Par exemple, sur mon lien ISDN  64 Kbits/s, je
   voudrais avoir un temps de latence de base de mise en file d'attente
   de 200 ms. Je configure donc Min  1600 octets (= 0,2 x 64000 / 8).
   Imposer une valeur Min trop petite va dgrader le dbit et une valeur
   Min trop grande va dgrader le temps de latence. Sur une liaison
   lente, choisir un coefficient Min petit ne peut pas remplacer une
   rduction du MTU pour amliorer les temps de rponse.

   Vous devriez configurer Max  au moins deux fois Min pour viter les
   synchronisations. Sur des liens lents avec de petites valeurs de Min,
   il peut tre prudent d'avoir Max quatre fois plus grand que Min ou
   plus.

   Burst contrle la rponse de l'algorithme RED aux rafales. Burst doit
   tre choisi plus grand que min/avpkt (paquet moyen).
   Exprimentalement, j'ai trouv que (min+min+max)/(3*avpkt) marche
   bien.

   De plus, vous devez configurer limit et avpkt. Limit est une valeur de
   scurit : s'il y a plus de Limit octets dans la file, RED reprend la
   technique "tail-drop". Je choisis une valeur typique gale  8 fois
   Max. Avpkt devrait tre fix  la taille moyenne d'un paquet. 1000
   fonctionne correctement sur des liaisons Internet haut dbit ayant un
   MTU de 1500 octets.

   Lire l'article sur la file d'attente RED par Sally Floyd et Van
   Jacobson pour les informations techniques.
     _________________________________________________________________

14.6. Generic Random Early Detection

   Il n'y a pas grand chose de connu sur GRED. Il ressemble  GRED avec
   plusieurs files d'attente internes, celles-ci tant choisies en se
   basant sur le champ tcindex de Diffserv. Selon une diapositive trouve
   ici, il possde les capacits _Distributed Weighted RED_ de Cisco,
   ainsi que les capacits RIO de Clark.

   Chaque file d'attente virtuelle peut avoir ses propres "Drop
   Parameters".

   FIXME: Demandez  Jamal or Werner de nous en dire plus
     _________________________________________________________________

14.7. Emulation VC/ATM

   Ceci est l'effort principal de Werner Almesberger pour vous autoriser
    construire des circuits virtuels au-dessus des sockets TCP/IP. Le
   circuit virtuel est un concept venant de la thorie des rseaux ATM.

   Pour plus d'informations, voir la page ATM sur Linux.
     _________________________________________________________________

14.8. Weighted Round Robin (WRR)

   Ce gestionnaire de mise en file d'attente n'est pas inclus dans les
   noyaux standards, mais peut tre tlcharge  partir de
   http://wipl-wrr.dkik.dk/wrr/. Ce gestionnaire de mise en file
   d'attente n'a t test qu'avec les noyaux 2.2, mais marchera
   probablement galement avec les noyaux 2.4/2.5.

   La file d'attente WRR partage la bande passante entre ses classes en
   utilisant la technique du tourniquet pondr. Ceci est similaire  la
   file d'attente CBQ qui contient des classes sur lesquelles l'on peut
   associer arbitrairement des files d'attente. Toutes les classes qui
   ont suffisamment de demandes obtiendront la bande passante
   proportionnellement au poids associ des classes. Les poidss peuvent
   tre configurs manuellement en utilisant le programme tc. Ils peuvent
   galement tre configurs pour dcrotre automatiquement pour les
   classes transfrant moins de donnes.

   La file d'attente a un classificateur intgr qui assigne les paquets
   venant ou allant vers diffrentes machines  diffrentes classes. On
   peut utiliser soit l'adresse MAC soit l'adresse IP de l'adresse source
   ou de destination. L'adresse MAC ne peut cependant tre utilise que
   quand la boite Linux est un pont ethernet. Les classes sont
   automatiquement assignes aux machines en fonction des paquets vus.

   Ce gestionnaire de mise en file d'attente peut tre trs utile au site
   comme les rsidences tudiantes o des individus sans liens
   particuliers partagent une connexion Internet. Un ensemble de scripts
   pour configurer un tel cas de figure pour ce genre de site est propos
   dans la distribution WRR.
     _________________________________________________________________

Chapitre 15. Recettes de cuisine

   Cette section contient des << recettes de cuisine >> qui peuvent vous
   aider  rsoudre vos problmes. Un livre de cuisine ne remplace
   cependant pas une relle comprhension, essayez donc d'assimiler ce
   qui suit.
     _________________________________________________________________

15.1. Faire tourner plusieurs sites avec diffrentes SLA (autorisations)

   Vous pouvez faire cela de plusieurs manires. Apache possde un module
   qui permet de le supporter, mais nous montrerons comment Linux peut le
   faire pour d'autres services. Les commandes ont t reprises d'une
   prsentation de Jamal Hadi, dont la rfrence est fournie ci-dessous.

   Disons que nous avons deux clients avec : http, ftp et du streaming
   audio. Nous voulons leur vendre une largeur de bande passante limite.
   Nous le ferons sur le serveur lui-mme.

   Le client A doit disposer d'au moins 2 mgabits, et le client B a pay
   pour 5 mgabits. Nous sparons nos clients en crant deux adresses IP
   virtuelles sur notre serveur.
# ip address add 188.177.166.1 dev eth0
# ip address add 188.177.166.2 dev eth0

   C'est  vous d'associer les diffrents serveurs  la bonne adresse IP.
   Tous les dmons courants supportent cela.

   Nous pouvons tout d'abord attacher une mise en file d'attente CBQ 
   eth0 :
# tc qdisc add dev eth0 root handle 1: cbq bandwidth 10Mbit cell 8 avpkt 1000 \
  mpu 64

   Nous crons ensuite les classes pour nos clients :
# tc class add dev eth0 parent 1:0 classid 1:1 cbq bandwidth 10Mbit rate \
  2MBit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21
# tc class add dev eth0 parent 1:0 classid 1:2 cbq bandwidth 10Mbit rate \
  5Mbit avpkt 1000 prio 5 bounded isolated allot 1514 weight 1 maxburst 21

   Nous ajoutons les filtres pour nos deux classes :
##FIXME: Pourquoi cette ligne, que fait-elle ? Qu'est-ce qu'un
diviseur ?
##FIXME: Un diviseur est li  une table de hachage et au nombre de
seaux -ahu
# tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 1: u32 divisor 1
# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.1
  flowid 1:1
# tc filter add dev eth0 parent 1:0 prio 5 u32 match ip src 188.177.166.2
  flowid 1:2

   Et voil qui est fait.

   FIXME: Pourquoi pas un filtre token bucket ? Y a t-il un retour par
   dfaut  pfifo_fast quelque part ?
     _________________________________________________________________

15.2. Protger votre machine des inondations SYN

   D'aprs la documentation iproute d'Alexey adapte  netfilter. Si vous
   utilisez ceci, prenez garde d'ajuster les nombres avec des valeurs
   raisonnables pour votre systme.

   Si vous voulez protger tout un rseau, oubliez ce script, qui est
   plus adapt  un hte seul.

   Il apparat que la toute dernire version de l'outil iproute2 est
   ncessaire pour que ceci fonctionne avec le noyau 2.4.0.
#! /bin/sh -x
#
# script simple utilisant les capacits de Ingress.
# Ce script montre comment on peut limiter le flux entrant des SYN.
# Utile pour la protection des TCP-SYN. Vous pouvez utiliser IPchains
# pour bnficier de puissantes fonctionnalits sur les SYN.
#
# chemins vers les divers utilitaires
#  changer en fonction des vtres
#
TC=/sbin/tc
IP=/sbin/ip
IPTABLES=/sbin/iptables
INDEV=eth2
#
# marque tous les paquets SYN entrant  travers $INDEV avec la valeur 1
############################################################
$iptables -A PREROUTING -i $INDEV -t mangle -p tcp --syn \
  -j MARK --set-mark 1
############################################################
#
# installe la file d'attente ingress sur l'interface associe
############################################################
$TC qdisc add dev $INDEV handle ffff: ingress
############################################################
#
# Les paquets SYN ont une taille de 40 octets (320 bits), donc trois SYN
# ont une taille de 960 bits (approximativement 1Kbit) ; nous limitons donc
# les SYNs entrants  3 par seconde (pas vraiment utile, mais sert 
# montrer ce point -JHS
############################################################
$TC filter add dev $INDEV parent ffff: protocol ip prio 50 handle 1 fw \
police rate 1kbit burst 40 mtu 9k drop flowid :1
############################################################


#
echo "---- qdisc parameters Ingress  ----------"
$TC qdisc ls dev $INDEV
echo "---- Class parameters Ingress  ----------"
$TC class ls dev $INDEV
echo "---- filter parameters Ingress ----------"
$TC filter ls dev $INDEV parent ffff:

#supprime la file d'attente ingress
#$TC qdisc del $INDEV ingress
     _________________________________________________________________

15.3. Limiter le dbit ICMP pour empcher les dnis de service

   Rcemment, les attaques distribues de dni de service sont devenues
   une nuisance importante sur Internet. En filtrant proprement et en
   limitant le dbit de votre rseau, vous pouvez  la fois viter de
   devenir victime ou source de ces attaques.

   Vous devriez filtrer vos rseaux de telle sorte que vous n'autorisiez
   pas les paquets avec une adresse IP source non-locale  quitter votre
   rseau. Cela empche les utilisateurs d'envoyer de manire anonyme des
   cochonneries sur Internet.

   La limitation de dbit peut faire encore mieux, comme vu plus haut.
   Pour vous rafrachir la mmoire, revoici notre diagramme ASCII :

[Internet] ---<E3, T3, n'importe quoi>--- [routeur Linux] --- [Bureau+FAI]
                                         eth1          eth0

   Nous allons d'abord configurer les parties pr-requises :

# tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000
# tc class add dev eth0 parent 10:0 classid 10:1 cbq bandwidth 10Mbit rate \
  10Mbit allot 1514 prio 5 maxburst 20 avpkt 1000

   Si vous avez des interfaces de 100 Mbits ou plus, ajustez ces nombres.
   Maintenant, vous devez dterminer combien de trafic ICMP vous voulez
   autoriser. Vous pouvez raliser des mesures avec tcpdump, en crivant
   les rsultats dans un fichier pendant un moment, et regarder combien
   de paquets ICMP passent par votre rseau. Ne pas oublier d'augmenter
   la longueur du "snapshot". Si la mesure n'est pas possible, vous
   pouvez consacrer par exemple 5% de votre bande passante disponible.
   Configurons notre classe :
# tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate \
  100Kbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 250 \
  bounded

   Cela limite le dbit  100 Kbits sur la classe. Maintenant, nous avons
   besoin d'un filtre pour assigner le trafic ICMP  cette classe :
# tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip
  protocol 1 0xFF flowid 10:100
     _________________________________________________________________

15.4. Donner la priorit au trafic interactif

   Si beaucoup de donnes arrivent  votre lien ou en partent, et que
   vous essayez de faire de la maintenance via telnet ou ssh, cela peut
   poser problme : d'autres paquets bloquent vos frappes clavier. Cela
   ne serait-il pas mieux si vos paquets interactifs pouvaient se
   faufiler dans le trafic de masse ? Linux peut faire cela pour vous.

   Comme prcdemment, nous avons besoin de manipuler le trafic dans les
   deux sens. Evidemment, cela marche mieux s'il y a des machines Linux
   aux deux extrmits du lien, bien que d'autres UNIX soient capables de
   faire la mme chose. Consultez votre gourou local Solaris/BSD pour
   cela.

   Le gestionnaire standard pfifo_fast a trois "bandes" diffrentes. Le
   trafic de la bande 0 est transmis en premier, le trafic des bandes 1
   et 2 tant trait aprs. Il est vital que votre trafic interactif soit
   dans la bande 0 ! Ce qui suit est adapt du (bientt obsolte)
   Ipchains-HOWTO :

   Il y a quatre bits rarement utiliss dans l'en-tte IP, appels bits
   de Type de Service (TOS). Ils affectent la manire dont les paquets
   sont traits. Les quatre bits sont "Dlai Minimum", "Dbit Maximum",
   "Fiabilit Maximum" et "Cot Minimum". Seul un de ces bits peut tre
   positionn. Rob van Nieuwkerk, l'auteur du code TOS-mangling dans
   ipchains, le configure comme suit :

Le "Dlai Minimum" est particulirement important pour moi. Je le
positionne  1 pour les paquets interactifs sur mon routeur (Linux)
qui envoie le trafic vers l'extrieur. Je suis derrire un modem 
33,6 Kbps. Linux rpartit les paquets dans trois files
d'attente. De cette manire, j'obtiens des performances acceptables
pour le trafic interactif tout en tlchargeant en mme temps.

   L'utilisation la plus commune est de configurer les connexions telnet
   et ftp  "Dlai Minimum" et les donnes FTP  "Dbit Maximum". Cela
   serait fait comme suit, sur mon routeur :

# iptables -A PREROUTING -t mangle -p tcp --sport telnet \
  -j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp \
  -j TOS --set-tos Minimize-Delay
# iptables -A PREROUTING -t mangle -p tcp --sport ftp-data \
  -j TOS --set-tos Maximize-Throughput

   En fait, cela ne marche que pour les donnes venant d'un telnet
   extrieur vers votre ordinateur local. Dans l'autre sens, a se fait
   tout seul : telnet, ssh, et consorts configurent le champ TOS
   automatiquement pour les paquets sortants.

   Si vous avez un client incapable de le faire, vous pouvez toujours le
   faire avec netfilter. Sur votre machine locale :

# iptables -A OUTPUT -t mangle -p tcp --dport telnet \
  -j TOS --set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp --dport ftp \
  -j TOS --set-tos Minimize-Delay
# iptables -A OUTPUT -t mangle -p tcp --dport ftp-data \
  -j TOS --set-tos Maximize-Throughput
     _________________________________________________________________

15.5. Cache web transparent utilisant netfilter, iproute2, ipchains et squid

   Cette section a t envoye par le lecteur Ram Narula de "Internet for
   Education" (Internet pour l'ducation) (Thailande).

   La technique habituelle pour raliser ceci dans Linux est probablement
   l'utilisation d'ipchains APRES s'tre assur que le trafic sortant du
   port 80 (web) est rout  travers le serveur faisant fonctionner
   squid.

   Il y a 3 mthodes communes pour tre sr que le trafic sortant du port
   80 est rout vers le serveur faisant fonctionner squid et une
   quatrime est introduite ici.

   La passerelle le fait.
          Si vous pouvez dire  votre passerelle que les paquets sortants
           destination du port 80 doivent tre envoys vers l'adresse IP
          du serveur squid.

          MAIS

          Ceci amnerait une charge supplmentaire sur le routeur et des
          routeurs commerciaux peuvent mme ne pas supporter ceci.

   Utiliser un commutateur Couche 4.
          Les commutateurs Couche 4 peuvent manipuler ceci sans aucun
          problme.

          MAIS

          Le cot pour un tel quipement est en gnral trs lev.
          Typiquement, un commutateur couche 4 cote normalement plus
          cher qu'un serveur classique + un bon serveur linux.

   Utiliser le serveur cache comme passerelle rseau
          Vous pouvez forcer TOUT le trafic  travers le serveur cache

          MAIS

          Ceci est plutt risqu dans la mesure o Squid utilise beaucoup
          de ressources CPU, ce qui peut conduire  une baisse des
          performances de tout le rseau. Le serveur peut galement ne
          plus fonctionner et personne sur le rseau ne pourra accder 
          Internet si cela a lieu.

   Routeur Linux+NetFilter.
          En utilisant Netfilter, une autre technique peut tre
          implmente. Celle-ci consiste  utiliser Netfilter pour
          "marquer" les paquets  destination du port 80 et  utiliser
          iproute2 pour router les paquets "marqus" vers le serveur
          Squid.

|----------------|
| Implmentation |
|----------------|

 Adresses utilises
 10.0.0.1 naret (serveur NetFilter)
 10.0.0.2 silom (serveur Squid)
 10.0.0.3 donmuang (routeur connect  Internet)
 10.0.0.4 kaosarn (un autre serveur sur le rseau)
 10.0.0.5 RAS
 10.0.0.0/24 rseau principal
 10.0.0.0/19 rseau total

|----------------|
|Schma du rseau|
|----------------|

Internet
|
donmuang
|
------------hub/commutateur----------
|        |             |       |
naret   silom        kaosarn  RAS etc.

   Premirement, faire en sorte que tout le trafic passe par naret en
   tant sr que c'est la passerelle par dfaut,  l'exception de silom.
   La passerelle par dfaut de silom doit tre donmuang (10.0.0.3) ou
   ceci crerait une boucle du trafic web.

   (Tous les serveurs sur mon rseau avaient 10.0.0.1 comme passerelle
   par dfaut qui tait l'ancienne adresse du routeur donmuang. Cela m'a
   conduit  attribuer 10.0.0.3 comme adresse IP  donmuang et  donner
   10.0.0.1 comme adresse IP  naret.)

Silom
-----
-configurer squid et ipchains

   Pour la configuration du serveur Squid sur silom, soyez sr que
   celui-ci supporte le cache/proxy transparent (transparent
   caching/proxying). Le port par dfaut pour squid est en gnral 3128.
   Tout le trafic pour le port 80 doit donc tre redirig localement vers
   le port 3128. Ceci peut tre fait en utilisant ipchains comme suit :

silom# ipchains -N allow1
silom# ipchains -A allow1 -p TCP -s 10.0.0.0/19 -d 0/0 80 -j REDIRECT 3128
silom# ipchains -I input -j allow1

   Ou, avec netfilter:
silom# iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to
-port 3128

   (note: vous pouvez avoir galement d'autres entres)

   Pour plus d'informations sur la configuration du serveur Squid, se
   rfrer  la page FAQ Squid sur http://squid.nlanr.net).

   Soyez sr que l"ip forwarding" est actif sur votre serveur et que la
   passerelle par dfaut pour ce serveur est donmuand (PAS naret).

Naret
-----
- configurer squid et ipchains
- dsactiver les messages icmp REDIRECT (si besoin)

    1. "Marquer" les paquets  destination du port 80 avec la valeur 2


naret# iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 80 \
 -j MARK --set-mark 2

    2. Configurer iproute2 de sorte qu'il route les paquets avec la
       marque 2 vers silom

naret# echo 202 www.out >> /etc/iproute2/rt_tables
naret# ip rule add fwmark 2 table www.out
naret# ip route add default via 10.0.0.2 dev eth0 table www.out
naret# ip route flush cache

       Si donmuang et naret sont sur le mme rseau, naret ne doit pas
       envoyer de messages icmp REDIRECT. Ceux-ci doivent tre dsactivs
       par :

naret# echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/default/send_redirects
naret# echo 0 > /proc/sys/net/ipv4/conf/eth0/send_redirects

   La configuration est termine, vrifions-la.

Sur naret:

naret# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
MARK       tcp  --  anywhere             anywhere           tcp dpt:www MARK se
t 0x2

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

naret# ip rule ls
0:      from all lookup local
32765:  from all fwmark        2 lookup www.out
32766:  from all lookup main
32767:  from all lookup default

naret# ip route list table www.out
default via 203.114.224.8 dev eth0

naret# ip route
10.0.0.1 dev eth0  scope link
10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
127.0.0.0/8 dev lo  scope link
default via 10.0.0.3 dev eth0

(soyez sr que silom appartiens  l'une des lignes ci-dessus. Dans ce cas,
c'est la ligne avec 10.0.0.0/24)

|------|
|-FAIT-|
|------|
     _________________________________________________________________

15.5.1. Schma du trafic aprs l'implmentation

|---------------------------------------|
|Schma du trafic aprs l'implmentation|
|---------------------------------------|

INTERNET
/\
||
\/
-----------------routeur donmuang---------------------
/\                                      /\         ||
||                                      ||         ||
||                                      \/         ||
naret                                  silom       ||
*trafic  destination du port 80=====>(cache)      ||
/\                                      ||         ||
||                                      \/         \/
\\===================================kaosarn, RAS, etc.

   Noter que le rseau est asymtrique car il y a un saut supplmentaire
   sur le chemin sortant.

Voici le cheminement d'un paquet traversant le rseau de kaosarn allant et
venant d'Internet.

Pour le trafic web/http :
requte http kaosarn->naret->silom->donmuang->Internet
rponse http de Internet->donmuang->silom->kaosarn

Pour les requtes non web/http (par ex. telnet) :
donnes sortantes kaosarn->naret->donmuang->Internet
donnes entrantes d'Internet->donmuang->kaosarn
     _________________________________________________________________

15.6. Circonvenir aux problmes de la dcouverte du MTU de chemin en
configurant un MTU par routes

   Pour envoyer de grande quantit de donnes, Internet fonctionne
   gnralement mieux quand de grands paquets sont utiliss. Chaque
   paquet implique une dcision de routage. Le transfert d'un fichier de
   1Mo peut entraner soit l'envoi de 700 paquets, en maximisant la
   taille des paquets, soit de 4000 paquets en utilisant la plus petite
   taille possible.

   Cependant, tous les lments d'Internet ne supportent pas une capacit
   utile (payload) de 1460 octets par paquet. Il est de plus ncessaire
   d'essayer de trouver le plus grand paquet qui "conviendra" le mieux,
   dans le but d'optimiser la connexion.

   Ce processus est appel "Dcouverte du MTU de chemin", o MTU signifie
   'Maximum Transfert Unit' (Unit de transfert maximum).

   Quand un routeur rencontre un paquet qui est trop gros pour tre
   envoy en un seul morceau, ET que celui-ci a t marqu avec le bit
   "Don't Fragment", il retourne un message ICMP indiquant qu'il a t
   oblig de rejeter le paquet. L'hte metteur prend acte de cette
   indication en envoyant des paquets plus petits et, par itration, peut
   trouver la taille optimum du paquet pour une connexion  travers un
   chemin particulier.

   Ceci fonctionnait correctement jusqu' ce que Internet soit dcouvert
   par des vandales qui s'efforcent de perturber les communications. Ceci
   a conduit les administrateurs , soit bloquer, soit mettre en forme le
   trafic ICMP lors d'essais malencontreux dans le but d'amliorer la
   scurit ou la robustesse de leurs services Internet.

   La consquence, maintenant, est que la dcouverte du MTU de chemin
   fonctionne de moins en moins bien, et choue pour certaines routes,
   conduisant  d'tranges sessions TCP/IP qui tombent peu de temps
   aprs.

   Bien que je n'aie pas de preuves de ceci, deux sites avec qui j'avais
   l'habitude d'avoir des problmes faisaient fonctionner  la fois
   Alteon et Acedirectors avant les systmes affects. Peut-tre
   quelqu'un avec plus de connaissances peut fournir des indices quant 
   la raison de ce qui se passe.
     _________________________________________________________________

15.6.1. Solution

   Quand vous rencontrez des sites qui prsentent ce problme, vous
   pouvez dsactiver la dcouverte du MTU de chemin en le configurant
   manuellement. Koos van den Hout a  peu prs crit :

     Le problme suivant : j'ai configur le mtu et mru de ma ligne
     ddie fonctionnant avec ppp  296 dans la mesure o le dbit est
     de seulement 33k6 et que je ne peux pas influencer la file
     d'attente de l'autre ct. A 296, la rponse  l'appui d'une touche
     intervient dans un dlai raisonnable.

     Et, de mon ct, j'ai un routeur avec translation d'adresse
     (masquage) fonctionnant (bien sr) sous Linux.

     Rcemment, j'ai spar le serveur du routeur de sorte que la
     plupart des applications fonctionnent sur une machine diffrente de
     celle qui ralise le routage.

     J'ai alors eu des problmes en me connectant sur l'irc. Grosse
     panique ! Je vous assure que certains essais trouvaient que j'tais
     connect  l'irc, me montrant mme comme connect sur l'irc mais je
     ne recevais pas le "motd" (message of the day, message du jour) de
     l'irc. J'ai vrifi ce qui pouvait tre erron et ai not que
     j'avais dj eu des soucis lis au MTU en contactant certains sites
     web. Je n'avais aucun souci pour les atteindre quand le MTU tait 
     1500, le problme n'apparaissant que lorsque le MTU tait configur
      296. Puisque les serveurs irc bloquent tout le trafic dont il
     n'ont pas besoin pour leurs oprations immdiates, ils bloquent
     aussi l'icmp.

     J'ai manoeuvr pour convaincre les responsables d'un serveur web
     que ceci tait la cause d'un problme, mais les responsables du
     serveur irc n'avaient pas l'intention de rparer ceci.

     Donc, je devais tre sr que le trafic masqu sortant partait avec
     le mtu faible du lien externe. Mais, je voulais que le trafic
     ethernet local ait le MTU normal (pour des choses comme le trafic
     nfs).

     Solution :

     ip route add default via 10.0.0.1 mtu 296

     (10.0.0.1 tant ma passerelle par dfaut, l'adresse interne de mon
     routeur masquant)

   En gnral, il est possible d'outrepasser la dcouverte du MTU de
   chemin en configurant des routes spcifiques. Par exemple, si seuls
   certains rseaux posent problmes, ceci devrait aider :
   ip route add 195.96.96.0/24 via 10.0.0.1 mtu 1000
     _________________________________________________________________

15.7. Circonvenir aux problmes de la dcouverte du MTU de chemin en
imposant le MSS (pour les utilisateurs de l'ADSL, du cble, de PPPoE & PPtP)

   Comme expliqu au-dessus, la dcouverte du MTU de chemin ne marche pas
   aussi bien que cela devrait tre. Si vous savez qu'un saut de votre
   rseau a un MTU limit (<1500), vous ne pouvez pas compter sur la
   dcouverte du MTU de chemin pour le dcouvrir.

   Outre le MTU, il y a encore un autre moyen de configurer la taille
   maximum du paquet, par ce qui est appel le MSS (Maximum Segment Size,
   Taille Maximum du Segment). C'est un champ dans les options TCP du
   paquet SYN.

   Les noyaux Linux rcents, et quelques pilotes de priphrique pppoe
   (notamment, l'excellent Roaring Penguin) implmente la possibilit de
   'fixer le MSS'.

   Le bon ct de tout ceci est que, en positionnant la valeur MSS, vous
   dtes  l'hte distant de manire quivoque "n'essaie pas de m'envoyer
   des paquets plus grands que cette valeur". Aucun trafic ICMP n'est
   ncessaire pour faire fonctionner cela.

   Malheureusement, c'est de la bidouille vidente -- a dtruit la
   proprit bout-en-bout de la connexion en modifiant les paquets.
   Ayant dit cela, nous utilisons cette astuce dans beaucoup d'endroit et
   cela fonctionne comme un charme.

   Pour que tout ceci fonctionne, vous aurez besoin au moins de
   iptables-1.2.1a et de Linux 2.4.3 ou plus. La ligne de commande
   basique est :
# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-
pmtu

   Ceci calcule le MSS appropri pour votre lien. Si vous vous sentez
   courageux ou que vous pensez tre le mieux plac pour juger, vous
   pouvez aussi faire quelque chose comme ceci :

   # iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 128

   Ceci configure le MSS du paquet SYN  128. Utilisez ceci si vous avez
   de la voix sur IP (VoIP) avec de tous petits paquets, et de grands
   paquets http qui provoquent des coupures dans vos communications
   vocales.
     _________________________________________________________________

15.8. Le Conditionneur de Trafic Ultime : Faible temps de latence,
Tlchargement vers l'amont et l'aval rapide

   Note : Ce script a rcemment t mis  niveau et il ne marchait avant
   qu'avec les clients Linux de votre rseau ! Vous devriez donc le
   mettre  jour si vous avez des machines Windows ou des Macs dans votre
   rseau qui n'taient pas capables de tlcharger plus rapidement
   pendant que d'autres taient en train de tlcharger vers l'amont.

   J'ai essay de crer le Saint Graal :

   Maintenir  tout moment un faible temps de latence pour le trafic
          interactif
          Ceci signifie que la rcupration ou la transmission de
          fichiers ne doivent pas perturber SSH ou mme telnet. Ceci est
          la chose la plus importante, car mme un temps de latence de
          200ms est important pour pouvoir travailler confortablement.

   Autoriser le 'surf'  des vitesses raisonnables pendant que l'on
          tlcharge vers l'amont ou vers l'aval
          Mme si http est un trafic de masse, les autres trafics ne
          doivent pas trop le noyer.

   Etre sr que le tlchargement vers l'amont ne va pas faire du tort
          aux tlchargements vers l'aval et aux autres lments autour
          Le principal phnomne observ est la forte rduction de la
          vitesse de tlchargement vers l'aval quand il y a du trafic
          montant.

   Il s'avre que tout ceci est possible, au prix d'une minuscule
   rduction de la bande passante. La prsence de grandes files d'attente
   sur les dispositifs d'accs domestiques, comme le cble ou les modems
   DSL, explique pourquoi les tlchargements vers l'amont, vers l'aval
   et ssh se pnalisent mutuellement.

   La prochaine partie explique en profondeur ce qui provoque les
   retards, et comment nous pouvons les corriger. Vous pouvez sans danger
   la passer et aller directement au script si vous vous fichez de la
   faon dont la magie opre.
     _________________________________________________________________

15.8.1. Pourquoi cela ne marche t-il pas bien par dfaut ?

   Les FAI savent que leurs performances ne sont seulement juges que sur
   la vitesse  laquelle les personnes peuvent tlcharger vers l'aval.
   En plus de la bande passante disponible, la vitesse de tlchargement
   est lourdement influence par la perte des paquets, qui gne
   srieusement les performances de TCP/IP. Les grandes files d'attente
   peuvent aider  prvenir la perte des paquets, et augmenter les
   tlchargements. Les FAI configurent donc de grandes files d'attente.

   Ces grandes files d'attente endommagent cependant l'interactivit. Une
   frappe doit d'abord parcourir la file d'attente du flux montant, ce
   qui peut prendre plusieurs secondes, et aller jusqu'au hte distant.
   Elle est alors traite, conduisant  un paquet de retour qui doit
   traverser la file d'attente du flux descendant, localise chez votre
   FAI, avant qu'elle n'apparaisse sur l'cran.

   Cet HOWTO nous enseigne plusieurs manires pour modifier et traiter la
   file d'attente mais, malheureusement, toutes les files d'attente ne
   nous sont pas accessibles. Les files d'attente du FAI sont sans
   limites et la file d'attente du flux montant rside probablement dans
   votre modem cble ou votre priphrique DSL. Il se peut que vous
   soyiez capable ou non de le configurer. La plupart du temps, ce ne
   sera pas le cas.

   Et aprs ? Etant donn que nous ne pouvons pas contrler ces files
   d'attente, elles doivent disparatre et tre transfres sur notre
   routeur Linux. Heureusement, ceci est possible.

   Limiter la vitesse de tlchargement vers l'amont (upload)
          En limitant notre vitesse de tlchargement vers l'amont  une
          vitesse lgrement plus faible que la vitesse relle
          disponible, il n'y a pas de files d'attente mises en place dans
          notre modem. La file d'attente est maintenant transfre vers
          Linux.

   Limiter la vitesse de tlchargement vers l'aval (download)
          Ceci est lgrement plus rus dans la mesure o nous ne pouvons
          pas vraiment influencer la vitesse  laquelle Internet nous
          envoie les donnes. Nous pouvons cependant rejetter les paquets
          qui arrivent trop vite, ce qui provoque le ralentissement de
          TCP/IP jusqu'au dbit dsir. Parceque que nous ne voulons pas
          supprimer inutilement du trafic, nous configurons une vitesse
          de rafale ('burst') plus grande.

   Maintenant que nous avons fait ceci, nous avons limin totalement la
   file d'attente du flux descendant (sauf pour de courtes rafales de
   donnes), et obtenu la possibilit de grer la file d'attente du flux
   montant avec toute la puissance Linux.

   Il nous reste  nous assurer que le trafic interactif se retrouve au
   dbut de la file d'attente du flux montant. Pour tre sr que le flux
   montant ne va pas pnaliser le flux descendant, nous dplaons
   galement les paquets ACK au dbut de la file d'attente. C'est ce qui
   provoque normalement un norme ralentissement quand du trafic de masse
   est gnr dans les deux sens. Les paquets ACK du trafic descendant
   rentrent en concurrence avec le trafic montant et sont donc ralentis.

   Si nous avons fait tout ceci, nous obtenons les mesures suivantes en
   utilisant l'excellente connexion ADSL de xs4all, en Hollande :

Temps de latence de base :
round-trip min/avg/max = 14.4/17.1/21.7 ms

Sans le conditionneur de trafic, lors d'un tlechargement vers l'aval :
round-trip min/avg/max = 560.9/573.6/586.4 ms

Sans le conditionneur de trafic, lors d'un tlechargement vers l'amont :
round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

Avec le conditionneur, lors d'un tlechargement vers l'amont  220kbit/s :
round-trip min/avg/max = 15.7/51.8/79.9 ms

Avec le conditionneur, lors d'un tlechargement vers l'aval  850kbit/s :
round-trip min/avg/max = 20.4/46.9/74.0 ms

Lors d'un tlchargement vers l'amont, les tlchargements vers l'aval s'effect
uent  environ
80 % de la vitesse maximale disponible et 90% pour les tlchargements vers
l'amont. Le temps de latence augmente alors jusqu' 850 ms ; je n'ai pas encore
dtermin la raison de ce phnomne.

   Ce que vous pouvez attendre de ce script dpend largement de votre
   vitesse de lien relle. Quand vous tlchargez vers l'amont  pleine
   vitesse, il y aura toujours un paquet devant votre frappe de clavier.
   Ceci est la limite basse de votre temps de latence. Pour la calculer,
   divisez votre MTU par la vitesse du flux montant. Les valeurs
   classiques seront un peu plus leves que ca. Diminuez votre MTU pour
   un meilleur effet !

   Voici deux versions de ce script, une avec l'excellent HTB de Devik,
   et l'autre avec CBQ qui est prsent dans chaque noyau Linux,
   contrairement  HTB. Les deux ont t tests et marchent correctement.
     _________________________________________________________________

15.8.2. Le script (CBQ)

   Marche avec tous les noyaux. A l'intrieur du gestionnaire de mise en
   file d'attente CBQ, nous plaons deux SFQ pour tre sr que de
   multiples flux de masse ne vont pas mutuellement se pnaliser.

   Le trafic descendant est rglement en utilisant un filtre tc
   contenant un Token Bucket Filter.

   Vous pourriez amliorer ce script en ajoutant 'bounded' aux lignes qui
   dmarrent avec 'tc class add .. classid 1:20'. Si vous avez diminu
   votre MTU, diminuez aussi les nombres allot & avpkt !

#!/bin/bash

# La configuration ultime pour votre connexion Internet domestique
#
# Configurez les valeurs suivantes avec des valeurs lgrement infrieures que
# vos vitesses de flux montant et descendant. Exprim en kilobits.
DOWNLINK=800
UPLINK=220
DEV=ppp0

# Nettoie les gestionnaires de sortie et d'entrs, cache les erreurs
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### Flux montant (uplink)

# installe CBQ  la racine

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit

# Le trafic est mis en forme  une vitesse de $UPLINK. Ceci vite
# d'normes files d'attente dans votre modem DSL qui pnalisent le temps de
# latence.
# Classe principale

tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
allot 1500 prio 5 bounded isolated

# classe de priorit suprieure 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
   allot 1600 prio 1 avpkt 1000

# la classe par dfaut et pour le trafic de masse 1:20. Reoit lgrement
# moins que le trafic et a une priorit plus faible :
# bulk and default class 1:20 - gets slightly less traffic,
#  and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
   allot 1600 prio 2 avpkt 1000

# Les deux sont gres par SFQ :
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# Dmarrage des filtres
# le bit Dlai Minimum du champ TOS (ssh, PAS scp) est dirig vers
# 1:10 :
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10
# ICMP (ip protocol 1) est dirig vers la classe interactive 1:10 de telle
# sorte que nous pouvons raliser des mesures et impressionner nos
# amis :
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
        match ip protocol 1 0xff flowid 1:10

# Pour acclrer les tlchargements vers l'aval lors de la prsence d'un
# flux montant, les paquets ACK sont placs dans la classe
# interactive :

tc filter add dev $DEV parent 1: protocol ip prio 12 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# Le reste est considr 'non-interactif' cad 'de masse' et fini dans 1:20

tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
   match ip dst 0.0.0.0/0 flowid 1:20

########## Flux descendant (downlink) #############
# Ralentir le flux descendant  une valeur lgrement plus faible que votre
# vitesse rlle de manire  viter la mise en file d'attente chez notre
# FAI. Faites des tests pour voir la vitesse maximum  laquelle vous pouvez
# le configurer. Les FAI ont tendance  avoir *d'normes* files d'attente
# pour s'assurer de la rapidit des gros tlchargements.
#
# attache la rglementation d'entre (ingress policer) :

tc qdisc add dev $DEV handle ffff: ingress

# Filtre *tout* (0.0.0.0/0), rejette tout ce qui arrive trop
# rapidement :

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

   Si vous voulez que ce script soit excut par ppp  la connexion,
   copiez-le dans /etc/ppp/ip-up.d.

   Si les deux dernires lignes conduisent  une erreur, mettez  jour
   l'outil tc avec la dernire version !
     _________________________________________________________________

15.8.3. Le script (HTB)

   Le script suivant nous permet d'atteindre tous nos buts en utilisant
   la merveilleuse file d'attente HTB. Voir le chapitre correspondant.
   Cela vaut la peine de mettre  jour votre noyau !
#!/bin/bash

# La configuration ultime pour votre connexion Internet domestique
#
# Configurez les valeurs suivantes avec des valeurs lgrement infrieures que
# vos vitesses de flux montant et descendant. Exprim en kilobits.
DOWNLINK=800
UPLINK=220
DEV=ppp0

#Nettoie les gestionnaires de sortie et d'entrs, cache les erreurs
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

###### Flux montant (uplink)

# installe HTB  la racine, le trafic ira par dfaut vers 1:20 :

tc qdisc add dev $DEV root handle 1: htb default 20

# Le trafic est mis en forme  une vitesse de $UPLINK. Ceci vite
# d'normes files d'attente dans votre modem DSL qui pnalisent le temps de
# latence.

tc class add dev $DEV parent 1: classid 1:1 htb rate ${UPLINK}kbit burst 6k

# la classe de haute priorit 1:10 :

tc class add dev $DEV parent 1:1 classid 1:10 htb rate ${UPLINK}kbit \
   burst 6k prio 1

# bulk & default class 1:20 - gets slightly less traffic,
# and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 htb rate $[9*$UPLINK/10]kbit \
   burst 6k prio 2

# Les deux sont gres par SFQ :
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# le bit Dlai Minimum du champ TOS (ssh, PAS scp) est dirig vers
# 1:10 :
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid 1:10

# ICMP (ip protocol 1) est dirig vers la classe interactive 1:10 de telle
# sorte que nous pouvons raliser des mesures et impressionner nos
# amis :
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
        match ip protocol 1 0xff flowid 1:10

# Pour acclrer les tlchargements vers l'aval lors de la prsence d'un
# flux montant, les paquets ACK sont placs dans la classe
# interactive :

tc filter add dev $DEV parent 1: protocol ip prio 10 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# Le reste est considr 'non-interactif' cad 'de masse' et fini dans 1:20


########## Flux descendant (downlink) #############
# Ralentir le flux descendant  une valeur lgrement plus faible que votre
# vitesse rlle de manire  viter la mise en file d'attente chez notre
# FAI. Faites des tests pour voir la vitesse maximum  laquelle vous pouvez
# le configurer. Les FAI ont tendance  avoir *d'normes* files d'attente
# pour s'assurer de la rapidit des gros tlchargements.
#
# attache la rglementation d'entre (ingress policer) :

tc qdisc add dev $DEV handle ffff: ingress

# Filtre *tout* (0.0.0.0/0), rejette tout ce qui arrive trop
# rapidement :

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1

   Si vous voulez que ce script soit excut par ppp  la connexion,
   copiez-le dans /etc/ppp/ip-up.d.

   Si les deux dernires lignes conduisent  une erreur, mettez  jour
   l'outil tc avec la dernire version !
     _________________________________________________________________

Chapitre 16. Construire des ponts et des pseudo-ponts avec du Proxy ARP

   Les ponts sont des priphriques qui peuvent tre installs dans un
   rseau sans aucune reconfiguration. Un commutateur rseau est
   basiquement un pont multi-ports. Un pont est souvent un commutateur
   avec 2 ports. Cependant, Linux supporte trs bien plusieurs interfaces
   dans un pont, le conduisant  fonctionner comme un vrai commutateur.

   Les ponts sont souvent dploys quand on est confront  un rseau
   dfaillant qui a besoin d'tre rpar sans aucune modification. Dans
   la mesure o un pont est un quipement de niveau 2, la couche sous la
   couche IP, les routeurs et serveurs ne sont pas conscients de son
   existence. Ceci signifie que vous pouvez bloquer ou modifier certains
   paquets de manire transparente ou mettre en forme le trafic.

   Un autre lment positif est qu'un pont peut souvent tre remplac par
   un cble crois ou un hub quand il tombe en panne.

   L'aspect ngatif est que la mise en place d'un pont peut engendrer
   beaucoup de confusion,  moins qu'il ne soit trs bien configur. Le
   pont n'apparat pas dans les traceroute, mais pourtant des paquets
   disparaissent sans raison ou sont changs en allant d'un point A  un
   point B. Vous devriez galement vous demander si une organisation qui
   "ne veut rien changer" fait le bon choix.

   Le _pont Linux 2.4_ est document sur cette page.
     _________________________________________________________________

16.1. Etat des ponts et iptables

   Au moment de Linux 2.4.14, le pont et iptables ne se "voient" pas l'un
   l'autre sans une aide. Si vous "pontez" les paquets de eth0  eth1,
   ils ne "passent" pas par iptables. Ceci signifie que vous ne pouvez
   pas faire de filtrage, de translation d'adresse (NAT), de dessossage
   ou quoique ce soit d'autres.

   Il y a plusieurs projets continuant de corriger ceci, le meilleur
   tant celui de l'auteur du code du pont Linux 2.4, Lennert Buytenhek.
   il nous a rcemment inform qu' partir de bridge-nf 0.0.2 (voir l'url
   ci-dessus), le code est stable et utilisable dans un environnement de
   production. Il demande maintenant aux responsables du noyau si et
   comment la mise  jour peut tre ajoute. Rester branch !

   Nous comptons que ce problme soit bientt rsolu.
     _________________________________________________________________

16.2. Pont et mise en forme

   Ca marche comme dans les rclames. Soyez sr du ct attribu  chaque
   interface. Autrement, il se peut que vous mettiez en forme le trafic
   sortant au niveau de votre interface interne, ce qui ne marchera pas.
   Utilisez tcpdump si ncessaire.
     _________________________________________________________________

16.3. Pseudo-pont avec du Proxy-ARP

   Si vous voulez juste implmenter un pseudo-pont, allez jusqu' la
   section "Implmentez-le". Cependant, il est sage de lire un peu la
   faon dont il fonctionne en pratique.

   Un pseudo-pont travaille de manire un peu diffrente. Par dfaut, un
   pont transmet les paquets sans les altrer d'une interface  une
   autre. Il ne regarde que l'adresse matrielle des paquets pour
   dterminer o ils doivent aller. Ceci signifie que vous pouvez
   "pontez" un trafic que Linux ne comprend pas, aussi longtemps qu'il y
   a une adresse matrielle.

   Un "pseudo-pont" travaille diffremment et ressemble plus  un routeur
   cach qu' un pont. Mais, comme un pont, il a un impact faible sur
   l'architecture du rseau.

   Le fait qu'il ne soit pas un pont prsente l'avantage que les paquets
   traversent rellement le noyau, et peuvent tre filtrs, modifis,
   redirigs ou rerouts.

   Un pont rel peut galement raliser ces tours de force, mais il a
   besoin d'un code spcial, comme le Ethernet Frame Diverter ou la mise
    jour mentionne au-dessus.

   Un autre avantage d'un pseudo-pont est qu'il ne transmet pas les
   paquets qu'il ne comprend pas, nettoyant ainsi votre rseau de
   beaucoup de cochonneries. Dans le cas o vous auriez besoin de ces
   cochonneries (comme les paquets SAP ou Netbeui), utilisez un vrai
   pont.
     _________________________________________________________________

16.3.1. ARP & Proxy-ARP

   Quand un hte veut dialoguer avec un autre hte sur le mme segment
   physique, il envoie un paquet du Protocole de Rsolution d'Adresse
   (ARP) qui, en simplifiant quelque peu, est lu comme ceci : "Qui a
   10.0.0.1, le dire  10.0.0.7". En rponse  ceci, 10.0.0.1 renvoie un
   petit paquet "ici".

   10.0.0.7 envoie alors des paquets  l'adresse matrielle mentionne
   dans le paquet "ici". Il met dans un cache cette adresse matrielle
   pour un temps relativement long et, aprs l'expiration du cache,
   repose sa question.

   Quand on construit un pseudo-pont, on configure le pont pour qu'il
   rponde  ces paquets ARP, les htes du rseau envoyant alors leurs
   paquets au pont. Le pont traite alors ces paquets et les envoie 
   l'interface adapte.

   Donc, en rsum, quand un hte d'un ct du pont demande l'adresse
   matrielle d'un hte se situant de l'autre ct, le pont rpond avec
   un paquet qui dit "transmets le moi".

   De cette faon, tout le trafic de donnes est transmis  la bonne
   place et il traverse toujours le pont.
     _________________________________________________________________

16.3.2. Implmentez-le

   Les versions anciennes du noyau linux permettait de faire du proxy ARP
   uniquement  une granularit sous rseaux. Ainsi, pour configurer un
   pseudo-pont, il fallait spcifier les bonnes routes vers les deux
   cts du pont, et galement crer les rgles proxy-ARP
   correspondantes. C'tait pnible, dj par la quantit de texte qu'il
   fallait taper, puis parce qu'il tait facile de se tromper et crer
   des configurations errones, o le pont rpondait  des requtes pour
   des rseaux qu'il ne savait pas router.

   Avec Linux 2.4 (et peut-tre bien le 2.2), cette possibilit a t
   retire et a t remplace par une option dans le rpertoire /proc,
   appele "proxy-arp". La procdure pour construire un pseudo-pont est
   maintenant :

    1. Assigner une adresse  chaque interface, la "gauche" et la
       "droite"
    2. Crer des routes pour que votre machine connaisse quels htes
       rsident  gauche et quels htes rsident  droite
    3. Activer le proxy-ARP sur chaque interface echo 1 >
       /proc/sys/net/ipv4/conf/ethL/proxy_arp echo 1 >
       /proc/sys/net/ipv4/conf/ethR/proxy_arp o L et R dsignent les
       numros de l'interface du ct gauche (Left) et de celle du ct
       droit (Right)

   N'oubliez pas galement d'activer l'option ip_forwarding ! Quand on
   convertit un vrai pont, il se peut que vous trouviez cette option
   dsactive dans la mesure o il n'y en a pas besoin pour un pont.

   Une autre chose que vous devriez considrer lors de la conversion est
   que vous aurez besoin d'effacer le cache arp des ordinateurs du
   rseau. Le cache arp peut contenir d'anciennes adresses matrielles du
   pont qui ne sont plus correctes.

   Sur un Cisco, ceci est ralis en utilisant la commande 'clear
   arp-cache' et, sous linux, en utilisant 'arp -d ip.adresse'. Vous
   pouvez aussi attendre l'expiration manuelle du cache, ce qui peut tre
   plutt long.

   Il se peut que vous dcouvriez galement que votre rseau tait mal
   configur si vous avez/aviez l'habitude de spcifier les routes sans
   les masques de sous-rseau. Dans le pass, certaines versions de
   _route_ pouvaient correctement deviner le masque ou, au contraire, se
   tromper sans pour autant vous le notifier. Quand vous faites du
   routage chirurgical comme dcrit plus haut, il est *vital* que vous
   vrifiez vos masques de sous-rseau.
     _________________________________________________________________

Chapitre 17. Routage Dynamique - OSPF et BGP

   Si votre rseau commence  devenir vraiment gros ou si vous commencez
    considrer Internet comme votre propre rseau, vous avez besoin
   d'outils qui routent dynamiquement vos donnes. Les sites sont souvent
   relis entre eux par de multiples liens, et de nouveaux liens
   surgissent en permanence.

   L'Internet utilise la plupart du temps les standards OSPF et BGP4
   (rfc1771). Linux supporte les deux, par le biais de gated et zebra.

   Ce sujet est pour le moment hors du propos de ce document, mais
   laissez-nous vous diriger vers des travaux de rfrence :

   Vue d'ensemble :

   Cisco Systems Cisco Systems Designing large-scale IP Internetworks

   Pour OSPF :

   Moy, John T. "OSPF. The anatomy of an Internet routing protocol"
   Addison Wesley. Reading, MA. 1998.

   Halabi a aussi crit un trs bon guide sur la conception du routage
   OSPF, mais il semble avoir t effac du site Web de Cisco.

   Pour BGP :

   Halabi, Bassam "Internet routing architectures" Cisco Press (New
   Riders Publishing). Indianapolis, IN. 1997.

   Il existe aussi

   Cisco Systems

   Using the Border Gateway Protocol for Interdomain Routing

   Bien que les exemples soient spcifiques  Cisco, ils sont
   remarquablement semblables au langage de configuration de Zebra :-)
     _________________________________________________________________

Chapitre 18. Autres possibilits

   Ce chapitre est une liste des projets ayant une relation avec le
   routage avanc et la mise en forme du trafic sous Linux. Certains de
   ces liens mriteraient des chapitres spcifiques, d'autres sont trs
   bien documents, et n'ont pas besoin de HOWTO en plus.

   Implmentation VLAN 802.1Q pour Linux (site)
          VLAN est une faon trs sympa de diviser vos rseaux d'une
          manire plus virtuelle que physique. De bonnes informations sur
          les VLAN pourront tre trouves ici. Avec cette implmentation,
          votre boite Linux pourra dialoguer VLAN avec des machines comme
          les Cisco Catalyst, 3Com: {Corebuilder, Netbuilder II,
          SuperStack II switch 630}, Extreme Ntwks Summit 48, Foundry:
          {ServerIronXL, FastIron}.

   Implmentation alternative VLAN 802.1Q pour Linux(site)
          Une implmentation alternative de VLAN pour Linux. Ce projet a
          dmarr suite au dsaccord avec l'architecture et le style de
          codage du projet VLAN 'tabli', avec comme rsultat une
          structure de l'ensemble plus clair. Mise  jour : a t inclus
          dans le noyau 2.4.14 (peut-tre dans le 2.4.13).

          Un bon HOWTO  propos des VLAN peut tre trouv ici.

          Mise  jour : a t inclus dans le noyau  partir de la version
          2.4.14 (peut-tre 13).

   Serveur Linux Virtuel (Linux Virtual Server )(site)
          Ces personnes sont trs talentueuses. Le Serveur Virtuel Linux
          est un serveur  haute disponibilit, hautement volutif,
          construit autour d'une grappe (cluster) de serveurs, avec un
          quilibreur de charge tournant sur le systme d'exploitation
          Linux. L'architecture du cluster est transparente pour les
          utilisateurs finaux, qui ne voient qu'un simple serveur
          virtuel.

          En rsum, que vous ayez besoin d'quilibrer votre charge ou de
          contrler votre trafic, LVS aura une manire de le faire.
          Certaines de leurs techniques sont positivement diaboliques !.
          Par exemple, ils permettent  plusieurs machines d'avoir une
          mme adresse IP, mais en dsactivant l'ARP dessus. Seule la
          machine LVS qui a, elle, l'ARP actif, dcide de l'hte qui
          manipulera le paquet entrant. Celui-ci est envoy avec la bonne
          adresse MAC au serveur choisi. Le trafic sortant passe
          directement par le routeur, et non par la machine LVS, qui, par
          consquent n'a pas besoin de voir vos 5Gbit/s de donnes allant
          sur Internet. Cette machine LVS ne peut alors pas tre un
          goulot d'tranglement.

          L'implmentation de LVS ncessite une mise  jour pour les
          noyaux 2.0 et 2.2, alors qu'un module Netfilter est disponible
          dans le 2.4. Il n'y a donc pas besoin de mise  jour pour cette
          version du noyau. Le support 2.4 est encore en dveloppement.
          Battez-vous donc avec et envoyez vos commentaires ou vos mises
           jour.

   CBQ.init (site)
          Configurer CBQ peut tre un peu intimidant, spcialement si
          votre seul souhait est de mettre en forme le trafic
          d'ordinateurs placs derrire un routeur. CBQ.init peut vous
          aider  configurer Linux  l'aide d'une syntaxe simplifie.

          Par exemple, si vous voulez que tous les ordinateurs de votre
          rseau 192.168.1.0/24 (sur eth1 10 Mbits) aient leur vitesse de
          tlchargement limite  28 Kbits, remplissez le fichier de
          configuration de CBQ.init avec ce qui suit :

DEVICE=eth1,10Mbit,1Mbit
RATE=28Kbit
WEIGHT=2Kbit
PRIO=5
RULE=192.168.1.0/24

          Utiliser simplement ce programme si le 'comment et pourquoi' ne
          vous intresse pas. Nous utilisons CBQ.init en production et il
          marche trs bien. On peut mme faire des choses plus avances,
          comme la mise en forme dpendant du temps. La documentation est
          directement intgre dans le script, ce qui explique l'absence
          d'un fichier README.

   Scripts faciles de mise en forme Chronox(site)
          Stephan Mueller (smueller@chronox.de) a crit deux scripts
          utiles, "limit.conn" et "shaper". Le premier vous permet de
          matriser une session de tlchargement, comme ceci :

# limit.conn -s SERVERIP -p SERVERPORT -l LIMIT

          Il fonctionne avec Linux 2.2 et 2.4.

          Le second script est plus compliqu et peut tre utilis pour
          mettre en place des files d'attente diffrentes bases sur les
          rgles iptables. Celles-ci sont utilises pour marquer les
          paquets qui sont alors mis en forme.

   Implmentation du Protocole Redondant Routeur Virtuel (site)
          Ceci est purement pour la redondance. Deux machines avec leurs
          propres adresses IP et MAC crent une troisime adresse IP et
          MAC virtuelle. Bien que destin  l'origine uniquement aux
          routeurs, qui ont besoin d'adresses MAC constantes, cela marche
          galement pour les autres serveurs.

          La beaut de cette approche est l'incroyable facilit de la
          configuration. Pas de compilation de noyau ou de ncessit de
          mise  jour, tout se passe dans l'espace utilisateur.

          Lancer simplement ceci sur toutes les machines participant au
          service :

# vrrpd -i eth0 -v 50 10.0.0.22

          Et vous voil oprationnel ! 10.0.0.22 est maintenant gr par
          l'un de vos serveurs, probablement le premier  avoir lanc le
          dmon vrrp. Dconnectez maintenant cet ordinateur du rseau et
          trs rapidement, l'adresse 10.0.0.22 et l'adresse MAC seront
          gres par l'un des autres ordinateurs.

          J'ai essay ceci et il a t actif et oprationnel en 1 minute.
          Pour une raison trange, ma passerelle par dfaut a t
          supprime. Cependant, l'option -n permet de prvenir cela.

          Voici une dfaillance en "direct" :

64 bytes from 10.0.0.22: icmp_seq=3 ttl=255 time=0.2 ms
64 bytes from 10.0.0.22: icmp_seq=4 ttl=255 time=0.2 ms
64 bytes from 10.0.0.22: icmp_seq=5 ttl=255 time=16.8 ms
64 bytes from 10.0.0.22: icmp_seq=6 ttl=255 time=1.8 ms
64 bytes from 10.0.0.22: icmp_seq=7 ttl=255 time=1.7 ms

          Pas *un* paquet ping n'a t perdu ! Aprs 4 paquets, j'ai
          dconnect mon P200 du rseau, et mon 486 a pris le relais, ce
          qui est visible par l'augmentation du temps de latence.
     _________________________________________________________________

Chapitre 19. Lectures supplmentaires

   http://snafu.freedom.org/linux2.2/iproute-notes.html
          Contient beaucoup d'informations techniques, et de commentaires
          sur le noyau.

   http://www.davin.ottawa.on.ca/ols/
          Transparents de Jamal Hadi Salim, un des auteurs du contrleur
          de trafic de Linux.

   http://defiant.coinet.com/iproute2/ip-cref/
          Version HTML de la documentation LaTeX d'Alexeys ; explique une
          partie d'iproute2 en dtails.

   http://www.aciri.org/floyd/cbq.html
          Sally Floyd a une bonne page sur CBQ, incluant ses publications
          originales. Aucune n'est spcifique  Linux, mais il y a un
          travail de discussion sur la thorie et l'utilisation de CBQ.
          Contenu trs technique, mais une bonne lecture pour ceux qui
          sont intresss.

   Differentiated Services on Linux
          This document par Werner Almesberger, Jamal Hadi Salim et
          Alexey Kuznetsov. Dcrit les fonctions DiffServ du noyau Linux,
          entre autres les gestionnaires de mise en file d'attente TBF,
          GRED, DSMARK et le classificateur tcindex.

   http://ceti.pl/~ekravietz/cbq/NET4_tc.html
          Un autre HOWTO, en polonais ! Vous pouvez cependant
          copier/coller les lignes de commandes, elles fonctionnent de la
          mme faon dans toutes les langues. L'auteur travaille en
          collaboration avec nous et sera peut tre bientt un auteur de
          sections de cet HOWTO.

   IOS Committed Access Rate
          Des gens de Cisco qui ont pris la louable habitude de mettre
          leur documentation en ligne. La syntaxe de Cisco est diffrente
          mais les concepts sont identiques, sauf qu'on fait mieux, et
          sans matriel qui cote autant qu'une voiture :-)

   TCP/IP Illustrated, volume 1, W. Richard Stevens, ISBN 0-201-63346-9
          Sa lecture est indispensable si vous voulez rellement
          comprendre TCP/IP, et de plus elle est divertissante.
     _________________________________________________________________

Chapitre 20. Remerciements

   Notre but est de faire la liste de toutes les personnes qui ont
   contribu  ce HOWTO, ou qui nous ont aids  expliquer le
   fonctionnement des choses. Alors qu'il n'existe pas actuellement de
   tableau d'honneur Netfilter, nous souhaitons saluer les personnes qui
   apportent leur aide.

     * Juanjo Alins
       <juanjo@mat.upc.es>
     * Joe Van Andel
     * Michael T. Babcock
       <mbabcock@fibrespeed.net>
     * Christopher Barton
       <cpbarton%uiuc.edu>
     * Ard van Breemen
       <ard%kwaak.net>
     * Ron Brinker
       <service%emcis.com>
     * ?ukasz Bromirski
       <L.Bromirski@prosys.com.pl>
     * Lennert Buytenhek
       <buytenh@gnu.org>
     * Esteve Camps
       <esteve@hades.udg.es>
     * Stef Coene
       <stef.coene@docum.org>
     * Don Cohen
       <don-lartc%isis.cs3-inc.com>
     * Jonathan Corbet
       <lwn%lwn.net>
     * Gerry N5JXS Creager
       <gerry%cs.tamu.edu>
     * Marco Davids
       <marco@sara.nl>
     * Jonathan Day
       <jd9812@my-deja.com>
     * Martin aka devik Devera
       <devik@cdi.cz>
     * Stephan "Kobold" Gehring
       <Stephan.Gehring@bechtle.de>
     * Jacek Glinkowski
       <jglinkow%hns.com>
     * Andrea Glorioso
       <sama%perchetopi.org>
     * Nadeem Hasan
       <nhasan@usa.net>
     * Erik Hensema
       <erik%hensema.xs4all.nl>
     * Vik Heyndrickx
       <vik.heyndrickx@edchq.com>
     * Spauldo Da Hippie
       <spauldo%usa.net>
     * Koos van den Hout
       <koos@kzdoos.xs4all.nl>
     * Stefan Huelbrock <shuelbrock%datasystems.de>
     * Alexander W. Janssen <yalla%ynfonatic.de>
     * Gareth John <gdjohn%zepler.org>
     * Martin Josefsson <gandalf%wlug.westbo.se>
     * Andi Kleen <ak%suse.de>
     * Andreas J. Koenig <andreas.koenig%anima.de>
     * Pawel Krawczyk <kravietz%alfa.ceti.pl>
     * Amit Kucheria <amitk@ittc.ku.edu>
     * Edmund Lau <edlau%ucf.ics.uci.edu>
     * Philippe Latu <philippe.latu%linux-france.org>
     * Arthur van Leeuwen <arthurvl%sci.kun.nl>
     * Jason Lunz <j@cc.gatech.edu>
     * Stuart Lynne <sl@fireplug.net>
     * Alexey Mahotkin <alexm@formulabez.ru>
     * Predrag Malicevic <pmalic@ieee.org>
     * Patrick McHardy <kaber@trash.net>
     * Andreas Mohr <andi%lisas.de>
     * Andrew Morton <akpm@zip.com.au>
     * Wim van der Most
     * Stephan Mueller <smueller@chronox.de>
     * Togan Muftuoglu <toganm%yahoo.com>
     * Chris Murray <cmurray@stargate.ca>
     * Patrick Nagelschmidt <dto%gmx.net>
     * Ram Narula <ram@princess1.net>
     * Jorge Novo <jnovo@educanet.net>
     * Patrik <ph@kurd.nu>
     * P?l Osgy?ny <oplab%westel900.net>
     * Lutz Preler <Lutz.Pressler%SerNet.DE>
     * Jason Pyeron <jason%pyeron.com>
     * Rusty Russell <rusty%rustcorp.com.au>
     * Mihai RUSU <dizzy%roedu.net>
     * Jamal Hadi Salim <hadi%cyberus.ca>
     * David Sauer <davids%penguin.cz>
     * Sheharyar Suleman Shaikh <sss23@drexel.edu>
     * Stewart Shields <MourningBlade%bigfoot.com>
     * Nick Silberstein <nhsilber%yahoo.com>
     * Konrads Smelkov <konrads@interbaltika.com>
     * William Stearns
       <wstearns@pobox.com>
     * Andreas Steinmetz <ast%domdv.de>
     * Jason Tackaberry <tack@linux.com>
     * Charles Tassell <ctassell%isn.net>
     * Glen Turner <glen.turner%aarnet.edu.au>
     * Tea Sponsor: Eric Veldhuyzen <eric%terra.nu>
     * Song Wang <wsong@ece.uci.edu>
