Incohérence de duplex sur un port de passerelle VPN : lisez les deux extrémités

Une copie de fichier à travers le tunnel se bloque une seconde, reprend, et les journaux du VPN n'affichent rien. L'application accuse le réseau, le réseau accuse l'application, et le port du commutateur est actif depuis onze mois. Cette analyse part de la pause et remonte vers la liaison physique : ce que fait réellement le port, ce que fait l'extrémité distante, et ce qu'ont fait les compteurs pendant que vous regardiez. Cela vaut la peine avant que quiconque touche à un réglage de duplex.

Partez de la pause, pas du port

Décrivez le symptôme d'une manière testable. Un blocage d'environ une seconde pendant un transfert massif est un problème différent d'une connexion qui se réinitialise, et une pause qui survient une fois par heure diffère de celle qui survient toutes les quelques secondes. Notez la charge, la direction et l'intervalle approximatif.

Reproduisez-le ensuite en observant l'interface. Un problème physique se manifeste par un mouvement des compteurs pendant la charge concernée, et un problème qui ne fait bouger aucun compteur se situe probablement au-dessus de la couche liaison. Observez une minute, pas une seconde, car ces défauts ont souvent besoin d'un trafic soutenu avant d'apparaître. La surveillance au repos ne prouve rien sur une liaison qui ne se comporte mal que sous charge.

Cela compte parce que les incohérences de duplex ont une signature : des erreurs qui n'apparaissent que sous charge, dans le sens du trafic, tandis que les petits pings et les sessions interactives restent parfaits. Si le trafic au repos échoue aussi, cherchez d'abord ailleurs.

Lisez le mode opérationnel aux deux extrémités

La configuration enregistrée n'est pas l'état opérationnel. Un port peut être configuré pour l'autonégociation et se retrouver en demi-duplex, ou être configuré sur une vitesse fixe que l'autre extrémité n'a jamais acceptée. Lisez ce que fait la liaison en ce moment des deux côtés.

ethtool eth0
ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0

Notez la vitesse, le duplex et si l'autonégociation est active, puis obtenez les mêmes trois faits sur le commutateur voisin ou le port de l'opérateur. Une seule extrémité ne dit rien, car l'incohérence est une relation et non un réglage. Placez les deux lignes côte à côte dans le ticket, avec l'heure à laquelle vous les avez relevées. La moitié de la valeur de l'exercice est d'avoir les deux relevés au même endroit.

Si vous ne pouvez pas lire l'extrémité distante, vous ne pouvez pas diagnostiquer ceci. Demandez au propriétaire le mode opérationnel et les compteurs, ou organisez un accès avant de commencer à modifier votre côté.

À quoi ressemble le cas 10/100 en demi-duplex

Sur les liaisons cuivre 10/100, une extrémité en autonégociation peut détecter la vitesse d'un pair forcé sans apprendre son réglage de duplex. La détection parallèle détermine la vitesse à partir du signal, et le duplex est supposé plutôt que négocié, si bien qu'un côté peut finir en demi-duplex pendant que l'autre fonctionne en duplex intégral.

Le guide d'autonégociation de Cisco explique ce cas précis. Ce n'est pas un argument pour désactiver la négociation partout, et il ne dit rien d'utile sur le cuivre gigabit, où le duplex est fixe et où l'autonégociation est nécessaire pour que la liaison se lève.

La preuve observable est un mélange d'erreurs qui n'existent que dans un sens : erreurs FCS ou CRC côté duplex intégral, collisions ou collisions tardives côté demi-duplex, et un débit qui s'effondre sous charge alors que la latence reste normale au repos. Cette asymétrie est la signature. Une liaison simplement sursouscrite se dégrade dans les deux sens et à tout moment.

Changez les deux extrémités ensemble, avec un chemin de retour

Une correction de duplex est un changement coordonné, pas local. Forcer votre côté sans l'accord de l'extrémité distante, c'est ainsi qu'une liaison qui fonctionne devient une liaison cassée, et le fait que la CLI accepte la commande prouve seulement que la syntaxe était valide.

sudo ethtool -s eth0 speed 100 duplex full autoneg off
ethtool eth0

Avant d'exécuter quoi que ce soit de ce genre, confirmez que la plateforme prend en charge la combinaison et que l'extrémité distante sera modifiée dans la même fenêtre. Conservez un moyen indépendant d'administrer l'équipement, car le port que vous êtes sur le point de changer peut être celui qui transporte votre session de gestion.

Sur de nombreuses liaisons modernes, la bonne réponse est de laisser l'autonégociation activée aux deux extrémités plutôt que de forcer quoi que ce soit. Forcer est un remède à une incohérence précise sur une technologie précise, pas une amélioration générale. Le cuivre gigabit en particulier a besoin de l'autonégociation pour que la liaison se lève, donc le conseil pour 10/100 ne se transpose pas.

Confirmez que les compteurs ont évolué dans le bon sens

Après le changement, relisez l'état opérationnel aux deux extrémités et confirmez qu'elles concordent. Exécutez ensuite la même charge qui a provoqué la pause et comparez les écarts des compteurs plutôt que les totaux depuis la mise en service, car un total qui s'accumule depuis un an ne peut pas vous dire ce qui s'est passé dans les dix dernières minutes.

ethtool -S eth0 | grep -iE 'error|drop|collision|fcs'
ip -s link show eth0
ping -f -c 200 10.90.0.1

Une liaison sans nouvelles erreurs sous la même charge est la preuve qui vous manquait. Une liaison qui erre encore, ou une liaison dont les compteurs n'ont jamais bougé, vous envoie vers la frontière suivante plutôt que plus loin dans le débat sur le duplex. Les deux issues sont un progrès, ce qui est plus que ce que le fichier de configuration peut vous offrir. Ne sautez pas la seconde lecture parce que la première semblait correcte.

Écrivez les chiffres avant et après dans le ticket avec des horodatages. C'est ce relevé qui transforme « le VPN va mieux » en quelque chose sur quoi l'ingénieur suivant peut construire.