Mohamed Saïdane Profiling

Guide pour les Administrateurs Systèmes et Réseaux
1 – Introduction 3
2 – Performances : Les bases 3
2.1 – Les critères de performance (telle que perçue par l’utilisateur) 3
2.1.1 – Le temps de réponse « applicatif » 3
2.1.2 – Capacité et débit 4
2.1.3 – Fiabilité 4
2.2 – Les métriques réseau liées à la performance 4
2.2.1 – One-Way Delay (OWD) 5
2.2.2 – Propagation Delay 5
2.2.3 – Serialization Delay 5
2.2.4 – Autres sources de délais 5
2.2.5 - Round-Trip Time (RTT) 6
2.2.6 – Delay Variation (Jitter/Gigue) 6
2.2.7 Packet Loss 6
2.2.8 Packet Reordering 6
2.2.9 Maximum Transmission Unit (MTU) 7
2.2.10 – Bandwidth Delay Product (BDP) 7
3 – Méthodologie pour la résolution de problèmes de performance 7
3.1 – Description du problème 7
3.2 – Collecte d'information 8
4 – Les problèmes de performance rencontrés 8
4.1 – Les problèmes de performance liés aux équipements d’extrémité : 8
4.2 – Eléments pouvant entraîner une dégradation du service au niveau d’un
site/campus: 9
4.2.1 - Boîtiers intermédiaires (Firewall, proxy, NAT, boîtiers de
performances) 9
4.2.2 - Half/Full duplex et Auto-négociation 9
4.2.3 - Collision dans un LAN (utilisation de Hubs) 10
4.2.4 – Réseaux sans fils 10
4.2.5 - Domaine de broadcast dans un réseau à base de commutateurs 10
5 – Les réseaux traversés et les services offerts (dans le monde académique): 10
6 – Evaluation des performances : Méthodes et outils 11
6.1 – Avant le problème de performance 11
6.2 – Résoudre les problèmes de performance 12
7 - Conclusion 13
Glossaire: 13
References: 13
Ce document décrit les procédures à utiliser par les administrateurs systèmes et réseaux (ASR) pour
résoudre les problèmes de performance réseaux. Sont exposés ici les différents types d’incidents ainsi
que les procédures/outils à mettre en place pour aborder ces problèmes et tenter de les résoudre.
Etant donné qu’il existe déjà un grand nombre d’outils permettant de déceler les pannes, nous nous
focalisons ici principalement sur les incidents liés aux problèmes de performances dans les réseaux
(dégradation plutôt que coupure d’un service).
1 – Introduction
Lorsqu’un problème de performance de bout en bout est constaté, la première étape est de bien le
décrire. L’utilisateur final a ici un rôle très important dans la compréhension et la description du
problème tel qu’il est perçu. L’ASR doit ainsi récupérer un ensemble de données lui permettant de
faire ensuite une investigation approfondie.
Une fois ces informations recueillies, l’étape suivante est de localiser le problème ; il s’agit de savoir
quel(s) maillon(s) du réseau et des systèmes est/sont en cause. Cette étape nécessite souvent
l’utilisation d’outils.
Enfin, une fois le problème repéré, l’ASR tentera de le résoudre dans la mesure du possible.
2 – Performances : Les bases
2.1 – Les critères de performance (telle que perçue par
l’utilisateur)
La performance d'une application réseau observée par un utilisateur est fonction d’un ensemble de
critères qualitatifs. Certaines applications ne sont sensibles qu’à l’un de ces critères : par exemple, les
applications de voix sont principalement sensibles au temps de réponse alors que les applications de
transferts seront-elles sensibles au débit. Plus généralement, une combinaison de ces critères
détermine la performance observée par l’utilisateur final.
2.1.1 – Le temps de réponse « applicatif »
Un des critères les plus important dans l’évaluation de la performance d’une application est son temps
de réponse. Il s’agit ici du temps mis par l’application pour répondre à une requête de l’utilisateur. Ce
critère est particulièrement critique pour les applications temps-réel telles que les systèmes de
conférence audio/vidéo. Il est difficile cependant de définir des temps de réponse pour qualifier
l’application car ils varient considérablement d’une application à l’autre.
Pour les applications multimedia, une méthode pour qualifier le flux audio est l’utilisation du MOS
(Mean Opinion Score) : Il s'agit d'une note donnée au codec audio utilisé par l’application pour
caractériser la qualité de la restitution sonore. La note peut varier entre 0 et 5 :
Mean Opinion Score (MOS)
MOS Qualité Dégradation
5 Excellente Imperceptible
4 Bonne Perceptible mais pas gênante
3 Moyenne Légèrement gênante
2 Mauvaise Gênante
1 Très Mauvaise Très gênante
2.1.2 – Capacité et débit
La capacité est la quantité d’information qui peut être véhiculée dans un lien réseau pendant un
intervalle de temps. L’unité utilisée est le bit par seconde (bit/s). Ce paramètre est fonction des
propriétés physiques du support utilisé, de la technologie de transport utilisée, etc.
Le débit est la quantité d’information traversant un lien réseau pendant un intervalle de temps. Le
débit est un paramètre qui n’est pas directement perçu par l’utilisateur. Cependant, le débit est
souvent utilisé en tant que métrique “commerciale” pour mieux différencier les liaisons haut débit de
celles à bas débit. Les applications indiquent donc souvent ce paramètre, ce qui permet aux
utilisateurs de vérifier si le débit observé correspond bien à la capacité de la liaison.
2.1.3 – Fiabilité
La fiabilité est souvent le critère le plus important pour un utilisateur. Ce paramètre repose sur la
notion de disponibilité. L’application doit être disponible lorsque l’utilisateur en a besoin. Ceci ne veut
pas forcement dire que l’application doit être toujours disponible bien que des applications comme un
serveur web dans une société doit avoir une disponibilité de 7 jours sur 7, 24 heures sur 24.
2.2 – Les métriques réseau liées à la performance
Une autre approche pour observer les performances est de se focaliser sur les caractéristiques du
réseau qui sont mesurables. Il y a un ensemble de métriques qui sont utilisées pour caractériser les
performances des réseaux. Les plus importantes sont décrites dans la suite du document ainsi que les
méthodes pour les mesurer.
La métrique qui représente le plus grand intérêt est souvent la bande passante. Cependant, avec
l’augmentation de la capacité des liens dans les dernières années, ce paramètre n’est plus le facteur
limitant dans les performances réseau.
Le groupe de travail de l’IETF, IP Performance Metrics (IPPM) a définit les métriques spécifiques aux
performances réseau.
2.2.1 – One-Way Delay (OWD)
Le One-Way Delay ou délai unidirectionnel est le temps que prend un paquet pour atteindre sa
destination. La RFC 2679 décrit cette métrique définie par le groupe IPPM.
Le délai introduit par le réseau a souvent un impact sur la performance surtout dans les réseaux
longue distance. Cette métrique peut être décomposée en plusieurs délais introduits par les différents
éléments du réseau :
• Les liens introduisent des délais de propagation
• Les noeuds introduisent des délais de sérialisation, de forwarding et de queuing
2.2.2 – Propagation Delay
Le Propagation Delay ou délai de propagation est le temps mis par le signal pour traverser le(s) lien(s)
physique(s). Ce délai est fonction de la longueur des liens et de la vitesse de propagation du signal
dans ces liens. La vitesse de propagation du signal dans une fibre optique est de l’ordre de 200 000
km/s (0,66c où c est la vitesse de propagation de la lumière dans le vide) alors qu’elle peut varier pour
le cuivre de 0,66c à 0,95c en fonction du type de ligne de transmission.
Ex : 5 ms de délai de propagation pour 1000 km de fibre optique
2.2.3 – Serialization Delay
Le Serialization Delay ou délai de sérialisation est le temps nécessaire pour qu'un paquet soit introduit
dans la ligne de transmission. Ce délai dépend de la taille du paquet mais aussi de la capacité de la
ligne.
Vu l’augmentation des débits dans les backbones, le délai de sérialisation n’est plus un problème
majeur étant donné que la taille des paquets n’a pas évolué énormément.
Ex : 12 microsecondes pour la sérialisation de 1500 octetes sur une liaison à 1 Gbps, ; 6
millisecondes pour la sérialisation de 1500 octetes sur une liaison à 2 Mbps
2.2.4 – Autres sources de délais
Aux délais de propagation et de sérialisation viennent s’ajouter d’autres délais
• Le Forwarding Delay
Le Forwarding Delay est le temps que met un noeud pour traiter un paquet. Le traitement du paquet
consiste en la lecture de l’adresse destination (et des autres paramètres nécessaires dans l'en-tête),
le calcul de la décision de forwarding (basé sur les tables de routage généralement) et l’envoie du
paquet vers l’interface appropriée. Ceci implique la copie du paquet vers une interface différente à
l’intérieur du noeud, la réécriture de certains champs de l’en-tête et d’autres traitements tels que la
fragmentation des paquets, l’accounting, etc.
La plupart des routeurs de coeur sont équipés aujourd’hui de cartes matérielles dédiés pour traiter la
fonction de forwarding. Dans le cas contraire, la fonction de forwarding est traitée par la CPU du
routeur et peut donc entrer en concurrence avec d’autres tâches qu’effectue le routeur entraînant des
problèmes de performance.
• Queuing Delay
Le Queuing Delay définit le temps que passe un paquet dans les files d’attentes du routeur. Ce délai
dépend de la charge de trafic dans les interfaces entrante et sortante, et de la priorité du paquet.
2.2.5 - Round-Trip Time (RTT)
Le Round-trip time (RTT) est le temps que met un paquet envoyé par A pour atteindre sa destination
B plus le temps que met le paquet de réponse envoyé par la destination B pour atteindre A: C’est la
somme des OWD de A vers B et de B vers A plus le temps nécessaire à B pour envoyer un paquet de
réponse.
Lorsque la valeur du RTT est élevée, cela peut entraîner des problèmes au niveau de TCP. Ces
problèmes seront décrits dans la suite du document.
Pour les applications interactives telles que les applications audio/video, le RTT peut avoir un impact
direct sur la perception du temps de réponse.
2.2.6 – Delay Variation (Jitter/Gigue)
Dans un réseau idéal, l’ensemble des paquets empruntant un même chemin ont exactement le même
OWD. Dans un réseau réel, le OWD n’est pas constant ; La différence entre le OWD d’un paquet
donné et la moyenne du OWD représente le Delay Variation ou variation de délai. Ce paramètre est
souvent appelé Jitter ou gigue. La gigue est souvent causée par des variations des temps d’attente
dans les files des routeurs. Lorsqu’un réseau est fortement chargé, cela se traduit souvent par de la
gigue.
La gigue est définie dans La RFC 3393 : IP Delay Variation Metric (IPDV)
2.2.7 Packet Loss
Packet Loss ou perte de paquet est définie comme la probabilité qu’un paquet soit perdu lorsqu’il est
envoyé par la source A vers la destination B. 2 RFC définissent la notion de perte de paquets :
• La RFC 2680 définit une métrique sur la perte de paquets unidirectionnels.
• La RFC 3357 se base sur la RFC 2680 pour définir des métriques additionnelles permettant
d’établir un modèle sur la perte des paquets dans l’Internet.
En fonction des applications utilisées, les paquets perdus seront retransmis par la couche supérieure
(TCP généralement). Par exemple, pour les applications de transfert de fichiers, la retransmission de
paquets est indispensable alors que pour des applications vidéo temps réel, la retransmission des
paquets perdus n’a aucun sens (les paquets retransmis arriveraient en retard).
La congestion des files d’attente et les erreurs de transmission (qui entraînent des corruptions de
paquets) sont souvent la cause de pertes de paquets.
2.2.8 Packet Reordering
Le protocole IP n’assure pas l’ordonnancement des paquets à l’arrivée. Ce sont les couches
supérieure (TCP dans la plupart des cas) qui assurent la fonction de Packet Reordering ou de réordonnancement
de paquets.
Cependant, le ré-ordonnancement des paquets peut avoir un impact important au niveau des
performances sur certaines implémentations de la pile TCP. De récentes implémentations de TCP, en
particulier celles supportant les SACK (Selective Acknowledgement, accusé de réception sélectif) sont
beaucoup plus robustes au phénomène de re-ordonnancement bien que le débit soit très peu
impacté.
2.2.9 Maximum Transmission Unit (MTU)
La MTU correspond à la taille maximale d’un paquet pouvant traverser un lien sans être fragmenté.
Les valeurs courantes des MTU sont :
• 1500 octets (Ethernet, 802.11)
• 4470 octets (valeur par défaut pour les interfaces POS)
• 9000 octets (convention entre Internet2 et GEANT correspondant également à la limite de
nombreux adaptateurs Gigabit Ethernet)
Path MTU:
Le Path MTU est la taille maximale d’un paquet pouvant traverser un chemin réseau. C’est la valeur
minimale de l’ensemble des MTUs des liens du chemin. La valeur du Path MTU la plus répandue est
1500 octets (Ethernet MTU). Il existe des initiatives pour encourager l’utilisation de valeurs de MTU
plus grandes (Jumbo MTU), particulièrement dans les réseaux de la recherche, mais des problèmes
sont souvent rencontrés : last-mile, non supporté par les équipements réseaux, lacunes au niveau de
la définition du Path MTU Discovery (PMTUD : RFC1191, mécanisme permettant de découvrir la
valeur du Path MTU). La RFC 2923 décrit les limitations du PMUD et l’impact sur le protocole TCP.
Un groupe de l’IETF (http://www.ietf.org/html.charters/pmtud-charter.html) est en train de définir un
nouveau mécanisme pour le Path MTU Discovery pour résoudre ces problématiques. Le groupe
essaye entre autres de rendre le mécanisme PMTUD indépendant des messages ICMP afin d’éviter
les problèmes de filtrages, etc.
2.2.10 – Bandwidth Delay Product (BDP)
Le Bandwidth Delay Product d’un chemin de bout en bout correspond à la bande passante maximale
que l'on peut obtenir sur le chemin (correspond au goulot d’étranglement du chemin) multipliée par le
délai du chemin. L’unité utilisée pour représenter ce paramètre est généralement l’octet. On associe
souvent ce paramètre à la « capacité mémoire » du chemin, c’est à dire la quantité de données qui
peut être contenue dans le chemin réseau à un instant donné.
Les réseaux ayant un BDP élevé sont appelé Long Fat Networks ou LFN. Dans le monde de la
recherche, certains projets internationaux utilisent ce type de réseaux. La caractéristique BDP est
donc à prendre en compte dans la performance des protocoles tel que TCP. Il faut souvent modifier
les paramètres des piles TCP des équipements terminaux afin qu’elles soient adaptées aux réseaux
LFN (cf. 4.1).
3 – Méthodologie pour la résolution de problèmes
de performance
Cette partie donne une méthodologie à suivre pour résoudre un problème de performance.
L'expérience de l'utilisateur final est l'un des facteurs les plus important dans la résolution des
problèmes de performances puisqu'il s'agit de savoir pourquoi les performances attendues ne sont
pas atteintes. Par conséquent, l'utilisateur a un rôle très important dans la définition, la compréhension
et la communication du problème perçu, d'autant plus que le nombre de domaines administratifs
impliqués dans le problème est souvent important.
3.1 – Description du problème
Il faut toujours décrire clairement le comportement de l'application qui subit des problèmes de
performances. Il est important de définir également le fonctionnement de l'application lorsque celle-ci
ne subit pas de dégradation de service.
Il faut s'assurer que l'utilisateur transmet les bonnes informations et est précis (spécifier les
dates/heures de la dégradation, éviter les confusions entre bit et octet (Byte), etc.).
Exemple: 10Mbit/s=10Mb/s=1,25MBytes/s=1,25MB/s
Les messages d'erreurs renvoyés par l'application ou des captures d'écran sont souvent appréciables
pour la compréhension du problème.
3.2 – Collecte d'information
Bien que les administrateurs puissent demander simplement l'information manquante au fur et à
mesure du diagnostic, il est préférable dans un premier temps de collecter un certain nombre
d'éléments afin de faciliter la documentation du problème et d’accélérer sa résolution. Ainsi, il devient
également plus facile de demander à un tiers son expertise pendant l'investigation.
Les premières informations qui doivent être collectées sont les suivantes concernant les extrémités. Il
faut communiquer dans la mesure du possible les informations des deux systèmes finaux:
􀂃 Le type d'application/logiciel et son mode de fonctionnement
􀂃 Les piles protocolaires employées (RTP, TCP, UDP, IPv4, IPv6, etc)
􀂃 Les systèmes d'exploitation (version, noyau, etc.)
􀂃 Les adresses IP et les ports de niveau 4 des extrémités
􀂃 Le type de cartes réseau, processeur, et taille de mémoire.
Une fois que les informations concernant les extrémités sont collectées, il faut récupérer les
informations concernant le chemin. L'outil traceroute permet de connaître le chemin réseau emprunté.
Il est important que ce travail soit réalisé dans les deux sens.
D’autres informations, telles que le type de CPU ou la taille de mémoire vive disponible ne sont pas du
ressort de l’ASR ; elles peuvent toutefois causer des problèmes de performances (ralentissement de
la machine, etc.) : Une fois que l’utilisateur aura vérifié que le problème de performance n’est pas lié à
ces paramètres, il pourra contacter l’ASR afin de lui transmettre les informations listées ci-dessus.
4 – Les problèmes de performance rencontrés
Les problèmes de performance peuvent intervenir à plusieurs niveaux:
• Ils sont souvent liés à une mauvaise configuration des équipements terminaux,
• Ils peuvent aussi se situer au niveau du réseau local ou du réseau de campus,
• Ils peuvent être causés par des éléments traversés au niveau des réseaux de collecte
nationaux ou internationaux.
4.1 – Les problèmes de performance liés aux équipements
d’extrémité :
Les éléments d'extrémité sont souvent les responsables des problèmes de performance. L'ASR doit
s'assurer que la machine est bien dimensionnée pour le type d'application (processeur suffisamment
puissant, mémoire suffisante, système d'exploitation adapté).
L'ASR doit également vérifier que la machine est configurée correctement. Si l'application repose sur
le protocole TCP, la vérification des paramètres TCP (buffers, etc.) est importante surtout si des
réseaux de type LFN sont traversés (voir tableau 2.2.10). Un guide de configuration de la pile TCP est
disponible sur le site web http://www-didc.lbl.gov/TCP-tuning/linux.html.
Voici quelques résultats de débits observés pour des liaisons ayant des RTT différents. Plusieurs
versions de noyaux linux ont été utilisées. Les débits indiqués correspondent au débit maximum
observé pendant un test de 3 minutes sur une liaison dont le débit du segment le plus lent est de 1
Gbps.
Linux 2.4
Linux 2.4
Linux 2.6
Linux 2.6
Buffers TCP
non modifiés
TCP manuellement
modifiés
Sans BIC (Binary Increase
Congestion control)
Avec
BIC
RTT = 67ms
10Mbps 300Mbps 500Mbps 700Mbps
RTT = 83ms
8Mbps 300Mbps 625Mbps 830Mbps
RTT = 153ms
4Mbps 70Mbps 140Mbps 560Mbps
Source: http://dsd.lbl.gov/TCP-tuning/TCP-Tuning-Tutorial.pdf
4.2 – Eléments pouvant entraîner une dégradation du
service au niveau d’un site/campus:
4.2.1 - Boîtiers intermédiaires (Firewall, proxy, NAT, boîtiers de performances)
Il existe un nombre important de boîtiers pouvant s'insérer entre les deux extrémités, la plupart sur le
réseau local, chacun ayant des fonctions bien spécifiques. En voici quelques uns:
􀂃 Pare-feux
􀂃 Lisseur de trafic
􀂃 Boîtiers NAT
􀂃 Proxies/Mandataires
􀂃 VPNs
Ces boîtiers offrent souvent des fonctionnalités intéressantes mais au détriment des performances
réseaux. En effet, ces éléments introduisent des délais supplémentaires, de la gigue, et causent des
pertes de paquets. Il faut donc être vigilant et prendre en compte ces éléments dans la résolution des
problèmes de performance.
4.2.2 - Half/Full duplex et Auto-négociation
Un segment Ethernet a deux modes de fonctionnement: half duplex ou full duplex. Dans le mode half
duplex, uniquement une station peut émettre à un moment donné alors qu'avec le mode full duplex,
les deux stations du segment peuvent émettre simultanément.
L'auto-négociation est un mécanisme qui permet à deux stations sur un lien point-à-point de négocier
le mode half/full duplex. Il est évident que le mode full duplex est préféré si les deux stations le
supportent. Ce mécanisme évite qu'une station soit en half-duplex et une autre en full duplex (duplex
mismatch), ce qui cause des problèmes de performance.
Il y a quelques années, des problèmes d'interopérabilité pouvaient apparaître avec l'auto-négotiation,
mais aujourd'hui ce mécanisme est devenu fiable. Si vous disposez d’équipements récents et d’un
parc homogène, la recommandation est d'activer ce mécanisme afin d'éviter les problèmes de
performances. Lorsqu’il s’agit de configuration d’un lien entre deux réseaux gérés par des entités
administratives différentes, il est préférable de se mettre d’accord préalablement avec le gestionnaire
du réseau (préférer toujours le mode full-duplex des deux cotés et en figer la configuration dans les
équipements d’extrémité).
4.2.3 - Collision dans un LAN (utilisation de Hubs)
Même si cela a tendance à disparaître, certaines stations sont raccordées via des hubs dans les
réseaux locaux. Le phénomène de collision peut donc être présent. Des pertes de paquets peuvent
apparaître entraînant des problèmes de performance.
Dans la mesure du possible, la solution est de faire évoluer son parc réseau vers un réseau à base de
commutateurs plutôt que des hubs, réduisant ainsi fortement le domaine de collision.
4.2.4 – Réseaux sans fils
Le paragraphe précédent explique que le domaine de collision peut être réduit en remplaçant les hubs
par des commutateurs. Dans les réseaux sans fils, la méthode d’accès employée est CSMA/CA
(Carrier Sense Multiple Access with Collision Avoidance) qui permet d’éviter les collisions. Cependant,
le média est tout de même partagé par l’ensemble des utilisateurs ce qui peut entraîner des
problèmes de performances dues au sous dimensionnement de l’ensemble du réseau sans fil.
4.2.5 - Domaine de broadcast dans un réseau à base de commutateurs
Bien que les commutateurs réduisent les domaines de collision, ils permettent de diffuser les requêtes
broadcast et multicast. Dans un réseau commuté où il y a un grand nombre de stations sur le même
réseau IP, cela peut avoir des conséquences néfastes pour les performances réseau du fait des
tempêtes de trames broadcast. Afin d'éviter cela, il est conseillé de segmenter le réseau en sousréseaux,
les domaines de broadcast seront ainsi réduits. L'utilisation de VLAN est conseillée pour faire
cette segmentation du réseau car elle ne sera pas forcément physique.
5 – Les réseaux traversés et les services offerts
(dans le monde académique):
Une bonne connaissance de la topologie des réseaux traversés ainsi que les services offerts est
essentielle dans le diagnostic et la résolution des problèmes de performance de bout en bout.
Dans la plupart des cas, les sites sont raccordés à des réseaux de collecte. Ce sont généralement des
réseaux haut débit offrant une bonne connectivité (de l’ordre du Gbps). Ces réseaux de collecte sont
raccordés généralement à RENATER, le Réseau National de Télécommunication pour
l'Enseignement et la Recherche, qui offre également une bonne connectivité (des liens à 2.5Gbps
ainsi qu’une infrastructure fibre noire pour des usages précis nécessitant d’importantes capacités).
Ces réseaux mettent à la disposition des utilisateurs un ensemble d'information qui pourra être utile
pendant la phase de débogage : Coordonnées, outils réseau (looking glass), etc:
http://gt-metro.grenet.fr/index.php/Liste_des_r%C3%A9seaux_de_collecte
RENATER est raccordé à GEANT2, le réseau paneuropéen de la recherche (Les liens dans GEANT2
ont une capacité de 10Gbps). Des informations concernant les outils employés par GEANT ainsi que
les autres réseaux de la recherche en Europe sont disponibles: http://stats.geant.net/
Des outils tels que perfsonar (http://www.perfsonar.net) sont développés par les réseaux de la
recherche afin de faciliter l’échange d’information de supervision entre réseaux. Il est ainsi plus simple
d’avoir les informations de bout en bout.
Une structure appelée PERT permet également de signaler des problèmes de performance entre
utilisateurs des différents réseaux de la recherche dans le monde. Cette équipe est chargé
d’investiguer et de résoudre ces problèmes de performance.
6 – Evaluation des performances : Méthodes et
outils
6.1 – Avant le problème de performance
Il est recommandé de faire des mesures régulièrement sur le réseau afin de connaître la « santé » du
réseau. Il ne faut pas attendre qu’un incident arrive pour faire ces mesures ; en effet l’analyse de
l’historique permet souvent de constater un changement associé à une dégradation (surcharge d’un
lien, etc). Sans ces mesures, il est beaucoup plus difficile d’établir un diagnostic lorsqu’un problème
de performance est rencontré :
• SNMP: MRTG/RRDtool est l’outil le plus répandu pour grapher le trafic et autres compteurs utiles
(charge des liens, CPU, nombres de routes, etc). Simple à installer, Il peut être interfacé avec des
outils facilitant la visualisation (CACTI, etc).
• Flow accounting: Le standard IPFIX de l’IETF définit un format d’export des flux qui transitent
dans le réseau. Ce standard est basé sur le format Netflow développé par Cisco. Si les
équipements réseau le permettent, des informations pertinentes sur les flux peuvent être
exportées vers un collecteur. L'étude des flux révèle souvent des problèmes de performances
(boucle de routage, etc). Netflow est le format le plus répandu (Cisco), mais d’autres
constructeurs proposent des formats d’exports alternatifs (sflow, etc).
D’autres mesures consistent à générer du trafic pour simuler les conditions d’usage des utilisateurs
(métrologie active). Il est utile d’avoir un ensemble de mesures actives qui sont réalisées
régulièrement (mesures par type d’application, par classes de services, etc). Plusieurs outils sont
disponibles, chacun ayant des fonctionnalités bien précises
• Ping : Le ping permet de déterminer le temps d’aller/retour. Il est ainsi possible de déterminer si
un équipement est joignable ou pas. Le ping utilise le protocole ICMP qui est souvent filtré par les
administrateurs. Il faut donc prendre en compte cela. L’option –n du ping qui évite la résolution
inverse de l’adresse IP, peut s’avérer utile dans certains cas.
• Ping « applicatif » : Il s’agit d’un ping qui permet de calculer le temps de réponse applicatif. Les
paquets sont traités tels qu’un paquet applicatif. Ceci permet d’éviter les problèmes liés au
traitement des paquets ICMP par les équipements traversés. Ainsi, si l’on veut vérifier si un
serveur web fonctionne correctement, le ping se fera sur le port TCP 80. Smokeping ou echoping
sont deux outils permettant de réaliser des pings applicatifs.
• Traceroute : Cet outil permet de déterminer le chemin emprunté par un paquet. Il peut par
exemple permettre de déceler un problème de routage si le nombre de sauts varie dans le temps.
• Des plateformes de supervision et boîtiers de mesures : Les plateformes de supervision et
boîtiers de mesures intègrent souvent les outils cités préalablement. Il est possible également de
développer des scripts utilisant ces outils pour s’adapter aux besoins d’un site. La procédure
serait de déterminer quels sont les tests pertinents puis ensuite grapher les résultats. Ceci peut
aider à repérer les causes d’un problème de performance.
• Générateur de trafic : Les générateurs de trafic sont principalement utilisés pour calculer la
bande passante entre deux points et repérer des éventuels goulots d’étranglement. Ces outils
peuvent cependant être utilisés aussi pour « stresser » régulièrement le réseau et observer des
comportements anormaux. Les outils les plus employés sont iperf (fonctionnement client/serveur)
et pchar (client sans nécessité de serveur).
6.2 – Résoudre les problèmes de performance
Lorsqu’un problème de performance est signalé, L’ASR doit récupérer un ensemble de paramètres
décrivant le problème et le contexte (cf. §3). Une fois que cela est fait, en fonction des premiers
éléments, l’ASR dispose d’une palette d’outils pour tenter de résoudre le problème.
Pour certains problèmes de performance, l’analyse des mesures passives telles que les graphes
SNMP ou NetFlow peut permettre de déceler une anomalie (courbes CPU irrégulières, pics de trafic,
saturation d’un lien, etc).
Une analyse plus poussée consiste à capturer et analyser le trafic. Afin de capturer le trafic, la
méthode la plus utilisée est la réplication des ports d’un commutateur vers un port d’administration
(mirroring). Ensuite, l’analyse des paquets peut se faire grâce aux outils TCPdump (en ligne de
commandes) ou Wireshark (interface graphique), outils qui sont très utiles.
Les mesures actives sont cependant généralement plus utilisées pour résoudre les problèmes de
performance.
• Ping, traceroute : Le ping applicatif ou traceroute seront également utiles dans cette phase de
résolution de problème. Ils ne seront pas couplés avec des scripts ou des plateformes de
supervision car il s’agit ici de résoudre un problème bien ciblé. L’ASR pourra vérifier par exemple
si le temps de réponse de l’application est convenable. Il faut toutefois se souvenir que les
résultats de la commande Ping peuvent être influencés par la charge CPU de l’équipement
‘pingué’, et ne pas les prendre comme une mesure définitive du temps de réponse du
réseau traversé.
• telnet : Un autre moyen plus basique mais très pratique pour vérifier si l’application répond est
d’utiliser la commande telnet sur le port applicatif souhaité (>telnet machine n°de port). Cette
méthode est souvent utilisée car le client telnet se trouve pratiquement sur tous les ordinateurs.
Par exemple pour vérifier si le serveur web toto.test.fr est disponible, il suffira de taper :
• telnet toto.test.fr 80
• iperf, pchar : L’utilisation de iperf ou de pchar est très utile pour déterminer la bande passante
disponible sur un chemin et éventuellement le goulot d’étranglement sur le chemin. L’utilisation
d’iperf est plus complète que celle de pchar mais nécessite la présence d’un serveur (pour
acquitter les paquets envoyés par le client). D’autant plus que le serveur iperf n’est vraiment
efficace que s’il se trouve proche de la machine impactée (car les problèmes se trouvent souvent
sur le dernier segment réseau et non pas en coeur de réseau). Les tests UDP permettront de
vérifier s’il y a un point de congestion sur le chemin de bout en bout. Les tests TCP eux
permettront de se rapprocher du comportement applicatif (étant donné que les applications sont
basées sur TCP) et de déceler un problème de configuration des piles TCP (cf. 4.1).
7 - Conclusion
L’ASR doit procéder avec méthodologie pour résoudre un problème de performance. Comme le décrit
ce document, un nombre important de facteurs peuvent entraîner une dégradation de service. Il est
donc important de procéder par étapes.
Tout d’abord, l’ASR doit collecter les informations concernant les extrémités impactées. L’utilisateur
joue alors un rôle essentiel.
Les étapes principales dans cette résolution sont :
• L’évaluation du temps de réponse applicatif (ping). On vérifie avec cette première étape que le
service est bien disponible.
• La détermination du chemin emprunté (traceroute). Cette étape permet de déceler des problèmes
de routage. L’ASR doit avoir une bonne connaissance des réseaux traversés.
• Une fois que le chemin est bien connu, l’ASR peut évaluer s’il s’agit d’un problème de congestion
sur un point du réseau (iperf en UDP) et en fonction de la topologie réseau trouver la cause de
cette congestion (lien saturé, boîtier intermédiaire, etc)
• Enfin l’ASR peut utiliser iperf en mode TCP pour déterminer s’il s’agit d’un problème de
performances lié à la configuration des piles TCP des extrémités et éventuellement modifier les
paramètres de ces piles TCP.
Glossaire:
ASR: Administrateur Système et Réseau
BDP: Bandwidth Delay Product
CPU: Central Process Unit
IETF: Internet Engineering Task Force
LAN: Local Area Network
LFN: Long Fat Network
MOS: Mean Opinion Score
MTU: Maximum Transfert Unit
NAT: Network Address Translation
OWD: One Way Delay
POS: Packet Over Sonet/SDH
RFC: Request For Comments
RRD: Round Robin Database
RTP: Real Time Protocol
RTT: Round Trip Time
SACK: Selective Acknowledge
SNMP: Simple Network Management Protocol
TCP: Transmission Control Protocol
UDP: User Datagram Protocol
VLAN: Virtual LAN
VPN: Virtual Private Network
References:
Guide pour configuration de pile TCP: http://www-didc.lbl.gov/TCP-tuning/linux.html
PERT Guide : http://wiki.geant2.net