Les malheurs du canal à fibres optiques sur les longues distances

J'ai besoin d'un regard neuf.

Nous utilisons une ligne de fibres optiques de 15 km sur laquelle les canaux de fibres et le 10GbE sont multiplexés (CWDM optique passif). Pour le FC, nous disposons de lasers longue distance qui conviennent jusqu'à 40 km ( Skylane SFCxx0404F0D ). Le multiplexeur est limité par les SFPs qui peuvent faire max. 4Gb fibrechannel. Le commutateur FC est un Brocade série 5000. Les longueurs d'onde respectives sont 1550, 1570, 1590 et 1610nm pour FC et 1530nm pour 10GbE.

Le problème est que les tissus 4GbFC ne sont presque jamais propres. Parfois, ils le sont pendant un certain temps, même s'ils sont très sollicités. Ensuite, elles peuvent soudainement commencer à produire des erreurs (RX CRC, RX encoding, RX disparity, ...) même avec un trafic marginal. Je joins quelques graphiques d'erreurs et de trafic. Les erreurs sont actuellement de l'ordre de 50-100 erreurs par 5 minutes avec un trafic de 1Gb/s.

Optique

Voici la puissance de sortie d'un port résumée (recueillie à l'aide de sfpshow sur des commutateurs différents)

SITE-A      units=uW (microwatt)    SITE-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      

Ce que je trouve curieux à ce stade, c'est l'asymétrie des niveaux de puissance. Alors que SW2 émet avec 1422uW et que SW4 reçoit avec 104uW, SW2 ne reçoit le signal de SW4 avec la même puissance d'origine qu'avec 54uW.

Vice versa pour SW1-3.

Quoi qu'il en soit, les SFP ont une sensibilité RX allant jusqu'à -18dBm (environ 20uW), donc dans tous les cas, ça devrait aller... Mais ce n'est pas le cas.

Certains SFP ont été diagnostiqués comme étant défectueux par le fabricant (les SFP 1550nm illustrés ci-dessus avec "ko"). Les SFPs 1610nm sont apparemment en bon état, ils ont été testés en utilisant un générateur de trafic. La ligne louée a également été testée plus d'une fois. Tout est dans les tolérances. J'attends les remplacements, mais pour une raison ou une autre, je ne pense pas que cela améliorera les choses, car ceux qui sont apparemment bons ne produisent pas non plus ZERO erreur.

Auparavant, un équipement actif était impliqué (une sorte de réamorceur 4GFC) avant de mettre le signal sur la ligne. On ne sait pas pourquoi. Cet équipement a été supprimé en raison des problèmes rencontrés, de sorte que nous ne disposons plus que de.. :

• le laser longue distance dans le commutateur,
• (nouveau) 10m de câble monomode LC-SC vers le mux (pour chaque tissu),
• la ligne louée,
• la même chose mais inversée de l'autre côté du lien.

Commutateurs FC

Voici la configuration d'un port du Brocade portcfgshow (c'est comme ça des deux côtés, évidemment)

Area Number:              0
Speed Level:              4G
Fill Word(On Active)      0(Idle-Idle)
Fill Word(Current)        0(Idle-Idle)
AL\_PA Offset 13:          OFF
Trunk Port                ON
Long Distance             LS
VC Link Init              OFF
Desired Distance          32 Km
Reserved Buffers          70
Locked L\_Port             OFF
Locked G\_Port             OFF
Disabled E\_Port           OFF
Locked E\_Port             OFF
ISL R\_RDY Mode            OFF
RSCN Suppressed           OFF
Persistent Disable        OFF
LOS TOV enable            OFF
NPIV capability           ON
QOS E\_Port                OFF
Port Auto Disable:        OFF
Rate Limit                OFF
EX Port                   OFF
Mirror Port               OFF
Credit Recovery           ON
F\_Port Buffers            OFF
Fault Delay:              0(R\_A\_TOV)
NPIV PP Limit:            126
CSCTL mode:               OFF

Forcer les liens à 2GbFC ne produit aucune erreur, mais nous avons acheté 4GbFC et nous voulons 4GbFC.

Je ne sais plus où chercher. Des idées sur ce qu'il faut essayer ensuite ou sur la façon de procéder ?

Si nous ne sommes pas capables de faire fonctionner 4GbFC de manière fiable, je me demande ce que font les gens qui travaillent avec 8 ou 16... Je ne pense pas que "quelques erreurs ici et là" soient acceptables.

Oh et BTW nous sommes en contact avec tous les fabricants (switch FC, MUX, SFPs, ...) A l'exception des SFPs à changer (certains ont déjà été changés) personne n'a la moindre idée. Brocade SAN Health dit que le tissu est correct. Le MUX, eh bien, il est passif, ce n'est qu'un prisme, la nature dans ce qu'elle a de meilleur.

Des coups de feu dans l'obscurité ?

ANNEXE : Réponses à vos questions

@Chopper3 : C'est la deuxième génération de Brocades qui présente ce problème. Avant nous avions des 5000, maintenant nous avons des 5100. Au début, lorsque nous avions encore le MUX actif, nous avons loué une fois un laser longue distance pour le mettre dans le commutateur directement afin de faire des tests pendant une journée, pendant cette journée, bien sûr, il était propre. Mais comme je l'ai dit, parfois c'est propre juste comme ça. Et parfois, ce n'est pas le cas. Des commutateurs alternatifs signifieraient qu'il faudrait reconstruire tout le SAN avec ces commutateurs uniquement pour les tester. Les SFP alternatifs sont difficiles à trouver comme ça.

@longneck : La ligne est louée. Il s'agit d'une fibre noire (monomode 9um), il n'y a donc personne d'autre dessus. Il est certain qu'il y a des épissures. Je ne peux pas aller voir, mais je dois croire qu'elles ont été faites correctement. Comme je l'ai dit, la ligne a été vérifiée et revérifiée (à l'aide d'un réflectomètre optique à domaine temporel). Il est évident que vous ne disposez pas de tout cet équipement, car il est beaucoup trop coûteux.

@mdpc : Quel serait le "mauvais" type de câble selon vous ? Jusqu'à l'interrupteur, tout est monomode, oui. Les connecteurs sont également corrects. Oui, je sais qu'il y a des câbles verts où la fibre est coupée à un certain angle, etc. Mais nous avons les bons, pour autant que je sache.

Rapport d'avancement n° 1

Nous avons eu deux fabrics (=2x2 switches) avec Brocade 5100s avec FabricOS 6.4.1 et deux fabrics (un autre 2x4 switches) sur FabricOS 7.0.2.

Sur les ISL longue distance (un dans chaque tissu), il s'est avéré qu'avec FOS 6.4.1, le réglage sur longue distance émet des avertissements sur le réglage VC Init et, par conséquent, sur le mot de remplissage. Mais ce ne sont que des avertissements. FOS 7.0.2 exige de modifier le VCI et le mot de passe pour les liaisons longue distance.

La configuration de FOS 6.4.1 en LS (longue distance statique) avec un mauvais VCI et un mauvais mot de passe a rendu tout le tissu inopérant (coincé dans une boucle SCN, utilisez le bouton fabriclog -s Vous ne le voyez nulle part ailleurs, pas de compteurs d'erreurs de port ou quoi que ce soit d'autre qui augmente).

Actuellement, je donne du fil à retordre à l'un des tissus avec les paramètres IMHO plus corrects et il semble bien fonctionner, tandis que l'autre tissu sans beaucoup de trafic a encore des erreurs ici et là.

En bref :

• Nous avons éliminé la partie active du MUX (le réamorceur FC).
• Nous intégrons les SFP longue distance dans les équipements finaux eux-mêmes.
• Pour être sûrs, nous avons acheté de nouveaux câbles monomodes pour connecter l'équipement final à la partie passive restante du MUX.
• Nous sommes en train d'essayer plusieurs configurations longue distance.

C'est presque de la magie noire. Tout ce qui se passe est essentiellement empirique, personne ne semble avoir la moindre idée des raisons exactes de faire quelque chose. ("Nous avons essayé ceci, et cela n'a pas marché, puis nous avons essayé cela et cela a marché, donc nous avons continué avec cela.") Mais personne ne semble vraiment savoir pourquoi).

Je vous tiendrai au courant.

Rapport d'avancement n° 2

Nous avons obtenu les nouveaux lasers pour l'un des tissus sous garantie. C'est ultra propre, même sur du 4GbFC.

Ils émettent à environ 2mW (3dBm) alors que les autres n'émettent qu'à 1,5mW (1,5dBm), ce qui devrait suffire.

L'autre tissu (où les lasers sont apparemment en bon état) produit encore un ou deux CRC de manière peu fréquente.

Utilisation sfpshow le SFP produisant les erreurs RX réelles montre

Status/Ctrl: 0x82
Alarm flags\[0,1\] = 0x5, 0x40
Warn Flags\[0,1\] = 0x5, 0x40

Je vais maintenant devoir découvrir ce que cela signifie. Je ne sais pas si c'était déjà le cas auparavant.

Je vais d'abord me changer les idées en prenant une semaine de vacances. 8-)