5 votes

Dépannage d'un taux de retransmission TCP élevé

J'ai essayé de résoudre un problème de réseau qui présente un taux très élevé de retransmissions TCP. 36 échantillons (pris avec Wireshark 1.10.8 fonctionnant sous Windows 7 32 bits) totalisant un peu plus de sept heures, entre 2 et 53 minutes chacun, montrent que les retransmissions occupent entre 43 et 61 % de la bande passante totale d'entrée.

Ce qui m'embrouille, c'est que, pour autant que je sache, il n'y a que deux raisons pour ce genre de problème : une liaison instable qui laisse tomber des paquets, et la congestion. Je pense avoir exclu ces deux causes. Permettez-moi d'exposer notre situation et j'aimerais que des personnes plus compétentes que moi me fassent part d'autres pistes de recherche pour résoudre le problème.

Le réseau en question se trouve à bord d'un navire en mer. Il utilise une liaison satellite pour communiquer avec l'Internet. Malheureusement, les coûts de la bande passante pour ce type de liaison sont prodigieux, nous sommes donc coincés avec une connexion de 1Mbps descendant / 512kbps montant. Comme il s'agit d'une liaison par satellite, le temps de ping est d'environ 650 ms. En ce moment, nous avons environ 300 personnes à bord, qui partagent toutes ce tuyau.

Le réseau se compose de deux VLAN (un pour les ordinateurs du navire, l'autre pour les invités). Les deux VLAN sont acheminés vers un SonicWall TZ 215 (exécutant SonicOS Enhanced 5.8.1.2-6o) qui contrôle le tuyau vers Internet. Les deux VLAN ont des clients câblés et sans fil. Le réseau câblé est géré par une série de commutateurs gigabit Cisco 2900. Le réseau sans fil est fourni par de nombreux AP Cisco (la propagation du signal dans un navire en acier en mer est terrible).

J'ai d'abord pensé qu'il s'agissait d'un problème d'encombrement, et j'ai donc cherché diverses solutions (blocage des services à large bande passante comme le chat vidéo et le streaming, pressions sur le siège social pour qu'il paie un tuyau plus gros, etc.) Malheureusement, nous n'avons pas obtenu de tuyau plus gros. Les autres solutions ont aidé un peu, mais pas assez pour faire une réelle différence.

Mais ce week-end, j'ai été renvoyé à la case départ. Le capitaine m'a demandé de désactiver l'accès des invités à Internet pendant un exercice. J'ai profité de cette occasion pour faire une capture Wireshark du réseau lorsqu'il n'était pas congestionné. À ma grande surprise, cet échantillon de 10 minutes a montré que le taux de retransmission TCP était presque identique à toutes les autres captures - 58 %. Pendant la durée de l'échantillon, l'utilisation moyenne de la bande passante était de 98 kbps, donc c'était définitivement pas encombré.

Il ne reste donc que la perte de paquets comme cause probable. Pour tester cela, j'ai lancé 12 heures de pings. A la fin, le programme a rapporté moins de 1% de perte de paquets.

Ce qui laisse... quoi ? Je ne sais pas. Toute idée supplémentaire serait la bienvenue.

1voto

TomTom Points 50635

Vérifiez tout avant votre réseau. Comme dans : La liaison satellite est instable. Cela peut être n'importe quoi au niveau physique de ce côté - un mauvais calibrage, peu importe.

Selon l'approche de Sherlock Holmes, c'est la seule chose qui reste. Les paquets sont perdus parce qu'ils sont PERDUS.

1voto

Tom Points 11

Une bonne façon de détecter les pertes est d'utiliser un flux de paquets UDP (il existe plusieurs outils qui le font, principalement pour les tests de QoS). Vous pouvez faire varier la taille, la fréquence et le délai. Cela devrait vous montrer si vous avez une perte réelle.

1voto

MagicAndi Points 10128

Pour tester cela, j'ai effectué douze heures de pings. À la fin, le programme a signalé moins de 1% de perte de paquets.

Le Ping utilise des paquets ICMP, c'est-à-dire le protocole de messages de contrôle Internet. L'ICMP est destiné à assurer la fluidité du trafic (c'est-à-dire à indiquer à d'autres machines comment acheminer le trafic) afin que les appareils MUST donner la priorité à ICMP sur les autres types de paquets.

c'est-à-dire qu'il s'agit de la pire façon de détecter la congestion.

0voto

J'ai eu une expérience similaire avec sonic wall dans le passé, vérifiez que vous avez la même taille MTU pour les paquets. CISCO a une MTU de 1500 alors que sonicwall en a 1492, donc chaque paquet est cassé en deux... voyez : https://www.sonicwall.com/support/knowledge-base/set-mtu-in-vpn-environment-in-case-of-throughput-issues/170705131319789/

0voto

Dave Andrews Points 21

Soyez d'accord avec le test ping, définissez le bit DF et voyez où votre MTU plafonne. Le trafic est-il encapsulé ? J'imagine qu'il l'est par le biais du SAT, ce qui réduira encore plus ce problème. J'ai versé une larme quand j'ai lu le nombre d'utilisateurs pour 1Mbps la saturation de l'upload aura un impact supplémentaire. Je sais qu'il n'y a pas grand-chose à faire, mais avec la façon dont les pages sont conçues de nos jours, c'est une bataille perdue d'avance. Nous avons essayé de limiter un service public sans fil à 256kbps par client et l'expérience n'était pas utilisable, je ne peux même pas imaginer charger une page avec un modem 56k aujourd'hui, et le vôtre est concurrencé 15 à 1.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X