Supermicro E300-9A на pfSense Plus 22.05: ix2 и ix3 остаются без несущей с DAC, который нормально поднимается на USW-Aggregation
Мой файрвол - Supermicro E300-9A на pfSense Plus 22.05, и оба 10G SFP+ порта отказываются подниматься. Ни ix2, ни ix3 никогда не показывают carrier, что бы я ни поставил в слот.
Оборудование:
- Supermicro E300-9A, pfSense Plus 22.05
- Ubiquiti DAC-SFP10-0.5M и пассивный твинаксиальный кабель 10Gtek
- модули Supermicro AXS85-192-M3 как альтернатива
- Ubiquiti USW-Aggregation на стороне коммутатора
# ifconfig ix2
ix2:
media: Ethernet autoselect
status: no carrierix3 выглядит так же.
Что уже пробовал:
- оба кабеля работают на USW-Aggregation между другими устройствами, то есть они не мертвы
- поменял медь на волоконные модули AXS85-192-M3 - тот же no carrier на обоих портах
- перезагружал устройство несколько раз, в том числе вставляя модуль во время работы
Есть ли в этой коробке что-то, что нужно "пнуть", прежде чем слоты начнут работать, или это просто два мёртвых порта?
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 4
Тёплые перезагрузки никуда вас не приведут - эти порты фиксируют состояние среды и не перепроверяют его при рестарте. Корректно выключите устройство, выдерните адаптер питания на пару минут, затем включите заново с уже вставленным модулем. Это вернуло оба порта здесь, и ещё один человек описал точно такое же поведение на порту Intel X552, поэтому я думаю, что это залипшее состояние среды, а не проблема pfSense.
Если вставляете модуль, пока система уже работает, вместо перезагрузки перезапустите интерфейс:
Это заставляет драйвер заново посмотреть на слот. Это не постоянное решение чего-либо, но экономит перезагрузку, когда меняете модули на столе. Проверяйте результат через
ifconfig -a, а не по передней панели.Сначала полностью снимите питание и подтвердите оба слота с DAC, прежде чем трогать сторону коммутатора. Здесь важно отлаживать по одной вещи за раз, потому что "no carrier с любым модулем" и "линк поднимается не на той скорости" обычно две разные неисправности, которые просто совпали в одном кабельном тракте.
Полное снятие питания помогло. Выключил, выдернул адаптер, подождал пару минут, включил снова - оба порта поднялись. Закольцевал DAC между ix2 и ix3 и получил чистый линк 10G, пара AXS85-192-M3 тоже даёт 10G между двумя портами, так что со слотами и модулями всё в порядке.
Сторона коммутатора - другая история. К USW-Aggregation линк всегда согласовывается только на 1G, а если форсировать 10G на любом конце - он падает и остаётся лежать. Так что половина проблемы ушла, а неприятная половина осталась.
Половина проблемы с откатом на 1G выглядит очень знакомо. Я гонялся за тем же симптомом на TL-SG3428X и TL-SX3008F: перезагружаешь сервер, висящий на одном из этих SFP+ портов, и он возвращается согласованным на 1G, что бы ни было настроено на порту коммутатора. Intel X520-DA2, адаптеры Mellanox и HP, оптика Intel E10GSFPSR и 10GTek, обновления прошивки, несколько версий драйверов на Linux и Windows, профили портов - ничего из этого ничего не меняло. Перезагрузка коммутатора или переключение скорости порта с 10G и обратно восстанавливало линк на 10G до следующего сброса хоста.
Что реально помогло - это смена оптики, а не что-либо на хосте: модули TP-Link SM5110-SR на стороне коммутатора, и линк каждый раз возвращался на 10G. Кто-то ещё подтвердил то же самое на SG3428XMPP. Вывод был в том, что коммутатор неправильно согласуется с некоторыми сторонними модулями после сброса линка со стороны хоста.
Вендор у вас другой, но форма совпадает. Прежде чем покупать комплект чего-либо, одолжите один модуль под брендом Ubiquiti и проверьте один порт на агрегационном коммутаторе.
Про форсирование 10G: делать это только на одном конце - хуже, а не лучше. Партнёр всё ещё пытается согласовываться, а фиксированная настройка не даёт ему ничего, с чем согласовываться, так что линк просто остаётся лежать - именно то поведение, что вы описываете. Фиксируйте скорость и дуплекс на обоих концах, либо ни на одном.
Два похожих случая из мира MikroTik, на всякий случай. На RB4011 Finisar FTLF8524P2BNV-BR определялся с sfp-rx-loss и sfp-tx-fault оба no, а интерфейс всё равно показывал no-link, потому что 1G SFP в слоте SFP+ нужно жёстко зафиксировать, а не согласовывать:
и опять же на обоих концах. Второй случай - CCR1072, где auto-negotiation оставался в DONE после потери линка, и драйвер никогда не перезапускал его; отключение autoneg и фиксация скорости вернули линк ценой корректного детектирования падения линка.