Recherche de la cause de la retransmission TCP dans un LAN

25

Bonjour les habitants de Server Fault

J'ai un problème irritant avec un LAN d'environ 100 ordinateurs, 2 serveurs de domaine Windows et 12 téléphones VoIP. Depuis leur installation il y a environ un an, chaque semaine environ, nous remarquons qu'un téléphone VoIP se réinitialise - parfois au milieu d'un appel. Simultanément, il y a souvent des signes de perte temporaire de connexion sur les ordinateurs: blocage dans l'explorateur lors de l'accès aux partages réseau, erreurs dans notre logiciel d'administration en raison de la perte de connexion au serveur de base de données.

J'ai fait une surveillance Wireshark sur la connexion entre le PBX VoIP et le reste du réseau. Wireshark récupère un groupe de paquets TCP retransmis au moment où nous enregistrons les redémarrages du téléphone. Le journal Wireshark montre environ 2 clusters de retransmissions par jour allant de 5 paquets à des centaines. Ceux de chaque cluster se trouvent principalement entre le PBX et certains ensembles de téléphones VoIP, mais pas toujours le même ensemble. Souvent, les retransmissions se font en même temps vers des téléphones connectés au même commutateur, mais parfois les retransmissions se produisent ensemble vers des téléphones aux extrémités opposées du réseau. Il y a généralement des retransmissions coïncidentes lors du passage du trafic TCP, par exemple entre les ordinateurs clients et les serveurs de fichiers.

Les pics des retransmissions et des réinitialisations téléphoniques ne correspondent pas bien avec le moment où le réseau est lourdement chargé. Ils semblent se produire un peu plus pendant la journée, mais surtout le soir, lorsque le trafic devrait diminuer. Ils se produisent assez souvent tard dans la nuit, lorsque la plupart des ordinateurs sont éteints et que le trafic doit être le plus faible.

Avez-vous des idées qui pourraient aider à diagnostiquer la cause de problèmes comme celui-ci? Une chose que je n'ai pas encore essayée, mais que j'aurais dû, est la mise à jour du firmware de tous les commutateurs.

Surréaliste
la source
1
Quel modèle change? À quoi ressemblent les statistiques du processeur, de la mémoire, etc.? Êtes-vous sur un domaine de diffusion? à quel point le débit maximum voyez-vous sur le réseau?
Zypher
Quel protocole VoIP utilisez-vous? De plus, en utilisant UDP ou TCP?
Chris S
Tous les commutateurs sont 3Com: Baseline 2924 - PWR Plus (3CBLSG24PWR) x 2, 4200 (3C17304A) x 3, 4200 (3C17304) x 2, 2824-SPF Plus (3C16487), 2250 plus (3C16476CS). Je ne pense pas qu'ils donnent des statistiques sur le processeur ou la mémoire, mais je serais très heureux d'apprendre le contraire. Oui, nous sommes sur un seul domaine de diffusion. Je ne connais pas le débit, je vais chercher à le mesurer.
Surréaliste

Réponses:

17

Les retransmissions TCP sont généralement dues à la congestion du réseau. Recherchez un grand nombre de paquets de diffusion au moment où le problème se produit. Si le pourcentage de trafic diffusé dans votre capture est supérieur à environ 3% du trafic total capturé, vous avez certainement une congestion. Recherchez les diffusions de couche physique (ARP) et de couche réseau (résolution de noms) sur le réseau. Si vous trouvez un volume élevé de trafic de diffusion, vous pouvez le suivre jusqu'à la source à partir des données de capture.

joeqwerty
la source
9
De plus, les retransmissions TCP ne sont pas la cause de votre problème, elles sont un symptôme du problème.
joeqwerty
J'aurais dû mentionner que j'avais regardé les émissions de l'UDP et qu'elles n'étaient pas en corrélation avec les retransmissions. Quelques-uns des événements de retransmission coïncident avec des pics de diffusion UDP, mais la plupart ne le font pas. J'ai jeté un autre coup d'œil et j'ai découvert que les émissions UDP ne dépassent pas 1,5% du trafic (environ 350 paquets) dans un segment de temps de 10 minutes, et atteindre ce niveau est rare. Cependant, je n'avais pas regardé les émissions Ethernet. J'exécute un script maintenant pour filtrer tous mes journaux Wireshark. La règle de base de 3% pour les diffusions UDP et les diffusions Ethernet est-elle individuelle ou combinée?
Surréaliste
1
Le 3% n'est pas vraiment une règle de base. C'est ce qu'on m'a dit et ce que j'ai vu dans mon propre environnement. J'ai entendu des chiffres allant de 10 à 20%, mais j'ai constaté qu'une fois qu'il dépassait 3 à 5%, cela causait généralement des problèmes. Vous devez examiner tout le trafic de diffusion: les diffusions Ethernet, réseau et multidiffusion, car elles peuvent toutes provoquer une congestion. Fondamentalement, tout trafic diffusé vers tous les ports de commutation est un trafic qui doit être analysé et réduit ou éliminé.
joeqwerty
Je n'ai toujours pas un joli graphique ensemble pour vérifier une bonne corrélation sur une longue période, mais les émissions Ethernet semblent très prometteuses. Un journal où il y avait retransmission avait un peu plus de 3% d'émissions, un autre environ 6%. J'ai au moins trouvé un problème: un ancien serveur éteint un flux constant de paquets ARP gratuits.
Surréaliste
1
J'ai trouvé les entrées ARP excessives en utilisant le filtre Wireshark de arp- et pour voir celles diffusées uniquement, en utilisant un filtre deeth.addr==ff:ff:ff:ff:ff:ff
mlhDev
2

La collecte de statistiques de trafic pour vos commutateurs peut indiquer que vous avez des périodes où vous exécutez à pleine capacité ou presque. Cela peut conduire à de nouvelles tentatives lorsque les réponses ne reviennent pas dans le délai initial (souvent 3 secondes). Cela augmente momentanément la congestion jusqu'à ce que les mécanismes d'atténuation de la congestion se déclenchent.

Recherchez des personnes utilisant des médias en streaming car cela peut absorber rapidement la bande passante.

Vous pourrez peut-être atténuer le problème pour les téléphones en modulant le trafic. Cela ne fera que déplacer le problème vers d'autres utilisateurs.

BillThor
la source
2

Cela ressemble à une boucle de spanning tree ou à une tempête de diffusion pour moi, surtout si les retransmissions et les problèmes sont localisés sur le même commutateur (qui diffère). Lorsque cela se produit, quels sont les états de port sur votre appareil L2? Probablement un mauvais commutateur ou de mauvaises priorités de pont racine? Problème intéressant.

McJeff
la source
Merci de m'avoir incité à lire sur les arbres qui s'étendent, dont je suis gêné par l'ignorance. Cependant, je ne pense pas qu'il puisse s'agir d'une boucle d'arbre couvrant, car nous n'avons pas de liens redondants dans notre réseau (peut-être un problème en soi). Par "états de port sur votre périphérique L2", ai-je raison de dire quels ports les commutateurs ont activés en raison de l'algorithme de spanning tree? Nous n'avons pas configuré manuellement un pont racine, serait-ce une bonne idée de le faire?
Surréaliste
Se familiariser avec STP est une bonne idée, mais si vous êtes sûr de ne pas avoir de liens redondants, alors STP ne sera pas le problème.
joeqwerty
Ouais, si vous n'avez pas de liens redondants, ce ne serait pas un problème. Par États du port, oui, je veux dire ceux qui sont en avant / bloqués / d'apprentissage.
McJeff
2

Vous avez probablement résolu ce problème depuis si longtemps, mais vous devez essentiellement activer le «port rapide» sur les ports dotés de terminaux (téléphones VoIP, postes de travail, serveurs). Un téléphone peut envoyer des PDU, donc si ce type redémarre, une convergence STP se produira, ce qui entraînera le vidage de la table FDB et tous les appareils passeront par le plaisir STP en 4/5 étapes. En mettant les ports avec point d'extrémité en "port rapide", ils sautent l'attente et passent directement au mode de transfert.

barak s.
la source
1

Espérons que vos téléphones se trouvent sur un sous-réseau et un VLAN différents des autres ordinateurs?

Greg Askew
la source
Non, ils sont sur le même sous-réseau IP, et je suis à peu près sûr que le même VLAN aussi. Est-ce un grave problème? Cela semble certainement être une bonne idée. Je peux voir que cela séparerait les domaines de diffusion pour les téléphones et tout le reste. Aurait-il d'autres avantages?
Surréaliste
Oui, je mettrais certainement les téléphones sur un VLAN dédié.
Greg Askew
1

Il peut également s'agir d'un équipement défectueux comme un interrupteur défectueux. Les retransmissions correspondent-elles aux téléphones / ordinateurs sur un commutateur ou une partie du réseau particulier?

Juste pour étendre un peu ma réponse. Tous les commutateurs ne sont pas créés égaux, même s'ils ont les mêmes spécifications. Certains sont capables de faire face à une charge beaucoup plus élevée que d'autres car ils ont des processeurs plus rapides à l'intérieur. Il se peut que vos commutateurs ne soient pas tout à fait à la hauteur.

Je commencerais par placer certains de vos téléphones VOIP les plus gênants sur leur propre commutateur physique et voir si les réinitialisations de ceux-ci se poursuivent. Si cela disparaît, vous êtes sur le point de le résoudre très bientôt.

Mat
la source
Je souhaite qu'ils l'ont fait. Il semble y avoir le plus de problèmes avec les appareils connectés à deux commutateurs, qui sont aux extrémités opposées du réseau. Cependant, il existe également des retransmissions importantes vers les téléphones dans d'autres parties du réseau.
Surréaliste