排查High CPU网络故障

引言：在日常网络管理中，CPU使用率高简称High CPU的问题会经常碰到。通常CPU进程高分中断高和进程高。中断高大多是由于实时的流量造成的，通过查询端口流量，处理相对容易，日常网管工作中，进程高，特别是IP Input进程引起的High CPU会时有发生。这里结合笔者最近刚刚处理的一起IP Input进程引起的High CPU问题，进行总结分析。

故障现象

最近在一次日常工作中，突然接到某台汇聚设备Cisco 6506短信告警。立刻远程登录该设备，运行show processes cpu sorted，发现CPU利用率已经高达99%，IP Input进程占了73%。正常情况下，该设备的CPU使用率都在10%以下。

图1 用show interface summary查看端口流量

故障排查

1.执行show interface或 show interface summary，查看哪些端口有较多的流量转发，以及这些接口是使用何种转发机制。建议执行本步骤之前，先执行clear counters，对计数进行清零，便于观察流量的增长情况。

笔者喜欢用show interface summary，相对简洁易看（如图1）。这里重点关注RXBS和RXPS两个指标的值，分别是每秒端口输入流量和数据包数。笔者发现，24号端口RXPS数为34241，远远大于同类型端口。查看端口配置发现，该端口为级联端口，进入该端口shutdown，CPU使用率立刻恢复正常。

故障基本可以确定是该端口下联设备所导致，联系下联单位网管处理即可。本着更加负责任的态度，决定揪出最终的“凶手”。

2.show ip traffic的输入，可以告诉我们是哪类流量增长最快，之后再检查一下这类流量是否需要上送CPU做进一步处理，就能得出大致结论，High CPU问题是哪类流量导致的。

3. 执 行debug ip packet detail，更直接查看到底是什么样的报文上送到CPU出 发CPU High，在执行该命令之前，建议在配置模式下先执行no logging console和no logging monitor。

执行完debug ip packet detail后3到5秒，立刻输入undebug all命令停止。

4.使用show logging查看结果，笔者发现某网段下两台主机以每2ms的速度发源端口为14001，目的地址为255.255.255.255，目的端口随机的UDP广播包。通过查询广播主机MAC地址对应的端口，正是第一步查到的24口，也验证了第一步的结果。

故障解决

找到“病根”问题自然好解决。有两种方法，第一种“简单粗暴法”，shutdown端口，通知故障单位网管，下联设备所属单位网管找到问题主机解决后，再回复。我们采用第二种：做ACL，只需要输入两条deny udp any eq 14001 any，permit ip any any，在故障端口24口in方向上应用。再次输入show processes cpu查看，恢复正常。

经验总结

在IOS中我们把SW process叫做IP Iput进程，简而言之就是数据报文没有被硬件switching cache或者CEF处理，而是punt到CPU去做进一步的处理。

在我们日常网络运维中，处理High CPU问题，除了采用我们上面的方法外，还可以依据实际情况用以下方式解决：如果您经验丰富去现场又方便，可以用Sniffer或Wireshark进行抓包；如果网络基础薄弱可以采取依次shutdown端口等同于现场依次拔网线，观察CPU的占用情况，从而发现故障端口。