Catalyst 9000 网络延迟和丢包故障排除指南

2026年8月25日 LOG admin

网络延迟升高和数据包丢失是Catalyst 9000交换机运维中最常见也最让人头疼的问题，原因可能藏在物理层、STP、MAC地址表甚至ASIC转发引擎里。这篇文章基于思科官方技术文档，系统梳理了Catalyst 9000上延迟和丢包的完整排查路径：先用ping和traceroute定位故障跳点，再逐层检查物理层错误、STP拓扑变更、MAC抖动、CAM/ARP老化、SPAN会话以及ASIC级异常，最后给出一个真实案例的解决方案，帮助你快速缩小故障范围。贯穿全文的原则是「先测量、后假设」：在给出解释之前先故障定位到具体子系统，避免在没有数据支撑的情况下改配置。

测量网络延迟：先定位再分析

排查延迟问题首先要了解网络拓扑。使用ping检查可达性和丢包率、RTT统计；用traceroute逐跳定位高延迟节点。例如输出中某跳延迟从2ms骤升到40ms，说明问题集中在这一跳及其链路，接下来针对该设备做深入检查。测量必须从路径两端同时进行：只从接入侧测得的延迟，可能完全掩盖故障域远端那条已经拥塞的上行链路。

ping 10.10.20.1 repeat 100 size 1400 df-bit
traceroute 10.10.20.1 numeric timeout 2 probe 3

接着用更小和更大的帧长重复同一组测试。如果64字节干净而1400字节开始丢包，指向的是MTU或分片问题而不是带宽不足——这一个观察就能省下大量在缓冲区上打转的时间。ping的repeat参数建议给足，例如100次，少量报文的重传或偶发丢包在统计上会被平均值淹没。

升级前的基线数据采集

在没有固定基线的情况下升级延迟或丢包工单，会浪费每一次沟通的头一个小时，因为接手的人无法区分这是一个长期存在的问题还是刚刚出现的故障。正确做法是在改动任何配置之前，先沿路径在每一台交换机上采集同一组输出，并记录采集时间。基线的价值不在于任何单条命令，而在于改动之后的对比——那也是唯一能证明问题真的被修好、而不是被一次计数器清零掩盖掉的证据。

show version | include Version|RELEASE
show interfaces | include line protocol|rate|drops
show interfaces counters errors | exclude 0
show processes cpu sorted 5sec | exclude 0.00
show logging | include %LINK|%SPANTREE|%MAC_MOVE
show platform software fed switch active punt cause summary

两个习惯会让基线好用很多。第一是刻意清空计数器并记录时间点，这样丢包增长可以用单位时间内的速率来表达，而不是一个模糊的累计总数。第二是把基线放进工单而不是留在终端窗口里——间歇性故障只能靠两份快照的对比来诊断，而关掉的终端里的那份快照已经不存在了。

延迟和丢包的常见原因

第1层物理层问题

检查接口状态和错误计数：show interface gi1/0/1。关注双工模式是否协商为Full-duplex、速率是否匹配，以及CRC错误、runts、giants等输入错误。85个input errors伴随85个CRC通常意味着光模块或线缆质量问题，这类问题不会因为任何QoS或队列调优而消失。更值得警惕的信号是：一个不承载任何业务的端口上CRC或input error计数仍在增长，这说明物理通道本身正在劣化，往往早于业务告警出现。

show interface GigabitEthernet1/0/1
show interfaces counters errors
show controllers ethernet-controller GigabitEthernet1/0/1 phy | include FCS|CRC

STP稳定性

执行show spanning-tree detail | include ieee|from|occur，如果拓扑变更计数持续增长（如6233次变更且3秒前刚发生），说明网络存在STP不稳定，需要定位引起变更的端口。每一次拓扑变更都会刷新MAC地址表并触发重新学习，在应用侧表现为每隔几秒的间歇性丢包，哪怕没有任何链路真正Down掉——这正是STP类问题最难被链路监控发现的原因。

show spanning-tree detail | include ieee|from|occur
show spanning-tree interface GigabitEthernet1/0/1 detail
show spanning-tree root

MAC抖动与二层环路

MAC抖动表现为同一源MAC在不同端口间持续迁移，导致转发中断和丢包。二层环路会加剧广播风暴。用mac address-table notification mac-move开启MAC移动通知，日志中的%MAC_MOVE消息能直接告诉你主机在哪两个端口间抖动，而这对端口本身通常就足以暴露环路或配置错误的双归属主机。

configure terminal
 mac address-table notification mac-move
end
show mac address-table notification mac-move
show mac address-table address 0011.2233.4455

如果MAC地址表暴露的不是环路而是别的异常行为，可以参考我们关于Catalyst 9000非预期MAC学习的文章（见文末链接）。

CAM与ARP老化时间

老化时间配置不当会导致频繁重学习。配置MAC老化用mac address-table aging-time，例如14400秒；ARP超时用arp timeout。在繁忙的接入交换机上，老化时间过短会造成持续泛洪并不断重新解析；而老化时间过长则会保留过期表项，在主机迁移之后仍然把流量指向错误端口。

configure terminal
 mac address-table aging-time 14400 vlan 100
 interface Vlan100
  arp timeout 14400
end
show mac address-table count
show ip arp summary

SPAN会话影响

活动监控器(SPAN)会话会把流量复制到多个目的端口，ASIC复制负载随源流量速率成比例增加。一个3Gbps的端口通道复制到多个目标可能产生超过15Gbps的镜像流量，导致延迟和拥塞。镜像目的端口的容量至少要按「源速率 × 目的端口数」来规划，并且尽量给分析仪准备一条独立的、不做超订的通道。

show monitor session all
show interfaces counters rate | include GigabitEthernet|TenGigabitEthernet

如果需要把镜像流量跨越网络传输而不是送到本地端口，可以参考我们的SPAN、RSPAN 与 ERSPAN 镜像传输对比。

ASIC级异常

Switch# show platform software fed switch active ifm mappings
Switch# show platform hardware fed switch active fwd-asic drops exceptions asic

第一条命令查看接口所在的ASIC实例，第二条查看ASIC异常丢包统计（如BLOCK_FORWARD、PKT_DROP_COUNT），这是定位硬件转发级问题的重要手段。它的价值在于：在ASIC内部被丢弃的报文不会增加任何端口的drop计数，也不会出现在软件侧抓包里，所以接口计数器全干净并不等于没有丢包。

控制平面Punt与CoPP：容易被忽略的延迟来源

并不是所有延迟问题都在数据平面。当交换机上送CPU的报文超过控制平面策略允许的量时，CoPP会限速或丢弃这些报文，相关协议——路由邻居、ARP、DHCP snooping、管理会话——随即开始表现异常。Punt类问题检查成本很低但极容易被忽略，因为整个数据转发路径看起来一直是健康的。经典的识别特征是：CPU利用率偏高，而所有接口计数器正常，此时punt cause视图能直接指出是哪个协议在大量上送。

Switch# show platform software fed switch active punt cause summary
Switch# show policy-map control-plane
Switch# show processes cpu sorted 5sec | exclude 0.00

MTU、分片与路径MTU发现

相当一部分「延迟和丢包」投诉实际上是只影响大包的MTU问题。小的控制报文一直正常，监控看上去完全健康，而任何承载完整1500字节净荷的流量被静默黑洞。测试方法是设置DF位并逐步加大净荷长度：能通过1400字节净荷、在1472字节失败，说明路径中间存在MTU限制，最常见的来源是隧道，或者成员口MTU不一致的端口通道。

ping 10.10.20.1 size 1400 df-bit repeat 5
ping 10.10.20.1 size 1472 df-bit repeat 5
show interfaces GigabitEthernet1/0/1 | include MTU|BW

由于ICMP经常被过滤，DF位ping失败本身不构成证据，需要在两端同时抓包，确认大帧只出现在一侧而另一侧没有。堆叠或端口通道中的巨帧不一致是常见变种，它的症状是按流丢包而不是按端口丢包，因此很容易被误判成应用问题。

两种定位思路：自下而上还是自上而下

排障的顺序本身就是一个决策，选错了方向会在无关的子系统里消耗大量时间。自下而上从第1层开始：先看物理计数器、双工、光功率，再往STP和MAC层走，最后到路由和ASIC。它适合「单端口、单链路、可复现」的故障，因为这类故障有极高概率落在链路本身。

自上而下则从业务和应用侧开始：先确认哪个应用、哪个网段、什么时段出问题，再顺着路径向设备收敛。它适合「面状」症状，例如整个VLAN的应用体验下降、某一类流量异常而其他流量正常、或者多个站点同时报告问题。判断依据很简单：如果症状随端口变化而在一个端口上集中，先自下而上；如果症状跨越多个端口或整个广播域，先自下而上只会浪费一轮枚举，应当自上而下先缩小到子系统，再用自下而上的方法在那一个子系统内部确认。

一个实用的折中做法是维护「固定采集集」——无论从哪个方向开始，第一轮都跑同一组基线命令。这样两轮排障之间永远有可比数据，方向判断错误也只损失一轮而不是整条时间线。

命令输出怎么读：三个高频现场

show interfaces counters errors

这条命令的价值在于横向比较，而不在于绝对值。先执行一次clear counters并记录时刻，然后观察增长速率：单个端口上CRC以每秒数次的速度增长，几乎一定是物理问题；而输入方向的FCS/CRC集中在跑Trunk的上联口，同时伴随runts，通常说明链路速率协商或线缆质量有问题。判断的关键是「哪个计数器在动」，因为不同计数器对应完全不同的故障类别：CRC/FCS指向信号质量，runt指向碰撞或短帧，giant指向MTU不一致，output drops指向拥塞或上游pause帧。

show mac address-table

读MAC地址表要关注三件事：同一MAC是否出现在多个端口，表项是否出现在错误的VLAN，以及某个端口的表项数量是否在短时间内剧烈波动。表项在两个端口之间来回迁移就是MAC抖动；某个下联口突然学习到成百上千个MAC，往往是接入了无管理的小交换机或出现了环路。配合show mac address-table count看每个VLAN的总量，比逐条查看更容易发现量级异常。

STP输出

STP相关输出先看角色再看时间。端口是Root、Designated还是Alternate决定了它是否应当转发；而show spanning-tree detail中的「from」与「occur」字段告诉你上次拓扑变更发生在多久之前。如果occur次数很大且from是一个很小的秒数，说明变更正在持续发生，这时应该逐个端口查看谁在沿时间线触发变化，重点关注连接终端设备的边缘端口是否配置了PortFast与BPDU Guard——未加保护的边缘端口收到BPDU就会引发拓扑变更。

常见误判与真实案例

第一类误判是把CRC错误当成软件Bug。CRC是链路层信号质量问题，软件改动无法改善，更换光模块、跳线或清洁光纤端面通常更快解决问题。第二类误判是把STP拓扑变更当成「网络抖动」而不加处理，实际上它会导致周期性丢包，且故障在链路监控上完全不可见。第三类误判是只测大包或只测小包，从而错过MTU问题或小报文路径的问题。

第四类误判在丢包与延迟的组合上：延迟升高但有丢包、延迟升高且无丢包、丢包但延迟正常，这三者的定位方向完全不同。延迟与丢包同时出现通常指向拥塞或物理层劣化；只有延迟升高而无丢包，多半是队列排队、CoPP限速或控制平面上送；只有丢包而延迟正常，则优先怀疑MAC抖动、STP变更和ASIC异常丢弃。把这些组合当成决策树的前两个分支，可以把现场排查的第一小时压缩掉一半。

案例研究：输入流控导致丢包

某案例中，接口接收方向流控导致对端设备缓冲积压，最终通过禁用输入流控解决：

Switch(config)# interface GigabitEthernet 1/0/5
Switch(config-if)# flowcontrol receive off

这个结论可以推广：pause帧会把拥塞向上游传播，因此一个超订端口就能让一台从未超过自身发送能力的设备产生队头阻塞。任何「利用率看起来不高但output drops持续增长」的接口，都应该检查它的flowcontrol设置。另外，软件Bug也可能导致延迟和丢包，建议用思科Bug搜索工具查询已知问题，并保持交换机运行推荐版本。

与其它型号的差异

排查思路可以复用，但命令和数据结构在不同平台上有差异，照搬会得出错误结论。Catalyst 2960/3750 等经典IOS平台使用show platform和show controllers系列命令，没有FED（Forwarding Engine Driver）层次的视图；Catalyst 3850/9000 系列运行IOS-XE，延迟和丢包相关的ASIC级信息主要来自show platform software fed与show platform hardware fed这两组命令，并且需要区分switch active与成员编号。

在堆叠或StackWise Virtual环境中，同一逻辑接口对应的物理端口可能位于不同成员，因此ifm mappings的意义比单机环境更重要：它告诉你要在哪个ASIC实例上继续深挖。Catalyst 9500/9600 这类高密度平台端口数和ASIC实例数更多，SPAN复制对ASIC带宽的影响也更明显，镜像规划需要留出更大余量。此外，IOS-XE的CoPP默认策略与老平台差异较大，升级之后出现「协议偶发中断但接口正常」的现象时，应优先复查控制平面策略而不是数据平面配置。

验证与回归步骤

任何改动之后，重新执行基线中的同一组命令，比较增长速率而不是绝对值。一个修复被验证成立的条件是：接口错误计数在一个完整业务周期内不再增长、STP拓扑变更计数保持平稳、并且从两端测得的延迟回到事件前基线。如果症状消失了但某个计数器仍在爬升，说明症状只是被掩盖，换个流量特征它还会回来。

回归时建议固定观察窗口（例如覆盖一个完整工作日），并在工单中记录计数器清零时刻与观察期长度——下一位工程师需要知道「修好了」在数据上是什么样子。对于间歇性故障，还应记录两次快照之间的流量特征变化，否则两次采集的差异无法归因到改动本身。

排错检查清单

只有一个端口丢包？先查物理层：错误计数、光模块、线缆、双工与速率。然后检查flowcontrol。
一个VLAN或广播域内丢包？按顺序查STP拓扑变更和MAC抖动。
延迟随负载增长？查缓冲与拥塞：output drops、队列统计，以及SPAN会话争抢ASIC带宽。
丢包但各处计数器都干净？查ASIC异常丢弃，再查CoPP的punt与CPU占用。
一切正常但应用仍报告丢包？把抓包点移向终端，检查MTU与路径MTU发现。
两个端口之间MAC来回迁移？开启MAC移动通知，按日志中的端口对定位环路或双归属配置。
改动之后如何收尾？重跑基线命令，比较增长速率，覆盖一个完整业务周期后再关闭工单。