IBM Flex System EN4093 роняет транковые порты SFP+ в ERRDISABLE при загрузке и во время работы
Два шасси Flex System, каждое с коммутатором EN4093R 10Gb Scalable Switch (опция 49Y4270) в качестве сетевого модуля. Порты возвращаются в состоянии error-disabled после события питания шасси, и реже уходят в то же состояние во время работы. Не всегда одни и те же порты, что и делает это таким утомительным для диагностики.
Схема:
- IBM Flex System EN4093 10Gb Scalable Switch, опция 49Y4270
- аплинк-транк из четырёх портов на ядро сети, оптика IBM плюс один DAC, добавленный позже
- порт QSFP+, разбитый в сторону второго шасси
- на нашей стороне работает MSTP, ядро сети - другого вендора
Что показывает список портов после загрузки:
port 5 ERRDISABLE reason: link flap detect threshold exceeded
port 17 ERRDISABLE reason: mismatched link capabilities
port 19 ERRDISABLE reason: mismatched link capabilitiesПробовал:
- shutdown / no shutdown на затронутых портах возвращает большинство из них до следующего события
- почистил и переустановил каждое волокно в транке - без изменений в картине
- сравнил конфигурацию порта на дальнем конце, скорости совпадают на бумаге
Что реально загоняет эти порты в errdisable, и есть ли способ остановить это при каждой загрузке вместо ручного сброса каждый раз?
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
У этого коммутатора семь задокументированных состояний, отключающих порт, и они мало друг с другом связаны:
Ваш случай - четвёртый, и это тот, с которым сталкивается большинство людей, потому что вы строите его сами: смешайте скорости или типы модулей внутри одного транка, и коммутатор возразит. Одного DAC рядом с тремя оптическими модулями достаточно. Уберите DAC оттуда и заполните слот модулем, соответствующим остальным трём.
Для порта на детекторе флапов документированное восстановление по-прежнему такое:
После этого перечитайте конфигурацию spanning tree на этом линке и пройдитесь вручную по меди и оптике. За любым изменением конфигурации следуйте перезагрузкой, иначе рабочее состояние тихо перестаёт совпадать с тем, что вы думаете, что настроили.
Две вещи, которых не стоит ожидать. Два из этих семи состояний держат порт выключенным после истечения таймаута и требуют ручного вмешательства на порту. И никакой релиз прошивки это не чинит - позиция вендора в том, что вы настраиваетесь в обход этого, так что одинаковые модули на всех членах транка плюс чистое волокно - это предел того, что можно сделать для профилактики.
С двух разных причин в одном логе я бы и начал. Данный порт всегда возвращается отключённым по одной и той же причине, или тот, что упал на несовпадении возможностей в эту загрузку, в следующую срабатывает по детектору флапов? Причина, что закреплена за портом, и причина, что блуждает - это два разных расследования, и только одно из них заканчивается покупкой железа.
Второе, что стоит выяснить - что ядро сети использует для spanning tree. У вас MSTP; если дальняя сторона кладёт на эти аплинки BPDU в стиле Cisco PVST, у этого коммутатора есть механизм защиты, реагирующий ровно на это и опускающий порт, и со стороны это выглядит как неисправность, за которой вы уже гоняетесь. Можете сказать, совпадают ли какие-либо из падений с изменением топологии на ядре сети, а не с вашими собственными загрузками?
По порту это стабильно, по коробке в целом - нет. Члены транка, которые падают, всегда возвращаются с mismatched link capabilities, а access-порт на 5 срабатывает только по детектору флапов, без какой-либо закономерности по интервалу, которую я могу найти. Так что это действительно похоже на две неисправности в одной обёртке.
Про spanning tree на дальней стороне пока ответить не могу - ядро сети принадлежит другой команде, и я спросил у них, что реально излучается на эти аплинки. Пока ничто в нашем логе не связывает падение с изменением топологии там, но я читал лог на предмет событий линка, а не этого, так что не назвал бы это исключённым.
Другой вендор, та же форма. У нас был FortiGate 201F, висящий на FortiSwitch 548D через SFP+ с фирменным DAC Fortinet между ними, и линк 10 Гбит/с просто не хотел держаться - падал что бы мы ни делали со скоростью и дуплексом, а откат обеих сторон с FortiOS 7.4 на 7.2.5 ничего не изменил.
В итоге сработал более короткий DAC Fortinet с выключенным STP на этом конкретном линке, и с тех пор он держится. Что стоит перенести дальше - это рассуждение, которое получилось потом: чем длиннее пассивная медная линия, тем сильнее деградирует сигнал к моменту прибытия, так что на 10G любой длинный или пограничный DAC должен быть в списке подозреваемых, каким бы брендом он ни был помечен. С тремя оптиками и одним DAC в транке в errdisable я бы пристально смотрел именно на несоответствующий элемент.
Одна вещь, которую стоит сделать, прежде чем трогать какое-либо железо: запишите точный ритм флапов относительно временных меток в логе.
На совершенно не связанном коммутаторе, TL-SG3452X, каждый занятый порт SFP+ падал и поднимался каждые десять-пятнадцать минут с сообщениями STP в логе при каждом флапе, и очевидным выводом была плохая оптика - пока фирменный DAC TL-SM5220-1M не начал флапать ровно в том же ритме. Это одним тестом убило теорию про оптику и указало вместо неё на регрессию в прошивке; единственным рабочим ответом там было остаться на старой сборке.
Регулярный интервал означает, что что-то по расписанию отваливается по таймауту. Случайный - что-то физическое. Дешёвый тест, и он экономит покупку модулей, которые вам не нужны. Также окупается держать под рукой предыдущий образ прошивки, чтобы откат оставался вариантом.