Назад | Перейти на главную страницу

Проблемы с оптоволоконным каналом на большие расстояния

Мне нужна пара свежих глаз.

Мы используем 15-километровую оптоволоконную линию, по которой мультиплексируются оптоволоконный канал и 10GbE (пассивный оптический CWDM). Для FC у нас есть лазеры на большие расстояния, подходящие до 40 км (Скайлейн SFCxx0404F0D). Мультиплексор ограничен SFP, которые могут делать макс. Волоконный канал 4Gb. Коммутатор FC - это серия Brocade 5000. Соответствующие длины волн составляют 1550, 1570, 1590 и 1610 нм для FC и 1530 нм для 10GbE.

Проблема в том, что сети 4GbFC почти никогда не чистятся. Иногда они действуют на время даже при большом трафике. Затем они могут внезапно начать выдавать ошибки (RX CRC, RX кодирование, RX несоответствие, ...) даже при только маргинальном трафике на них. Прилагаю графики ошибок и трафика. В настоящее время количество ошибок составляет 50–100 ошибок за 5 минут при трафике 1 Гбит / с.


Оптика

Вот суммированная выходная мощность одного порта (полученная с использованием sfpshow на разных свитчах)

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      

Что мне сейчас интересно, так это асимметрия уровней мощности. В то время как SW2 передает с 1422 мкВт, а SW4 принимает с 104 мкВт, SW2 принимает только сигнал SW4 с аналогичной исходной мощностью только с 54 мкВт.

Для SW1-3 наоборот.

В любом случае SFP имеют чувствительность приема до -18 дБм (около 20 мкВт), так что в любом случае все должно быть в порядке ... Но ничего не стоит.

Некоторые SFP-модули были диагностированы производителем как неисправные (1550-нм те, что показаны выше с «ko»). 1610нм, видимо, в порядке, они тестировались с помощью генератора трафика. Выделенная линия также неоднократно тестировалась. Все в пределах допусков. Я жду замен, но по какой-то причине я не верю, что они улучшат ситуацию, так как кажущиеся хорошими также не вызывают НУЛЕВЫХ ошибок.

Раньше перед подачей сигнала на линию было задействовано активное оборудование (какой-то ретаймер 4GFC). Понятия не имею почему. Это оборудование было ликвидировано из-за проблем, поэтому теперь у нас есть только:


Коммутаторы FC

Вот конфигурация порта от Brocade portcfgshow (это очевидно с обеих сторон)

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

Форсирование ссылок на 2GbFC не вызывает ошибок, но мы купили 4GbFC и хотим 4GbFC.

Я больше не знаю, где искать. Есть идеи, что попробовать дальше или как действовать?

Если мы не можем заставить 4GbFC работать надежно, мне интересно, что делают люди, работающие с 8 или 16 ... Я не думаю, что "несколько ошибок здесь и там" приемлемы.

Да, кстати, мы поддерживаем контакт со всеми производителями (коммутатор FC, MUX, SFP и т. Д.). За исключением смены модулей SFP (некоторые из них были изменены ранее), никто не имеет ни малейшего понятия. Brocade SAN Health говорит, что ткань в порядке. MUX, ну это пассив, это всего лишь призма, природа в лучшем виде.

Есть выстрелы в темноте?


ПРИЛОЖЕНИЕ: Ответы на ваши вопросы

@ Chopper3: Это второе поколение Brocades, демонстрирующее проблему. Раньше у нас было 5000, теперь у нас 5100. Вначале, когда у нас еще был активный мультиплексор, мы арендовали дальний лазер один раз, чтобы вставить его непосредственно в переключатель, чтобы провести дневные тесты, в течение этого дня, конечно, он был чист. Но, как я уже сказал, иногда бывает так чисто. А иногда это не так. Альтернативные переключатели означало бы перестроить всю SAN, используя только для тестирования. Альтернативные SFP, ну их трудно найти просто так.

@longneck: Линия арендована. Это темное волокно (мономод 9 мкм), поэтому на нем больше никого нет. Конечно, есть стыки. Я не могу пойти посмотреть, но я должен верить, что все сделано правильно. Как я уже сказал, линия была проверена и перепроверена (с использованием оптического рефлектометра во временной области). Очевидно, у вас самого нет всего этого оборудования, потому что оно слишком дорогое.

@mdpc: Какой, по вашему мнению, "неправильный" тип кабеля? Да, до коммутатора все мономодовое. Разъемы тоже правильные. Да, я знаю, что есть зеленые, где волокно обрезано под определенным углом и т. Д. Но у нас есть правильные, насколько я знаю.


Отчет о ходе работ №1

У нас было две структуры (= коммутаторы 2x2) с Brocade 5100 с 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 и настройкой заполняющего слова вызвала неработоспособность всей структуры (застряла в петле SCN, используйте fabriclog -s чтобы увидеть, вы его больше нигде не видите, нет счетчиков ошибок порта или чего-либо увеличивающегося).

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

Коротко:

Это почти черная магия. Все, что происходит, в основном эмпирическое, никто, кажется, не понимает, каковы точные причины что-то делать. («Мы пробовали это, и это не сработало, потом мы попробовали это, и это сработало, поэтому мы и придерживались этого». Но на самом деле, похоже, никто не знает, почему.)

Буду держать вас в курсе.


Отчет о ходе работ №2

На одну из тканей мы получили новые лазеры на гарантии. Он очень чистый даже на 4GbFC.

Они передают примерно 2 мВт (3 дБм), тогда как другие - всего 1,5 мВт (1,5 дБм), хотя этого действительно должно быть достаточно.

Другая ткань (где лазеры явно в порядке) по-прежнему нечасто выдает один или два CRC.

С помощью sfpshow SFP, производящий фактические ошибки RX, показывает

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

Теперь мне нужно выяснить, что это значит. Не уверен, было ли это раньше.

Хорошо, я сначала прочищу голову неделей отпуска. 8-)

Хорошо, я думаю, мне нужно опубликовать ответ. Одним словом это: настаивать.

Проблема не решена на 100% по моему мнению, так как у нас все еще есть одна ткань с 1 (одной) ошибкой CRC время от времени. Другой чистый. Но я могу с этим жить.

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


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


Итак, я могу сделать вывод, если вы купили решение, которое не работает должным образом: настаивайте. С технической стороны мы сделали две вещи

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

(И, конечно, вся стандартная диагностика, меняйте по одному, смотрите, что происходит и т. Д., Не нужно вам об этом говорить. Поэтому мы проверили каждую линию, кабель и т. Д., К сожалению, за наш счет).

В этом случае настаивали долго, но, в конце концов, мы дошли до уровня, когда сам производитель сэкономил несколько человек и некоторое оборудование для проведения проверок, которые помогли. И, конечно же, мы попросили интегратора заплатить эту сумму, поскольку наше оборудование находится на техническом обслуживании. Так что это был не только технический вызов, но и коммерческий.

PS. Да и еще, флаги, которые я упомянул в своем последнем обновлении, не указали на что-то плохое, но я не помню, что именно они значили. Когда я найду утверждение, я обновлю ответ для полноты картины.


В конце концов, флаги все-таки значили что-то плохое. Однако, по-видимому, неясно, какая сторона ссылки является причиной ошибок. Так что эту пару тоже нужно сменить.

Да и кстати, трансиверы DWDM 8GbFC только дешевле по сравнению с 8G CWDM ;-) Самый дешевый способ - это 4GbFC на CWDM, а затем использовать транкинг ISL (если у вас есть лицензия)