¿Se debe configurar el hardware de red en velocidades de "autonegociación" o velocidades fijas?

Nos hace poco tuvimos un pequeño problema con la creación de redes que varios servidores serían intermitentemente perder la conectividad de red de una manera bastante dolorosa-a-determinación (reinicio duro necesario). Esto ha estado sucediendo durante aproximadamente dos semanas, aparentemente al azar, en diferentes servidores. Ningún patrón particular que pudiéramos discernir.

Después de investigar un poco, vimos que el conmutador informaba 100 Mbps para el puerto con problemas:

Esto suena notablemente a lo que sucedió en el artículo de Joel Spolsky Five Whys

Michael pasó un 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 interruptor puede usar para comunicarse (10, 100 o 1000 megabits / segundo). Puede establecer la velocidad manualmente, o puede dejar que el interruptor negocie automáticamente la velocidad más alta con la que ambos lados pueden trabajar. El interruptor que falló había sido configurado para autonegociar. Esto generalmente funciona, pero no siempre, y en la mañana del 10 de enero, no funcionó.

Ahora hemos deshabilitado la negociación automática en nuestro hardware de red y lo hemos configurado a una velocidad fija de 1000 Mbps (gigabit).

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

1. ¿Qué tan comunes son los problemas de negociación automática 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?

1. Todavía tengo que ver un problema con la negociación automática de las velocidades de red que no se debe a (a) una falta de coincidencia del manual en un extremo del enlace y automático 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 desajustes 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 las fallas que he visto se deben a 1 (a) y solo se llega a esa situación cuando comienza a configurar manualmente la configuración de velocidad / dúplex.

Como se menciona en la 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 desactive la negociación automática para dispositivos finales, como las NIC Gigabit más antiguas que no son compatibles con la negociación automática Gigabit. No desactive 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 lazos de árbol que se extienden.

A menos que esté preparado para configurar un sistema de gestión de cambios para cambios de red que requiera la verificación de la velocidad / dúplex (y no olvide el control de flujo) o esté dispuesto a lidiar con desajustes ocasionales que provienen de especificar manualmente estas configuraciones en todos los dispositivos de red, luego quédese 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 a muchas personas haciendo referencia a fallas de negociación en equipos antiguos. Sí, esto era un problema hace mucho tiempo cuando se creaban los estándares y no todos los dispositivos los seguían. ¿Sus NIC e interruptores tienen menos de 10 años? Si es así, entonces esto no será un problema.

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 bastidor del servidor) y no cree que habrá cambios, es una buena idea configurar las velocidades y los dúplex manualmente. Siempre que esté bien documentado para que se puedan evitar problemas futuros.

EDITAR:

Solo para aclarar, no estoy abogando por 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 racks de servidores) que tienen configuraciones principalmente manuales. Operamos una LAN muy estrechamente controlada con puertos no utilizados que se apagan y filtros MAC en la mayoría de los puertos, por lo que no es muy difícil realizar un seguimiento de las velocidades.

Creo que si la negociación automática funcionaba durante una hora al día o un mes y luego, por alguna razón, "algo sucede" que establecer el enlace a velocidad fija "lo arregla", hay un problema que no se resuelve sino que se evita. Supongo que veo configurar el enlace como fijo como una solución temporal hasta que se corrija el problema real.

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 todavía lo está ejecutando, apague esa mierda de "equilibrio de carga de Windows" extremadamente malvada que Joel está presionando todo el tiempo: la forma en que funciona es rompiendo el caché del interruptor, forzándolo a procesar el software de cada paquete. Su conmutador está diseñado para reenviar paquetes en hardware, y solo tiene la CPU requerida para determinar qué ruta física debe tomar un flujo de tráfico desconocido (in -> asic -> out) y programar el hardware para que lo haga (lea: a la calculadora tiene una CPU mejor que su conmutador, no haga cosas estúpidas que hagan que la CPU de su conmutador trabaje más). El equilibrio de carga de Windows funciona al hacer que su switch tome esa decisión y reinstale el caché de hardware para cada paquete. Es posible que eso 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, parece que lo has hecho
4. Google para errores de autoneg en su conmutador: a menos que lo haya construido usted mismo, no es el único que intenta ejecutar autoneg en lo que sea que esté utilizando
5. Reemplace el cable, con Cat5e o mejor, idealmente un cable que sepa que funciona, como el que está conectado a su estación de trabajo. No intente usar Cat5, o alguna basura hecha por alguien, use una que tenga extremos moldeados reales de un paquete.
6. Mueva 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 en los que está conectado, el cableado entre ellos. Si todavía está sucediendo, algunas otras causas pueden ser:

1. Enrutamiento de cables: tenga cuidado con la interferencia EM de sus cables de alimentación de CA, diríjalos por diferentes lados del bastidor.
2. Enfriamiento: asegúrese de que su temperatura ambiental no sea algo así como 90 grados y que sus tarjetas NIC no entren en una especie de modo "querido Dios, déjeme enviar este paquete, por favor". He oído, pero no he visto, que los enrutadores Cisco dejan de realizar cambios rápidos y reenvían paquetes a través de la CPU cuando se sobrecalientan, por ejemplo.
3. Reemplace el conmutador con algo que no apesta: compruebe la cantidad de ancho de banda que sus hosts están hablando por segundo en conjunto, y luego observe la capacidad nominal del plano posterior de su conmutador. 7 hosts fuera del potencial 48 todos transmitiendo 1.0G es suficiente para detener un Cisco 3750, por ejemplo. También tenga mucho cuidado con los vendedores de red también gestionados por cheapo: D-Link, Linksys, Dell, Intel y HP. Nadie que trate las redes usa a esos tipos en serio, y no porque "nadie haya sido despedido por usar Cisco", sino porque "la gente recuerda que el conmutador Intel que tuvo 20/48 puertos falló durante 2 años" o "Solía ​​usar ProCurve exclusivamente y Me di cuenta de lo malvado que era Cisco, hasta que realmente usé Cisco, momento en el que dejé de comprar algo menos ". Cisco es considerado un rango medioproveedor de red, entonces, ¿qué le dice eso sobre los tipos debajo de 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 red global pequeña (15 sucursales, 8 centros de datos):

Todos nuestros puertos LAN son de autoneg, porque controlamos el equipo en ambos extremos y tenemos algún tipo de acceso a ambos lados, lo que puede ser tan simple como conectar el teléfono con alguien y hacer que verifiquen la configuración. En tres años, solo he tenido una falla en uno de nuestros puertos internos debido a un fallo de autoneg, y eso se debió a un cable defectuoso, que desapareció 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. Restablezca todo a auto / auto en la siguiente ventana de mantenimiento y no he tenido ningún problema con ellos desde entonces.

¿En los dos lugares donde tenemos una transferencia de cobre de un operador para nuestra WAN? Debería esperar que una conexión WAN / Internet de cobre apestara todo el tiempo, en parte porque no tiene idea de lo que hay del otro lado. ¿Algún antiguo conmutador Extreme que tiene firmware defectuoso para autoneg pero hace etiquetado MPLS? ¿Un convertidor de medios de $ 5 porque el dispositivo Ciena edge de $ 200k de su ISP es simplemente demasiado impresionante para proporcionar Ethernet sobre par trenzado? Decida de antemano cómo se manejará eso y cúmplalo, luego espere que algunos twittes dentro del operador lo cambien a las 10 p.m. de un sábado porque la configuración acordada nunca se documentó y tienen alguna política a seguir.

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

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

Como dijo dimitri.p, cuando algo repentinamente no puede detener la negociación automática, generalmente es una indicación de otro problema. Establecer el puerto manualmente es similar a poner una venda en alguien que fue apuñalado en el intestino; podría detener el sangrado, pero seguramente habrá daños debajo.

Mi lista de verificación habitual:

• ¿Ha cambiado algo en la máquina? conductores? ¿Configuración de nivel de sistema operativo o BIOS? Tal vez autoneg fue deshabilitado en el sistema operativo?
• ¿Ha cambiado los cables de conexión y ha verificado los tendidos de cable (si es un funcionamiento de registro que un bastidor?)
• ¿Has probado para ver si el puerto del conmutador es malo o está fallando?
• ¿podría la NIC ir mal?

Nosotros, como regla, nunca deshabilitamos la autenticació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 otras causas posibles, movimos los puertos del interruptor, cambiamos los cables, probamos la NIC, etc. y no hay 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 el sistema operativo.

Las estaciones de trabajo y AP, por otro lado, son una historia diferente. La autoneg fallida es un signo clásico de un mal tendido de cables, y muchas veces tenemos que configurar manualmente la velocidad y el dúplex hasta que llegue la temporada de verano de cables nuevos en las paredes.

Este es el mito de la red. Nuestros muchachos de la red juran por estas tonterías, porque en 1998 los conmutadores Bay no negociarían con Cisco o algo así. Entonces, en lugar de usar el valor predeterminado para el 99.999% del equipo en la tierra, tenemos este ejercicio de administración de configuración ridículo y un gran chivo expiatorio para aquellos momentos en 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 usan características dudosas como la formación de equipos de NIC, que evitan que pierda el acceso a la red en el improbable caso de una falla del interruptor, mientras lo expone a una falla de software mucho más probable. (Los conductores siempre apestan)

En defensa de los chicos de la red, se están ejecutando muchos servidores con controladores NIC predeterminados de Windows, que generalmente son una mierda. Si tiene problemas con la negociación automática y su equipo no data de la administración Clinton, actualice esos controladores NIC.

Debes negociar automáticamente. Si tiene un interruptor que no se negocia automáticamente de manera confiable, compre un interruptor mejor.

Se supone que Gigabit negocia automáticamente, y eso incluye la detección de cruce automático (MDI-X).

Se garantiza que 100baseT fallará si un extremo está configurado en automático y el otro en manual, y eso es según las especificaciones. Si se fuerza a un extremo 100 / lleno, entonces el otro extremo se la negociación automática a 100 / media, que le da un desajuste dúplex.

Por lo general, configuro los servidores para que se reparen, ya que he visto que el equipo de red negocia a 10 / medio en lugar de 1000 / completo.

Además, algunos CoLos configuran sus interruptores no para negociar, sino para hacer un enlace a 1000 / completo.

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 haber probado, ve que hay un dúplex o desajuste de velocidad o que 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 hardware, no hay garantías de que su configuración se conserve en el lado del servidor.

Establezca ambos lados del enlace para negociar, o arregle ambos lados. Cuando corrige la configuración de velocidad y dúplex en algunos dispositivos, ya no anuncian sus capacidades a sus pares. No sé qué 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 elegirán el mínimo común denominador, que es 10 mitad y otros asumirán que todo está bien y elegirán la velocidad más rápida posible.

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

Hace muchos años pasé un tiempo trabajando para 3com haciendo soporte técnico para casi todo su equipo de redes. Es sorprendente la frecuencia con la que surgió este problema y fue casi un procedimiento estándar configurar todo manualmente.

He tenido muchos problemas con la negociación automática. Muchos, por supuesto, significa uno cada pocos meses, pero ese es un problema demasiado en mi libro.

Los problemas de negociación automática son difíciles de encontrar, especialmente cuando las personas que manejan redes, servidores, aplicaciones y bases de datos son cuatro equipos diferentes. Por lo general, los dos últimos pasarán mucho tiempo yendo y viniendo, acusándose mutuamente de mal desempeño y mintiendo acerca de las mediciones, y a veces se lo dirigen a la gente del servidor, que mirará debidamente la salida de "top" y dirá que todo es bien con el servidor.

Esto continúa hasta que el asunto se intensifica hasta el punto en que un "experto" (en realidad, alguien que es un generalista y, por lo tanto, comprende redes, hardware, sistemas operativos, bases de datos, marcos y aplicaciones) es asignado al problema y encuentra el problema. dentro de cinco o diez minutos.

Por lo tanto, mi propia regla general, siempre que tengo la capacidad de hacer algo al respecto, es SIEMPRE establecer velocidades fijas en servidores de producción, conmutadores y enrutadores. Los servidores que no son de producción también, si están lo suficientemente segregados para las personas que lo usan, no tienen acceso a la raíz.

Los conmutadores que manejan el acceso al escritorio / portátil se pueden dejar para negociar automáticamente, y hay excepciones a la regla. Solo por mencionar uno, si hay muchos cambios en la red, es mejor dejarlo en automático y vigilar las cosas.

Otro punto que puede ser útil, sea ​​cual sea su elección con respecto a la negociación automática , es monitorear la cosa. Simplemente configure Nagios o lo que tenga para vigilar el estado de cualquier puerto importante. Ya estás monitoreando ese equipo de red de todos modos, ¿no?

Áspero uno He visto NIC 3com de 100Mb que no se conectarían a nada por encima de 10Mb si forzaras la velocidad o el dúplex. Solo podría obtener la velocidad máxima al permitirles negociar automáticamente a pesar de que el controlador tenía configuraciones de 100Mb Full y 100Mb Half.

Muchos controladores NIC no le permitirán especificar 1000Mb. Las únicas opciones son 10, 100, Auto. Nuevamente obligándote a hacer Auto si quieres velocidad máxima. por ejemplo, el controlador Broadcom netXtreme 57xx Gigabit se comporta de esta manera.

Puede forzar fácilmente Gigabit en el conmutador, pero creo que se verá obligado a dejar que la mayoría de las NIC negocien automáticamente.

1. En mi experiencia (principalmente equipos 3Com y HP, no mucho Cisco), la negociación automática no causa muchos problemas.

2. De manera similar a mrdenny, generalmente configuraré los servidores a su velocidad más rápida (todavía tenemos algunos a 100), dúplex completo, y luego dejaré el interruptor en automático. Dado que tenemos una mezcla de velocidades tanto en servidores como en estaciones de trabajo, prefiero dejar los interruptores en automático y dejar que se adapten al punto final.

He tenido algunos problemas con la negociación automática en una configuración doméstica y el problema era el cableado, en particular los cables de red enrollados en un bucle con un diámetro demasiado pequeño o demasiado cerca de los cables de alimentación.

Pero creo que esas sugerencias son demasiado triviales para su configuración. ;)

Hace poco leí sobre esto en Network Warrior por Gary Donahue. Basado en este libro para que la negociación automática funcione correctamente AMBOS el conmutador y la NIC deben configurarse para negociación automática. Establecer la NIC en un modo de velocidad y dúplex específico y dejar el servidor en negociación automática no funcionará correctamente: la negociación automática es un protocolo y ambas partes deben hablarlo para que la configuración funcione correctamente.

Si desea establecer explícitamente la velocidad y el modo dúplex, debe hacerlo en ambos extremos de la conexión.

Cisco discute algunos casos en los que es posible que desee configurar manualmente la velocidad del puerto y el dúplex en lugar de usar autonegociación, al usar dispositivos de seguridad PIX / ASA: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/ products_tech_note09186a008009491c.shtml # solucionar problemas

Mi regla general es usar la negociación automática para todo excepto los enlaces de enrutador a menos que tenga un problema específico (como las tarjetas Broadcom recientes ... ¡BAH!)

Si tiene dos enrutadores vinculados a través de Ethernet, por ejemplo, configure manualmente la velocidad en ambos extremos.