Вопрос: Проблемы с длинным расстоянием между волокнами


Мне нужны свежие глаза.

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

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


Оптика

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

Единицы SITE-A = uW (microwatt) SITE-B
**********************************************
Fab1
SW1 TX 1234.3 RX 49,1 SW3 1550 нм (ко)
      RX 95.2 TX 1175,6
Fab2
SW2 TX 1422.0 RX 104.6 SW4 1610nm (ok)
      RX 54,3 TX 1468,4

То, что мне кажется любопытным на данный момент, - это асимметрия уровней мощности. В то время как SW2 передает с 1422uW, который SW4 принимает с 104uW, SW2 принимает только сигнал SW4 с аналогичной оригинальной мощностью только с 54uW.

И наоборот, для SW1-3.

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

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

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

  • дальний лазер в переключателе,
  • (новый) 10 м LC-SC мономодный кабель к мультиплексору (для каждой ткани),
  • арендованная линия,
  • то же самое, но наоборот на другой стороне ссылки.


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

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

Площадь: 0
Уровень скорости: 4G
Fill Word (On Active) 0 (Idle-Idle)
Fill Word (Current) 0 (Idle-Idle)
AL_PA Смещение 13: ВЫКЛ
Порт внешней линии
Длинные расстояния LS
VC Link Init OFF
Желаемое расстояние 32 Km
Зарезервированные буферы 70
Заблокировано L_Порт ВЫКЛ
Заблокировано G_Порт ВЫКЛ
Отключено E_Port OFF
Заблокировано E_Порт ВЫКЛ
Режим ISL R_RDY выключен
RSCN отключен OFF
Постоянный отключить ВЫКЛ
LOS TOV включить OFF
Возможность NPIV ON
QOS E_Port OFF
Port Auto Disable: OFF
Ограничение скорости ВЫКЛ
Порт EX OFF
Зеркальный порт ВЫКЛ
Возврат кредита
Буферы F_Port OFF
Задержка сбоя: 0 (R_A_TOV)
NPIV PP Limit: 126
Режим CSCTL: ВЫКЛ

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

error and traffic graphs

Я не знаю, где искать. Любые идеи, что делать дальше или как продолжить?

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

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

Любые выстрелы в темноте?


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

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

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

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


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

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

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

progress1

Вкратце:

  • Мы устранили активную часть MUX (корректор FC).
  • Мы помещаем SFP на большие расстояния в конечное оборудование.
  • Чтобы убедиться, что мы купили новые мономодные кабели для подключения конечного оборудования к оставшейся пассивной части MUX.
  • Теперь мы тестируем несколько конфигураций на большие расстояния.

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

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


 Отчет о проделанной работе №2

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

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

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

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

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

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

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


52
2017-08-26 22:02


Источник


Прежде всего, большой вопрос, для чего этот сайт, хорошо сделано. Во-вторых, у вас есть доступ к альтернативным коммутаторам / SFP - в идеале другой make / model, который вы можете поменять для тестирования? - Chopper3
Большое обновление, следите за хорошей работой, жаль, что у меня не было предложений или советов, но вы на правильном пути, приятно найти нового пользователя в SF, который знает их вещи :) - Chopper3
Существуют ли какие-либо согласования во времени или длительности ошибок? Всегда ли они происходят через N час? Всегда ли они продолжаются X минут? Можете ли вы сопоставить их с погодой, рядом с спортивными событиями или другим явлением? Прерывистые проблемы - самые сложные ошибки для сквоша, и я обычно начинаю атаковать их, создавая графики времени и продолжительности, которые они встречают на доске. Надеемся, что появляются паттерны, которые могут быть связаны с другое явление, - dotancohen
Вы отслеживаете их на доске, видимой для все? Я не буду настаивать, но я очень рекомендую. Как вы сказали, вам нужны свежие глаза, и, возможно, кто-то из вашей организации увидит, что картина возникает из времени / продолжительности, а не обязательно от симптомов. - dotancohen
Привет, Марки. Я не совсем знаком с тем, о чем вы говорите, но по последнему обновлению кажется, что проблема была устранена заменой SFP? Если это так, вероятно, хорошая идея опубликовать это как ответ и задать новый вопрос, если у вас есть дополнительные проблемы. - Mark Henderson♦


Ответы:


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

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

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


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


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

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

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

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

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


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

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


4
2017-11-02 20:02



К сожалению, я не видел этого, когда его спрашивали. Я не могу сказать вам точно, что это поможет, но если вы используете незанятые полные слова, вы отправляете много света. Это означает, что каждый неиспользованный кадр тянет много энергии и, как я думаю, выделяет много тепла на SFP. Изменение интервала в другом режиме (я использую режим 3, но у меня есть другой переключатель и SFP), что позволит вам увеличить пропускную способность с меньшим количеством ошибок. - Basil
@Basil Я знал, что использование правильного слова заполнения было проблемой для синхронизации слов на 8GFC, но я подумал об этом таким образом ... - Marki
Это рекомендуется в любое время, когда вы можете его использовать. Насколько я могу судить, вопрос о том, сколько помех создает незанятый кадр, создает его SFP. - Basil