Пара Aruba 2530-48G по новому 200-метровому OM4: порт 51 в состоянии Down, хотя самотест модулей J4858C проходит успешно
Некоторое время назад проложили 200-метровую магистраль OM4 между двумя зданиями, и я пытаюсь запустить её на уже имеющемся оборудовании. Оба конца - 2530, оба модуля - родная деталь HPE, и линк просто не поднимается.
- 2x Aruba 2530-48G
- 2x J4858C 1000SX, порт 51 на каждой стороне
- примерно 200 м свежепроложенного OM4, подрядчик сертифицировал как исправное
- перемычки Digitus DK-2533-01 OM2 LC от патч-панели до коммутатора
show tech transceivers для этого порта выдаёт:
Port 51 Down Auto 1000FDx 1000SX multi
Что уже сделано:
- прогнал самотест модуля на обоих коммутаторах, оба проходят
interface 51 enableна обеих сторонах - без изменений, порт остаётся Down- поменял два модуля местами между коммутаторами - тот же результат в любую сторону
- переустановил перемычки на панели и на коммутаторе
Застрял между двумя теориями: либо оба модуля бракованные из коробки, либо перемычки OM2 на магистрали OM4 всё это убивают. Что вероятнее, и что стоит проверить дальше, чтобы реально доказать одну из версий?
Comments 4
Прежде чем строить дальнейшие теории, сократите линк. Перенесите один коммутатор к другому, вставьте оба J4858C и соедините их одним патч-кордом - одна перемычка, без панелей, без проложенного волокна. Если в таком виде порт 51 поднимается, вы одним махом сняли подозрение и с обоих модулей, и с обоих портов коммутатора, и остаётся другая сторона линии: проложенное волокно, панели, соединители, терминации.
Именно так развивался случай, которым я занимался. Та же пара 2530-48G, те же J4858C, порт 51 Down на проложенной трассе и Up, как только два модуля соединили напрямую одним кордом. С такими доказательствами я бы перестал подозревать оптику - но будьте честны насчёт того, что этот тест на самом деле доказывает. Он изолирует сегмент, не более того. Какая именно часть трассы плохая - панель, сварка, коннектор или просто не та пара, что подключена - остаётся открытым вопросом, пока кто-нибудь не приложит к этому измеритель или рефлектометр.
Раз уж вы этим занимаетесь, я бы отложил теорию про OM2. Для 1000SX на 200 м класс перемычки не то, что вас останавливает, да и OM3 с OM4 в любом случае взаимно совместимы. Смешивать классы неаккуратно, и я бы не стал так строить новую инфраструктуру, но это не та неисправность, за которой вы гонитесь.
Как только тест напрямую пройдёт, вернитесь к тому, кто тянул волокно, и попросите результаты сертификации в письменном виде, по каждому волокну, с затуханием и длиной. Их собственный тест объявил линк исправным, значит либо что-то пропустили, либо они измерили другую пару, а не ту, к которой вы подключены - и вот на этом основании стоит требовать, чтобы они вернулись и переделали.
Первым делом разделите две разные неисправности, которые обе печатаются как Down. Порт, административно выключенный или неправильно настроенный, - это одна проблема, порт, который включён, но не видит света на приёмнике, - совсем другая. Вы уже выполнили
interface 51 enable, и он всё равно показывает Down, так что вы на уровне 1, и конфигурация со счетов снята.Две вещи, которые сузили бы поиск. Что физически стоит между двумя коммутаторами - сколько патч-панелей, есть ли сварочные кассеты, добавлял ли кто-то соединители, чтобы дотянуть трассу? И есть ли у вас отчёт о сертификации от подрядчика с реальными цифрами затухания по каждому волокну, или только устное "проверили, всё нормально"?
Также подтвердите, что ваши дуплексные перемычки не разведены одинаково на обеих панелях. Прямая разводка на обоих концах даёт TX на TX, а это выглядит в точности как то, что вы описываете.
Вариант того же теста на случай, если два коммутатора не получается свести в одну комнату: закольцуйте модуль сам на себя. Патч-корд с TX на RX на одном и том же дуплексном модуле, с аттенюатором в линии, если это модуль высокой мощности, чтобы не сжечь приёмник. Если порт поднимается, хостовый порт и модуль в порядке и электрически, и оптически, а неисправность на дальнем конце, в волокне или в разводке пары.
Сделал именно так на MES3324F с FIBO SFP+, который отказывался линковаться коммутатор-коммутатор - петля поднялась сразу же, что перенесло поиск с модуля на трассу. Одна оговорка: петля на себя бесполезна для BiDi-модулей, поскольку TX и RX там на разных длинах волн. Вместо этого закольцовывайте согласованную пару друг на друга.
Для следующей партии тестируйте модули прежде, чем они окажутся хоть рядом со стеной. Прочитайте EEPROM и DDM (вендор, партномер, температура, мощность TX и RX), измерьте мощность TX измерителем и проверьте чувствительность с аттенюатором, закольцуйте, как описано выше, а затем прогоните реальный линк на целевой скорости с трафиком и следите за счётчиками ошибок -
ethtool -mиiperf3покроют эти последние два пункта, если под рукой есть хост. На линках, которые действительно важны, прогон PRBS-31 BER достаточной длительности, подтверждающий уровень ниже 1e-12 для NRZ, - вот что реально доказывает исправность модуля. Ни один отдельный инструмент не проверяет всё сразу.Ещё одна привычка, позаимствованная у WISP-сообщества, которая дважды меня спасала: прогонять каждый модуль через тёплую перезагрузку, холодную перезагрузку и переустановку, прежде чем ставить его в эксплуатацию. Некоторые детали линкуются при установке, а после перезапитки возвращаются мёртвыми - GLC-T-OEM классический пример, он поднимается только после переустановки - а другие сообщают состояние линка, которое не соответствует действительности. Гораздо дешевле обнаружить это на столе, чем на крыше.