OCe14000 主板集成网卡在拔线之后仍报告链路正常，导致 ESXi 网卡组从不切换
一个小型 vSphere 集群，每台主机有两条 10G 上联到一对 ToR 交换机。一次为升级固件重启 ToR 之后，其中一台主机上一部分虚拟机失去了响应，两条上联的 vMotion 都失败了——但 ESXi 从未把任何链路标记为 down，网卡指示灯也一直亮着。
- Fujitsu Primergy RX2540 M1
- Emulex OneConnect OCe14000 主板集成网卡（VID 10df DID 0720 SVID 1734 SSID 120e）
- ESXi 6.0 U3
- 接入 ToR 的 SFP+ 光模块，vSwitch 上是普通的 active/standby 组网
让我确信这不是交换机的问题的地方：我把光纤从网卡上整根拔掉，它看起来还是活的。
esxcli network nic get -n vmnic2 (cable physically removed)
Link Status: Up
Firmware Version: 11.2.1194.36
esxcli software vib list | grep elxnet
elxnet 10.2.309.6v已经尝试过：
- 重新插拔了模块和光纤，换过跳线
- 把这条上联换到另一台 ToR 交换机，那边的端口会按预期显示 down
- 重启了主机上的管理代理
因为主机认为这条上联是活的，网卡组策略就没有理由切换任何东西，虚拟机全都钉在一个已经死掉的端口上。这是 OneConnect 上一个已知的驱动和固件版本不匹配的问题，还是应该去查主板网卡的硬件本身？
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
这个组合的问题出在你自己这边，ESXi 6.0 的兼容列表里并没有把它列为受支持的搭配。网卡最终处于一种半活状态：它停止转发流量了，却继续把端口报告为已连接，导致网卡组策略永远等不到它需要的那个 down 事件去采取行动。这就是为什么你看到的是一种局部隔离——两条上联的 vMotion 都死了，而不是一次干脆利落的网卡故障；一块正常死掉的网卡反而比一块在撒谎的网卡容易应付得多。
把驱动升到 11.2.1149.0。这正是 VMware 兼容性列表里针对 11.2.1194.36 这个固件版本认证过的 elxnet 版本，所以你是把驱动升上去去匹配固件，而不是把网卡固件降回去。升级之后用你已经用过的这两条命令核实一下：
vib 那一行应该显示新版本号，主机重新上线后 Link Status 应该会重新跟着物理线缆的状态走。在把这台主机重新交给生产集群使用之前，先在这条上联上跑一台虚拟机，拔一下光纤测试一遍。
值得记住的一个习惯是：在 OneConnect 上，驱动和固件是成对升级的，应该把两者排在一起做，而不是让某次维护包悄悄把其中一个单独往前带。对比这两行输出只需要一条命令，而且应该在你开始拔光模块、怀疑交换机之前很早就做。
你贴的这两行才是关键：固件 11.2.1194.36，跑在 elxnet 10.2.309.6v 之下。这个固件是不是曾经随某次服务器维护包单独到达过，而没有同时带上驱动？
拿这个组合去对照 ESXi 6.0 的兼容性列表核实，而不是想当然地认为「越新越好」。OneConnect 正是驱动和固件按对认证的产品线之一，版本不匹配未必会闹得很明显——它会半好半坏地工作，这反而更糟。
另外也值得说一下，这块网卡的第二个端口在拔线之后是不是表现一样。
是的，固件是随一次服务器维护包上去的；驱动自这台主机搭建以来就没动过。
两个主板网卡端口表现完全一样：拔线之后，esxcli network nic get 仍然报告 Link Status: Up，指示灯还亮着，vSwitch 也一直把这条上联留在活动列表里。交换机那一侧是干净的，我一拔线它的端口就立刻掉下来。
所以这台主机上唯一不匹配的地方，就是 elxnet 版本和 11.2.1194.36 这个固件版本。
不同的产品线，同样的教训。一对 Emulex LPe31000/LPe32000 光纤通道端口，之前一直好好地跑着没动过，在 Proxmox 内核升到 5.15.64、后来又升到 5.15.74 之后，突然看不到任何 LUN 了。线缆和光模块都没碰过，日志显示：
这是主机侧 lpfc 驱动的一个回归问题，不是光学故障；出现在 5.15.60 之后的内核上。把启动内核锁回去，是在生产环境里挺住的应对办法：
对于不介意离开 5.15 分支的人，选用可选的 5.19 内核也能用。修复本该在 5.15.77 落地，但我自己一直没抽空去实测那个版本，所以这条只能算道听途说。要点还是那句话：一条原本正常的链路，在主机端发生变化之后突然死了，先去看主机端的变更日志，别急着怀疑光模块。
补一个反方向的例子，因为它训练的是同一种警觉。指示灯是软件驱动的，软件在两个方向上都会出错。
在 EX3400 和 EX2300 上有一个 Junos 缺陷，编号 PR1428703：SFP+ 和 SFP 端口的指示灯一直不亮，而链路其实是真正 up 的，也在正常转发流量。有人是在从 15.1X53 升到 18.1 和 19.x 系列时踩到的，大多是用 DAC 的情况。CLI 和面板上的显示对不上：
报告指示灯是 Green，而物理指示灯却是灭的。有些版本据说修复了，但另一些版本仍然有人反映指示灯不亮，所以我不会说这个问题已经彻底解决。
你遇到的是灯亮着但没链路，那个案例是灯不亮但有链路。不管哪种情况，都应该相信对端和计数器，而不是指示灯。
现在两台主机上的驱动都是 11.2.1149.0 了。拔掉线缆后，指示灯会熄灭，esxcli 会报告链路 down，备用上联也会像本该的那样接管——分别在每条上联上单独测试了一遍，vMotion 都跑得干干净净。
驱动和固件成对升级这一条，已经写进我们的服务器维护检查清单，避免下一次维护包再悄悄把两者拆开。