Vraag Lange-afstands-problemen met Fibre Channel


Ik heb een nieuw paar ogen nodig.

We gebruiken een 15 km glasvezellijn waar fibrechannel en 10GbE gemultiplext is (passieve optische CWDM). Voor FC hebben we langeafstandlasers geschikt tot 40 km (Skylane SFCxx0404F0D). De multiplexer wordt beperkt door de SFP's die maximaal kunnen werken. 4Gb fibrechannel. De FC-schakelaar is een Brocade 5000-serie. De respectievelijke golflengten zijn 1550,1570,1590 en 1610 nm voor FC en 1530 nm voor 10 GbE.

Het probleem is dat de 4GbFC-stoffen bijna nooit schoon zijn. Soms zijn ze voor een tijdje zelfs met veel verkeer op hen. Dan kunnen ze plotseling fouten gaan produceren (RX CRC, RX-codering, RX-ongelijkheid, ...) zelfs met slechts marginaal verkeer op hen. Ik voeg een aantal fout- en verkeersgrafieken toe. Fouten zijn momenteel in de orde van 50 - 100 fouten per 5 minuten bij 1Gb / s-verkeer.


Optiek

Hier is de vermogenoutput van een samengevatte poort (verzameld met sfpshow op verschillende schakelaars)

SITE-A-eenheden = 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

Wat ik op dit punt nieuwsgierig vind, is de asymmetrie in de vermogensniveaus. Terwijl SW2 verzendt met 1422uW die SW4 ontvangt met 104uW, ontvangt SW2 alleen het SW4-signaal met een vergelijkbaar origineel vermogen alleen met 54uW.

Vice versa voor SW1-3.

In ieder geval hebben de SFP's een RX-gevoeligheid tot -18 dBm (ca. 20uW), dus het zou in elk geval goed moeten zijn ... Maar niets is.

Sommige SFP's zijn gediagnosticeerd als defect door de fabrikant (de 1550nm exemplaren die hierboven zijn weergegeven met "ko"). De 1610nm exemplaren zijn blijkbaar in orde, ze zijn getest met behulp van een verkeersgenerator. De huurlijn is ook meer dan eens getest. Alles is binnen toleranties. Ik wacht op de vervangingen, maar om de een of andere reden geloof ik niet dat het dingen beter zal maken, omdat de schijnbaar goede ook geen ZERO-fouten produceren.

Eerder was er actieve apparatuur bij betrokken (een soort van 4GFC-retimer) voordat het signaal op de lijn werd gezet. Geen idee waarom. Die apparatuur is geëlimineerd vanwege de problemen, dus we hebben nu alleen nog:

  • de laser op lange afstand in de schakelaar,
  • (nieuwe) 10 m LC-SC monomodekabel naar de mux (voor elke stof),
  • de huurlijn,
  • hetzelfde, maar omgekeerd aan de andere kant van de link.


FC schakelt

Hier is een poortconfiguratie van de Brocade portcfgshow (zo is het aan beide kanten, uiteraard)

Oppervlakte nummer: 0
Snelheidsniveau: 4G
Woord opvullen (actief) 0 (Idle-Idle)
Fill Word (Current) 0 (Idle-Idle)
AL_PA Offset 13: UIT
Trunk Port ON
Lange afstand LS
VC Link Init OFF
Gewenst Afstand 32 Km
Gereserveerde buffers 70
L_Port OFF vergrendeld
G_Port OFF vergrendeld
Uitgeschakeld E_poort UIT
Vergrendeld E_Port UIT
ISL R_RDY modus UIT
RSCN onderdrukt UIT
Persistent Uitschakelen UIT
LOS TOV schakelt UIT in
NPIV-mogelijkheid AAN
QOS E_Port UIT
Poort automatisch uitschakelen: UIT
Snelheidslimiet UIT
EX-poort UIT
Spiegelpoort UIT
Credit Recovery ON
F_Portbuffers UIT
Foutvertraging: 0 (R_A_TOV)
NPIV PP-limiet: 126
CSCTL-modus: UIT

Het dwingen van de links naar 2GbFC levert geen fouten op, maar we hebben 4GbFC gekocht en we willen 4GbFC.

error and traffic graphs

Ik weet niet waar ik moet kijken. Om het even welke ideeën wat om daarna te proberen of hoe te te werk te gaan?

Als we 4GbFC niet betrouwbaar kunnen laten werken, vraag ik me af wat de mensen die met 8 of 16 werken doen ... ik neem niet aan dat "een paar fouten hier en daar" acceptabel zijn.

Oh en trouwens, we hebben contact met iedereen van de fabrikanten (FC-switch, MUX, SFP's, ...) Behalve dat de SFP's moeten worden gewijzigd (sommige zijn al eerder gewijzigd) heeft niemand een idee. Brocade SAN Health zegt dat de stof in orde is. MUX, wel, het is passief, het is maar een prisma, de natuur op zijn best.

Alle opnamen in het donker?


 APPENDIX: Antwoorden op uw vragen

@ Chopper3: Dit is de tweede generatie van Brocades die het probleem vertoont. Voordat we 5000's hadden, hebben we nu 5100's. In het begin, toen we nog steeds de actieve MUX hadden, huurden we een laser met een lange afstand om hem direct in de schakelaar te plaatsen om tests voor een dag uit te voeren, tijdens die dag was hij natuurlijk schoon. Maar zoals ik al zei, soms is het net zo schoon. En soms is het dat niet. Alternatieve schakelaars zouden betekenen dat het hele SAN opnieuw moet worden opgebouwd met die alleen om te testen. Alternatieve SFP's, nou ze zijn moeilijk om zomaar voorbij te komen.

@lange nek: De lijn wordt verhuurd. Het is een donkere vezel (9um monomode) dus er is niemand anders op. Natuurlijk zijn er lassen. Ik kan niet gaan kijken, maar ik moet erop vertrouwen dat ze correct zijn gedaan. Zoals ik al zei, de lijn is gecontroleerd en opnieuw gecontroleerd (met behulp van een optische tijd-domein reflectometer). Vanzelfsprekend heb je niet al deze apparatuur zelf omdat het veel te duur is.

@mdpc: Wat zou volgens jou het "verkeerde" type kabel zijn? Tot aan de switch is alles monomode, ja. De connectoren zijn ook de juiste. Ja, ik weet dat er groene zijn waarbij de vezel in een bepaalde hoek wordt afgesneden enz. Maar we hebben de juiste voor alles wat ik weet.


 Voortgangsrapport # 1

We hebben twee stoffen (= 2x2 switches) met Brocade 5100s met FabricOS 6.4.1 en twee stoffen (nog eens 2x4 switches) op FabricOS 7.0.2.

Op ISL's met een lange afstand (één in elke stof) bleek dat met FOS 6.4.1 het instellen op lange afstand waarschuwingen opleverde over de VC Init-instelling en bijgevolg het vulwoord. Maar dat zijn slechts waarschuwingen. FOS 7.0.2 vereist je moet aanpassingen doen aan VCI en het sluitwoord voor interlokale links.

Het instellen van FOS 6.4.1 op de LS (lange afstand statische afstand) instelling met verkeerde VCI en fillword instelling maakte de hele fabric inoperational (zit vast in een SCN-lus, gebruik fabriclog -s om te zien, zie je het nergens anders, geen poortfouttellers of iets dat toeneemt).

Momenteel geef ik de enige structuur met de IMHO correctere instellingen een pak slaag en lijkt het goed te doen, terwijl de andere zonder veel verkeer nog steeds hier en daar fouten heeft.

progress1

Kortom:

  • We hebben het actieve deel van de MUX geëlimineerd (de FC-retimer).
  • We plaatsen de SFP's voor lange afstanden zelf in de eindapparatuur.
  • Om zeker te zijn hebben we nieuwe monomodekabels gekocht om de eindapparatuur aan te sluiten op het overgebleven passieve deel van de MUX.
  • We proberen nu verschillende interlokale configs uit.

Het is bijna zwarte magie. Alles wat er gebeurt is meestal empirisch, niemand lijkt een idee te hebben wat de exacte redenen zijn om iets te doen. ("We hebben dit geprobeerd, en het werkte niet, daarna hebben we dat geprobeerd en het werkte, dus dat hielden we vol." Maar niemand lijkt echt te weten waarom.)

Ik hou je op de hoogte.


 Voortgangsrapport # 2

We hebben de nieuwe lasers voor een van de stoffen op garantie. Het is ultraschoon, zelfs op 4GbFC.

Ze zenden uit met ongeveer 2 mW (3dBm) terwijl de anderen slechts 1,5 mW (1,5 dBm) zijn, hoewel dat eigenlijk voldoende zou moeten zijn.

Het andere weefsel (waar de lasers blijkbaar in orde zijn) produceert nog steeds maar één of twee CRC's.

Gebruik makend van sfpshow de SFP die de werkelijke RX-fouten produceert, wordt weergegeven

Status / Ctrl: 0x82
Alarmvlaggen [0,1] = 0x5, 0x40
Waarschuw vlaggen [0,1] = 0x5, 0x40

Nu zal ik moeten uitvinden wat dat betekent. Niet zeker of het er eerder was.

Wel zal ik eerst mijn hoofd opruimen met een week vakantie. 8-)


52
2017-08-26 22:02


oorsprong


Allereerst geweldige vraag, waar deze site precies voor bedoeld is, goed gedaan. Ten tweede heeft u toegang tot alternatieve switches / SFP's - in het ideale geval een ander merk / model dat u zou kunnen inruilen om te testen? - Chopper3
Fantastische update, ga zo door met het goede werk, ik wou dat ik wat suggesties of advies had, maar je bent op de goede weg, leuk om een ​​nieuwe gebruiker op SF te vinden die hun dingen weet :) - Chopper3
Zijn er consistenties in de tijd of de duur van de fouten? Vallen ze altijd op N uur? Doen ze altijd X minuten mee? Kun je ze correleren met het weer, nabijgelegen sportevenementen of een ander fenomeen? Intermitterende problemen zijn de moeilijkste bugs om te pletten, en ik begin ze meestal aan te vallen door de tijden en tijdsduren weer te geven die ze op een whiteboard hebben. Hopelijk ontstaan ​​er patronen die met elkaar in verband kunnen worden gebracht ander fenomeen. - dotancohen
Volgt u ze op een whiteboard, zichtbaar voor iedereen? Ik zal niet drukken, maar ik beveel het ten zeerste aan. Zoals je al zei, heb je een nieuw paar ogen nodig en misschien ziet iemand in je organisatie het patroon tevoorschijn komen uit de tijd / duur en niet noodzakelijkerwijs van de symptomen. - dotancohen
Hallo Marki. Ik ben niet helemaal bekend met waar je het over hebt, maar bij je laatste update lijkt het probleem opgelost door de vervangende SFP's? Als dat zo is, is het waarschijnlijk een goed idee om dit als een antwoord te plaatsen en een nieuwe vraag te stellen als u nog meer problemen ondervindt. - Mark Henderson♦


antwoorden:


Ok, ik denk dat ik een antwoord moet plaatsen. In één woord is het: aandringen.

Het probleem is niet 100% naar mijn smaak opgelost, omdat we nog steeds sporadisch één weefsel met 1 (één) CRC-fout hebben. De andere is schoon. Maar daar kan ik mee leven.

In elk geval zullen we de CWDM-units niet lang blijven gebruiken, maar eerder overstappen op een passieve DWDM-multiplexer volgend jaar, omdat onze infrastructuur veel zal veranderen. Blijkbaar zijn DWDM-lasers ook goedkoper dan de CWDM-lasers. Oh we zullen het zien en misschien heb ik veel problemen om het je te vragen :-)


Bijwerken Nee, we hebben CWDM opnieuw gekocht en het is echt minder duur. AFAICS voor bepaalde toepassingen echter, u hebben om DWDM te gebruiken omdat er geen CWDM-lasers voor zijn. Uiteindelijk probeerden we zo dicht mogelijk bij de fabrikant te komen en het geheel kwam op ongeveer 1/5 van de prijs in vergelijking met kopen bij een distributeur of zelfs een integrator.


Dus ik kan concluderen, als je een oplossing hebt gekocht die niet werkt zoals verwacht: eis. Op het technische vlak hebben we twee dingen gedaan

  • verwijder het actieve deel van de MUX (kan niet zeggen dat ik er spijt van heb, maar weet ook niet of dat uiteindelijk een andere bron van fouten was of niet)
  • laat de SFP's grondig controleren

(En natuurlijk alle standaard diagnostiek, één ding per keer veranderen, kijken wat er gebeurt enz., Dat hoef je niet te vertellen. Dus hebben we ook elke lijn en kabel enz. Gecontroleerd, helaas op onze kosten.)

In dit geval duurde het lang, maar uiteindelijk kwamen we op het niveau waarop de fabrikant zelf een paar mensen en wat apparatuur spaarde om de controles uit te voeren die hielpen. En natuurlijk hadden we de integrator die betalen, omdat onze hardware in onderhoud is. Dus dit was evenzeer een commerciële uitdaging als een technische uitdaging.

PS. Oh, de vlaggen die ik in mijn vorige update noemde, duidden niet op iets slechts, maar ik weet niet meer wat ze precies betekenden. Als ik de verklaring vind, zal ik het antwoord voor de volledigheid bijwerken.


Uiteindelijk betekenden de vlaggen toch iets slechts. Blijkbaar is het echter niet zeker welke kant van de link de oorzaak van de fouten is. Dus dat paar moet ook worden veranderd.

Oh en tussen haakjes, 8GbFC DWDM transceivers zijn alleen goedkoper in vergelijking met 8G CWDM ;-) De goedkoopste manier om te gaan is 4GbFC op CWDM en dan ISL trunking te gebruiken (als je de licentie hebt)


4
2017-11-02 20:02



Ik zag dit niet toen het werd gevraagd, helaas. Ik kan je niet met zekerheid zeggen dat dit zou helpen, maar als je niet-gebruikte vullingen gebruikt, stuur je veel licht. Dit betekent dat elk ongebruikt frame veel kracht trekt en veel warmte genereert op de SFP, denk ik. Het wijzigen van het trefwoord in een andere modus (ik gebruik modus 3, maar ik heb een andere schakelaar en SFP) kan u toestaan ​​meer doorvoer te genereren met minder fouten. - Basil
@Basil Ik wist dat het gebruik van het juiste vulwoord een probleem was bij de woordsynchronisatie bij 8GFC, maar ik heb er op deze manier over nagedacht ... - Marki
Het wordt aanbevolen elke keer dat je het kunt gebruiken - voor zover ik weet is het een kwestie van hoeveel interferentie een inactief frame veroorzaakt dat de SFP veroorzaakt. - Basil