Supermicro E300-9A跑pfSense Plus 22.05:ix2和ix3一直是no carrier,而同一根DAC在USW-Aggregation上链路正常
我的防火墙是一台运行pfSense Plus 22.05的Supermicro E300-9A,两个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原厂模块,在aggregation交换机上单独测一个端口。
关于强制10G:只在一端这么做只会让情况更糟,不会更好。对端仍在尝试协商,而固定配置那一端根本没有东西可供协商,所以链路就一直起不来——这正是你描述的现象。要么两端都固定速率和双工,要么两端都不固定。
分享两个MikroTik这边相关的案例,看看是否眼熟。在一台RB4011上,一个Finisar FTLF8524P2BNV-BR被检测到sfp-rx-loss和sfp-tx-fault都显示no,但接口依然显示no-link,原因是SFP+模块笼里插1G SFP必须手动固定而不是协商:
同样要两端都这么设。第二个案例是一台CCR1072,链路丢失之后自动协商状态一直停在DONE,驱动没有重新启动它;关掉自动协商、固定速率之后链路恢复了,代价是失去了正常的链路断开检测。