Неприємності на довгих відстанях волоконного каналу

Мені потрібна свіжа пара очей.

Ми використовуємо волоконно-оптичну лінію в 15 км, через яку мультиплексовані волокнисті канали та 10 Гбіт (пасивний оптичний CWDM). Для FC у нас є лазери на великі відстані до 40 км ( Skylane SFCxx0404F0D ). Мультиплексор обмежений SFP, які можуть робити макс. 4Gb фіброканал. Перемикач FC - серія Brocade 5000. Відповідні довжини хвиль складають 1550,1570,1590 і 1610nm для FC і 1530nm для 10GbE.

Проблема в тому, що тканини 4GbFC майже ніколи не чисті. Іноді вони на деякий час навіть з великим трафіком на них. Тоді вони можуть раптом почати створювати помилки (RX CRC, кодування RX, невідповідність RX, ...) навіть при лише граничному трафіку на них. Я додаю графіки помилок та трафіку. Наразі помилки складають 50-100 помилок за 5 хвилин при трафіку 1Gb / s.

Ось підсумована потужність одного порту (зібрана за допомогою sfpshowрізних комутаторів)

SITE-A одиниці = uW (мікрохвильовий) SITE-B
**********************************************
FAB1
SW1 TX 1234,3 RX 49,1 SW3 1550nm (ко)
      RX 95.2 TX 1175.6
FAB2
SW2 TX 1422.0 RX 104.6 SW4 1610nm (нормально)
      RX 54.3 TX 1468.4      

Що мені здається цікавим на даний момент - це асиметрія в рівнях потужності. У той час як SW2 передає потужність 1422uW, яку SW4 отримує зі 104uW, SW2 приймає сигнал SW4 з аналогічною оригінальною потужністю лише з 54uW.

Навпаки для SW1-3.

У будь-якому випадку у SFP чутливість RX до -18dBm (приблизно 20uW), тож у будь-якому випадку це повинно бути добре ... Але нічого.

Деякі SFP були встановлені як несправні в роботі виробника (1550 nm, показані вище з "ko"). 1610 нм, мабуть, нормально, вони були протестовані за допомогою генератора трафіку. Орендована лінія також перевірялася не раз. Все в межах допусків. Я чекаю на заміну, але я чомусь не вірю, що це покращить ситуацію, оскільки, очевидно, хороші не створюють помилок ZERO.

Раніше перед тим, як подавати сигнал на лінію, було залучено активне обладнання (якийсь ретимер 4GFC). Не знаю чому. Це обладнання було усунене через проблеми, тому у нас тепер є лише:

• лазер на великій відстані в комутаторі,
• (новий) 10-метровий мономодовий кабель LC-SC до mux (для кожної тканини),
• орендована лінія,
• те саме, але перевернуте на іншій стороні посилання.

Ось конфігурація порту з Brocade portcfgshow(очевидно, що це з обох сторін)

Номер області: 0
Рівень швидкості: 4G
Заповніть слово (увімкнено) 0 (у режимі очікування)
Заповнити слово (поточне) 0 (у режимі очікування)
AL_PA Зсув 13: OFF
Порт магістралі ВКЛ
LS на велику відстань
VC Link Init OFF
Бажана відстань 32 км
Застережені буфери 70
Заблоковано L_Port OFF
Заблоковано G_Port OFF
Вимкнено E_Port OFF
Заблоковано E_Port OFF
Режим ISL R_RDY вимкнено
RSCN пригнічено
Постійне відключення вимкнено
LOS TOV увімкнено
Можливість NPIV увімкнена
QOS E_Port OFF
Автоматичне вимкнення порту: вимкнено
Ліміт швидкості вимкнено
EX порт вимкнено
Дзеркальний порт вимкнено
Відновлення кредитів увімкнено
Буфери F_Port вимкнено
Затримка помилок: 0 (R_A_TOV)
Ліміт PPIV PP: 126
Режим CSCTL: OFF

Примусові посилання на 2GbFC не створюють помилок, але ми купили 4GbFC і хочемо 4GbFC.

Я вже не знаю, де шукати. Будь-які ідеї, що спробувати далі або як продовжити?

Якщо ми не можемо змусити 4GbFC працювати надійно, мені цікаво, що роблять люди, які працюють з 8 або 16 ... Я не вважаю, що "кілька помилок тут і там" є прийнятними.

О та BTW, ми контактуємо з усіма виробниками (перемикач FC, MUX, SFP, ...) За винятком змін SFP (деякі були змінені раніше) ніхто не має поняття. Brocade SAN Health каже, що тканина в порядку. MUX, ну, це пасивно, це лише призма, природа в кращому випадку.

Якісь постріли в темряві?

@ Chopper3: Це Брокади другого покоління, які демонструють проблему. Раніше у нас було 5000, зараз у нас 5100. На початку, коли у нас ще був активний MUX, ми взяли напрокат лазер довгої відстані один раз, щоб перевести його в комутатор безпосередньо для того, щоб робити тести на день, протягом цього дня, звичайно, було чисто. Але, як я вже сказав, іноді це чисто як раз. А іноді це не так. Альтернативні комутатори означали б відновити весь SAN з тими лише для тестування. Альтернативні SFP, ну вони важко прийти просто так.

@longneck: Лінія орендована. Це темне волокно (мономер 9 дюймів), тому на ньому більше немає нікого. Впевнені, що є зрощення. Я не можу піти і дивитись, але мушу вірити, що вони зроблені правильно. Як я вже сказав, лінію перевіряли та перевіряли (використовуючи оптичний рефлектометр часової області). Очевидно, що ви не маєте все це обладнання самостійно, оскільки це занадто дорого.

@mdpc: Який би ти був "неправильний" тип кабелю? До вимикача все мономодне, так. Роз'єми є і правильними. Так, я знаю, що є зелені, де волокно відрізається під певним кутом і т. Д. Але у нас є правильні для всього, що я знаю.

У нас було дві тканини (= 2x2 вимикачі) з Brocade 5100s з FabricOS 6.4.1 і дві тканини (ще 2x4 перемикачі) на FabricOS 7.0.2.

На ISL з довгими відстанями (по одному в кожній тканині) з'ясувалося, що при встановленні FOS 6.4.1 на великі відстані видається попередження про налаштування VC Init і, отже, слово заповнення. Але це лише попередження. FOS 7.0.2 вимагає внести зміни в VCI та слово заповнення міжміських зв'язків.

Якщо встановити FOS 6.4.1 на статичну відстань LS (міжміська статична відстань) з неправильним налаштуванням VCI та wordword, зробила всю тканину непрацездатною (застрягла в циклі SCN, використовуйте fabriclog -sдля перегляду, ви її більше ніде не бачите, жодної помилки порту лічильники або що-небудь збільшується).

В даний час я даю одній тканині з IMHO більш правильні налаштування побиття, і, здається, це добре, тоді як інший без особливого трафіку все ще має помилки тут і там.

Коротко:

• Ми усунули активну частину MUX (FC ретимер).
• Ми ставимо великі відстані SFP в кінцеве обладнання.
• Щоб переконатися, ми купили нові мономодні кабелі, щоб підключити кінцеве обладнання до пасивної частини MUX.
• Зараз ми пробуємо кілька конфігурацій на великі відстані.

Це майже чорна магія. Все, що відбувається, здебільшого емпіричне, ніхто, здається, не має поняття, які точні причини зробити щось. ("Ми спробували це, і це не вийшло. Тоді ми спробували це, і воно спрацювало, тому ми дотрималися цього". Але, схоже, ніхто не знає, чому.)

Я буду тримати вас в курсі.

Ми отримали нові лазери для однієї з тканин на гарантії. Це надзвичайно чисто навіть на 4GbFC.

Вони передають приблизно 2мВт (3dBm), тоді як інші лише на 1,5mW (1,5dBm), хоча цього дійсно має бути достатньо.

Інша тканина (де лазери, очевидно, нормально) все ще нечасто виробляє одну або дві КРС.

sfpshowПоказано використання SFP, що створює фактичні помилки RX

Статус / Ctrl: 0x82
Попереджувальні сигнали [0,1] = 0x5, 0x40
Попереджуйте прапори [0,1] = 0x5, 0x40

Тепер мені доведеться з’ясувати, що це означає. Не впевнений, чи був там раніше.

Ну я спочатку очищую голову з тижневої відпустки. 8-)

Гаразд, я думаю, мені потрібно опублікувати відповідь. Одним словом це: наполягати .

Проблема не вирішується на 100% до мого вподобання, оскільки ми все ще маємо спорадично одну тканину з 1 (однією) помилкою CRC. Інший - чистий. Але я можу з цим жити.

У будь-якому випадку ми не будемо продовжувати використовувати модулі CWDM дуже довго, а скоріше перейдемо на пасивний мультиплексор DWDM наступного року, оскільки наша інфраструктура сильно зміниться. Мабуть, лазери DWDM дешевші, ніж у CWDM. О, ми побачимо, і, можливо, у мене буде багато питань, щоб запитати вас тоді :-)

Оновіть Nope до вищесказаного, ми знову купили CWDM, і це дійсно менш дорого. AFAICS для певних програм, однак, вам потрібно пройти DWDM, оскільки для цього немає лазерів CWDM. Нарешті ми спробували наблизитися до виробника, наскільки ми могли, і вся справа вийшла приблизно на 1/5 ціни порівняно з покупкою у дистриб'ютора чи навіть інтегратора.

Тож я можу зробити висновок, якщо ви купили рішення, яке не працює так, як очікувалося: наполягайте. З технічної сторони ми зробили дві речі

• видаліть активну частину MUX (не можу сказати, що шкодую про це, але також не впевнений, що це було нарешті іншим джерелом помилок чи ні)
• провести ретельну перевірку SFP

(І звичайно вся стандартна діагностика, міняйте по одній справі, дивіться, що відбувається і т. Д., Вам не потрібно цього говорити. Тому ми перевіряли кожну лінію та кабель тощо. На жаль, за наш рахунок.)

У цьому випадку потрібно було довго наполягати, але нарешті ми дійшли до рівня, коли сам виробник пощадив кількох людей та деяке обладнання для проведення перевірок, які допомогли. І, звичайно, нам довелося платити за це інтегратором, оскільки наше обладнання знаходиться в технічному обслуговуванні. Тож це було стільки комерційного виклику, скільки технічного.

PS. О, і прапори, про які я згадував у своєму останньому оновленні, не вказували на щось погане, але я не пам'ятаю, що саме вони мали на увазі. Коли я знайду твердження, я оновлю відповідь заради повноти.

Зрештою, прапори означали все-таки щось погане. Мабуть, однак невідомо, яка сторона посилання є причиною помилок. Тож цю пару теж треба змінити.

О та BTW, 8GbFC DWDM приймачі лише дешевші порівняно з 8G CWDM ;-) Найдешевший шлях - це 4GbFC на CWDM, а потім використовувати трансляцію ISL (якщо у вас є ліцензія)