Comment diagnostiquez-vous la perte de paquets?

Je me rends compte que cela est très subjectif et dépend d'un certain nombre de variables, mais je me demande quelles étapes la plupart des gens passent lorsqu'ils ont besoin de diagnostiquer la perte de paquets sur un système donné?

Je suis ingénieur réseau, je vais donc décrire cela de mon point de vue.

Pour moi, le diagnostic de la perte de paquets commence généralement par "ça ne marche pas très bien". À partir de là, j'essaie généralement de trouver le kit le plus près possible des deux extrémités de la communication (généralement un poste de travail dans un bureau et un serveur quelque part) et de cingler le plus près possible de l'autre extrémité (idéalement, le "point final distant", mais parfois il y a des pare-feu que je ne peux pas envoyer de pings, donc je devrai me contenter d'une interface LAN sur un routeur) et voir si je peux voir une perte.

Si je peux voir une perte, c'est généralement un cas de «bande passante insuffisante» ou de «lien avec des problèmes» quelque part entre les deux, alors trouvez l'itinéraire à travers le réseau et commencez par le milieu, ce qui vous donne généralement une extrémité ou l'autre.

Si je ne vois pas de perte, les deux étapes suivantes ont tendance à être "envoyer plus de pings" ou "envoyer de plus grands pings". Si cela ne donne pas une indication du problème, il est temps de commencer à regarder les politiques de QoS et les statistiques d'interface à travers tout le chemin entre les points de terminaison.

Si cela ne trouve rien, il est temps de commencer à remettre en question vos hypothèses, souffrez-vous réellement d'une perte de paquets? La seule façon sûre de le trouver est de faire des captures simultanées aux deux extrémités, soit en utilisant WireShark (ou équivalent) sur les hôtes, soit en connectant des renifleurs (probablement en utilisant WireShark ou similaire) via des taps réseau. Vient ensuite le plaisir de comparer les deux captures de paquets ...

Parfois, ce qui est attribué à la "perte de paquets" est simplement quelque chose du côté serveur qui est sensiblement plus lent (comme, par exemple, déplacer la base de données de "sur le même LAN" à "20 ms" et utiliser des requêtes qui nécessitent énormément de aller-retour entre le front-end et la base de données).

Du point de vue d'un système Linux, je vais d'abord rechercher la perte de paquets sur l'interface réseau avec ethtool -S ethX.

La plupart du temps, l'augmentation du tampon en anneau avec ethtool -G ethX rx VALUErésout ce problème.

Parfois, les interruptions ne s'équilibrent pas car le système manque le service irqbalance, alors regardez dans chkconfig(EL) ou update-rc(Debuntu) pour voir si ce service est en cours d'exécution. Vous pouvez savoir si les interruptions ne s'équilibrent pas car /proc/interruptsseul le Core 0 desservira tous les canaux IRQ.

À défaut, vous devrez peut-être augmenter net.core.netdev_max_backlogsi le système passe plus de quelques gigabits de trafic, et peut-être net.core.netdev_budget.

Si cela ne fonctionne pas, vous pouvez modifier les valeurs de coalescence d'interruption avec ethtool -C.

S'il n'y a pas de pertes de paquets sur l'interface réseau, regardez netstat -set voyez s'il y a des pertes dans les tampons de socket, ceux-ci seront signalés avec des statistiques comme " pruned from receive queue" et " dropped from out-of-order queue".

Vous pouvez essayer d'augmenter les tampons de socket par défaut et max pour le protocole approprié (par exemple: net.ipv4.tcp_rmempour TCP).

Si l'application définit sa propre taille de tampon de socket, l'application peut nécessiter des modifications de configuration. Si votre application a des tailles de mémoire tampon de socket codées en dur, contactez votre fournisseur d'application.

Personnellement, je n'aime pas le déchargement de protocole sur les cartes réseau (somme de contrôle, déchargement de segmentation, grand déchargement de réception) car il semble causer plus de problèmes qu'il n'en vaut la peine. Jouer avec ces paramètres en utilisant ethtool -Kpeut valoir la peine.

Regardez les options du module pour votre NIC ( modinfo <drivername>) car vous devrez peut-être modifier certaines fonctionnalités. Pour donner un exemple que j'ai rencontré, l'utilisation d'Intel Flow Director sur un système qui gère un gros flux TCP nuira probablement à l'efficacité de ce flux, donc désactivez FDir.

Au-delà de cela, vous êtes en train de régler manuellement ce système spécifique pour sa charge de travail spécifique, ce qui, je suppose, dépasse la portée de votre question.

Je vais commencer par utiliser l'outil de capture de paquets tel que: wireShark (sous Windows) et tcpdump (sur le terminal Linux).

Je vérifierai également la configuration du pare-feu (pare-feu hôte ainsi que pare-feu réseau).

Isolez, puis éliminez.

Trouvez le plus petit sous-ensemble de chemins avec le problème. Pour ce faire, testez différentes combinaisons et / ou distillez les rapports des utilisateurs. N'oubliez pas de prendre en compte le temps dans l'équasion. Peut-être que c'est seulement la perte de paquets sur tout le trafic vers un réseau spécifique, ou peut-être que seuls les clients sans fil souffrent. Prendre en compte différents types de trafic (limite de taux sur les pings). Trouvez le moyen le plus fiable et facilement reproductible de le tester.

Éliminez ensuite les causes potentielles. Réduisez le trafic sur les liaisons (temporairement), supprimez les sources d'interférence du spectre, déconnectez certains clients. Finalement, vous trouverez la source du problème.

Vous pouvez parfois prendre des raccourcis en regardant les vidages de paquets ou en deviner (c'est toujours bittorrent). De plus, dites à votre professeur que le défaut de serveur est génial.

Les pings peuvent ne pas afficher de perte de paquets à moins que vous n'envoyiez de grands pings! J'ai eu une perte de paquets sur mon réseau qui était invisible jusqu'à ce que j'augmente la taille de mon paquet ping.

Pour les fenêtres:

ping -n 30 -l <largevalue> <target>

Car largevaluej'ai utilisé 40960 (paquet de 40k)

Car targetj'ai utilisé les premières adresses IP detracert google.com

(qui était mes routeurs et modem câble). L'un des appareils plus bas dans la chaîne a enregistré une perte de paquets terrible (> 60%) pour les gros paquets mais 0% pour les petits. Je l'ai corrigé en le redémarrant, mais il peut également s'agir d'un câble ou d'un élément interne qui doit être remplacé.