          HOWTO du routage avanc et du contrle de trafic sous Linux

  Bert Hubert

   Netherlabs BV

   <bert.hubert@netherlabs.nl>

   Thomas Graf (Auteur d'une section)

   <tgraf%suug.ch>

   Gregory Maxwell (Auteur d'une section)
   Remco van Mook (Auteur d'une section)

   <remco@virtu.nl>

   Martijn van Oosterhout (Auteur d'une section)

   <kleptog@cupid.suninternet.com>

   Paul B. Schroeder (Auteur d'une section)

   <paulsch@us.ibm.com>

   Jasper Spaans (Auteur d'une section)

   <jasper@spaans.ds9a.nl>

   Pedro Larroy (Auteur d'une section)

   <piotr%member.fsf.org>

  Laurent Foucher

   Traducteur

   <foucher(at)gch.iut-tlse3.fr>

   Philippe Latu
   Traducteur/Relecteur

   <philippe.latu(at)linux-france.org>

   Guillaume Allgre
   Relecteur

   <Guillaume.Allegre(at)imag.fr>

   +------------------------------------------------------------------------+
   | Historique des versions                                                |
   |------------------------------------------------------------------------|
   | Version $Revision: | $Date: 2007-04-21 16:52:00      | $Author: latu $ |
   | 1112 $             | +0200 (sam, 21 avr 2007) $      |                 |
   |------------------------------------------------------------------------|
   | IPSEC, OSPF & BGP                                                      |
   +------------------------------------------------------------------------+

   Rsum

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

   --------------------------------------------------------------------------

   Table des matires

   1. Ddicace

   2. Introduction

                1. Conditions de distribution et Mise en garde

                2. Connaissances pralables

                3. Ce que Linux peut faire pour vous

                4. Notes diverses

                5. Accs, CVS et propositions de mises  jour

                6. Liste de diffusion

                7. Plan du document

   3. Introduction  iproute2

                1. Pourquoi iproute2 ?

                2. Un tour d'horizon d'iproute2

                3. Prrequis

                4. Explorer votre configuration courante

                             4.1. ip nous montre nos liens

                             4.2. ip nous montre nos adresses IP

                             4.3. ip nous montre nos routes

                5. ARP

   4. Rgles - bases de donnes des politiques de routage

                1. Politique de routage simple par l'adresse source

                2. Routage avec plusieurs accs Internet/fournisseurs d'accs

                             2.1. Accs spar

                             2.2. Balance de charge

   5. GRE et autres tunnels

                1. Quelques remarques gnrales  propos des tunnels :

                2. IP dans un tunnel IP

                3. Le tunnel GRE

                             3.1. Le tunnel IPv4

                             3.2. Le tunnel IPv6

                4. Tunnels dans l'espace utilisateur

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

                1. Tunnel IPv6

   7. IPSEC: IP scuris  travers Internet

                1. Introduction sur la gestion manuelle des cls

                2. Gestion automatique des cls

                             2.1. Thorie

                             2.2. Exemple

                             2.3. Gestion automatique des cls en utilisant
                             les certificats X.509

                3. tunnels IPSEC

                4. Autre logiciel IPSEC

                5. Interoprabilit d'IPSEC avec d'autres systmes

                             5.1. Windows

                             5.2. Check Point VPN-1 NG

   8. Routage multidistribution (multicast)

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

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

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

                             2.1. pfifo_fast

                             2.2. Filtre  seau de jetons (Token Bucket
                             Filter)

                             2.3. Mise en file d'attente stochastiquement
                             quitable (Stochastic Fairness Queueing)

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

                4. terminologie

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

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

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

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

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

                             5.5. Seau de jetons  contrle hirarchique
                             (Hierarchical Token Bucket)

                6. Classifier des paquets avec des filtres

                             6.1. Quelques exemples simples de filtrage

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

                7. Le priphrique de file d'attente intermdiaire (The
                Intermediate queueing device (IMQ))

                             7.1. Configuration simple

   10. quilibrage de charge sur plusieurs interfaces

                1. Avertissement

   11. Netfilter et iproute - marquage de paquets

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

                1. Le classificateur u32

                             1.1. Le slecteur U32

                             1.2. Slecteurs gnraux

                             1.3. Les slecteurs spcifiques

                2. Le classificateur route

                3. Les filtres de rglementation (Policing filters)

                             3.1. Techniques de rglementation

                             3.2. Actions de dpassement de limite (Overlimit
                             actions)

                             3.3. Exemples

                4. Filtres hachs pour un filtrage massif trs rapide

                5. Filtrer le trafic IPv6

                             5.1. Comment se fait-il que ces filtres tc IPv6
                             ne fonctionnent pas ?

                             5.2. Marquer les paquets IPv6 en utilisant
                             ip6tables

                             5.3. Utiliser le slecteur u32 pour reprer le
                             paquet IPv6

   13. Paramtres rseau du noyau

                1. Filtrage de Chemin Inverse (Reverse Path Filtering)

                2. Configurations obscures

                             2.1. ipv4 gnrique

                             2.2. Configuration des priphriques

                             2.3. Politique de voisinage

                             2.4. Configuration du routage

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

                1. bfifo/pfifo

                             1.1. Paramtres & usage

                2. Algorithme Clark-Shenker-Zhang (CSZ)

                3. DSMARK

                             3.1. Introduction

                             3.2. A quoi DSMARK est-il reli ?

                             3.3. Guide des services diffrencis

                             3.4. Travailler avec DSMARK

                             3.5. Comment SCH_DSMARK travaille.

                             3.6. Le filtre TC_INDEX

                4. Gestionnaire de mise en file d'attente d'entre (Ingress
                qdisc)

                             4.1. Paramtres & usage

                5. Random Early Detection (RED)

                6. Generic Random Early Detection

                7. Emulation VC/ATM

                8. Weighted Round Robin (WRR)

   15. Recettes de cuisine

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

                2. Protger votre machine des inondations SYN

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

                4. Donner la priorit au trafic interactif

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

                             5.1. Schma du trafic aprs l'implmentation

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

                             6.1. Solution

                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)

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

                             8.1. Pourquoi cela ne marche t-il pas bien par
                             dfaut ?

                             8.2. Le script (CBQ)

                             8.3. Le script (HTB)

                9. Limitation du dbit pour un hte ou un masque de
                sous-rseau

                10. Exemple d'une solution de traduction d'adresse avec de la
                QoS

                             10.1. Commenons l'optimisation de cette rare
                             bande passante

                             10.2. Classification des paquets

                             10.3. Amliorer notre configuration

                             10.4. Rendre tout ceci actif au dmarrage

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

                1. Etat des ponts et iptables

                2. Pont et mise en forme

                3. Pseudo-pont avec du Proxy-ARP

                             3.1. ARP & Proxy-ARP

                             3.2. Implmentez-le

   17. Routage Dynamique - OSPF et BGP

                1. Configurer OSPF avec Zebra

                             1.1. Prrequis

                             1.2. Configurer Zebra

                             1.3. Excuter Zebra

                2. Configurer BGP4 avec Zebra

                             2.1. schma rseau (Exemple)

                             2.2. Configuration (Exemple)

                             2.3. Vrification de la configuration

   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

   Table des matires

   1. Conditions de distribution et Mise en garde

   2. Connaissances pralables

   3. Ce que Linux peut faire pour vous

   4. Notes diverses

   5. Accs, CVS et propositions de mises  jour

   6. Liste de diffusion

   7. Plan du document

   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.

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. 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
   [http://netfilter.samba.org/unreliable-guides/networking-concepts-HOWTO/index.html]

           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 [http://www.linuxports.com/howto/networking]

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.

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'autres 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.

5. Accs, CVS et propositions de mises  jour

   L'adresse canonique de cet HOWTO est Ici [http://www.ds9a.nl/lartc].

   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/lartc.db

   Si vous avez fait des changements et que vous vouliez contribuer au HOWTO,
   excutez cvs -z3 diff -uBb, et envoyez-nous le rsultat par courrier
   lectronique de faon  pouvoir facilement intgrer les modifications.
   Merci ! Au fait, soyez sr que vous avez dit le fichier .db, les autres
   documents tant gnrs  partir de celui-ci.

   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.

   Faites attention de ne pas diter le fichier 2.4routing.sgml ! Il contient
   une ancienne version du HOWTO. Le bon fichier est lartc.db.

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 [http://mailman.ds9a.nl/mailman/listinfo/lartc].

   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.

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
       [http://netfilter.samba.org/unreliable-guides/]

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

Chapitre 3. Introduction  iproute2

   Table des matires

   1. Pourquoi iproute2 ?

   2. Un tour d'horizon d'iproute2

   3. Prrequis

   4. Explorer votre configuration courante

                4.1. ip nous montre nos liens

                4.2. ip nous montre nos adresses IP

                4.3. ip nous montre nos routes

   5. ARP

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.

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. 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 [1]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 actives dans le noyau fourni 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.

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.

  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 : traduction 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.

  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.

  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

5. ARP

   ARP est le Protocole de Rsolution d'Adresse (Address Resolution
   Protocol). Il est dcrit dans le RFC 826
   [http://www.faqs.org/rfcs/rfc826.html]. 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

   Table des matires

   1. Politique de routage simple par l'adresse source

   2. Routage avec plusieurs accs Internet/fournisseurs d'accs

                2.1. Accs spar

                2.2. Balance de charge

   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 paquet iproute2 de votre distribution].

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.

2. Routage avec plusieurs accs Internet/fournisseurs d'accs

   Une configuration classique est la suivante, o deux fournisseurs d'accs
   permettent la connexion d'un rseau local (ou mme d'une simple machine) 
   Internet.

                                                                    ________
                                           +--------------+        /
                                           |              |       |
                             +-------------+ Fournisseur 1+-------
         __                  |             |              |     /
     ___/  \_         +------+-------+     +--------------+    |
   _/        \__      |     if1      |                        /
  /             \     |              |                        |
 | Rseau Local  -----+ Routeur Linux|                        |     Internet
  \_           __/    |              |                        |
    \__     __/       |     if2      |                        \
       \___/          +------+-------+     +--------------+    |
                             |             |              |     \
                             +-------------+ Fournisseur 2+-------
                                           |              |       |
                                           +--------------+        \________

   Il y a gnralement deux questions  se poser pour cette configuration.

  2.1. Accs spar

   La premire est de savoir comment router les rponses aux paquets entrants
   par un fournisseur particulier, disons le Fournisseur 1, vers ce mme
   fournisseur.

   Commenons par dfinir quelques symboles. $IF1 sera le nom de la premire
   interface (if1 sur la figure au-dessus) et $IF2 le nom de la deuxime
   interface. $IP1 sera alors l'adresse IP associe  $IF1 et $IP2 sera
   l'adresse IP associe  $IF2. $P1 sera l'adresse IP de la passerelle du
   fournisseur d'accs 1 et $P2 sera l'adresse IP de la passerelle du
   fournisseur d'accs 2. Enfin, $P1_NET sera l'adresse rseau  l'intrieur
   duquel se situe $P1 et $P2_NET sera l'adresse rseau  l'intrieur duquel
   se situe $P2.

   Deux tables de routage supplmentaires sont cres, par exemple T1 et T2.
   Celles-ci sont ajoutes dans /etc/iproute2/rt_tables. La configuration du
   routage dans ces tables s'effectue de la faon suivante :

 ip route add $P1_NET dev $IF1 src $IP1 table T1
 ip route add default via $P1 table T1
 ip route add $P2_NET dev $IF2 src $IP2 table T2
 ip route add default via $P2 table T2

   Rien de vraiment spectaculaire. Une route est simplement positionne vers
   la passerelle et une route par dfaut via cette passerelle est mise en
   place, comme nous le ferions dans le cas d'un seul fournisseur d'accs.
   Ici, les routes sont places dans des tables spares, une par fournisseur
   d'accs. Il est  noter que la route vers le rseau suffit, dans la mesure
   o elle indique comment trouver n'importe quel hte dans ce rseau, ce qui
   inclut la passerelle.

   La table de routage principale est maintenant configure. C'est une bonne
   ide de router les lments  destination d'un voisin direct  travers
   l'interface connecte  ce voisin. Notez les arguments "src" qui assurent
   que la bonne adresse IP source sera choisie.

 ip route add $P1_NET dev $IF1 src $IP1
 ip route add $P2_NET dev $IF2 src $IP2

   Indiquez maintenant votre prfrence pour votre route par dfaut :

 ip route add default via $P1

   Vous configurez ensuite les rgles de routage. Celles-ci dfinissent la
   table qui sera vraiment choisie pour le routage. Il faut s'assurer que le
   routage s'effectue  travers une interface donne si vous avez l'adresse
   source correspondante :

 ip rule add from $IP1 table T1
 ip rule add from $IP2 table T2

   Cet ensemble de commandes vous assure que toutes les rponses au trafic
   entrant sur une interface particulire seront envoyes par cette
   interface.

[2][Avertissement] Avertissement
                   Notes d'un lecteur : si $P0_NET est le rseau local et $IF0 est son interface,
                   alors les entres suivantes sont dsirables :

                   ip route add $P0_NET     dev $IF0 table T1
                   ip route add $P2_NET     dev $IF2 table T1
                   ip route add 127.0.0.0/8 dev lo   table T1
                   ip route add $P0_NET     dev $IF0 table T2
                   ip route add $P1_NET     dev $IF1 table T2
                   ip route add 127.0.0.0/8 dev lo   table T2

   Nous avons maintenant une configuration trs basique. Elle marchera pour
   tous les processus excuts sur le routeur lui-mme, ainsi que pour le
   rseau local si celui-ci est masqu. Si ce n'est pas le cas, soit vous
   avez une plage d'adresses IP pour chaque fournisseur d'accs, soit vous
   masquez vers l'un des deux fournisseurs d'accs. Dans les deux cas, vous
   ajouterez des rgles indiquant, en fonction de l'adresse IP de la machine
   du rseau local, vers quel fournisseur vous allez router.

  2.2. Balance de charge

   La seconde question concerne la balance de charge du trafic sortant vers
   les deux fournisseurs d'accs. Ceci n'est pas vraiment trs dur si vous
   avez dj configur l'accs spar comme dcrit ci-dessus.

   Au lieu de choisir l'un des deux fournisseurs d'accs comme route par
   dfaut, celle-ci peut tre une route multi-chemin. Par dfaut, le noyau
   rpartira les routes vers les deux fournisseurs d'accs. Ceci est ralis
   de la faon suivante (construit galement sur l'exemple de la section de
   l'accs spar) :

 ip route add default scope global nexthop via $P1 dev $IF1 weight 1 \
 nexthop via $P2 dev $IF2 weight 1

   Ceci ralisera la balance des routes vers les deux fournisseurs. Les
   paramtres weight peuvent permettre de favoriser un fournisseur par
   rapport  un autre.

   Il est  noter que la balance de charge ne sera pas parfaite dans la
   mesure o elle est base sur les routes et que celles-ci sont mises dans
   des caches. Ceci signifie que les routes vers les sites les plus souvent
   utiliss passeront toujours par le mme fournisseur d'accs.

   De plus, si vous voulez vraiment mettre en oeuvre ceci, vous devriez
   galement aller consulter les mises  jour de Julien Anastasov 
   http://www.ssi.bg/~ja/#routes [http://www.ssi.bg/~ja/#routes] Elles
   rendront le travail plus facile.

Chapitre 5. GRE et autres tunnels

   Table des matires

   1. Quelques remarques gnrales  propos des tunnels :

   2. IP dans un tunnel IP

   3. Le tunnel GRE

                3.1. Le tunnel IPv4

                3.2. Le tunnel IPv6

   4. Tunnels dans l'espace utilisateur

   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).

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.

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.

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.

  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.

  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.

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)

   Table des matires

   1. Tunnel IPv6

   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.

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 225]
 # 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 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 Internet

   Table des matires

   1. Introduction sur la gestion manuelle des cls

   2. Gestion automatique des cls

                2.1. Thorie

                2.2. Exemple

                2.3. Gestion automatique des cls en utilisant les
                certificats X.509

   3. tunnels IPSEC

   4. Autre logiciel IPSEC

   5. Interoprabilit d'IPSEC avec d'autres systmes

                5.1. Windows

                5.2. Check Point VPN-1 NG

   A ce jour, deux versions d'IPSEC sont disponibles pour Linux. FreeS/WAN,
   qui ft la premire implmentation majeure, existe pour les noyaux Linux
   2.2 et 2.4. Ce projet a un site officiel [http://www.freeswan.org/] et
   galement un site non officiel [http://www.freeswan.ca], qui est bien
   maintenu. FreeS/WAN n'a jamais t intgr dans le noyau pour un certain
   nombre de raisons. Celle qui est la plus souvent mentionne concerne un
   problme "politique" avec les amricains travaillant sur la cryptographie
   qui freinent son exportabilit. De plus, la mise en place de FreeS/WAN
   dans le noyau Linux est dlicate, ce qui n'en fait pas un bon candidat
   pour une relle intgration.

   De plus, des [http://www.edlug.ed.ac.uk/archive/Sep2002/msg00244.html]
   personnes se sont inquites
   [http://lists.freeswan.org/pipermail/design/2002-November/003901.html] de
   la qualit du code. Pour configurer FreeS/WAN, de nombreuses
   documentations
   [http://www.freeswan.ca/code/old/freeswan-Snapshot/doc/index.html] sont
   disponibles [http://www.freeswan.org/doc.html].

   Une implmentation native d'IPSEC est prsente dans le noyau  partir de
   la version Linux 2.5.47. Elle a t crite par Alexey Kuznetsov et Dave
   Miller, qui se sont inspirs des travaux du groupe USAGI IPv6. Avec cette
   fusion, les CryptoAPI de James Morris deviennent galement une partie du
   noyau, qui fait ainsi vraiment du cryptage.

   Ce HOWTO ne documente que la version 2.5 d'IPSEC. FreeS/WAN est recommand
   pour l'instant pour les utilisateurs de Linux 2.4. Fates cependant
   attention, dans la mesure o sa configuration est diffrente de l'IPSEC
   natif. Il y a maintenant une mise  jour
   [http://gondor.apana.org.au/~herbert/freeswan/] qui permet au code
   FreeS/WAN de l'espace utilisateur de fonctionner avec l'IPSEC natif de
   Linux.

   A partir du noyau 2.5.49, IPSEC fonctionne sans l'ajout de mises  jour
   supplmentaires.

   [3][Note] Note
             Les outils de l'espace utilisateur sont disponibles ici
             [http://sourceforge.net/projects/ipsec-tools]. Il y a plusieurs
             programmes disponibles ; celui qui est propos dans le lien est
             bas sur Racoon.

             Lors de la compilation du noyau, soyez sr d'activer 'PF_KEY',
             'AH' et tous les lments de CryptoAPI !

   [4][Avertissement] Avertissement
                      L'auteur de ce chapitre est un complet nigaud en ce qui
                      concerne IPSEC ! Si vous trouvez les invitables
                      erreurs, envoyez un courrier lectronique  Bert Hubert
                      <ahu@ds9a.nl>.

   Tout d'abord, nous montrerons comment configurer manuellement une
   communication scurise entre deux htes. Une grande partie de ce
   processus peut tre automatise, mais nous le ferons ici  la main afin de
   comprendre ce qui se passe "sous le capot".

   Passez  la section suivante si la seule gestion automatique des cls vous
   intresse. Soyez cependant conscient que la comprhension de la gestion
   manuelle des cls est utile.

1. Introduction sur la gestion manuelle des cls

   IPSEC est un sujet compliqu. De nombreuses informations sont disponibles
   en ligne. Ce HOWTO se concentrera sur la mise en place et  l'explication
   des principes de base. Tous les exemples sont bass sur Racoon dont le
   lien est donn au-dessus.

   [5][Note] Note
             Certaines configurations iptables rejettent les paquets IPSEC !
             Pour transmettre IPSEC, utilisez : iptables -A xxx -p 50 -j
             ACCEPT et 'iptables -A xxx -p 51 -j ACCEPT.

   IPSEC offre une version scurise de la couche IP (Internet Protocol). La
   scurit dans ce contexte prend deux formes : l'encryptage et
   l'authentification. Une vision nave de la scurit ne propose que le
   cryptage. On peut cependant montrer facilement que c'est insuffisant : il
   se peut que vous ayez une communication crypte, mais vous n'avez aucune
   garantie que l'hte distant est bien celui auquel vous pensez.

   IPSEC supporte 'Encapsulated Security Payload' (Encapsulation Scurise de
   la Charge utile) (ESP) pour le cryptage et 'Authentication Header' (Entte
   d'Authentification) (AH) pour authentifier le partenaire distant. Vous
   pouvez configurer les deux, ou dcider de ne faire que l'un des deux.

   ESP et AH s'appuient tous les deux sur des Associations de Scurit
   (Security Associations (SA)). Une Association de Scurit (SA) consiste en
   une source, une destination et une instruction. Un exemple simple
   d'Association de Scurit (SA) pour l'authentification peut ressembler 
   ceci :

 add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";

   Ceci indique que le trafic allant de 10.0.0.11 vers 10.0.0.216 a besoin
   d'un En-tte d'Authentification (AH) qui peut tre sign en utilisant
   HMAC-MD et le secret 1234567890123456. Cette instruction est repre par
   l'identificateur SPI (Security Parameter Index) 15700, dont nous parlerons
   plus par la suite. Le point intressant  propos des Associations de
   Scurit (SA) est qu'elles sont symtriques. Les deux cots de la
   conversation partagent exactement la mme Association de Scurit (SA),
   qui n'est pas recopie sur l'hte distant. Notez cependant qu'il n'y a pas
   de rgles "d'inversion automatique". Cette Association de Scurit (SA)
   dcrit une authentification possible de 10.0.0.11 vers 10.0.0.216. Pour un
   trafic bidirectionnel, deux Associations de Scurit (SA) sont
   ncessaires.

   Un exemple d'Association de Scurit (SA) pour le cryptage ESP :

 add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";

   Ceci signifie que le trafic allant de 10.0.0.11 vers 10.0.0.216 est
   chiffr en utilisant 3des-cbc avec la cl 123456789012123456789012.
   L'identificateur SPI est 15701.

   Jusqu'ici, nous avons vu que les Associations de Scurit (SA) dcrivent
   les instructions possibles, mais pas la politique qui indique quand ces SA
   doivent tre utilises. En fait, il pourrait y avoir un nombre arbitraire
   de SA presques identiques ne se diffrenciant que par les identificateurs
   SPI. Entre parenthses, SPI signifie Security Parameter Index, ou Index du
   Paramtre de Scurit en franais. Pour faire vraiment du cryptage, nous
   devons dcrire une politique. Cette politique peut inclure des choses
   comme "utiliser ipsec s'il est disponible" ou "rejeter le trafic  moins
   que vous ayez ipsec".

   Une "Politique de Scurit" (Security Policy (SP)) typique ressemble 
   ceci :

 spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
  esp/transport//require
  ah/transport//require;

   Si cette configuration est applique sur l'hte 10.0.0.216, cela signifie
   que tout le trafic allant vers 10.0.0.11 doit tre encrypt et encapsul
   dans un en-tte d'authentification AH. Notez que ceci ne dcrit pas quelle
   SA sera utilise. Cette dtermination est un exercice laiss  la charge
   du noyau.

   En d'autres termes, une Politique de Scurit spcifie CE QUE nous
   voulons ; une Association de Scurit dcrit COMMENT nous le voulons.

   Les paquets sortants sont tiquets avec le SPI SA ('le comment') que le
   noyau utilise pour l'encryptage et l'authentification et l'hte distant
   peut consulter les instructions de vrification et de dcryptage
   correspondantes.

   Ce qui suit est une configuration trs simple permettant le dialogue de
   l'hte 10.0.0.216 vers l'hte 10.0.0.11 en utilisant l'encryptage et
   l'authentification. Notez que le trafic de retour de cette premire
   version est en clair et que cette configuration ne doit pas tre dploye.

   Sur l'hte 10.0.0.216 :

 #!/sbin/setkey -f
 add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
 add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

 spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
    esp/transport//require
    ah/transport//require;

   Sur l'hte 10.0.0.11, nous donnons les mmes Associations de Scurit
   (SA). Nous ne donnons pas de Politique de Scurit :

 #!/sbin/setkey -f
 add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";
 add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

   Avec la mise en place de la configuration ci-dessus (ces fichiers peuvent
   tre excuts si 'setkey' est install dans /sbin), la commande ping
   10.0.0.11 excute sur 10.0.0.216 va donner la sortie suivante avec
   tcpdump :

 22:37:52 10.0.0.216 > 10.0.0.11: AH(spi=0x00005fb4,seq=0xa): ESP(spi=0x00005fb5,seq=0xa) (DF)
 22:37:52 10.0.0.11 > 10.0.0.216: icmp: echo reply

   Notez que le paquet de retour provenant de 10.0.0.11 est en effet
   compltement visible. Le paquet ping mis par 10.0.0.216 ne peut
   videmment pas tre lu par tcpdump, mais celui-ci montre l'Index du
   Paramtre de Scurit (SPI) de l'AH, ainsi que l'ESP, qui indique 
   10.0.0.11 comment vrifier l'authenticit de notre paquet et comment le
   dcrypter.

   Quelques lments doivent tre mentionns. La configuration ci-dessus est
   propose dans de nombreux exemples d'IPSEC, mais elle est trs dangereuse.
   Le problme est qu'elle contient la politique indiquant  10.0.0.216
   comment traiter les paquets allant vers 10.0.0.11 et comment 10.0.0.11
   doit traiter ces paquets, mais ceci n'INDIQUE pas  10.0.0.11 de rejeter
   le trafic non authentifi et non encrypt !

   N'importe qui peut maintenant insrer des donnes "spoofes" (NdT :
   usurpes) et entirement non cryptes que 10.0.0.1 acceptera. Pour
   remdier  ceci, nous devons avoir sur 10.0.0.11 une Politique de Scurit
   pour le trafic entrant :

 #!/sbin/setkey -f
 spdadd 10.0.0.216 10.0.0.11 any -P IN ipsec
    esp/transport//require
    ah/transport//require;

   Ceci indique  10.0.0.11 que tout le trafic venant de 10.0.0.216 ncessite
   d'avoir un ESP et AH valide.

   Maintenant, pour complter cette configuration, nous devons galement
   renvoyer un trafic encrypt et authentifi. La configuration complte sur
   10.0.0.216 est la suivante :

 #!/sbin/setkey -f
 flush;
 spdflush;

 # AH
 add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
 add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

 # ESP
 add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
 add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";

 spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
            esp/transport//require
            ah/transport//require;

 spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
            esp/transport//require
            ah/transport//require;

   Et sur 10.0.0.11 :

 #!/sbin/setkey -f
 flush;
 spdflush;

 # AH
 add 10.0.0.11 10.0.0.216 ah 15700 -A hmac-md5 "1234567890123456";
 add 10.0.0.216 10.0.0.11 ah 24500 -A hmac-md5 "1234567890123456";

 # ESP
 add 10.0.0.11 10.0.0.216 esp 15701 -E 3des-cbc "123456789012123456789012";
 add 10.0.0.216 10.0.0.11 esp 24501 -E 3des-cbc "123456789012123456789012";


 spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
            esp/transport//require
            ah/transport//require;

 spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
            esp/transport//require
            ah/transport//require;

   Notez que, dans cet exemple, nous avons utilis des cls identiques pour
   les deux directions du trafic. Ceci n'est cependant en aucun cas exig.

   Pour examiner la configuration que nous venons de crer, excuter setkey
   -D, qui montre les SA ou setkey -DP qui montre les politiques configures.

2. Gestion automatique des cls

   Dans la section prcdente, l'encryptage tait configur pour utiliser
   simplement le partage de secrets. En d'autres termes, pour rester
   scuris, nous devons transfrer la configuration de notre encryptage 
   travers un tunnel scuris. Si nous avons configur l'hte distant par
   telnet, n'importe quel tiers pourrait avoir pris connaissance de notre
   secret partag et, ainsi, notre configuration ne serait plus sre.

   De plus, puisque le secret est partag, ce n'est pas un secret. L'hte
   distant ne peut pas en faire grand chose, mais nous devons tre srs
   d'utiliser un secret diffrent pour les communications avec tous nos
   partenaires. Ceci ncessite un grand nombre de cls. Pour 10 partenaires,
   nous devrions avoir au moins 50 secrets diffrents.

   En plus du problme des cls symtriques, le renouvellement des cls est
   galement ncessaire. Si un tiers coute suffisamment le trafic, il peut
   tre en position de retrouver la cl par rtro ingnierie. On peut s'en
   prmunir en modifiant la cl de temps en temps, mais ce processus a besoin
   d'tre automatis.

   Un autre problme est que la gestion manuelle des cls dcrite au-dessus
   impose de dfinir prcisment les algorithmes et les longueurs de cls
   utilises, ce qui ncessite une grande coordination avec l'hte distant.
   Il serait prfrable d'avoir la capacit  dcrire une politique des cls
   plus large comme par exemple "Nous pouvons faire du 3DES et du Blowfish
   avec les longueurs de cls suivantes".

   Pour rsoudre ces problmes, IPSEC fournit l'Echange de Cl sur Internet
   (Internet Key Echange (IKE)) permettant d'automatiser l'change de cls
   gnres alatoirement. Ces cls sont transmises en utilisant une
   technologie d'encryptage asymtrique ngocie.

   L'implmentation IPSEC de Linux 2.5 fonctionne avec le dmon IKE "KAME
   racoon". Depuis le 9 novembre, la version de racoon prsente la
   distribution iptools d'Alexey peut tre compile en supprimant, au
   pralable #include <net/route.h> dans deux fichiers. Je fournis une
   version prcompile [http://ds9a.nl/ipsec/racoon.bz2].

   [6][Note] Note
             L'Echange de Cl sur Internet (IKE) doit avoir accs au port UDP
             500. Soyez sr que iptables ne le bloque pas.

  2.1. Thorie

   Comme expliqu avant, la gestion automatique des cls ralise beaucoup
   d'oprations pour nous. Spcifiquement, il cre  la vole les
   Associations de Scurit. Il ne configure cependant pas la politique pour
   nous, ce qui est le fonctionnement attendu.

   Donc, pour bnficier de IKE, configurez une politique, mais ne fournissez
   aucune Association de Scurit. Si le noyau dcouvre qu'il y a une
   politique IPSEC, mais pas d'Association de Scurit, il va le notifier au
   dmon IKE qui va chercher  en ngocier une.

   De nouveau, rappelons que la Politique de Scurit spcifie CE QUE nous
   voulons tandis que l'Association de Scurit dcrit COMMENT nous le
   voulons. L'utilisation de la gestion automatique des cls nous permet de
   ne spcifier que ce que nous voulons.

  2.2. Exemple

   Kame racoon possde un grand nombre d'options dont la plupart des valeurs
   par dfaut sont corrects ; nous n'avons donc pas besoin de les modifier.
   Comme nous l'avons dit auparavant, l'oprateur doit dfinir une Politique
   de Scurit, mais pas d'Associations de Scurit. Nous laissons cette
   ngociation au dmon IKE.

   Dans cet exemple, 10.0.0.1 et 10.0.0.216 sont encore une fois sur le point
   d'tablir des communications scurises mais, cette fois, avec l'aide du
   dmon racoon. Par soucis de simplification, cette configuration utilisera
   des cls pr-partages, les redouts 'secrets partags'. Nous discuterons
   des certificats X.509 dans une section  part. Voir Section 2.3,  Gestion
   automatique des cls en utilisant les certificats X.509 .

   Nous allons  peu prs rester fidle  la configuration par dfaut, qui
   est identique sur les deux htes :

 path pre_shared_key "/usr/local/etc/racoon/psk.txt";

 remote anonymous
 {
         exchange_mode aggressive,main;
         doi ipsec_doi;
         situation identity_only;

         my_identifier address;

         lifetime time 2 min;   # sec,min,hour
         initial_contact on;
         proposal_check obey;    # obey, strict or claim

         proposal {
                 encryption_algorithm 3des;
                 hash_algorithm sha1;
                 authentication_method pre_shared_key;
                 dh_group 2 ;
         }
 }

 sainfo anonymous
 {
         pfs_group 1;
         lifetime time 2 min;
         encryption_algorithm 3des ;
         authentication_algorithm hmac_sha1;
                 compression_algorithm deflate ;
 }

   Beaucoup de paramtres. Je pense que l'on peut encore en supprimer pour se
   rapprocher de la configuration par dfaut. Remarquons ici quelques
   lments notables. Nous avons configur deux sections "anonymous", ce qui
   convient pour tous les htes distants. Ceci va ainsi faciliter les
   configurations supplmentaires. Il n'est pas ncessaire d'avoir de
   sections spcifiques  une machine particulire,  moins que vous ne le
   vouliez vraiment.

   De plus, la configuration prcise que nous nous identifions grce  notre
   adresse IP ('my_identifier address') et que nous pouvons faire du 3des,
   sha1 et que nous utiliserons une cl "pr-partage" se trouvant dans
   psk.txt.

   Dans le fichier psk.txt, nous avons configur deux entres qui sont
   diffrentes suivant les htes. Sur 10.0.0.11 :

 10.0.0.216  password2

   Sur 10.0.0.216 :

 10.0.0.11   password2

   Soyez sr que ces fichiers sont la proprit de root, et qu'ils ont le
   mode 0600. Dans le cas contraire, racoon ne pourra faire confiance  leur
   contenu. Notez que ces fichiers sont symtriques l'un de l'autre.

   Nous sommes maintenant prt  configurer notre politique qui est assez
   simple. Sur l'hte 10.0.0.216 :

 #!/sbin/setkey -f
 flush;
 spdflush;

 spdadd 10.0.0.216 10.0.0.11 any -P out ipsec
         esp/transport//require;

 spdadd 10.0.0.11 10.0.0.216 any -P in ipsec
         esp/transport//require;

   Et sur 10.0.0.11 :

 #!/sbin/setkey -f
 flush;
 spdflush;

 spdadd 10.0.0.11 10.0.0.216 any -P out ipsec
         esp/transport//require;

 spdadd 10.0.0.216 10.0.0.11 any -P in ipsec
         esp/transport//require;

   Noter que ces politiques sont encore une fois symtriques.

   Nous sommes maintenant prt  lancer racoon ! Une fois lanc, au moment o
   nous essayons une connexion un telnet depuis 10.0.0.11 vers 10.0.0.216, ou
   l'inverse, racoon aura dmarr la ngociation :

 12:18:44: INFO: isakmp.c:1689:isakmp_post_acquire(): IPsec-SA
   request for 10.0.0.11 queued due to no phase1 found.
 12:18:44: INFO: isakmp.c:794:isakmp_ph1begin_i(): initiate new
   phase 1 negotiation: 10.0.0.216[500]<=>10.0.0.11[500]
 12:18:44: INFO: isakmp.c:799:isakmp_ph1begin_i(): begin Aggressive mode.
 12:18:44: INFO: vendorid.c:128:check_vendorid(): received Vendor ID:
   KAME/racoon
 12:18:44: NOTIFY: oakley.c:2037:oakley_skeyid(): couldn't find
   the proper pskey, try to get one by the peer's address.
 12:18:44: INFO: isakmp.c:2417:log_ph1established(): ISAKMP-SA
   established 10.0.0.216[500]-10.0.0.11[500] spi:044d25dede78a4d1:ff01e5b4804f0680
 12:18:45: INFO: isakmp.c:938:isakmp_ph2begin_i(): initiate new phase 2
   negotiation: 10.0.0.216[0]<=>10.0.0.11[0]
 12:18:45: INFO: pfkey.c:1106:pk_recvupdate(): IPsec-SA established:
   ESP/Transport 10.0.0.11->10.0.0.216 spi=44556347(0x2a7e03b)
 12:18:45: INFO: pfkey.c:1318:pk_recvadd(): IPsec-SA established:
   ESP/Transport 10.0.0.216->10.0.0.11 spi=15863890(0xf21052)

   L'excution de la commande setkey -D, qui nous montre les Associations de
   Scurit, nous indique qu'elles sont en effet prsentes :

 10.0.0.216 10.0.0.11
         esp mode=transport spi=224162611(0x0d5c7333) reqid=0(0x00000000)
         E: 3des-cbc  5d421c1b d33b2a9f 4e9055e3 857db9fc 211d9c95 ebaead04
         A: hmac-sha1  c5537d66 f3c5d869 bd736ae2 08d22133 27f7aa99
         seq=0x00000000 replay=4 flags=0x00000000 state=mature
         created: Nov 11 12:28:45 2002   current: Nov 11 12:29:16 2002
         diff: 31(s)     hard: 600(s)    soft: 480(s)
         last: Nov 11 12:29:12 2002      hard: 0(s)      soft: 0(s)
         current: 304(bytes)     hard: 0(bytes)  soft: 0(bytes)
         allocated: 3    hard: 0 soft: 0
         sadb_seq=1 pid=17112 refcnt=0
 10.0.0.11 10.0.0.216
         esp mode=transport spi=165123736(0x09d79698) reqid=0(0x00000000)
         E: 3des-cbc  d7af8466 acd4f14c 872c5443 ec45a719 d4b3fde1 8d239d6a
         A: hmac-sha1  41ccc388 4568ac49 19e4e024 628e240c 141ffe2f
         seq=0x00000000 replay=4 flags=0x00000000 state=mature
         created: Nov 11 12:28:45 2002   current: Nov 11 12:29:16 2002
         diff: 31(s)     hard: 600(s)    soft: 480(s)
         last:                           hard: 0(s)      soft: 0(s)
         current: 231(bytes)     hard: 0(bytes)  soft: 0(bytes)
         allocated: 2    hard: 0 soft: 0
         sadb_seq=0 pid=17112 refcnt=0

   Nous avons les Politiques de Scurit que nous avons nous-mme
   configures :

 10.0.0.11[any] 10.0.0.216[any] tcp
         in ipsec
         esp/transport//require
         created:Nov 11 12:28:28 2002 lastused:Nov 11 12:29:12 2002
         lifetime:0(s) validtime:0(s)
         spid=3616 seq=5 pid=17134
         refcnt=3
 10.0.0.216[any] 10.0.0.11[any] tcp
         out ipsec
         esp/transport//require
         created:Nov 11 12:28:28 2002 lastused:Nov 11 12:28:44 2002
         lifetime:0(s) validtime:0(s)
         spid=3609 seq=4 pid=17134
         refcnt=3

    2.2.1. Problmes et dfauts connus

   Si cela ne marche pas, vrifiez que tous les fichiers de configuration
   sont la proprit de root et qu'ils ne peuvent tre lus que par celui-ci.
   Pour dmarrer racoon en avant-plan, utilisez '-F'. Pour le forcer  lire
   un fichier de configuration  la place de celui prcis lors de la
   compilation, utilisez '-f'. Pour obtenir de nombreux dtails, ajouter
   l'option 'log debug' dans le fichier racoon.conf.

  2.3. Gestion automatique des cls en utilisant les certificats X.509

   Comme nous l'avons dit avant, l'utilisation de secrets partags est
   complique car ils ne peuvent pas tre facilement partags et, une fois
   qu'ils le sont, ils ne sont plus secrets. Heureusement, nous avons la
   technologie d'encryptage asymmtrique pour nous aider  rsoudre ce
   problme.

   Si chaque participant d'une liaison IPSEC cre une cl publique et prive,
   des communications scurises peuvent tre mises en place par les deux
   parties en publiant leur cl publique et en configurant leur politique.

   Crer une cl est relativement facile, bien que cela exige un peu de
   travail. Ce qui suit est bas sur l'outil 'openssl'.

    2.3.1. Construire un certificat X.509 pour votre hte

   OpenSSL dispose d'une importante infrastructure de gestions des clefs,
   capable de grer des clefs signes ou non par une autorit de
   certification. Pour l'instant, nous avons besoin de court-circuiter toute
   cette infrastructure et de mettre en place une scurit de charlatan, et
   de travailler sans autorit de certification.

   Nous allons tout d'abord crer une requte de certificat (certificate
   request) pour notre hte, appel 'laptop' :

 $ openssl req -new -nodes -newkey rsa:1024 -sha1 -keyform PEM -keyout \
   laptop.private -outform PEM -out request.pem

   Des questions nous sont poses :

 Country Name (2 letter code) [AU]:NL
 State or Province Name (full name) [Some-State]:.
 Locality Name (eg, city) []:Delft
 Organization Name (eg, company) [Internet Widgits Pty Ltd]:Linux Advanced
 Routing & Traffic Control
 Organizational Unit Name (eg, section) []:laptop
 Common Name (eg, YOUR name) []:bert hubert
 Email Address []:ahu@ds9a.nl

 Please enter the following 'extra' attributes
 to be sent with your certificate request
 A challenge password []:
 An optional company name []:

   Vous avez toute libert quant aux rponses. Vous pouvez ou non mettre le
   nom d'hte, en fonction de vos besoins de scurit. C'est ce que nous
   avons fait dans cet exemple.

   Nous allons maintenant "auto signer" cette requte :

 $ openssl x509 -req -in request.pem -signkey laptop.private -out \
   laptop.public
 Signature ok
 subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic \
   Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl
 Getting Private key

   Le fichier "request.pem" peut maintenant tre limin.

   Rptez cette procdure pour tous les htes qui ont besoin d'une cl. Vous
   pouvez distribuer le fichier '.public' en toute impunit, mais garder le
   fichier '.private' priv !

    2.3.2. Configuration et lancement

   Une fois que nous avons les cls publiques et prives pour nos htes, nous
   pouvons indiquer  racoon de les utiliser.

   Reprenons notre configuration prcdente et les deux htes 10.0.0.11
   ('upstairs') et 10.0.0.216 ('laptop').

   Dans le fichier racoon.conf prsent sur 10.0.0.11, nous ajoutons :

 path certificate "/usr/local/etc/racoon/certs";

 remote 10.0.0.216
 {
         exchange_mode aggressive,main;
         my_identifier asn1dn;
         peers_identifier asn1dn;

         certificate_type x509 "upstairs.public" "upstairs.private";

         peers_certfile "laptop.public";
         proposal {
                 encryption_algorithm 3des;
                 hash_algorithm sha1;
                 authentication_method rsasig;
                 dh_group 2 ;
         }
 }

   Ceci indique  racoon que les certificats se trouvent dans
   /usr/local/etc/racoon/certs/. De plus, il contient des lments
   spcifiques pour l'hte distant 10.0.0.216.

   La ligne 'asn1dn' indique  racoon que l'identification pour l'hte local
   et distant doit tre extraite des cls publiques. Ceci correspond  la
   ligne 'subject=/C=NL/L=Delft/O=Linux Advanced Routing & Traffic
   Control/OU=laptop/CN=bert hubert/Email=ahu@ds9a.nl' donn au-dessus.

   La ligne certificate_type prcise l'emplacement des cls publiques et
   prives locales. La dclaration peers_certfile prcise  racoon que la cl
   publique de l'hte distant se trouve dans le fichier laptop.public.

   La section proposal reste inchange par rapport  ce que nous avons vu
   plus tt,  l'exception de authentification_method qui est maintenant
   rsasig, ce qui indique l'utilisation de cl RSA publique/prive pour
   l'authentification.

   La configuration ajoute sur 10.0.0.216 est presque identique, exception
   faite de l'habituelle symtrie :

 path certificate "/usr/local/etc/racoon/certs";

 remote 10.0.0.11
 {
         exchange_mode aggressive,main;
         my_identifier asn1dn;
         peers_identifier asn1dn;

         certificate_type x509 "laptop.public" "laptop.private";

         peers_certfile "upstairs.public";

         proposal {
                 encryption_algorithm 3des;
                 hash_algorithm sha1;
                 authentication_method rsasig;
                 dh_group 2 ;
         }
 }

   Maintenant que nous avons ajout ces lments sur les deux htes, la seule
   chose qui reste  faire est de mettre en place les fichiers contenant les
   cls. La machine 'upstairs' doit avoir les fichiers upstairs.private,
   upstairs.public, et laptop.public placs dans /usr/local/etc/racoon/certs.
   Soyez sr que le rpertoire est la proprit de root et qu'il possde les
   droits 0700. Dans le cas contraire, racoon pourrait refuser de lire le
   contenu de ce rpertoire.

   La machine 'laptop' doit avoir les fichiers upstairs.private,
   upstairs.public, et laptop.public placs dans /usr/local/etc/racoon/certs.
   Autrement dit, chaque hte doit avoir ses propres cls publique et prive
   et, de plus, la cl publique de l'hte distant.

   Vrifiez que la Politique de Scurit est en place (excutez la commande
   'spdadd' vue dans Section 2.2,  Exemple ). Lancez alors racoon et tout
   devrait fonctionner.

    2.3.3. Comment configurer des tunnels scuriss

   Pour configurer des communications scurises avec un hte distant, nous
   devons changer des cls publiques. Bien qu'il ne soit pas ncessaire que
   la cl publique reste secrte, il est important d'tre sr que cette cl
   n'a pas t modifie. En d'autres termes, vous devez tre certain qu'il
   n'y a pas de 'man in the middle'. [NdT : 'man in the middle' est le nom
   d'une attaque qui consiste  se placer entre l'hte metteur et l'hte de
   destination]

   Pour faciliter ceci, OpenSSL propose la commande 'digest' :

 $ openssl dgst upstairs.public
 MD5(upstairs.public)= 78a3bddafb4d681c1ca8ed4d23da4ff1

   La seule chose que nous devons faire est de vrifier que notre partenaire
   distant voit la mme empreinte. Ceci peut tre effectu en se rencontrant
   physiquement, ou par tlphone, en s'assurant que le numro de tlphone
   de l'hte distant n'a pas t envoy dans le mme courrier lectronique
   que celui qui contenait la cl !

   Une autre manire de faire ceci est d'utiliser un tiers de confiance qui
   excute le service d'autorit de certification (Certificate Authority).
   Cette autorit de certification (CA) peut alors signer votre cl ; celle
   que nous avons nous-mme cr au-dessus.

3. tunnels IPSEC

   Jusqu'ici, nous n'avons seulement considr IPSEC dans le mode appel
   'transport' o les points terminaux comprennent directement IPSEC. Comme
   ceci n'est pas souvent le cas, il peut tre ncessaire d'avoir des
   routeurs qui, eux seuls, comprennent IPSEC et qui ralisent le travail
   pour les htes se trouvant derrire eux. Ceci est appel le mode tunnel.

   Configurer ceci est trs rapide. Pour tunneler tout le trafic vers
   130.161.0.0/16  partir de 10.0.0.216 via 10.0.0.11, nous ditons ce qui
   suit sur 10.0.0.216 :

 #!/sbin/setkey -f
 flush;
 spdflush;

 add 10.0.0.216 10.0.0.11 esp 34501
         -m tunnel
         -E 3des-cbc "123456789012123456789012";

 spdadd 10.0.0.0/24 130.161.0.0/16 any -P out ipsec
            esp/tunnel/10.0.0.216-10.0.0.11/require;

   Notez que l'option '-m tunnel' est vitale ! Ceci configure tout d'abord
   une Association de Scurit ESP entre les points terminaux de notre
   tunnel,  savoir 10.0.0.216 et 10.0.0.11.

   Nous allons ensuite rellement configurer le tunnel. On doit indiquer au
   noyau d'encrypter tout le trafic de 10.0.0.0/24 vers 130.161.0.0. De plus,
   ce trafic doit tre envoy vers 10.0.0.11.

   10.0.0.11 a galement besoin d'tre configur :

 #!/sbin/setkey -f
 flush;
 spdflush;

 add 10.0.0.216 10.0.0.11 esp 34501
         -m tunnel
         -E 3des-cbc "123456789012123456789012";

 spdadd 10.0.0.0/24 130.161.0.0/16 any -P in ipsec
            esp/tunnel/10.0.0.216-10.0.0.11/require;

   Notez que ceci est exactement identique,  l'exception du changement de
   '-P out' en '-P in'. Les exemples prcdents n'ont configur le trafic que
   dans un seul sens. Il est laiss comme exercice au lecteur le soin de
   complter l'autre moiti du tunnel.

   Le nom de 'proxy ESP' est galement donn pour cette configuration, ce qui
   est un peu plus clair.

   [7][Note] Note
             Le tunnel IPSEC a besoin d'avoir la transmission IP active dans
             le noyau !

4. Autre logiciel IPSEC

   Thomas Walpuski prcise qu'il a crit une mise  jour pour que OpenBSD
   isakpmd puisse fonctionner avec Linux 2.5 IPSEC. De plus, la repository
   principale CVS de isakpmd contient maintenant le code ! Des notes sont
   disponibles sur cette page
   [http://bender.thinknerd.de/~thomas/IPsec/isakmpd-linux.html].

   isakpmd est diffrent de racoon mentionn au-dessus, mais de nombreuses
   personnes l'apprcient. Il peut tre trouv ici
   [http://www.openbsd.org/cgi-bin/cvsweb/src/sbin/isakmpd/]. D'autres
   lments de lecture sur le CVS d'OpenBSD ici
   [http://www.openbsd.org/anoncvs.html]. Thomas a galement cr un tarball
   [http://bender.thinknerd.de/~thomas/IPsec/isakmpd.tgz] pour ceux qui ne
   sont pas habitus  CVS ou patch.

   De plus, des mises  jour sont disponibles pour permettre aux outils
   FreeS/WAN de l'espace utilisateur de fonctionner avec l'IPSEC natif de
   Linux 2.5. Vous pourrez les trouver ici
   [http://gondor.apana.org.au/~herbert/freeswan/].

5. Interoprabilit d'IPSEC avec d'autres systmes

   FIXME: Ecrire ceci

  5.1. Windows

   Andreas Jellinghaus <aj@dungeon.inka.de> rapporte : "win2k: cela marche.
   pr-partage de cl et l'adresse ip pour l'authentification (je ne pense
   pas que windows supporte fdqn ou userfdqn). Les certificats devraient
   galement marcher, mais cela n'a pas t essay.

  5.2.  Check Point VPN-1 NG

   Peter Bieringer rapporte :

 Voici des rsultats (seul le mode tunnel a t test,
          auth=SHA1) :
  DES:     ok
  3DES:    ok
  AES-128: ok
  AES-192: non support par CP VPN-1
  AES-256: ok
  CAST* :  non support par le noyau Linux utilis

  Version Teste : FP4 aka R54 aka w/AI

   Plus d'informations ici
   [http://www.fw-1.de/aerasec/ng/vpn-racoon/CP-VPN1-NG-Linux-racoon.html].

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

   Table des matires

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

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

                2.1. pfifo_fast

                2.2. Filtre  seau de jetons (Token Bucket Filter)

                2.3. Mise en file d'attente stochastiquement quitable
                (Stochastic Fairness Queueing)

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

   4. terminologie

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

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

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

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

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

                5.5. Seau de jetons  contrle hirarchique (Hierarchical
                Token Bucket)

   6. Classifier des paquets avec des filtres

                6.1. Quelques exemples simples de filtrage

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

   7. Le priphrique de file d'attente intermdiaire (The Intermediate
   queueing device (IMQ))

                7.1. Configuration simple

   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 (octet/s) et b (octet).

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


 1Mbit = 1024 Kbit = 1024 * 1024 bps => octets/s

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.

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.

  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.

    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 !

  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.

    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).

    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.

  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 !

    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 !

    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.

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
       faites, 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 !

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
   [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 (qdisc) (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. Certaines de ces classes
           contiennent 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 bas sur les classes
           peut avoir beaucoup de classes, chacune d'elles tant internes au
           gestionnaire. Une classe peut  son tour se voir ajouter plusieurs
           classes. Une classe peut donc avoir comme parent soit un
           gestionnaire de mise en file d'attente, soit une autre classe. Une
           classe terminale est une classe qui ne possde de classes enfants.
           Seul 1 gestionnaire de mise en file d'attente est attach  cette
           classe. Ce gestionnaire est responsable de l'envoi des donnes de
           cette classe. Quand vous crez une classe, un gestionnaire de mise
           en file d'attente fifo est cr. Quand vous ajoutez une classe
           enfant, ce gestionnaire est supprim. Le gestionnaire fifo d'une
           classe terminale peut tre remplac par un autre gestionnaire plus
           adapt. Vous pouvez mme remplacer ce gestionnaire fifo par un
           gestionnaire de mise en file d'attente bas sur des classes de
           sorte que vous pourrez rajouter des classes supplmentaires.

   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
   lments 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.

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.

  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 lments
   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.

  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
   et classe est 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 : <major>:<minor>. 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. Le nombre
   majeur doit tre unique  l'intrieur d'une configuration egress ou
   ingress. Le nombre mineur doit tre unique  l'intrieur d'un gestionnaire
   de mise en file d'attente et de ses classes.

    5.2.1. Comment les filtres sont utiliss pour classifier le trafic

   Pour rcapituler, une hirarchie typique pourrait ressembler  ceci :

                      1:   Gestionnaire de mise en file d'attente racine
                       |
                      1:1    classe enfant
                    /  |  \
                   /   |   \
                  /    |    \
                  /    |    \
               1:10  1:11  1:12   classes enfants
                |      |     |
                |     11:    |    classe terminale
                |            |
                10:         12:   Gestionnaire de mise en file d'attente
               /   \       /   \
            10:1  10:2   12:1  12:2   classes terminales

   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.

    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.

  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 seulement aux options du champ TOS. Vous pouvez
   galement ajouter un autre gestionnaire de mise en file d'attente aux
   trois classes prdfinies, tandis que pfifo_fast est limit aux simples
   gestionnaires 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.

    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 ...

    5.3.2. Configuration simple

   Nous allons crer cet arbre :

      racine 1: prio
           1:   Gestionnaire racine
          / | \
        /   |   \
        /   |   \
      1:1  1:2  1:3    classes
       |    |    |
      10:  20:  30:    gestionnaire gestionnaire
      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.

  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.

    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.

    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 valeurs
   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 numros.

   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 leves 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 !

    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 soeurs. 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.

    5.4.4. Configuration simple

                1:           gestionnaire de mise en file d'attente racine
                |
               1:1           classe enfant
              /   \
             /     \
           1:3     1:4       classes terminales
            |       |
           30:     40:       gestionnares de mise en file d'attente
          (sfq)   (sfq)

   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:1 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 gestionnaire de mise en file d'attente parent !

 # 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.

    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-gestionnaires 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 ET 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.

  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
   [http://luxik.cdi.cz/~devik/qos/htb/].

   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 ! HTB3 (voir sa page principale
   [http://luxik.cdi.cz/~devik/qos/htb/] pour les dtails des versions HTB)
   fait maintenant parti des sources officielles du noyau ( partir des
   versions 2.4.20-pre1 et 2.5.31 et suprieures). Il est encore cependant
   possible que vous soyez oblig de rcuprer la version mise  jour de 'tc'
   pour HTB3. Les programmes de l'espace utilisateur et la partie HTB du
   noyau doivent avoir le mme numro majeur. Sans cela, 'tc' ne marchera pas
   avec HTB.

   Si vous avez dj un noyau rcent ou si vous tes sur le point de mettre 
   jour votre noyau, considrez HTB cote que cote.

    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.

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 :

                    racine 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 !

  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

  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 et 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 ou iptables 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.

7. Le priphrique de file d'attente intermdiaire (The Intermediate queueing
device (IMQ))

   Le priphrique IMQ n'est pas un gestionnaire de mise en file d'attente
   mais son utilisation est fortement lie  ceux-ci. Au coeur de Linux, les
   gestionnaires de mise en file d'attente sont attachs aux priphriques
   rseaux et tout ce qui est mis en file d'attente dans ce priphrique
   l'est d'abord dans le gestionnaire. Avec ce concept, il existe deux
   limitations :

   1. Seule la mise en forme du trafic sortant est possible (un gestionnaire
   d'entre existe, mais ses possibilits sont trs limites en comparaison
   des gestionnaires de mise en file bass sur les classes).

   2. Un gestionnaire de mise en file d'attente ne voit le trafic que d'une
   interface, et des limitations globales ne peuvent pas tre mises en place.

   IMQ est ici pour aider  rsoudre ces deux limitations. En rsum, vous
   pouvez mettre tout ce que vous voulez dans un gestionnaire de mise en file
   d'attente. Les paquets spcialement marqus sont intercepts par les
   points d'accroche netfilter NF_IP_PRE_ROUTING et NF_IP_POST_ROUTING et
   sont transfrs vers le gestionnaire attach au priphrique imq. Une
   cible iptables est utilise pour le marquage des paquets.

   Ceci vous permet de raliser de la mise en forme d'entre tant donn que
   vous pouvez marquer les paquets entrant par un priphrique quelconque
   et/ou traiter les interfaces comme des classes pour configurer des limites
   globales. Vous pouvez galement raliser de nombreuses autres choses comme
   simplement mettre votre trafic http dans un gestionnaire, mettre les
   requtes de nouvelles connexions dans un gestionnaire, ...

  7.1. Configuration simple

   La premire chose qui devrait vous venir  l'esprit est d'utiliser la mise
   en forme du trafic entrant pour vous garantir une grande passante. ;) La
   configuration se fait comme avec n'importe quelle autre interface :

 tc qdisc add dev imq0 root handle 1: htb default 20

 tc class add dev imq0 parent 1: classid 1:1 htb rate 2mbit burst 15k

 tc class add dev imq0 parent 1:1 classid 1:10 htb rate 1mbit
 tc class add dev imq0 parent 1:1 classid 1:20 htb rate 1mbit

 tc qdisc add dev imq0 parent 1:10 handle 10: pfifo
 tc qdisc add dev imq0 parent 1:20 handle 20: sfq

 tc filter add dev imq0 parent 10:0 protocol ip prio 1 u32 match \
                 ip dst 10.0.0.230/32 flowid 1:10

   Dans cet exemple, u32 est utilis pour la classification. Les autres
   classificateurs devraient marcher tout aussi bien. Le trafic doit ensuite
   tre slectionn et marqu pour tre mis en file d'attente vers imq0.

 iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0

 ip link set imq0 up

   Les cibles iptables IMQ sont valides dans les chanes PREROUTING et
   POSTROUTING de la table mangle. La syntaxe est la suivante :

 IMQ [ --todev n ]   n : numro du priphrique imq

   Il existe aussi une cible ip6tables.

   Notez que le trafic n'est pas mis en file d'attente quand la cible est
   active, mais aprs. La localisation exacte de l'entre du trafic dans le
   priphrique imq dpend de la direction de ce trafic (entrant/sortant).
   Ces entres sont les points d'accroche prdfinis de netfilter et utiliss
   par iptables :

 enum nf_ip_hook_priorities {
         NF_IP_PRI_FIRST = INT_MIN,
         NF_IP_PRI_CONNTRACK = -200,
         NF_IP_PRI_MANGLE = -150,
         NF_IP_PRI_NAT_DST = -100,
         NF_IP_PRI_FILTER = 0,
         NF_IP_PRI_NAT_SRC = 100,
         NF_IP_PRI_LAST = INT_MAX,
 };

   Pour le trafic entrant, imq se dclare avec la priorit NF_IP_PRI_MANGLE +
   1, ce qui signifie que les paquets entrent dans le priphrique imq juste
   aprs la chaine PREROUTING de la table mangle.

   Pour le trafic sortant, imq utilise NF_IP_PRI_LAST qui honore le fait que
   les paquets rejets par la table filter n'occuperont pas de bande
   passante.

   Les mises  jour et de plus amples informations peuvent tre trouves sur
   le site imq [http://luxik.cdi.cz/~patrick/imq/].

Chapitre 10. quilibrage de charge sur plusieurs interfaces

   Table des matires

   1. Avertissement

   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 apparaissent 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.

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 rejetteront les paquets
   destins  des adresses autres que les leurs :

 # echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
 # echo 0 > /proc/sys/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 recevra 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
   [http://netfilter.samba.org/unreliable-guides/]. Le logiciel Netfilter
   peut tre trouv ici [http://netfilter.filewatcher.org/].

   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
   traduction 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
   [http://lists.samba.org/pipermail/netfilter/2000-November/006089.html].

   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 5,  Cache web transparent utilisant netfilter,
   iproute2, ipchains et squid  dans le chapitre Recettes de cuisine.

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

   Table des matires

   1. Le classificateur u32

                1.1. Le slecteur U32

                1.2. Slecteurs gnraux

                1.3. Les slecteurs spcifiques

   2. Le classificateur route

   3. Les filtres de rglementation (Policing filters)

                3.1. Techniques de rglementation

                3.2. Actions de dpassement de limite (Overlimit actions)

                3.3. Exemples

   4. Filtres hachs pour un filtrage massif trs rapide

   5. Filtrer le trafic IPv6

                5.1. Comment se fait-il que ces filtres tc IPv6 ne
                fonctionnent pas ?

                5.2. Marquer les paquets IPv6 en utilisant ip6tables

                5.3. Utiliser le slecteur u32 pour reprer le paquet IPv6

   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
           [http://www.isi.edu/div7/rsvp/overview.html]. 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.

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.

  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.

  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.

   Correspond  tous les paquets TCP ayant le bit ACK activ :

 # tc filter add dev ppp14 parent 1:0 prio 10 u32 \
      match ip protocol 6 0xff \
      match u8 0x10 0xff at nexthdr+13 \
      flowid 1:3

   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'en-tte 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.

   Le filtre ci dessous est une version modifie du filtre prsent
   au-dessus. La diffrence est qu'il ne vrifie pas la longueur de l'en-tte
   ip. Pourquoi ? Car le filtre au-dessus ne marche que sur les systmes 32
   bits.

 tc filter add dev ppp14 parent 1:0 protocol ip prio 10 u32 \
       match ip protocol 6 0xff \
       match u8 0x10 0xff at nexthdr+13 \
       match u16 0x0000 0xffc0 at 2 \
       flowid 1:3

  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 dport 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 dport 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 dport 53 0xffff \
         match ip protocol 0x6 0xff \
         flowid 1:2

2. Le classificateur route

   Ce classificateur filtre en se basant sur les informations des tables de
   routage. Quand un paquet passant  travers les classes et 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.

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.

  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.

    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.

    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.

  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.

  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.

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 !

5. Filtrer le trafic IPv6

  5.1. Comment se fait-il que ces filtres tc IPv6 ne fonctionnent pas ?

   La base de donnes des politiques de routage (RPDB) a remplac le routage
   IPv4 et la structure d'adressage  l'intrieur du noyau Linux, ce qui a
   permis les merveilleuses fonctionnalits dcrites dans ce HOWTO.
   Malheureusement, la pile IPv6  l'intrieur de Linux a t implmente en
   dehors de cette structure principale. Bien qu'ils partagent des
   fonctionnalits, la structure RPDB de base ne participe pas dans ou avec
   les structures d'adressage et de routage de IPv6.

   Ceci va srement changer, nous devons juste attendre un peu plus
   longtemps.

   FIXME : Des ides sur des personnes travaillant sur ce sujet ?
   Planifications ?

  5.2. Marquer les paquets IPv6 en utilisant ip6tables

   ip6tables est capable de marquer un paquet et de lui assigner un numro :

  # ip6tables -A PREROUTING -i eth0 -t mangle -p tcp -j MARK --mark 1


   Ceci ne va cependant pas nous aider dans la mesure o le paquet ne passera
   pas par la structure RPDB.

  5.3. Utiliser le slecteur u32 pour reprer le paquet IPv6

   IPv6 est normalement encapsul dans un tunnel SIT et transport  travers
   les rseaux IPv4. Voir la section sur le tunnel IPv6 pour de plus amples
   informations quant  la configuration d'un tel tunnel. Ceci nous permet de
   filtrer les paquets IPv4 en considrant les paquets IPv6 comme la charge
   utile.

   Le filtre suivant repre tous les paquets IPv6 encapsuls dans des paquets
   IPv4 :

 # tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
              match ip protocol 41 0xff flowid 42:42

   Continuons. Supposons que les paquets IPv6 soient envoys grce  des
   paquets IPv4 et que ces paquets n'ont pas d'options. On pourrait utiliser
   le filtre suivant pour reprer ICMPv6 dans IPv6 dans IPv4 n'ayant aucune
   option. 0x3a (58) est le type du champ en-tte suivant pour ICMPv6.

 # tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
             match ip protocol 41 0xff \
             match u8 0x05 0x0f at 0 \
             match u8 0x3a 0xff at 26 \
             flowid 42:42

   Reprer l'adresse de destination IPv6 ncessite un peu plus de travail. Le
   filtre suivant repre l'adresse de destination
   3ffe:202c:ffff:32:230:4fff:fe08:358d:

 # tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
              match ip protocol 41 0xff \
              match u8 0x05 0x0f at 0 \
              match u8 0x3f 0xff at 44 \
              match u8 0xfe 0xff at 45 \
              match u8 0x20 0xff at 46 \
              match u8 0x2c 0xff at 47 \
              match u8 0xff 0xff at 48 \
              match u8 0xff 0xff at 49 \
              match u8 0x00 0xff at 50 \
              match u8 0x32 0xff at 51 \
              match u8 0x02 0xff at 52 \
              match u8 0x30 0xff at 53 \
              match u8 0x4f 0xff at 54 \
              match u8 0xff 0xff at 55 \
              match u8 0xfe 0xff at 56 \
              match u8 0x08 0xff at 57 \
              match u8 0x35 0xff at 58 \
              match u8 0x8d 0xff at 59 \
              flowid 10:13

   La mme technique peut tre utilise pour reprer les rseaux. Par exemple
   2001::

 # tc filter add dev $DEV parent 10:0 protocol ip prio 10 u32 \
              match ip protocol 41 0xff \
              match u8 0x05 0x0f at 0 \
              match u8 0x20 0xff at 28 \
              match u8 0x01 0xff at 29 \
              flowid 10:13

Chapitre 13. Paramtres rseau du noyau

   Table des matires

   1. Filtrage de Chemin Inverse (Reverse Path Filtering)

   2. Configurations obscures

                2.1. ipv4 gnrique

                2.2. Configuration des priphriques

                2.3. Politique de voisinage

                2.4. Configuration du routage

   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.

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

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.

   Oskar Andreasson a une page sur ces options et il apparat qu'elle soit
   meilleure que la notre. De ce fait, allez galement voir
   http://ipsysctl-tutorial.frozentux.net/
   [http://ipsysctl-tutorial.frozentux.net/].

  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 incrmente  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 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
           rejettera 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 senss 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 [http://www.ietf.org/rfc/rfc1122.txt] 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.

  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, puisque 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

  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.

  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
           [http://mailman.ds9a.nl/pipermail/lartc/2002q1/002667.html] 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

   Table des matires

   1. bfifo/pfifo

                1.1. Paramtres & usage

   2. Algorithme Clark-Shenker-Zhang (CSZ)

   3. DSMARK

                3.1. Introduction

                3.2. A quoi DSMARK est-il reli ?

                3.3. Guide des services diffrencis

                3.4. Travailler avec DSMARK

                3.5. Comment SCH_DSMARK travaille.

                3.6. Le filtre TC_INDEX

   4. Gestionnaire de mise en file d'attente d'entre (Ingress qdisc)

                4.1. Paramtres & usage

   5. Random Early Detection (RED)

   6. Generic Random Early Detection

   7. Emulation VC/ATM

   8. Weighted Round Robin (WRR)

   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.

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.

  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.

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.

3. DSMARK

   Rsum

   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 :

     * [8]Draft-almesberger-wajhak-diffserv-linux-01.txt.

     * Exemples de la distribution iproute2.

     * White Paper-QoS protocols and architectures
       [http://www.qosforum.com/white-papers/qosprot_v3.pdf] et Foires Aux
       Questions IP QoS [http://www.qosforum.com/docs/faq], les deux par
       Quality of Service Forum.

  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
   [http://www.ietf.org/html.charters/diffserv-charter.html] et sur le site
   web de Werner Almesberger [http://diffserv.sf.net/] (Il a crit le code
   permettant le support des Services Diffrencis sous Linux).

  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.

  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 :-).

  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.

  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    |     |  <-----Peut 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 couples
      v            |         v                v       |                    (masque,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 utilis dans des configurations autres que celles incluant les
   services DS.

  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.

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.

  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.

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
   [http://www.aciri.org/floyd/papers/red/red.html] par Sally Floyd et Van
   Jacobson pour les informations techniques.

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
   [http://www.davin.ottawa.on.ca/ols/img22.htm], 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

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
   [http://linux-atm.sourceforge.net/].

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 ce lien
   [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 poids 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

   Table des matires

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

   2. Protger votre machine des inondations SYN

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

   4. Donner la priorit au trafic interactif

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

                5.1. Schma du trafic aprs l'implmentation

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

                6.1. Solution

   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)

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

                8.1. Pourquoi cela ne marche t-il pas bien par dfaut ?

                8.2. Le script (CBQ)

                8.3. Le script (HTB)

   9. Limitation du dbit pour un hte ou un masque de sous-rseau

   10. Exemple d'une solution de traduction d'adresse avec de la QoS

                10.1. Commenons l'optimisation de cette rare bande passante

                10.2. Classification des paquets

                10.3. Amliorer notre configuration

                10.4. Rendre tout ceci actif au dmarrage

   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.

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 ?

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

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

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

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 [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 set 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-|
 |------|



  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

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.

  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 traduction 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

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) implmentent 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.

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.

  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' l'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 de 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 soyez 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 rejeter les paquets qui
           arrivent trop vite, ce qui provoque le ralentissement de TCP/IP
           jusqu'au dbit dsir. Comme 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 tlchargement vers l'aval :
 round-trip min/avg/max = 560.9/573.6/586.4 ms

 Sans le conditionneur de trafic, lors d'un tlchargement vers l'amont :
 round-trip min/avg/max = 2041.4/2332.1/2427.6 ms

 Avec le conditionneur, lors d'un tlchargement vers l'amont  220kbit/s :
 round-trip min/avg/max = 15.7/51.8/79.9 ms

 Avec le conditionneur, lors d'un tlchargement 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'effectuent  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 a. 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.

  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 relle 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 !

  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 !

9. Limitation du dbit pour un hte ou un masque de sous-rseau

   Bien que ceci soit dcrit en dtail ailleurs et dans nos pages de manuel,
   cette question est souvent pose. Heureusement, il y a une rponse simple
   qui ne ncessite pas la comprhension complte du contrle de trafic.

   Ce script de trois lignes met en place la limitation du dbit :

 tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit

 tc class add dev $DEV parent 1: classid 1:1 cbq rate 512kbit \
    allot 1500 prio 5 bounded isolated

 tc filter add dev $DEV parent 1: protocol ip prio 16 u32 \
    match ip dst 195.96.96.97 flowid 1:1

   La premire ligne installe un gestionnaire de mise en file d'attente bas
   sur des classes sur votre interface, et indique au noyau que, pour ses
   calculs, il peut la considrer comme une interface  10 Mbits/s.
   Cependant, il n'y aura pas de grands dommages si vous indiquez une valeur
   errone. Donner la vraie valeur permettra d'avoir des choses plus
   prcises.

   La seconde ligne cre une classe de 512kbit/s avec des valeurs par dfaut
   raisonnables. Pour les dtails, voir les pages de manuel cbq et
   Chapitre 9, Gestionnaires de mise en file d'attente pour l'administration
   de la bande passante.

   La dernire ligne indique quel trafic devra passer par la classe ralisant
   la mise en forme. Le trafic qui n'est slectionn par cette rgle n'est
   PAS mis en forme. Pour avoir des slections plus compliques
   (sous-rseaux, ports sources ou de destinations), voir Section 6.2,
    Toutes les commandes de filtres dont vous aurez normalement besoin .

   Si vous avez chang quelque chose et que vous vouliez recharger le script,
   excutez la commande tc qdisc del dev $DEV root pour supprimer votre
   configuration actuelle.

   Le script peut tre amlior en ajoutant une dernire ligne optionnelle tc
   qdisc add dev $DEV parent 1:1 sfq perturb 10. Voir Section 2.3,  Mise en
   file d'attente stochastiquement quitable (Stochastic Fairness Queueing) 
   pour savoir ce que cela fait.

10. Exemple d'une solution de traduction d'adresse avec de la QoS

   Je m'appelle Pedro Larroy

   <piotr%member.fsf.org>

   . Je dcris ici une configuration dans le cas o de nombreux utilisateurs
   seraient connects  Internet  travers un routeur Linux qui possde une
   adresse publique et qui ralise de la traduction d'adresse (NAT).
   J'utilise cette configuration QoS pour fournir l'accs  198 utilisateurs
   dans une cit universitaire dans laquelle je vis et o j'administre le
   rseau. Les utilisateurs sont de gros consommateurs de programmes "peer to
   peer" et un contrle de trafic correct est ncessaire. J'espre que ceci
   servira d'exemples pratiques  tous les lecteurs intresss par le lartc.

   Dans un premier temps, la configuration sera ralise pas  pas et,  la
   fin, j'expliquerai comment rendre ce processus automatique au dmarrage.
   Le rseau utilis pour cet exemple est un rseau local connect  Internet
    travers un routeur Linux ayant une adresse publique. L'ajout d'un
   ensemble de rgles iptables permettrait facilement l'extension  plusieurs
   adresses IP publiques. Les lments suivants sont ncessaires :

   Linux 2.4.18 ou une version du noyau suprieure installe

           Si vous utilisez le noyau 2.4.18, vous devrez appliquer la mise 
           jour HTB.

   iproute

           Soyez galement sr que le binaire "tc" est compatible avec HTB.
           Un binaire pr compil est distribu avec HTB.

   iptables

  10.1. Commenons l'optimisation de cette rare bande passante

   Tout d'abord, nous allons configurer des gestionnaires de mise en file
   d'attente dans lesquels nous allons classifier le trafic. Nous crons un
   gestionnaire htb compos de 6 classes avec des priorits croissantes. Nous
   avons alors des classes qui obtiendront le dbit allou et qui pourront,
   de plus, utiliser la bande passante dont les autres classes n'ont pas
   besoin. Rappelons que les classes de plus hautes priorits (correspondant
   aux nombres prio les plus faibles) obtiendront en premier l'excs de bande
   passante. Notre liaison ADSL  un flux descendant de 2Mbits/s et un flux
   montant de 300 kbits/s. J'utilise un dbit de seuil (ceil rate) de 240
   kbits/s car, au-del de cette limite, les problmes de latence commence 
   prendre de l'ampleur. Ceci est d au remplissage d'un tampon plac quelque
   part entre nous et les htes distants.

   Ajuster la variable CEIL  75% de votre bande passante montante maximum et
   ajuster le nom de l'interface (eth0 dans la suite)  celle qui a l'adresse
   publique Internet. Excutez ce qui suit dans un shell root :

 CEIL=240
 tc qdisc add dev eth0 root handle 1: htb default 15
 tc class add dev eth0 parent 1: classid 1:1 htb rate ${CEIL}kbit ceil ${CEIL}kbit
 tc class add dev eth0 parent 1:1 classid 1:10 htb rate 80kbit ceil 80kbit prio 0
 tc class add dev eth0 parent 1:1 classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1
 tc class add dev eth0 parent 1:1 classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2
 tc class add dev eth0 parent 1:1 classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2
 tc class add dev eth0 parent 1:1 classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3
 tc class add dev eth0 parent 1:1 classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3
 tc qdisc add dev eth0 parent 1:12 handle 120: sfq perturb 10
 tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
 tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
 tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

   Nous avons juste cr une arborescence htb avec un seul niveau de
   profondeur. Quelque chose comme ceci :

 +-----------+
                         | racine 1: |
                         +-----------+
                              |
                         +---------------------------------------+
                         | classe 1:1                            |
                         +---------------------------------------+
                           |      |      |      |      |      |
                         +----+ +----+ +----+ +----+ +----+ +----+
                         |1:10| |1:11| |1:12| |1:13| |1:14| |1:15|
                         +----+ +----+ +----+ +----+ +----+ +----+


   classid 1:10 htb rate 80kbit ceil 80kbit prio 0

           Ceci est la classe de priorit la plus leve. Les paquets de
           cette classe auront le plus faible dlai et obtiendront en premier
           l'excs de bande passante. C'est donc une bonne ide de limiter le
           dbit de seuil de cette classe. Nous enverrons dans cette classe
           les paquets qui ont un avantage  avoir un faible dlai, tel que
           le trafic interactif : ssh, telnet, dns, quake3, irc, et les
           paquets avec le bit SYN activ.

   classid 1:11 htb rate 80kbit ceil ${CEIL}kbit prio 1

           Nous avons ici la premire classe dans laquelle nous commenons 
           mettre du trafic de masse. Dans mon exemple, j'ai le trafic
           provenant de mon serveur web local et les requtes pour les pages
           web : respectivement le port source 80 et le port destination 80.

   classid 1:12 htb rate 20kbit ceil ${CEIL}kbit prio 2

           Dans cette classe, je mettrai le trafic configur avec le champ
           TOS "Dbit Maximum" activ, ainsi que le reste du trafic provenant
           des processus locaux de mon routeur vers Internet. Les classes
           suivantes ne recevront donc que du trafic rout par cette machine.

   classid 1:13 htb rate 20kbit ceil ${CEIL}kbit prio 2

           Cette classe est pour le trafic des autres machines NATes
           (NdT : bnficiant du service de traduction d'adresse) qui ont
           besoin d'une priorit plus grande dans leur trafic de masse.

   classid 1:14 htb rate 10kbit ceil ${CEIL}kbit prio 3

           Le trafic mail (SMTP, pop3,...) et les paquets configurs avec le
           champ TOS "Cot Minimum" seront envoys dans cette classe.

   classid 1:15 htb rate 30kbit ceil ${CEIL}kbit prio 3

           Finalement, nous avons ici le trafic de masse des machines
           "NATes" se trouvant derrire le routeur. Les paquets lis 
           kazaa, edonkey et autres iront ici pour ne pas interfrer avec les
           autres services.

  10.2. Classification des paquets

   Nous avons configur le gestionnaire de mise en file d'attente, mais
   aucune classification de paquets n'a encore t faite. Pour l'instant,
   tous les paquets sortants passent par la classe 1:15 (car, nous avons
   utilis : tc qdisc add dev eth0 root handle 1: htb default 15). Nous
   devons donc maintenant indiquer o doivent aller les paquets. Ceci est la
   partie la plus importante.

   Nous allons maintenant configurer les filtres de tel sorte que nous
   puissions classifier les paquets avec iptables. Je prfre vraiment le
   faire avec iptables car celui-ci est trs souple et que nous avons un
   compteur de paquets pour chaque rgle. De plus, avec la cible RETURN, les
   paquets n'ont pas besoin de traverser toutes les rgles. Nous excutons
   les commandes suivantes :

 tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
 tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:11
 tc filter add dev eth0 parent 1:0 protocol ip prio 3 handle 3 fw classid 1:12
 tc filter add dev eth0 parent 1:0 protocol ip prio 4 handle 4 fw classid 1:13
 tc filter add dev eth0 parent 1:0 protocol ip prio 5 handle 5 fw classid 1:14
 tc filter add dev eth0 parent 1:0 protocol ip prio 6 handle 6 fw classid 1:15

   Nous indiquons simplement au noyau que les paquets qui ont une valeur
   FWMARK spcifique (handle x fw) vont dans la classe spcifie (classid
   x:x). Voyons maintenant comment marquer les paquets avec iptables.

   Tout d'abord, nous devons comprendre comment les paquets traversent les
   filtres avec iptables :

         +------------+                +---------+               +-------------+
 Paquets-| PREROUTING |--- Dcision----| FORWARD |-------+-------| POSTROUTING |- Paquets
 entrant +------------+   de routage   +--------+       |       +-------------+  sortants
                              |                          |
                         +-------+                    +--------+
                         | INPUT |-- Processus locaux-| OUTPUT |
                         +-------+                    +--------+

   Je suppose que toutes vos tables ont leur politique par dfaut configure
    ACCEPT (-P ACCEPT), ce qui devrait tre le cas si vous n'avez pas encore
   touch  iptables. Notre rseau priv est une classe B avec l'adresse
   172.17.0.0/16 et notre adresse publique est 212.170.21.172.

   Nous indiquons au noyau de faire de la traduction d'adresse NAT; les
   clients du rseau priv peuvent alors commencer  dialoguer avec
   l'extrieur.

                         echo 1 > /proc/sys/net/ipv4/ip_forward
                         iptables -t nat -A POSTROUTING -s 172.17.0.0/255.255.0.0 -o eth0 -j SNAT --to-source 212.170.21.172


   Vrifions maintenant que les paquets transitent bien  travers 1:15 :

                         tc -s class show dev eth0


   Vous pouvez commencer  marquer les paquets en ajoutant les rgles dans la
   chane PREROUTING de la table mangle.

 iptables -t mangle -A PREROUTING -p icmp -j MARK --set-mark 0x1
 iptables -t mangle -A PREROUTING -p icmp -j RETURN

   Vous devriez maintenant tre capable de voir l'volution du compteur de
   paquets quand vous pinguez des sites sur Internet depuis les machines du
   rseau priv. Vrifiez que le compteur de paquets augmente dans 1:10 :

 tc -s class show dev eth0

   Nous avons mis -j RETURN de manire  ce que les paquets ne traversent pas
   toutes les rgles. Les paquets icmp ne scruteront pas les autres rgles
   dfinies sous RETURN. Gardez ceci  l'esprit. Nous commenons maintenant 
   ajouter d'autres rgles pour grer les champs TOS :

 iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j MARK --set-mark 0x1
 iptables -t mangle -A PREROUTING -m tos --tos Minimize-Delay -j RETURN
 iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j MARK --set-mark 0x5
 iptables -t mangle -A PREROUTING -m tos --tos Minimize-Cost -j RETURN
 iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j MARK --set-mark 0x6
 iptables -t mangle -A PREROUTING -m tos --tos Maximize-Throughput -j RETURN

   Donnons la priorit aux paquets SSH :

 iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j MARK --set-mark 0x1
 iptables -t mangle -A PREROUTING -p tcp -m tcp --sport 22 -j RETURN

   Une bonne ide est de donner la priorit aux paquets initiant une
   connexion tcp,  savoir ceux qui ont le bit SYN activ :

 iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j MARK --set-mark 0x1
 iptables -t mangle -I PREROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j RETURN

   Et ainsi de suite. Aprs la mise en place des rgles dans la chane
   PREROUTING de la table "mangle", nous terminons par :

 iptables -t mangle -A PREROUTING -j MARK --set-mark 0x6

   Ainsi, le trafic non marqu est dirig vers 1:15. En fait, cette dernire
   tape n'est pas ncessaire puisque la classe par dfaut est 1:15. Un
   marquage est quand mme ralis de manire  avoir une cohrence pour
   l'ensemble de la configuration. De plus, il est utile d'avoir une
   comptabilit pour cette rgle.

   C'est une bonne ide de faire de mme avec la chane OUTPUT. Rptez ces
   commandes avec -A OUTPUT  la place de PREROUTING (s/PREROUTING/OUTPUT/).
   Le trafic gnr localement (sur le routeur Linux) sera alors galement
   classifi. Je termine la chane OUTPUT par -j MARK --set-mark 0x3 de tel
   sorte que le trafic local ait une priorit plus grande.

  10.3. Amliorer notre configuration

   Toute notre configuration est maintenant oprationnelle. Prenez du temps
   pour regarder les graphes et observer o votre bande passante est la plus
   utilise et cela correspond  vos souhaits. J'ai fait ceci pendant de
   nombreuses heures, ce qui m'a permis d'avoir une connexion Internet
   fonctionnant trs bien. Autrement, vous serez confront en permanence 
   des "timeout" et des allocations de bande passante presque nulles pour les
   nouvelles connexions tcp.

   Si vous reprez des classes qui sont pleines la plupart du temps, ce peut
   tre une bonne ide de leur attacher un autre gestionnaire de mise en file
   d'attente de manire  ce que le partage de la bande passante soit plus
   quitable :

 tc qdisc add dev eth0 parent 1:13 handle 130: sfq perturb 10
 tc qdisc add dev eth0 parent 1:14 handle 140: sfq perturb 10
 tc qdisc add dev eth0 parent 1:15 handle 150: sfq perturb 10

  10.4. Rendre tout ceci actif au dmarrage

   Il est certain que ceci peut tre fait de diffrentes faons. Dans mon
   cas, j'ai un shell script /etc/init.d/packetfilter qui accepte les
   arguments [start | stop | stop-tables | start-tables | reload-tables].
   Celui-ci configure les gestionnaires de mise en file d'attente et charge
   les modules du noyau ncessaires et se comporte donc comme une dmon. Le
   mme script charge les rgles iptables  partir de
   /etc/network/iptables-rules. Je vais l'embellir un peu et le rendrait
   disponible sur ma page web ici
   [http://omega.resa.es/piotr/files/packetfilter.tar.bz2]

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

   Table des matires

   1. Etat des ponts et iptables

   2. Pont et mise en forme

   3. Pseudo-pont avec du Proxy-ARP

                3.1. ARP & Proxy-ARP

                3.2. Implmentez-le

   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 ('ce rseau est HANTE !). Vous devriez galement vous demander si
   une organisation qui "ne veut rien changer" fait le bon choix.

   Le pont Linux 2.4/2.5 est document sur cette page
   [http://bridge.sourceforge.net/].

1. Etat des ponts et iptables

   Au moment de Linux 2.4.20, 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 traduction d'adresse (NAT), de dsossage ou quoique ce soit
   d'autres. Ceci a t corrig dans les versions 2.5.45 et suprieures.

   Vous devriez galement regarder 'ebtables', qui est encore un autre
   projet. Il vous permettra de faire des choses vraiment terribles comme
   MACNAT et 'brouting'. C'est vraiment effroyable.

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.

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.

  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.

  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

   Table des matires

   1. Configurer OSPF avec Zebra

                1.1. Prrequis

                1.2. Configurer Zebra

                1.3. Excuter Zebra

   2. Configurer BGP4 avec Zebra

                2.1. schma rseau (Exemple)

                2.2. Configuration (Exemple)

                2.3. Vrification de la configuration

   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 (RFC 2328) et
   BGP4 (RFC 1771). 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
   [http://www.cisco.com/univercd/cc/td/doc/cisintwk/idg4/nd2003.htm]

   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
   [http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/icsbgp4.htm]

   Bien que les exemples soient spcifiques  Cisco, ils sont remarquablement
   semblables au langage de configuration de Zebra :-)

1. Configurer OSPF avec Zebra

  Pedro Larroy Tovar

   <piotr%member.fsf.org>

   Contactez-moi si les informations qui suivent ne sont pas exactes ou si
   vous avez des suggestions. Zebra [http://www.zebra.org] est un formidable
   logiciel de routage dynamique crit par Kunihiro Ishiguro, Toshiaki Takada
   et Yasuhiro Ohara. Configurer OSPF avec zebra est simple et rapide mais,
   en pratique, il y a de nombreux paramtres dans le cas o vous auriez des
   besoins spcifiques. OSPF est l'abrviation de Open Shortest Path First et
   quelques une de ses fonctionnalits sont :

   hirarchique

           Les rseaux sont regroups par zones (areas), qui sont
           interconnectes par une zone pine dorsale qui sera appele zone
           0. Tout le trafic passe par la zone 0 et tous les routeurs de
           cette zone ont les informations de routage de toutes les autres
           zones.

   convergence rapide

           Les routes sont propages trs rapidement, compar  RIP par
           exemple.

   conomie de bande passante

           Utilise la multi-distribution  la place de la diffusion, ce qui
           vite de submerger les autres htes avec des informations de
           routage sans intrt pour eux. La multi-distribution rduit ainsi
           le dbit sur le rseau. De mme, les routeurs internes (ceux dont
           toutes les interfaces sont situes dans la mme zone) n'obtiennent
           pas d'informations sur les autres zones. Les routeurs avec des
           interfaces dans plus d'une zone sont appels Area Border Routers.
           Ils possdent les informations de topologie sur les zones
           auxquelles ils sont connects.

   Utilisation intensive de CPU

           OSPF est bas sur l'algorithme de Dijkstra Shortest Path First
           [http://www.soi.wide.ad.jp/class/99007/slides/13/07.html], qui est
           coteux en temps de calcul compar aux autres algorithmes de
           routage. Ce n'est pas forcment mauvais, dans la mesure o le plus
           court chemin est calcul uniquement pour chaque zone. Donc, pour
           les rseaux de petite  moyenne taille, ce ne sera pas un problme
           ; vous ne vous en rendrez pas compte.

   Information d'tat de lien

           OSPF prend en compte les caractristiques spcifiques des rseaux
           et interfaces, telles que la bande passante, les dfauts de liens
           et le cot montaire.

   Protocole ouvert et logiciel sous license GPL

           OSPF est un protocole ouvert et Zebra est un logiciel sous license
           GPL, ce qui reprsente un avantage vident par rapport aux
           protocoles et logiciels propritaires.

  1.1. Prrequis

   Noyau Linux :

           Compil avec CONFIG_NETLINK_DEV and CONFIG_IP_MULTICAST (Je ne
           sais pas si d'autres lments sont galement ncessaires).

   Iproute

   Zebra

           Rcuprez-le avec votre gestionnaire de paquet favori ou  partir
           de http://www.zebra.org [http://www.zebra.org].

  1.2. Configurer Zebra

   Prenons le rseau suivant comme exemple :

                         ----------------------------------------------------
                         | 192.168.0.0/24                                   |
                         |                                                  |
                         |      Zone 0    100BaseTX Commut                 |
                         |     Epine dorsale     Ethernet                   |
                         ----------------------------------------------------
                           |           |                |              |
                           |           |                |              |
                           |eth1       |eth1            |eth0          |
                           |100BaseTX  |100BaseTX       |100BaseTX     |100BaseTX
                           |.1         |.2              |.253          |
                          ---------   ------------   -----------      ----------------
                          |R Omega|   |R Atlantis|   |R Legolas|      |R Frodo       |
                          ---------   ------------   -----------      ----------------
                           |eth0         |eth0             |             |          |
                           |             |                 |             |          |
                           |2MbDSL/ATM   |100BaseTX        |10BaseT      |10BaseT   |10BaseT
                         ------------   ------------------------------------       -------------------------------
                         | Internet |   | 172.17.0.0/16        Zone 1      |       | 192.168.1.0/24 wlan  Zone 2 |
                         ------------   |     Rseau etudiant (dortoir)    |       |   Sans fil de Barcelone     |
                                        ------------------------------------       -------------------------------


   Ne soyez pas effray par ce diagramme, Zebra ralise la plus grande partie
   du travail automatiquement ; ce qui ne demandera aucun travail de saisie
   des routes avec Zebra. Il serait pnible de maintenir toutes ces routes 
   la main au quotidien. La chose la plus importante  matriser clairement,
   c'est la topologie du rseau. Faites particulirement attention  la zone
   0, puisque c'est la plus importante. Dans un premier temps, configurez
   Zebra en ditant zebra.conf et en l'adaptant  vos besoins :

 hostname omega
 password xxx
 enable password xxx
 !
 ! Interface's description.
 !
 !interface lo
 ! description test of desc.
 !
 interface eth1
 multicast
 !
 ! Static default route
 !
 ip route 0.0.0.0/0 212.170.21.129
 !
 log file /var/log/zebra/zebra.log

   Debian ncessite galement l'dition de /etc/zebra/daemons pour qu'ils
   soient lancs au dmarrage :

                         zebra=yes
                         ospfd=yes


   Nous devons maintenant editer ospfd.conf si vous utilisez encore IPV4 ou
   ospf6d.conf si vous travaillez avec IPV6. Mon fichier ospfd.conf ressemble
    ceci :

                         hostname omega
                         password xxx
                         enable password xxx
                         !
                         router ospf
                           network 192.168.0.0/24 area 0
                           network 172.17.0.0/16 area 1
                         !
                         ! log stdout
                         log file /var/log/zebra/ospfd.log


   Ceci indique  ospf la topologie de notre rseau.

  1.3. Excuter Zebra

   Nous devons maintenant dmarrer Zebra soit  la main en tapant "zebra -d",
   soit avec un script comme "/etc/init.d/zebra start". En regardant
   attentivement les logs de ospdfd, on peut voir les lments suivants :

 2002/12/13 22:46:24 OSPF: interface 192.168.0.1 join AllSPFRouters Multicast group.
 2002/12/13 22:46:34 OSPF: SMUX_CLOSE with reason: 5
 2002/12/13 22:46:44 OSPF: SMUX_CLOSE with reason: 5
 2002/12/13 22:46:54 OSPF: SMUX_CLOSE with reason: 5
 2002/12/13 22:47:04 OSPF: SMUX_CLOSE with reason: 5
 2002/12/13 22:47:04 OSPF: DR-Election[1st]: Backup 192.168.0.1
 2002/12/13 22:47:04 OSPF: DR-Election[1st]: DR     192.168.0.1
 2002/12/13 22:47:04 OSPF: DR-Election[2nd]: Backup 0.0.0.0
 2002/12/13 22:47:04 OSPF: DR-Election[2nd]: DR     192.168.0.1
 2002/12/13 22:47:04 OSPF: interface 192.168.0.1 join AllDRouters Multicast group.
 2002/12/13 22:47:06 OSPF: DR-Election[1st]: Backup 192.168.0.2
 2002/12/13 22:47:06 OSPF: DR-Election[1st]: DR     192.168.0.1
 2002/12/13 22:47:06 OSPF: Packet[DD]: Negotiation done (Slave).
 2002/12/13 22:47:06 OSPF: nsm_change_status(): scheduling new router-LSA origination
 2002/12/13 22:47:11 OSPF: ospf_intra_add_router: Start

   Ignorez le message SMUX_CLOSE pour l'instant dans la mesure o il concerne
   SNMP. Nous pouvons voir que 192.168.0.1 est routeur dsign (Designated
   Router) et que 192.168.0.2 est le le routeur dsign de sauvegarde (Backup
   Designated Router).

   Nous pouvons galement interagir avec zebra et ospfd en excutant :

 $ telnet localhost zebra
 $ telnet localhost ospfd

   Voyons comment les routes se sont propages en se connectant  zebra :

                         root@atlantis:~# telnet localhost zebra
                         Trying 127.0.0.1...
                         Connected to atlantis.
                         Escape character is '^]'.

                         Hello, this is zebra (version 0.92a).
                         Copyright 1996-2001 Kunihiro Ishiguro.

                         User Access Verification

                         Password:
                         atlantis> show ip route
                         Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
                                B - BGP, > - selected route, * - FIB route

                         K>* 0.0.0.0/0 via 192.168.0.1, eth1
                         C>* 127.0.0.0/8 is directly connected, lo
                         O   172.17.0.0/16 [110/10] is directly connected, eth0, 06:21:53
                         C>* 172.17.0.0/16 is directly connected, eth0
                         O   192.168.0.0/24 [110/10] is directly connected, eth1, 06:21:53
                         C>* 192.168.0.0/24 is directly connected, eth1
                         atlantis> show ip ospf border-routers
                         ============ OSPF router routing table =============
                         R    192.168.0.253         [10] area: (0.0.0.0), ABR
                                                    via 192.168.0.253, eth1
                                                          [10] area: (0.0.0.1), ABR
                                                    via 172.17.0.2, eth0


   ou directement avec iproute :

                         root@omega:~# ip route
                         212.170.21.128/26 dev eth0  proto kernel  scope link  src 212.170.21.172
                         192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.1
                         172.17.0.0/16 via 192.168.0.2 dev eth1  proto zebra  metric 20
                         default via 212.170.21.129 dev eth0  proto zebra
                         root@omega:~#


   Nous pouvons voir les routes Zebra, qui n'taient pas prsentes
   auparavant. Il est vraiment agrable de voir apparatre les routes
   quelques secondes aprs le lancement de zebra et ospfd. Vous pouvez
   vrifier la connectivit avec les autres htes en utilisant ping. Les
   routes zebra sont automatiques. Vous pouvez ajouter un autre routeur au
   rseau, configurez Zebra et voil !

   Astuce : vous pouvez utiliser :

                         tcpdump -i eth1 ip[9] == 89


   pour analyser les paquets OSPF. Le numro du protocole OSPF est 89 et le
   champ du protocole est le 9ime octet de l'en-tte ip.

   OSPF possde de nombreux paramtres, spcialement pour les grands rseaux.
   Dans de prochains dveloppements du HOWTO, nous montrerons des mthodes de
   rglages fins d'OSPF.

2. Configurer BGP4 avec Zebra

   Le Border Gateway Protocol Version 4 (BGP4) est un protocole de routage
   dynamique dcrit dans la RFC 1771. Il permet la distribution des
   informations de connectivit, c'est  dire les tables de routage, vers
   d'autres noeuds BGP4 actifs. Il peut tre utilis comme un EGP ou un IGP.
   Dans le mode EGP, chaque noeud doit avoir son propre numro de systme
   autonome ( utonomous System (AS)). BGP4 supporte ????????? et
   l'aggrgation de routes (runir plusieurs routes en une seule). > The
   Border Gateway Protocol Version 4 (BGP4) is a dynamic routing > protocol
   described in RFC 1771. It allows the distribution of > reachability
   information, i.e. routing tables, to other BGP4 > enabled nodes. It can
   either be used as EGP or IGP, in EGP mode > each node must have its own
   Autonomous System (AS) number. > BGP4 supports Classless Inter Domain
   Routing (CIDR) and route > aggregation (merge multiple routes into one).

  2.1. schma rseau (Exemple)

   Le schma rseau suivant est utilis pour les exemples  suivre. AS 1 et
   50 ont plusieurs voisins mais nous avons seulement besoin de configurer 1
   et 50 comme nos voisins. Les noeuds communiquent entre eux par des tunnels
   dans cet exemple, mais ce n'est pas une obligation.

   Note : les numros AS utiliss dans cet exemple sont rservs. Veuillez
   obtenir vos propres numros AS du RIPE si vous installez des liens
   officiels.


                    --------------------
                    | 192.168.23.12/24 |
                    |    AS: 23        |
                    --------------------
                      /             \
                     /               \
                    /                 \
          ------------------       ------------------
          | 192.168.1.1/24 |-------| 10.10.1.1/16   |
          |    AS: 1       |       |    AS: 50      |
          ------------------       ------------------


  2.2. Configuration (Exemple)

   La configuration suivante est crite pour le noeud 192.168.23.12/24 et
   elle sera facile  adapter pour les autres noeuds.

   Elle commence par des lments gnraux comme le nom de l'hte, les mots
   de passe et les options de debug :

  ! hostname
  hostname anakin

  ! login password
  password xxx

  ! enable password (super user mode)
  enable password xxx

  ! path to logfile
  log file /var/log/zebra/bgpd.log

  ! debugging: be verbose (can be removed afterwards)
  debug bgp events
  debug bgp filters
  debug bgp fsm
  debug bgp keepalives
  debug bgp updates


   La liste de contrle d'accs (Access list) est utilise pour limiter la
   redistribution aux rseaux privs (RFC 1918).

  ! RFC 1918 networks
  access-list local_nets permit 192.168.0.0/16
  access-list local_nets permit 172.16.0.0/12
  access-list local_nets permit 10.0.0.0/8
  access-list local_nets deny any

   L'etape suivante consiste  configurer chaque AS :

  ! Own AS number
  router bgp 23

      ! IP address of the router
      bgp router-id 192.168.23.12

      ! announce our own network to other neighbors
      network 192.168.23.0/24

      ! advertise all connected routes (= directly attached interfaces)
      redistribute connected

      ! advertise kernel routes (= manually inserted routes)
      redistribute kernel

   Chaque section 'router bgp' contient une liste de voisins auquels le
   routeur est connect :

      neighbor 192.168.1.1 remote-as 1
      neighbor 192.168.1.1 distribute-list local_nets in
      neighbor 10.10.1.1   remote-as 50
      neighbor 10.10.1.1   distribute-list local_nets in

  2.3. Vrification de la configuration

   Note : vtysh est un multiplexeur qui connecte toutes les interfaces
   utilisateur de zebra ensemble.

  anakin# sh ip bgp summary
  BGP router identifier 192.168.23.12, local AS number 23
  2 BGP AS-PATH entries
  0 BGP community entries

  Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
  10.10.0.1       4    50      35      40        0    0    0 00:28:40        1
  192.168.1.1     4     1   27574   27644        0    0    0 03:26:04       14

  Total number of neighbors 2
  anakin#
  anakin# sh ip bgp neighbors 10.10.0.1
  BGP neighbor is 10.10.0.1, remote AS 50, local AS 23, external link
    BGP version 4, remote router ID 10.10.0.1
    BGP state = Established, up for 00:29:01
    ....
  anakin#


   Voyons quelles routes nous avons obtenues de nos voisins :

  anakin# sh ip ro bgp
  Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
         B - BGP, > - selected route, * - FIB route

  B>* 172.16.0.0/14 [20/0] via 192.168.1.1, tun0, 2d10h19m
  B>* 172.30.0.0/16 [20/0] via 192.168.1.1, tun0, 10:09:24
  B>* 192.168.5.10/32 [20/0] via 192.168.1.1, tun0, 2d10h27m
  B>* 192.168.5.26/32 [20/0] via 192.168.1.1, tun0, 10:09:24
  B>* 192.168.5.36/32 [20/0] via 192.168.1.1, tun0, 2d10h19m
  B>* 192.168.17.0/24 [20/0] via 192.168.1.1, tun0, 3d05h07m
  B>* 192.168.17.1/32 [20/0] via 192.168.1.1, tun0, 3d05h07m
  B>* 192.168.32.0/24 [20/0] via 192.168.1.1, tun0, 2d10h27m
  anakin#


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)
   [http://scry.wanfear.com/~greear/vlan.html]

           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 [9]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)
   [http://vlan.sourceforge.net]

           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
           [http://scry.wanfear.com/~greear/vlan/cisco_howto.html].

           Mise  jour : a t inclue dans le noyau  partir de la version
           2.4.14 (peut-tre 13).

   Serveur Linux Virtuel (Linux Virtual Server )(site)
   [http://www.LinuxVirtualServer.org/]

           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 [10](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) [http://www.chronox.de]

           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)
   [http://w3.arobas.net/~jetienne/vrrpd/index.html]

           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
   [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/ [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/
   [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 [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 [11]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
   [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
   [http://www.cisco.com/univercd/cc/td/doc/product/software/ios111/cc111/car.htm]

           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 coutant le prix d'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.

     * Junk Alins

       <juanjo@mat.upc.es>

     * Joe Van Andel

     * Michael T. Babcock

       <mbabcock@fibrespeed.net>

     * Christopher Barton

       <cpbarton%uiuc.edu>

     * Peter Bieringer

       <pb:bieringer.de>

     * Ard van Breemen

       <ard%kwaak.net>

     * Ron Brinker

       <service%emcis.com>

     * ?ukasz Bromirski

       <l.bromirski@mr0vka.eu.org>

     * Lennert Buytenhek

       <buytenh@gnu.org>

     * Esteve Camps

       <esteve@hades.udg.es>

     * Ricardo Javier Cardenes

       <ricardo%conysis.com>

     * 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>

     * Hannes Ebner

       <he%fli4l.de>

     * Derek Fawcus

       <dfawcus%cisco.com>

     * David Fries

       <dfries%mail.win.org>

     * Stephan "Kobold" Gehring

       <Stephan.Gehring@bechtle.de>

     * Jacek Glinkowski

       <jglinkow%hns.com>

     * Andrea Glorioso

       <sama%perchetopi.org>

     * Thomas Graaf

       <tgraf%suug.ch>

     * Sandy Harris

       <sandy%storm.ca>

     * 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>

     * Ayotunde Itayemi

       <aitayemi:metrong.com>

     * Alexander W. Janssen <yalla%ynfonatic.de>

     * Andreas Jellinghaus <aj%dungeon.inka.de>

     * Gareth John <gdjohn%zepler.org>

     * Dave Johnson

       <dj@www.uk.linux.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>

     * Jose Luis Domingo Lopez

       <jdomingo@24x7linux.com>

     * Robert Lowe

       <robert.h.lowe@lawrence.edu>

     * 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>

     * James Morris <jmorris@intercode.com.au>

     * 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>

     * Rod Roark <rod%sunsetsystems.com>

     * Pavel Roskin <proski@gnu.org>

     * Rusty Russell <rusty%rustcorp.com.au>

     * Mihai RUSU <dizzy%roedu.net>

     * Rob Pitman <rob%pitman.co.za>

     * Jamal Hadi Salim <hadi%cyberus.ca>

     * Ren? Serral <rserral%ac.upc.es>

     * 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>

     * Matthew Strait <straitm%mathcs.carleton.edu>

     * Jason Tackaberry <tack@linux.com>

     * Charles Tassell <ctassell%isn.net>

     * Glen Turner <glen.turner%aarnet.edu.au>

     * Tea Sponsor: Eric Veldhuyzen <eric%terra.nu>

     * Thomas Walpuski <thomas%bender.thinknerd.de>

     * Song Wang <wsong@ece.uci.edu>

     * Chris Wilson

       <chris@netservers.co.uk>

     * Lazar Yanackiev

       <Lyanackiev%gmx.net>

     * Pedro Larroy

       <piotr%member.fsf.org>

          * Chaptitre 15, section 10: Exemple d'une solution de traduction
            d'adresse avec de la QoS

          * Chaptitre 17, section 1: Configurer OSPF avec Zebra

