90 votos

¿El hardware de la red debe ajustarse a velocidades "autonegociadas" o a velocidades fijas?

Nosotros recientemente tuvo un pequeño problema con la red donde varios servidores perderían intermitentemente la conectividad de la red de una manera bastante dolorosa de resolver (requería un reinicio duro). Esto ha estado sucediendo durante unas dos semanas, aparentemente al azar, en diferentes servidores. No hay un patrón particular que podamos discernir.

Tras investigar un poco, vimos que el conmutador informaba de 100 Mbps para el puerto problemático:



Esto se parece mucho a lo que ocurrió en el artículo de Joel Spolsky Cinco razones

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 switch puede utilizar para comunicarse (10, 100 o 1000 megabits/segundo). Puedes configurar la velocidad manualmente, o puedes dejar que el switch negocie automáticamente la velocidad más alta con la que ambas partes puedan trabajar. El conmutador que falló había sido configurado para autonegociar. Esto suele funcionar, pero no siempre, y la mañana del 10 de enero no lo hizo.

Ahora tenemos desactivar la autonegociación en nuestro hardware de red y configurarlo a una velocidad fija de 1000 Mbps (gigabit).

Mis preguntas a los que tienen más experiencia en redes de hardware de servidores:

  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 desactivar la autonegociación y establecer velocidades fijas al configurar la red?

0 votos

¿Has desactivado también la autonegociación en tus servidores y los has fijado en 1000/full?

22 votos

Esto es sólo yo, pero si me encontrara con tu problema me preguntaría por qué el switch y el servidor no están negociando la velocidad de mayor prioridad (1000/full). Eso me dice que algo está roto y al forzar el enlace a una determinada velocidad sólo estás encubriendo un problema.

0 votos

Hay algunas plataformas (en particular Solaris 9) que tienen problemas con la autonegociación en escenarios conocidos - sólo uso autoneg con cualquier cosa hecha en la última década, sin embargo

101voto

Xcalibur Puntos 111
  1. Todavía no he visto un problema con la autonegociación de las velocidades de la red que no esté causado por (a) un desajuste de la 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 se especifican manualmente las velocidades de los enlaces y la configuración dúplex, entonces es probable que se produzcan desajustes de velocidad. ¿Por qué? Porque es casi imposible documentar las diferentes conexiones entre los switches y los servidores y luego seguir esa documentación al hacer los cambios. La mayoría de los fallos que he visto se deben a 1(a) y sólo se llega a esa situación cuando se empieza a configurar manualmente la velocidad/dúplex.

Como se menciona en el Documentación de Cisco :

Si se desactiva la autonegociación, se ocultan las caídas del enlace y otros problemas de la capa física. Desactive la autonegociación sólo para los dispositivos finales, como las NIC Gigabit más antiguas que no admiten la autonegociación Gigabit. No desactive la autonegociación entre los conmutadores a menos que sea absolutamente necesario, ya que los problemas de la capa física pueden pasar desapercibidos y provocar bucles de árbol de expansión.

A menos que esté preparado para configurar un sistema de gestión de cambios en la red que requiera la verificación de la velocidad/dúplex (y no olvide el control de flujo) o esté dispuesto a lidiar con los desajustes ocasionales que se producen al especificar manualmente estos ajustes en todos los dispositivos de la red, entonces quédese con la configuración por defecto de auto/auto.

En el futuro, considere la posibilidad de supervisar los errores en los puertos del conmutador con MRTG para que puedas detectar estas cuestiones antes de que tengas un problema.

Editar: Veo que mucha gente hace referencia a fallos 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. ¿Tus NICs y switches tienen menos de 10 años? Si es así, esto no será un problema.

1 votos

Sí, estoy de acuerdo con cisco en que los ajustes entre conmutadores no deberían ser manuales. También diría que para los conmutadores de la capa de acceso de los ordenadores de sobremesa es preferible dejarlos en automático, ya que el hardware de los ordenadores de sobremesa siempre está cambiando.

1 votos

+1 - simplemente pon todo en auto-negociación y déjalo. La antigua especificación 802.3 solía ser una mierda con respecto a la auto-negación, desde el gigabit es mucho más clara.

0 votos

Ya usamos Cacti en todos los puertos, ¿hay algo que MRTG haga diferente?

23voto

Martin Geisler Puntos 144
  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 (por ejemplo, un rack de servidores) y no crees que vaya a haber cambios, es una buena idea configurar las velocidades y los dúplex manualmente. Siempre y cuando esté bien documentado para poder evitar futuros problemas.

EDITAR:

Sólo para aclarar, no estoy abogando por el uso de velocidades manuales en toda su red, yo diría que el 95% de las veces auto/auto es el camino a seguir. Sólo digo que he tenido problemas con el dúplex/la velocidad y que hay pequeñas partes de mi red (por ejemplo, uno de nuestros bastidores de servidores) que tienen en su mayoría configuraciones manuales. Operamos una LAN muy controlada con puertos no utilizados que se apagan y filtros MAC en la mayoría de los puertos, por lo que mantener un seguimiento de las velocidades no es muy difícil.

5 votos

He encontrado el mismo problema, pero tal vez sólo 1/100 servidores tendrán algún tipo de problemas de autonegociación. Por lo general, no se nota en las redes más pequeñas, pero lo suficiente como para ser molesto en los más grandes.

0 votos

+1 - Yo también he visto el problema de la negociación automática a lo largo de los años. El hecho de que el equipo haya estandarizado la desactivación de la autonegociación en todos los conmutadores ha eliminado este problema.

0 votos

Nada que añadir a esto, salvo que me hago eco de que he visto numerosos problemas. Si alguien más tiene información sobre por qué la autonegociación falla tan (relativamente) regularmente, me encantaría escucharlo.

15voto

Mridang Agarwalla Puntos 330

Creo que si la autonegociación funcionaba durante una hora al día o un mes y luego, por alguna razón, "pasa algo" que al poner el enlace a velocidad fija "se arregla", hay un problema que no se está resolviendo sino que se está eludiendo. Supongo que veo el ajuste del enlace a fijo como una solución temporal hasta que se corrija el verdadero problema.

0 votos

Es totalmente posible; ya hemos hecho un montón de otras soluciones de problemas para descartar cosas, pero me preocupaba que el equipo de Joel tuviera el mismo problema documentado en "Five Whys". Parece bastante extendido..

7 votos

Estoy de acuerdo en que el problema de la autonegociación ocurre "a menudo" pero en la mayoría de los casos después de haber funcionado durante un "tiempo". Eso es lo que me impulsa a querer investigar más a fondo en lugar de utilizar el enlace fijo como una "solución" Quiero decir ... si su coche que "funciona bien" empezar a funcionar mal a menos que se calienta durante 10 minutos, no se dice a sí mismo "Hey que está envejeciendo y ahora tiene que calentar durante 10 minutos" Usted lo llevaría a ser mirado en su primera oportunidad porque "algo está mal" que no era antes :)

15voto

Cory Dee Puntos 1527

Así que los pasos de solución de problemas (se supone que se detiene después de cada uno y esperar a que el problema vuelva a aparecer):

  1. Comprueba los registros del switch para ver si te dice por qué está usando 100M.
  2. Si todavía lo estás ejecutando, desactiva esa mierda de "balanceo de carga de Windows" tan malvada que Joel está impulsando todo el tiempo -- la forma en que funciona es rompiendo el caché del switch, forzándolo a procesar por software cada paquete. Tu switch está diseñado para reenviar paquetes por hardware, y sólo tiene la CPU necesaria para averiguar qué ruta física tiene que tomar un flujo de tráfico desconocido (entrada -> asic -> salida), y programar el hardware para hacerlo (léase: una calculadora tiene mejor CPU que tu switch, no hagas cosas estúpidas que hagan trabajar más a la CPU de tu switch). El balanceo de carga de Windows funciona haciendo que tu switch tome esa decisión y reinstale la caché del hardware para cada paquete. Puede que eso no arregle este problema en particular, pero me molesta de los podcasts... lo siento.
  3. Asegúrese de que la configuración coincide en ambos lados - parece que ha hecho eso
  4. Busca en Google los errores de autoneg en tu switch - a menos que lo hayas construido tú mismo, no eres el único que intenta ejecutar autoneg en lo que sea que estés usando
  5. Reemplace el cable, con Cat5e o mejor - idealmente un cable que usted sabe que funciona, como el que su estación de trabajo está conectado. No intentes usar Cat5, o alguna porquería que alguien haya hecho, usa uno que tenga los extremos moldeados reales de un paquete.
  6. Mover el puerto - Poner el servidor en un puerto diferente en el mismo conmutador
  7. Cambiar el NIC - utilizar un lote diferente pedido en un momento diferente

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

  1. Tendido de cables: tenga cuidado con las interferencias electromagnéticas de los cables de alimentación de CA, páselos por diferentes lados del bastidor.
  2. Enfriamiento - Asegúrate de que la temperatura ambiental no es de unos 90 grados y que tus tarjetas NIC no están entrando en una especie de modo "Dios mío, déjame sólo reenviar este paquete, por favor". He oído, pero no he visto, que los routers Cisco dejan de hacer fast-switching y reenvían los paquetes a través de la CPU cuando se sobrecalientan, por ejemplo.
  3. Sustituye el conmutador por algo que no apeste - comprueba cuánto ancho de banda están hablando tus hosts por segundo en conjunto, y luego mira la capacidad nominal del backplane de tu conmutador. 7 hosts de los 48 potenciales que transmiten 1.0G es suficiente para detener un Cisco 3750, por ejemplo. También hay que tener en cuenta muy cuidado con los vendedores de redes baratas: D-Link, Linksys, Dell, Intel y HP. Nadie que se tome las redes en serio utiliza a estos tipos, y no porque "nunca se haya despedido a nadie por utilizar Cisco", sino porque "la gente se acuerda de aquel conmutador de Intel al que le fallaron 20/48 puertos en 2 años" o del "yo solía utilizar ProCurve exclusivamente y me quejaba de lo malvado que era Cisco, hasta que realmente utilicé Cisco, momento en el que dejé de comprar nada menos". Cisco se considera un gama media proveedor de redes, así que ¿qué te dice eso de los tipos debajo de ¿Cisco...? :-)

Antecedentes/por qué mi respuesta es la más asombrosa: Trabajo como ingeniero de redes/sistemas en el sector financiero, y ésta es mi experiencia con nuestra pequeña red global (15 sucursales, 8 centros de datos):

Todos nuestros puertos LAN son 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 hablar por teléfono con alguien y que compruebe la configuración. En tres años, sólo he tenido un fallo en uno de nuestros puertos internos debido a un fallo de autoneg, y fue debido a un cable defectuoso; desapareció después de sustituir el cable.

Tuvimos muchos más problemas cuando los predecesores habían codificado 100/full en sus NICs, y no documentaron ese hecho. Reajustamos todo a automático/auto en la siguiente ventana de mantenimiento y no hemos tenido ningún problema con ellos desde entonces.

¿En el par de lugares en los que tenemos un traspaso de cobre desde un operador para nuestra WAN? Es de esperar que una conexión WAN/Internet de cobre sea una mierda todo el tiempo, en parte porque no tienes ni idea de lo que hay al otro lado. ¿Un antiguo conmutador Extreme que tiene un firmware defectuoso para autoneg pero que hace el etiquetado MPLS? ¿Un convertidor de medios de 5 dólares porque el dispositivo de borde Ciena de 200 mil dólares de su ISP es simplemente demasiado impresionante para proporcionar Ethernet sobre par trenzado? Decida de antemano cómo se va a manejar eso y cúmplalo, y luego espere que algún imbécil dentro del operador lo cambie a las 10 de la noche de un sábado porque la configuración acordada nunca fue documentada y ellos tienen alguna política que seguir.

En serio, sin embargo, consigue un traspaso de fibra de tu ISP.

2 votos

Acabo de leer esto - excelente respuesta.

0 votos

Excelente respuesta.

2 votos

Sólo para que la respuesta final esté aquí, en algún lugar, fueron los malos controladores de Broadcom. No pudimos encontrar ningún conjunto que funcionara. Cambiar a NICs de Intel lo arregló al 100%. blog.serverfault.com/2011/03/04/broadcom-die-mutha

14voto

Jason Antman Puntos 1378

La red de la que soy responsable (junto con otros compañeros) está formada por unos 40 servidores, más de 1.000 estaciones de trabajo (repartidas por un campus bastante grande) y unos 1.000 WAP también repartidos por una gran zona con equipos de red de distintos tipos y edades.

Como dijo dimitri.p, cuando algo deja de autonegociar de repente, suele ser una indicación de otro problema. Configurar el puerto manualmente es como poner una tirita a alguien que ha sido apuñalado en las tripas: puede que detenga la hemorragia, pero seguro que hay daños por debajo.

Mi lista de control habitual:

  • ¿Ha cambiado algo en la máquina? ¿Controladores? ¿configuraciones a nivel del SO o de la BIOS? ¿Quizás se desactivó el autoneg en el SO?
  • ¿has cambiado los cables de conexión, y verificado los recorridos de los cables (si se trata de un recorrido más largo que un bastidor)
  • ¿has comprobado si el puerto del switch está mal o falla?
  • ¿podría estar fallando el NIC?

Nosotros, por regla general, nunca desactivar el autoneg en los servidores (o cualquier otra cosa en el centro de datos) a menos que se trate de una situación en la que se hayan eliminado todas las demás causas posibles, hayamos movido los puertos de los conmutadores, hayamos cambiado los cables, hayamos probado la NIC, etc. y no haya otra opción. En ese caso, se documenta hasta la saciedad. Esto ocurre muy raramente, y normalmente con aparatos a los que no podemos acceder para comprobar la configuración de la BIOS y el SO.

En cambio, las estaciones de trabajo y los puntos de acceso son una historia diferente. El fallo del autoneg es un signo clásico de un mal tendido de cable, y muchas veces tenemos que ajustar manualmente la velocidad y el dúplex hasta que llega la temporada de verano de cables nuevos en las paredes.

0 votos

Hemos intercambiado cables y puertos repetidamente en un servidor "problemático", y hemos vuelto a utilizar los controladores de red originales (Server 2008 R2). También ocurre en varios servidores de idéntica configuración. Me resulta difícil conciliar el "¡nunca hagas esto!" y el "¡siempre haz esto!" en las respuestas a la misma pregunta.

0 votos

@Jeff: Al estar familiarizado con la pregunta que usted y su equipo publicaron originalmente ( serverfault.com/questions/104791 ) Me interesa saber si el problema sigue el puerto del switch o el puerto NIC en el ordenador(es) servidor(es) problemático(s). ¿Cuál es la marca / modelo de NIC / chipset, de todos modos?

1 votos

@Jeff - Algunas respuestas no son binarias :) Es Hazlo cuando tengas que hacerlo, hasta que tengas la oportunidad de averiguar cuál es el problema.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: