Linux 2.4 Advanced Routing HOWTO
 Netherlabs BV (bert hubert <[email protected]>)
 Gregory Maxwell <[email protected]>
 Remco van Mook <[email protected]>
 Martijn van Oosterhout <[email protected]>
 Paul B Schroeder  <[email protected]>
 [email protected]
 Traduction de Laurent Foucher <[email protected]>,
 Philippe Latu <[email protected]> et Guillaume
 All�gre <[email protected]>
 v0.1.0 $Date: 01/07/2000 12:20:21 $

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

 Table des mati�res

















































 1. D�dicace

 2. Introduction

    2.1 Conditions de distribution et Mise en garde
    2.2 Connaissances pr�alables
    2.3 Ce que Linux peut faire pour vous
    2.4 Notes diverses
    2.5 Acc�s, CVS et propositions de mises � jour
    2.6 Plan du document

 3. Introduction � iproute2

    3.1 Pourquoi iproute2 ?
    3.2 Un tour d'horizon d'Iproute2
    3.3 Pr�requis
    3.4 Explorer votre configuration courante
       3.4.1 (TT
       3.4.2 (TT
       3.4.3 (TT
    3.5 ARP

 4. R�gles - bases de donn�es des politiques de routage

    4.1 Routage simple par l'adresse source

 5. GRE et autres tunnels

    5.1 Quelques remarques g�n�rales � propos des tunnels :
    5.2 IP dans un tunnel IP
    5.3 Le tunnel GRE
       5.3.1 Le tunnel IPv4
       5.3.2 Le tunnel IPv6
    5.4 Tunnels dans l'espace utilisateur

 6. IPsec : IP s�curis� � travers l'Internet

 7. Routage multi-diffusion (multicast)

 8. Utilisation de la mise en file d'attente bas�e sur des classes ("Class Based Queueing") pour la gestion de la bande passante

    8.1 Qu'est-ce que la mise en file d'attente ?
    8.2 Premi�re tentative de partage de bande passante
    8.3 Que faire de la bande passante en exc�s ?
    8.4 Subdivisions de classes
    8.5 �quilibrage de charge sur plusieurs interfaces

 9. D'autres gestionnaires de mise en file d'attente (queueing disciplines)

    9.1 pfifo_fast
    9.2 Stochastic Fairness Queueing
    9.3 Token Bucket Filter
    9.4 Random Early Detect
    9.5 Ingress policer qdisc

 10. Netfilter et iproute - marquage de paquets

 11. D'autres classificateurs

    11.1 Le classificateur "fw"
    11.2 Le classificateur "u32"
       11.2.1 Le s�lecteur U32
       11.2.2 S�lecteurs g�n�raux
       11.2.3 Les s�lecteurs sp�cifiques
    11.3 Le classificateur "route"
    11.4 Le classificateur "rsvp"
    11.5 Le classificateur "tcindex"

 12. Param�tres r�seau du noyau

    12.1 Filtrage du Chemin Inverse (Reverse Path Filtering)
    12.2 Configurations obscures
       12.2.1 ipv4 g�n�rique
       12.2.2 Configuration p�riph�rique par p�riph�rique
       12.2.3 Politique de voisinage
       12.2.4 Configuration du routage

 13. Application du contr�le de trafic aux dorsales

    13.1 Files d'attente de routeurs

 14. Recettes de cuisine pour la mise en forme du trafic

    14.1 Faire tourner plusieurs sites avec diff�rentes SLA (autorisations)
    14.2 Prot�ger votre machine des inondations SYN floods
    14.3 Limiter le d�bit ICMP pour emp�cher les d�nis de service
    14.4 Donner la priorit� au trafic interactif

 15. Routage avanc� sur Linux

    15.1 Comment la mise en file d'attente des paquets fonctionne-t-elle en pratique ?
    15.2 Utilisation avanc�e du syst�me de mise en file d'attente des paquets
    15.3 D'autres syst�mes de mise en forme des paquets

 16. Routage Dynamique - OSPF et BGP

 17. Lectures suppl�mentaires

 18. Remerciements



 ______________________________________________________________________

 11..  DD��ddiiccaaccee


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



 �  Rusty Russel

 �  Alexey N. Kuznetsov

 �  La fine �quipe de Google

 �  L'�quipe de Casema Internet



 22..  IInnttrroodduuccttiioonn

 Bienvenue, cher lecteur.

 Ce document a pour but de vous �clairer sur la mani�re de faire du
 routage avanc� avec Linux 2.2/2.4. M�connus 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'esp�re que cet HOWTO deviendra aussi lisible que le tr�s r�put�
 Netfilter, de Rusty Russel.

 Vous pouvez nous contacter en nous �crivant � �quipe HOWTO
 <mailto:[email protected]>.


 22..11..  CCoonnddiittiioonnss ddee ddiissttrriibbuuttiioonn eett MMiissee eenn ggaarrddee

 Ce document est distribu� avec l'espoir qu'il sera utile et utilis�.
 Sauf mention contraire, les documents Linux HOWTO sont la propri�t� de
 leurs auteurs respectifs. Les documents Linux HOWTO peuvent �tre
 reproduits et distribu�s en totalit� ou en partie, sur tout support
 physique ou �lectronique, tant que cette notice de droit d'auteur est
 pr�sente sur chaque copie. La redistribution commerciale est autoris�e
 et encourag�e ; n�ammoins, l'auteur souhaite �tre inform� de toute
 distribution de ce genre.  Toute traduction, travail d�riv�, ou
 agr�gat incorporant tout ou partie d'un ou plusieurs documents Linux
 HOWTO doit �tre couvert par ce m�me droit d'auteur. Ce qui veut dire
 que vous ne pouvez produire un travail d�riv� d'un HOWTO et imposer
 des restrictions suppl�mentaires concernant sa distribution.

 En un mot, si votre dorsale STM-64 est tomb�e ou distribue de la
 pornographie � vos estim�s clients, cela n'est pas de notre faute.
 D�sol�.

 Copyright (c) 2000 par Bert Hubert, Gregory Maxwell et Martijn van
 Oosterhout

 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.
 Vous pouvez cr�er un travail d�riv� et le distribuer � condition :


 1. d'envoyer votre travail d�riv� (dans le format le plus appropri�,
    tel que sgml) au LDP (Linux Documentation Project), ou autre, pour
    une diffusion sur Internet.  Si ce n'est pas au LDP, faites savoir
    au LDP o� il est disponible ;

 2. que la licence de votre travail d�riv� soit la m�me, ou utilisez la
    GPL.  Incluez une notification du copyright et, au moins, un
    pointeur vers la licence utilis�e ;

 3. de cr�diter pour leur travail les auteurs pr�c�dents et les
    principaux contributeurs.

    Si vous envisagez un travail d�riv� autre qu'une traduction, vous
    �tes invit� � discuter de vos projets avec le mainteneur actuel.

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



 22..22..  CCoonnnnaaiissssaanncceess pprr��aallaabblleess

 Comme le titre l'implique, ceci est un HOWTO "avanc�". Bien qu'il ne
 soit pas besoin d'�tre un expert r�seau, certains pr�requis sont
 n�cessaires.  Ce document se veut la suite du Linux 2.4 Networking
 HOWTO <http://www.ds9a.nl/2.4Networking/> par les m�me auteurs. Vous
 devriez probablement le lire en premier.

 Voici d'autres r�f�rences qui pourront vous aider � en apprendre
 plus :
    RRuussttyy RRuusssseellss nneettwwoorrkkiinngg--ccoonncceeppttss--HHOOWWTTOO <<http://netfilter.kernel�
       notes.org/unreliable-guides/networking-concepts-HOWTO.html>
       Tr�s bonne introduction, expliquant ce qu'est un r�seau, et
       comment on le connecte � d'autres r�seaux.


    LLiinnuuxx NNeettwwoorrkkiinngg--HHOOWWTTOO ((eexx NNeett--33 HHOOWWTTOO))
       Excellent document, bien que tr�s bavard. Il vous apprendra
       beaucoup de choses qui sont d�j� configur�es si vous �tes
       capable de vous connecter � Internet.  Probablement �
       /usr/doc/HOWTO/NET-HOWTO.txt mais peut aussi �tre trouv� en
       ligne <http://www.linuxports.com/howto/networking>


 22..33..  CCee qquuee LLiinnuuxx ppeeuutt ffaaiirree ppoouurr vvoouuss

 Une petite liste des choses qui sont possibles :


 �  Ma�triser la bande passante pour certains ordinateurs

 �  Ma�triser la bande passante vers certains ordinateurs

 �  Vous aider � partager �quitablement votre bande passante

 �  Prot�ger votre r�seau des attaques de type D�ni de Service

 �  Prot�ger le r�seau local des acc�s de vos clients

 �  Multiplexer plusieurs serveurs en un seul, pour l'�quilibrage de
    charge, ou une disponibilit� am�lior�e

 �  Restreindre l'acc�s � vos ordinateurs

 �  Limiter l'acc�s de vos utilisateurs vers d'autres h�tes

 �  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 fonctionnalit�s avanc�es. Il
 y a plusieurs raisons � cela. Bien que la documentation soit fournie,
 la prise en main est difficile.  Les commandes de contr�le du trafic
 ne sont pratiquement pas document�es.


 22..44..  NNootteess ddiivveerrsseess

 Il y a plusieurs choses qui doivent �tre not�es au sujet de ce
 document.  Bien que  j'en aie �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'h�sitez pas � m'avertir des coquilles ou
 d'erreurs pures et simples.  Si mon anglais vous para�t parfois peu
 naturel, ayez en t�te, s'il vous pla�t, que l'anglais n'est pas ma
 langue natale.  N'h�sitez 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.  Le source SGML de cette
 documentation est disponible via CVS, ce qui permet � plus de
 personnes de travailler dessus.

 Pour vous aider, vous trouverez beaucoup de mentions FIXME (NdT : "�
 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 tr�s attention.  Si vous avez valid� quelque chose,
 faites-le nous savoir, ce qui nous permettra de retirer la mention
 FIXME.

 Je prendrai quelques libert�s tout au long de cet HOWTO. Par exemple,
 je pars de l'hypoth�se d'une connexion Internet � 10 Mbits, bien que
 je sache tr�s bien que cela n'est pas vraiment courant.


 22..55..  AAcccc��ss,, CCVVSS eett pprrooppoossiittiioonnss ddee mmiisseess �� jjoouurr

 L'adresse canonique de cet HOWTO est Ici
 <http://www.ds9a.nl/2.4Routing>.

 Nous avons maintenant un CVS en acc�s anonyme disponible depuis le
 monde entier. Cela est int�ressant pour plusieurs raisons. Vous pouvez
 facilement t�l�charger les nouvelles versions de ce HOWTO et soumettre
 des patches.  En outre, cela permet aux auteurs de travailler sur le
 source de facon ind�pendante, ce qui est une bonne chose aussi.



      $ export CVSROOT=:pserver:[email protected]:/var/cvsroot
      $ cvs login
      CVS password: [enter 'cvs' (without 's)]
      $ cvs co 2.4routing
      cvs server: Updating 2.4routing
      U 2.4routing/2.4routing.sgml




 Si vous rep�rez une erreur, ou voulez ajouter quelque chose, faites le
 en local, ex�cutez  cvs diff -u, et envoyez-nous le r�sultat.

 Un fichier Makefile est fourni pour vous aider � cr�er des fichiers
 PostScript, dvi, pdf, html et texte.  Vous pouvez avoir � installer
 les sgml-tools, ghostscript et tetex pour obtenir tous les formats de
 sortie.


 22..66..  PPllaann dduu ddooccuummeenntt

 Nous allons essayer de faire des manipulations int�ressantes d�s le
 d�but, ce qui veut dire que tout ne sera pas expliqu� en d�tail tout
 de suite.  Veuillez passer sur ces d�tails, et accepter de consid�rer
 qu'ils deviendront clairs par la suite.

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


 �  Rusty's Remarkably Unreliable Guides
    <http://netfilter.kernelnotes.org/unreliable-guides/>

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


 33..  IInnttrroodduuccttiioonn �� iipprroouuttee22




 33..11..  PPoouurrqquuooii iipprroouuttee22 ??

 La plupart des distributions Linux et des UNIX utilisent couramment
 les v�n�rables commandes "arp", "ifconfig" et "route". Bien que ces
 outils fonctionnent, ils montrent quelques comportements inattendus
 avec les noyaux Linux des s�ries 2.2 et plus.  Par exemple, les
 tunnels GRE font partie int�grante du routage de nos jours, mais ils
 n�cessitent des outils compl�tement diff�rents.

 Avec iproute2, les tunnels font partie int�grante des outils.

 Les noyaux Linux des s�ries 2.2 et plus ont un sous-syst�me r�seau
 compl�tement r��crit. Ce nouveau codage de la partie r�seau apporte �
 Linux des performances et des fonctionnalit�s qui n'ont pratiquement
 pas d'�quivalent dans les autres syst�mes d'exploitation.  En fait, le
 nouveau logiciel de filtrage, routage et de classification poss�de
 plus de fonctionnalit�s que les logiciels fournis sur beaucoup de
 routeurs d�di�s, de pare-feux et de produits de mise en forme
 (shaping) du trafic.

 Dans les syst�mes d'exploitation existants, au fur et � mesure que de
 nouveaux concepts r�seau apparaissaient, les d�veloppeurs sont
 parvenus � les greffer sur les structures existantes.  Ce travail
 constant d'empilage de couches a conduit � des codes r�seau 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'id�al.

 La nouvelle structure d'iproute2 a permis de formuler clairement des
 fonctionnalit�s impossibles � implanter dans le sous-syst�me r�seau
 pr�c�dent.


 33..22..  UUnn ttoouurr dd''hhoorriizzoonn dd''IIpprroouuttee22

 Linux poss�de un syst�me sophistiqu� d'allocation de bande passante
 appel� Contr�le de trafic (Traffic Control).  Ce syst�me supporte
 diff�rentes m�thodes pour classer, ranger par ordre de priorit�,
 partager et limiter le trafic entrant et sortant.

 Nous commencerons par un petit tour d'horizon des possibilit�s
 d'iproute2.


 33..33..  PPrr��rreeqquuiiss

 Vous devez �tre s�r 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.  Certains �l�ments
 d'iproute vous imposent l'activation de certaines options du noyau.

 FIXME: Nous devrions mentionner iproute2-current.tar.gz
 <ftp://ftp.inr.ac.ru/ip-routing/iproute2-current.tar.gz> qui est
 toujours la derni�re version.


 33..44..  EExxpplloorreerr vvoottrree ccoonnffiigguurraattiioonn ccoouurraannttee

 Cela peut vous para�tre surprenant, mais iproute2 est d�j� configur� !
 Les commandes courantes ifconfig et route utilisent d�j� les appels
 syst�me avanc�s d'iproute2, mais essentiellement avec les options par
 d�faut (c'est-�-dire ennuyeuses).


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


 33..44..11..  iipp  nnoouuss mmoonnttrree nnooss lliieennss



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




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

 La premi�re interface que nous voyons est l'interface loopback. Bien
 que votre ordinateur puisse fonctionner sans, je vous le d�conseille.
 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 pr�sente sur votre ordinateur. Il y a ensuite mes
 deux interfaces r�seau, l'une du c�t� de mon modem c�ble, l'autre
 servant mon segment ethernet � la maison. De plus, nous voyons une
 interface ppp0.

 Notons l'absence d'adresses IP. Iproute d�connecte les concepts de
 "liens" et "d'adresses IP". Avec l'IP aliasing, le concept de
 l'adresse IP canonique est devenu, de toute fa�on, sans signification.

 ip nous montre bien, cependant, l'adresse MAC, l'identifiant mat�riel
 de nos interfaces ethernet.


 33..44..22..  iipp  nnoouuss mmoonnttrree nnooss aaddrreesssseess IIPP
















 [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" d�signe Internet. Il y a
 beaucoup d'autres familles d'adresses, mais elles ne nous concernent
 pas pour le moment.

 Examinons eth0 de plus pr�s. Il est dit qu'il est reli� � l'adresse
 internet "10.0.0.1/8". Qu'est-ce que cela signifie ? Le /8 d�signe le
 nombre de bits r�serv�s � l'adresse r�seau. Il y a 32 bits, donc il
 reste 24 bits pour d�signer une partie de notre r�seau.  Les 8
 premiers bits de 10.0.0.1 correspondent � 10.0.0.0, notre adresse
 r�seau, et notre masque de sous-r�seau est 255.0.0.0.

 Les autres bits rep�rent des machines directement connect�es � 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 m�me concept existe, bien que les nombres soient
 diff�rents.  Son adresse est 212.64.94.251, sans masque de sous-
 r�seau. 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 c�t� du lien, il n'y a encore qu'une seule adresse,
 212.64.94.1. Le /32 nous pr�cise qu'il n'y a pas de "bits r�seau".

 Il est absolument vital que vous compreniez ces concepts. R�f�rez-vous
 � la documentation mentionn�e au d�but de cet HOWTO si vous avez des
 doutes.

 Vous pouvez aussi noter "qdisc", qui d�signe la "Queueing Discipline"
 (gestion de la mise en file d'attente). Cela deviendra vital plus
 tard.


 33..44..33..  iipp  nnoouuss mmoonnttrree nnooss rroouutteess

 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 pr�t � propager nos paquets � travers le
 monde, et � nous renvoyer le r�sultat.







 [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-m�me. Les 4 premi�res lignes donnent
 explicitement ce qui �tait sous-entendu par ip address show, la
 derni�re ligne nous indiquant que le reste du monde peut �tre trouv�
 via 212.64.94.1, notre passerelle par d�faut. Nous pouvous 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 r�f�rence, 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





 33..55..  AARRPP

 ARP est le Protocole de R�solution d'Adresse (Address Resolution
 Protocol).  Il est d�crit dans le RFC 826
 <http://www.faqs.org/rfcs/rfc826.html>.  ARP est utilis� par une
 machine d'un r�seau local pour retrouver l'adresse mat�rielle (la
 localisation) d'une autre machine sur le m�me r�seau.  Les machines
 sur Internet sont g�n�ralement connues par leur nom auquel correspond
 une adresse IP. C'est ainsi qu'une machine sur le r�seau foo.com est
 capable de communiquer avec une autre machine qui est sur le r�seau
 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 tr�s simple. Supposons que j'aie un r�seau 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 d�cide
 d'envoyer un "ping" vers bar, il a besoin d'envoyer une requ�te ARP.
 Cette requ�te ARP est une fa�on pour foo de crier sur le r�seau "Bar
 (10.0.0.2) ! O� es-tu ?". Par cons�quent, toutes les machines sur le
 r�seau entendront foo crier, mais seul bar (10.0.0.2) r�pondra. Bar
 enverra une r�ponse ARP directement � foo ; ce qui revient � dire :
 "Foo (10.0.0.1) ! je suis ici, � l'adresse 00:60:94:E:08:12".  Apr�s
 cette simple transaction utilis�e pour localiser son ami sur le
 r�seau, foo est capable de communiquer avec bar jusqu'� ce qu'il (le
 cache ARP de foo) oublie o� bar est situ�.

 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

      --- espa043.austin.ibm.com ping statistics ---
      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 cons�quent, lorsque espa041 a essay� de contacter espa043,
 l'adresse mat�rielle de espa043 (sa localisation) a alors �t� ajout�e
 dans le cache ARP. Donc, tant que la dur�e de vie de l'entr�e
 correspondant � espa043 dans le cache ARP n'est pas d�pass�e, espa041
 sait localiser espa043 et n'a plus besoin d'envoyer de requ�te ARP.

 Maintenant, effa�ons 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 requ�te 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
 confirm�e � la premi�re transaction avec cette machine.


 44..  RR��gglleess -- bbaasseess ddee ddoonnnn��eess ddeess ppoolliittiiqquueess ddee rroouuttaaggee

 Si vous avez un routeur important, il se peut que vous vouliez
 satisfaire les besoins de diff�rentes personnes, qui peuvent �tre
 trait�es diff�remment. Les bases de donn�es des politiques de routage
 vous aident � faire cela, en g�rant plusieurs ensembles de tables de
 routage.  Si vous voulez utiliser cette fonctionnalit�, assurez vous
 que le noyau est compil� avec l'option "IP: policy routing".


 Quand le noyau doit prendre une d�cision de routage, il recherche
 quelle table consulter. Par d�faut, il y a trois tables.  L'ancien
 outil route modifie les tables "main" (principale) et "local"
 (locale), comme le fait l'outil ip (par d�faut).

 Les r�gles par d�faut :


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




 Cela liste les r�gles, accompagn�es de leurs priorit�s.  Nous voyons
 que toutes les r�gles sont appliqu�es � tous les paquets ("from all").
 Nous avons vu la table "main" pr�c�demment, 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 cr�er des
 r�gles qui pointent vers des tables diff�rentes et qui nous permettent
 de red�finir les r�gles de routage du syst�me.

 Pour savoir exactement ce que fait le noyau en pr�sence d'un
 assortiment de r�gles plus complet, r�f�rez-vous � la documentation
 ip-cref d'Alexey [NdT : dans le paquet iproute de votre distribution].



 44..11..  RRoouuttaaggee ssiimmppllee ppaarr ll''aaddrreessssee ssoouurrccee

 Prenons encore une fois un exemple r�el. J'ai 2 modems c�ble,
 connect�s � un routeur Linux NAT ("masquerading"). Les personnes
 habitant avec moi me paient pour avoir acc�s � Internet. Supposons
 qu'un de mes co-locataires visite seulement hotmail et veuille payer
 moins. C'est d'accord pour moi, mais il utilisera le modem le plus
 lent.

 Le modem c�ble "rapide" est connu sous 212.64.94.251 et est en liaison
 PPP avec 212.64.94.1. Le modem c�ble "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 pr�cis�es quelque peu, ce que nous allons faire.  La
 table de routage par d�faut 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 g�n�rons une nouvelle r�gle que nous appellerons
 "John", pour notre hypoth�tique 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 g�n�rer 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'� implanter cela dans ip-up.


 55..  GGRREE eett aauuttrreess ttuunnnneellss

 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, par
 exemple, PPTP).


 55..11..  QQuueellqquueess rreemmaarrqquueess gg��nn��rraalleess �� pprrooppooss ddeess ttuunnnneellss ::

 Les tunnels peuvent faire des choses tr�s inhabituelles et vraiment
 sympa.  Ils peuvent aussi absolument tout d�traquer si vous ne les
 avez pas configur�s correctement. Ne d�finissez pas votre route par
 d�faut sur un tunnel, � moins que vous ne sachiez eexxaacctteemmeenntt ce que
 vous faites.

 De plus, le passage par un tunnel augmente le poids des en-t�tes
 (overhead), puisqu'un en-t�te IP suppl�mentaire est n�cessaire.
 Typiquement, ce surco�t est de 20 octets par paquet.  Donc, si la
 taille maximum de votre paquet sur votre r�seau (MTU) est de 1500
 octets, un paquet qui est envoy� � travers un tunnel sera limit� � une
 taille de 1480 octets.  Cela n'est pas n�cessairement un probl�me,
 mais soyez s�r d'avoir bien �tudi� la fragmentation et le r�assemblage
 des paquets IP quand vous pr�voyez de relier des r�seaux de grande
 taille par des tunnels.  Et bien s�r, la mani�re la plus rapide de
 creuser un tunnel est de creuser des deux c�t�s.



 55..22..  IIPP ddaannss uunn ttuunnnneell IIPP

 Ce type de tunnel est disponible dans Linux depuis un long moment. Il
 n�cessite deux modules, ipip.o et new_tunnel.o.

 Disons que vous avez trois r�seaux : 2 r�seaux internes A et B, et un
 r�seau interm�diaire C (ou disons Internet).  Les caract�ristiques du
 r�seau A sont :



      r�seau 10.0.1.0
      masque de sous-r�seau 255.255.255.0
      routeur  10.0.1.1




 Le routeur a l'adresse 172.16.17.18 sur le r�seau C.

 et le r�seau  B :


      r�seau 10.0.2.0
      masque de sous-r�seau 255.255.255.0
      routeur  10.0.2.1




 Le routeur a l'adresse 172.19.20.21 sur le r�seau C.

 En ce qui concerne le r�seau 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 :

 Premi�rement, assurez-vous que les modules sont install�s :


      insmod ipip.o
      insmod new_tunnel.o




 Ensuite, sur le routeur du r�seau 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 r�seau 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 r�seaux IPv4 qui, normalement, ne
 seraient pas capables de se "parler", c'est tout.  Dans la mesure o�
 la compatibilit� a �t� conserv�e, 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 syst�mes d'exploitation ou
 routeurs, pour autant que je sache. C'est simple, �a marche. Utilisez-
 le si vous le pouvez, autrement utilisez GRE.


 55..33..  LLee ttuunnnneell GGRREE

 GRE est un protocole de tunnel qui a �t� � l'origine d�velopp� par
 Cisco, et qui peut r�aliser 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.


 55..33..11..  LLee ttuunnnneell IIPPvv44

 Dans un premier temps, int�ressons-nous au tunnel IPv4 :

 Disons que vous avez trois r�seaux : 2 r�seaux internes A et B, et un
 r�seau interm�diaire C (ou disons Internet).

 Les caract�ristiques du r�seau A sont :


      r�seau 10.0.1.0
      masque de sous-r�seau 255.255.255.0
      routeur  10.0.1.1




 Le routeur a l'adresse 172.16.17.18 sur le r�seau C.  Appelons ce
 r�seau neta.

 Et pour le r�seau B :


      r�seau 10.0.2.0
      masque de sous-r�seau 255.255.255.0
      routeur  10.0.2.1




 Le routeur a l'adresse 172.19.20.21 sur le r�seau C.  Appelons ce
 r�seau netb.

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


 Sur le routeur du r�seau 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 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
 p�riph�rique 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 cot�), que nos
 paquets "tunnel�s" devront �tre g�n�r�s � partir de 172.16.17.18 (ce
 qui autorise votre serveur � avoir plusieurs adresses IP sur le r�seau
 C et ainsi vous permet de choisir laquelle sera utilis�e pour votre
 tunnel) et que le champ TTL de vos paquets sera fix� � 255 (ttl 255).

 Sur la deuxi�me ligne, nous avons donn� � cette nouvelle interface
 l'adresse 10.0.1.1. C'est bon pour de petits r�seaux, mais quand vous
 commencez une exploitation mini�re (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 troisi�me ligne, nous positionnons une route pour le r�seau B.
 Notez la notation diff�rente pour le masque de sous-r�seau. Si vous
 n'�tes pas familiaris� avec cette notation, voici comment �a marche :
 vous �crivez le masque de sous-r�seau 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 int�resserait.


 Mais arr�tons ici, et continuons avec le routeur du r�seau B.


      ip tunnel add neta mode gre remote 172.16.17.18 local 172.19.20.21 ttl 255
      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 s�r, vous pouvez remplacer netb par neta pour le routeur B.



 55..33..22..  LLee ttuunnnneell IIPPvv66


 BON GROS AVERTISSEMENT !

 Ce qui suit n'est pas test�.  Vous op�rez � vos risques et p�rils.  Ne
 dites pas que je ne vous avais pas pr�venu.

 FIXME: v�rifier et essayer tout ceci.


 De petites choses � propos des adresses IPv6 :

 Les adresses IPv6 sont, en comparaison avec les adresses IPv4,
 monstrueusement grosses. Voici un exemple :

 3ffe:2502:200:40:281:48fe:dcfe:d9bc


 Donc, pour rendre l'�criture plus facile, il y a quelques r�gles :

 �  Ne pas utiliser les z�ros de t�te, comme dans IPv4 ;

 �  Utiliser des double-points de s�paration tous les 16 bits (2
    octets) ;

 �  Quand vous avez beaucoup de z�ros cons�cutifs, vous pouvez �crire
    ::. Vous ne pouvez faire cela qu'une seule fois par adresse et
    seulement pour une longueur de 16 bits.

    En utilisant ces r�gles, l'addresse
    3ffe:0000:0000:0000:0000:0020:34A1:F32C peut �tre �crite
    3ffe::20:34A1:F32C, ce qui est beaucoup plus court.


 � propos des tunnels.

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



      R�seau 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 pr�s. Sur la premi�re ligne, nous avons cr�� un
 p�riph�rique 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 p�riph�rique actif (up). Puis, nous
 avons ajout� notre propre adresse r�seau et configur� une route pour
 3ffe::/15 � travers le tunnel.


 Les tunnels GRE constituent actuellement le type pr�f�r� de tunnel.
 C'est un standard qui est largement adopt�, m�me � l'ext�rieur de la
 communaut� Linux, ce qui constitue une bonne raison de l'utiliser.

 55..44..  TTuunnnneellss ddaannss ll''eessppaaccee uuttiilliissaatteeuurr

 Il y a des dizaines d'impl�mentations de tunnels � l'ext�rieur du
 noyau. Les plus connus sont bien s�r PPP et PPTP, mais il y en a bien
 plus (certains propri�taires, certains s�curis�s, d'autres qui
 n'utilisent pas IP), qui d�passent le cadre de cet HOWTO.


 66..  IIPPsseecc :: IIPP ss��ccuurriiss�� �� ttrraavveerrss ll''IInntteerrnneett

 FIXME: Attendre notre r�dacteur vedette Stefan pour finir cette
 partie.


 77..  RRoouuttaaggee mmuullttii--ddiiffffuussiioonn ((mmuullttiiccaasstt))

 FIXME: Pas de r�dacteur !


 88..  UUttiilliissaattiioonn ddee llaa mmiissee eenn ffiillee dd''aatttteennttee bbaass��ee ssuurr ddeess ccllaasssseess
 ((""CCllaassss BBaasseedd QQuueeuueeiinngg"")) ppoouurr llaa ggeessttiioonn ddee llaa bbaannddee ppaassssaannttee

 Quand je l'ai d�couvert, cela m'a vraiment "souffl�". Linux 2.2
 contient toutes les fonctionnalit�s pour la gestion de la bande
 passante, de mani�re comparable � un syst�me d�di� de haut niveau.

 Linux d�passe m�me ce que l'ATM et le Frame peuvent fournir.

 Les deux unit�s de base du Contr�le de Trafic sont les filtres et les
 files d'attente. Les filtres placent le trafic dans des files
 d'attente, qui recueillent ainsi le trafic et d�cident ce qu'il faut
 envoyer en premier, envoyer plus tard, ou �liminer. Il existe
 plusieurs variantes de filtres et de files d'attente.

 Les filtres les plus communs sont fwmark et u32. Le premier vous
 permet d'utiliser le code Netfilter de Linux pour s�lectionner le
 trafic, et le second vous permet de s�lectionner ce trafic � partir de
 N'IMPORTE QUEL en-t�te. La file d'attente la plus connue est la Class
 Based Queue (File d'attente bas�e sur des classes). CBQ est une super-
 file d'attente, qui peut contenir d'autres files d'attente (m�me
 d'autres CBQ).

 Il n'est peut-�tre pas �vident de voir ce que la mise en file
 d'attente peut avoir � faire avec la gestion de bande passante, mais
 �a marche vraiment.

 Pour cadre de r�f�rence de cette section, j'ai pris l'exemple d'un
 fournisseur d'acc�s chez qui j'ai appris les ficelles du m�tier, pour
 ne pas le citer : Casema Internet en Hollande.  Casema, qui est
 actuellement un c�ble-op�rateur, a des besoins internet pour ses
 clients et pour son propre compte. La plupart des ordinateurs de la
 soci�t� ont un acc�s Internet. En r�alit�, ils ont beaucoup d'argent �
 d�penser et n'utilisent pas Linux pour la gestion de la bande
 passante.

 Nous �tudierons comment notre fournisseur d'acc�s aurait pu utiliser
 Linux pour g�rer sa bande passante.


 88..11..  QQuu''eesstt--ccee qquuee llaa mmiissee eenn ffiillee dd''aatttteennttee ??

 Avec la mise en file d'attente, nous d�terminons l'ordre dans lequel
 les donn�es sont envoy�es. Il est important de le comprendre, nous ne
 pouvons que mettre en forme les donn�es que nous transmettons. Comment
 ce changement de priorir� d�termine-t-il la vitesse de transmission ?

 Imaginez une caisse enregistreuse capable de traiter 3 clients par
 minute.  Les personnes souhaitant payer vont attendre en file indienne
 en bout de queue. C'est une "file d'attente fifo".  (NdT : fifo =
 First In, First Out, premier entr�, premier sorti) Supposons
 maintenant que vous laissiez toujours certaines personnes s'ins�rer au
 milieu de la queue, et non en fin. Ces personnes attendront moins de
 temps et donc pourront faire leurs courses plus rapidement.

 Avec la mani�re dont Internet travaille, nous n'avons pas de contr�le
 direct de ce que les personnes nous envoient. C'est un peu comme votre
 bo�te aux lettres (physique !) chez vous. Il n'y a pas de fa�on
 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 poss�de
 quelques fonctionnalit�s qui vont pouvoir nous aider. TCP/IP n'a pas
 d'aptitude � conna�tre les performances d'un r�seau entre deux h�tes.
 Il commence � envoyer des paquets, de plus en plus rapidement ('slow
 start') et quand des paquets commencent � se perdre, il ralentit.

 C'est comme si vous ne lisiez que la moiti� de votre courrier en
 esp�rant que vos correspondants arr�teront de vous en envoyer. � la
 diff�rence du courrier, �a marche sur l'Internet :-)

 FIXME: expliquer comment, normalement, les acquittements (ACKs) sont
 utilis�s pour d�terminer la vitesse.



      [L'Internet] ---<E3, T3, peu importe>--- [Routeur Linux] --- [Bureau+FAI]
                                              eth1          eth0




 Maintenant, notre routeur Linux a deux interfaces que je vais appeler
 eth0 et eth1. Eth1 est connect� � notre routeur qui transmet les
 paquets venant de ou allant vers notre fibre optique.

 Eth0 est connect� � un sous-r�seau qui contient � la fois le pare-feu
 de la soci�t� et notre �quipement de t�te, � travers lequel nos
 clients peuvent se connecter.

 Dans la mesure o� nous ne pouvons limiter que ce que nous envoyons,
 nous avons besoin de deux ensembles de r�gles s�par�s, mais tr�s
 similaires.  En modifiant la mise en file d'attente sur eth0, nous
 d�terminons � quelle vitesse les donn�es re�ues sont envoy�es � nos
 clients.  On d�termine ainsi la bande passante descendante disponible
 vers eux, en r�sum�, leur "vitesse de t�l�chargement".

 Sur eth1, nous d�terminons � quelle vitesse nous envoyons les donn�es
 sur Internet, � quelle vitesse nos utilisateurs, � la fois ceux de la
 soci�t� et les clients, peuvent �mettre les donn�es.


 88..22..  PPrreemmii��rree tteennttaattiivvee ddee ppaarrttaaggee ddee bbaannddee ppaassssaannttee

 CBQ nous permet de cr�er plusieurs classes, et m�me des classes
 incluses dans d'autres classes. Les divisions les plus larges peuvent
 �tre appel�es des agences. Au sein de ces classes, se trouveraient des
 classes comme "traitement par lot" et "traitement interactif".

 Par exemple, nous pourrions avoir une connexion Internet de 10 Mbits
 devant �tre partag�e par nos clients et les besoins de la soci�t�.
 Nous ne devons pas permettre � quelques personnes de la soci�t� de
 monopoliser un gros volume de bande passante, qui devrait �tre vendue
 � nos clients.

 D'un autre c�t�, nos clients ne doivent pas pouvoir grignoter le
 trafic r�serv� � nos bureaux.

 Avant, une mani�re de r�soudre cela �tait d'utiliser le Frame
 relay/ATM et de cr�er des circuits virtuels. Cela fonctionne, mais les
 r�seaux Frame Relay ne sont pas suffisament maill�s et ATM est
 terriblement inefficace dans le transport du trafic IP. Ni l'un ni
 l'autre ne poss�de de moyens standardis�s pour distribuer le trafic
 sur diff�rents circuits virtuels (VC).

 Cependant, si vous utilisez ATM, Linux peut habilement r�aliser des
 t�ches de classification de trafic pour vous.  Une autre mani�re de
 proc�der consiste � commander plusieurs connexions s�par�es mais ce
 n'est ni pratique ni �l�gant et �a ne r�soudra pas tous vos probl�mes.

 CBQ � la rescousse !

 Clairement, nous avons ici deux classes principales, "ISP" et
 "Office".  Au d�part, on ne se pr�occupe pas vraiment de ce que les
 divisions font de leur bande passante, et donc, nous ne subdiviserons
 pas plus loin leurs classes.

 Nous d�cidons que les clients devront toujours avoir 8 Mbits de trafic
 descendant garanti, et nos bureaux 2 Mbits.

 La configuration du contr�le de trafic est faite avec l'outil tc, du
 paquet iproute2.



      # tc qdisc add dev eth0 root handle 10: cbq bandwidth 10Mbit avpkt 1000





 Bon, beaucoup de chiffres ici. Qu'avons-nous fait ?  Nous avons
 configur� la gestion de la mise en file d'attente (queuing discipline)
 de eth0. Par "root", nous signifions que cette file d'attente est la
 racine. Nous lui avons donn� la r�f�rence (handle) "10:".  Nous
 voulons faire du "CBQ", nous le mentionnons donc sur la ligne de
 commande. Nous indiquons au noyau qu'il peut allouer 10 Mbits et que
 la taille moyenne d'un paquet est aux alentours de 1000 octets.

 FIXME: Re-v�rifier avec Alexey que le calcul de la cellule int�gr�e
 est suffisant.

 FIXME: Avec un MTU de 1500, la cellule par d�faut est calcul�e de la
 m�me fa�on que dans l'ancien exemple.

 FIXME: J'ai v�rifi� les sources (espaces utilisateur et noyau), on
 doit pouvoir l'omettre sans probl�me.

 Maintenant, nous devons g�n�rer notre classe racine, � partir de
 laquelle toutes les autres descendront :


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




 Encore des nombres � g�rer - l'impl�mentation CBQ dans Linux est tr�s
 g�n�rique. Avec "parent 10:0", nous indiquons que cette classe descend
 de la file d'attente racine g�n�r�e plus t�t, et r�f�renc�e par "10:".
 Avec "classid 10:1", nous baptisons cette nouvelle classe.

 Nous ne disons vraiment rien de plus au noyau. Nous g�n�rons
 simplement une classe qui englobe toute la bande passante disponible
 sur l'interface.  Nous avons aussi sp�cifi� que le MTU (plus l'en-
 t�te) est de 1514 octets.  Nous appliquons une pond�ration � cette
 classe avec un param�tre de r�glage de 1 Mbit.

 Maintenant, nous cr�ons notre classe ISP :


      # tc class add dev eth0 parent 10:1 classid 10:100 cbq bandwidth 10Mbit rate \
        8Mbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 1000 \
        bounded




 Nous allouons 8 Mbits et nous indiquons que cette classe ne doit pas
 d�passer cette limite par l'ajout du param�tre "bounded".  Autrement,
 elle aurait commenc� � emprunter de la bande passante aux autres
 classes.  De plus, cette classe pourra pr�ter sa bande passante �
 d'autres classes.  Nous en discuterons plus tard.

 Pour finir, nous g�n�rons la classe "Office" (bureau) :


      # tc class add dev eth0 parent 10:1 classid 10:200 cbq bandwidth 10Mbit rate \
        2Mbit allot 1514 weight 200Kbit prio 5 maxburst 20 avpkt 1000 \
        bounded




 Pour rendre les choses un peu plus claires, voici un diagramme qui
 montre nos classes :



      +-------------[10: 10Mbit]----------------------+
      |+-------------[10:1 root 10Mbit]--------------+|
      ||                                             ||
      || +-[10:100 8Mbit]-+ +--[10:200 2Mbit]-----+  ||
      || |                | |                     |  ||
      || | ISP            | |  Office             |  ||
      || |                | |                     |  ||
      || +----------------+ +---------------------+  ||
      ||                                             ||
      |+---------------------------------------------+|
      +-----------------------------------------------+




 Nous avons maintenant indiqu� au noyau quelles sont nos classes, mais
 pas encore comment g�rer les files d'attente.  Nous le faisons �
 pr�sent, d'un seul coup pour les deux classes.
      # tc qdisc add dev eth0 parent 10:100 sfq quantum 1514b perturb 15
      # tc qdisc add dev eth0 parent 10:200 sfq quantum 1514b perturb 15




 Dans ce cas, nous installons le gestionnaire de mise en file d'attente
 Stochastic Fairness Queueing (approx. "statistiquement �quitable") ou
 sfq, qui n'est pas vraiment le plus �quitable, mais qui marche bien
 pour les grandes bandes passantes, sans utiliser trop de temps CPU. Il
 existe d'autres gestionnaires de file d'attente qui sont meilleurs,
 mais qui n�cessitent plus de temps CPU.  Le gestionnaire de mise en
 file d'attente Token Bucket Filter (filtre � seau de jetons) est
 souvent utilis�.

 Maintenant, la seule chose qui reste � faire est de dire au noyau
 quels sont les paquets qui appartiennent � une classe. Nous le ferons
 tout d'abord nativement avec iproute2, mais des applications plus
 int�ressantes sont possibles en combinaison avec netfilter.



      # tc filter add dev eth0 parent 10:0 protocol ip prio 100 u32 match ip dst \
        150.151.23.24 flowid 10:200

      # tc filter add dev eth0 parent 10:0 protocol ip prio 25 u32 match ip dst \
        150.151.0.0/16 flowid 10:100




 Ici, on suppose que notre soci�t� (classe Office) est cach�e derri�re
 un pare-feu avec l'adresse IP 150.151.23.24 et que toutes nos autres
 adresses IP devront �tre consid�r�es comme faisant partie de la classe
 ISP.

 La classificateur u32 est un mod�le tr�s simple ; des r�gles de
 classification plus sophistiqu�es sont possibles lorsque l'on utilise
 netfilter pour marquer nos paquets. On peut ensuite utiliser ce
 marquage avec tc.

 Maintenant, nous avons divis� �quitablement la bande passante
 descendante, et nous avons besoin de faire la m�me chose avec le flux
 montant. Pour abr�ger, voici toutes les commandes en bloc :






















 # tc qdisc add dev eth1 root handle 20: cbq bandwidth 10Mbit avpkt 1000

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

 # tc class add dev eth1 parent 20:1 classid 20:100 cbq bandwidth 10Mbit rate \
   8Mbit allot 1514 weight 800Kbit prio 5 maxburst 20 avpkt 1000 \
   bounded

 # tc class add dev eth1 parent 20:1 classid 20:200 cbq bandwidth 10Mbit rate \
   2Mbit allot 1514 weight 200Kbit prio 5 maxburst 20 avpkt 1000 \
   bounded

 # tc qdisc add dev eth1 parent 20:100 sfq quantum 1514b perturb 15
 # tc qdisc add dev eth1 parent 20:200 sfq quantum 1514b perturb 15

 # tc filter add dev eth1 parent 20:0 protocol ip prio 100 u32 match ip src \
   150.151.23.24 flowid 20:200

 # tc filter add dev eth1 parent 20:0 protocol ip prio 25 u32 match ip src \
   150.151.0.0/16 flowid 20:100





 88..33..  QQuuee ffaaiirree ddee llaa bbaannddee ppaassssaannttee eenn eexxcc��ss ??

 Dans notre exemple, il se trouve que m�me si les clients du
 fournisseur d'acc�s ne sont pas en majorit� connect�s (disons 8 heures
 du matin), nos bureaux n'ont toujours que 2 Mbits, ce qui est un peu
 du gaspillage.

 En enlevant le param�tre "bounded", les classes pourront se pr�ter de
 la bande passante les unes aux autres.

 Il se peut que des classes ne souhaitent pas pr�ter leur bande
 passante � d'autres. Deux fournisseurs d'acc�s rivaux sur un m�me lien
 peuvent ne pas vouloir s'offrir mutuellement de la bande passante pour
 des prunes.  Dans ce cas, vous pouvez ajouter le mot-cl� "isolated" �
 la fin de vos lignes "tc class add".


 88..44..  SSuubbddiivviissiioonnss ddee ccllaasssseess

 FIXME: suppositions qui n'ont pas du tout �t� test�es !  Les essayer
  !

 Nous pouvons aller plus loin. Supposons que tous les employ�s d�cident
 de lancer leur client "napster", il est toujours possible que notre
 base de donn�es de routage d�passe la capacit� de bande passante. Pour
 ce cas de figure, nous cr�ons deux sous-classes, "Human" et
 "Database".

 Notre base de donn�es a toujours besoin de 500 Kbits, il nous reste
 donc 1,5 Mbits pour la consommation de la classe "Human".

 Nous devons donc cr�er deux nouvelles classes � l'int�rieur de la
 classe Office :







 # tc class add dev eth0 parent 10:200 classid 10:250 cbq bandwidth 10Mbit rate \
   500Kbit allot 1514 weight 50Kbit prio 5 maxburst 20 avpkt 1000 \
   bounded

 # tc class add dev eth0 parent 10:200 classid 10:251 cbq bandwidth 10Mbit rate \
   1500Kbit allot 1514 weight 150Kbit prio 5 maxburst 20 avpkt 1000 \
   bounded




 FIXME: Finir cet exemple!


 88..55..  ��qquuiilliibbrraaggee ddee cchhaarrggee ssuurr pplluussiieeuurrss iinntteerrffaacceess

 FIXME: document TEQL


 99..  DD''aauuttrreess ggeessttiioonnnnaaiirreess ddee mmiissee eenn ffiillee dd''aatttteennttee ((qquueeuueeiinngg ddiissccii��
 pplliinneess))

 Le noyau Linux nous offre beaucoup de gestionnaires de mises en file
 d'attente.  Le plus largement utilis� est de loin la file d'attente
 pfifo_fast, qui est celle par d�faut. Cela explique aussi pourquoi ces
 fonctionnalit�s avanc�es sont si robustes. Un autre mod�le de file
 d'attente ne co�te rien en d�veloppement.

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


 99..11..  ppffiiffoo__ffaasstt

 Cette file d'attente, comme son nom l'indique (fifo = premier entr�,
 premier sorti), signifie qu'il n'y a pas de traitement sp�cial pour
 les paquets re�us.  En fait, ce n'est pas tout � fait vrai. Cette file
 d'attente a trois "bandes".  � l'int�rieur de chacune de ces bandes,
 la r�gle FIFO est appliqu�e. Cependant, tant qu'il y a un paquet en
 attente dans la "bande" 0, la "bande" 1 ne sera pas trait�e. Il en va
 de m�me pour la "bande" 1 et la "bande" 2.


 99..22..  SSttoocchhaassttiicc FFaaiirrnneessss QQuueeuueeiinngg

 SFQ, comme dit pr�c�demment, n'est pas vraiment d�terministe, mais
 marche (en moyenne). Ses principaux avantages sont qu'elle a besoin de
 peu de CPU et de m�moire. Une v�ritable mise en file d'attente
 �quitable n�cessite que le noyau garde une trace de toutes les
 sessions courantes.

 Stochastic Fairness Queueing (SFQ) est une impl�mentation simple de la
 famille des algorithmes de mise en file d'attente �quitable.  Cette
 impl�mentation est moins pr�cise, mais n�cessite aussi moins de
 calculs que les autres tout en �tant presque parfaitement �quitable.

 Le concept cl� dans SFQ est la conversation (ou flux), qui est une
 s�quence de paquets de donn�es ayant suffisamment de param�tres
 communs pour les distinguer des autres conversations. Les param�tres
 utilis�s dans le cas de paquets IP sont les adresses de source et de
 destination, ainsi que le num�ro de protocole.

 SFQ consiste en l'allocation dynamique de files d'attente FIFO, une
 par conversation. Le gestionnaire de mise en file d'attente travaille
 en tourniquet (round-robin), envoyant un paquet de chaque FIFO �
 chaque tour.  C'est pour cette raison qu'il est r�put� �quitable.  Le
 principal avantage de SFQ est qu'il autorise le partage �quitable du
 lien entre plusieurs applications et �vite la monopolisation de la
 bande passante par un client. SFQ ne peut cependant pas distinguer les
 flux interactifs des flux de masse. On a, en g�n�ral, recours � CBQ
 pour effectuer cette distinction, et diriger le flux de masse vers
 SFQ.  [NdT : par flux de masse, il faut entendre gros flot de donn�es,
 transmis en continu, comme un transfert FTP, par opposition � un flux
 interactif, comme celui g�n�r� par des requ�tes HTTP].


 99..33..  TTookkeenn BBuucckkeett FFiilltteerr

 Le Token Bucket Filter (TBF) est une file d'attente simple.  Elle ne
 fait que passer les paquets entrants avec un taux de transfert dont
 les limites sont fix�es administrativement. Il est possible de placer
 en m�moire tampon de courtes rafales de donn�es.

 L'impl�mentation TBF consiste en un tampon (seau), constamment rempli
 par des morceaux d'informations virtuelles appel�s jetons, avec un
 d�bit sp�cifique (d�bit de jeton). Le param�tre le plus important du
 tampon est sa taille, qui est le nombre de jetons qu'il peut stocker.

 Chaque jeton arrivant laisse sortir un paquet de donn�es entrant de la
 file d'attente. Ce paquet est alors effac� du seau. L'association de
 cet algorithme avec les deux flux de jetons et de donn�es, nous donne
 trois sc�narios possibles :


 �  Les donn�es arrivent dans TBF avec un d�bit _�_g_a_l au d�bit des
    jetons entrants. Dans ce cas, chaque paquet entrant a son jeton
    correspodant et passe la file d'attente sans d�lai.

 �  Les donn�es arrivent dans TBF avec un d�bit _p_l_u_s _p_e_t_i_t que le d�bit
    des jetons.  Seuls quelques jetons sont supprim�s quand les paquets
    de donn�es sortent de la file d'attente. Les jetons s'accumulent
    donc jusqu'� atteindre la taille du tampon. Les jetons en r�serve
    peuvent �tre utilis�s pour envoyer des donn�es avec un d�bit
    sup�rieur au d�bit des jetons, si de courtes rafales de donn�es
    arrivent.

 �  Les donn�es arrivent dans TBF avec un d�bit _p_l_u_s _g_r_a_n_d que le d�bit
    des jetons.  Dans ce cas, un d�passement de filtre a lieu. Les
    donn�es entrantes peuvent �tre envoy�es sans perte jusqu'� ce que
    les jetons accumul�s soient utilis�s. Apr�s, les paquets au-dessus
    de la limite sont �limin�s.


 Le dernier sc�nario est tr�s important, parce qu'il autorise la mise
 en forme administrative de la bande passante disponible pour les
 donn�es traversant le filtre. L'accumulation de jetons autorise
 l'�mission de courtes rafales de donn�es sans perte, mais toute
 surcharge restante causera la perte syst�matique des paquets.

 Le noyau Linux semble aller au-del� de cette sp�cification, et nous
 autorise aussi � limiter la vitesse de la transmission par rafales.
 Cependant, Alexey nous avertit :


      Noter que le d�bit de pointe de TBF est beaucoup plus coriace : avec
      un MTU � 1500, P_crit = 150 Koctets/s.  Donc, si vous avez besoin d'un
      d�bit de pointe plus grand, utilisez une alpha avec HZ=1000 :-)


 FIXME: Est-ce encore vrai avec TSC (pentium+) ou �quivalent ?


 FIXME: Si ce n'est pas le cas, ajouter une section sur l'augmentation
 de fr�quence


 99..44..  RRaannddoomm EEaarrllyy DDeetteecctt

 RED comporte quelques finesses suppl�mentaires.  Quand une session
 TCP/IP d�marre, on ne conna�t pas la bande passante disponible. TCP/IP
 commence donc � transmettre lentement et va de plus en plus vite, mais
 est limit� par le temps de latence au bout duquel les ACKs
 (acquittements) reviennent.

 Une fois qu'un lien est satur�, RED commence � �liminer des paquets,
 ce qui indique � TCP/IP que le lien est congestionn�, et qu'il devrait
 ralentir.  La finesse r�side dans le fait que RED simule la congestion
 r�elle, et commence parfois � �liminer des paquets avant que le lien
 ne soit compl�tement satur�. Une fois que le lien est compl�tement
 satur�, il se comporte comme un contr�leur normal.

 Pour plus d'informations sur le sujet, voir le chapitre Dorsale.


 99..55..  IInnggrreessss ppoolliicceerr qqddiisscc


 Ingress qdisc sert si vous avez besoin de limiter le d�bit d'un h�te
 sans l'aide de routeurs ou d'autres machines Linux. Vous pouvez g�rer
 la bande passante entrante et jeter des paquets quand cette bande
 passante d�passe le d�bit d�sir�. Cela peut, par exemple, pr�server
 votre h�te d'une attaque SYN flood. Cela peut aussi servir � ralentir
 TCP/IP, qui r�agit � la perte des paquets par la r�duction de la
 vitesse.

 FIXME: au lieu d'�liminer des paquets, pouvons-nous �galement les
 envoyer vers une vraie file d'attente ?

 FIXME: la mise en forme en �liminant des paquets semble moins
 d�sirable que d'utiliser, par exemple, un filtre token bucket. Pas s�r
 cependant, les routeurs Cisco travaillent de cette mani�re, et les
 gens semblent en �tre contents.

 Voir la r�f�rence ``IOS Committed Access Rate'' � la fin de ce
 document.



 En r�sum�, vous pouvez utiliser cela pour limiter la vitesse de
 t�l�chargement des fichiers et, donc, laisser plus de bande passante
 disponible pour les autres.

 Voir la section sur la protection de votre h�te des attaques SYN flood
 pour un exemple de la mani�re dont cela marche.


 1100..  NNeettffiilltteerr eett iipprroouuttee -- mmaarrqquuaaggee ddee ppaaqquueettss

 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.kernelnotes.org/unreliable-guides/>.

 Netfilter nous permet de filtrer les paquets, ou de d�sosser leurs en-
 t�tes.  Une de ses fonctionnalit�s particuli�res est de pouvoir
 marquer un paquet avec un nombre, gr�ce � l'option --set-mark.


 Comme exemple, la commande suivante marque tous les paquets destin�s
 au port 25, en l'occurence 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
 ch�re, au m�gaoctet) et une qui est plus lente, mais avec un tarif
 moins �lev�. Nous souhaiterions que le courrier passe par la route la
 moins ch�re.

 Nous avons d�j� marqu� le paquet avec un "1" et nous allons maintenant
 renseigner la base de donn�es de la politique de routage pour qu'elle
 agisse sur ces paquets marqu�s.



      # 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 g�n�rer la table mail.out avec une route vers
 la ligne lente, mais peu co�teuse.


      # /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 y a beaucoup de moyens de le faire. Nous pouvons
 modifier la configuration de netfilter pour exclure certains h�tes, ou
 nous pouvons ins�rer une r�gle avec une priorit� plus faible qui
 pointe sur la table principale pour nos h�tes faisant exception.

 Nous pouvons aussi utiliser cette fonctionnalit� pour nous conformer
 aux bits TOS en marquant les paquets avec diff�rents types de service
 et les nombres correspondants. On cr�e ensuite les r�gles qui agissent
 sur ces types de service. De cette fa�on, on peut d�dier une ligne
 RNIS aux connexions interactives.

 Inutile de la dire, cela marche parfaitement sur un h�te qui fait de
 la translation d'adresse (NAT), autrement dit du "masquerading".

 Note : pour ce faire, 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/?]

 1111..  DD''aauuttrreess ccllaassssiiffiiccaatteeuurrss


 Les classificateurs sont les moyens par lesquels le noyau d�cide dans
 quelle file d'attente un paquet sera plac�. Il y a divers
 classificateurs, chacun d'eux pouvant �tre utilis� pour diff�rents
 buts.


    ffww Base la d�cision sur la fa�on dont la pare-feu a marqu� les
       paquets.


    uu3322
       Base la d�cision sur les champs � l'int�rieur du paquet
       (c'est-�-dire l'adresse IP source, etc.)


    rroouuttee
       Base la d�cision sur la route � emprunter par le paquet.


    rrssvvpp,, rrssvvpp66
       Base la d�cision sur la cible (destination, protocole) et,
       optionnellement, sur la source (je pense).


    ttcciinnddeexx
       FIXME: Remplissez-moi

 Notez qu'il y a g�n�ralement plusieurs mani�res de classifier un
 paquet.  Cela d�pend du syst�me de classification que vous souhaitez
 utiliser.

 Les classificateurs acceptent en g�n�ral quelques arguments communs.
 Ils sont list�s ici pour des raisons pratiques :


    pprroottooccooll
       Le protocole que ce classificateur acceptera.  G�n�ralement, on
       n'acceptera que le trafic IP. Exig�.


    ppaarreenntt
       La r�f�rence � laquelle ce classificateur est attach�.  Cette
       r�f�rence doit �tre une classe d�j� existante. Exig�.


    pprriioo
       La priorit� de ce classificateur.  Les plus grand nombres seront
       test�s en premier.


    hhaannddllee
       Cette r�f�rence a plusieurs significations suivant les
       diff�rents filtres.

       FIXME: En ajouter d'autres

 Toutes les sections suivantes supposeront que vous essayez de mettre
 en forme le trafic allant vers HostA. Ces sections suppposeront que la
 classe racine a �t� configur�e sur 1: et que la classe vers laquelle
 vous voulez envoyer le trafic s�lectionn� est 1:1.



 1111..11..  LLee ccllaassssiiffiiccaatteeuurr ""ffww""

 Le classificateur "fw" s'appuie sur le marquage des paquets � mettre
 en forme par le pare-feu.  Donc, nous configurerons d'abord le pare-
 feu pour les marquer :



      # iptables -I PREROUTING -t mangle -p tcp -d HostA \
       -j MARK --set-mark 1




 Maintenant, tous les paquets vers cette machine (HostA) sont balis�s
 avec la marque 1. � pr�sent, nous construisons les r�gles de mise en
 forme pour mettre en forme les paquets. Nous avons juste besoin
 d'indiquer que les paquets balis�s avec la marque 1 vont vers la
 classe 1:1. C'est fait par la commande suivante :



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




 Cela devrait se comprendre de soi-m�me. On attache � la classe 1:0 un
 filtre avec la priorit� 1 pour filtrer tous les paquets marqu�s � 1
 par le pare-feu vers la classe 1:1.  Noter l'utilisation du param�tre
 "handle" pour indiquer la marque attendue.

 C'est tout ce qu'il y a � faire ! C'est le proc�d� le plus simple (�
 mon humble avis). Je pense que les autres proc�d�s sont plus
 difficiles � comprendre. Notez que toute la puissance du pare-feu peut
 �tre utilis�e avec ce classificateur.  Cela inclut l'analyse des
 adresses MAC, des identificateurs d'utilisateurs (user ID) et tout ce
 que le firewall peut traiter.


 1111..22..  LLee ccllaassssiiffiiccaatteeuurr ""uu3322""

 Le filtre u32 est le filtre le plus avanc� dans l'impl�mentation
 courante.  Il est enti�rement bas� sur des tables de hachage, ce qui
 le rend robuste quand il y a beaucoup de r�gles de filtrage.

 Dans sa forme la plus simple, le filtre u32 est une liste
 d'enregistrements, chacun consistant en deux champs : un s�lecteur et
 une action. Les s�lecteurs, d�crits ci-dessous, sont compar�s avec le
 paquet IP trait� jusqu'� la premi�re correspondance, et l'action
 associ�e est accomplie.  Le type d'action le plus simple serait de
 diriger le paquet vers une classe CBQ d�finie.

 La ligne de commande du programme filtre tc, utilis� pour configurer
 le filtre, consiste en trois parties : la sp�cification du filtre, un
 s�lecteur et une action.  La sp�cification du filtre peut �tre d�finie
 comme :



      tc filter add dev IF [ protocol PROTO ]
                           [ (preference|priority) PRIO ]
                           [ parent CBQ ]



 Le champ protocol d�crit 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 d�finit. C'est important dans la mesure o�
 vous pouvez avoir plusieurs filtres (listes de r�gles) avec des
 priorit�s diff�rentes.  Chaque liste sera scrut�e dans l'ordre d'ajout
 des r�gles. Alors, la liste avec la priorit� la plus faible (celle qui
 a le num�ro de pr�f�rence le plus �lev�) sera trait�e.  Le champ
 parent d�finit le sommet de l'arbre CBQ (par ex. 1:0) auquel le filtre
 doit �tre attach�.

 Les options d�crites s'appliquent � tous les filtres, pas seulement �
 u32.


 1111..22..11..  LLee ss��lleecctteeuurr UU3322

 Le s�lecteur U32 contient la d�finition d'un mod�le, qui sera compar�
 au paquet trait�. Plus pr�cis�ment, il d�finit quels bits doivent
 correspondre dans l'en-t�te du paquet, et rien de plus, mais cette
 m�thode simple est tr�s puissante. Jetons un oeil sur l'exemple
 suivant, directement tir� d'un filtre assez complexe r�ellement
 existant :



      # 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 c�t� la premi�re ligne - tous ces
 param�tres d�crivent les tables de hachage du filtre. Focalisons-nous
 sur la ligne de s�lection contenant le mot-cl� match.  Ce s�lecteur
 fera correspondre les en-t�tes 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 d�marrer au d�calage
 sp�cifi� (en octets) - dans notre cas, c'est au d�but du paquet.
 Traduisons tout cela en langage humain : le paquet correspondra si son
 champ Type de Service (TOS) a le bit "faible d�lai" positionn�.
 Analysons une autre r�gle :



      # 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 d�signe l'en-t�te suivant encapsul� dans le paquet
 IP, c'est � dire celui du protocole de la couche sup�rieure.  La
 correspondance commencera �galement au d�but du prochain en-t�te.
 Elle devrait avoir lieu dans le deuxi�me mot de 32 bits de l'en-t�te.
 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 d�cimal, 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 s�lecteur suivant tr�s
 facile � lire : match c0a80100/ffffff00 at 16. Ce que nous avons ici,
 c'est une correspondance de trois octets au 17�me octet, en comptant �
 partir du d�but de l'en-t�te IP. Cela correspond aux paquets qui ont
 une adresse de destination quelconque dans le r�seau 192.168.1/24.
 Apr�s avoir analys� les exemples, nous pouvons r�sumer ce que nous
 avons appris.


 1111..22..22..  SS��lleecctteeuurrss gg��nn��rraauuxx

 Les s�lecteurs g�n�raux d�finissent le mod�le, le masque et le
 d�calage qui seront compar�s au contenu du paquet. En utilisant les
 s�lecteurs g�n�raux, vous pouvez rechercher des correspondances sur
 n'importe quel bit de l'en-t�te IP (ou des couches sup�rieures). Ils
 sont quand m�me plus difficiles � �crire et � lire que les s�lecteurs
 sp�cifiques d�crits ci-dessus. La syntaxe g�n�rale des s�lecteurs
 est :



      match [ u32 | u16 | u8 ] PATTERN MASK [ at OFFSET | nexthdr+OFFSET]





 Un des mots-cl�s u32,u16 ou u8 doit sp�cifier la longueur du mod�le en
 bits. PATTERN et MASK se rapporteront � la longueur d�finie par ce
 mot-cl�. Le param�tre OFFSET est le d�calage, en octets, pour le
 d�marrage de la recherche de correspondance. Si le mot-clef nexthdr+
 est pr�sent, le d�calage sera relatif � l'en-t�te de la couche r�seau
 sup�rieure.


 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 r�gle si sa "dur�e de vie" (TTL) est de
 64.  TTL est le champ d�marrant juste apr�s le 8�me octet de l'en-t�te
 IP.



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





 Cette r�gle correspondra seulement aux paquets TCP avec le bit ACK
 positionn�. Ici, nous pouvons voir un exemple d'utilisation de deux
 s�lecteurs, le r�sultat final �tant un ET logique de leurs r�sultats.
 Si vous jetez un oeil sur un sch�ma de l'en-t�te TCP, vous pouvez voir
 que le bit ACK est le second bit (0x10) du 14�me octet de l'en-t�te
 TCP (at nexthdr+13). Comme second s�lecteur, si vous voulez vous
 compliquer la vie, vous pouvez �crire match u8 0x06 0xff at 9 � la
 place du s�lecteur sp�cifique protocol tcp, puisque 6 est le num�ro du
 protocole TCP, sp�cifi� au 10�me octet de l'en-t�te IP. En revanche,
 dans cet exemple, vous ne pourrez pas utiliser de s�lecteur sp�cifique
 pour la premi�re correspondance, simplement parce qu'il n'y a pas de
 s�lecteur sp�cifique pour d�signer les bits TCP ACK.


 1111..22..33..  LLeess ss��lleecctteeuurrss sspp��cciiffiiqquueess

 La table suivante contient la liste de tous les s�lecteurs sp�cifiques
 que les auteurs de cette section ont trouv�s 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 s�par�
 "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




 La r�gle ci-dessus correspondra � des paquets qui ont le champ TOS
 �gal � 0x10. Le champ TOS commence au deuxi�me octet du paquet et
 occupe 1 octet, ce qui nous permet d'�crire un s�lecteur g�n�ral
 �quivalent : match u8 0x10 0xff at 1. Cela nous donne une indication
 sur l'impl�mentation du filtre u32 ; les r�gles sp�cifiques sont
 toujours traduites en r�gles g�n�rales, et c'est sous cette forme
 qu'elles sont stock�es en m�moire par le noyau.  Cela am�ne � une
 autre conclusion : les s�lecteurs tcp et udp sont exactement les m�mes
 et c'est la raison pour laquelle vous ne pouvez pas utiliser un simple
 s�lecteur match tcp dst 53 0xffff pour d�signer un paquet TCP envoy�
 sur un port donn� : cela d�signe aussi les paquets UDP envoy�s sur ce
 port. Vous devez �galement sp�cifier le protocole avec la r�gle
 suivante :


      # tc filter add dev ppp0 parent 1:0 prio 10 u32 \
              match tcp dst 53 0xffff \
              match ip protocol 0x6 0xff \
              flowid 1:2






 1111..33..  LLee ccllaassssiiffiiccaatteeuurr ""rroouuttee""


 Ce classificateur filtre en se basant sur le r�sultat des tables de
 routage. Quand un paquet passant � travers les classes en atteint une
 qui est marqu�e 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,
 puisqu'il est racine, arrive imm�diatement), il consulte la table de
 routage et si une entr�e de la table correspond, il envoie le paquet
 vers la classe donn�e et lui donne une priorit� de 100. Ensuite, pour
 finalement activer les choses, vous ajoutez l'entr�e de routage
 appropri�e.

 L'astuce ici est de d�finir "realm" en se basant soit sur la
 destination, soit sur la source. Voici la fa�on de faire cela :



      # ip route add Host/Network via Gateway dev Device realm RealmNumber




 Par exemple, nous pouvons d�finir notre r�seau 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 repr�senter les r�seaux ou les h�tes et sp�cifier 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 r�gle ci-dessus indique que les paquets allant vers le r�seau
 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-r�seau 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 sp�cifie que les paquets venant du r�seau 192.168.2.0
 (realm 2) correspondront � la classe 1:2.


 1111..44..  LLee ccllaassssiiffiiccaatteeuurr ""rrssvvpp""

 FIXME: � remplir


 1111..55..  LLee ccllaassssiiffiiccaatteeuurr ""ttcciinnddeexx""

 FIXME: � remplir


 1122..  PPaarraamm��ttrreess rr��sseeaauu dduu nnooyyaauu

 Le noyau utilise de nombreux param�tres qui peuvent �tre ajust�s en
 diff�rentes circonstances. Bien que, comme d'habitude, les param�tres
 par d�faut conviennent � 99% des installations, nous ne pourrions pas
 appeler ce document "HOWTO avanc�" sans en dire un mot.

 Les �l�ments int�ressants sont dans /proc/sys/net, jetez-y un oeil.
 Tout ne sera pas document� ici au d�part, mais nous y travaillons.


 1122..11..  FFiillttrraaggee dduu CChheemmiinn IInnvveerrssee ((RReevveerrssee PPaatthh FFiilltteerriinngg))

 Par d�faut, les routeurs routent tout, m�me les paquets qui
 visiblement n'appartiennent pas � votre r�seau. Un exemple courant est
 l'espace des adresses IP priv�es 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 d�sactiver cette fonctionnalit�. Les
 d�veloppeurs 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 m�thode est appel�e "Reverse Path Filtering" (Filtrage par
 chemin inverse). Pour faire simple, si la r�ponse � 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 d�but, si un paquet arrivant sur le routeur
 Linux par eth1 pr�tend venir du r�seau Bureau+FAI, il sera �limin�.
 De m�me, si un paquet arrivant du r�seau Bureau pr�tend �tre de
 quelque part � l'ext�rieur du pare-feu, il sera �galement �limin�.

 Ce qui est pr�sent� ci-dessus est le filtrage de chemin inverse
 complet.  Le param�trage par d�faut filtre seulement sur les adresses
 IP des r�seaux directement connect�s. Ce param�trage par d�faut est
 utilis� parce que le filtrage complet �choue dans le cas d'un routage
 asym�trique (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 r�seau.
 Les donn�es descendent vers la parabole satellite et les r�ponses
 repartent par des lignes terrestres normales).

 Si cette exception s'applique dans votre cas (vous devriez �tre au
 courant), vous pouvez simplement d�sactiver le rp_filter sur
 l'interface d'arriv�e des donn�es satellite. Si vous voulez voir si
 des paquets sont �limin�s, le fichier log_martians du m�me r�pertoire
 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


 1122..22..  CCoonnffiigguurraattiioonnss oobbssccuurreess

 Bon, il y a beaucoups de param�tres qui peuvent �tre modifi�s.  Nous
 essayons de tous les lister. Voir aussi une documentation partielle
 dans Documentation/ip-sysctl.txt.

 Certaines de ces configurations ont des valeurs par d�faut diff�rentes
 suivant que vous r�pondez "Yes" ou "No" � la question "Configure as
 router and not host" lors de la compilation du noyau.


 1122..22..11..  iippvv44 gg��nn��rriiqquuee

 En remarque g�n�rale, les fonctionnalit�s de limitation de d�bit ne
 fonctionnent pas sur loopback, donc n'essayez pas de les tester
 localement.


    //pprroocc//ssyyss//nneett//iippvv44//iiccmmpp__ddeessttuunnrreeaacchh__rraattee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iiccmmpp__eecchhoo__iiggnnoorree__aallll
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iiccmmpp__eecchhoo__iiggnnoorree__bbrrooaaddccaassttss [[UUsseeffuull]]
       Si vous pinguez l'adresse de diffusion d'un r�seau, tous les
       h�tes sont cens�s r�pondre. Cela permet de coquettes attaques de
       d�ni de service.  Mettez cette valeur � 1 pour ignorer ces
       messages de diffusion.


    //pprroocc//ssyyss//nneett//iippvv44//iiccmmpp__eecchhoorreeppllyy__rraattee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iiccmmpp__iiggnnoorree__bboogguuss__eerrrroorr__rreessppoonnsseess
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iiccmmpp__ppaarraammpprroobb__rraattee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iiccmmpp__ttiimmeeeexxcceeeedd__rraattee
       Voici la c�l�bre cause des "�toiles Solaris" dans traceroute.
       Limite le nombre de messages ICMP Time Exceeded envoy�s.  FIXME:
       Unit� de ces "rates" ? Soit je suis stupide, soit �a ne
       fonctionne pas.

    //pprroocc//ssyyss//nneett//iippvv44//iiggmmpp__mmaaxx__mmeemmbbeerrsshhiippss
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iinneett__ppeeeerr__ggcc__mmaaxxttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iinneett__ppeeeerr__ggcc__mmiinnttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iinneett__ppeeeerr__mmaaxxttttll
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iinneett__ppeeeerr__mmiinnttttll
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iinneett__ppeeeerr__tthhrreesshhoolldd
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iipp__aauuttooccoonnffiigg
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iipp__ddeeffaauulltt__ttttll
       Dur�e de vie (TTL) des paquets. Fixez-la � la valeur s�re de 64.
       Augmentez-la si vous avez un r�seau immense, mais pas "pour
       voir" : les boucles sans fin d'un mauvais routage sont plus
       dangereuses si le TTL est �lev�.  Vous pouvez m�me envisager de
       diminuer la valeur dans certaines circonstances.


    //pprroocc//ssyyss//nneett//iippvv44//iipp__ddyynnaaddddrr
       Vous aurez besoin de positionner cela si vous utilisez la
       connexion � la demande avec une adresse d'interface dynamique.
       Une fois que votre interface sera activ�e, tout paquet plac� en
       file d'attente sera retrait� pour avoir la bonne adresse. Cela
       r�sout le probl�me pos� par une connexion d�fectueuse ayant
       configur� une interface, suivie par une deuxi�me tentative
       r�ussie (avec une adresse IP diff�rente).


    //pprroocc//ssyyss//nneett//iippvv44//iipp__ffoorrwwaarrdd
       Le noyau doit-il essayer de transmettre les paquets ?  D�sactiv�
       par d�faut pour les h�tes, activ� par d�faut quand le noyau est
       configur� pour un routeur.


    //pprroocc//ssyyss//nneett//iippvv44//iipp__llooccaall__ppoorrtt__rraannggee
       Intervalle des ports locaux pour les connections sortantes.  En
       fait, assez petit par d�faut, 1024 � 4999.


    //pprroocc//ssyyss//nneett//iippvv44//iipp__nnoo__ppmmttuu__ddiisscc
       Configurez cela si vous voulez d�sactiver la d�couverte du MTU :
       une technique pour d�terminer le plus grand MTU possible sur
       votre chemin.


    //pprroocc//ssyyss//nneett//iippvv44//iippffrraagg__hhiigghh__tthhrreesshh
       FIXME: � remplir

    //pprroocc//ssyyss//nneett//iippvv44//iippffrraagg__llooww__tthhrreesshh
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//iippffrraagg__ttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__aabboorrtt__oonn__oovveerrffllooww
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__ffiinn__ttiimmeeoouutt
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__kkeeeeppaalliivvee__iinnttvvll
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__kkeeeeppaalliivvee__pprroobbeess
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__kkeeeeppaalliivvee__ttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__mmaaxx__oorrpphhaannss
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__mmaaxx__ssyynn__bbaacckklloogg
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__mmaaxx__ttww__bbuucckkeettss
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__oorrpphhaann__rreettrriieess
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__rreettrraannss__ccoollllaappssee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__rreettrriieess11
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__rreettrriieess22
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__rrffcc11333377
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__ssaacckk
       Utilise un ACK s�lectif qui peut �tre utilis� pour signifier
       qu'un seul paquet est manquant. Facilite ainsi une r�cup�ration
       rapide.


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__ssttdduurrgg
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__ssyynn__rreettrriieess
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__ssyynnaacckk__rreettrriieess
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__ttiimmeessttaammppss
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__ttww__rreeccyyccllee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ttccpp__wwiinnddooww__ssccaalliinngg
       TCP/IP autorise normalement des fen�tres jusqu'� une taille de
       65535 octets. Pour des r�seaux vraiment rapides, cela peut ne
       pas �tre assez. Les options "windows scaling" autorisent des
       fen�tres jusqu'au gigaoctet, ce qui est bon pour les produits �
       grande bande passante mais fort d�lai.



 1122..22..22..  CCoonnffiigguurraattiioonn pp��rriipphh��rriiqquuee ppaarr pp��rriipphh��rriiqquuee

 DEV peut d�signer soit une interface r�elle, soit "all", soit
 "default".  Default change �galement les param�tres des interfaces qui
 seront cr��es par la suite.


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//aacccceepptt__rreeddiirreeccttss
       Si un routeur d�cide que vous l'utilisez � tort (c'est-�-dire
       qu'il a besoin de r�-envoyer votre paquet sur la m�me
       interface), il vous enverra un ICMP Redirect. Cela pr�sente
       cependant un petit risque pour la s�curit�, et vous pouvez le
       d�sactiver, ou utiliser les redirections s�curis�es.


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//aacccceepptt__ssoouurrccee__rroouuttee
       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.


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//bboooottpp__rreellaayy
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//ffoorrwwaarrddiinngg
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//lloogg__mmaarrttiiaannss
       Voir la section sur le "reverse path filters"


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//mmcc__ffoorrwwaarrddiinngg
       Si vous faites de la transmission multidiffusion (multicast) sur
       cette interface.

    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//pprrooxxyy__aarrpp
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//rrpp__ffiilltteerr
       Voir la section sur le "reverse path filters"


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//sseeccuurree__rreeddiirreeccttss
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//sseenndd__rreeddiirreeccttss
       Si vous employez les redirections mentionn�es ci-dessus.


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//sshhaarreedd__mmeeddiiaa
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//ccoonnff//DDEEVV//ttaagg
       FIXME: � remplir



 1122..22..33..  PPoolliittiiqquuee ddee vvooiissiinnaaggee

 DEV peut d�signer soit une interface r�elle, soit "all", soit
 "default".  Default change �galement les param�tres des interfaces qui
 seront cr��es par la suite.


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//aannyyccaasstt__ddeellaayy
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//aapppp__ssoolliicciitt
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//bbaassee__rreeaacchhaabbllee__ttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//ddeellaayy__ffiirrsstt__pprroobbee__ttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//ggcc__ssttaallee__ttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//lloocckkttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//mmccaasstt__ssoolliicciitt
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//pprrooxxyy__ddeellaayy
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//pprrooxxyy__qqlleenn
       FIXME: � remplir
    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//rreettrraannss__ttiimmee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//uuccaasstt__ssoolliicciitt
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//nneeiigghh//DDEEVV//uunnrreess__qqlleenn
       FIXME: � remplir



 1122..22..44..  CCoonnffiigguurraattiioonn dduu rroouuttaaggee


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//eerrrroorr__bbuurrsstt
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//eerrrroorr__ccoosstt
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//fflluusshh
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//ggcc__eellaassttiicciittyy
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//ggcc__iinntteerrvvaall
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//ggcc__mmiinn__iinntteerrvvaall
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//ggcc__tthhrreesshh
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//ggcc__ttiimmeeoouutt
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//mmaaxx__ddeellaayy
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//mmaaxx__ssiizzee
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//mmiinn__aaddvv__mmssss
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//mmiinn__ddeellaayy
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//mmiinn__ppmmttuu
       FIXME: � remplir
    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//mmttuu__eexxppiirreess
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//rreeddiirreecctt__llooaadd
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//rreeddiirreecctt__nnuummbbeerr
       FIXME: � remplir


    //pprroocc//ssyyss//nneett//iippvv44//rroouuttee//rreeddiirreecctt__ssiilleennccee
       FIXME: � remplir



 1133..  AApppplliiccaattiioonn dduu ccoonnttrr��llee ddee ttrraaffiicc aauuxx ddoorrssaalleess

 Ce chapitre est con�u comme une introduction au routage de dorsales
 (backbones).  Ces liaisons impliquent souvent des bandes passantes
 sup�rieures � 100 m�gabits/s, ce qui n�cessite une approche diff�rente
 de celle de votre modem ADSL � la maison.


 1133..11..  FFiilleess dd''aatttteennttee ddee rroouutteeuurrss

 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 d�borde. 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 entra�nera une rafale de retransmissions retard�e
 qui inondera � nouveau le routeur congestionn�.

 Dans le but d'en finir avec les congestions occasionnelles des liens,
 les routeurs de dorsales int�grent souvent des files d'attente de
 grande taille. Malheureusement, bien que ces files d'attente offrent
 un bon d�bit, elles peuvent augmenter sensiblement les temps de
 latence et entra�ner un comportement tr�s saccad� des connections TCP
 pendant la congestion.

 Ces probl�mes avec le "tail-drop" deviennent de plus en plus
 pr�occupants avec l'augmentation de l'utilisation d'applications
 hostiles au r�seau. Le noyau Linux nous offre la technique RED,
 abr�viation de Random Early Detect, ou d�tection pr�coce directe.

 RED n'est pas la solution miracle � tous ces probl�mes.  Les
 applications qui n'int�grent 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 d�g�ts sur le d�bit 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 congestionn�e, cela entra�ne
 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 t�t, il conserve une file d'attente plus
 courte et des temps de latence mieux contr�l�s.  La probabilit� qu'un
 paquet soit �limin� d'une connexion particuli�re est proportionnelle �
 la bande passante utilis�e par cette connexion plut�t 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 co�t d'une
 m�morisation d'�tat par session qui est n�cessaire pour une mise en
 file d'attente vraiment �quitable.

 Pour utiliser RED, vous devez r�gler trois param�tres : 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 envoy�s "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 d�grader le d�bit et une valeur
 Min trop grande va d�grader le temps de latence.  Sur une liaison
 lente, choisir un coefficient Min petit ne peut pas remplacer une
 r�duction du MTU  pour am�liorer les temps de r�ponse.

 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 contr�le la r�ponse de l'algorithme RED aux rafales. Burst doit
 �tre choisi plus grand que min/avpkt (paquet moyen).
 Exp�rimentalement, j'ai trouv� que (min+min+max)/(3*avpkt) marche
 bien.

 De plus, vous devez configurer limit et avpkt. Limit est une valeur de
 s�curit� : 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 d�bit ayant un
 MTU de 1500 octets.

 Lire the paper on RED queueing
 <http://www.aciri.org/floyd/papers/red/red.html> par Sally Floyd et
 Van Jacobson pour les informations techniques.

 FIXME: besoin de plus d'infos. Cela d�pend de toi, Greg :-) - ahu


 1144..  RReecceetttteess ddee ccuuiissiinnee ppoouurr llaa mmiissee eenn ffoorrmmee dduu ttrraaffiicc

 Cette section contient des "recettes de cuisine" qui peuvent vous
 aider � r�soudre vos probl�mes. Un livre de cuisine ne remplace
 cependant pas une r�elle compr�hension, essayez donc d'assimiler ce
 qui suit.


 1144..11..  FFaaiirree ttoouurrnneerr pplluussiieeuurrss ssiitteess aavveecc ddiiffff��rreenntteess SSLLAA ((aauuttoorriissaa��
 ttiioonnss))

 Vous pouvez faire cela de plusieurs mani�res. Apache poss�de 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
 pr�sentation de Jamal Hadi, dont la r�f�rence est fournie ci-dessous.

 Disons que nous avons deux clients, avec http, ftp et du streaming
 audio, et que nous voulions leur vendre une largeur de bande passante
 limit�e.  Nous le ferons sur le serveur lui-m�me.


 Le client A doit disposer d'au moins 2 m�gabits, et le client B a pay�
 pour 5 m�gabits. Nous s�parons nos clients en cr�ant 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 diff�rents serveurs � la bonne adresse IP.
 Tous les d�mons 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: bandwidth 10Mbit cell 8 avpkt 1000 \
        mpu 64




 Nous cr�ons 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
 d�faut � pfifo_fast quelque part ?


 1144..22..  PPrroott��ggeerr vvoottrree mmaacchhiinnee ddeess iinnoonnddaattiioonnss SSYYNN ffllooooddss

 D'apr�s la documentation iproute d'Alexeys, adapt�e � netfilter.  Si
 vous utilisez ceci, prenez garde d'ajuster les nombres avec des
 valeurs raisonnables pour votre syst�me.


 Si vous voulez prot�ger tout un r�seau, oubliez ce script, qui est
 plus adapt� � un h�te seul.



      #! /bin/sh -x
      #
      # script simple utilisant les capacit�s 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 b�n�ficier de puissantes fonctionnalit�s sur les SYN.
      #
      # chemins vers les divers utilitaires
      # � changer en fonction des v�tres
      #
      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 associ�e
      ############################################################
      $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





 1144..33..  LLiimmiitteerr llee dd��bbiitt IICCMMPP ppoouurr eemmpp��cchheerr lleess dd��nniiss ddee sseerrvviiccee

 R�cemment, les attaques distribu�es de d�ni de service sont devenues
 une nuisance importante sur Internet. En filtrant proprement et en
 limitant le d�bit de votre r�seau, vous pouvez � la fois �viter de
 devenir victime ou source de ces attaques.

 Vous devriez filtrer vos r�seaux de telle sorte que vous n'autorisiez
 pas les paquets avec une adresse IP source non-locale � quitter votre
 r�seau. Cela emp�che les utilisateurs d'envoyer de mani�re anonyme des
 cochonneries sur Internet.



 La limitation de d�bit peut faire encore mieux, comme vu plus haut.
 Pour vous rafra�chir la m�moire, 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 d�terminer combien de trafic ICMP vous voulez
 autoriser. Vous pouvez r�aliser des mesures avec tcpdump, en �crivant
 les r�sultats dans un fichier pendant un moment, et regarder combien
 de paquets ICMP passent par votre r�seau. 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 d�bit � 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






 1144..44..  DDoonnnneerr llaa pprriioorriitt�� aauu ttrraaffiicc iinntteerraaccttiiff

 Si beaucoup de donn�es arrivent � votre lien ou en partent, et que
 vous essayez de faire de la maintenance via telnet ou ssh, cela peut
 poser probl�me : 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 pr�c�demment, nous avons besoin de manipuler le trafic dans les
 deux sens. Evidemment, cela marche mieux s'il y a des machines Linux
 aux deux extr�mit�s du lien, bien que d'autres UNIX soient capables de
 faire la m�me chose.  Consultez votre gourou local Solaris/BSD pour
 cela.

 Le gestionnaire standard pfifo_fast a trois "bandes" diff�rentes. Le
 trafic de la bande 0 est transmis en premier, le trafic des bandes 1
 et 2 �tant trait� apr�s. Il est vital que votre trafic interactif soit
 dans la bande 0 !  Ce qui suit est adapt� du (bient�t obsol�te)
 Ipchains-HOWTO :

 Il y a quatre bits rarement utilis�s dans l'en-t�te IP, appel�s bits
 de Type de Service (TOS). Ils affectent la mani�re dont les paquets
 sont trait�s. Les quatre bits sont "D�lai Minimum", "D�bit Maximum",
 "Fiabilit� Maximum" et "Co�t 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 "D�lai Minimum" est particuli�rement important pour moi. Je le
      positionne � 1 pour les paquets interactifs sur mon routeur (Linux)
      qui envoie le trafic vers l'ext�rieur. Je suis derri�re un modem �
      33,6 Kbps. Linux r�partit les paquets dans trois files d'attente. De
      cette mani�re, j'obtiens des performances acceptables pour le trafic
      interactif tout en t�l�chargeant en m�me temps.


 L'utilisation la plus commune est de configurer les connections telnet
 et ftp � "D�lai Minimum" et les donn�es FTP � "D�bit 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 donn�es venant d'un telnet
 ext�rieur 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









 1155..  RRoouuttaaggee aavvaanncc�� ssuurr LLiinnuuxx

 Cette section est destin�e � tous les gens qui voudraient savoir
 comment fonctionne le syst�me complet ou qui ont une configuration si
 bizarre qu'ils ont besoin d'informations "bas niveau" pour le faire
 fonctionner.

 Cette section est compl�tement facultative. Il est tout � fait
 possible qu'elle soit trop  complexe et pas vraiment destin�e aux
 utilisateurs normaux. Vous avez �t� averti.

 FIXME: D�cider ce qui doit r�ellement �tre ici.


 1155..11..  pprraattiiqquuee ??  CCoommmmeenntt llaa mmiissee eenn ffiillee dd''aatttteennttee ddeess ppaaqquueettss ffoonncc��
 ttiioonnnnee--tt--eellllee eenn

 C'est la base du fonctionnement du syst�me de mise en file d'attente
 d'un paquet.

 Lister les �tapes que le noyau r�alise pour classifier un paquet, etc.

 FIXME: � �crire.


 1155..22..  UUttiilliissaattiioonn aavvaanncc��ee dduu ssyysstt��mmee ddee mmiissee eenn ffiillee dd''aatttteennttee ddeess
 ppaaqquueettss

 Passer par l'exemple extr�mement rus� de Alexeys impliquant les bits
 inutilis�s dans le champs TOS.

 FIXME: � �crire.


 1155..33..  DD''aauuttrreess ssyysstt��mmeess ddee mmiissee eenn ffoorrmmee ddeess ppaaqquueettss

 Je voudrais inclure une br�ve description sur les autres syst�mes de
 mise en forme des paquets dans d'autres syst�mes d'exploitation et les
 comparer � celui de Linux. Puisque Linux est l'un des rares OS qui ont
 une pile TCP/IP originale (non d�riv�e de BSD), je pense qu'il serait
 int�ressant de savoir comment les autres font cela.

 Malheureusement je n'ai aucune exp�rience sur d'autres syst�mes, aussi
 je ne peux pas l'�crire.

 FIXME: Personne ? - Martijn



 1166..  RRoouuttaaggee DDyynnaammiiqquuee -- OOSSPPFF eett BBGGPP

 Si votre r�seau commence � devenir vraiment gros, ou si vous commencez
 � consid�rer Internet comme votre propre r�seau, vous avez besoin
 d'outils qui routent dynamiquement vos donn�es.  Les sites sont
 souvent reli�s entre eux par de multiples liens, et de nouveaux liens
 surgissent en permanence.

 L'Internet utilise la plupart du temps les standards OSPF et BGP4
 (rfc1771). Linux supporte les deux, par le biais de gated et zebra.

 Ce sujet est pour le moment hors du propos de ce document, mais
 laissez-nous vous diriger vers des travaux de r�f�rence :

 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 tr�s 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 sp�cifiques � Cisco, ils sont
 remarquablement semblables au langage de configuration de Zebra :-)



 1177..  LLeeccttuurreess ssuuppppll��mmeennttaaiirreess



    hhttttpp::////ssnnaaffuu..ffrreeeeddoomm..oorrgg//lliinnuuxx22..22//iipprroouuttee--nnootteess..hhttmmll
       <<http://snafu.freedom.org/linux2.2/iproute-notes.html>
       Contient beaucoup d'informations techniques, et de commentaires
       sur le noyau.


    hhttttpp::////wwwwww..ddaavviinn..oottttaawwaa..oonn..ccaa//oollss//
       <<http://www.davin.ottawa.on.ca/ols/>
       Transparents de Jamal Hadi, un des auteurs du contr�leur de
       trafic de Linux.


    hhttttpp::////ddeeffiiaanntt..ccooiinneett..ccoomm//iipprroouuttee22//iipp--ccrreeff// <<http://defi�
       ant.coinet.com/iproute2/ip-cref/>
       Version HTML de la documentation LaTeX d'Alexeys ; explique une
       partie d'iproute2 en d�tails.


    hhttttpp::////wwwwww..aacciirrii..oorrgg//ffllooyydd//ccbbqq..hhttmmll
       <<http://www.aciri.org/floyd/cbq.html>
       Sally Floyd a une bonne page sur CBQ, incluant ses publications
       originales. Aucune n'est sp�cifique � Linux, mais il y a un
       travail de discussion sur la th�orie et l'utilisation de CBQ.
       Contenu tr�s technique, mais une bonne lecture pour ceux qui
       sont int�ress�s.


    hhttttpp::////cceettii..ppll//~~eekkrraavviieettzz//ccbbqq//NNEETT44__ttcc..hhttmmll <<http://ceti.pl/~ekravi�
       etz/cbq/NET4_tc.html>
       Un autre HOWTO, en polonais ! Vous pouvez cependant
       copier/coller les lignes de commandes, elles fonctionnent de la
       m�me fa�on dans toutes les langues. L'auteur travaille en
       collaboration avec nous et sera peut �tre bient�t un auteur de
       sections de cet HOWTO.


    LLeess sseerrvviicceess ddiiffff��rreennccii��ss ssuurr LLiinnuuxx <<http://snafu.free�
       dom.org/linux2.2/docs/draft-almesberger-wajhak-diffserv-
       linux-00.txt>
       Discussion sur l'utilisation de Linux dans un environnement
       compatible diffserv. Assez loin des besoins quotidiens de votre
       routeur, mais n�anmoins tr�s int�ressant. Nous pourrons inclure
       une section sur le sujet, plus tard.


    IIOOSS CCoommmmiitttteedd AAcccceessss RRaattee <<http://www.cisco.com/uni�
       vercd/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 diff�rente
       mais les concepts sont identiques, sauf qu'on fait mieux, et
       sans mat�riel qui co�te autant qu'une voiture :-)


    TTCCPP//IIPP IIlllluussttrraatteedd,, vvoolluummee 11,, WW.. RRiicchhaarrdd SStteevveennss,, IISSBBNN
       00--220011--6633334466--99
       Sa lecture est indispensable si vous voulez r�ellement
       comprendre TCP/IP, et de plus elle est divertissante.




 1188..  RReemmeerrcciieemmeennttss


 Notre but est de faire la liste de tous les personnes qui ont
 contribu� � ce HOWTO, ou qui nous ont aid�s � expliquer le
 fonctionnement des choses.

 Alors qu'il n'existe pas de liste dans Netfilter, nous souhaitons
 saluer les personnes qui ont apport� leur aide.


 �  Jamal Hadi <hadi%cyberus.ca>

 �  Nadeem Hasan <[email protected]>

 �  Jason Lunz <[email protected]>

 �  Alexey Mahotkin <[email protected]>

 �  Pawel Krawczyk <kravietz%alfa.ceti.pl>

 �  Wim van der Most

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

 �  Song Wang <[email protected]>

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.