Alrededor de un 15% de pérdida de paquetes a través de una SFP+ de cobre S+RJ10 en una CRS518-16XS-2XQ mientras la ruta directa a 100G está limpia
Enviamos tráfico desde un servidor de laboratorio hacia una CRS518-16XS-2XQ por un uplink QSFP28 de 100G, y sale del switch por una S+RJ10 de cobre SFP+ de MikroTik hacia un host RJ45 simple de 1G. El lado receptor pierde una parte importante de los paquetes y no logro atribuirlo a nada evidente.
Montaje:
- MikroTik CRS518-16XS-2XQ, uplink QSFP28 de 100G desde la fuente de tráfico
- S+RJ10 de cobre SFP+ de MikroTik en una de las jaulas, dispositivo RJ45 de 1G en el extremo remoto
- captura corriendo en el host receptor
Lo que dice la captura:
100G QSFP28 uplink -> CRS518-16XS-2XQ -> S+RJ10 -> 1G RJ45 host
capture on the 1G host: ~15% of the packets never arrive
same source, direct 100G connection: nothing missing
switch CPU load: 1%Probado hasta ahora:
- conecté la misma fuente directamente a 100G, sin ninguna pérdida, así que el emisor en sí está bien
- bajé la carga de CPU del switch, ahora está en 1% y la pérdida sigue ocurriendo
- reasenté el S+RJ10 y cambié el latiguillo hacia el dispositivo de 1G
El módulo de cobre es mi principal sospechoso en este punto, pero el enlace está limpio y la interfaz no muestra ningún error. ¿Se sabe que el S+RJ10 se coma tráfico así, o debería mirar en otro lugar dentro del switch?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 5
400-500 Mbps de promedio con un emisor a ráfagas es toda la historia. Tu tráfico no está repartido de forma uniforme: las ráfagas cortas salen de la fuente a más de 1 Gbps, y todo lo que queda por encima de esa línea tiene que esperar en el búfer de salida del puerto hasta que el lado de 1G lo drene. Cuando el búfer se llena, el switch descarta. Eso es exactamente lo que te está diciendo el movimiento de rx-overflow, y por eso la conexión directa a 100G no muestra nada: ahí no hay ningún escalón de velocidad contra el que amortiguar.
El transceptor es inocente. Cualquier cosa en esa jaula, cobre o fibra, se comportaría igual, porque la pérdida ocurre en el escalón de 100G a 1G y no dentro del módulo.
Dos cosas por hacer. El arreglo real está en el emisor: regula su ritmo para que los paquetes se repartan de forma uniforme en vez de escribirse en ráfagas. En cuanto la fuente deje de producir ráfagas por encima de la tasa de salida, la pérdida desaparece.
En el switch puedes hacer que la situación del búfer sea menos hostil:
Eso da margen y deja que una ráfaga se sostenga más tiempo, pero no elimina la causa: si el emisor genera ráfagas lo bastante fuertes durante lo bastante tiempo, ningún tamaño de búfer te va a salvar. Sigue vigilando las estadísticas QoS del switch y los contadores de rx-overflow después del cambio, así puedes ver si sigues chocando con el techo o solo lo tocas de vez en cuando.
Vale la pena quedarse con la lección general: un puerto con el enlace limpio, sin errores y con un módulo sano, aun así puede perder un porcentaje de dos cifras de tráfico simplemente por un escalón de velocidad entre puertos.
Antes de culpar al módulo, mira lo que realmente dicen los contadores del puerto. Ejecuta
en el puerto de entrada de 100G y en la jaula donde está el S+RJ10, y fíjate específicamente en la línea de rx-overflow en vez de en los contadores habituales de errores rx/tx. Una SFP+ de cobre realmente rota se anuncia como errores FCS o un enlace que parpadea, no como un recorte ordenado del 15% de un flujo por lo demás sano.
Segunda pregunta: ¿cuál es la tasa promedio por esa ruta, y tienes alguna idea de los picos? Perder uno de cada siete paquetes con la CPU al 1% huele mucho más a que el puerto de salida se está quedando sin búfer que a un fallo del transceptor.
Contadores primero: sin errores en ninguno de los dos puertos, el enlace se mantiene arriba todo el tiempo y el módulo no reporta nada raro. rx-overflow es el único lugar donde los números se mueven en absoluto.
En cuanto a la tasa, la ruta promedia 400-500 Mbps, así que sobre el papel no está ni cerca de saturar el lado de 1G. No tengo medición de picos, pero el tráfico es a ráfagas por naturaleza: el emisor escribe un bloque y luego queda en silencio un rato. La CPU sigue al 1% mientras se pierden paquetes.
Fallo distinto, misma lección sobre confiar en los contadores más que en la intuición. Tuve una CRS354-48G-4S+2Q+RM en SwOS 2.18 con Rx FCS Errors creciendo de forma constante en ambos puertos QSFP+, y Rx MAC Errors a una tasa menor. Ambos puertos estaban a 40G full duplex con MTU 1500, y del otro lado había hosts ESXi con tarjetas Mellanox ConnectX-3 Pro CX324A.
La parte interesante: el lado de la NIC no reportaba absolutamente nada.
Limpio. Cambiar por cables conocidos como buenos no cambió nada, y los puertos SFP+ de 10G de la misma caja se mantuvieron libres de errores todo el tiempo. Nunca conseguí un diagnóstico real; pasar el switch de SwOS a RouterOS hizo que los contadores desaparecieran, lo cual cuento como ocultar el problema y no como resolverlo.
El método que sobrevivió: poner los contadores a cero, volver a leerlos tras un intervalo fijo y ver si los errores siguen el volumen de tráfico. En tu caso van a seguir las ráfagas, en el mío no siguieron nada útil, y esa diferencia por sí sola te dice de qué lado seguir cavando.
Una cosa a tener en cuenta mientras experimentas en ese puerto: no recurras a forzar velocidad y duplex como salida. El comportamiento documentado de los módulos de cobre de MikroTik, tanto S-RJ01 como S+RJ10, es que solo funcionan con la autonegociación activada; fija la tasa de forma estática y el enlace directamente no sube. La práctica lo contradice en parte, ya que algunos dueños de RB5009 y RB4011 reportan lo contrario y solo consiguieron estabilizar un S-RJ01 forzando 1G full duplex, así que es algo de «prueba ambas cosas en tu propio hardware» más que una regla. En cualquier caso es un desvío de tu problema real, que está del lado del búfer.
Otro detalle del S+RJ10 que conviene saber para más adelante: consume notablemente más energía que una óptica normal y se calienta, así que no se recomienda en un dispositivo de refrigeración pasiva sin ventilación extra. Si ese módulo alguna vez empieza a comportarse mal en un chasis caliente, la temperatura sería lo primero que revisaría.