Ethereal - IPRoute 2 - QoS

FORMATON ETHEREAL - IPROUTE 2 - QOS
18-19-20-21 AVRIL 2005
François-Xavier GUIDET
Ethernet : les raisons du succès
Quelques principes simples
Toutes les stations sont égales vis-à-vis du réseau : il n'y a pas d'équipement maître de
contrôle du réseau.
La méthode d'accès employée est distribuée entre tous les équipements connectés.
Le mode de transmission est de type bidirectionnel alterné : les signaux transitent dans
les deux sens, mais pas
simultanément. • on peut relier ou retirer une machine du réseau sans perturber le

fonctionnement de l'ensemble.
Ces principes ont montré qu'il était plus facile de concevoir les réseaux et les équipements
correspondants avec Ethernet qu'avec d'autres technologies aux définitions plus complètes. De
nombreuses technologies réseaux «mieux définies» au départ comme Token Ring (IEEE
802.5) par exemple, se sont avérées très peu évolutives au fil du temps.
Ces principes ont été formalisés au début des années soixante-dix. Aujourd'hui, seul le mode
de transmission bidirectionnel alterné est de moins en moins employé. Le déploiement de la
commutation de niveau 2 étant généralisé, les transmissions se font sur des paires cuivre ou
fibre optique dédiées à chaque sens de communication. On parle alors de mode full duplex.
Ethernet a été intégré dans le modèle OSI
Ethernet était à l'origine un standard développé par les laboratoires Xerox au tout
début des années 1970. Ce standard a d'abord évolué jusqu'à la version Ethernet II
aussi appelée DIX ou encore v2.0 avec l'association regroupant Digital Equipment
Corporation, Intel et Xerox. Par la suite, Ethernet a été inclu dans les travaux sur la
modélisation OSI au début des années 1980. Depuis cette époque, la technologie
Ethernet est totalement indépendante des constructeurs ; c'est un des facteurs
importants de sa popularité.
Les éléments de la couche physique (couche 1 OSI) sont définis par les normes IEEE des
sous-comités 802.3 et la méthode d'accès CSMA/CD correspond à partie MAC de la couche
liaison (couche 2 OSI).
Comme dans le cas des principes énoncés ci-avant, la généralisation de la commutation

simplifie la méthode d'accès en éliminant toute la partie consacrée à la gestion des collisions.
On attache aujourd'hui beaucoup plus d'importance aux méthodes de codage employées au
niveau de la couche physique.
Une évolution constante
La simplicité de la méthode d'accès et la simplicité de l'interconnexion avec les autres

technologies ont fait d'ethernet une technologie évolutive à des coûts acceptables pour toutes
les catégories d'utilisateurs.
Même si les évolutions des débits ont entraîné l'abandon de supports bon marché (câbles
coaxiaux lors du passage de 10 à 100Mbps), la mise en oeuvre est restée simple. Les
infrastructures existantes progressent vers les technologies multimédias sans
réinvestissements lourds.
C'est une des grandes leçons de l'histoire des réseaux de télécommunications sur les trente
dernières années. Toutes les technologies de transmission qui on cherché à qualifier les flux
réseau au plus près du matériel n'ont pas su évoluer simplement. L'exemple de la technologie
ATM est caractéristique. Faire évoluer les équipements actifs ATM pour adapter les débits est
excessivement plus coûteux qu'avec des équipements Ethernet.
Au début des années 1970 : Le premier réseau local Ethernet expérimental a été développé au
centre de recherche Xerox de Palo Alto (PARC) pour interconnecter des ordinateurs et des
imprimantes laser à un débit de 2.94Mbps. En juillet 1976, les deux concepteurs de ce
réseau Bob Metcalfe et David Boggs publièrent le document de référence Ethernet:
5
Distributed Packet Switching for Local Computer Network .
En Septembre 1980 : Le premier standard Ethernet est publié. Les sociétés Intel et Digital
Equipment Corporation (DEC) ont rejoint Xerox pour produire un standard utilisable par
tous. On a baptisé ce standard DIX standard. Il correspond à la version 10Base5 ou
Ethernet «épais». Voir Section 4.1.1, « Ethernet standard ». Les premières cartes Ethernet
sont apparues avec la version 2.0 du standard DIX en Novembre 1982 : le standard
Ethernet II.
En 1983 : La première norme Ethernet est publiée par l' Institute of Electrical and Electronic
6 7
Engineers (IEEE) ; plus précisemment par le sous-comité IEEE 802.3 . C'est à cette
époque qu'est apparue la double signification d'un champ dans le format de la trame
Ethernet : le champ Type/Longueur. Cette différence entre normalisation et standard n'a
jamais eu d'effet sur l'exploitation des réseaux locaux Ethernet. Voir Section 9, « Format
de trame ».
En 1985, l'IEEE publia la norme IEEE 802.3a correspondant à l'Ethernet «fin». En 1987,
l'utilisation des fibres optiques devint effective avec la norme IEEE 802.3d.
En 1990 : La première norme utilisant les câbles de paires torsadées cuivre sur une topologie
étoile est publiée : IEEE 802.3i. C'est à partir de cette étape que les autres technologies de
réseaux locaux ont décliné rapidement.
En 1993, la norme IEEE 802.3j est venue étendre l'application de la topologie étoile sur
fibres optiques.
En 1995 : Nouvelle étape majeure dans l'évolution d'Ethernet : le passage à 100Mbps avec
l'introduction de la norme IEEE 802.3u. Cette version d'Ethernet est connue sous le nom
FastEthernet.
En 1997 : La norme IEEE 802.3x a défini le mode «full-duplex» qui permet de

reserver une paire cuivre ou fibre optique par sens de communication. Associée à
la généralisation de l'utilisation des commutateurs, cette norme marque la fin de
l'utilisation de la méthode d'accès historique d'Ethernet : CSMA/CD.
En 1998 : Les débits ont à nouveau été multipliés par 10 avec la sortie du Gigabit Ethernet.
La norme correspondante est l'IEEE 802.3z.
Cette première définition a été complétée en 1999 avec la norme IEEE 802.3ab qui définit
l'utilisation du Gbps sur les câbles en paires torsadées UTP de catégorie 5.
En 2002 : Une fois de plus, les débits ont été multipliés par 10 pour atteindre les 10Gbps avec
la publication de la norme IEEE 802.3ae. Cette catégorie de débit marque l'avènement de
l'exploitation d'Ethernet sur les dorsales des réseaux étendus.
De même qu'avec le Gigabit Ethernet, une définition d'Ethernet 10Gbps sur paires
torsadées cuivre devrait voir le jour prochainement. La norme devrait être publiée avec
8
l'appelation IEEE 802.3an .
9
L' Institute of Electrical and Electronic Engineers a mis à disposition en ligne les normes du
10
comité 802 : Get IEEE 802 .
Ce document est construit à partir des 4 familles de débits d'Ethernet :

Ethernet à 10Mbps : la définition d'origine à partir de la constitution du sous-comité
IEEE 802.3.
Ethernet à 100Mbps ou FastEthernet.
Ethernet à 1Gbps ou GigabitEthernet.
Ethernet à 10Gbps ou 10GigabitEthernet.
A l'intérieur de chaque famille, il existe de nombreuses déclinaisons. Les plus utilisées sont
décrites ci-après.
Du point de vue conception, les câblages en paires torsadées cuivre sont habituellement
utilisés pour la «desserte» des postes de travail à des débits allant de 10Mbps à 1Gbps.
Ensuite, les câblages en fibres optiques sont utilisés pour les dorsales réseau.
Bien que cela ne corresponde à aucune normalisation, on rencontre de plus en plus souvent un
découpage en 3 couches lors de la conception des réseaux locaux Ethernet : accès, distribution
et coeur. Ce découpage a surtout pour but de faciliter le classement des équipements dans les
catalogues constructeurs.
Définitions IEEE 802.3

Correspondance entre le modèle OSI et les définitions IEEE 802.3
Cette vue met en évidence les éléments introduits pour faire évoluer les débits.
Les acronymes :
AUI : Attachment Unit Interface

MDI : Media Dependant Interface
MII : Media Independant Interface : reconnaissance des vitesses 10/100/1000 Mbps
PCS : Physical Coding Sublayer
PLS : Physical Layer Signaling
PMA : Physical Media Attachment sublayer
PMD : Physical Media Dependant sublayer
Normalisations IEEE 802.3
Il existe de nombreux suppléments à la norme IEEE 802.3 initialement publiée qui décrivent
les différents supports utilisables.
Ethernet IEEE 802.3
C'est le point de départ de la normalisation. La première définition est la plus proche du

Standard Ethernet II publié par DEC, Intel et Xerox.
La topologie utilisant des câbles coaxiaux est toujours de type BUS. Cette topologie était
avantageuse lorsque le nombre et la disposition des stations changeaient. Aujourd'hui, les
câbles coaxiaux sont systématiquement abandonnés au profit des câbles en paires torsadées
cuivre ou des fibres optiques. Le coût de la connectique des câbles coaxiaux est devenu
supérieur à celui de la connectique RJ45 utilisée avec les paires torsadées.
Ethernet standard
Le câble standard a été défini à l'origine pour des connexions avec transceivers à piquage
(vampire) puis étendu à la connectique de type N-BNC.
Exemple de topologie BUS Ethernet IEEE 802.3
Tableau 1. Ethernet Standard
Appellations 10Base5, Thick Ethernet

Support câble coaxial 50 Ohms associé à une connectique N-BNC
Longueur 500 m par brin. Les câbles doivent avoir une longueur multiple de 23,4m
maximum (généralement 117m) pour que les réflexions produites sur les raccords soient
superposées déphasées
Distance entre au moins 2,50m (points repérés sur le câble)
connexions
Nombre au plus 100 connexions par brin
maximum de
connexions
IEEE 802.3 a
Tableau 2. Ethernet Fin
Appellations 10Base2, Thinnet ou Thin Ethernet

Support câble coaxial 50 Ohms (RG58) associé à une connectique BNC
Longueur
185m
maximum
Distance entre 50cm
connexions
Nombre 30 stations
maximum de
connexions
IEEE 802.3 c-d
Définit les caractéristiques des répéteurs 10Base2 ainsi que les liaisons inter-répéteurs en fibre
optique FOIRL (Fiber Optic Inter Repeater Link).
Le répéteur ineterconnecte les brins de média entre eux en :

régénérant les signaux,
prolongeant les fragments (morceaux de trames issus des collisions),
complétant les préambules.
Il peut aussi intervenir sur la propagation des collisions (Jamming) ou interrompre une
émission trop longue.
La liaison FOIRL doit avoir une longueur inférieure ou égale à 1 Km.
IEEE 802.3 i
Introduite en 1990, cette définition constitue une évolution majeure d'Ethernet. C'est la
première à adopter une topologie étoile analogue à celle des installations téléphoniques.
Depuis, cette topologie étoile domine très largement dans les installations réseau.
Exemple de topologie étoile 10BaseT et 10BaseFL
Tableau 3. 10BaseT
Appellations 10BaseT débit 10Mbps

Support paire torsadée non-blindée (UTP : Unshielded Twisted Pair) associée à une
connectique RJ45 en topologie étoile.
Longueur
100m
maximum
IEEE 802.3 j
Cette définition a très largement été utilisée pour l'implantation des dorsales réseau de
campus.
Tableau 4. 10Base-F
Appellations 10Base-F débit 10Mbps

Support fibre optique multimodes (62.5/125µm) associée à une connectique ST ou SC.
Longueur
2Km
maximum
10BASE-FL : Redéfinition de FOIRL avec des capacités plus intéressantes telles que
la possibilité de concevoir une topologie étoile avec des répéteurs multi-ports.
Fast Ethernet IEEE 802.3u

Publiée en 1995, ces spécifications ont très vite été adoptées. Le coût par port a chuté de 50%
entre 1996 et 1999.
100BaseT
La signalisation 100Base-X sur les câbles et fibres reprend celle développée pour la
technologie FDDI (Fiber Distributed Data Interface).
Tableau 5. 100BaseT
Appellations 100BaseT débit 100Mbps

Support 100Base- utilise 4 paires (transmission, réception, 2 bi-directionnelles) de câbles UTP de
T4 catégories 3, 4 ou 5. Les 100Mbps sont répartis sur 3 paires.
Support 100Base- utilise 2 paires (transmission, réception) de câbles UTP5 ou STP (Shielded
TX Twisted Pair). Ce câble supporte 200Mbps en mode full duplex après
négociation entre les extrémités.
Longueur
100m
maximum
100BaseF
Tableau 6. 100BaseFX
Appellations 100BaseFX débit 100Mbps

Support fibre optique multimodes (62.5/125µm) associée à une connectique ST ou SC.
Longueur
400m
maximum
Gigabit Ethernet
Comme les câbles en paires torsadées de catégorie 5 sont certifiés pour des fréquences allant
jusqu'à 100MHz (cf TIA/EIA-568-A), le passage à 1000Mbps pose des difficultés nouvelles
par rapport aux évolutions précédentes. La couche physique a été entièrement revue. La
nouvelle définition est une « fusion » de deux technologies : l'Ethernet IEEE802.3 et le Fiber
Channel ANSI X3/T11.
Cette fusion reprend le format de trame Ethernet 802.3 et la méthode d'accès CSMA/CD full-
duplex pour conserver la compatibilité avec les couches supérieures du réseau et elle bénéficie
du débit élevé de l'interface physique Fiber Channel.
Comme pour la famille FastEthernet, il existe plusieurs variantes 1000BaseX.
Définitions IEEE 802.3z : 1000BaseX
Tableau 7. 1000Base-LX
Appellation 1000BaseLX
Support laser grandes ondes sur fibre optique multimodes et monomode destiné aux
artères de campus.
Longueur
3Km
maximum
Tableau 8. 1000Base-SX
Appellation 1000BaseSX
laser ondes courtes sur fibre optique multimodes destiné aux artères intra-
Support
muros.
Longueur
500m
maximum
Tableau 9. 1000Base-CX
Appellation 1000BaseCX
Support câble en paires torsadées blindées 150 Ohms destiné aux connexions entre
serveurs dans le même local.
Longueur
25m
maximum
Définition 1000BaseT : IEEE802.3ab
Cette définition est très importante. C'est elle qui permet d'utiliser le Gigabit Ethernet dans la
majorité des installations actuelles.
Ceci dit, les installations existantes auront certainement besoin d'une « requalification » avant
d'être équipées en 1000BaseT. Cette technologie utilise les câbles FTP de catégorie 5 au
maximum de leur certification. De nouvelles catégories de câbles sont en cours de
spécification : 5enhanced à 100MHz, 6 à 200MHz et 7 à 600MHz.
Il est recommandé de limiter au maximum les brassages intermédiaires dans les armoires de
câblage.
Tableau 10. 1000Base-T
Appellation 1000BaseT
Support câble en paires torsadées non blindées de catégorie 5.
Longueur
100m
maximum
6.3. Extension CSMA/CD
Avec la définition GigabitEthernet, la méthode d'accès CSMA/CD n'est pas remise en

question mais les « espaces temps » ont été étendus. Sans extension, un paquet de petite taille
(64 octets) peut très bien arriver à destination avant que la station qui l'a émis ne puisse
détecter une collision. On a donc étendu la taille minimum de paquet a 512 octets avec un
nouveau champ placé après le champ de contrôle FCS. Voir Section 9.5, « Le champ de
contrôle ».
Gigabit Ethernet
IEEE 802.3ae
Définition 10Gbps
Négociation de la bande passante
Avec les évolutions des débits d'Ethernet, la grande majorité des infrastructures actuelles sont
« mixtes ». Il est donc nécessaire que les équipements réseau (cartes, commutateurs, etc.)
12
soient capables de reconnaître et d'utiliser la bande passante disponible sur le câble.
Auto-négociation
La négociation entre équipements porte sur deux fonctionnalités :
le débit 10, 100 et 1000Mbps,

le mode half-duplex ou full-duplex (IEEE 802.3x).
La fonction d'auto-négociation est optionnelle. Elle est apparue avec l'extension FastEthernet
et ne concerne que les câbles en paires torsadées et les fibres optiques.
La fonction de négociation utilise les signaux de contrôle d'état du lien physique en respectant
la compatibilité entre tous les équipements indépendemment de leur génération et des options
qu'ils supportent.
L'ordre des négociations est le suivant :
1 100BaseTX Full-Duplex,
2 100BaseT4,
3 100BaseTX,
4 10BaseT Full-Duplex,
5 10BaseT.
Mode Full-Duplex IEEE 802.3x
Le mode de fonctionnement de base d'Ethernet est dit Half-Duplex : bidirectionnel à l'alternat.

Il suppose que le média est partagé entre plusieurs stations et que les informations transitent
dans les 2 sens. C'est sur ce mode de base que la méthode d'accès CSMA/CD est bâtie.
Le mode Full-Duplex correspond à une communication point-à-point entre deux équipements.

Dans ce contexte, le média n'est plus partagé entre plus de 2 stations et les informations
transitent toujours dans les deux sens mais sur des canaux (paires torsadées ou fibres)
distincts.
En conséquence, l'algorithme d'accès au média est considérablement simplifié et la bande
passante utile est doublée. Aujourd'hui, beaucoup de constructeurs ont adopté ces options
d'Ethernet. Il est donc possible de concevoir des artères à 200Mbps entres commutateurs et/ou
concentrateurs (hubs) pour un coût très raisonnable.
Exemple de conception
12
Document de référence sur l'auto négociation Ethernet : An Introduction to Auto-
Negotiation [http://www.scyld.com/expert/NWay.html].
L'exemple qui suit est une synthèse sur l'utilisation de la technologie Ethernet. Il ne prend pas
en compte certaines autres normes telles que les VLANs IEEE 802.1Q qui autoriseraient
d'autres modes de conception.
Exemple de conception Ethernet
1 100BaseFX FD : artère de campus en fibres optiques avec un débit de 200Mbps en

Full-Duplex,
2 100BaseTX FD : alimentation du commutateur mixte (Switch 10/100) du local serveur
(Server Farm) avec un débit de 200Mbps en Full-Duplex,
3 100BaseTX FD : alimentation du commutateur mixte (Switch 10/100) des stations
10/100 (typiquement multimédia/CAO) avec un débit de 200Mbps en Full-Duplex,
4 10BaseT FD : alimentation du commutateur (Switch) des stations 10BaseT
(typiquement bureautique) avec un débit de 20Mbps.
Format de trame
Les 2 types de trames reconnuesLa signification de chacun des champs de trame est donnée
ci-après.
Le préambule
Le préambule est une suite de 0 et de 1 alternés. Il permet à l'horloge du récepteur de se

synchroniser sur celle de l'émetteur. Comme la transmission est asynchrone, il est possible
qu'une partie du préambule soit perdue.
Même si la norme IEEE 802.3 a spécifié un champ spécifique en fin de préambule : SOF
(Start of Frame) avec 2 bits à 1, il n'y a aucune différence avec le standard Ethernet v2.0 pour
lequel les 2 derniers bits du préambule sont aussi à
1.
Les adresses MAC
Les adresses MAC identifient le ou les destinataire(s) de la trame puis l'émetteur. Elles sont
constituées de 6 octets :
Les 3 premiers octets font référence au constructeur de l'interface. Ils sont uniques et sont
attribués par l'IEEE.
Les 3 octets suivants donnent le numéro d'interface chez ce constructeur.
L'adresse source est toujours celle d'une interface unique (unicast). La destination peut être
une adresse unique, de groupe (multicast) ou de diffusion générale (broadcast = FF-FF-FF-
FF-FF-FF). Dans une adresse de groupe, le premier bit transmis est à 1. Si les autres bits ne
changent pas, l'adresse de groupe correspond à toutes les cartes d'un même constructeur.
Le champ longueur / type
Ce champ de 2 octets a été défini dans le standard Ethernet II pour indiquer le type de
protocole de niveau 3 employé pour transporter le message.
Avec la normalisation IEEE 802.3 ce champ a été redéfini pour contenir la longueur en octets
du champ des données.
9.4. Les données
Ethernet II
Avec ce format, la couche 2 est complète. Les données sont directement transmises au niveau
réseau identifié par le champ type. Aucune « séquence de bourrage » ou padding n'est prévue
bien que le nombre minimum de données attendues soit de 46 octets.
IEEE 802.3
Le champ de données contient l'entête de la sous-couche LLC en plus des données. Au niveau
MAC ce champ est vu comme une suite de 46 à 1500 octets que l'on n'interprète pas.
Si le nombre de données n'atteint pas 46 octets, le champ est complété par padding.
Le champ de contrôle
Le FCS : Frame Check Sequence est un champ de 4 octets qui permet de valider l'intégrité de
la trame à 1 bit près. Il utilise un CRC (Cyclic Redundancy Check) qui englobe tous les
champs de la trame. Ainsi, la station réceptrice peut décider si la trame est correcte et doit être
transmise à la couche supérieure : LLC (Logical Link Control IEEE 802.2) ou réseau. Voir
Section 11.2, « Sous-couche LLC : IEEE 802.2 »
Le temps inter-trame
Le temps inter-trame est appelé indifféremment Inter Frame Space ou Inter Frame Gap.
Une machine ne peut émettre toutes les trames qu'elle a à transmettre les unes à la suite des
autres. Le délai inter-trame normalisé est de 96 bits soit 9,6 microsecondes à 10Mbps.
Attention, cette définition a été revue pour le Gigabit-Ethernet. Voir Section 6.3, « Extension
CSMA/CD ». Il correspond au temps minimum de retour au repos du média et permet aux
autres stations de prendre la main.
Trames erronées
A la suite d'incidents tels qu'une collision, le débranchement brutal d'une machine, la perte du
bouchon d'adaptation d'impédance ou le mauvais fonctionnement d'une partie du matériel, des
trames non cohérentes peuvent apparaître. Certains de ces défauts sont répertoriés avec un
vocabulaire particulier.
Runt
Ce terme désigne les trames trop courtes (moins de 64 octets). Ce type de trame est le plus
souvent le résultat d'une collision.
Jabber
Il s'agit d'une trame trop longue (plus de 1518 octets). On distingue 2 types de causes :
S'il y a superposition de 2 trames sans détection de collision, on peut considérer que les
couches 1 et 2 d'une interface du réseau ne fonctionnent plus correctement.
La trame n'a plus de structure et est émise par un composant qui reste beaucoup trop
longtemps en émission.
Ce type de défaut est très pénalisant pour le réseau et entraîne une dégradation rapide des
performances.
Misaligned frame
Une trame désalignée est une trame dont le nombre de bits n'est pas divisble par 8. Dans la
pratique, ce type de trame possède presque toujours un CRC faux.
Bad FCS
Il s'agit d'une trame complète dont un bit n'a pas été reçu tel qu'il avait été transmis ou d'une
trame tronquée résultant d'une collision.
Les collisions
Ce phénomène résulte de la superposition de 2 trames sur le média lorsque deux stations

émettent simultanément.
Important
Un réseau peut être considéré comme sain tant que le taux de collision est inférieur
à 1 pour 1000 trames.
Illustration d'une collision
Les collisions tardives
Ce type de collision intervient lorsque la longueur du câble dépasse la norme ou lorsqu'il y a

trop de répéteurs dans le réseau.
Couche liaison et Ethernet
Sous-couche MAC : Méthode d'accès CSMA/CD
La méthode CSMA/CD est dérivée d'un système de transmission radio appelé Aloha. Son
principe est de laisser chacun libre de gérer ses émissions en fonction de ses besoins et de la
disponibilité du média.
En l'absence d'information à transmettre, la station écoute (ou reçoit) les paquets qui circulent
sur le câble dans un sens ou dans l'autre. Quand la station a besoin d'émettre un ou plusieurs
paquets, elle agit indépendamment des autres. Elle sait juste que lorsqu'elle perçoit une trame,
une autre machine doit être en émission.
Chaque machine ayant à tout instant la possibilité de débuter une transmission de manière
autonome, la méthode d'accès est distribuée : elle est dite à accès multiple (Multiple Acess:
MA). La machine observe le média en cherchant à détecter une porteuse (Carrier Sense: CS).
Si aucune trame n'est en transit, elle ne trouve pas de porteuse.
Elle envoie ses paquets sur le support physique et reste à l'écoute du résultat de son émission
pendant quelque temps, pour vérifier qu'aucune autre machine n'a suivi le même
comportement qu'elle au même instant.
La méthode d'accès étant à détection de collision (Collision Detect: CD), lors de son émission
une machine peut déceler un problème de contention, et s'arrêter avec l'intention de renvoyer
son paquet ultérieurement quand elle aura de nouveau la parole. De façon à minimiser le
risque de rencontrer une deuxième collision avec la même machine, chacune attend pendant
un délai aléatoire avant de tenter une nouvelle émission.
Cependant, de manière à ne pas saturer un réseau qui s'avérerait déjà très chargé, la machine
n'essaiera pas indéfiniment de retransmettre un paquet. Si à chaque tentative elle se trouve en
conflit avec une autre ; après un certain nombre d'essais infructueux, le paquet est éliminé. On
évite ainsi l'effondrement du réseau. Les couches supérieures sont averties que la transmission
du message a échoué.
Méthode d'accès
Sous-couche LLC : IEEE 802.2
A partir de cette sous-couche, on sort du domaine d'appelation Ethernet. Cependant, de

nombreux réseaux locaux associent la norme IEEE 802.2 avec Ethernet.
Le sous-comité IEEE 802.2 a standardisé une couche de niveau LLC qui possède plusieurs
types d'opérations offrant des services de différentes qualités.
Le premier type d'opération est un service minimum, sans connexion (pas de liaison logique)
ni acquittement (pas de retour d'information sur le déroulement de l'acheminement). Le type 1
permet des communications en point à point (un émetteur un récepteur) ou en diffusion (un
émetteur plusieurs récepteurs).
Le type d'opération 2 est un service sur connexion (liaison logique entre SAP) avec
acquittement, vérification de l'ordre des trames, détection et correction d'erreur, détection des
doubles, contrôle de flux. L'identificateur correspondant au couple SSAP/DSAP (Source
Service Access Point / Destination Service Access Point) est unique. Ce type d'opération ne
permet que des communications en point à point.
Le type d'opération 3 est un service datagramme (sans connexion) acquitté, sans

retransmission (pas de correction des erreurs), réalisant une prestation de qualité intermédiaire
à la fois simple et performante.
Dans tous les cas, quel que soit le type d'opération, les données du niveau LLC sont
présentées sous la forme d'un LPDU (LLC Protocol Data Unit), tel que représenté ci-dessous.
Les valeurs des LSAP (points d'accès LLC) sont représentées sur un octet. Elles sont relatives
au protocole de niveau supérieur (06 pour TCP/IP). Une trame LLC est encapsulée dans la
trame de niveau inférieur (MAC). Le LPDU correspond donc au champ de données de la
trame MAC.
En guise de conclusion
Cette synthèse sur la technologie Ethernet est nécessairement incomplète et certains aspects
ont été volontairement occultés. En voici deux exemples significatifs :
La signalisation. Dans le domaine de l'instrumentation réseau on ne mélange pas le test de

câble et l'analyse de protocole. Il en est de même pour cette présentation, l'aspect signalisation
dans la couche physique n'a pas été traité. C'est un sujet à part entière qui mérite que l'on s'y
intéresse. Après avoir connu une décennie plûtot «tranquille», le test de câble va
probablement revenir au devant de l'actualité avec l'utilisation du GigabitEthernet sur les
câbles de catégorie 5 qui sont spécifiés à 100MHz seulement.
Les autres définitions 100Mbps. Il en existe 2 : 100BaseT2 et 100BaseVG AnyLan. Pour le

100BaseT2 la question est vite réglée, il n'existe aucun équipement qui l'utilise à ma
connaissance. La situation est à peine différente pour le 100BaseVG AnyLan, cette définition
a été publiée en 1995 en même temps que celle du 100BaseTX. Sans rentrer dans la
polémique sur le fait qu'elle ne respecte pas la méthode d'accès CSMA/CD, la base installée
d'équipements 100BaseVG AnyLan est aujourd'hui insignifiante comparée à la base
100BaseTX.
Identification des interfaces disponibles
Avant de pouvoir configurer une interface, il faut que le pilote de périphérique correspondant
ait été chargé. Comme une interface réseau est un dispositif matériel, c'est au niveau du noyau
Linux que l'opération doit s'effectuer. Soit le pilote d'interface a été inclu dans la partie
monolithique du noyau soit il est chargeable sous forme de module. C'est cette dernière
solution qui est le plus souvent retenue. Un module peut être chargé ou déchargé à volonté
sans avoir à redémarrer la machine.
Comment identifier le périphérique réseau ?
Il existe un grande variété de contrôleurs ethernet. A chaque composant correspond un pilote

logiciel spécifique. Qu'il s'agisse d'une carte additionnelle ou d'un composant intégré sur la
carte mère, le contrôleur est toujours un périphérique connecté au bus PCI. La commande
lspci du paquetage pciutils donne la liste des périphériques reliés au bus PCI.
Voici deux exemples caractéristiques : une première machine avec un contrôleur RNIS/ISDN
et un contrôleur Ethernet puis une seconde machine avec un contrôleur Ethernet différent.
# lspci -v
00:0e.0 Network controller: Cologne Chip Designs GmbH ISDN

network controller [HFC-PCI] (rev 02)
Subsystem: Cologne Chip Designs GmbH: Unknown device b401
Flags: bus master, medium devsel, latency 16, IRQ 11
I/O ports at e400 [size=8]
Memory at e9001000 (32-bit, non-prefetchable) [size=256]
Capabilities: [40] Power Management version 1
00:12.0 Ethernet controller: 3Com Corporation 3c900B-

Combo [Etherlink XL Combo] (rev 04)Subsystem: 3Com
Corporation 3C900B-Combo Etherlink XL ComboFlags:
bus master, medium devsel, latency 64, IRQ 9I/O
ports at e800 [size=128]Memory at e9000000 (32-bit,
non-prefetchable) [size=128]Expansion ROM at
e8000000 [disabled] [size=128K]Capabilities: [dc]
Power Management version 1
# lspci -v
00:09.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet
Pro 100] (rev 09)Subsystem: Intel Corp. EtherExpress
PRO/100+ MiniPCIFlags: medium devsel, IRQ 11Memory at
41280000 (32-bit, non-prefetchable) [size=4K]I/O ports at
3440 [size=64]Memory at 41200000 (32-bit, non-
prefetchable) [size=128K]Expansion ROM at <unassigned>
[disabled] [size=1M]Capabilities: [dc] Power Management
version 2
Comment identifier le pilote logiciel ?
Comme précisé plus haut, les périphériques réseau utilisent des composants matériel. Il est
donc logique de se réferrer à la documentation du noyau Linux pour identifier le logiciel
correspondant au contrôleur utilisé. Le répertoire
/usr/src/linux/Documentation/networking contient de nombreux fichiers de
documentation sur les différents contrôleurs supportés par le noyau Linux.
En suivant les 2 exemples ci-dessus, on peut repérer les fichiers qui traitent des contrôleurs :
vortex.txt et e100.txt.
/usr/src/linux/Documentation/networking$ grep -i 3c900B

*vortex.txt: 3c900B Cyclone 10Mbps Tvortex.txt: 3c900B-FL
Cyclone 10base-FL
/usr/src/linux/Documentation/networking$ grep -i "Intel

PRO/100" *e100.txt:For the latest Intel PRO/100 network driver
for Linux, see:e100.txt:For example, with two Intel PRO/100
PCI adapters, entering:
En consultant ces 2 fichiers, on identifie facilement le nom du module logiciel à charger pour
utiliser le périphérique
réseau. Dans le cas de la carte 3Com 3c900B-Combo, il s'agit du module 3c59x. Dans le cas
du contrôleur intégré Intel EtherExpress PRO/100+ MiniPCI, il s'agit du module e100.
Comment charger et valider le pilote logiciel ?
Le chargement d'un module s'effectue avec la commande modprobe et la validation du

résultat avec les commandes dmesg et ifconfig. De plus, on peut vérifier la présence du pilote
dans la liste des modules chargé avec la commande lsmod. On utilise toujours les 2 mêmes
exemples de contrôleurs.
Avertissement
Pour tester les manipulations ci-dessous à partir d'une configuration déjà établie, il
faut :
désactiver la configuration de l'interface : /etc/init.d/networking stop,
retrouver le pilote de l'interface dans la liste des modules : lsmod,
décharger le module pilote de cette même interface : rmmod <module_carte>,
Attention ! lors du (re)chargement du module pilote de l'interface, les scripts de
configuration de l'interface sont automatiquement relancés. Le système effectue une opération
identique à la commande : /etc/init.d/networking start.
Enfin, si le pilote de carte est chargé dans la partie monolithique du noyau, toute
manipulation de module est impossible.
1. Cas du contrôleur vortex 3Com :
# modprobe 3c59x# dmesg
PCI: Found IRQ 9 for device 00:12.03c59x: Donald Becker and

others. www.scyld.com/network/vortex.htmlSee
Documentation/networking/vortex.txt
00:12.0: 3Com PCI 3c900 Cyclone 10Mbps Combo at 0xe800.
Vers LK1.1.18-ac
00:50:04:4c:28:27, IRQ 9product code 5354 rev 00.4 date

06-04-99Internal config register is 1000000, transceivers
0x38.8K byte-wide RAM 5:3 Rx:Tx split, autoselect/10baseT
interface.
00:12.0: Media override to transceiver type 3
(10base2).Enabling bus-master transmits and whole-frame
receives.
00:12.0: scatter/gather enabled. h/w checksums enabled
# ifconfig -a
eth0 Lien encap:Ethernet HWaddr

00:50:04:4C:28:27 BROADCAST MULTICAST
MTU:1500 Metric:1 RX packets:0 errors:0
dropped:0 overruns:0 frame:0 TX packets:0
errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100 RX
bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interruption:9 Adresse de base:0xe800
2. Cas du contrôleur Intel EtherExpress PRO/100+ MiniPCI :
# modprobe e100# dmesg

<snip/>
e100: selftest OK.
e100: eth0: Intel(R) PRO/100 Network ConnectionHardware

receive checksums enabledcpu cycle saver enabled
e100: eth0 NIC Link is Up 10 Mbps Half duplex
# ifconfig -a
eth0 Lien encap:Ethernet HWaddr 00:D0:59:9D:29:C6

BROADCAST MULTICAST MTU:1500 Metric:1 RX
packets:0 errors:0 dropped:0 overruns:0
frame:0 TX packets:0 errors:0 dropped:0
overruns:0 carrier:0 collisions:0 lg file
transmission:100 RX bytes:0 (0.0 b) TX
bytes:0 (0.0 b) Interruption:11 Adresse de
base:0x3440 Mémoire:41280000-41280038
En plus du chargement du module, l'interface doit être configurée à l'aide des scripts
utilisé lors de l'initialisation du système.
A partir de cette étape, on dispose de deux interfaces prêtes à être configurées.
Configuration de l'interface
Pour configurer une interface réseau, il faut utiliser les commandes de base disponibles sur
n'importe quel système Unix. Voici une présentation succinte des commandes classiques de
configuration et de test d'une connexion réseau : ifconfig, ping, arp et host.
Commande ifconfig
Pour toute information sur le format des adresses IP utilisées ci-après, se référer à l'article
5
Adressage IP .
ifconfig sert à fixer les paramètres d'une interface ; eth0 dans notre exemple.
Etat de l'interface
$ /sbin/ifconfig -a
eth0Lien encap:Ethernet HWaddr 00:50:04:4C:28:27 inet

adr:192.168.1.1 Bcast:192.168.1.255
Masque:255.255.255.0 UP BROADCAST RUNNING MULTICAST
MTU:1500 Metric:1 Paquets Reçus:134 erreurs:0 jetés:0
débordements:0 trames:0 Paquets transmis:17 erreurs:0
jetés:0 débordements:0 carrier:0 collisions:0 lg file
transmission:100 Interruption:10 Adresse de base:0xe000
loLien encap:Boucle localeinet adr:127.0.0.1

Masque:255.0.0.0UP LOOPBACK RUNNING MTU:3924
Metric:1Paquets Reçus:13599 erreurs:0 jetés:0
débordements:0 trames:0Paquets transmis:13599 erreurs:0
jetés:0 débordements:0 carrier:0collisions:0 lg file
transmission:0
Informations sur la couche liaison (2) :

• encap:Ethernet : format de trame Ethernet II.
• HWaddr ... : Adresse MAC de la carte réseau. Informations sur la couche
réseau (3) :
inet adr : adresse IP de l'interface.
Bcast : adresse de diffusion du réseau.
• Masque : masque de sous-réseau. Informations sur l'état de l'interface :
UP BROADCAST RUNNING MULTICAST : interface de diffusion active.
MTU:1500 : Maximum Transmission Unit. La taille maximum des trames Ethernet
6
transmises sur Internet est fixée par le document RFC 1191 .
Metric:1 : nombre de sauts autorisés pour obtenir un routage vers n'importe quelle
destination. Statistiques de l'interface. Ces informations sont essentielles pour
déterminer la qualité du réseau. Paramètres d'entrées/sorties de l'interface. Ces
informations indiquent si la carte réseau est correctement reconnue par le système.
Configurer l'interface
Typiquement, on configure une interface Ethernet avec une commande du type :
# ifconfig eth0 192.168.1.1 netmask 255.255.255.0 broadcast

192.168.1.255 up
La commande ifconfig possède de nombreuses options. Les principales sont :

up : activation de l'interface,
down : désactivation de l'interface,
[-]arp : activation/désactivation du protocole ARP sur l'interface,
netmask <addr> : valeur du masque de réseau,
broadcast <addr> : valeur de l'adresse de diffusion.
Pour obtenir la syntaxe de toutes les options disponibles, il faut utiliser la commande man
ifconfig
Rendre la configuration permanente
Avec la distribution Debian GNU/Linux les paramètres de configuration des interfaces réseau
sont stockés dans le répertoire /etc/network. Le fichier interfaces de ce répertoire
rassemble la configuration des interfaces réseau.
Voici l'exemple d'une interface ethernet configurée à l'aide du protocole DHCP :
# /etc/network/interfaces --configuration file for ifup(8),

ifdown(8)
# The loopback
interfaceauto loiface
lo inet loopback
# The first network card -this entry was created during the
Debian installation# (network, broadcast and gateway are
optional)auto eth0iface eth0 inet dhcp
Pour une configuration statique de l'interface, il faut utiliser les pages de manuels : man
interfaces. Voici un exemple :
auto eth0
iface eth0 inet staticaddress 192.168.1.1netmask

255.255.255.0network 192.168.1.0broadcast 192.168.1.255
Tests de communication ICMP

Commande ping
Le protocole Internet Control Message Protocol ou ICMP est décrit dans le document RFC
7
792 . Comme le protocole IP de la couche réseau fonctionne en mode non connecté, il ne
fournit aucun service de contrôle lors de la transmission des paquets sur le réseau. Le rôle du
protocole ICMP est de notifier l'émetteur lorsqu'il y a eu un problème.
La commande ping utilise principalement deux types de messages du protocole ICMP pour
informer l'utilisateur sur les conditions de transmissions :
• L'hôte distant est-il actif ou inactif.
7
http://www.faqs.org/rfcs/rfc792.html
Le temps de propagation en boucle (round-trip delay) lors de la communication avec

l'hôte distant.
Les pertes de paquets pendant la communication.
Il existe 18 types de messages ICMP. Les deux types de messages employés par la
commande ping sont :
Letype8(echo request) est émis vers l'hôte distant.
Letype0(echo reply) est émis par l'hôte distant en réponse.
Pour valider le bon fonctionnement d'une communication sur un réseau IP, on suit une
séquence précise de tests :
1 adresse IP de l'interface de boucle locale : lo,
2 adresse IP de l'interface du poste de travail : eth0 ou ppp0,
3 adresse IP du destinataire de la passerelle par défaut,
4 adresse IP extérieure au réseau local.
Etat de la pile TCP/IP
La commande suivante permet de valider le fonctionnement du protocole réseau IP pour les

processus appartenant au même système. On parle alors de validation inter-processus.
$ ping -c 2 127.0.0.1PING 127.0.0.1 (127.0.0.1): 56 data

bytes64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.1
ms64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.1 ms
---127.0.0.1 ping statistics --2 packets transmitted, 2
packets received, 0% packet lossround-trip min/avg/max =
0.1/0.1/0.1 ms
Il s'agit ici de contrôler que les processus pairs à l'intérieur du même système sont capables de
dialoguer entre eux. On teste ensuite le fonctionnement de l'interface seule :
$ ping -c 2 192.168.1.1PING 192.168.1.1 (192.168.1.1): 56 data

bytes64 bytes from 192.168.1.1: icmp_seq=0 ttl=255 time=0.1
0.1/0.1/0.1 ms
Il s'agit ici de contrôler que l'interface réseau est bien configurée et active.Une fois ces deux
étapes franchies, on peut tester les communications avec les autres systèmes.
Tests vers l'extérieur

Exemple d'echec :
$ ping -c 5 192.168.1.14PING 192.168.1.14

(192.168.1.14): 56 data bytes
packets received, 100% packet loss
Exemple de succès :
$ ping -c 2 192.168.1.13 PING 192.168.1.13 (192.168.1.13): 56

data bytes 64 bytes from 192.168.1.13: icmp_seq=0 ttl=255
time=1.1 ms 64 bytes from 192.168.1.13: icmp_seq=1 ttl=255
time=0.8 ms
0.8/0.9/1.1 ms
Adresse de réponse du message ICMP : destinataire du test. Numéro de séquence

du message. La valeur du champ TTL d'un paquet IP correspond au nombre
d'interfaces de routage traversées pour arriver àl'interface.
Pour obtenir la syntaxe de toutes les options disponibles, il faut accéder aux pages de manuels
Unix :
via la console avec la commande man ping.
Tests de la résolution des noms
Cette commande est aussi très utile pour savoir si la résolution des noms d'hôtes fonctionne
correctement. Dans ce cas on fait appel à un service Internet appelé Domain Name Service
(>DNS). Cet appel au service >DNS nécessite un minimum de configuration.
$ ping -c 5 www.nic.fr PING rigolo.nic.fr (192.134.4.20) :

56 data bytes 64 bytes from 192.134.4.20: icmp_seq=0 ttl=54
time=165.3 ms
---rigolo.nic.fr ping statistics --5 packets transmitted, 5
51.0/88.1/165.3 ms
Utilisation de la commande ping avec un nom d'hôte au lieu

d'une adresse IP. Affichage de la correspondance entre le nom
de l'hôte et son adresse IP.
En cas d'echec sur la résolution des noms, il faut contrôler la validité des informations dans
les deux fichiers suivants :
• /etc/resolv.conf
search <domaine-fai>.fr nameserver <addr dns-fai>
Nom du domaine auquel l'interface de l'hôte est connectée. Adresse IP du serveur de

noms qui doit résoudre toutes les requêtes au service DNS.
• /etc/host.conf
order hosts, bind multi on

Ordre de recherche des noms d'hôtes. Dans le cas présenté, la recherche est d'abord
effectuée localement puis à l'aide du service DNS.
Localisation de hôtes du réseau local

Commande arp
La commande arp utilise le protocole du même nom : Address Resolution Protocol décrit
8
dans le document RFC 826 .
Elle sert à localiser un hôte du réseau local en faisant la correspondance entre l'adresse IP et
l'adresse MAC de cet hôte.
Entre deux hôtes d'un même réseau, il n'existe pas de service de «détermination du chemin à
suivre» (c'est le travail des routeurs entre réseaux différents). La tâche du protocole ARP est
donc indispensable pour la communication entre les hôtes d'un réseau local.
Dans l'exemple suivant, on visualise la table des adresses MAC connues avec la commande
arp.
$ arp
Adresse TypeMap AdresseMat Indicateurs Iface
router ether 00:60:3E:10:48:20 C eth0
dns ether 00:A0:24:A0:A4:11 C eth0
On effectue une localisation sur le réseau local avec la commande ping.
$ ping -c 2 serverPING server (192.168.10.10) from

192.168.10.34 : 56(84) bytes of data.64 bytes from server
(192.168.10.10): icmp_seq=0 ttl=128 time=0.9 ms64 bytes from
server (192.168.10.10): icmp_seq=1 ttl=128 time=0.4 ms
---server ping statistics --2 packets transmitted, 2
packets received, 0% packet lossround-trip
min/avg/max = 0.4/0.6/0.9 ms
Le résultat de la localisation apparaît lorsque l'on visualise à nouveau la table des adresses
MAC.
$arp
Adresse TypeMap AdresseMat Indicateurs Iface
router ether 00:60:3E:10:48:20 C eth0
dns ether 00:A0:24:A0:A4:11 C eth0
server ether 00:60:97:91:60:0A C eth0
La table des adresses MAC est maintenue dynamiquement en fonction du trafic reçu par les
interfaces. Les entrées valides sont contrôlées toutes les 30 secondes sans qu'il y ait émission
de trafic. Ensuite, les entrées passent phase de «gel» (stale) pendant 60 secondes avant d'être
effacées.
Unix :
via la console avec la commande man arp.
Résolution des noms d'hôtes

Commande host
La commande host recherche la correspondance nom -adresse IP et vice versa :
$ host www.yahoo.frwww.yahoo.fr is a nickname for

homerc.europe.yahoo.comhomerc.europe.yahoo.com has address
194.237.109.73homerc.europe.yahoo.com has address
194.237.109.72homerc.europe.yahoo.com mail is handled (pri=10)
by nomail.yahoo.com
$ host 194.237.109.7070.109.237.194.IN-ADDR.ARPA is a nickname

for 70.194-237-109-rev-map.europe.yahoo.com
8
Unix : http://www.faqs.org/rfcs/rfc826.html
via la console avec la commande man host.
8. Table de routage locale
Le routage est un sujet à part entière auquel il faut consacrer beaucoup de temps pour avoir
une bonne compréhension des échanges entre plusieurs réseaux. L'objectif de cette section est
limité à l'observation des routes connues de l'interface de l'hôte et à la détection de pannes.
8.1. Commande route
La commande route, tout comme ifconfig sert à la fois à connaître l'état de la table de routage
de l'hôte et à configurer de nouvelles routes au besoin.
Cette commande n'a rien à voir avec le routage dynamique qui fonctionne sur un routeur. Elle
ne sert qu'à poser des routes statiques entre interfaces.
# route -n
Kernel IP routing table
Flags
Use
Destination Gateway Genmask
Metric
Iface
Ref
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Indicateurs d'état :
U : Up ; l'interface est active.
H : Host ; désigne un hôte.
• G : Gateway ; C'est l'interface à partir de laquelle on atteind les autres hôtes/réseaux.

On retrouve les deux interfaces : lo l'interface de boucle locale et eth0 l'interface
Ethernet.
Pour obtenir la syntaxe de toutes les options disponibles, il faut accéder aux pages de
manuels Unix :
via la console avec la commande man route.
Commande traceroute
traceroute renvoie les informations sur la route suivie pour atteindre un hôte. Le résultat
obtenu donne la liste des routeurs traversés.
# traceroute www.nic.fr
traceroute to rigolo.nic.fr (192.134.4.20), 30 hops max, 38

byte packets
1 toulouse-50-254-gw.dial.proxad.net (212.27.50.254) 24.806 ms

21.489 ms 21.530 ms
2 paris11-2-p1.routers.proxad.net (212.27.32.225) 43.597 ms

33.325 ms 33.270 ms
3 paris11-1-p1.routers.proxad.net (212.27.32.226) 149.188 ms

129.723 ms 147.430 ms
4 sfinx.routers.proxad.net (212.27.32.167) 126.530 ms 138.881

ms 126.858 ms
5 ri-renater.gix-paris.ft.net (194.68.129.34) 107.966 ms

132.974 ms 135.544 ms
6 nio-i.cssi.renater.fr (193.51.206.57) 144.283 ms 122.517 ms

127.308 ms
7 193.51.206.146 (193.51.206.146) 132.595 ms 145.998 ms

148.399 ms
8 stlambert1.rerif.ft.net (193.48.53.102) 124.040 ms 260.685

ms 108.853 ms
9 inria-rocquencourt-atm.rerif.ft.net (193.48.53.226) 38.604

ms 167.956 ms 143.657 ms10 rocq-gw.inria.fr (192.93.122.2)
151.084 ms 96.052 ms 100.700 ms11 nic-gw.inria.fr
(192.93.1.112) 126.699 ms 153.840 ms *12 rigolo.nic.fr
(192.134.4.20) 155.644 ms 150.290 ms 191.674 ms
Dans l'exemple ci-dessus, l'hôte recherché a été trouvé. En cas de défaut, cette commande est
très utile pour repérer le routeur sur lequel se situe le problème d'interconnexion.
Les tests ICMP effectués avec la commande ping ne permettent pas de localiser le point de
rupture de la communication entre deux hôtes distants. La commande traceroute identifie
tous les équipements d'interconnexion réseau traversés.
Le principe de ce tracé de route est le suivant :

Emettre un premier message avec la valeur 1 dans le champ TTL de l'en-tête IP.
L'équipement d'interconnexion qui reçoit ce message décrémente la valeur du champ TTL de
l'en-tête IP et obtient 0. Il jette donc le message et émet un message ICMP à destination de
l'émetteur indiquant qu'il est impossible d'atteindre la destination.
Emettre un second message avec la valeur 2 dans le champ TTL de l'en-tête IP.
Cette fois-ci, c'est le second équipement d'interconnexion qui décrémentera la valeur pour
obtenir 0. Ce sera donc à ce second équipement d'émettre un message ICMP à destination de
l'émetteur.
Ainsi de suite avec les valeurs 3, 4, etc. pour le champ TTL de de l'en-tête IP.
Pour obtenir la syntaxe de toutes les options disponibles, il faut accéder aux pages de
manuels Unix :
via la console avec la commande man traceroute.
Commande tcptraceroute
L'utilisation de la commande traceroute est de plus en plus limitée par les divers systèmes de
filtrage réseau et pour contrer les outils automatisés de relevé de topologie réseau à distance.
La façon la plus immédiate de bloquer la commande traceroute consiste à bloquer en entrée

d'un périmètre les ports UDP de la plage 33434 à 33600.
Pour autant, la fonction traceroute est très utile pour qualifier la validité d'une
communication. Il existe une autre commande : tcptraceroute permettant de fixer les
numéros des ports source et destination.
# tcptraceroute -p 2048 www.nic.fr 80
Selected device eth0, address 172.16.80.20, port 2048 for

outgoing packets
Tracing the path to www.nic.fr (192.134.4.20) on TCP port 80,

30 hops max
Fonctions réseau d'une interface
Sur tous les systèmes, un certain nombre de paramètres sont actifs par défaut sur les interfaces
réseau. Avec le noyau Linux, ces paramètres sont placés dans le système de fichiers virtuel
/proc.
Comment visualiser les paramètres du noyau ?
Dans le noyau Linux, la granularité du paramètrage de la pile de protocoles TCP/IP est très
fine. Aussi le nombre de paramètres est important. Il suffit de visualiser le résultat des
commandes ls /proc/sys/net/ipv4/ ou sysctl -A |grep net pour le
constater.
Voici un petit script appelé show_proc.sh qui permet de visualiser les paramètres par
protocole ou catégorie et leurs valeurs :
#!/bin/bash
for param in `find /proc/sys -type f -name "*$1*"`; doecho

$param = `cat $param`done
Dans le cas des réglages ICMP on obtient le résultat suivant avec un noyau de distribution
standard :
# ./bin/show_proc.sh
icmp/proc/sys/net/ipv4/netfilter/ip_conntrack_icmp_timeout =
30/proc/sys/net/ipv4/icmp_ratemask =
6168/proc/sys/net/ipv4/icmp_ratelimit =
1000/proc/sys/net/ipv4/icmp_ignore_bogus_error_responses =
0/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts =
0/proc/sys/net/ipv4/icmp_echo_ignore_all = 0
Comment changer les valeurs des paramètres ?
Pour changer les valeurs par défaut attribuées dans le noyau, il existe au moins trois solutions
:
• La première solution consiste à affecter les valeurs individuellement. Prenons l'exemple
célèbre de la fonction de routage des paquets IP du noyau:
echo 1 > /proc/sys/net/ipv4/ip_forward
• La seconde solution utilise le fichier de configuration /etc/sysctl.conf de la

commande sysctl appartenant au paquetage procps. Ce fichier de configuration n'est pas
limité aux fonctions réseau du noyau Linux comme le montre le résultat de la commande
sysctl -A. Voici un exemple très simple de fichier /etc/sysctl.conf :
# Activation de protection contre les mauvais messages

d'erreurs ICMP
net.ipv4.icmp_ignore_bogus_error_responses=1
La commande sysctl -p active l'ensemble des valeurs indiquées dans le fichier ce

configuration. On obtient alors :
# ./bin/show_proc.sh
icmp_ignore_bogus_error_responses/proc/sys/net/ipv4/icmp_ignor
e_bogus_error_responses = 1
Comme le fichier /etc/sysctl.conf est lu à chaque démarrage du système, les

valeurs des paramètres ajustés seront reprises. Ce fichier de configuration est un moyen
pratique de conserver les paramètres personnels des fonctions réseau d'une interface.
Analyse avec Ethereal
5
Avec Ethereal , il est possible de capturer des paquets directement sur les interfaces du
système utilisé ou de lire des fichiers de captures sauvegardées. Ethereal supporte les formats
de fichiers de capture les plus courants : libpcap/tcpdump, Sun's snoop/atmsnoop, LanAlyzer,
MS Network Monitor, HPUX nettl, AIX iptrace, Cisco Secure IDS, etc. Æ voir liste
protocole sur CDROM
Quels sont les protocoles supportés ?
Ethereal supporte les descriptions des champs spécifiques de plus de 580 protocoles. Voir le
menu Help->Supported Protocols.
Quels sont les médias supportés ?
Contrairement à ce que son nom indique, le logiciel Ethereal permet l'analyse de

transmissions réseau sur n'importe quelle technologie. Les limitations d'utilisation sont plutôt
dues au système d'exploitation sur lequel on exécute ce logiciel. Pour obtenir un état des
possibilités d'analyse en focntion du système utilisé, il faut consulter la page : Supported
6
Capture Media
Comment accéder aux interfaces ?
Lorsque l'on exécute ethereal en tant qu'utilisateur normal, on ne peut accéder à la

liste des interfaces en lançant l'opération Capture. Un utilisateur normal ne doit pas
avoir accès aux interfaces sans conditions. Il existe plusieurs solutions pour donner
un accès direct à la liste des interfaces physiques ; en voici deux :
En mode super-utilisateur Partant d'une connexion avec un compte utilisateur normal, celui-ci
est propriétaire exclusif de son écran (display). Il doit donc autoriser le super utilisateur à
accéder à son écran à l'aide de la commande xhost, passer en connexion super-utilisateur
avec la commande su puis exécuter l'application Ethereal.
$ xhost +local:$ suPassword:# ethereal &
En mode utilisateur avec sudo L'application sudo permet de déléguer les droits du super-
utilisateur avec une granularité très fine. L'optique de l'analyse réseau étant un cas particulier
de l'administration système, on se limitera à la présentation du fichier de configuration de
l'application : /etc/sudoers.
# sudoers file.## This file MUST be edited with the 'visudo'
command as root.## See the man page for details on how to
write a sudoers file.#
# Host alias specification
# User alias specification

# Cmnd alias specification
# User privilege specificationroot

ALL=(ALL) ALL
etu ALL = NOPASSWD: /usr/bin/ethereal, /usr/bin/tcptraceroute
C'est à la dernière ligne que se situe la partie intéressante. L'utilisateur normal etu dispose,
sur n'importe quel hôte géré par ce système (ALL), d'un accès super-utilisateur aux
applications Ethereal et tcptraceroute sans avoir à saisir son mot de passe. Pour lancer
l'application, il faut préciser l'appel à l'application sudo de la façon suivante :
$ sudo ethereal &
Interface utilisateur
7
Capture d'écran Ethereal -vue complète
L'interface de l'analyseur se décompose en plusieurs barres ou fenêtres :

Barre de menus On y retrouve la liste classique de menus. Voici une liste des fonctions
remarquables accessibles à partir de ces menus.
Le menu File sert à sauvegarder ou charger un fichier de capture réseau. Une capture
peut très bien avoir été réalisée sur une sonde distante ou avec un autre outil et être analysée
avec Ethereal à postériori.
Le menu Capture sert à fixer les paramètres d'une nouvelle capture réseau. Voir
Section 4, « Capture d'une série de trame ».
Le menu Statistics sert à effectuer différents calculs sur les volumes de données et la
répartition des protocoles.
Barre des icônes Cette barre regroupe tous les raccourcis sur les manipulations d'une capture.
Barre de filtrage Cette barre sert à saisir l'expression de filtrage à postériori d'une capture pour
isoler tout ou partie d'un échange réseau.
Fenêtre contenant la liste des

trames capturées Sur chaque
ligne on retrouve :
le numéro du paquet,
son temps de capture,
sa source,
sa destination,
le protocole de plus haut niveau décodé,
le résumé des champs caractéristiques de ce protocole.
Fenêtre d'affichage de la pile des protocoles décodés pour la trame sélectionnée Avant toute
opération de développement des champs d'un ou plusieurs protocoles, cette fenêtre donne
la liste la pile de protocoles décodés allant du niveau physique (en haut) jusqu'au niveau le
plus haut reconnu (en bas). Le protocole de niveau le plus haut reconnu apparaît est celui
qui apparaît dans la colonne protocole de la Fenêtre contenant la liste des trames
capturées.
La première ligne ou niveau Frame correspond à une pseudo couche physique. Comme il n'est
pas possible de réaliser la capture directement à partir des composants électroniques qui
pilotent l'interface réseau sans perturber le fonctionnement du système, l'opération a lieu au
niveau liaison à l'aide de la bibliothèque libpcap.
A ce niveau, les informations disponibles sont : la quantité de bits capturés et la date
de capture.
La deuxième ligne correspond au niveau liaison. On y détaille le type et les champs de
la trame et les adresses physiques.
La troisième ligne correspond au niveau réseau. On y détaille les champs du protocole

réseau reconnu : adresses logiques et indicateurs d'état.
La quatrième ligne correspond au niveau transport. On y détaille les champs du

protocole de transport reconnu : état de la connexion, numéros de ports utilisés et diverses
options.
La cinquième ligne correspond au niveau application. On y trouve les données

utilisateur.
Pour le développement de chacun des champs de la trame, il faut cliquer sur le triangle
situé à gauche au niveau de chaque couche.
Fenêtre d'affichage brut de la trame sélectionnée Cette fenêtre affiche tous les octets de la
trame en hexadécimal.
Capture d'une série de trame
Après avoir lancé le logiciel Ethereal, suivre la séquence suivante pour capturer une série de
60 trames :
Sélectionner Capture puis Start.
La ligne Capture Filter, permet de préciser un filtrage à priori. La syntaxe de ce filtrage est
identique à celle de la commande tcpdump. La documentation est disponible à partir des
pages de manuels de cette command : man tcpdump. Voici 3 exemples :
ip : en spécifiant le protocole réseau à analyser, on évite la capture des trames des autres
protocoles de niveau réseau (IPX) et des protocoles de niveau liaison (STP, CDP, etc.).
host 192.168.0.1 : en spécifiant l'adresse IP d'un hôte, on ne retient que le trafic émis
et reçu par cette adresse.
host 192.168.0.1 and host 10.0.0.1 : en spécifiant les adresses IP de 2 hôtes,
on ne retient que le trafic entre ces 2 adresses.
D'une façon plus générale, on peut combiner plusieurs critères avec les opérateurs logiques
and et|ou or.
le type : host, net et port.
la direction : src et dst.
le protocole : ether, fddi, tr, ip, ip6, arp, rarp, decnet, tcp et udp.
En règle générale, il faut limiter au maximum de filtrage à priori de façon à disposer du

maximum d'information pour l'analyse. La syntaxe de la Section 5, « Filtrage de
l'affichage après capture » offre beaucoup plus de possibilités.
La rubrique Stop Capture permet de fixer plusieurs critères d'arrêt en fonction du nombre de
trames et|ou du volume de données capturées.
Clicker sur le bouton Valider pour lancer la capture.
8
Paramètres de capture -vue complète
Filtrage de l'affichage après capture
Le filtrage à postériori est certainement l'étape la plus importante dans l'analyse réseau. C'est
cette opération qui permet d'isoler l'information pertinente. La granularité de la syntaxe de
filtrage disponible avec Ethereal est très importante. Il est possible de retenir un champ
unique parmi les 580 protocoles supportés. Voici quelques exemples de filtrage allant du plus
général au plus détaillé.
Isoler une connexion TCP
Après avoir réalisé une capture, il est possible d'isoler une connexion TCP en repérant son
établissement (le début) et sa libération (la fin). En cliquant sur le bouton droit de la souris
après avoir sélectionné n'importe quelle trame appartenant à la connexion à isoler, il faut
valider l'option Follow TCP Stream.
9
Isoler une connexion TCP -vue complète
A la suite de cette opération, Ethereal ouvre une nouvelle fenêtre contenant les
données vues de la couche transport.
10
Données vues de la couche transport -vue complète
Syntaxe du filtrage à postériori
Comme indiqué ci avant, la granularité de la syntaxe de filtrage est très importante. Elle peut
donc s'avérer très complexe à manipuler. Ethereal offre plusieurs solutions pour rendre
l'apprentissage de cette syntaxe interactif.
Tout d'abord, l'opération précédente de filtrage simplifié n'était qu'un cas particulier de saisie
interactive de filtre de capture. En sélectionnant l'option Follow TCP Stream, on a «saisi» un
filtre avec la syntaxe suivante :
(ip.addr eq 192.168.1.9 and ip.addr eq 80.247.225.35) \ and
(tcp.port eq 32783 and tcp.port eq 80)
Cette expression est extraite de la Barre de filtrage. Elle doit tenir sur une ligne unique
quelque soit sa longueur.
ip.addr : sélection d'une adresse IP.
eq 192.168.1.9 : valeur particulière d'adresse IP. L'opérateur eq correspond à un test
d'égalité. Il est aussi possible d'utiliser la syntaxe du langage C pour les tests :
== : égalité,
!= : différence,
>= : supérieur ou égal,
<= : inférieur ou égal.
Les opérateurs logiques tels que and et|ou or associés aux parenthèses servent à composer
des expressions de
sélection précises.
tcp.port : sélection d'un numéro de port du protocole TCP de la couche transport.
eq 32783 : valeur particulière de port TCP. La syntaxe de test est identique pour tous les
champs des différents
protocoles reconnus.
La construction interactive des filtres d'affichage peut se faire à l'aide de la souris. Voici 2
exemples «simplistes» :
Option TCP MSS Admettons que l'on veuille repérer toutes les trames capturées dans
lesquelles l'option MSS (Maximum Segment Size) apparaît. On développe alors l'en-tête
TCP d'un paquet correspondant à une demande de connexion pour faire apparaître cette
option. En cliquant sur le bouton droit de la souris on accède au menu Prepare a Filter.
11
Préparation d'un filtre d'affichage à la souris -vue complète L'expression préparée apparaît
dans la champ de la Barre de filtrage :
tcp.options.mss_val == 1460
Supposons maintenant que l'on veuille afficher toutes les trames ayant cette option
indépendemment de sa valeur. Il suffit alors de supprimer le test :
tcp.options.mss_val
Fragmentation IP Admettons que l'on veuille observer la fragmentation IP en repérant les

champs correspondants de l'en-tête des paquets IP. Tout d'abord, il faut «provoquer» la
fragmentation IP artificiellement. On utilise 2 hôtes avec chacun une interface ethernet et
un hub. En réduisant la taille maximum des données transmises par paquet (Maximum
Transmit Unit) sur l'interface ethernet d'un hôte, on observe plus facilement les effets de la
fragmentation.
Hote_A # ifconfig eth0 mtu 256Hote_A # ping -s 128 -c 5

192.168.1.1
PING 192.168.1.1
(192.168.1.1) 128(156) bytes of data.136 bytes from
192.168.1.1: icmp_seq=1 ttl=64 time=0.591 ms136 bytes from
192.168.1.1: icmp_seq=5 ttl=64 time=0.546 ms
received, 0% packet loss, time 3999msrtt min/avg/max/mdev =
0.528/0.552/0.591/0.036 msHote_A # ping -s 8192 -c 5
192.168.1.1PING 192.168.1.1 (192.168.1.1) 8192(8220) bytes of
data.8200 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=15.4
ms8200 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=15.4
received, 0% packet loss, time 4004msrtt min/avg/max/mdev =
15.444/15.462/15.481/0.079 ms
On observe ensuite le résultat sur l'affichage des trames capturées. La syntaxe du filtre est :
ip.flags.df == 0
Préparation d'un filtre d'affichage à la souris -vue complète
Connaissant maintenant la syntaxe d'identification de la fragmentation IP, il sera toujours

possible d'appliquer le même filtre sur une capture beaucoup plus importante en volume.
Documentation de référence sur les filtres d'affichage
La documentation sur l'ensemble des champs des protocoles reconnus utilisables dans les
13
expressions de filtres d'affichage est disponible à l'adresse : Display Filter Reference .
Sur http://www.ethereal.com/docs/dfref/
iproute2
Pourquoi iproute2 ?
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 parmi 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-feu 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 à implémenter dans le sous-système réseau précédent.
Un tour d'horizon d'iproute2
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.
Prérequis
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.
1
Vous pouvez aussi essayer iproute2-current.tar.gz pour la dernière version.
Certains éléments d'iproute vous imposent l'activation de certaines options du noyau. Il devra
également être noté que toutes les versions de RedHat jusqu'à la version 6.2 incluse n'ont pas
les fonctionnalités du contrôle de trafic activées dans le noyau fourni par défaut.
RedHat 7.2 contient tous les éléments par défaut.
Soyez également sûr que vous avez le support netlink, même si vous devez choisir de
compiler votre propre noyau ; iproute2 en a besoin.
Explorer votre configuration courante
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.
ip nous montre nos liens
[ahu@home ahu]$ ip link list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc

noqueuelink/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc

nooplink/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 100link/ether 48:54:e8:2a:47:16 brd
ff:ff:ff:ff:ff:ff

pfifo_fast qlen 100link/ether 00:e0:4c:39:24:78 brd
ff:ff:ff:ff:ff:ff
3764: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP> mtu 1492 qdisc

pfifo_fast qlen 10
link/ppp
La sortie peut varier, mais voici ce qui est affiché pour mon routeur NAT (NdT : traduction
d'adresse) chez moi. J'expliquerai seulement une partie de la sortie, dans la mesure où tout
n'est pas directement pertinent.
La 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 physiques, 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.
ip nous montre nos adresses IP
[ahu@home ahu]$ ip address show
1: lo: <LOOPBACK,UP> mtu 3924 qdisc

noqueuelink/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00inet 127.0.0.1/8 brd
127.255.255.255 scope host lo
2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc

nooplink/ether 00:00:00:00:00:00 brd
ff:ff:ff:ff:ff:ff

pfifo_fast qlen 100link/ether 48:54:e8:2a:47:16 brd
ff:ff:ff:ff:ff:ffinet 10.0.0.1/8 brd 10.255.255.255 scope
global eth0

pfifo_fast qlen 100link/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 10link/pppinet 212.64.94.251 peer
212.64.94.1/32 scope global ppp0
Cela contient plus d'informations : ip montre toutes nos adresses, et à quelles cartes elles
appartiennent. inet signifie Internet (IPv4). Il y a beaucoup d'autres familles d'adresses,
mais elles ne nous concernent pas pour le moment.
Examinons l'interface eth0 de plus près. Il est dit qu'elle est reliée à 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 ce HOWTO si vous avez des doutes.
Vous pouvez aussi noter qdisc, qui désigne la gestion de la mise en file d'attente (Queueing
Discipline). Cela deviendra vital plus tard.
ip nous montre nos routes
Nous savons maintenant comment trouver les adresses 10.x.y.z, et nous sommes capables
d'atteindre 212.64.94.1. Cela n'est cependant pas suffisant, et nous avons besoin
d'instructions pour atteindre le monde. L'Internet est disponible via notre connexion PPP, et il
se trouve que 212.64.94.1 est 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.25110.0.0.0/8 dev eth0 proto kernel scope link src
10.0.0.1127.0.0.0/8 dev lo scope linkdefault 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 pouvons voir
que c'est une passerelle à cause du mot « via », qui nous indique que nous avons besoin
d'envoyer les paquets vers 212.64.94.1, et que c'est elle qui se chargera de tout.
En référence, voici ce que l'ancien utilitaire route nous propose :
[ahu@home ahu]$ route -n

Kernel IP routing table
Flags
Destination Gateway Genmask Metric Use
Ref
Iface
255.255.255.255 0
212.64.94.1 0.0.0.0 0 0
UH ppp0
0
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0
eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0
0.0.0.0 212.64.94.1 0.0.0.0 UG 0 0 ppp0
ARP
ARP est le Protocole de Résolution d'Adresse (Address Resolution Protocol). Il est décrit dans
2
le RFC 826 . 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é (typiquement au bout de 15 minutes sur
Unix).
Maintenant, voyons comment cela fonctionne. Vous pouvez consulter votre cache (table)
ARP (neighbor) comme ceci :
[root@espa041/home/src/iputils]#ip neigh show
9.3.76.42 dev eth0 lladdr 00:60:08:3f:e9:f9 nud reachable
9.3.76.1 dev eth0 lladdr 00:06:29:21:73:c8 nud reachable
Comme vous pouvez le voir, ma machine espa041 (9.3.76.41) sait où trouver

espa042 (9.3.76.42) et espagate (9.3.76.1). Maintenant, ajoutons une autre
machine dans le cache ARP.
[root@espa041 /home/paulsch/.gnome-desktop]# ping -c 1
espa043PING espa043.austin.ibm.com (9.3.76.43) from 9.3.76.41
: 56(84) bytes of data.64 bytes from 9.3.76.43: icmp_seq=0
ttl=255 time=0.9 ms
1 packets transmitted, 1 packets received, 0%
packet lossround-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.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.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.
Règles -bases de données des politiques de routage
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 les
options IP : Advanced router et 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 principale (main) et locale
(local), 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 local32766: from all lookup main32767: from

all lookup default
Ceci liste la priorité de toutes les règles. 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 paquetage iproute2
de votre distribution].
Politique de routage simple par l'adresse source
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 consulte 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 localbroadcast

127.255.255.255 dev lo proto kernel scope link src
127.0.0.1local 10.0.0.1 dev eth0 proto kernel scope host src
10.0.0.1broadcast 10.0.0.0 dev eth0 proto kernel scope link
src 10.0.0.1local 212.64.94.251 dev ppp0 proto kernel scope
host src 212.64.94.251broadcast 10.255.255.255 dev eth0 proto
kernel scope link src 10.0.0.1broadcast 127.0.0.0 dev lo proto
kernel scope link src 127.0.0.1local 212.64.78.148 dev ppp2
proto kernel scope host src 212.64.78.148local 127.0.0.1 dev
lo proto kernel scope host src 127.0.0.1local 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.25110.0.0.0/8 dev
eth0 proto kernel scope link src
10.0.0.1127.0.0.0/8 dev lo scope
linkdefault 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 local32765: from 10.0.0.10 lookup

John32766: from all lookup main32767: 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'à implémenter cela
dans ip-up.
Routage avec plusieurs accès Internet/fournisseurs d'accès
Une configuration classique est la suivante, où deux fournisseurs d'accès permettent la

connexion d'un réseau local (ou même d'une simple machine) à Internet.
Il y a généralement deux questions à se poser pour cette configuration.
4.2.1. Accès séparé
La première est de savoir comment router les réponses aux paquets entrants par un fournisseur
particulier, disons le Fournisseur 1, vers ce même fournisseur.
Commençons par définir quelques symboles. $IF1 sera le nom de la première interface (if1
sur la figure au-dessus) et $IF2 le nom de la deuxième interface. $IP1 sera alors l'adresse IP
associée à $IF1 et $IP2 sera l'adresse IP associée à $IF2. $P1 sera l'adresse IP de la passerelle
du fournisseur d'accès 1 et $P2 sera l'adresse IP de la passerelle du fournisseur d'accès 2.
Enfin, $P1_NET sera l'adresse réseau à l'intérieur duquel se situe $P1 et $P2_NET sera
l'adresse réseau à l'intérieur duquel se situe $P2.
Deux tables de routage supplémentaires sont créées, par exemple T1 et T2. Celles-ci sont
ajoutées dans /etc/iproute2/rt_tables. La configuration du routage dans ces tables
s'effectue de la façon suivante :
ip route add $P1_NET dev $IF1 src $IP1 table T1

ip route add default via $P1 table T1
ip route add $P2_NET dev $IF2 src $IP2 table T2
ip route add default via $P2 table T2
Rien de vraiment spectaculaire. Une route est simplement positionnée vers la passerelle et une
route par défaut via
cette passerelle est mise en place, comme nous le ferions dans le cas d'un seul fournisseur
d'accès. Ici, les routes sont placées dans des tables séparées, une par fournisseur d'accès. Il est
à noter que la route vers le réseau suffit, dans la mesure où elle indique comment trouver
n'importe quel hôte dans ce réseau, ce qui inclut la passerelle.
La table de routage principale est maintenant configurée. C'est une bonne idée de router les
éléments à destination d'un voisin direct à travers l'interface connectée à ce voisin. Notez les
arguments "src" qui assurent que la bonne adresse IP source sera choisie.
ip route add $P1_NET dev $IF1 src $IP1ip route add $P2_NET dev
$IF2 src $IP2
Indiquez maintenant votre préférence pour votre route par défaut :
ip route add default via $P1
Vous configurez ensuite les règles de routage. Celles-ci définissent la table qui sera vraiment
choisie pour le routage.Il faut s'assurer que le routage s'effectue à travers une interface donnée
si vous avez l'adresse source correspondante :
ip rule add from $IP1 table T1ip rule add from $IP2 table T2
Cet ensemble de commandes vous assure que toutes les réponses au trafic entrant sur une
interface particulière seront envoyées par cette interface.
Avertissement
Notes d'un lecteur : si $P0_NET est le réseau local et $IF0 est son interface, alors
les entrées suivantes sont désirables :
ip route add $P0_NET dev $IF0 table T1

ip route add 127.0.0.0/8 dev lo table T1
ip route add 127.0.0.0/8 dev lo table T2
Nous avons maintenant une configuration très basique. Elle marchera pour tous
les processus exécutés sur le routeur lui-même, ainsi que pour le réseau local si celui-ci est
masqué. Si ce n'est pas le cas, soit vous avez une plage d'adresses IP pour chaque fournisseur
d'accès, soit vous masquez vers l'un des deux fournisseurs d'accès. Dans les deux cas, vous
ajouterez des règles indiquant, en fonction de l'adresse IP de la machine du réseau local, vers
quel fournisseur vous allez router.
Balance de charge
La seconde question concerne la balance de charge du trafic sortant vers les deux fournisseurs
d'accès. Ceci n'est pas vraiment très dur si vous avez déjà configuré l'accès séparé comme
décrit ci-dessus.
Au lieu de choisir l'un des deux fournisseurs d'accès comme route par défaut, celle-ci peut être
une route multi-chemin. Par défaut, le noyau répartira les routes vers les deux fournisseurs
d'accès. Ceci est réalisé de la façon suivante (construit également sur l'exemple de la section
de l'accès séparé) :
ip route add default scope global nexthop via $P1 dev $IF1
weight 1 \
nexthop via $P2 dev $IF2 weight 1
Ceci réalisera la balance des routes vers les deux fournisseurs. Les paramètres weight peuvent
permettre de favoriser un fournisseur par rapport à un autre.
Il est à noter que la balance de charge ne sera pas parfaite dans la mesure où elle est basée sur
les routes et que celles-ci sont mises dans des caches. Ceci signifie que les routes vers les sites
les plus souvent utilisés passeront toujours par le même fournisseur d'accès.
Équilibrage de charge sur plusieurs interfaces

Il existe plusieurs manières pour le faire. Une des plus faciles et des plus directes est TEQL
(True (or Trivial) Link Equalizer. Comme la plupart des éléments en relation avec la gestion
de file d'attente, l'équilibrage de charge est bidirectionnel. Les deux équipements terminaux
du lien ont besoin de participer pour obtenir une efficacité optimale.
A et B sont des routeurs dont nous supposerons qu'ils fonctionnent avec Linux pour le
moment. Si le trafic va du réseau 1 vers le réseau 2, le routeur A a besoin de distribuer les
paquets sur les deux liens allant vers B. Le routeur B a besoin d'être configuré pour l'accepter.
On retrouve la même chose dans le sens inverse, pour les paquets allant du réseau 2 vers le
réseau 1. Le routeur B a besoin d'envoyer les paquets à la fois sur eth1 et eth2.
La répartition est faite par un périphérique TEQL, comme ceci (cela ne pouvait pas être plus
simple) :
# tc qdisc add dev eth1 root teql0
# tc qdisc add dev eth2 root teql0
# ip link set dev teql0 up
N'oubliez pas la commande ip link set up !
Ceci a besoin d'être fait sur les deux hôtes. Le périphérique teql0 est basiquement un
distributeur tourniquet au-dessus de eth1 et eth2 pour l'envoi des paquets. Aucune
donnée n'arrive jamais à travers un périphérique teql, mais les données apparaissent sur
eth1 et eth2.
Nous n'avons pour le moment que les périphériques et nous avons également besoin d'un
routage correct. L'une des possibilités pour réaliser cela est d'assigner un réseau /31 sur
chacun des liens, ainsi que sur le périphérique teql0 :
FIXME: Avons nous besoin de quelque chose comme nobroadcast ? Un /31 est trop
petit pour contenir une adresse réseau et une adresse de diffusion. Si cela ne marche pas
comme prévu, essayez un /30, et ajustez les adresses IP. Vous pouvez même essayer sans
attribuer d'adresses à eth1 et eth2.
Sur le routeur A:
# ip addr add dev eth1 10.0.0.0/31# ip addr add dev eth2

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

# ip addr add dev teql0 10.0.0.5/31
Le routeur A devrait maintenant être capable de lancer un ping vers 10.0.0.1, 10.0.0.3
et 10.0.0.5 à travers les deux liens physiques et le périphérique « égalisé ». Le routeur B
devrait maintenant être capable de lancer un ping vers 10.0.0.0, 10.0.0.2 et
10.0.0.4 à travers les liens.
Si cela marche, le routeur A peut prendre 10.0.0.5 comme route vers le réseau 2 et le
routeur B10.0.0.4 comme route vers le réseau 1. Pour le cas particulier où le réseau 1 est
votre réseau personnel et où le réseau 2 est l'Internet, le routeur A peut prendre 10.0.0.5
comme passerelle par défaut.
Avertissement
Rien n'est aussi simple qu'il y paraît. Les interfaces eth1 et eth2 sur les deux routeurs A
et B ne doivent pas avoir la fonction de filtrage par chemin inverse activée. Dans le cas
contraire, ils rejetteront les paquets destinés à des adresses autres que les leurs :
# echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
# echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter
Il y a un sérieux problème avec le réordonnancement des paquets. Supposons que six paquets
aient besoin d'être envoyés de A vers B. Par exemple, eth1 peut traiter les paquets 1, 3 et 5
et eth2 les paquets 2, 4 et 6. Dans un monde idéal, le routeur B devrait recevoir ces paquets
dans l'ordre 1, 2, 3, 4, 5, 6. Mais il est plus probable que le noyau les recevra comme ceci : 2,
1, 4, 3, 6, 5. Ce problème va perturber TCP/IP. Alors qu'il n'y a pas de problèmes pour les
liens transportant différentes sessions TCP/IP, vous ne serez pas capable de regrouper
plusieurs liens et obtenir par ftp un simple fichier beaucoup plus rapidement, à moins que le
système d'exploitation envoyant ou recevant ne soit Linux. En effet, celui-ci n'est pas
facilement perturbé par de simples réordonnancements.
Cependant, l'équilibrage de charge est une bonne idée pour de nombreuses applications.
Netfilter et iproute -marquage de paquets
Jusqu'à maintenant, nous avons vu comment iproute travaille, et netfilter a été mentionné
plusieurs fois. Vous ne perdrez pas votre temps à consulter Rusty's Remarkably Unreliable
1 2
Guides . Le logiciel Netfilter peut être trouvé ici .
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'occurrence le courrier sortant.
# iptables -A PREROUTING -i eth0 -t mangle -p tcp --dport 25

\-j MARK --set-mark 1
Disons que nous avons plusieurs connexions, une qui est rapide (et 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 local32764: from all fwmark 1 lookup
mail.out32766: from all lookup main32767: 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 existe de
nombreux moyens pour 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 le dire, cela marche parfaitement sur un hôte qui fait de la traduction d'adresse
(NAT), autrement dit du masquerading.
Désactivez le filtrage de chemin inverse pour que cela fonctionne correctement.
Note : pour marquer les paquets, vous aurez besoin de valider quelques options du noyau :
IP: advanced router (CONFIG_IP_ADVANCED_ROUTER) [Y/n/?]IP:

policy routing (CONFIG_IP_MULTIPLE_TABLES) [Y/n/?]IP: use
netfilter MARK value as routing key (CONFIG_IP_ROUTE_FWMARK)
[Y/n/?]
Introduction
Dans cet article, je vais vous expliquer les différentes étapes pour mettre en place la QoS et
gérer votre bande passante sous Linux.
Pourquoi faire de la QoS ? Retenez que sans la QoS, vous ne pouvez pas gérer correctement
les flux qui transitent sur votre réseau. Vous aurez par exemple des problèmes à écouter un
flux audio en streaming sachant qu'en même temps, vous êtes en train de faire du ftp. Dans la
première partie de cet article, je vais vous montrer comment prioriser les divers flux de
votre réseau.
Pourquoi gérer la BP de mon réseau ? Une personne qui fait du ftp sur une ligne ADSL de
bureau peut monopoliser à elle seule toute la bande passante en sortie de votre réseau. Ce cas
ne se limite pas aux réseaux ADSL et peut être aussi constaté sur des réseaux à très haut débit
(lignes de type T1/T2). Linux peut apporter une solution efficace face à ce genre de problème
en vous offrant la possibilité de gérer intelligemment votre bande passante. Ce sera le sujet
de la deuxième partie de ce présent document.
Actuellement, sachez que vous pouvez faire de la QoS et de la gestion de bande passante sous
les noyaux 2.2 et 2.4. Néamoins, pour une question de facilité, je vous recommande un noyau
2.4 pour effectuer ce qui suit.
QoS via iptables
Pour faire de la QoS, nous allons modifier la valeur du champs TOS se situant dans l'en tête
IP grâce à iptables. Le champ TOS est sur 4 bits :
HEXA BINAIRE DECIMAL SIGNIFICATION

0x10 1000 8 Minimize Delay
0x08 0100 4 Maximize throughput
0x04 0010 2 Maximize reliability
Minimize monetary
0x02 0001 1
cost
0x00 0000 0 Normal
• Minimize-Delay : Améliore la réactivité des connexions en réduisant le délai (ssh,

telnet, ftp contrôle, tftp, flux DNS UDP)
• Maximize-Throughput : Améliore le débit au prix d'une possible détérioration de
l'interactivité de la session. Les temps de latence ne sont pas importants (ftp-
data,www, transfert de zone DNS)
• Maximum-Reliability : Certitude que les données arrivent sans perte - Améliore la
fiabilité (snmp, smtp)
• Minimize monetary cost : minimise le délai, meilleure rentabilité (nntp, icmp)
L'intêret de la QoS sous Linux est très souvent associé à la priorisation de flux interactifs via
iptables. Par exemple, vous ne souhaitez pas que votre session ssh soit interrompue à cause
d'un utilisateur qui est en train de monopoliser la bande passante de votre réseau en
downloadant une bande annonce sur internet (Il s'agit d'un cas de figure bien plus répandu
qu'on ne le pense !). Nous allons ici à titre d'exemple optimiser les trafics courants avec
iptables, à savoir le ftp et ssh :
# Priorisation des connexions ftp et ssh

iptables -A PREROUTING -t mangle -p tcp --sport ssh -j TOS --
set-tos Minimize-Delay
iptables -A PREROUTING -t mangle -p tcp --sport ftp -j TOS --
set-tos Minimize-Delay
# On donne un maximum de débit aux transferts ftp, peu importe
la latence
iptables -A PREROUTING -t mangle -p tcp --sport ftp-data -j TOS
--set-tos Maximize-Throughput
A vous d'adapter ce script suivant les services de votre réseau que vous souhaitez prioriser.
Gestion de la bande passante sous Linux
Nous abordons la deuxième partie du document. Linux utilise deux unités du contrôle de
trafic pour la gestion de la bande passante :
• Les filtres qui placent le trafic dans les files d'attentes (fwmark, u32)
• Les files d'attentes qui décident des flux prioritaires (CBQ, HTB, RED, TBF, SFQ...)
Gardez en vue que le protocole TCP/IP n'a pas d'aptitude à connaître les performances d'un
réseau. Il commence à envoyer des paquets, de plus en plus rapidement et quand des paquets
commencent à se perdre, il ralentit. La plupart des files d'attentes fonctionnent selon le
modèle suivant : elles recoivent des paquets, les positionnent en file d'attente jusqu'à un
certain point, et ensuite, éliminent tout paquet qui arrive dans le cas où la file d'attente est
pleine. Si on travaille en UDP, les paquets ne sont plus retransmis, si c'est du TCP, l'émetteur
renverra les paquets perdus. Le débit s'en trouve alors ralenti.
Compilation du noyau
Nous allons compiler le noyau afin que celui-ci sache gérer notre BP ( = Bande Passante). Si
vous avez une ditribution récente, il se peut que vous n'ayez pas besoin de le compiler. Lancez
un "make xconfig" sous le X dans le répertoire /usr/src/linux. Si cela ne marche pas, installez
les sources du noyau (le rpm est du type kernel-src-*.rpm)
Les options
Dans la partie "Networking Options" -> "QoS and fair queuing" :
Sélection à la
Option Noyau Définition
Compilation
QoS & fair queuing oui
Netfilter module Network Packet Filtering
(Classed Based Queue) - file d'attente basée
CBQ packet sur des classes. C'est ce type de file d'attente
module
scheduler qui sera implémentée dans la suite du présent
document
(Hierarchical Token buckets) implémenté dans
HTB packet la suite du présent document - Si vous ne
module
scheduler l'avez pas, j'explique plus bas comment avoir
cette file d'attente en patchant votre noyau
(Clark-Shenker-Zhang) - Les flux ne sont pas
CSZ packet
module limités à leur bande passante. Fournit un
scheduler
service garanti
The simplest PRIO
module
pseudoscheduler
(Random Early Detect) - Anticipe les
problèmes de congestion. RED élimine les
RED queue module
paquets pour indiquer à TCP/IP de ralentir -
Pour de gros débits
(Stochastic Fair Queuing) - Limitation basée
sur le taux de transfert utilisé - Consomme peu
SFQ queue module de CPU/Mem. Rapide, peu précis. Efficace sur
de gros débits - Offre un traitement
sensiblement équitable de chaque classe
Consomme peu de CPU. Limitation basée sur
TBF queue module le taux de transfert à utiliser - Non basé sur les
classes
(Queuing discipline) - Indispensable lorsque
Ingress QDisc module
l'on souhaite utiliser les files d'attente
QoS support oui
Rate estimator oui
Packet classifier
oui
API
TC Index classifier module
Routing table based
module
classifier
Firewall based
module
classifier
U32 classifier module
Special RSVP
module
classifier
Special RSVP
module
classifier for IPv6
Les files d'attentes les plus importantes sont CBQ et HTB (la suite du document se base sur
ces deux files d'attente). Vous n'êtes pas obligé de mettre en module les autres files d'attentes
(CSZ, RED, SFQ, TBF, TEQL), cependant, cela reste toujours intéressant de les laisser en
tant que module au cas où vous en auriez besoin plus tard.
Terminer la compilation
Compilez le noyau par :
• make dep
• make clean
• make bzImage
• make modules
• make modules_install
cp /usr/src/linux/arch/i386/boot/bzImage /boot/vmlinuz
cp /usr/src/linux/arch/i386/boot/System.map /boot
Modifiez /etc/lilo.conf pour prendre en compte le nouveau noyau et lancez la commande

"lilo".
Assurez-vous enfin que votre station Linux comporte la commande "tc" (un "which tc" vous
permettra de voir si "tc" est installé). Si vous ne l'avez pas, elle fait partie du package iproute2
(les sources sont ici et le rpm peut être téléchargé là)
Désormais, votre noyau linux implémente la gestion de bande passante. Il ne reste plus qu'à
écrire un script propre à votre config, ce qui est décrit dans la suite du document.
Scripts de gestion de bande passante CBQ.init, HTB.init et wshaper.htb
Si vous souhaitez partager votre bande passante sans trop vous compliquer la vie, sachez que
des scripts on été créés afin d'optimiser votre bande passante. Dans la suite du document, je
vais vous expliquer comment les mettre en place. Lisez bien la définition de chacun de ces
scripts, de manière à définir celui qui vous convient le mieux.
CBQ.init : file d'attente CBQ
• convient à de petits débits

• nécessite de connaître la taille moyenne des paquets et la vitesse maximale de la
connexion
• utilise le temps d'inactivité de la connexion pour calculer une approximation du débit
utilisé.
HTB.init : file d'attente HTB
• convient à des gros débits

• consomme peu de ressources
• ne fait pas d'approximation en ce qui concerne le calcul du débit
• nécessite de connaitre le débit maximal de votre connexion.
Wondershaper : file d'attente HTB

• maintient une bonne réactivité pour le traffic interactif (ssh, telnet...)
• surfer sans souci lors de gros downloads
• s'assure que l'upload ne défavorise pas le download et inversement.
Remarque : Sachez que souvent, on préconise l'utilisation de files d'attentes de type HTB
plutot que CBQ. Cependant, si votre distribution n'est pas très récente, il y aura pas mal de
choses à réaliser pour implémenter les files d'attentes HTB sur votre station (j'explique
neanmoins la démarche à suivre si vous êtes dans ce cas).
CBQ.init
Récupérez le script à l'adresse suivante :
https://sourceforge.net/projects/cbqinit
Faites un "chmod u+x CBQ.init*" afin de le rendre executable.

Copiez le script dans le répertoire /usr/bin : "cp CBQ.init-[VERSION] /usr/bin"
Créez le répertoire /etc/sysconfig/cbq qui contiendra les options de gestion de BP sur lequelles
se basera le script : "mkdir /etc/sysconfig/cbq" - Si vous souhaitez placer vos fichiers de
configurations CBQ ailleurs, modifiez la variable $CBQ_PATH dans le script CBQ.init afin
de renseigner le nouveau chemin.
Exemples de fichiers de configurations pour le script CBQ.init :
Les fichiers de configuration doivent respecter une syntaxe précise de type cbq-
CLASS_ID.name où CLASS_ID est compris en hexa entre 0002 et FFFF (pour en savoir
plus, editez le script, c'est expliqué en détail).
Exemple 1 : $CBQ_PATH/cbq-1280.My_first_shaper - vous avez 2 interfaces (eth0=LAN

et eth1=INTERNET) sur votre machine et souhaitez limiter le trafic INTERNET -> LAN à 16
Ko/s
DEVICE=eth0,10Mbit,1Mbit # 10 Mbits -> debit max de votre interface eth0

RATE=128Kbit # Exprimez les valeurs en Kbit ou Mbit selon les débits spécifiés
WEIGHT=10Kbit # WEIGHT = RATE / 10
PRIO=5 # Va de 1 à 8 , 1 etant le + prioritaire (la valeur 5 est recommandée et suffisante pour
prioriser un traffic spécifique)
RULE=192.168.1.0/24
Exemple 2 : $CBQ_PATH/cbq-1280.My_second_shaper - vous avez 1 interface sur votre

machine (eth0-192.168.1.5) et souhaitez limiter le trafic MACHINE -> INTERNET à 16 Ko/s
DEVICE=eth0,10Mbit,1Mbit # La limite du traffic s'effectue sur l'interface 10 Mbits/s eth0

RATE=128Kbit
WEIGHT=10Kbit
PRIO=5
RULE=192.168.1.5, # Attention à la ',' cela permet de specifier qu'il s'agit d'une d'adresses
source ! Ici, la limitation de BP s'applique uniquement à la machine 192.168.1.5
Exemple 3 : $CBQ_PATH/cbq-1280.My_third_shaper - vous souhaitez limiter le traffic de
votre serveur web (192.168.1.50) à 8 Ko/s
DEVICE=eth0,10Mbit,1Mbit # 10 Mbits -> debit max de l'interface de votre serveur web

RULE=192.128.1.50:80,
Exemple 4 : $CBQ_PATH/cbq-1280.My_fourth_shaper - vous souhaitez limiter le traffic

des gens qui download sur votre serveur ftp (192.168.1.50) à 10 Ko/s
DEVICE=eth0,10Mbit,1Mbit # 10 Mbits -> debit max de l'interface de votre serveur ftp

RULE=192.128.1.50:20/0xfffe # limitation de BP appliquée sur port 20/21
Exemple 5 : $CBQ_PATH/cbq-1280.My_fifth_shaper - vous souhaitez que le traffic LAN -

> INTERNET soit limité à 50 Ko/s (400 Kbits/s), et que le traffic INTERNET -> LAN soit
limité à 10Ko/s (80 Kbits/s), remplissez CBQ.init de la manière suivante :
LAN ----- eth0 [LINUX] eth1 ----- INTERNET

######################## {{ LAN -> INTERNET }}
####################################
DEVICE=eth1,10Mbit,1Mbit
RATE=400Kbit
PRIO=5
BOUNDED=yes # Pour ne pas aller prendre de la BP aux classes
parents
ISOLATED=NO # Permet de léguer de la BP aux classes filles si
il en reste
RULE=192.168.0.0/24 # Le partage de BP concerne le traffic a
destination du reseau 192.168.0.0
############################################################
############
######################## {{ INTERNET -> LAN }}
####################################
DEVICE=eth0,100Mbit,10Mbit #
RATE=80Kbit # On souhaite limiter le traffic entrant à 10 Ko/s
(adaptez selon le debit de votre ligne)
PRIO=5
BOUNDED=yes
ISOLATED=NO
RULE=80,192.168.1.10 # Tout le traffic HTTP INTERNET ->
192.168.1.10 limité à 10 Ko/s
####################################
####################################
Il ne reste plus qu'à lancer le script CBQ.init à chaque démarrage ; pour cela éditez le
/etc/rc.d/rc.local et ajoutez la ligne "CBQ.init-[version] start" où [version] désigne la version
de votre script CBQ.
Si vous souhaitez obtenir des statistiques CBQ, lancez la commande "CBQ.init-[VERSION]
stats". Le script vous sortira des informations qui peuvent s'avérer utile.
Voilà, vous êtes désormais un gourou des files d'attentes CBQ :). Passons maintenant à la
gestion de la BP avec file d'attentes HTB.
HTB.init
Récupérez le script HTB.init à l'adresse suivante : http://sourceforge.net/projects/htbinit
Notes pour noyau < 2.4.18-3 : pour utiliser des files d'attentes HTB, sachez que vous devez
patcher votre noyau si il est inférieur à la version 2.4.18-3 (tapez "uname -a" pour vérifier la
version de votre distribution) :
http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.4.17.diff pour les noyaux 2.4
http://luxik.cdi.cz/~devik/qos/htb/v2/htb2_2.2.17.diff pour les noyaux 2.2
Pour appliquer le patch lancez la commande suivante dans le répertoire /usr/src/linux : "patch
-pl -i htb2_2.4.17.diff"
Dans /usr/src/linux tapez : "make xconfig"
Dans la partie "Networking Options" -> "QoS and fair Queuing", selectionnez HTB packet
scheduler en module
Recompilez le noyau : "make dep && make clean && make bzImage && make modules &&
make modules_install"
Mettez en place le nouveau noyau qui prend en charge HTB :
cp /usr/src/linux/arch/i386/bzImage /boot/vmlinuz
cp /usr/src/linux/arch/i386/boot/System.map /boot
Vous devez aussi mettre à jour la commande "tc" : http://luxik.cdi.cz/~devik/qos/htb/v2/tc.gz
Faites un "chmod u+x HTB.init-[VERSION]" afin de le rendre executable.

Copiez le script dans le répertoire /usr/bin : "cp HTB.init-[VERSION] /usr/bin"
Créez le répertoire /etc/sysconfig/htb qui contiendra les fichiers de gestion de BP sur lequelles
se basera le script : "mkdir /etc/sysconfig/htb" - Si vous souhaitez placer vos fichiers de
configurations HTB ailleurs, modifiez la variable $HTB_PATH dans le script HTB.init afin
de renseigner le nouveau chemin.
Exemples de fichiers de configurations HTB.init :
Il n'existe pas un mais plusieurs fichiers de configurations pour HTB.init. Les fichiers doivent
obligatoirement avoir une syntaxe précise. Par exemple :
eth0-2 -> classe root ID 2, device eth0

eth0-2:3 -> classe fille ID 3, ayant comme parent 2, device eth0
eth0-2:3:4 -> classe fille ID 4, ayant comme parent 3, device eth0
eth1-2.root -> classe root ID 2, device eth1
Remarque : Une autre notation en cas d'erreur lors de la creation de ce type de fichiers : eth0-
2\:3 -> Vous placez un "\" avant le ":"
Cela peut paraître un peu confu comme syntaxe, cependant, je vais vous donner des exemples.
Editez le script si vous souhaitez néanmoins en savoir plus à ce sujet.
Avec ce type de files d'attentes, vous ne pouvez realiser un contrôle de flux qu'en sortie de
vos interfaces réseaux. Dans le cas d'une station qui fait du routage, configurez les débits sur
les sorties des deux interfaces (voir exemple 2).
Exemple 1 :
Imaginons que vous ayez une bande passante sur votre station de 5 Mbits/s (~600Ko/s). Vous
souhaitez :
5Mbits/s pour le HTTP,

3Mbits/s pour le SMTP
1Kbit/s pour le traffic divers (qui vous importent peu)
Dans le cas où il y a de la bande passante de libre, vous souhaitez la partager entre le SMTP et
traffics divers.
SMTP pourra utiliser tout le temps au moins 3Mbits/s et pourra monter jusqu'à 5 Mbits/s si il
y a de la BP de libre.
Le traffic divers pourra utiliser tout le temps au moins 1Kbit/s et pourra monter jusqu'à
5Mbits/s si il y a de la BP de libre.
Allez dans le répertoire /etc/sysconfig/htb ($HTB_PATH) et placez-y les lignes suivantes

pour chaque fichier :
fichier eth0
DEFAULT=30 # ID class default - Le traffic non répertorié utilisera la class ID 30
fichier eth0-2.root
RATE=5Mbit # Bande passante allouée a la classe root (ici 5Mbits)
BURST=15k
fichier eth0-2:10.www
RATE=5Mbit
BURST=15k
LEAF=sfq # Type de file d'attente utilisée par cette classe (ici sfq)
RULE=*:80, # Voir les exemples du script CBQ.init - La syntaxe "RULE" est identique
fichier eth0-2:20.smtp
RATE=3Mbit
CEIL=5Mbit # La bande passante max de cette classe peut aller jusqu'a 5 Mbits/s uniquement
si il y a de la BP de libre.
BURST=15k
LEAF=sfq
RULE=*:25
fichier eth0-2:30.dfl
RATE=1Kbit
CEIL=5Mbit
BURST=15k
LEAF=sfq
Exemple 2 :
On traite ici le cas d'une personne ayant une connexion ADSL de type 512/128. Sa connexion
se fait via une machine-routeur possédant deux interfaces (eth0 et eth1). Elle souhaite limiter
l'upload à 90 Kbits/s (11,3 Ko/s) et donner la priorité aux services HTTP, SSH, TELNET,
POP3, SMTP et DNS. Une priorité plus petite sera attribuée à tout autre traffic. Côté,
download on garde la même idée, cependant, la limite sera fixée à 450 Kbits/s (57 Ko/s).
Allez dans le répertoire /etc/sysconfig/htb ($HTB_PATH) et placez-y les lignes suivantes

pour chaque fichier :
fichier eth1 (Tous fichier de type eth1* -> traffic sortant de l'interface eth1)
DEFAULT=30
R2Q=1
fichier eth1-2.root
#Classe root pour traffic sortant
RATE=90Kbit
fichier eth1-2\:10.high
# Classe pour traffic sortant de haute priorité
RATE=30Kbit
CEIL=prate
LEAF=sfq
#HTTP
RULE=*:80
#SSH
RULE=*:22
#TELNET
RULE=*:23
#SMTP
RULE=*:25
#DNS
RULE=*:53
#POP3
RULE=*:110
fichier eth1-2\:20.normal
# Classe pour traffic sortant normal
RATE=30kbit
CEIL=prate
LEAF=sfq
#IRC
RULE=*:6667
fichier eth1-2\:30.low
# Classe pour traffic sortant peu important
RATE=20Kbit
CEIL=prate
LEAF=sfq
#EMULE
RULE=*:3000
RULE=*:3000,
RULE=*:3010
RULE=*:3010,
RULE=*:4662 RULE=*:4662,
fichier eth0 (Tous fichier de type eth0* -> traffic sortant de l'interface eth0)
DEFAULT=30
R2Q=10
fichier eth0-2\:10.high
# Classe pour traffic sortant de haute priorité
RATE=150 Kbit
CEIL=prate
LEAF=sfq
#HTTP
RULE=*:80,
#SSH
RULE=*:22,
#TELNET
RULE=*:23,
#SMTP
RULE=*:25,
#DNS
RULE=*:53,
#POP3
RULE=*:110,
fichier eth0-2\:20.normal
# Classe pour traffic sortant normal
RATE=30kbit
CEIL=prate
LEAF=sfq
#IRC
RULE=*:6667,
fichier eth0-2\:30.low
# Classe pour traffic sortant peu important
RATE=150Kbit
CEIL=prate
LEAF=sfq
#EMULE
RULE=*:3000,
RULE=*:3010,
RULE=*:4662,
RULE=*:3000
RULE=*:3010
RULE=*:4662
RULE=*:4662
RULE=*:4662,
Il ne reste plus qu'à lancer le script HTB.init à chaque démarrage ; pour cela éditez le
/etc/rc.d/rc.local et ajoutez la ligne "HTB.init-[version] start" où [VERSION] désigne la
version de votre script HTB.
Si vous souhaitez obtenir des statistiques HTB, lancez la commande "HTB.init-[VERSION]
stats". Le script vous sortira des informations qui peuvent s'avérer utile.
wondershaper
Récupérez wondershaper à l'adresse suivante :
http://lartc.org/wondershaper
Editez le script wshaper et indiquez les débits ; par exemple pour une ligne ADSL 512/128 :
DOWNLINK= 500
UPLINK= 100
DEV=ppp0
Désormais, votre machine avec ce script :
• maintient une bonne réactivité pour le traffic interactif (ssh, telnet...)

• vous pouvez surfer sans soucis lors de gros downloads
• l'upload ne défavorise pas le download et inversement.
J'ai trouvé sur internet un script dérivé de Wondershaper, il peut s'avérer intéressant de le
mettre en oeuvre si vous avez une connexion de type ADSL. En revanche, ce script fait appel
à de nombreuses files d'attentes : CBQ, RED, IMQ, HTB et SFQ (Assurez-vous au préalable
que votre noyau les prend toutes en compte).
#!/bin/bash
#
# mon_limiteur - Limiteur et classificateur de trafic pour
modem Cable ou ADSL.
# Inspiré de WonderShaper (www.lartc.org)
#
# Écrit par Dan Singletary (7/8/02)
#
# Remarque - ce script suppose que le noyau a été patché avec
les files
# HTB et IMQ disponibles ici (les noyaux à venir ne demanderont
# pas forcément l'application d'un correctif):
# http://luxik.cdi.cz/~devik/qos/htb/
# http://luxik.cdi.cz/~patrick/imq/
#
# Options de configuration pour mon_limiteur:
# DEV - correspond au périphérique ethX connecté au modem
# RATEUP - à positionner à une valeur inférieure à la bande
# passante montante de la ligne.
# Pour ma ligne ADSL en 1500/128, RATEUP=90 convient au rythme
# montant de 128 kbps. À vous d'ajuster.
# RATEDN - à positionner en dessous de la bande passante
descendante de
# la ligne.
#
#
# Principe d'utilisation d'imq pour limiter le trafic entrant:
#
# Il est impossible de limiter directement le rythme auquel les
# données vous sont envoyées depuis l'Internet. Afin de limiter
le
# trafic entrant, on s'appuie sur les mécanismes anti-
congestion de
# TCP. Ceci signifie que SEUL LE TRAFIC TCP PEUT SE LIMITER. Le
# trafic hors TCP est placé dans une queue prioritaire car le
jeter
# ne conduit vraisemblablement qu'à une retransmission
ultérieure
# qui accroît la bande passante consommée.
# On limite le trafic TCP en jetant les paquets lorsqu'ils
débordent
# de la file HTB qui les limitera à un certain rythme (RATEDN)
# légèrement inférieur à la capacité réelle de la ligne. Jeter
ces
# paquets revient à en singer la perte par la file d'émission
du
# côté du FAI. Ceci a l'avantage d'éviter la congestion de la
file
# d'émission chez le FAI puisque TCP ralentira avant qu'elle ne
# se remplisse. L'usage d'une stratégie de mise en attente
basée sur
# la classification des paquets par priorité permet de ne PAS
jeter
# certains types de paquets (ssh, telnet, etc). Les paquets ne
sont
# retirés des files d'attente de faible priorité qu'une fois
que
# chaque classe a atteint un seuil minimum (1/7 de la bande
passante
# dans ce script).
#
# Résumé:
# * La perte d'un paquet TCP diminue le rythme de réception de
la
# connexion associée via les mécanismes de contrôle de
congestion.
# * Jeter des paquets TCP n'apporte rien. S'ils sont
importants, ils
# seront retransmis.
# * Limiter le rythme des connexions TCP entrantes en dessous
de la
# capacité de la ligne DEVRAIT éviter la mise en attente des
paquets
# du côté du FAI (DSLAM, concentrateur de cables, etc).
L'expérience
# indique que ces files contiennent 4 secondes de trafic à
1500 kbps,
# soit 6 Mb de données. À ce niveau, l'absence de mise en
attente
# diminue la latence.
#
# Avertissements:
# * Est-ce que la limitation de bande passante diminue
l'efficacité de
# transferts TCP massifs ?
# - Apparemment non. L'augmentation de priorité des paquets
# d'acquittement maximise le débit en évitant de perdre de la
bande
# passante à retransmettre des paquets déjà reçus.
#
# NOTE: La configuration ci-dessous fonctionne avec ma

connexion ADSL
# 1.5M/128K via Pacific Bell Internet (SBC Global Services)
DEV=eth0
RATEUP=90
RATEDN=700 # Nettement inférieur à la capacité de la ligne de
1500.
# On n'a donc pas à limiter le trafic entrant jusqu'à ce
# qu'une meilleure réalisation telle que la modification
# de fenêtre TCP soit disponible.
#
# Fin des options de configuration
#
if [ "$1" = "status" ]
then
echo "[qdisc]"
tc -s qdisc show dev $DEV
tc -s qdisc show dev imq0
echo "[class]"
tc -s class show dev $DEV
tc -s class show dev imq0
echo "[filter]"
tc -s filter show dev $DEV
tc -s filter show dev imq0
echo "[iptables]"
iptables -t mangle -L MONLIMITEUR-OUT -v -x 2> /dev/null
iptables -t mangle -L MONLIMITEUR-IN -v -x 2> /dev/null
exit
fi
# Remise à zéro
tc qdisc del dev $DEV root 2> /dev/null > /dev/null
tc qdisc del dev imq0 root 2> /dev/null > /dev/null
iptables -t mangle -D POSTROUTING -o $DEV -j MONLIMITEUR-OUT 2>
/dev/null > /dev/null
iptables -t mangle -F MONLIMITEUR-OUT 2> /dev/null > /dev/null
iptables -t mangle -X MONLIMITEUR-OUT 2> /dev/null > /dev/null
iptables -t mangle -D PREROUTING -i $DEV -j MONLIMITEUR-IN 2>
/dev/null > /dev/null
iptables -t mangle -F MONLIMITEUR-IN 2> /dev/null > /dev/null
iptables -t mangle -X MONLIMITEUR-IN 2> /dev/null > /dev/null
ip link set imq0 down 2> /dev/null > /dev/null
rmmod imq 2> /dev/null > /dev/null
if [ "$1" = "stop" ]
then
echo "Limitation de débit désactivée sur $DEV."
exit
fi
###########################################################
#
# Limitation de trafic sortant (limite supérieure à RATEUP)
# positionnement de la taille de la file d'émission pour

obtenir
# une latence d'environ 2 secondes pour les paquets de la file
# de faible priorité.
ip link set dev $DEV qlen 30
# modification de MTU du périphérique sortant.

# - Diminuer la MTU abaisse la latence mais dégrade le débit en
raison de
# la surcharge IP et TCP.
ip link set dev $DEV mtu 1000
# ajout de la stratégie HTB

tc qdisc add dev $DEV root handle 1: htb default 26
# ajout de la classe de limitation principale

tc class add dev $DEV parent 1: classid 1:1 htb rate
${RATEUP}kbit
# ajout des classes filles:

# - chaque classe dispose AU MOINS de son quota de bande
passante. Aucune
# classe n'est donc étouffée par les autres. Chaque classe peut
également
# consommer toute la bande passante si aucune autre classe ne
l'emploie.
tc class add dev $DEV parent 1:1 classid 1:20 htb rate
$[$RATEUP/7]kbit \
ceil ${RATEUP}kbit prio 0
$[$RATEUP/7]kbit \
$[$RATEUP/7]kbit \
$[$RATEUP/7]kbit \
$[$RATEUP/7]kbit \
$[$RATEUP/7]kbit \
$[$RATEUP/7]kbit \
# ajout de la stratégie aux classes filles

# - SFQ offre un traitement sensiblement équitable de chaque
classe.
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10
# répartition du trafic en classe via fwmark

# - le trafic est réparti en classes de priorité suivant
l'indicateur
# fwmark des paquets (ceux-ci sont positionnés avec iptables un
peu plus
# loin). La classe de priorité par défaut a été mise à 1:26 de
telle sorte
# que les paquets qui ne sont pas marqués se retrouvent dans la
classe de
# priorité la plus faible.
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 20
fw flowid 1:20
fw flowid 1:21
fw flowid 1:22
fw flowid 1:23
fw flowid 1:24
fw flowid 1:25
fw flowid 1:26
# ajout de MONLIMITEUR-OUT à la table de modification des

paquets d'iptables
# - ceci déclare la table employée pour filtrer et classer les
paquets
iptables -t mangle -N MONLIMITEUR-OUT
iptables -t mangle -I POSTROUTING -o $DEV -j MONLIMITEUR-OUT
# ajout de fwmark pour classer les différents types de trafic

# - fwmark est positionné de 20 à 26 suivant la classe. 20
correspond à la
# priorité la plus forte.
# Trafic sur les ports bas

iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport 0:1024 -j
MARK --set-mark 23
# Trafic sur les ports bas
iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport 0:1024 -j
MARK --set-mark 23
# Port ftp-data, faible priorité

iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport 20 -j MARK
--set-mark 26
# Messagerie Immédiate AOL

iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport 5190 -j
MARK --set-mark 23
# ICMP (ping) - forte priorité (impressionnez vos amis)

iptables -t mangle -A MONLIMITEUR-OUT -p icmp -j MARK --set-
mark 20
# DNS (petits paquets)

iptables -t mangle -A MONLIMITEUR-OUT -p udp -j MARK --set-mark
21
# shell sécurisé
iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport ssh -j
MARK --set-mark 22
# shell sécurisé
iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport ssh -j
MARK --set-mark 22
# telnet (hum ...)

iptables -t mangle -A MONLIMITEUR-OUT -p tcp --dport telnet -j
MARK --set-mark 22
# telnet (hum ...)

iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport telnet -j
MARK --set-mark 22
# IPSec - la surcharge n'est pas connue ...

iptables -t mangle -A MONLIMITEUR-OUT -p ipv6-crypt -j MARK --
set-mark 24
# Serveur WWW local

iptables -t mangle -A MONLIMITEUR-OUT -p tcp --sport http -j
MARK --set-mark 25
# Petits paquets (des ACK probablement)
iptables -t mangle -A MONLIMITEUR-OUT -p tcp -m length --length
:64 -j MARK --set-mark 21
# Répétition - on marque les paquets restants à 26 (faible

priorité)
iptables -t mangle -A MONLIMITEUR-OUT -m mark --mark 0 -j MARK
--set-mark 26
# Fin de la limitation sortante

#
####################################################
echo "Limitation de trafic sortant activé sur $DEV. Débit:

${RATEUP}kbit/sec."
# Décommenter la ligne suivante pour n'avoir que la limitation

de trafic montant.
# exit
#################################################### #
# Limitation du trafic entrant (débit maximal de RATEDN)
# on force le chargement du module imq
modprobe imq numdevs=1
ip link set imq0 up
# ajout de la stratégie de mise en file d'attente

# - par défaut une classe 1:21 à faible priorité
tc qdisc add dev imq0 handle 1: root htb default 21
# ajout de la classe de limitation principale

tc class add dev imq0 parent 1: classid 1:1 htb rate
${RATEDN}kbit
# ajout des classes filles

# - trafic TCP en 21, le reste en 20
#
tc class add dev imq0 parent 1:1 classid 1:20 htb rate
$[$RATEDN/2]kbit \
ceil ${RATEDN}kbit prio 0
tc class add dev imq0 parent 1:1 classid 1:21 htb rate
$[$RATEDN/2]kbit \
ceil ${RATEDN}kbit prio 1
# ajout de la stratégie de limitation aux classes filles

# - voir les remarques ci-dessus sur SFQ.
tc qdisc add dev imq0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev imq0 parent 1:21 handle 21: red limit 1000000
\
min 5000 max 100000 avpkt 1000 burst 50
# répartition du trafic en classe via fwmark

# - le trafic est réparti en classes de priorité suivant
l'indicateur
# fwmark des paquets (ceux-ci sont positionnés avec iptables un
peu plus
# loin). La classe de priorité par défaut à été mise à 1:26 de
telle sorte
# que les paquets qui ne sont pas marqués se retrouvent dans la
classe de
# priorité la plus faible.
tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 20
fw flowid 1:20
tc filter add dev imq0 parent 1:0 prio 0 protocol ip handle 21
fw flowid 1:21
# ajout de MONLIMITEUR-IN à la table de modification des

paquets d'iptables
iptables -t mangle -N MONLIMITEUR-IN
iptables -t mangle -I PREROUTING -i $DEV -j MONLIMITEUR-IN
# ajout de fwmark pour classer les différents types de trafic

# - fwmark est positionné de 20 à 21 suivant la classe. 20
correspond à la
# priorité la plus forte.
# Forte priorité pour les paquets non TCP

iptables -t mangle -A MONLIMITEUR-IN -p ! tcp -j MARK --set-
mark 20
# Les petits paquets TCP sont probablement des ACK

iptables -t mangle -A MONLIMITEUR-IN -p tcp -m length --length
:64 -j MARK --set-mark 20
# shell sécurisé
iptables -t mangle -A MONLIMITEUR-IN -p tcp --dport ssh -j MARK
--set-mark 20
# shell sécurisé
iptables -t mangle -A MONLIMITEUR-IN -p tcp --sport ssh -j MARK
--set-mark 20
# telnet (hum ...)

iptables -t mangle -A MONLIMITEUR-IN -p tcp --dport telnet -j
MARK --set-mark 20
# telnet (hum ...)

iptables -t mangle -A MONLIMITEUR-IN -p tcp --sport telnet -j
MARK --set-mark 20
# Répétition - les paquets sans marque sont positionnés à 21

(faible priorité)
iptables -t mangle -A MONLIMITEUR-IN -m mark --mark 0 -j MARK -
-set-mark 21
# on envoie les paquets précédents à l'interface imq0.

iptables -t mangle -A MONLIMITEUR-IN -j IMQ
# Fin de la limitation de trafic entrant.

#
####################################################
echo "Limitation de trafic entrant activée sur $DEV. Débit:

${RATEDN}kbit/sec."
Script de visualisation des files d'attentes
Le script suivant visualise les files d'attentes :
#!/bin/bash
echo 'Qdisc'
tc -s qdisc show dev eth0
echo 'Classes'
tc -s class show dev eth0
echo 'Filter'
tc -s filter show dev eth0

Ethereal - IPRoute 2 - QoS

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ethereal - IPRoute 2 - QoS

Transféré par

Droits d'auteur :

Formats disponibles

FORMATON ETHEREAL - IPROUTE 2 - QOS

18-19-20-21 AVRIL 2005

Quelques principes simples

simultanément. • on peut relier ou retirer une machine du réseau sans perturber le

Ethernet a été intégré dans le modèle OSI

Comme dans le cas des principes énoncés ci-avant, la généralisation de la commutation

Une évolution constante

La simplicité de la méthode d'accès et la simplicité de l'interconnexion avec les autres

En 1997 : La norme IEEE 802.3x a défini le mode «full-duplex» qui permet de

Ce document est construit à partir des 4 familles de débits d'Ethernet :

Définitions IEEE 802.3

AUI : Attachment Unit Interface

Ethernet IEEE 802.3

C'est le point de départ de la normalisation. La première définition est la plus proche du

Exemple de topologie BUS Ethernet IEEE 802.3

Tableau 1. Ethernet Standard

Appellations 10Base5, Thick Ethernet

Tableau 2. Ethernet Fin

Appellations 10Base2, Thinnet ou Thin Ethernet

IEEE 802.3 c-d

Le répéteur ineterconnecte les brins de média entre eux en :

La liaison FOIRL doit avoir une longueur inférieure ou égale à 1 Km.

Appellations 10BaseT débit 10Mbps

Appellations 10Base-F débit 10Mbps

Fast Ethernet IEEE 802.3u

Appellations 100BaseT débit 100Mbps

Appellations 100BaseFX débit 100Mbps

Comme pour la famille FastEthernet, il existe plusieurs variantes 1000BaseX.

Définitions IEEE 802.3z : 1000BaseX

Définition 1000BaseT : IEEE802.3ab

Tableau 10. 1000Base-T

6.3. Extension CSMA/CD

Avec la définition GigabitEthernet, la méthode d'accès CSMA/CD n'est pas remise en

Négociation de la bande passante

La négociation entre équipements porte sur deux fonctionnalités :

le débit 10, 100 et 1000Mbps,

L'ordre des négociations est le suivant :

Mode Full-Duplex IEEE 802.3x

Le mode de fonctionnement de base d'Ethernet est dit Half-Duplex : bidirectionnel à l'alternat.

Le mode Full-Duplex correspond à une communication point-à-point entre deux équipements.

Exemple de conception Ethernet

1 100BaseFX FD : artère de campus en fibres optiques avec un débit de 200Mbps en

Le préambule est une suite de 0 et de 1 alternés. Il permet à l'horloge du récepteur de se

Les adresses MAC

Le champ longueur / type

9.4. Les données

Ce phénomène résulte de la superposition de 2 trames sur le média lorsque deux stations

Les collisions tardives

Ce type de collision intervient lorsque la longueur du câble dépasse la norme ou lorsqu'il y a

Couche liaison et Ethernet

Sous-couche MAC : Méthode d'accès CSMA/CD

Sous-couche LLC : IEEE 802.2

A partir de cette sous-couche, on sort du domaine d'appelation Ethernet. Cependant, de

Le type d'opération 3 est un service datagramme (sans connexion) acquitté, sans

La signalisation. Dans le domaine de l'instrumentation réseau on ne mélange pas le test de

Les autres définitions 100Mbps. Il en existe 2 : 100BaseT2 et 100BaseVG AnyLan. Pour le

Comment identifier le périphérique réseau ?

Il existe un grande variété de contrôleurs ethernet. A chaque composant correspond un pilote

00:0e.0 Network controller: Cologne Chip Designs GmbH ISDN

Subsystem: Cologne Chip Designs GmbH: Unknown device b401

Flags: bus master, medium devsel, latency 16, IRQ 11

I/O ports at e400 [size=8]

Memory at e9001000 (32-bit, non-prefetchable) [size=256]

Capabilities: [40] Power Management version 1

for param in `find /proc/sys -type f -name "$1"`; doecho