Guai interurbani a fibra ottica

Ho bisogno di un nuovo paio di occhi.

Stiamo utilizzando una linea in fibra ottica di 15 km attraverso la quale il multiplo con fibrechannel e 10GbE (CWDM ottico passivo). Per FC abbiamo laser a lunga distanza adatti fino a 40 km ( Skylane SFCxx0404F0D ). Il multiplexer è limitato dagli SFP che possono fare max. Fibrechannel 4Gb. Lo switch FC è una serie 5000 di Brocade. Le rispettive lunghezze d'onda sono 1550,1570,1590 e 1610nm per FC e 1530nm per 10GbE.

Il problema è che i tessuti 4GbFC non sono quasi mai puliti. A volte sono per un po 'anche con molto traffico su di loro. Quindi potrebbero improvvisamente iniziare a produrre errori (CRC RX, codifica RX, disparità RX, ...) anche con solo traffico marginale su di essi. Allego alcuni grafici di errore e traffico. Gli errori sono attualmente nell'ordine di 50-100 errori ogni 5 minuti con traffico da 1Gb / s.

Ecco la potenza di una porta riepilogata (raccolta utilizzando sfpshowsu diversi switch)

Unità SITE-A = 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      

Ciò che trovo curioso a questo punto è l'asimmetria nei livelli di potenza. Mentre SW2 trasmette con 1422uW che SW4 riceve con 104uW, SW2 riceve solo il segnale SW4 con una potenza originale simile solo con 54uW.

Viceversa per SW1-3.

Comunque gli SFP hanno una sensibilità RX fino a -18dBm (circa 20uW), quindi in ogni caso dovrebbe andare bene ... Ma niente lo è.

Alcuni SFP sono stati diagnosticati come malfunzionanti dal produttore (quelli 1550nm indicati sopra con "ko"). I 1610nm apparentemente sono ok, sono stati testati usando un generatore di traffico. Anche la linea noleggiata è stata testata più di una volta. Tutto rientra nelle tolleranze. Sto aspettando i rimpiazzi, ma per qualche ragione non credo che migliorerà le cose in quanto anche quelli apparentemente buoni non producono errori ZERO.

In precedenza c'erano apparecchiature attive coinvolte (una sorta di retimer 4GFC) prima di mettere il segnale sulla linea. Non ho idea del perché. Quell'attrezzatura è stata eliminata a causa dei problemi, quindi ora abbiamo solo:

• il laser a lunga distanza nell'interruttore,
• (nuovo) cavo monomodale LC-SC da 10 m al mux (per ogni tessuto),
• la linea affittata,
• la stessa cosa ma invertita dall'altra parte del collegamento.

Ecco un port config dal Brocade portcfgshow(è così su entrambi i lati, ovviamente)

Area Numero: 0
Livello di velocità: 4G
Inserisci parola (attiva) 0 (inattiva)
Fill Word (Current) 0 (Idle-Idle)
AL_PA Offset 13: OFF
Porta trunk attivata
LS a lunga distanza
VC Link Init OFF
Distanza desiderata 32 Km
Buffer riservati 70
L_Port bloccato OFF
G_Port bloccato OFF
Disabilitato E_Port OFF
E_Port bloccato OFF
Modalità ISL R_RDY OFF
RSCN soppresso OFF
Disabilitazione persistente OFF
LOS TOV abilita OFF
Funzionalità NPIV ON
QOS E_Port OFF
Disabilitazione automatica porta: OFF
Limite tariffa OFF
Porta EX OFF
Porta specchio OFF
Recupero crediti ON
F_Port Buffers OFF
Ritardo guasto: 0 (R_A_TOV)
Limite PP NPIV: 126
Modalità CSCTL: OFF

Forzare i collegamenti a 2GbFC non produce errori, ma abbiamo acquistato 4GbFC e vogliamo 4GbFC.

Non so più dove cercare. Qualche idea su cosa provare dopo o come procedere?

Se non riusciamo a far funzionare in modo affidabile 4GbFC, mi chiedo cosa fanno le persone che lavorano con 8 o 16 ... Non presumo che "alcuni errori qua e là" siano accettabili.

Oh e BTW siamo in contatto con tutti i produttori (switch FC, MUX, SFP, ...) Tranne che per gli SFP da cambiare (alcuni sono stati cambiati prima) nessuno ha la minima idea. Brocade SAN Health afferma che il tessuto è ok. MUX, beh, è ​​passivo, è solo un prisma, la natura al suo meglio.

Qualche scatto al buio?

@ Chopper3: questa è la seconda generazione di broccati che presenta il problema. Prima avevamo 5000 anni, ora ne abbiamo 5100. All'inizio, quando avevamo ancora il MUX attivo, abbiamo noleggiato una volta un laser a lunga distanza per metterlo direttamente nello switch per fare test per un giorno, durante quel giorno ovviamente era pulito. Ma come ho detto, a volte è pulito proprio così. E a volte no. Switch alternativi significherebbe ricostruire l'intera SAN con quelli solo per testare. SFP alternativi, beh, sono difficili da trovare proprio così.

@longneck: la linea è in affitto. È una fibra scura (9um monomode) quindi non c'è nessun altro. Sicuro ci sono delle giunzioni. Non posso andare a guardare ma devo fidarmi che sono stati fatti correttamente. Come ho detto, la linea è stata controllata e ricontrollata (usando un riflettometro nel dominio del tempo ottico). Ovviamente non hai tutto questo equipaggiamento da solo perché è troppo costoso.

@mdpc: Quale sarebbe il tipo di cavo "sbagliato" secondo te? Fino allo switch tutto è monomodale, sì. Anche i connettori sono quelli corretti. Sì, so che ci sono quelli verdi in cui la fibra viene tagliata ad un certo angolo, ecc. Ma abbiamo quelli giusti per tutto quello che so.

Abbiamo avuto due fabric (= switch 2x2) con Brocade 5100s con FabricOS 6.4.1 e due fabric (altri switch 2x4) su FabricOS 7.0.2.

Sulle ISL a lunga distanza (una per ogni tessuto) si è scoperto che con FOS 6.4.1 impostandolo su lunga distanza viene emesso un avviso sull'impostazione VC Init e di conseguenza sulla parola di riempimento. Ma quelli sono solo avvertimenti. FOS 7.0.2 richiede di apportare modifiche a VCI e alla parola d'ordine per i collegamenti a lunga distanza.

Impostando FOS 6.4.1 sull'impostazione LS (distanza statica a lunga distanza) con VCI errato e l'impostazione fillword ha reso l'intero tessuto non operativo (bloccato in un loop SCN, usare fabriclog -sper vedere, non lo vedi da nessun'altra parte, nessun errore di porta contatori o qualsiasi cosa in aumento).

Attualmente sto battendo un tessuto con l'IMHO impostazioni più corrette e sembra andare bene, mentre l'altro senza molto traffico ha ancora errori qua e là.

In breve:

• Abbiamo eliminato la parte attiva del MUX (il retimer FC).
• Stiamo inserendo gli SFP a lunga distanza nelle apparecchiature stesse.
• Per essere sicuri, abbiamo acquistato nuovi cavi monomodali per collegare l'apparecchiatura terminale alla parte passiva rimanente del MUX.
• Ora stiamo provando diverse configurazioni di lunga distanza.

È quasi magia nera. Tutto ciò che accade è per lo più empirico, nessuno sembra avere la minima idea di quali siano i motivi esatti per fare qualcosa. ("Abbiamo provato questo, e non ha funzionato, poi l'abbiamo provato e ha funzionato, quindi ci siamo fermati." Ma nessuno sembra davvero sapere perché.)

Ti terrò aggiornato.

Abbiamo ottenuto i nuovi laser per uno dei tessuti in garanzia. È ultra pulito anche su 4GbFC.

Stanno trasmettendo con circa 2mW (3dBm) mentre gli altri sono solo a 1.5mW (1.5dBm) anche se questo dovrebbe essere abbastanza.

L'altro tessuto (dove apparentemente i laser sono ok) produce ancora raramente uno o due CRC.

sfpshowViene mostrato l' utilizzo dell'SFP che produce gli errori RX effettivi

Stato / Ctrl: 0x82
Flag di allarme [0,1] = 0x5, 0x40
Segnala flag [0,1] = 0x5, 0x40

Ora dovrò scoprire cosa significa. Non sono sicuro che fosse lì prima.

Bene, per prima cosa mi schiarirò la testa con una settimana di vacanza. 8-)

Ok, immagino di dover pubblicare una risposta. In una parola è: insistere .

Il problema non è stato risolto al 100% a mio piacimento, poiché abbiamo ancora un tessuto con 1 (uno) errore CRC sporadicamente. L'altro è pulito. Ma posso conviverci.

In ogni caso non continueremo a utilizzare le unità CWDM per molto tempo, ma passeremo piuttosto a un multiplexer DWDM passivo l'anno prossimo poiché la nostra infrastruttura cambierà molto. Apparentemente i laser DWDM sono meno costosi di quelli CWDM. Oh vedremo e forse avrò molti problemi da chiederti allora :-)

Aggiorna No a quanto sopra, abbiamo acquistato nuovamente CWDM ed è davvero meno costoso. AFAICS per alcune applicazioni, tuttavia, devi utilizzare DWDM perché non ci sono laser CWDM per questo. Alla fine abbiamo cercato di avvicinarci il più possibile al produttore e il tutto è arrivato a circa 1/5 del prezzo rispetto all'acquisto da un distributore o persino da un integratore.

Quindi posso concludere, se hai acquistato una soluzione che non funziona come previsto: insisti. Dal punto di vista tecnico abbiamo fatto due cose

• rimuovere la parte attiva del MUX (non posso dire che me ne pento, ma anche non sono sicuro che fosse finalmente un'altra fonte di errore o meno)
• far controllare accuratamente gli SFP

(E ovviamente tutta la diagnostica standard, cambia una cosa alla volta, vedi cosa succede ecc., Non c'è bisogno di dirtelo. Quindi abbiamo controllato anche ogni linea, cavo ecc., Purtroppo a nostre spese.)

In questo caso ci è voluto molto tempo per insistere, ma alla fine siamo arrivati ​​al livello in cui il produttore stesso ha risparmiato alcune persone e alcune attrezzature per eseguire i controlli che hanno aiutato. E, naturalmente, abbiamo pagato l'integratore, dato che il nostro hardware è in manutenzione. Quindi questa è stata una sfida tanto commerciale quanto tecnica.

PS. Oh, le bandiere che ho menzionato nel mio ultimo aggiornamento non indicavano nulla di negativo, ma non ricordo cosa significassero esattamente. Quando trovo la dichiarazione, aggiornerò la risposta per completezza.

Alla fine, le bandiere significavano qualcosa di brutto dopo tutto. Apparentemente, tuttavia, non è certo quale parte del collegamento sia la causa degli errori. Quindi anche quella coppia deve essere cambiata.

Oh e BTW, i ricetrasmettitori DWDM 8GbFC sono solo più economici rispetto a 8G CWDM ;-) Il modo più economico per andare è 4GbFC su CWDM e quindi utilizzare il trunking ISL (se si dispone della licenza)