Erreurs d'interface Ethernet

L'interface Ethernet de mes serveurs Ubuntu qui se connecte au multiplexeur du FAI affiche des erreurs. Voici l'instantané:

          RX packets:204564288 errors:3193970 dropped:0 overruns:0 frame:3138402
          TX packets:29305799 errors:38752 dropped:0 overruns:0 carrier:38762
          collisions:2205053 txqueuelen:1000

L'interface Ubuntu est capable de duplex intégral mais elle ne négocie qu'une connexion semi-duplex. Lorsque j'ai connecté un autre appareil (un routeur) à MUX, il a également montré de telles erreurs. La bande passante attribuée est de 50 Mbps, mais je n'obtiens que 20 Mbps. Le FAI hésite à changer son appareil (ressemble à un commutateur ou concentrateur Ethernet) dans le MUX. Les ingénieurs du FAI blâment cela de ma faute à mes côtés. Mais j'ai vérifié avec plus de 3 appareils, tous ont montré des erreurs. Alors, y a-t-il des outils pour Linux que je peux utiliser pour sonder profondément les causes de ces erreurs, ou y a-t-il quelque chose que je puisse faire pour reconfigurer l'interface de mon serveur afin de se débarrasser de ces erreurs?

Vous avez très probablement une discordance de duplex en raison du fait que le FAI a codé en dur leur côté à 100-Full, désactivant essentiellement la négociation automatique sur le PHP Ethernet ISP.

Avec l'ISP réglé sur 100-Full et votre côté restant sur auto / auto (un pressentiment, mais un commun), la négociation automatique de votre côté configurera l'interface à 100-Half - une incompatibilité duplex comme côté ISP restera 100-Full.

Réparer

Vous pouvez résoudre le problème en codant en dur votre PHY Ethernet à 100-Full - ou spécifiquement quel que soit le FAI est réglé sur. La plupart des FAI utilisent 100-Full.

Détails supplémentaires

Avec l'inadéquation duplex de 100-Full à 100-Half, le côté 100-Full désactive CSMA / CD tandis que CSMA / CD reste en vigueur du côté 100-Half. Le côté 100-Full transmet sans tenir compte du fait que le support soit libre ou non. Le côté 100-Half effectue des vérifications et des interruptions CSMA / CD comme défini par CSMA / CD. C'est pourquoi vous ne pouvez atteindre que 20 Mb / s sur ce qui devrait être un circuit Internet à 50 Mb / s . L'arrêt CSMA / CD en raison des collisions détectant le côté 100-Half limite le débit.

En codant en dur l'interface à 100-Full pour qu'elle corresponde au FAI, CSMA / CD sera désactivé des deux côtés, donc la détection des interruptions et des collisions sera désactivée et vous devriez obtenir des chiffres beaucoup plus proches de votre débit de données du circuit Internet à 50 Mb / s.

Histoire

De nombreux FAI codent en dur leurs transferts Ethernet PHY car il fut un temps où il était beaucoup plus fiable de le faire. Lorsque la norme Fast Ethernet 802.3u 100 Mb / s d'origine a été publiée, la négociation automatique de la vitesse et du duplex était présente, mais pas nécessaire . Il a fallu attendre la norme Gigabit Ethernet 802.3z 1 Gb / s lorsque la négociation automatique était requise par la norme.

De nombreux ingénieurs réseau ont des idées fausses sur la négociation automatique. La plus grande idée fausse est que la négociation automatique peut négocier correctement la vitesse et le duplex si un seul côté implémente la négociation automatique. C'est faux - comme vous l'avez vu.

La raison en est probablement la suivante - si un côté est codé en dur à 100-Full, l'autre côté exécutant la négociation automatique semble toujours comprendre la partie à 100 Mb / s. Même si un côté est codé en dur à 10-Full - l'autre côté exécutant la négociation automatique peut déterminer la partie 10 Mb / s. La capacité de déterminer la vitesse de liaison provient d'une fonction appelée détection parallèle qui essaie le signal de couche physique reçu sur toutes les vitesses de liaison prises en charge localement jusqu'à ce qu'une correspondance soit trouvée. Cependant, la détection parallèle ne fonctionne que pour la vitesse, pas pour la correspondance duplex. C'est pourquoi des asymétries de duplex peuvent se produire - car une interface retombera toujours en semi-duplex lorsqu'elle ne pourra pas déterminer l'autre côté par auto-négociation.

Caisse à savon

À un moment donné, l'auto-négociation a reçu un soutien inégal et cela a causé autant de problèmes que prévu. Cette fois, de l'avis de cet ingénieur réseau - est passée. Bien que des problèmes de négociation automatique existent toujours, le nombre de problèmes que j'ai vus en raison de la configuration de la négociation automatique au cours des 5 dernières années éclipse le nombre de problèmes que j'ai vus en raison de la désactivation de la négociation automatique.

Je n'ai jamais eu de FAI refusant de changer son transfert Ethernet en auto / auto lorsqu'on me le demandait. Avec la plupart des modems et passerelles câble et DSL, ce n'est pas un problème. Ce sont les routeurs CPE NxT1 et fibre gérés avec transfert Ethernet où ce problème réside généralement. Le problème est qu'un administrateur réseau doit demander en premier lieu.

Avec un ISP codé en dur à 100-Full, ils ont donné une obligation . Une obligation qui doit être documentée et maintenue. L'auto-négociation est une technologie qui est maintenant stable, existe depuis des années et s'occupe de ce problème pour nous. Comme mentionné précédemment, le nombre de problèmes causés par l'auto-négociation est largement compensé par le nombre de problèmes qui surviennent en raison de sa désactivation en 2011. La technologie existe pour résoudre ce problème, utilisez-le. Peut-être devrions-nous définir manuellement les TCP SYN, MSS et gérer la fenêtre de réception pour chaque circuit virtuel TCP également? Je blague.

Déclamez.