Environ 15 % de perte de paquets à travers un SFP+ cuivre S+RJ10 sur un CRS518-16XS-2XQ alors que le chemin direct 100G est propre
On envoie du trafic depuis un serveur de labo vers un CRS518-16XS-2XQ via un uplink 100G QSFP28, et ça sort du switch via un SFP+ cuivre MikroTik S+RJ10 vers un simple hôte 1G RJ45. Le côté récepteur manque une grande part des paquets et je n'arrive à l'imputer à rien d'évident.
Configuration :
- MikroTik CRS518-16XS-2XQ, uplink 100G QSFP28 depuis la source de trafic
- SFP+ cuivre MikroTik S+RJ10 dans l'une des cages, appareil 1G RJ45 à l'autre bout
- capture en cours sur l'hôte récepteur
Ce que dit la capture :
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Essayé jusqu'ici :
- connecté la même source directement en 100G, aucune perte du tout, donc l'émetteur lui-même va bien
- fait baisser le CPU du switch, il est maintenant à 1 % pendant que la perte se produit toujours
- réinséré le S+RJ10 et échangé le cordon de brassage vers l'appareil 1G
Le module cuivre est mon principal suspect à ce stade, mais le lien est propre et l'interface ne montre aucune erreur du tout. Le S+RJ10 est-il connu pour avaler du trafic comme ça, ou devrais-je regarder ailleurs dans le switch ?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
400-500 Mbps de moyenne avec un émetteur en rafales, c'est toute l'histoire. Votre trafic n'est pas réparti uniformément : de courtes rafales quittent la source plus vite que 1 Gbps, et tout ce qui dépasse cette ligne doit rester dans le buffer de sortie du port jusqu'à ce que le côté 1G l'écoule. Quand le buffer est plein, le switch jette. C'est exactement ce que vous dit le mouvement de rx-overflow, et c'est pourquoi la connexion directe 100G ne montre rien - il n'y a pas de palier de vitesse là-bas contre lequel tamponner.
Le transceiver est innocent. N'importe quoi dans cette cage, cuivre ou fibre, se comporterait pareil, parce que la perte se produit sur le palier 100G vers 1G et pas à l'intérieur du module.
Deux choses à faire. La vraie correction est côté émetteur : cadencez-le pour que les paquets soient répartis uniformément au lieu d'être écrits en rafales. Une fois que la source arrête de produire des rafales au-dessus du débit de sortie, la perte disparaît.
Sur le switch, vous pouvez rendre la situation du buffer moins hostile :
Ça achète de la marge et permet à une rafale de tenir plus longtemps, mais ça ne supprime pas la cause - si l'émetteur envoie une rafale assez forte assez longtemps, aucune taille de buffer ne vous sauvera. Continuez à surveiller les statistiques QoS du switch et les compteurs rx-overflow après le changement, pour voir si vous touchez encore le plafond ou seulement occasionnellement.
La leçon générale vaut la peine d'être retenue : un port avec un lien propre, sans erreurs et un module sain peut quand même laisser tomber une part à deux chiffres du trafic uniquement à cause d'un palier de vitesse entre ports.
Avant de blâmer le module, regardez ce que disent réellement les compteurs de port. Lancez
sur le port d'entrée 100G et sur la cage contenant le S+RJ10, et allez chercher spécifiquement la ligne rx-overflow plutôt que les compteurs d'erreurs rx/tx habituels. Un SFP+ cuivre réellement cassé s'annonce par des erreurs FCS ou un lien qui flappe, pas par une coupe nette de 15 % sur un flux par ailleurs sain.
Deuxième question : quel est le débit moyen sur ce chemin, et avez-vous une idée des pics ? Perdre un paquet sur sept avec un CPU à 1 % sent bien plus le port de sortie à court de buffer qu'un défaut de transceiver.
Les compteurs d'abord : aucune erreur sur aucun des deux ports, le lien reste up tout du long et le module ne rapporte rien d'inhabituel. rx-overflow est le seul endroit où les chiffres bougent.
Côté débit, le chemin fait en moyenne 400-500 Mbps, donc sur le papier ça n'approche pas de saturer le côté 1G. Je n'ai pas de mesure de pic, mais le trafic est en rafales par nature - l'émetteur écrit un bloc puis se tait un moment. Le CPU est toujours à 1 % pendant que des paquets disparaissent.
Panne différente, même leçon sur le fait de faire confiance aux compteurs plutôt qu'à l'intuition. J'avais un CRS354-48G-4S+2Q+RM sous SwOS 2.18 avec des Rx FCS Errors qui augmentaient régulièrement sur les deux ports QSFP+, et des Rx MAC Errors à un rythme plus faible. Les deux ports étaient à 40G full duplex avec MTU 1500, et de l'autre côté il y avait des hôtes ESXi avec des cartes Mellanox ConnectX-3 Pro CX324A.
La partie intéressante : le côté carte réseau ne rapportait absolument rien.
Propre. Des câbles connus bons n'ont rien changé, et les ports SFP+ 10G du même boîtier sont restés sans erreur tout du long. Je n'ai jamais eu de vrai diagnostic - faire passer le switch de SwOS à RouterOS a fait disparaître les compteurs, ce que je considère comme cacher le problème plutôt que le résoudre.
La méthode qui a survécu : réinitialisez les compteurs, relisez-les sur un intervalle fixe et voyez si les erreurs suivent le volume de trafic. Dans votre cas elles suivront les rafales, dans le mien elles ne suivaient rien d'utile, et cette seule différence vous dit de quel côté continuer à creuser.
Une chose à garder en tête pendant que vous expérimentez sur ce port : n'allez pas chercher la vitesse et le duplex forcés comme solution. Le comportement documenté des modules cuivre MikroTik, S-RJ01 comme S+RJ10, est qu'ils ne fonctionnent qu'avec l'auto-négociation activée - fixez le débit statiquement et le lien ne monte pas du tout. La pratique contredit partiellement ça, puisque quelques propriétaires de RB5009 et RB4011 rapportent le contraire et n'ont stabilisé un S-RJ01 qu'en forçant le 1G full duplex, donc c'est plutôt du « essayez les deux sur votre propre matériel » qu'une règle. Dans tous les cas, c'est un détour par rapport à votre vrai problème, qui est du côté du buffer.
L'autre détail sur le S+RJ10 bon à connaître pour plus tard : il tire nettement plus de courant qu'une optique normale et chauffe, donc il n'est pas recommandé dans un appareil à refroidissement passif sans flux d'air supplémentaire. Si ce module se met un jour à mal se comporter dans un châssis chaud, la température est la première chose que je vérifierais.