本文记录一次服务器接入交换机的聚合整改。设备地址、端口编号、服务器名称和 MAC 地址均已脱敏。

一、故障现象

服务器交换机上出现大量 MAC move 记录，同一个虚拟机 MAC 在同一台服务器的多个物理端口之间反复漂移。现场同时存在以下特征：

  • 服务器使用多块物理网卡；
  • 虚拟交换机或操作系统 Teaming 启用了负载均衡；
  • 交换机端仍把这些端口当作独立 Access 口；
  • 部分端口属于同一业务 VLAN，但没有加入相同聚合组。

这会造成交换机不断重写 MAC 表，表现为间歇丢包、ARP 异常、服务时通时断和未知单播增加。

二、先确认服务器侧模式

交换机端不能凭端口数量直接创建聚合。必须先确认服务器侧属于哪一种模式：

服务器侧模式 交换机侧要求
LACP / 802.3ad 对应端口必须加入同一个动态聚合组
Active/Standby 通常保持独立端口，只允许主端口转发
Switch Independent 不应强制创建 LACP 聚合
虚拟交换机桥接 需要确认是否会让同一 MAC 同时从多个端口发出

本次通过服务器配置、端口流量、LACP Partner 信息和 MAC 漂移方向交叉确认后，才确定需要整改的端口组。

三、变更设计

整改过程采用事务式思路：

1
2
3
4
5
6
7
8
9
变更前采集
    ↓
应用一组聚合配置
    ↓
验证聚合状态、VLAN、MAC 学习和业务连通性
    ├── 验证失败：立即回滚，不保存
    └── 验证成功：进入观察窗口
                       ↓
                    保存配置

验证条件包括：

  • 聚合接口状态为 Up；
  • 所有预期成员均为 Selected；
  • Unselected 和 Individual 成员为 0；
  • Access VLAN 与原端口保持一致；
  • MAC 地址转移到聚合接口学习；
  • 接口错误计数没有新增；
  • 业务探测通过。

四、实际调整过程

第一次自动应用时，验证未满足预期，脚本立即回滚，并且没有保存配置。这个结果说明回滚机制是有效的，也避免了把半完成状态留在生产交换机上。

确认服务器侧配置后再次执行，四组聚合成功建立：

  • 两组为双端口聚合；
  • 一组为四端口聚合；
  • 另一组为双端口聚合；
  • 所有预期成员均为 Selected；
  • 没有 Unselected 或 Individual 成员。

另有一组端口因为服务器侧关系不明确，被明确跳过，没有为了“配置整齐”而强行纳入聚合。

五、处理残留 MAC 漂移

聚合整改后，大部分服务器 VLAN 的漂移停止，但一个双端口组合仍持续产生 MAC move。进一步比对发现：

  • 两个端口承载相同 VLAN；
  • 同一批 MAC 在两个端口间双向切换；
  • 其中一个端口速率较低；
  • 服务器侧没有形成可验证的 LACP Partner 关系。

因此没有继续强行建聚合，而是先关闭其中一个冗余端口进行止血。

第一次关闭尝试未通过验证并自动回滚。重新确认目标端口后再次执行，端口进入 Administratively Down 状态；随后进行多轮轻量监控，MAC move 计数保持不变，没有出现新的漂移增量，最终才保存配置。

六、整改结果

调整后的状态：

  • 已确认的服务器链路全部运行在正确的 LACP 聚合上；
  • 聚合成员状态完整，没有半选中状态；
  • 原有物理端口属性迁移到聚合接口；
  • 主要服务器 VLAN 的 MAC 漂移停止增长；
  • 未确认的链路保持保守配置；
  • 配置只在验证通过后保存。

七、后续建议

  1. 给每台服务器建立网卡、虚拟交换机、交换机端口和业务 VLAN 的对应表；
  2. 监控 MAC move 增量，而不是只查看累计值；
  3. 对聚合组监控 Selected 数量变化；
  4. 服务器更换网卡或 Teaming 模式时同步更新交换机配置；
  5. 配置 STP、边缘端口保护和环路检测，降低误接线风险；
  6. 所有生产变更都保留前置检查、验证、回滚和保存四个阶段。

这次整改最重要的经验不是“把多口都做成聚合”，而是确保服务器侧和交换机侧使用同一种链路模型。