虚拟交换机链路故障处理核心是“检测—判断—切换”三步闭环：依赖链路状态或信标探测进行持续监控，按绑定模式（如active-backup、ip哈希+lacp）执行切换，恢复后默认不自动回切，需人工或策略控制，排查须从物理层状态、驱动、协议栈到虚拟配置逐层验证。
虚拟交换机处理绑定物理网卡的链路故障，核心是靠“检测—判断—切换”三步闭环，不是等断了才反应，而是持续监控并自动兜底。
故障检测机制要配对启用
虚拟交换机本身不主动感知物理链路是否真实可用，必须依赖配置的检测策略：
- 仅链路状态：最基础的方式，靠网卡硬件上报的Link Up/Down信号。能发现拔线、交换机掉电，但无法识别VLAN错配、STP阻塞、光模块收光弱等“假UP”情况
- 信标探测（Beacon Probing）：更可靠。ESXi会从每个绑定网卡发出广播包，并监听其他成员是否收到。只要有一张卡收不到信标，就判定该链路异常——这对光纤抖动、中间交换机静默丢包特别有效
注意：vSphere中若负载均衡策略设为“基于IP哈希”，网络故障检测必须强制设为“仅链路状态”，否则会冲突报错。
故障切换行为取决于绑定模式
不同平台对故障的响应逻辑不同，关键看是否启用主动探测和策略是否匹配：
- VMware标准交换机使用active-backup模式时，主卡失效后约1–3秒完成切换，期间可能丢1–3个包；若用IP哈希+LACP，则需物理交换机同步聚合，否则虚机会出现间歇性断连
- Linux bond mode1（主备）同样依赖miimon参数轮询，建议设为100ms（即每秒检测10次），太长会导致业务感知明显中断
- Hyper-V外部虚拟交换机不支持原生故障探测，实际依赖Windows网卡堆叠或第三方SDN插件，常见做法是配合NIC Teaming设置快速故障转移阈值
链路恢复后不会自动回切，需人工干预或策略控制
多数虚拟交换机默认启用“故障恢复后保持当前路径”，避免来回震荡影响TCP连接：
- vSphere中可在端口组高级选项里开启“Notify switches”并勾选“Failback”，允许主链路恢复后5秒内自动切回
- Linux bond默认不回切，需在配置中加入fail_over_mac=active或设置ad_actor_sys_prio参数配合LACP协商
- 如果业务对主路径有强依赖（如管理口、存储心跳），建议禁用自动回切，改为手动触发，防止恢复瞬间流量洪峰冲击
排查时先确认物理层是否真坏，再查虚拟层配置
很多“链路故障”其实是表象，真实原因常藏在底层：
- 用esxcli network nic get -n vmnicX检查物理网卡实时状态，关注Link Status、Rx/Tx Errors、Firmware Version
- 在vSphere主机界面查看“配置→网络→虚拟交换机→端口组→上行链路状态”，确认是否显示“Unused”或“Incompatible”
- 对比物理交换机侧show etherchannel summary输出，验证LACP协商是否成功、端口是否in use、是否有suspended标记
链路故障不是单点问题，是物理设备、驱动、协议栈、虚拟交换策略共同作用的结果。配对检测、匹配策略、明确回切逻辑，才能让故障真正“静默收敛”。
