Vous constatez des pertes de paquets entre deux sites et vous soupçonnez la liaison MPLS de l’opérateur qui les interconnecte ? le service support de l’opérateur ne veut rien entendre sans preuve ?
Dans cet article, je partage avec vous mon approche pour détecter les pertes de paquets à l’aide du logiciel Wireshark.
À chaque fois je fais face à ce type des problèmes, je demande à la limite du possible une capture dans les deux extrémités de la liaison en question.
Dans notre démonstration, on va utiliser deux traces Wireshark récupérées lors du test de la liaison à l’aide du logiciel iPerf.
L’architecture de références est illustrée ci-dessous :
Dans cette architecture, PC B (Client iPerf) génère du trafic TCP à destination du PC A ( Serveur iPerf). Pour vérifier cette information, il faut tout simplement regarder le champ length (taille de la trame) de la trace Wireshark pour constater que PC B génère des trames à 1514 Octets (Data {1460} + TCP{20} + IP{20} + Ethernet{14}) et PC A acquitte la réception de ces trames en répondant avec des trames à 54 Octets.
À chaque fois je reçois une trace Wireshark, je clique sur le bouton « Info Expert » qui se trouve en bas à gauche de la trace car il me permet de se faire une idée claire ou un résumé de ce que le logiciel a pu constater dans la trace.
Dans notre trace, je vois clairement qu’il y a énormément de Duplicate ACK et des retransmissions de paquets, ce qui représente un véritable indice d’une hémorragie de paquets quelque part dans le chemin.
Maintenant comment montrer qu’il y a des pertes de paquets à votre interlocuteur ?
Il existe au moins deux méthodes :
- La première consiste en une maitrise et une connaissance avancée de la couche 4, par exemple comment le protocole TCP utilise le principe de séquencement des paquets et suivre ses séquences afin de trouver les paquets perdus. Ce mode, je l’utilise quand je suis en face d’une audience purement technique.
- La deuxième se base sur le champ identification de la couche IP. Je fais appel à cette méthode quand je dois montrer les pertes de paquets à une audience moins technique.
À quoi sert le champ identification de la couche IP ?
Le champ identification (16 bits ) était conçu principalement pour permettre à une machine d’identifier et rassembler l’ensemble des fragments d’un paquet initialement fragmenté par la source. C’est un identifiant unique associé à chaque paquet émis.
Dans une communication IP, quand la fragmentation des paquets est nécessaire, la machine source tâche à associer le même id à l’ensemble des fragments pour permettre à la machine de destination de rassembler les fragments ayant le même id avant de les envoyer à la couche supérieure.
Mais ce champ peut servir également à :
- Identifier les boucles réseaux : Par défaut la valeur de l’identification s’incrémente par 1, apercevant le même id dans la même communication signifie qu’on a reçu le paquet en double et donc la présence d’une éventuelle boucle réseau.
- Avoir une idée sur la charge de travail de la machine émettrice : comme j’ai expliqué ci-dessus l’IP.id s’incrémente par un, voyant des paquets avec des id consécutives vers la même destination signifie simplement que la machine communique exclusivement avec cette destination. En revanche s’il y un gap important de la valeur de l’id entre deux paquets vers la même destination, cela explique que la machine communique avec plusieurs destinations en même temps.
- À suivre facilement les paquets perdues dans une communication en comparants les paquets capturés dans deux points de captures différents.
Retournant à nos deux captures Wireshark entre PC A et PC B
Dans la trace de gauche (Celle capturée par le PC B), je vois bien que ce dernier a envoyé des paquets vers le PC A et l’ IP.id s’incrémente par 1, c’est-à-dire que le PC B ne communique qu’au PC A.
En revanche, dans la trace de droite prise directement sur le PC A, Wireshark me remonte qu’il n’a pas capturé des segments précédents sans spécifier leurs nombres mais grâce au champ identification je sais que j’ai reçu le paquet avec l’id 10534 puis celui de 10538 mais pas les 10535-10537. Pourtant le PC B a bel et bien envoyé ses trois paquets. Conclusion ces paquets sont envoyés par PC B mais ils n’ont jamais été reçus par le PC A ‘disparus lors de leur transit dans l’infrastructure opérateur’.
La balle est envoyée chez l’opérateur pour investiguer le problème.
Dans cet article on a vu ensemble comment peut-on exploiter le IP.id pour démonter qu’il y ait eu des pertes de paquets chez l’opérateur à une audience moins technique et puis clôturer le ticket (Like a BOSS).
Si vous avez des questions, un autre avis sur le sujet ou vous avez besoin d’un complément d’informations, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.
Anas
février 21, 2021Très intéressant, Merci Driss