DAC 25G линкуется между одинаковыми FortiSwitch, но не между FS2048 и FS648
Мы сводим два ряда агрегации на FortiSwitch, и последний элемент - соединение 25G между FS2048 и FS648 в соседних стойках. Всё остальное в проекте поднялось с первой попытки; этот линк подниматься отказывается.
- FortiSwitch 2048, порт 25G на передней панели
- FortiSwitch 648, порт 25G на передней панели
- фирменный пассивный DAC Fortinet FN-CABLE-SFP28-5, не сторонний
- на обоих портах ничего не менялось, кроме настройки VLAN
Что я получаю:
FS2048 port: down, no rx/tx counters moving
FS648 port: down, no rx/tx counters moving
same FN-CABLE-SFP28-5 between two FS648 units: up at 25G, stableЧто уже сделано:
- заменил на второй FN-CABLE-SFP28-5 из той же коробки - без изменений
- переставил оба конца на другие порты 25G на каждом шасси - без изменений
- доказал, что кабель исправен, подключив его между двумя одинаковыми FS648, где он поднимается сразу
То есть кабель в порядке и порты в порядке, но именно эта комбинация - нет. Есть ли что-то на портах 25G, что должно совпадать между этими двумя моделями, прежде чем линк сможет обучиться (train)?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 6
Именно так. Два шасси построены на разных поколениях ASIC и PHY, и режим коррекции ошибок, который каждое из них выбирает по умолчанию на 25G, не совпадает с обеих сторон, поэтому обучение линка так и не завершается. В итоге вы получаете чистый down/down и ничего полезного в логах.
Зафиксируйте одинаковый режим FEC вручную на обоих портах:
Сделайте это и на FS2048, и на FS648, используя собственное имя порта для каждой стороны. CL91 - это вариант Рида-Соломона, и он даёт заметно больше выигрыша, чем вариант firecode CL74, но какой из двух вы выберете, гораздо менее важно, чем то, чтобы выбрать один и тот же на обеих сторонах: обе PHY должны кодировать и декодировать по идентичной схеме, иначе обучение никогда не завершится, а "auto" на двух разных семействах PHY - это не идентичная схема.
Порт должен подняться сразу, как только вы примените настройку на второй стороне. Если позже добавите в это соединение третью модель, задайте режим явно и на ней, а не рассчитывайте, что унаследуется значение по умолчанию.
Кабель, который линкуется между одинаковыми устройствами и умирает между разными моделями, - это физический уровень, который не может договориться о чём-то, а на 25G по меди это почти всегда FEC.
Прежде всего приведите текущее значение fec-state на обоих портах. Значение по умолчанию не одинаково между поколениями FortiSwitch, а две модели, которые вы соединяете, относятся к разным семействам ASIC/PHY, так что "заводские настройки на обоих концах" не означает "одинаковая настройка на обоих концах".
Если на этих двух портах окажутся разные значения, ответ у вас уже есть, ещё до того, как что-то трогать.
Ни на одной из сторон ничего не менялось, так что оба порта работают с тем, что по умолчанию задаёт прошивка. Со стороны FS2048 конфигурация пустая:
То же самое на FS648. Скорость и автосогласование тоже не трогал, только назначил порты в нужный VLAN. Если значения по умолчанию отличаются между моделями, это бы объяснило, почему тот же самый кабель прекрасно работает между двумя одинаковыми коробками.
Ради справедливости - тот же класс проблемы встречается и далеко за пределами Fortinet. У меня был пассивный DAC 25G SFP28, который спокойно линковался между UniFi USW-Pro-Aggregation и сервером с картой Intel SFP28, и совсем ничего не давал на sfp28-2 у MikroTik CCR2004-1G-12S+2XS - ни ошибки с любой стороны, просто нет линка. Пробовал Ubiquiti UACC-DAC-SFP28-3M и Lenovo 7Z57A03558 - результат тот же. В какой-то момент порт даже поднялся и упал снова секунды через две - это и была подсказка, что дело в неудачном обучении, а не в мёртвом кабеле.
Опять FEC: сторона Ubiquiti держит FEC включённым без поддерживаемого способа это изменить, а RouterOS в версии 6.49 сменила значение по умолчанию с fec91 на отсутствие FEC. Помогло вот что: перейти на RouterOS 7.4, где опции FEC доступны для настройки, выполнив
а затем выставить на порту fec74 с выключенным автосогласованием, выключенным управлением потоком в обе стороны, 25 Гбит/с полным дуплексом, плюс переопределение профиля порта на стороне UniFi, фиксирующее 25G FDX. Это моё железо и моя прошивка, так что относитесь к этому рецепту как к отправной точке и проверяйте на своём оборудовании.
Стоит добавить, что один и тот же параметр называется по-разному в зависимости от того, в чьём CLI вы находитесь, и именно это делает задачу болезненной, как только в стойке появляется больше одного вендора. На линках Cisco 25G между стеком Catalyst 9300 и парой Catalyst 9500 помогло fec cl108 на обоих концах; на 100G между этой парой 9500 и Nexus 9000 сработало fec off с обеих сторон. Одно и то же решение, разные ключевые слова.
И FEC не всегда нужно включать. На Nexus 93180YC-EX с SFP-H25GB-SR, подключённом к адаптеру Cavium 25G, порт коммутатора стоял в FEC auto и ожидал FEC из-за самого модуля, а сетевая карта вообще не сообщала о поддержке FEC, так что стороны так и не договорились, и интерфейсы оставались down при том, что модули определялись нормально. Там помогло fec off на интерфейсе коммутатора, и show interface подтверждает переход режима с Auto на Off.
Так что правило не "используйте cl91", а "выберите режим и затем явно задайте его на обоих концах".
Подтверждаю. set fec-state cl91 на порту FS2048 само по себе ничего не изменило, но затем то же самое на порту FS648 - и линк поднялся за пару секунд. Счётчики движутся с обеих сторон, и это пережило перезагрузку каждого шасси.
Теперь настройка будет явно указываться на каждом порту 25G в этой паре, а не полагаться на значение по умолчанию. Два вечера замены заведомо исправных кабелей ради одной строчки конфигурации.