DAC Q+DA0001 40G между CRS326-24S+2Q+RM и Huawei S6720: обе стороны читают кабель, линк остаётся down
Перестраиваем агрегацию на одной из наших площадок: CRS326-24S+2Q+RM принимает клиентские порты SFP+ и уходит аплинком на 40G в Huawei S6720. Короткий участок внутри одной стойки, поэтому пассивный DAC вместо оптики.
- MikroTik CRS326-24S+2Q+RM, порт QSFP+ qsfpplus1-1
- Huawei S6720-54C-EI-48S-AC, обычный порт 40GE
- пассивный DAC MikroTik Q+DA0001 QSFP+ 40G
Обе коробки корректно читают кабель, MikroTik показывает его как собственный Q+DA0001, а Huawei перечисляет в информации о порту медный кабель 40G. А затем ничего не происходит:
MikroTik: qsfpplus1-1 no-link
Huawei: 40GE... current state : DOWN
Что уже сделано:
- закольцевал тот же кабель между двумя портами QSFP+ на CRS326: линкуется сразу
- закольцевал его между двумя портами 40GE на Huawei: тоже линкуется
- поменял концы местами, переставил на другой порт QSFP+, всё переустановил
- убедился, что ни одна из сторон не отключена административно
То есть кабель исправен, и каждый коммутатор по отдельности им доволен, только пара разных вендоров отказывается работать. Кто-нибудь реально поднимал Q+DA0001 между CRS326 и S6720, и что пришлось поменять с той или иной стороны, чтобы порт поднялся?
Comments 5
Эта пара «по умолчанию с обеих сторон» и есть ваша проблема, как и отключение автосогласования на обеих сторонах сразу. То, что сработало здесь на такой же комбинации, асимметрично, и на бумаге это выглядит неправильно, но факт остаётся фактом: порт Huawei 40GE с выключенным автосогласованием, а qsfpplus1-1 на MikroTik держит своё автосогласование включённым.
На Huawei, внутри интерфейса:
На MikroTik не трогайте это, или задайте явно, чтобы никто потом это "не поправил":
Линк 40G поднялся сразу после этого на моей паре CRS326-S6720 и с тех пор стабилен. Я бы не назвал это решением в полном смысле, скорее обходом: эти две реализации явно не согласны друг с другом насчёт того, что должен согласовывать линк DAC 40G, и асимметричная настройка - это просто тот угол, где обе стороны довольны. Делайте это в окне обслуживания, а не на живом аплинке, и если не сработает, проверьте, вообще ли ваша прошивка Huawei позволяет отключить автосогласование на этом порту - это не универсально.
Кросс-вендорный 40G, где обе стороны видят кабель, но ни одна его не поднимает, почти всегда сводится к тому, что именно пытаются согласовать эти два порта.
Приведите состояние автосогласования с обеих сторон: конфигурацию порта 40GE на Huawei и значение auto-negotiation для qsfpplus1-1 на MikroTik, и скажите, меняли ли вы что-то из этого относительно значения по умолчанию. Также скажите, пробовали ли вы уже отключать его - на обеих сторонах сразу или только на одной, потому что это два разных эксперимента.
Тесты петлёй доказывают только то, что кабель исправен. Они ничего не говорят о том, согласны ли два конца между собой насчёт одного и того же поведения при согласовании, а это здесь самое интересное.
Обе стороны на значениях по умолчанию: auto-negotiation=yes на qsfpplus1-1 и negotiation auto на порту Huawei 40GE, и я не трогал ни одну из конфигураций сверх поднятия интерфейсов. Я действительно пробовал отключить это на обеих сторонах одновременно, что вообще ничего не изменило; вариант с отключением только на одной стороне мне даже в голову не приходил.
Состояние линка держится как no-link на MikroTik и DOWN на Huawei, счётчики вообще не двигаются, так что дело даже не доходит до того, чтобы записать ошибку на какой-либо из коробок.
Эта последняя оговорка заслуживает не просто сноски, потому что именно на ней я и застрял. На S6320-54C-EI, с RouterOS 7.12 на стороне MikroTik, порт 40G вообще не даёт отключить автосогласование, так что асимметричному трюку просто некуда приземлиться.
Симптомы в остальном идентичны: обе стороны читают кабель, порт остаётся down, ошибок нигде нет. Так что описанный выше обходной путь реален, но платформо-зависим, а лежащая в основе несовместимость между этими двумя реализациями 40G, насколько я могу судить, так и остаётся открытой.
Для тех, кто попадёт сюда, так и не сумев заставить кросс-вендорный DAC вести себя нормально: в какой-то момент дешевле перестать с этим бороться.
У меня был Alta Route 10 против CRS309-1G-8S+, где Route 10 распознавал и 10Gtek, и DAC SFP+ от FS, отображавшийся как SFP-H10GB-CU2M, тогда как CRS309 не видел объявления партнёра по линку, и пара линковалась только при принудительном понижении до 1G. Принудительная установка 10gbase_r в /cfg/sfpX.txt ничего не давала, и какой бы модуль ни стоял в клетке, ethtool на Route 10 продолжал перечислять режимы baseT. Заменил модули с обеих сторон на оптику FS SFP-10GSR-85, и линк 10G поднялся мгновенно.
Другая скорость и другие устройства, тот же урок: когда кабель заведомо исправен, а два конца всё равно не могут договориться, пара оптических модулей стоит дешевле, чем ещё неделя настройки.