Canal de fibra problemas de larga distancia

Necesito un par de ojos nuevos.

Estamos utilizando una línea de fibra óptica de 15 km a través de la cual se multiplexan el canal de fibra y 10 GbE (CWDM óptico pasivo). Para FC tenemos láseres de larga distancia adecuados hasta 40 km ( Skylane SFCxx0404F0D ). El multiplexor está limitado por los SFP que pueden hacer máx. Canal de fibra de 4 Gb. El interruptor FC es una serie Brocade 5000. Las longitudes de onda respectivas son 1550,1570,1590 y 1610nm para FC y 1530nm para 10GbE.

El problema es que las telas 4GbFC casi nunca están limpias. A veces son por un tiempo, incluso con mucho tráfico en ellos. Entonces, de repente pueden comenzar a producir errores (RX CRC, codificación RX, disparidad RX, ...) incluso con solo tráfico marginal en ellos. Adjunto algunos gráficos de error y tráfico. Los errores están actualmente en el orden de 50-100 errores por 5 minutos cuando se tiene tráfico de 1 Gb / s

Aquí se resume la potencia de salida de un puerto (recopilada mediante sfpshowdiferentes conmutadores)

Unidades del SITIO-A = uW (microwatt) SITIO-B
**********************************************
FAB1
SW1 TX 1234.3 RX 49.1 SW3 1550nm (ko)
      RX 95.2 TX 1175.6
FAB2
SW2 TX 1422.0 RX 104.6 SW4 1610nm (ok)
      RX 54.3 TX 1468.4      

Lo que me parece curioso en este momento es la asimetría en los niveles de potencia. Mientras SW2 transmite con 1422uW que SW4 recibe con 104uW, SW2 solo recibe la señal SW4 con una potencia original similar solo con 54uW.

Viceversa para SW1-3.

De todos modos, los SFP tienen una sensibilidad RX de hasta -18dBm (ca. 20uW), así que en cualquier caso debería estar bien ... Pero nada lo es.

El fabricante ha diagnosticado algunos SFP como mal funcionamiento (los de 1550 nm que se muestran arriba con "ko"). Los 1610nm aparentemente están bien, han sido probados usando un generador de tráfico. La línea arrendada también ha sido probada más de una vez. Todo está dentro de las tolerancias. Estoy esperando los reemplazos, pero por alguna razón no creo que mejore las cosas, ya que los aparentemente buenos tampoco producen errores CERO.

Anteriormente había equipo activo involucrado (algún tipo de retimer 4GFC) antes de poner la señal en la línea. No tengo idea de por qué. Ese equipo fue eliminado debido a los problemas, por lo que ahora solo tenemos:

• El láser de larga distancia en el interruptor,
• (nuevo) cable monomodo LC-SC de 10 m al mux (para cada tejido),
• la línea arrendada
• lo mismo pero invertido en el otro lado del enlace.

Aquí hay una configuración de puerto de Brocade portcfgshow(es así en ambos lados, obviamente)

Número de área: 0
Nivel de velocidad: 4G
Palabra de relleno (en activo) 0 (inactivo)
Palabra de relleno (actual) 0 (inactivo)
AL_PA Offset 13: OFF
Puerto troncal activado
LS de larga distancia
VC Link Init OFF
Distancia deseada 32 Km
Buffers reservados 70
Bloqueado L_Port OFF
Bloqueado G_Port OFF
Desactivado E_Port OFF
Bloqueado E_Port OFF
ISL R_RDY Modo OFF
RSCN suprimido apagado
Desactivar persistente APAGADO
LOS TOV habilitado OFF
Capacidad NPIV activada
QOS E_Port OFF
Puerto Auto Disable: OFF
Límite de velocidad desactivado
Puerto EX desactivado
Puerto espejo apagado
Recuperación de crédito activada
F_Port Buffers OFF
Retraso de falla: 0 (R_A_TOV)
NPIV Límite PP: 126
Modo CSCTL: APAGADO

Forzar los enlaces a 2GbFC no produce errores, pero compramos 4GbFC y queremos 4GbFC.

Ya no sé dónde mirar. ¿Alguna idea de qué probar a continuación o cómo proceder?

Si no podemos hacer que 4GbFC funcione de manera confiable, me pregunto qué hacen las personas que trabajan con 8 o 16 ... No asumo que "algunos errores aquí y allá" son aceptables.

Ah, y por cierto, estamos en contacto con todos los fabricantes (conmutador FC, MUX, SFP, ...) Excepto para cambiar los SFP (algunos se han cambiado antes), nadie tiene ni idea. Brocade SAN Health dice que la tela está bien. MUX, bueno, es pasivo, es solo un prisma, la naturaleza en su mejor momento.

¿Alguna toma en la oscuridad?

@ Chopper3: Esta es la segunda generación de Brocades que exhiben el problema. Antes teníamos 5000, ahora tenemos 5100. Al principio, cuando todavía teníamos el MUX activo, alquilamos un láser de larga distancia una vez para ponerlo directamente en el interruptor y hacer pruebas durante un día, durante ese día, por supuesto, estaba limpio. Pero como dije, a veces está limpio así como así. Y a veces no lo es. Los conmutadores alternativos significarían reconstruir toda la SAN con aquellos solo para probar. SFP alternativos, bueno, son difíciles de conseguir así como así.

@longneck: La línea está alquilada. Es una fibra oscura (monomodo 9um), por lo que no hay nadie más en ella. Claro que hay empalmes. No puedo ir a mirar, pero tengo que confiar en que se hayan hecho correctamente. Como dije, la línea ha sido verificada y verificada nuevamente (usando un reflectómetro óptico en el dominio del tiempo). Obviamente, no tiene todo este equipo usted mismo porque es demasiado costoso.

@mdpc: ¿Cuál sería el tipo de cable "incorrecto" según usted? Hasta el cambio, todo es monomodo, sí. Los conectores son los correctos también. Sí, sé que hay los verdes donde la fibra se corta en un cierto ángulo, etc. Pero tenemos los correctos para todo lo que sé.

Hemos tenido dos fabric (= 2x2 switches) con Brocade 5100s con FabricOS 6.4.1 y dos fabric (otros 2x4 switches) en FabricOS 7.0.2.

En los ISL de larga distancia (uno en cada estructura) resultó que con FOS 6.4.1 configurarlo a larga distancia emite advertencias sobre la configuración VC Init y, en consecuencia, la palabra de relleno. Pero esas son solo advertencias. FOS 7.0.2 requiere que haga modificaciones a VCI y la palabra de relleno para enlaces de larga distancia.

La configuración de FOS 6.4.1 a la configuración LS (distancia estática de larga distancia) con VCI incorrecta y la configuración de la palabra de relleno hizo que todo el tejido no funcionara (atascado en un bucle SCN, use fabriclog -spara ver, no lo ve en ningún otro lugar, no hay error de puerto contadores o cualquier cosa en aumento).

Actualmente le doy una paliza a la estructura con la IMHO más correcta y parece funcionar bien, mientras que la otra sin mucho tráfico todavía tiene errores aquí y allá.

En breve:

• Hemos eliminado la parte activa del MUX (el retimer FC).
• Estamos colocando los SFP de larga distancia en el equipo final ellos mismos.
• Solo para asegurarnos de que compramos nuevos cables monomodo para conectar el equipo final a la parte pasiva restante del MUX.
• Ahora estamos probando varias configuraciones de larga distancia.

Es casi magia negra. Todo lo que sucede es principalmente empírico, nadie parece tener idea de cuáles son las razones exactas para hacer algo. ("Hemos intentado esto, y no funcionó, luego lo intentamos y funcionó, así que nos quedamos con eso". Pero nadie parece saber realmente por qué).

Te mantendré informado.

Tenemos los nuevos láseres para una de las telas en garantía. Es ultra limpio incluso con 4GbFC.

Transmiten con aproximadamente 2 mW (3dBm), mientras que los otros solo tienen 1.5mW (1.5dBm), aunque eso debería ser suficiente.

La otra tela (donde los láseres aparentemente están bien) todavía produce uno o dos CCR con poca frecuencia.

El uso sfpshowdel SFP que produce los errores RX reales muestra

Estado / Ctrl: 0x82
Indicadores de alarma [0,1] = 0x5, 0x40
Avisar banderas [0,1] = 0x5, 0x40

Ahora tendré que averiguar qué significa eso. No estoy seguro si estaba allí antes.

Bueno, primero aclararé mi cabeza con una semana de vacaciones. 8-)

Ok, supongo que necesito publicar una respuesta. En una palabra es: insistir .

El problema no se resuelve al 100% a mi gusto, ya que todavía tenemos una estructura con 1 (uno) error CRC esporádicamente. El otro está limpio. Pero puedo vivir con eso.

En cualquier caso, no continuaremos usando las unidades CWDM durante mucho tiempo, sino que cambiaremos a un multiplexor DWDM pasivo el próximo año, ya que nuestra infraestructura cambiará mucho. Aparentemente, los láseres DWDM son menos costosos que los CWDM también. Ah, ya veremos y tal vez tendré muchos problemas para preguntarte :-)

Actualice No a lo anterior, compramos CWDM nuevamente, y es realmente menos costoso. AFAICS para ciertas aplicaciones, sin embargo, se tienen que ir DWDM porque no hay láseres CWDM para ello. Finalmente, tratamos de acercarnos lo más posible al fabricante y todo llegó a aproximadamente 1/5 del precio en comparación con la compra de un distribuidor o incluso un integrador.

Entonces puedo concluir, si compró una solución que no funciona como se esperaba: insista. En el aspecto técnico hicimos dos cosas

• eliminar la parte activa del MUX (no puedo decir que me arrepienta de eso, pero tampoco estoy seguro de si finalmente fue otra fuente de error o no)
• hacer que las SFP se verifiquen a fondo

(Y, por supuesto, todos los diagnósticos estándar, cambiar una cosa a la vez, ver qué sucede, etc., no es necesario que le diga eso. Así que verificamos cada línea y cable, etc., desafortunadamente a nuestro costo).

En este caso, llevó mucho tiempo insistir, pero finalmente llegamos al nivel en que el propio fabricante ahorró algunas personas y algunos equipos para realizar las comprobaciones que ayudaron. Y, por supuesto, hicimos que el integrador pagara eso, ya que nuestro hardware está en mantenimiento. Así que esto fue tanto un desafío comercial como técnico.

PD. Ah, y las banderas que mencioné en mi última actualización no indicaron nada malo, pero no recuerdo qué significaban exactamente. Cuando encuentre la declaración, actualizaré la respuesta para completarla.

Al final, las banderas significaban algo malo después de todo. Sin embargo, aparentemente no es seguro de qué lado del enlace es la causa de los errores. Entonces ese par tiene que ser cambiado también.

Ah, y BTW, los transceptores DWDM de 8GbFC son solo más baratos en comparación con CWDM 8G ;-) La forma más económica de hacerlo es 4GbFC en CWDM y luego usar el enlace ISL (si tiene la licencia)