Question Le matériel réseau doit-il être configuré pour «négocier automatiquement» des vitesses ou des vitesses fixes?


nous eu récemment un petit problème avec une mise en réseau où plusieurs serveurs perdraient de façon intermittente la connectivité réseau de manière assez pénible à résoudre (redémarrage forcé requis). Cela dure depuis environ deux semaines, apparemment au hasard, sur différents serveurs. Aucun modèle particulier que nous pourrions discerner à cela.

Après avoir approfondi le sujet, nous avons constaté que le commutateur signalait 100 Mbps pour le port à problème:

Cela ressemble remarquablement à ce qui s'est passé dans l'article de Joel Spolsky Cinq pourquoi

Michael a passé un certain temps à effectuer un post-mortem et a découvert que le problème était un simple problème de configuration sur le commutateur. Un commutateur peut utiliser plusieurs vitesses possibles pour communiquer (10, 100 ou 1000 mégabits / seconde). Vous pouvez soit régler la vitesse manuellement, soit laisser le commutateur négocier automatiquement la vitesse la plus élevée avec laquelle les deux côtés peuvent travailler. Le commutateur qui a échoué a été configuré pour une négociation automatique. Cela fonctionne généralement, mais pas toujours, et pas le matin du 10 janvier.

Nous avons maintenant désactivé auto-négocier sur notre matériel réseau et réglez-le à un débit fixe de 1000 Mbps (gigabits).

Mes questions aux personnes plus expérimentées dans la mise en réseau de serveurs:

  1. Quelle est la fréquence des problèmes de négociation automatique avec le matériel de réseau moderne?
  2. Est-il considéré comme une bonne pratique réseau standard de désactiver la négociation automatique et de définir des vitesses fixes lors de la configuration du réseau?

87
2018-01-25 18:57


origine


Avez-vous également désactivé la négociation automatique sur vos serveurs et les avez fixés à 1000 / complet? - James
Ceci est juste pour moi, mais si je rencontrais votre problème, je me demanderais pourquoi le commutateur et le serveur ne négocient pas la vitesse de priorité la plus élevée (1000 / full). Cela me dit que quelque chose est brisé et qu'en forçant le lien à une certaine vitesse, vous ne faites que masquer un problème. - Doug Luxem
Certaines plates-formes (notamment Solaris 9) rencontrent des problèmes d'autonégociation dans les scénarios connus. J'utilise uniquement autoneg avec tout ce qui a été fabriqué au cours de la dernière décennie, bien que - warren
Quelque chose qui m'a presque rendu rose a glissé: serverfault.com/questions/328105/ethernet-interface-errors - nixnotwin


Réponses:


  1. Je n'ai pas encore vu de problème avec la négociation automatique de la vitesse du réseau qui ne soit causée par (a) une incompatibilité de manuel à une extrémité de la liaison et automatique de l'autre ou (b) un composant défaillant de la liaison ( câble, port, etc.).

  2. Cela dépend de l'administrateur, mais mon expérience m'a montré que si vous spécifiez manuellement les vitesses de liaison et les paramètres de duplex, vous risquez de rencontrer des problèmes de vitesse. Pourquoi? Parce qu'il est presque impossible de documenter les différentes connexions entre les commutateurs et les serveurs, puis de suivre cette documentation lors de modifications. La plupart des échecs que j'ai vus sont dus à 1 (a) et vous ne vous en apercevrez que lorsque vous commencez à définir manuellement les paramètres de vitesse / duplex.

Comme mentionné dans le Documentation Cisco:

Si vous désactivez la négociation automatique, les masques de liaison et autres problèmes de couche physique sont masqués. Désactivez uniquement la négociation automatique sur les périphériques finaux, tels que les cartes réseau Gigabit plus anciennes qui ne prennent pas en charge la négociation automatique Gigabit. Ne désactivez pas la négociation automatique entre les commutateurs, sauf en cas d'absolue nécessité, car les problèmes de couche physique risquent de ne pas être détectés et d'entraîner des boucles en arborescence.

Sauf si vous êtes prêt à configurer un système de gestion des modifications pour les modifications réseau nécessitant la vérification de la vitesse / du duplex (et n'oubliez pas le contrôle de flux), ou si vous êtes prêt à gérer les incompatibilités occasionnelles dues à la spécification manuelle de ces paramètres sur tous les périphériques réseau, puis s'en tenir à la configuration par défaut auto / auto.

À l’avenir, envisagez de surveiller les erreurs sur les ports du commutateur avec MRTG afin que vous puissiez repérer ces problèmes avant d'avoir un problème.

Modifier: Je vois beaucoup de gens se référant à des échecs de négociation sur du vieux matériel. Oui, c'était un problème il y a longtemps lorsque les normes ont été créées et que tous les appareils ne les ont pas suivies. Vos cartes réseau et commutateurs ont-ils moins de 10 ans? Si oui, alors ce ne sera pas un problème.


101
2018-01-25 19:15



Cacti est essentiellement MRTG sans le désordre de configuration, donc ça devrait être bon. Commencez simplement à surveiller les erreurs et réceptions RX, les collisions TX, etc. Un ou plusieurs de ces compteurs seront «élevés» si vous rencontrez un problème de négociation. Elevé par rapport à la quantité de trafic sur le port. - Doug Luxem
@EK - La configuration doit être effectuée sur le commutateur et le périphérique. Le remplacement du périphérique (ou peut-être simplement la mise à niveau des pilotes / microprogrammes), le déplacement des ports ou le remplacement du commutateur sont autant de problèmes pour les paramètres incompatibles. Je ne suis pas sûr de savoir pourquoi vous voyez tant d’erreurs - nous utilisons ici HP, Cisco, Extreme et Juniper et je ne vois jamais de problèmes de négociation automatique. Les seuls problèmes que j'ai vus sont quand une extrémité du lien est définie manuellement. Comme le mentionne le document Cisco, vous avez peut-être des problèmes sous-jacents de L1? - Doug Luxem
Mon expérience avec les commutateurs HP, Cisco et Dell correspond à w / DLux. Je suppose que, d’après les votes positifs, beaucoup d’autres personnes ressentent la même chose. Les réseaux où les administrateurs administraient religieusement des vitesses de port / duplex rigoureuses avaient toujours beaucoup plus de problèmes d'inadéquation que les réseaux où tout était réglé pour une négociation automatique. - Evan Anderson
Les liens WAN @Whisk sont une autre histoire. Lorsqu'un fournisseur vous transfère des liens Ethernet, ils sont souvent forcés de les utiliser manuellement ou utilisent un émetteur-récepteur qui ne prend pas en charge la négociation automatique. Celles-ci doivent être traitées au cas par cas. - Doug Luxem
Je pense que le vote est un peu trompeur en ce que certaines personnes auront le luxe de matériel de 1 ou 2 fournisseurs (ou n’ont tout simplement pas beaucoup d’expérience) et ne verront jamais un problème alors que d’autres, comme moi, auront hérité du matériel de nombreux fournisseurs différents. se comporter mal dans certaines combinaisons. - JamesRyan


  1. Très commun, j'ai eu de nombreux problèmes au fil des ans avec divers types de matériel.

  2. À mon avis, si la configuration est statique (c'est-à-dire un rack de serveur) et que vous ne pensez pas qu'il y aura des modifications, il est judicieux de configurer manuellement les vitesses et les duplex. Tant que cela est bien documenté pour éviter les problèmes futurs.

MODIFIER:

Juste pour clarifier, je ne préconise pas l’utilisation de vitesses manuelles sur l’ensemble de votre réseau, je dirais que 95% du temps auto / auto est la voie à suivre. Je dis simplement que j’ai eu des problèmes avec le mode duplex / vitesse et que de petites parties de mon réseau (c’est-à-dire l’un de nos racks de serveurs) sont généralement paramétrées manuellement. Nous exploitons un réseau local très étroitement contrôlé avec des ports inutilisés en cours d’arrêt et des filtres MAC sur la plupart des ports, de sorte que le suivi des vitesses n’est pas très difficile.


23
2018-01-25 19:03



J'ai trouvé le même problème, mais peut-être que seulement 1/100 des serveurs auront une sorte de problèmes de négociation automatique. Ce n'est généralement pas perceptible sur les petits réseaux mais suffisant pour être ennuyeux sur les plus grands. - Dave Drager
+1 - J'ai moi aussi vu le problème du problème de la négociation automatique au fil des ans. Le fait que l'équipe ait normalisé la désactivation de la négociation automatique pour tous les commutateurs a éliminé ce problème pour nous. - Joe Doyle
Rien à ajouter à cela, si ce n'est que je peux dire que j'ai rencontré de nombreux problèmes. Si quelqu'un d'autre a des informations sur POURQUOI l'auto-négociation échoue si (relativement) régulièrement, j'aimerais l'entendre. - Schof
@dave donc les chances que le problème de négociation automatique se produise augmentent avec la taille et la complexité du réseau - c'est logique. En outre, nous avons étendu de 3x notre réseau de racks de serveurs au cours de la dernière année ... - Jeff Atwood
@ Jeff Atwood: Ce n'est que dans la mesure où la "taille" est liée à une meilleure chance d'ajouter un périphérique avec un comportement de négociation automatique rompu que le potentiel de problèmes augmente. Cela ne ressemble pas à une inondation de trames ou à un trafic de diffusion. L'autonégociation est strictement effectuée entre chaque périphérique client et chaque port de commutateur. - Evan Anderson


Je crois que si la négociation automatique fonctionnait une heure par jour ou un mois et que, pour une raison quelconque, il se produisait quelque chose qui fixait le lien à une vitesse fixe, il y avait un problème qui n'était pas résolu mais contourné. Je suppose que je vois la définition du lien comme une solution temporaire jusqu'à ce que le problème soit résolu.


15
2018-01-25 19:47



tout à fait possible; nous avons déjà fait beaucoup d'autres procédures de dépannage pour éliminer certains problèmes, mais je craignais que l'équipe de Joel ait le même problème que celui décrit dans "Five Whys". Cela semble plutôt répandu .. - Jeff Atwood
Je conviens que le problème de la négociation automatique se produit "souvent", mais dans la plupart des cas après avoir fonctionné pendant un "temps". C’est ce qui m’incite à vouloir approfondir les recherches au lieu d’utiliser le lien fixe comme "solution". Je veux dire ... si votre voiture qui "fonctionne bien" commence à s’agiter, à moins de chauffer pendant 10 minutes, vous ne diriez pas à vous-même "Hey, ça prend de l’âge et maintenant il faut se réchauffer pendant 10 minutes" Vous voudriez le regarder pour le regarder le plus tôt possible parce que "quelque chose ne va pas" qui n’était pas avant :) - dimitri.p


Le réseau dont je suis responsable (avec quelques autres gars) est constitué d'environ 40 serveurs, plus de 1 000 postes de travail (répartis sur un campus assez grand) et environ 1 000 WAP répartis sur une vaste zone de types et d'âges variés. des équipements de réseau.

Comme dit dimitri.p, quand quelque chose ne parvient pas à arrêter la négociation automatique, c'est généralement un indice d'un autre problème. Régler le port manuellement revient à poser un pansement à quelqu'un qui a été poignardé au ventre - cela pourrait arrêter le saignement, mais il y a sûrement des dégâts en dessous.

Ma liste de contrôle habituelle:

  • Est-ce que quelque chose a changé sur la machine? les conducteurs? Paramètres au niveau du système d'exploitation ou du BIOS? Peut-être que autoneg était désactivé dans le système d'exploitation?
  • avez-vous échangé les câbles de raccordement, et vérifié le câble passe (s'il s'agit d'une journalisation d'un rack?)
  • Avez-vous testé pour voir si le port du commutateur est défectueux ou défaillant?
  • la carte réseau pourrait-elle mal tourner?

Nous, en règle générale, jamais Désactivez Autoneg sur les serveurs (ou tout autre élément du centre de données), à moins que toutes les autres causes possibles aient été éliminées, nous avons déplacé les ports de commutation, changé les câbles, testé la carte réseau, etc. sans autre choix. Dans ce cas, il est documenté à mort. Cela se produit très rarement et généralement avec des appliances auxquelles nous n'avons pas accès pour vérifier les paramètres du BIOS et du système d'exploitation.

Les postes de travail et les points d'accès, en revanche, sont une autre histoire. Échec de la connexion automatique est le signe classique d’un mauvais passage des câbles et nous devons souvent régler manuellement la vitesse et le mode duplex jusqu’à ce que la saison estivale d’installation de nouveaux câbles dans les murs vienne.


14
2018-01-25 20:08



nous avons échangé des câbles et des ports à plusieurs reprises sur un serveur "problème" et nous sommes revenus à l'utilisation de pilotes réseau "dans la boîte" (Server 2008 R2). Cela se produit également sur plusieurs serveurs de configuration identique. J'ai du mal à réconcilier "ne fais jamais ça!" et "fais toujours ça!" dans les réponses à la même question. - Jeff Atwood
@ Jeff: Connaître la question que vous et votre équipe avez initialement posée (serverfault.com/questions/104791) Je souhaite savoir si le problème survient après le port du commutateur ou le port de la carte réseau du ou des ordinateurs serveur posant problème. Quelle est la marque / le modèle de la carte réseau / du chipset, de toute façon? - Evan Anderson
@ Jeff - Certaines réponses ne sont pas binaires :) C’est fais-le quand vous le devez, jusqu’à ce que vous ayez une chance de comprendre le problème. - dimitri.p
@evan se produit sur tous les serveurs Web, sans suivre aucun port de commutateur ni aucune carte Ethernet. Si le problème persiste après ce changement, il s'agit d'un problème logiciel. Les serveurs sont Lenovo RS110 x6 et Lenovo RD120 x2. - Jeff Atwood
Juste pour m'assurer que la réponse finale est là, quelque part: c'était un problème de pilote avec Broadcom. Nous n'avons pas pu résoudre le problème avec aucun jeu de pilotes connu. Le seul "correctif" consistait à passer aux cartes réseau Intel. - Jeff Atwood


Donc, les étapes de dépannage (supposez que vous vous arrêtez après chaque et attendez que le problème réapparaisse):

  1. Consultez les journaux sur le commutateur pour voir s’il indique pourquoi il utilise 100M.
  2. Si vous l'exécutez toujours, désactivez cette connerie extrêmement diabolique "d'équilibrage de la charge Windows" que Joel pousse tout le temps. Son fonctionnement consiste à casser le cache du commutateur, le forçant à traiter chaque paquet par logiciel. Votre commutateur est conçu pour transférer les paquets dans le matériel et ne requiert que le processeur pour déterminer le chemin physique que doit prendre un flux de trafic inconnu (entrée -> asique -> sortie) et pour programmer le matériel en conséquence (lire: a la calculatrice a un meilleur processeur que votre commutateur, ne faites pas de bêtises qui obligent le processeur de votre commutateur à travailler plus fort). L'équilibrage de charge Windows fonctionne en faisant en sorte que votre commutateur prenne cette décision et réinstalle le cache matériel pour chaque paquet. Cela ne résoudra peut-être pas ce problème, mais cela me dérange des podcasts ... désolé.
  3. Assurez-vous que la configuration est identique des deux côtés - cela ressemble à ce que vous avez fait
  4. Google pour la recherche automatique de bogues sur votre commutateur - à moins que vous ne l'ayez construit vous-même, vous n'êtes pas le seul à essayer d'exécuter la recherche automatique sur ce que vous utilisez
  5. Remplacez le câble par Cat5e ou mieux - idéalement, un câble comme vous le savez, tel que celui auquel votre station de travail est branchée. N'essayez pas d'utiliser Cat5, ou une merde fabriquée par quelqu'un, utilisez-en une qui présente des extrémités moulées dans un emballage.
  6. Déplacer le port - Placez le serveur sur un port différent du même commutateur
  7. Remplacez la carte réseau - utilisez un autre lot commandé à une heure différente

À ce stade, vous avez éliminé la configuration, les ports physiques auxquels vous êtes connecté et le câblage entre eux. Si c'est encore passe, certaines autres causes peuvent être:

  1. Acheminement des câbles - faites attention aux interférences électromagnétiques générées par vos câbles d’alimentation secteur, puis acheminez-les vers les différents côtés du rack.
  2. Refroidissement - Assurez-vous que votre température ambiante ne fait pas 90 degrés et que vos cartes NIC ne tombent pas dans une sorte de mode "cher dieu, laissez-moi simplement transmettre ce paquet, s'il vous plaît". J'ai entendu dire, mais pas vu, que les routeurs Cisco arrêtaient par exemple de basculer rapidement et de transférer des paquets via le CPU, par exemple lorsqu'ils surchauffaient.
  3. Remplacez le commutateur par quelque chose qui ne craint rien - vérifiez la bande passante totale que vos hôtes parlent par seconde, puis examinez la capacité nominale du fond de panier de votre commutateur. 7 hôtes sur un total de 48 transmettant tous la 1.0G suffisent pour arrêter un Cisco 3750, par exemple. Être aussi très faites attention aux fournisseurs de réseaux également pas chers: D-Link, Linksys, Dell, Intel et HP. Personne ne traite sérieusement la mise en réseau de ces utilisateurs, non pas parce que "personne n’a été licencié pour avoir utilisé Cisco", mais parce que "les gens se rappellent que le commutateur Intel dont les ports étaient 20/48 en panne sur 2 ans" ou le "J’utilisais exclusivement ProCurve et expliquons à quel point Cisco était diabolique, jusqu’à ce que j’utilise Cisco, puis j’arrête d’acheter moins ». Cisco est considéré comme un milieu de gamme fournisseur de réseau, alors qu'est-ce que cela vous dit sur les gars au dessous de Cisco ...? :-)

Contexte / Pourquoi ma réponse est-elle la plus impressionnante? Je travaille en tant qu'ingénieur réseau / système dans le secteur financier. Voici mon expérience avec notre réseau mondial de petite taille (15 succursales, 8 centres de données):

Tous nos ports LAN sont automatiques, car nous contrôlons l’équipement des deux côtés et avons un accès aux deux côtés - ce qui peut être aussi simple que de téléphoner à une personne et de la faire vérifier les paramètres. En trois ans, un seul de nos ports internes est tombé en panne en raison d’une défaillance automatique, et c’est à cause d’un mauvais câble - il est parti après le remplacement du câble.

Nous avons eu beaucoup plus de problèmes lorsque les prédécesseurs avaient codé en dur 100 / full sur leur carte d'interface réseau et n'ont pas documenté ce fait. Réinitialisez tout sur auto / auto à la fenêtre suivante et ne rencontrez aucun problème depuis.

Sur les quelques endroits où un transporteur nous a transférés le cuivre pour notre réseau étendu? Vous devriez vous attendre à ce qu'une connexion Internet WAN / Internet en cuivre soit nulle, en tout temps, en partie parce que vous ne savez pas ce qui se passe de l'autre côté. Un ancien commutateur Extreme qui possède un micrologiciel buggé pour l'autoneg, mais le marquage MPLS est-il utilisé? Certains convertisseurs de média à 5 $ parce que le périphérique de 200 $ Ciena de votre fournisseur de services Internet est tout simplement trop génial pour fournir Ethernet sur paire torsadée? Décidez à l'avance de la manière dont cela va être traité et respectez-le, puis attendez-vous à ce que le transporteur le change à 22 heures le samedi, car la configuration convenue n'a jamais été documentée et la politique à suivre est respectée.

Sérieusement, obtenez un transfert de fibre de votre FAI.


14
2018-01-26 12:37



Je viens de lire ceci - excellente réponse. - Helvick
Excellente réponse. - Rushino
juste pour que la réponse finale soit ici, quelque part, c’était les mauvais pilotes Broadcom. Nous n'avons pu trouver aucun ensemble qui a fonctionné. Le passage aux cartes réseau Intel a corrigé le problème à 100%. blog.serverfault.com/2011/03/04/broadcom-die-mutha - Jeff Atwood
@ JeffAtwood Est-ce le même problème? Je pensais que celui-ci avait finalement été localisé en mode d'économie d'énergie sur le commutateur ... - James Cape


C'est le mythe du réseau. Nos gars du réseau ne jurent que par cette absurdité, car en 1998, les commutateurs Bay ne négociaient pas avec Cisco ou quelque chose du genre. Ainsi, au lieu d’utiliser la valeur par défaut de 99,999% des équipements sur Terre, nous avons cet exercice de gestion de configuration ridicule et un excellent bouc émissaire pour les situations dans lesquelles une mise à jour de pilote de carte réseau réinitialise les paramètres pour une négociation automatique et que rien ne se produit.

Cela est d'autant plus amusant que beaucoup de nos serveurs utilisent des fonctionnalités douteuses telles que l'association de cartes réseau, qui vous empêchent de perdre l'accès au réseau dans l'éventualité peu probable d'une défaillance du commutateur, tout en vous exposant à une défaillance logicielle beaucoup plus probable. (Les pilotes sucent toujours)

Pour la défense des gars du réseau, beaucoup de serveurs utilisent des pilotes de carte réseau Windows par défaut, ce qui est généralement nul. Si vous rencontrez des problèmes avec la négociation automatique et que votre matériel ne date pas de l'administration Clinton, mettez à jour ces pilotes de carte réseau.


10
2018-01-26 04:16



En fin de compte, c’était de mauvais pilotes, mais la seule solution que nous puissions trouver était de passer aux cartes réseau Intel. Nous avons maintenant une vendetta à vie contre les NIC Broadcom. - Jeff Atwood


Vous devriez auto-négocier. Si vous avez un commutateur qui ne négocie pas automatiquement de manière fiable, achetez-en un meilleur.

Gigabit est supposé pour négocier automatiquement, et qui inclut la détection de croisement automatique (MDI-X).

100baseT est garanti échouer si une extrémité est réglée sur auto et l'autre sur manuel, conformément aux spécifications. Si vous forcez une extrémité à 100 / full alors l'autre extrémité volonté négociez automatiquement à 100 / moitié, vous donnant une disparité de duplex.


10
2018-01-26 10:12