На FortiGate 101F совмещённые порты RJ45/SFP 17-20 гаснут после обновления FortiOS
У нас пара FortiGate 101F на офис на 40 человек, ничего экзотического. port17 несёт SFP-аплинк на core-коммутатор, port19 - это RJ45 в серверную, оба они внутри совмещённого блока RJ45/SFP (порты 17-20). В прошлом окне обслуживания мы подняли пару до FortiOS 7.4.4, и с тех пор этот блок мёртв.
- FortiGate 101F, и FortiGate 100F на втором сайте ведёт себя так же
- port17: 1G SFP модуль на стековый access-коммутатор
- port19: RJ45 в порт 1G коммутатора
- FortiOS 7.4.4, обновлено с ветки 7.2
Порты 1-16 в порядке, упали только совмещённые. Что бросилось в глаза - варианты скорости в GUI теперь выглядят не так, как до обновления, а в текущей конфигурации вот это:
config system interface
edit "port17"
set speed 1000full
next
endЭто никто у нас не вводил. Все порты на этой коробке были на auto до обновления.
Что уже пробовал:
- переустановил SFP и заменил его на заведомо рабочий - без изменений
- перенёс дальний конец на другой порт коммутатора
- холодная перезагрузка файрвола - конфигурация сохраняется как выше
Ожидаемо ли, что совмещённый блок RJ45/SFP на 100F/101F теряет auto при обновлении, или у нас где-то испортилась конфигурация? И как правильно вернуть всё обратно?
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 5
Вашу конфигурацию испортил не кто-то в офисе, это сделало само обновление. На 100F и 101F обновление тихо прописывает фиксированный 1000full на совмещённые порты RJ45/SFP там, где раньше был auto, не спрашивая, может ли партнёр жить с такой скоростью. В зависимости от дальнего конца вы получаете либо порт, поднимающийся не на той скорости, либо вообще никогда не поднимающийся, что и объясняет, почему 17-20 темны, а выделенные порты не тронуты. У Fortinet это заведено как известная проблема 989629, описанная в release notes для 7.2.9; затронутые ветки - v7.2.8 и новее, v7.4.2 и новее, и v7.6.0 и новее.
Верните скорость вручную, для каждого порта:
На v7.2.8 и на v7.4.2-7.4.4 обычный auto в списке не предлагается, именно поэтому GUI выглядит для вас по-другому, так что там используйте 1000auto. На v7.2.9, v7.4.5, v7.6.0 и новее обычная опция вернулась, и нужно:
Повторите для port18-port20, если они используются. И на следующее окно: заранее проверьте, что ничего в вашем management-тракте не проходит через порты 17-20, иначе коробка вернётся с вашим access-портом, зафиксированным на 1000full, и вам придётся ехать на площадку чинить это с консоли.
С какой сборки вы на самом деле пришли? "сборка 7.2" - это очень широкий диапазон, а то, что нужно вводить для исправления, отличается между ветками. Ещё стоит знать, поддерживают ли дальние концы автосогласование или сами зафиксированы: партнёр, который умеет только автосогласование, будет просто стоять против порта, зафиксированного на конкретной скорости.
Одна вещь, которую стоит выяснить до любых изменений: проходит ли ваш management-трафик через какой-либо из портов 17-20? Если да, делайте следующее изменение с консоли, а не по сети.
Стоит добавить общую вещь для тех, кто попадёт сюда с некорректно ведущим себя совмещённым портом: на большинстве коробок пара действительно взаимоисключающая. NETGEAR называет это dual personality на GS716T-200, где каждый из двух слотов SFP спарен с одним из последних медных портов, и активной может быть только одна половина пары одновременно, так что установка модуля тихо выводит из строя соответствующий RJ-45. На этой модели все порты гигабитные в любом случае, так что оптический аплинк покупает вам кабельный маршрут, а не полосу.
Та же идея на блоке FortiGate, так что подтвердите, на какую именно половину port17 вы смотрите. Модуль в слоте плюс патч-корд в медной половине того же порта - классический гол в свои ворота, и с CLI это выглядит очень похоже на проблему скорости.
Другой вендор, тот же вкус боли. EX4200 с аплинк-модулем EX-UM-2X4SFP: xe-0/1/0 спокойно работал на 10G, xe-0/1/1 даже нельзя было добавить в VLAN, и он не пропускал трафик. Оба порта работали на 1G, SFP+ был полностью виден в show chassis hardware, я менял модули, пробовал запасной EX-UM-2X4SFP и делал сброс до заводских настроек, прежде чем кто-то сказал мне, что это за модуль на самом деле.
Ничего не было неисправно. Этот модуль принимает SFP+ только в двух из своих слотов, аппаратно пронумерованных 0 и 2; другая пара примет только 1G оптику и ничего быстрее. Так что 10G интерфейсы, которые у вас в итоге есть - это xe-0/1/0 и xe-0/1/2, а xe-0/1/1, тот, с которым я боролся, никогда не собирался работать на 10G, что бы я в него ни воткнул. Переставил оптику на слот дальше, настроил xe-0/1/2, готово. С разнорежимными слотами читайте, что поддерживает блок, прежде чем оформлять возврат.
Осторожнее с версией про взаимоисключающие комбо-порты, она не объясняет этот случай. Порты работали до обновления, сломался только совмещённый блок после, и в конфигурации есть строка со скоростью, которую никто не вводил. Это перезапись, а не приоритет слота.
Обратная ошибка, впрочем, тоже многих подводит. Я однажды потратил неделю на коммутаторах D-Link DES-1210-52, поднятых по оптике на OSNOVO NS-SW-8GX2G: индикация линка на оптических портах есть, а LAN и интернета нет вообще, притом что те же коммутаторы прекрасно работали, соединённые цепочкой по меди, и обновление прошивки ничего не изменило. Комбо-порт был главным подозреваемым несколько дней. Реальная неисправность была на дальнем конце: порты OSNOVO, несущие эти SFP модули, были внутренне мертвы, выгорели, при этом сама оптика в них была абсолютно исправна.
Так что, как только локальная конфигурация в порядке, поставьте заведомо рабочий модуль в заведомо рабочий порт на другой стороне, прежде чем делать выводы о своей собственной коробке.