Errores de interfaz de Ethernet

La interfaz ethernet de mis servidores Ubuntu que se conecta al multiplexor del ISP muestra errores. Aquí está la instantánea:

          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

La interfaz de Ubuntu es capaz de dúplex completo, pero solo negocia una conexión semidúplex. Cuando conecté un dispositivo diferente (un enrutador) a MUX, también mostró tales errores. El ancho de banda asignado es de 50 mbps, pero solo obtengo 20 mbps. El ISP es reacio a cambiar su dispositivo (parece un conmutador o hub de ethernet) en el MUX. Los ingenieros de ISP culpan de que sea culpa mía. Pero lo comprobé con más de 3 dispositivos, todos mostraron errores. Entonces, ¿hay alguna herramienta para Linux que pueda usar para investigar profundamente las causas de esos errores, o hay algo que pueda hacer para reconfigurar la interfaz de mi servidor para deshacerme de esos errores?

Es muy probable que tenga una falta de coincidencia dúplex debido a que el ISP codificó su lado a 100-Full, esencialmente deshabilitando la negociación automática en el ISP Ethernet PHY.

Con el ISP configurado en 100-Full y su lado restante en auto / auto (una corazonada, pero común), la negociación automática de su lado configurará la interfaz en 100-Half, un desajuste dúplex como el lado del ISP permanecerá 100 lleno.

Reparar

Puede solucionar el problema codificando su PHY de Ethernet a 100-Full, o específicamente a lo que sea que esté configurado el ISP. La mayoría de los ISP usan 100-Full.

Detalle adicional

Con el desajuste dúplex de 100-Full a 100-Half, el lado 100-Full desactiva CSMA / CD mientras que CSMA / CD permanece vigente en el lado 100-Half. El lado 100-Full transmite sin tener en cuenta si el medio es libre o no. El lado 100-Half realiza comprobaciones de CSMA / CD y retroceso según lo definido por CSMA / CD. Es por eso que solo puede alcanzar 20 Mb / s en lo que debería ser un circuito de Internet de 50 Mb / s . El retroceso de CSMA / CD debido a las colisiones de detección del lado 100-Half está limitando el rendimiento.

Al codificar la interfaz a 100-Full para que coincida con el ISP, ambas partes tendrán CSMA / CD deshabilitado, por lo tanto, la desactivación y la detección de colisiones se deshabilitarán y debería alcanzar números mucho más cercanos a su velocidad de datos del circuito de Internet de 50 Mb / s.

Historia

Muchos ISP codifican sus transferencias de PHY de Ethernet, ya que hubo un momento en que era mucho más confiable hacerlo. Cuando se lanzó el estándar Fast Ethernet original 802.3u de 100 Mb / s, se negoció automáticamente la velocidad y el dúplex estaba presente, pero no era obligatorio . No fue hasta el estándar 802.3z 1 Gb / s Gigabit Ethernet cuando el estándar requirió negociación automática .

Muchos ingenieros de redes tienen ideas erróneas sobre la negociación automática. El error más grande es que la negociación automática puede negociar adecuadamente la velocidad y el dúplex si solo un lado implementa la negociación automática. Esto es falso, como has visto.

La razón de esto probablemente se debe a lo siguiente: si un lado está codificado en 100-Full, el otro lado que ejecuta la negociación automática siempre parece descubrir la parte de 100 Mb / s. Lo mismo si un lado está codificado en 10-Full: el otro lado que ejecuta la negociación automática puede calcular la parte de 10 Mb / s. La capacidad de determinar la velocidad del enlace proviene de una característica llamada detección paralela que prueba la señal de capa física recibida en todas las velocidades de enlace compatibles localmente hasta que se encuentre una coincidencia. Sin embargo, la detección en paralelo solo funciona para la velocidad, no para la coincidencia dúplex. Esta es la razón por la cual pueden producirse desajustes dúplex, ya que una interfaz siempre volverá a semidúplex cuando no pueda determinar el otro lado a través de la negociación automática.

Plataforma improvisada

Hubo un tiempo en que hubo un soporte irregular para la negociación automática y causó tantos problemas como se pretendía resolver. Esa vez, en opinión de este ingeniero de redes, ha pasado. Si bien todavía existen problemas de negociación automática, la cantidad de problemas que he visto debido a que la negociación automática se configuró en los últimos 5 años eclipsa la cantidad de problemas que he visto debido a la desactivación de la negociación automática.

Nunca he tenido un ISP que no esté dispuesto a cambiar su transferencia de Ethernet a auto / auto cuando me lo pidan. Con la mayoría de los módems y pasarelas de cable y DSL, esto no es un problema. Es el NxT1 y los enrutadores CPE gestionados por fibra con transferencia Ethernet donde generalmente reside este problema. El problema es que un administrador de red tiene que preguntar en primer lugar.

Con un ISP de codificación rígida a 100-Full , han dado una obligación . Una obligación que debe ser documentada y continuada. La negociación automática es una tecnología que ahora es estable, lo ha sido durante años y se ocupa de este problema por nosotros. Como se mencionó anteriormente, la cantidad de problemas causados ​​por la negociación automática es muy superior a la cantidad de problemas que surgen debido a que se deshabilitó en 2011. La tecnología existe para resolver este problema, úsela. ¿Quizás deberíamos configurar manualmente los SYN de TCP iniciales, MSS y administrar también la Ventana de recepción para cada circuito virtual de TCP? Bromeo.

Despotricar