交换机对接服务器丢包

问题深度解析

1. 1.

   ​​日志解读​​：

   • •

     %Sep 10 05:00:03:962 2025 product_sw_101 IFNET/4/IF_EGRESS_DROP: Packet loss occurs in queue 2 of GigabitEthernet1/0/22.

   • •

     这条日志明确告诉我们：在 GigabitEthernet1/0/22接口的​​出方向（Egress）​​，​​第2号队列（Queue 2）​​ 发生了包丢弃。

2. 2.

   ​​为什么会发生队列拥塞？​​

   • •

     华三交换机默认启用了​​基于端口的QoS​​。每个物理端口都有8个出口队列（0-7），默认使用​​SP（Strict Priority，严格优先级）​​ 调度方式。

   • •

     ​​Queue 7​​是最高优先级队列，​​Queue 0​​是最低优先级队列。​​Queue 2​​是一个中间优先级队列。

   • •

     当服务器（尤其是做了Bond后）​​瞬间发送大量数据​​，速率超过交换机接口的处理能力时，数据包就会在出口缓冲区（Buffer）中排队。

   • •

     如果数据流被算法（如默认的基于端口的优先级映射）分配到了 Queue 2，而 Queue 2 的缓冲区被填满后，后续到达这个队列的报文就会被丢弃，从而产生您看到的日志。

3. 3.

   ​​根本原因分析​​：

   • •

     ​​服务器Bonding模式​​：这是最可能的原因。如果服务器端的Bond模式是 ​​mode-4 (802.3ad/LACP)​​ 或 ​​mode-0 (round-robin)​​，它们会在多个物理链路上进行​​负载均衡​​。

   • •

     ​​流量哈希不对称​​：交换机和服务器的负载均衡哈希算法（通常基于IP+端口五元组）可能导致​​大部分流量都哈希到了同一个物理端口​​上。例如，服务器Bond口认为应该从eth0发送大量数据，而交换机对应的GigabitEthernet1/0/22接口就成为了瓶颈，即使其他Bond成员口很空闲。

   • •

     ​​流量突发（Microburst）​​：服务器应用程序可能产生非常短暂的、高速率的流量突发（毫秒或微秒级）。虽然平均流量不高，但瞬间峰值流量超过了端口速率，导致队列瞬间被填满。这种丢包很难通过display interface的平均流量统计看出来，需要更专业的流量分析工具捕捉。

解决方案

请按照以下步骤进行排查和解决：

1. 确认服务器Bonding模式及流量分布（最关键的一步）

• •

  ​​在服务器上执行命令查看Bond模式​​：

  • •

    Linux: cat /proc/net/bonding/bond0

  • •

    重点关注 Bonding Mode这一行。

• •

  ​​评估模式​​：

  • •

    ​​如果模式是 round-robin (mode-0)或 LACP (mode-4)​​：这是导致流量集中到单个物理端口的典型模式。需要检查每个Slave接口的流量计数是否均衡。

  • •

    ​​在服务器上查看每个物理网卡的流量统计​​：使用 ifconfig或 ip -s link show，对比 eth0, eth1的发送字节数（TX bytes）。如果其中一个远高于其他，则证实了哈希不对称问题。

  • •

    ​​如果模式是 active-backup (mode-1)​​：则通常不会有此问题，因为同一时间只有一块网卡活跃。

2. 调整交换机的QoS配置（缓解队列丢包）

即使流量不均，也可以通过调整交换机侧的队列参数来缓解丢包。

• •

  ​​检查接口的默认QoS配置​​：

  display interface GigabitEthernet 1/0/22

  注意看输出中关于 Peak information的部分，会有队列的权重、缓冲等参数。

• •

  ​​修改队列调度方式和权重（推荐）​​：

  • •

    SP调度虽然简单，但低优先级队列容易“饿死”。可以改为更公平的 ​​WRR（Weighted Round Robin）​​ 或 ​​SP+WRR​​ 混合调度。

  • •

    例如，将队列0-6改为WRR调度，队列7保留为SP调度，并为Queue 2分配更多的权重或缓冲区。

  # 进入系统视图 system-view # 进入接口视图 interface GigabitEthernet 1/0/22 # 配置出口队列的调度算法为WRR，并为各队列分配权重（权重值需要根据实际情况调整） qos wrr queue-group 2 queue 0 weight 10 qos wrr queue-group 2 queue 1 weight 20 qos wrr queue-group 2 queue 2 weight 30 # 给Queue 2分配较高的权重 ... （配置其他队列） # 将队列7设置为严格优先级队列（如果有高优先级流量需求） qos sp queue 7
• •

  ​​增加队列的缓冲区（Buffer）​​（如果支持）：

  # 在接口视图下，为queue 2分配更多的共享缓冲区 qos queue 2 queue-length 40 # 数值仅供参考，请根据设备型号和手册调整

3. 优化服务器和交换机的Bonding配置（根治问题）

• •

  ​​确保交换机侧配置了正确的链路聚合​​：

  • •

    如果服务器是 mode-4 (LACP)，​​交换机侧也必须创建相应的静态聚合组或动态LACP聚合组​​，而不仅仅是配置多个独立的access口。

  • •

    ​​正确的配置示例​​：

    # 创建聚合组1（静态）或2（动态LACP） interface Bridge-Aggregation 1 port link-type access port access vlan 10 # interface GigabitEthernet1/0/22 port link-mode bridge port link-type access port access vlan 10 port bridge-aggregation group 1 # 将物理端口加入聚合组 # interface GigabitEthernet1/0/23 # 服务器的另一个网卡端口 port link-mode bridge port link-type access port access vlan 10 port bridge-aggregation group 1
  • •

    这样配置后，交换机会将两个物理端口视为一个逻辑端口，进行流量哈希和负载均衡，从根本上避免单个物理端口拥塞。

• •

  ​​优化哈希算法​​：

  • •

    在交换机的聚合接口视图下，可以尝试更改负载分担的哈希算法，例如从默认的src-ip改为src-dst-ip或src-dst-mac，使其与服务器的哈希算法配合更好，使流量分布更均匀。

  interface Bridge-Aggregation 1 link-aggregation load-sharing mode destination-ip source-ip # 示例模式

总结与行动步骤

1. 1.

   ​​立即检查​​：登录服务器，确认Bonding模式和各个物理网卡的​​发送流量（TX）​​ 是否均衡。

2. 2.

   ​​检查交换机配置​​：确认交换机侧对应服务器多个网卡的端口是否配置了​​正确的链路聚合（Bridge-Aggregation）​​，而不仅仅是独立的VLAN Access口。

3. 3.

   ​​临时缓解​​：如果暂时无法改动聚合配置，可以先在交换机的物理接口上​​调整QoS队列参数​​（如改用WRR调度并为Queue 2增加权重），以缓解丢包。

4. 4.

   ​​根治方案​​：根据服务器的Bond模式，在交换机侧补全​​链路聚合（Link Aggregation）​​ 的配置。这是解决此问题最正确、最彻底的方法。

您遇到的问题正是“服务器配置了Bond而交换机未对应配置聚合”的典型症状。补齐交换机的聚合配置后，问题应能得到根本解决。

确认下服务器的bond模式和交换机聚合模式是否匹配

交换机对面的服务器是做的超融合是吧，如果是超融合的话，那说明该交换机性能不够，需要更换性能高的交换机就可以了，瞬时包过大，需要更换性能更高的交换机