Quelques différentes causes de congestion réseau

Facebook Tweet Pin Email

Les congestions peuvent survenir sur un réseau de plusieurs façons. Elles peuvent aussi bien survenir à la suite d’une surcharge de trafic qu’à cause d’un équipement mal configuré ou encore un câble qui cesse de fonctionner. C’est pourquoi, on peut les regrouper en plusieurs catégories.

Les boucles de routage

Une boucle de routage se produit lorsqu’un paquet n’arrive plus à trouver sa destination. Elle va transiter à travers le réseau jusqu’à l’expiration de son TTL13 qui peut aller de 1 à 255. A un certain moment, il y aura beaucoup trop de paquets ne trouvant pas de route de destination et une congestion peut survenir. Une boucle de routage peut se produire lorsque le réseau n’est pas convergé, lorsqu’un équipement tombe en panne, lorsqu’un câble est mal branché, etc. Il existe plusieurs techniques pour pallier aux boucles de routage comme par exemple la route poisoning qui va, lorsqu’une route tombe, avertir le réseau d’une métrique de distance infinie. Ainsi, les paquets seront directement abandonnés.

Une boucle de routage peut également se produire sur la couche 2 lorsqu’il y a plusieurs chemins possibles entre deux équipements du réseau. La résolution de ces boucles se fait par l’implémentation du Spanning Tree Protocol14 sur les commutateurs concernés.

Les boucles de routage peuvent survenir suite à une mauvaise configuration de notre schéma réseau et seront donc détectables assez rapidement. Celles-ci peuvent aussi se produire lorsqu’un équipement tombe en panne (on débranche un câble accidentellement par exemple), les données ne sauront plus où transiter puisqu’elles ne trouvent plus leur chemin de destination.

Bande passante insuffisante

La bande passante est insuffisante, les données n’arrivent pas à joindre leur destination à temps, le réseau est saturé. Dans ce cas, c’est la façon la plus courante de déclencher une congestion. On fait appel à plus de ressources que notre réseau peut en fournir, ce qui provoque le ralentissement de celui-ci. Il n’y a pas de solution miracle à ce problème, on peut augmenter la bande passante, mais, cela coûte de l’argent. L’autre solution est simplement de réduire sa consommation de trafic en diminuant sa vitesse de téléchargement par exemple. S’il y a plusieurs utilisateurs sur le même réseau local, il faudrait gérer la bande passante de la meilleure façon possible pour que chaque personne puisse en bénéficier au mieux.

Les collisions

On appelle généralement un domaine de collision une partie du réseau ou les données transmises peuvent entrer en collision. Les informations qui transitent proviennent d’hôtes différents, mais, font partie du même réseau. Si les données entrent en collision elles deviennent inutilisables, il faut alors les retransmettre. Pour pallier à ce problème, on va segmenter au maximum les domaines de collision de notre réseau grâce aux routeurs, commutateurs ou bridge. Ceci permettra d’une part l’isolement du trafic entre les différents domaines de collisions, d’autre part d’offrir une bande passante réservée à chaque segment du réseau. On peut également, utiliser le mode full-duplex (permet de transporter les paquets simultanément dans les deux sens) qui empêche les collisions de se produire s’il n’y a que deux équipements dans le domaine de collisions.

L’exemple typique pour illustrer ce problème est l’utilisation du talkie-walkie où deux personnes ne peuvent pas parler en même temps car le signal se brouille (il y a des collisions, on est en bidirectionnel alterné). A l’inverse, avec un téléphone, deux personnes peuvent parler simultanément (il n’y a pas de collisions, on est en bidirectionnel simultané).

Mauvaise gestion des MTU

Maximum transmission unit (MTU) est la taille maximale d’un paquet pouvant être transmis en une seule fois (sans fragmentation) sur une interface. (Source Wikipédia https://fr.wikipedia.org/wiki/Maximum_transmission_unit)

Lorsque deux entités vont communiquer, par exemple un client et un serveur, on peut utiliser ce qu’on appelle le Path MTU discovery qui est une technique permettant de déterminer le bon MTU entre deux hôtes IP. Cette technique fonctionne en définissant un bit DF (Dont’t Fragment) dans les paquets sortants. Chaque équipement ayant un MTU plus petit qu’un paquet reçu va alors l’abandonner et envoyer un message d’erreur de type ICMP (Internet Control Message Protocol) spécifiant que le paquet est trop grand. L’émetteur va alors retransmettre avec un MTU plus petit jusqu’à qu’il soit capable de traverser l’hôte en question sans avoir à fragmenter le paquet. Si on ne définit pas de bit DF, les paquets trop gros pourront alors être fragmentés avant d’être envoyés. Cette technique n’est pas optimale car les paquets fragmentés seront alors plus nombreux, ce que va augmenter le nombre de bytes transmis. De plus, les paquets fragmentés peuvent potentiellement arriver à destination dans le désordre.

Le problème qui survient est que de nombreux équipements bloquent par défaut (entièrement ou partiellement) le trafic ICMP ce qui peut empêcher les redimensionnements du MTU de se produire. Si les messages ICMP sont bloqués, l’émetteur va continuellement envoyer des paquets trop gros et ils seront jetés. L’émetteur ne sera pas notifié des messages d’erreurs suit au blocage d’ICMP. Les décisions relatives à ICMP peuvent être également prises par des administrateurs, il faut donc être conscient du problème des MTU afin d’éviter une congestion réseau de se produire.

Table des matières

1. Introduction
2. La problématique de la congestion réseau
2.1 Les conséquences de la congestion réseau
2.2 Où se produit la congestion réseau
2.2.1 La couche transport
2.2.2 La couche réseau
2.2.3 La couche liaison de données
2.3 Eviter la congestion réseau
2.3.1 Le buffer (mémoire tampon)
2.3.2 Augmenter le débit
2.3.3 Bande passante variable
2.3.4 Bande passante asymétrique
2.3.5 Priorisation du trafic
2.3.6 La qualité de service (Quality of Service, QoS)
2.3.7 L’approche Flow control
2.4 Quelques différentes causes de congestion réseau
2.4.1 Les boucles de routage
2.4.2 Bande passante insuffisante
2.4.3 Les collisions
2.4.4 Mauvaise gestion des MTU
3. La détection de la congestion réseau 1
3.1 Les générateurs de trafic
3.1.1 Iperf
3.1.2 IP SLA
3.2 Les différents outils qui permettent de détecter la congestion
3.2.1 Le protocole SNMP
3.2.1.1 Caractéristiques et fonctionnement de SNMP
3.2.1.2 Fonctionnement détaillé de SNMP
3.2.1.3 La trappe SNMP (SNMP trap)
3.2.1.3.1 Le message inform
3.2.1.4 L’interface web Cacti
3.2.2 NetFlow
3.2.2.1 NfSen et NfDump
3.2.3 Le protocole Syslog
3.2.3.1 Configuration de Syslog
3.2.4 La méthode Storm control
3.2.4.1 Fonctionnement détaillé de Storm control
3.3 Sélection des outils les plus pertinents
4. Transmission, alerte de la congestion
4.1 Alerter avec Nfsen
4.1.1.1 Anomalie détectée avec les alertes Nfsen
4.1.2 L’envoi d’email avec Postfix
4.2 Alerter avec Syslog
4.3 Alerter avec prudence
5. Partie pratique, les schémas prototypes
5.1 Matériel utilisé
5.1.1 Les routeurs
5.1.1.1 Compatibilité
5.1.2 Les commutateurs (switch)
5.1.2.1 Compatibilité
5.1.3 Les ordinateurs et les serveurs
5.1.4 Le câblage
5.2 Configuration
5.3 Schéma n°1, chaine de deux routeurs avec lien série
5.3.1 Caractéristiques du schéma
5.4 Schéma n°2, chaine de trois commutateurs
5.4.1 Caractéristiques du schéma
5.5 Schéma n°3, chaine de deux routeurs avec câble coaxial
5.5.1 Caractéristiques du schéma
6. Phase de test
6.1 Schémas n°1, routeurs avec lien série, phases de test
6.1.1 Test n°1, schéma n°1, simulation d’une longue congestion
6.1.1.1 Trafic avec une boucle de routage
6.1.1.2 Simulation de la congestion avec du trafic TCP sur Iperf3
6.1.1.3 Simulation de la congestion avec du trafic UDP sur Iperf2
6.1.1.4 Mise en place et déclenchement des alertes sur Nfsen
6.1.1.5 Test TCP et UDP, déterminer le coupable avec Cacti et Nfsen
6.1.1.6 Test TCP et UDP, observation du trafic supplémentaire généré
6.1.1.7 Consultation du serveur Syslog
6.1.1.8 Conclusion du test n°1
6.1.2 Test n°2, schéma n°1, simulation d’un pic de trafic passager UDP
6.1.2.1 Simulation de la congestion avec du trafic UDP sur Iperf3
6.1.2.2 Mise en place et déclenchement des alertes sur Nfsen
6.1.2.3 Déterminer le coupable avec Cacti et Nfsen
6.1.2.4 Consultation du serveur Syslog
6.1.2.5 Conclusion du test n°2
6.2 Schémas n°2, suite de switch, phases de test
6.2.1 Test n°3, schéma n°2, simulation d’une longue congestion sans Storm
control
6.2.1.1 Simulation de la congestion avec du trafic TCP sur Iperf3
6.2.1.2 Trafic supplémentaire
6.2.1.3 Mise en place et déclenchement des alertes sur Nfsen
6.2.1.4 Déterminer le coupable avec Cacti et Nfsen
6.2.1.5 Consultation du serveur Syslog
6.2.1.6 Conclusion du test n°3
6.2.2 Test n°4, schéma n°2, simulation d’une longue congestion avec Storm
control qui va bloquer le port
6.2.2.1 Simulation de la congestion avec du trafic UDP sur Iperf2
6.2.2.2 Trafic supplémentaire avec Iperf version 2
6.2.2.3 Consultation du serveur Syslog
6.2.2.4 Mise en place et déclenchement des alertes sur Nfsen
6.2.2.5 Déterminer le coupable avec Cacti et Nfsen
6.2.2.6 Conclusion du test n°4
6.2.3 Test n°5, schéma n°2, simulation d’une longue congestion avec Storm
control qui va mettre en shutdown le port
6.2.3.1 Nouvelle configuration du switch
6.2.3.2 Simulation de la congestion avec du trafic TCP sur Iperf3
6.2.3.3 Trafic supplémentaire avec Iperf version 2
6.2.3.4 Consultation du serveur Syslog
6.2.3.5 Mise en place et déclenchement des alertes sur Nfsen
6.2.3.6 Déterminer le coupable avec Cacti et Nfsen
6.2.3.7 Conclusion du test n°5
6.3 Schémas n°3, routeurs avec câble coaxial, phases de test
6.3.1 Test n°6, schéma n°3, simulation d’une longue congestion
6.3.1.1 Simulation de la congestion avec du trafic TCP sur Iperf3
6.3.1.2 Simulation de la congestion avec du trafic UDP sur Iperf2
6.3.1.3 Consultation du serveur Syslog
6.3.1.4 Mise en place et déclenchement des alertes sur Nfsen
6.3.1.5 Test TCP, déterminer le coupable avec Cacti et Nfsen
6.3.1.6 Test UDP, déterminer le coupable avec Cacti et Nfsen
6.3.1.7 Conclusion du test n°6
6.3.2 Test n°7, schéma n°3, simulation de deux longue congestion parallèle
6.3.2.1 Simulation de la congestion avec Iperf2 entre le client et le serveur
6.3.2.2 Simulation de la congestion avec Iperf3 entre les deux PCs cisco-td-xx
6.3.2.3 Consultation du serveur Syslog
6.3.2.4 Mise en place et déclenchement des alertes sur Nfsen
6.3.2.5 Test UDP, Déterminer le coupable avec Cacti et Nfsen
6.3.2.6 Conclusion du test n°7
6.4 Conclusion des phases de test
7. Conclusion