Catalyst 9000 交换机输出丢包故障排除

2026年8月25日 LOG admin

接口计数器上的 Output Drops 持续增长，往往是缓冲区拥塞的信号，而不是简单的链路质量问题。在 Catalyst 9000 系列交换机上，理解缓冲区分配机制是解决输出丢包的关键前提。这篇文章依据思科官方文档，解释了输出丢弃的产生原理（接口入方向突发超过出方向转发速率时缓冲区被填满），并给出了验证缓冲区拥塞的两条核心命令、队列统计解读方法以及用 Wireshark 分析丢包流量的思路，帮助你区分拥塞丢包与硬件故障丢包。全文围绕一条主线展开：先把症状归入正确的计数器族，再用队列级统计定位到底丢在哪个阈值上，最后才考虑调整阈值或者做流量整形。

什么是输出丢弃

当目标接口的数据包到达速率超过其输出速率时就会发生拥塞，多余的数据包必须暂存在缓冲区中等待发送。Catalyst 9000 每个 ASIC 最多有 36MB 缓冲区，在所有端口间共享。即使突发流量只持续几分之一秒，也可能造成延迟；如果缓冲区被完全填满，就会产生输出丢弃。注意：16.9.3 及以上版本中，show interface 的输出丢弃计数器默认以数据包为单位显示，更早版本默认以字节为单位；跨版本升级之后做历史对比时，如果不核对单位，很容易得出错误的结论。

Switch# show interfaces GigabitEthernet1/0/1 | include output drops
Switch# show interfaces GigabitEthernet1/0/1 | include rate|drops|packets/sec

低吞吐量拥塞与突发流量

即使接口输出速率明显低于最大接口容量，流量突发同样会导致输出丢弃。show interface 的输出速率默认按五分钟取平均，无法捕捉毫秒级突发，因此平均速率看起来正常，但突发瞬间缓冲区已被打满。这也是最容易误判的一点：看到平均利用率不高就断定「链路没有拥塞」，关掉工单，而计数器仍在一格一格往上走。排查时建议结合更细粒度的队列统计来观察瞬时行为，或者用更短的采样间隔连续读取计数器，而不是只依赖一次读数。

缓冲区架构：丢包究竟发生在哪里

Catalyst 9000 的缓冲区内存并不是一个单一的池子。每个端口拥有一组队列，每个队列既有自己的保留（reserved）配额，又能按阈值占用共享池（shared pool）的一部分。当某个队列超出自身预留的大小时，它会向共享池借用；一旦共享池被耗尽，数据包就会按照队列阈值逻辑或者共享缓冲区逻辑被丢弃，具体落在哪一套逻辑上，取决于限制是在哪一层被触发的。这个区别正是队列级计数器要告诉你的事情，也是「这个队列需要更大的配额」与「同一 ASIC 上其它端口把共享缓冲吃光了」这两种完全不同的结论之间的分界线。

验证缓冲区拥塞

两条命令用于验证缓冲区拥塞：

9300# show platform hardware fed switch active qos queue config interface gigabitEthernet 1/0/48
9300# show platform hardware fed switch active qos queue stats interface Gig 1/0/1

第一条命令查看端口当前的缓冲区分配（队列数量、DTS、Hardmax、Softmax 等参数），第二条查看每个队列的入队与丢弃字节数，包括 Drop-TH0/TH1/TH2、SBufDrop、QebDrop 等分类计数，直接反映哪些队列在丢包以及丢在哪个阈值上。建议把两条命令的输出并排来看：config 给出的是每个队列的上限，stats 显示的是实际上撞到了哪一个上限。

9300# show platform hardware fed switch active qos queue stats interface Gig 1/0/1 | include Queue|Drop
9300# show platform hardware fed switch active qos interface Gig 1/0/1

解读队列计数器：TH0、TH1、TH2、SBufDrop 与 QebDrop

这些计数器的名字看起来晦涩，但一旦映射回缓冲区架构就很好理解，每一个都在回答「数据包死在哪里」这个问题的不同侧面。

每个队列的 Total Enqueue / Dequeue 字节数 —— 表示真正送入该队列的流量，以及最终发出去的那一部分。入队远大于出队的队列，就是拥塞队列。
Drop-TH0 / TH1 / TH2 —— 因为越过队列的阈值 0、1 或 2 而丢弃。采用三色或者加权阈值策略的队列会优先在 TH1、TH2 上丢包，TH0 属于最后手段；看哪一个 TH 在增长，就能判断突发深入到队列配额的哪一层。
SBufDrop —— 端口无法向共享缓冲区借用，因为共享池已经被占满，通常是被同一 ASIC 上的其它端口占用。这个计数器指向的是跨端口拥塞，而不是本端口自己的突发。
QebDrop —— 记录在排队引擎缓冲区（queueing engine buffer）上的丢弃，通常出现在队列被配置或者运行在硬限制上、无法再接受更多描述符的时候。

一个实用的阅读顺序是：先确认接口级 output drops 计数器在增长，再看逐队列统计找出真正丢包的队列，然后判断丢包是基于 TH（本队列自己的阈值）还是基于 SBuf（共享池压力）。如果计数显示一个没有任何实际流量的队列在丢包，或者丢包与任何突发都对不上，那就是应该停止把它当作缓冲区调优问题、转而检查 ASIC 与物理层的时刻。

使用 Wireshark 分析输出丢包

对于间歇性丢包，可以在交换机上配置 SPAN 或使用嵌入式抓包工具将流量镜像到 Wireshark 分析。结合队列统计与抓包时间戳，可以确认丢包是否与特定流（如突发的大流量会话）相关，从而制定 QoS 限速或调整缓冲区阈值的方案。条件允许时尽量在入方向和出方向同时抓包：一个数据包在入方向出现、在出方向消失，说明它是交换机内部丢包，这能把排查范围直接收窄到缓冲区与队列配置上。

Switch(config)# monitor session 1 source interface GigabitEthernet1/0/1 both
Switch(config)# monitor session 1 destination interface GigabitEthernet1/0/48
Switch# show monitor session 1

输出丢包与其他丢包计数器的区别

在调整任何缓冲区之前，先确认你正在看的计数器真的代表拥塞。Catalyst 9000 接口上暴露了好几族看起来都像「丢包」的计数器，但它们指向完全不同的子系统：

Output drops —— 出方向队列无法存储该数据包，与拥塞、缓冲区或者阈值相关。这就是本文讨论的对象。
Input drops —— 数据包在进入方向就被丢弃，通常来自 policer、CoPP 或者接收侧的队列限制。这往往是控制平面保护的结果，而不是容量问题。
Input errors、CRC 与 runts —— 物理层完整性。QoS 或者缓冲区配置在这里帮不上任何忙，应该去看光模块和线缆。
Ignored 与 overrun 计数器 —— 内部资源耗尽，通常与输出丢包同时出现，但并不是由输出丢包引起的。
ASIC exception drops —— 转发引擎内部的丢包，只能通过 platform 命令看到，接口计数器里不会显示。

9300# show interfaces GigabitEthernet1/0/1 | include drops|errors|ignored|overrun
9300# show platform hardware fed switch active fwd-asic drops exceptions asic
9300# show controllers ethernet-controller GigabitEthernet1/0/1 phy | include FCS

把症状归入正确的计数器族，才能避免两个经典错误：为了修一个坏掉的光模块去调 QoS，或者为了修微突发去换光模块。

从计数器估算突发大小

队列统计还能粗略估算造成丢包的突发规模，进而判断调整阈值能否吸收它，还是必须改变实际负载。Catalyst 9000 ASIC 的共享缓冲区最大为 36MB，也就是 288 兆比特。在 10Gbps 的出方向速率下，满载的共享缓冲区大约 29 毫秒就能排空；在 1Gbps 下大约需要 288 毫秒。任何长于这个排空时间的突发，无论阈值怎么设置都无法被吸收。所以丢包模式本身就说明了问题类型：随短微突发出现又消失的丢包，属于阈值与整形问题；一次持续数秒的丢包，则属于持续性过载问题。

调整之前先收集证据

缓冲区调优属于有影响、且事后很难判断对错的操作，所以应该先收集齐证据，并与变更记录放在一起。最小证据集是：接口计数器、队列配置、队列统计，以及受影响业务的带时间戳抓包。如果这四项一致表明某个队列在突发期间越过自己的阈值，那你做出的调整就是有依据的。如果它们互相矛盾——比如计数器显示丢包，而队列统计始终干净——说明丢包发生在流水线的其它环节，改阈值不会有任何帮助。

9300# show interfaces GigabitEthernet1/0/1 | include output drops|rate
9300# show platform hardware fed switch active qos queue config interface Gig 1/0/1
9300# show platform hardware fed switch active qos queue stats interface Gig 1/0/1
9300# show platform hardware fed switch active fwd-asic drops exceptions asic

排错检查清单

核对 show interface 的输出丢弃单位（16.9.3 之后为数据包，之前为字节），确认计数器确实在增长。
用 show interfaces ... | include rate|drops|packets/sec 观察瞬时速率，不要只看五分钟平均值。
把 queue config 与 queue stats 并排看，定位丢包的队列与阈值。
区分 Drop-TH*（本队列自己的阈值）与 SBufDrop（共享池被其它端口占用）。
在入、出两个方向同时抓包，确认丢包发生在交换机内部还是外部。
排除 input drops、CRC、input errors、ignored/overrun 与 ASIC exception 等其它计数器族。
用共享缓冲区排空时间（10G 约 29ms、1G 约 288ms）判断突发能否被吸收。
确认证据集一致之后，再执行阈值调整或者流量整形，并把证据与变更一起归档。

解决思路小结

确认是缓冲区拥塞导致的输出丢包后，处理方向包括：优化 QoS 队列调度、调整队列缓冲区阈值、对 burst 流量做整形或限速、排查上游突发源。降低实际负载几乎总是比扩大缓冲区更便宜也更有效，因为更大的缓冲区只会把丢包转换成延迟。如果队列统计显示丢包与拥塞无关（例如空闲队列上的丢包，或者 exception 而不是阈值丢包），则需要回到物理层和 ASIC exception 路径继续排查。

9300# show platform hardware fed switch active fwd-asic drops exceptions asic
9300# show interfaces GigabitEthernet1/0/1 | include error|drop|CRC

同一平台的相关阅读：内置抓包工作流见 Cisco IOS-XE 嵌入式抓包排障手册；当分析仪不在同一台交换机上时，参见 SPAN、RSPAN 与 ERSPAN 镜像传输指南。