S6805-G 丢包

这个是 队列上cpu持续丢包，可能是接口流量满了，看一下接口带宽利用率

参考案例某局点 S6805-56HF-G 告警分析 Continous packet loss no longer detected on protocol message queue 125 - 知了社区

1）SOFTCAR DROP：M-LAG 组网大量未知单播跨 peer-link 泛洪并上送 CPU，触发 CPU 报文限速丢弃，8307P10 版本本身存在 MAC 老化异常漏洞，会加重泛洪。
2）IF_EGRESS_DROP：万兆口 1/0/20 普通业务队列突发流量爆满，端口缓冲区不足造成出方向丢包，泛洪流量也会挤占带宽加剧丢包。
快速处理步骤
① 两台 M-LAG 交换机开启M-LAG 未知单播抑制，peer-link 丢弃未知单播，阻断跨设备泛洪；适当放宽 MLAG、ARP 协议上送 CPU 的限速。
② 扩容 1/0/20 端口缓冲区，开启缓冲共享，缓解业务队列拥塞。
③ peer-link 聚合扩容、关闭 peer-link 的 STP；接入交换机也开启未知单播抑制，源头减少泛洪。
长效方案
版本升级至 8307P16 及以上，修复 M-LAG MAC 收敛 BUG；全网部署 DHCP Snooping 规避非法 MAC 引发泛洪。
验证方式
观察软 CAR 丢弃计数、端口丢包计数不再增长，故障解决；配置同步、排查下联环路避免复发。

你交换机上报的这些日志，是典型的控制平面过载和物理端口拥塞问题。它们共同指向了网络中存在异常流量或瞬时流量高峰，导致交换机CPU和出方向队列不堪重负。

下面是针对这三条日志的详细分析、排查思路和优化建议。

📊 日志分析

1. DRVPLAT/4/SOFTCAR DROP (软限速丢包)

这是一条由交换机的CPU保护机制触发的告警。

• 根本原因：当上送CPU处理的特定协议报文（如ARP、LACP、MLAG同步等）速率超过了设备内部设定的阈值（SOFTCAR）时，交换机为了保护CPU不被冲垮，会主动丢弃超出的部分。

• 你的日志详解：

  • possible protocol L2_COPY_CPU/LSP_PING/MLAG_UNKNOWN_UCAST_TM：这行明确指出了被丢弃的流量类型。

    • L2_COPY_CPU：需要CPU处理的二层协议报文，如STP、LLDP、ARP等。

    • MLAG_UNKNOWN_UCAST_TM：M-LAG组网下，设备间同步的未知单播流量。

  • TotalCnt=90263916：被丢弃的总报文数高达9000多万，这是一个非常巨大的数字，表明问题严重。

2. IFNET/4/IF_BOARD_EGRESS_DROP (板卡级出方向丢包)

这条日志表明，交换机内部在处理从 chassis 0 slot 1 发出的数据时，发生了板卡级的拥塞丢包。

• 根本原因：可能是该板卡的出方向总带宽瞬间被占满，或者内部交换矩阵出现瞬时拥塞。

• 关联性：IF_BOARD_EGRESS_DROP 常常是具体物理端口丢包 (IF_EGRESS_DROP) 的宏观体现或前兆。当某个端口持续拥塞时，可能会影响整个板卡的转发性能。

3. IFNET/4/IF_EGRESS_DROP (端口出方向丢包)

这条日志直接指明了丢包发生的具体位置。

• 根本原因：Ten-GigabitEthernet1/0/20 这个端口的出方向队列2发生了拥塞。这意味着该端口试图发出的数据量，在某个瞬间超过了其接口的物理带宽或队列缓存容量，导致部分报文被丢弃。

• 常见场景：端口下行连接了大流量服务器、存储设备，或者存在广播/未知单播风暴。

🔍 排查步骤

建议按照“定位异常 -> 分析根因 -> 优化调整”的顺序进行。

第一步：定位软CAR丢包的流量源头

1. 查看软CAR统计：

   bash

   display qos car softcar

   重点检查 Cos=78 对应的CAR速率和丢包计数。

2. 查看CPU队列统计：

   bash

   display cpu-defend statistics

   这个命令可以帮你确认是哪种协议报文上送CPU的流量最大。

3. 检查MAC地址漂移：

   bash

   display mac-address flapping

   查看是否存在MAC地址漂移。如果存在，说明网络中很可能有二层环路。

4. 检查M-LAG状态：

   bash

   display mlag peer display mlag consistency

   确认M-LAG对等体和一致性检查是否正常。

第二步：排查端口出方向丢包

1. 查看端口队列统计：

   bash

   display qos queue-statistics interface Ten-GigabitEthernet 1/0/20

   确认 queue 2 的丢包计数和队列深度。

2. 查看端口流量：

   bash

   display interface Ten-GigabitEthernet 1/0/20

   查看该端口的出方向带宽利用率，确认是否长时间接近或达到1Gbps上限。

3. 排查下游设备：检查连接在该端口下的设备（可能是服务器或下级交换机），确认其是否存在大流量业务或异常发包行为。

第三步：进阶排查（如需要）

• 抓包分析：对 Ten-GigabitEthernet1/0/20 端口进行流量镜像抓包，分析到底是什么流量导致了队列拥塞。

• 流统排查：配置流统策略，精准定位丢包发生的具体位置。

🛠️ 优化建议

针对软CAR丢包 (DRVPLAT/4/SOFTCAR DROP)

• 首要：排查环路：如果检查到MAC漂移或二层环路，必须立即修复。这是导致协议报文风暴最常见的原因。

• 抑制未知单播：如果确认是MLAG未知单播流量过大，可以在接口下配置未知单播风暴抑制：

  bash

  interface Ten-GigabitEthernet 1/0/20 unicast-suppression pps 1000

• 调整软CAR限速：若确认是正常协议流量高峰，可以适当提高对应软CAR的限速值。此操作需谨慎，可能导致CPU负载过高。

针对端口丢包 (IF_EGRESS_DROP)

• 开启突发模式：交换机支持 burst-mode enable 命令，可以动态调整缓冲区分配，以更好地应对突发流量。

• 扩容或聚合：如果 1/0/20 端口是带宽瓶颈，考虑升级到更高带宽接口，或将其加入链路聚合组。

• 流量整形：在该端口的出方向配置流量整形（qos gts），将输出流量限制在一个合理的速率，避免瞬间拥塞。