Pregunta ¿Debe configurarse el hardware de la red para "negociar automáticamente" o velocidades fijas?


Nosotros Recientemente tuve un pequeño problema con redes en las que varios servidores perderían de forma intermitente la conectividad de la red de una manera bastante dolorosa de resolver (requiere reinicio por hardware). Esto ha estado ocurriendo durante aproximadamente dos semanas, aparentemente al azar, en diferentes servidores. No hay un patrón particular que podamos discernir.

Después de profundizar en él, vimos que el switch estaba reportando 100 Mbps para el puerto problemático:

Esto suena notablemente como lo que sucedió en el artículo de Joel Spolsky. Cinco por qué

Michael pasó algún tiempo haciendo una autopsia y descubrió que el problema era un simple problema de configuración en el conmutador. Hay varias velocidades posibles que un conmutador puede utilizar para comunicarse (10, 100 o 1000 megabits / segundo). Puede establecer la velocidad manualmente o dejar que el interruptor negocie automáticamente la velocidad más alta con la que ambos lados puedan trabajar. El interruptor que falló se había configurado para negociar automáticamente. Esto generalmente funciona, pero no siempre, y en la mañana del 10 de enero no funcionó.

Tenemos ahora auto-negociación deshabilitada en nuestro hardware de red y configúrelo a una velocidad fija de 1000 Mbps (gigabit).

Mis preguntas para aquellos con más experiencia en redes de hardware de servidor:

  1. ¿Qué tan comunes son los problemas de autonegociación con el hardware de red moderno?
  2. ¿Se considera una buena práctica de red estándar deshabilitar la negociación automática y establecer velocidades fijas al configurar la red?

87
2018-01-25 18:57


origen


¿También ha desactivado la negociación automática en sus servidores y los ha fijado en 1000 / full? - James
Soy yo, pero si me encontrase con su problema, me preguntaría por qué el conmutador y el servidor no están negociando la velocidad de prioridad más alta (1000 / full). Eso me dice que algo está roto y al forzar el enlace a una cierta velocidad, simplemente está encubriendo un problema. - Doug Luxem
hay algunas plataformas (en particular, Solaris 9) que tienen problemas con la negociación automática en escenarios conocidos; solo uso autoneg con todo lo creado en la última década, aunque - warren
Algo que casi me hizo deslizar el rosa: serverfault.com/questions/328105/ethernet-interface-errors - nixnotwin


Respuestas:


  1. Todavía tengo que ver un problema con la autonegociación de velocidades de red que no se debe a (a) una falta de coincidencia entre el manual en un extremo del enlace y la automática en el otro o (b) un componente defectuoso del enlace ( cable, puerto, etc).

  2. Esto depende del administrador, pero mi experiencia me ha demostrado que si especifica manualmente las velocidades de enlace y la configuración dúplex, es probable que se encuentre con discrepancias de velocidad. ¿Por qué? Debido a que es casi imposible documentar las diversas conexiones entre conmutadores y servidores y luego seguir esa documentación al realizar cambios. La mayoría de los fallos que he visto se deben a 1 (a) y solo te metes en esa situación cuando comienzas a configurar manualmente la configuración de velocidad / dúplex.

Como se menciona en el Documentación de Cisco:

Si deshabilita la negociación automática, oculta las caídas de enlaces y otros problemas de la capa física. Solo deshabilite la negociación automática para dispositivos finales, como las NIC Gigabit más antiguas que no admiten la negociación automática Gigabit. No deshabilite la negociación automática entre conmutadores a menos que sea absolutamente necesario, ya que los problemas de la capa física pueden pasar desapercibidos y dar lugar a lapsos de árbol de expansión.

A menos que esté preparado para configurar un sistema de gestión de cambios para cambios de red que requiera la verificación de velocidad / dúplex (y no olvide el control de flujo) o esté dispuesto a lidiar con desajustes ocasionales que provienen de la especificación manual de estos ajustes en todos los dispositivos de red, luego seguir con la configuración predeterminada de auto / auto.

En el futuro, considere monitorear los errores en los puertos del switch con MRTG para que pueda detectar estos problemas antes de tener un problema.

Editar: Veo mucha gente que hace referencia a fallas de negociación en equipos viejos. Sí, esto fue un problema hace mucho tiempo cuando se creaban los estándares y no todos los dispositivos los seguían. ¿Son sus NICs y switches menos de 10 años? Si es así, entonces esto no será un problema.


101
2018-01-25 19:15



Cacti es esencialmente MRTG sin el desorden de configuración, por lo que debería ser bueno. Simplemente comience a monitorear las caídas y errores de RX, colisiones de TX, etc. Uno o más de estos contadores estarán "altos" si tiene un problema de negociación. Alto siendo relativo a la cantidad de tráfico en el puerto. - Doug Luxem
@EK - La configuración debe realizarse en el switch y el dispositivo. Reemplazar el dispositivo (o tal vez simplemente actualizar los controladores / firmware), mover puertos o reemplazar el conmutador, entonces todos son problemas para una configuración no coincidente. No estoy seguro de por qué ves tantos errores: aquí ejecutamos HP, Cisco, Extreme y Juniper y nunca veo problemas de negociación automática. Los únicos problemas que he visto son cuando un extremo del enlace se establece manualmente. Como menciona la documentación de Cisco, ¿quizás tenga algunos problemas subyacentes de L1? - Doug Luxem
Mi experiencia con los conmutadores de HP, Cisco y Dell coincide con w / DLux. Estoy adivinando por los comentarios positivos que muchas otras personas sienten lo mismo. Las redes donde los administradores de velocidad de puerto / dúplex religiosamente establecidos siempre tuvieron muchos más problemas con los desajustes que las redes en las que todo estaba configurado para negociar automáticamente. - Evan Anderson
Los enlaces @Whisk WAN son una historia diferente. Cuando se le entregan los enlaces de Ethernet de algún proveedor, con frecuencia se los obliga a usar el manual o están utilizando un transceptor que no admite la negociación automática. Esos casos deben ser manejados caso por caso. - Doug Luxem
Creo que la votación es un poco engañosa ya que algunas personas tendrán el lujo de hardware de 1 o 2 proveedores (o simplemente no experimentaron mucho) y nunca verán un problema, mientras que otros como yo habrán heredado equipos de muchos proveedores diferentes que sí lo hacen. portarse mal en ciertas combinaciones. - JamesRyan


  1. Muy común, he tenido numerosos problemas a lo largo de los años con varios tipos de hardware.

  2. En mi opinión, si la configuración es estática (es decir, un rack del servidor) y no cree que haya cambios, es una buena idea configurar las velocidades y los dúplex manualmente. Siempre y cuando esté bien documentado para evitar problemas futuros.

EDITAR:

Solo para aclarar, no estoy recomendando el uso de velocidades manuales en toda su red, diría que el 95% del tiempo auto / auto es el camino a seguir. Solo digo que he tenido problemas con el dúplex / velocidad y que hay pequeñas porciones de mi red (es decir, uno de nuestros bastidores de servidores) que tienen configuraciones principalmente manuales. Operamos una LAN muy controlada, con puertos no utilizados apagados y filtros MAC en la mayoría de los puertos, por lo que no es muy difícil mantener un registro de las velocidades.


23
2018-01-25 19:03



He encontrado el mismo problema, pero quizás solo 1/100 servidores tengan algún tipo de problemas de negociación automática. Por lo general, no se nota en redes más pequeñas, pero es suficiente para ser molesto en redes más grandes. - Dave Drager
+1 - Yo también he visto el problema emergente de autonegociación en los últimos años. Tener el equipo estandarizado en la desactivación de la negociación automática para todos los switches eliminó ese problema para nosotros. - Joe Doyle
No hay nada que agregar a esto, excepto que puedo repetir que he visto numerosos problemas. Si alguien más tiene información sobre POR QUÉ el autonegocia falla tan (relativamente) regularmente, me encantaría escucharla. - Schof
@dave, por lo que las posibilidades de que ocurra un problema de autonegociación aumentan con el tamaño y la complejidad de la red; eso tiene sentido. Además, ampliamos nuestra pequeña red de servidores en rack en el último año en 3x ... - Jeff Atwood
@Jeff Atwood: Solo en la medida en que el migt de "tamaño" se relacione con tener mejores posibilidades de agregar un dispositivo con un comportamiento de negociación automática roto, aumentaría el potencial de problemas. Esto no es como la inundación de cuadros o el tráfico de difusión. La autonegociación es estrictamente entre cada dispositivo cliente y cada puerto de switch. - Evan Anderson


Creo que si la negociación automática funcionó durante una hora al día o al mes y luego, por alguna razón, "algo sucede" que establece que el enlace a una velocidad fija "lo soluciona", existe un problema que no se resuelve, sino que se evita. Creo que veo que la configuración del enlace se fija como una solución temporal hasta que el problema real se corrige.


15
2018-01-25 19:47



enteramente posible Ya hemos hecho un montón de otros problemas para descartar cosas, pero me preocupaba que el equipo de Joel tuviera el mismo problema que el documentado en "Cinco por qué". Parece bastante extendido .. - Jeff Atwood
Estoy de acuerdo en que el problema con la negociación automática se produce "a menudo", pero en la mayoría de los casos después de que ha funcionado durante un "tiempo". Eso es lo que me impulsa a querer seguir investigando en lugar de usar el enlace fijo como una "solución". Quiero decir ... si su automóvil que "funciona bien" comienza a funcionar de manera irregular a menos que se caliente durante 10 minutos, no diría que usted mismo "Oye, se está volviendo viejo y ahora necesita calentarse durante 10 minutos" Lo tomaría para que lo vean en su primera oportunidad porque "algo está mal" que no estaba antes :) - dimitri.p


La red de la que soy responsable (junto con algunos otros tipos) está formada por ~ 40 servidores, más de 1000 estaciones de trabajo (distribuidas en un campus bastante grande) y ~ 1000 WAP también distribuidas en un área grande con diferentes tipos y edades de equipos de red.

Como dijo dimitri.p, cuando algo falla repentinamente en detener la negociación automática, generalmente es una indicación de otro problema. Configurar el puerto de forma manual es similar a ponerle una banda a alguien que fue apuñalado en la tripa; puede detener la hemorragia, pero seguramente habrá daño debajo.

Mi lista de verificación habitual:

  • ¿Cambió algo en la máquina? conductores? Configuración de nivel de OS o BIOS? Tal vez autoneg fue deshabilitado en el sistema operativo?
  • ¿Ha cambiado los cables de conexión, y verificado el cable corre (si es un logner run de un rack?)
  • ¿has probado para ver si el puerto del switch es malo o está fallando?
  • ¿Podría estar mal el NIC?

Nosotros, como regla, Nunca deshabilite la conexión automática en los servidores (o cualquier otra cosa en el centro de datos) a menos que sea una situación en la que se hayan eliminado todas las demás causas posibles, cambiamos los puertos del switch, cambiamos los cables, probamos la NIC, etc. y no tenemos otra opción. En cuyo caso, se documenta hasta la muerte. Esto ocurre muy raramente, y generalmente con dispositivos a los que no podemos acceder para verificar la configuración del BIOS y del SO.

Las estaciones de trabajo y los puntos de acceso, por otro lado, son una historia diferente. La autonegulación fallida es un signo clásico de un mal funcionamiento del cable, y muchas veces tenemos que configurar manualmente la velocidad y el dúplex hasta que llegue la temporada de verano de nuevos cables en las paredes.


14
2018-01-25 20:08



hemos intercambiado cables y puertos repetidamente en un servidor "problemático", y volvimos a usar los controladores de red "en la caja" (Server 2008 R2). También sucede en múltiples servidores de configuración idéntica. Me está costando mucho reconciliar "¡nunca hagas esto!" y "siempre haz esto!" En las respuestas a la misma pregunta. - Jeff Atwood
@Jeff: estar familiarizado con la pregunta que usted y su equipo publicaron originalmente (serverfault.com/questions/104791) Estoy interesado en saber si el problema está siguiendo al puerto del switch o al puerto NIC en la (s) computadora (s) del servidor con problemas. ¿Cuál es la marca / modelo de NIC / chipset, de todos modos? - Evan Anderson
@Jeff - Algunas respuestas no son binarias :) Es hacerlo cuando sea necesario, hasta que tenga la oportunidad de averiguar cuál es el problema. - dimitri.p
@evan sucede en todos los servidores de nivel web, sin seguir ningún puerto de switch o tarjeta Ethernet. Si sigue siendo un problema después de este cambio, es un problema de software. Los servidores son Lenovo RS110 x6 y Lenovo RD120 x2. - Jeff Atwood
Solo para asegurarse de que la respuesta final esté aquí, en algún lugar: fue un problema de manejo con Broadcom. No pudimos resolverlo con ningún conjunto de controladores conocidos. La única "solución" era cambiar a Intel NICs. - Jeff Atwood


Entonces, los pasos de solución de problemas (suponga que se detiene después de cada uno y espera a que vuelva a aparecer el problema):

  1. Verifique los registros en el interruptor para ver si le dice por qué está usando 100M.
  2. Si aún lo estás ejecutando, desactiva esa mierda extremadamente malvada del "equilibrio de carga de Windows" que Joel está presionando todo el tiempo; la forma en que funciona es rompiendo la memoria caché del conmutador, forzándolo a procesar el software de cada paquete. Su conmutador está diseñado para reenviar paquetes en hardware, y solo tiene la CPU necesaria para averiguar qué ruta física debe tomar un flujo de tráfico desconocido (en -> asic -> fuera), y programar el hardware para hacerlo (lea: a la calculadora tiene una CPU mejor que su conmutador, no haga cosas estúpidas que hacen que la CPU de su conmutador trabaje más duro). El equilibrio de carga de Windows funciona haciendo que su conmutador tome esa decisión y vuelva a instalar el caché de hardware para cada paquete. Puede que no solucione este problema en particular, pero me molesta de los podcasts ... lo siento.
  3. Asegúrate de que la configuración coincida en ambos lados, suena como si lo hubieras hecho
  4. Google busca errores de autonegulación en su conmutador: a menos que lo haya creado usted mismo, no es el único que intenta ejecutar autoneg en cualquier cosa que esté usando
  5. Reemplace el cable con Cat5e nominal o mejor, idealmente un cable que sepa que funciona, como el que está enchufado en su estación de trabajo. No intentes usar Cat5, o alguna mierda hecha por alguien, usa una que tenga extremos moldeados reales de un paquete.
  6. Mover el puerto: coloque el servidor en un puerto diferente en el mismo conmutador
  7. Cambie la NIC - use un lote diferente ordenado en un momento diferente

En este punto, ha eliminado la configuración, los puertos físicos a los que está conectado, el cableado entre ellos. Si es todavía Sucediendo, algunas otras causas pueden ser:

  1. Encaminamiento de los cables: tenga cuidado con la interferencia EM de sus cables de alimentación de CA, diríjalos hacia diferentes lados del rack.
  2. Enfriamiento: asegúrate de que la temperatura ambiental no sea de aproximadamente 90 grados y que tus tarjetas NIC no estén cayendo en algún tipo de modo de "querido Dios, solo permíteme reenviar este paquete". He escuchado, pero no he visto, que los enrutadores de Cisco dejan de hacer paquetes de cambio rápido y reenvío a través de la CPU cuando se sobrecalientan, por ejemplo.
  3. Reemplace el conmutador con algo que no apague: verifique la cantidad de ancho de banda que sus hosts están hablando por segundo en conjunto, y luego mire la capacidad nominal del plano posterior de su conmutador. 7 hosts fuera del potencial 48, todo lo que transmite 1.0G es suficiente para detener un Cisco 3750, por ejemplo. También ser muy cuidado con los vendedores de la red también administrados por cheapo: D-Link, Linksys, Dell, Intel y HP. Nadie que trate a la red usa seriamente a esos tipos, y no porque "nadie fue despedido por usar Cisco", sino porque "la gente recuerda que el conmutador Intel que tenía 20/48 puertos fallaron en 2 años" o el "solía usar ProCurve exclusivamente y No sé qué tan mal fue Cisco, hasta que realmente utilicé Cisco, en ese momento dejé de comprar nada menos ". Cisco es considerado un rango medio proveedor de red, así que, ¿qué te dice eso acerca de los chicos? abajo Cisco ...? :-)

Antecedentes / por qué mi respuesta es la más asombrosa: trabajo como ingeniero de redes / sistemas en la industria financiera, y aquí está mi experiencia con nuestra pequeña red global (15 sucursales, 8 centros de datos):

Todos nuestros puertos LAN son automáticos, porque controlamos el equipo en ambos extremos y tenemos algún tipo de acceso a ambos lados, lo que puede ser tan simple como enviar el teléfono a alguien y hacer que compruebe la configuración. En tres años, solo he tenido uno de nuestros puertos internos con fallas debido a fallas en el autoneg, y esto se debió a un cable defectuoso: se fue después de reemplazar el cable.

Tuvimos muchos más problemas donde los predecesores habían codificado 100 / full en sus NIC y no documentaron ese hecho. Restablece todo a automático en la siguiente ventana de maint y no he tenido ningún problema con ellos desde entonces.

¿En los lugares de pareja donde tenemos una transferencia de cobre de un operador para nuestra WAN? Debería esperar que una conexión WAN / Internet de cobre apague, todo el tiempo, en parte porque no tiene idea de lo que hay al otro lado. Algún conmutador Extreme antiguo que tiene un firmware defectuoso para autonegulación, ¿pero el etiquetado MPLS? ¿Un conversor de medios de $ 5 debido a que el dispositivo de borde Ciena de $ 200k de su ISP es simplemente demasiado impresionante para proporcionar Ethernet sobre par trenzado? Decida de antemano cómo se va a manejar y apéguese a ello, luego espere que algún imbécil dentro del operador lo cambie a las 10 pm de un sábado porque la configuración acordada nunca se documentó y tienen alguna política que seguir.

En serio, sin embargo, obtenga una transferencia de fibra de su ISP.


14
2018-01-26 12:37



Acabo de leer esto, excelente respuesta. - Helvick
Excelente respuesta. - Rushino
solo para que la respuesta final estuviera aquí, en algún lugar, eran malos controladores de Broadcom. No pudimos encontrar ningún conjunto que funcionara. El cambio a Intel NICs lo solucionó al 100%. blog.serverfault.com/2011/03/04/broadcom-die-mutha - Jeff Atwood
@JeffAtwood ¿Es el mismo problema? Pensé que este fue eventualmente rastreado hasta un modo de ahorro de energía en el interruptor ... - James Cape


Este es el mito de la red. Nuestros chicos de la red confían en esta tontería, porque en 1998 los switches Bay no negociarían con Cisco o algo así. Entonces, en lugar de utilizar el valor predeterminado para el 99,999% del equipo en la tierra, tenemos este ridículo ejercicio de administración de la configuración y un gran chivo expiatorio para aquellos momentos en los que una actualización del controlador NIC restablece la configuración para negociar automáticamente y sucede cualquier cosa.

Se hizo más divertido porque muchos de nuestros servidores utilizan características dudosas como la formación de equipos NIC, lo que evita que pierda el acceso a la red en el improbable caso de que se produzca una falla en el conmutador, al tiempo que lo expone a una falla de software mucho más probable. (Los conductores siempre apestan)

En defensa de los chicos de la red, muchos servidores se ejecutan con los controladores NIC predeterminados de Windows, que normalmente apestan. Si tiene problemas con la negociación automática, y su equipo no se remonta a la administración de Clinton, actualice los controladores de NIC.


10
2018-01-26 04:16



En última instancia, eran malos controladores, pero la única solución que pudimos encontrar fue cambiar a las NIC de Intel. Ahora tenemos una venganza de por vida contra las NIC de Broadcom. - Jeff Atwood


Deberías auto-negociar Si tiene un interruptor que no se negocia automáticamente de manera confiable, compre un interruptor mejor.

Gigabit es supuesto para la negociación automática, y eso incluye la detección automática de cruce (MDI-X).

100baseT es garantizado fallar si uno de los extremos se establece en automático y el otro en manual, y eso es por las especificaciones. Si fuerza un extremo a 100 / lleno, el otro extremo será Negociación automática a 100 / la mitad, lo que le da una falta de coincidencia de dúplex.


10
2018-01-26 10:12





Por lo general, configuro los servidores para que sean fijos, ya que he visto que los equipos de red negocian a 10 / half en lugar de 1000 / full.

También algunos CoLos configuran sus conmutadores no para negociar, sino para hacer solo el enlace en 1000 / full.


9
2018-01-25 19:06





Deshabilitar la negociación automática en una configuración inicial no probada es similar a la programación de vudú: está cambiando algo sin una buena razón. Si, después de realizar la prueba, observa que hay un dúplex o una discrepancia de velocidad o si hay errores excesivos en el puerto, entonces realice otra solución de problemas y finalmente arregle la configuración si es necesario.

Cuando actualiza un controlador o reemplaza el hardware, no hay garantías de que su configuración se mantenga en el lado del servidor.

Establezca ambos lados del enlace para negociar, o arreglar ambos lados. Cuando fijas la configuración de velocidad y dúplex en algunos dispositivos, ya no anuncian sus capacidades a sus compañeros. No sé lo que dice el estándar de Ethernet sobre qué hacer cuando un lado anuncia capacidades y el otro no, y eso probablemente significa que muchos implementadores tampoco lo saben. Algunos escogerán el denominador común más bajo, que es 10 por la mitad y otros asumirán que todo está bien y escogerán la velocidad más rápida posible.

Hay algunas piezas contemporáneas de hardware que no admiten la negociación automática en Gigabit Copper Ethernet, como (al menos algunos) switches Cisco con SFP de cobre.


7
2018-01-25 20:43



Los módulos 6748-SFP son compatibles con autoneg muy bien, simplemente no te permiten negociar a menos de 1000 / full. :-) - James Cape


Hace muchos años pasé un tiempo trabajando para 3com haciendo soporte técnico para casi todos sus equipos de red. Es sorprendente la frecuencia con la que surgió este problema y era un procedimiento bastante estándar para configurar todo manualmente.


6
2018-01-25 19:12



La declaración operativa en esta respuesta es "Hace muchos años". La negociación automática 10/100 no es lo mismo que la negociación automática de gigabits de hoy. - Evan Anderson
¡Tienes toda la razón! Esto fue, efectivamente, "hace muchos años" y ahora, en retrospectiva, no recuerdo que esto suceda tan a menudo con cualquiera de los equipos gigabit, que era bastante nuevo en ese momento.