【交换机】交换机show cpu发现snmpd，printk_task两个进程cpu近100%，怎么解决

发布时间：2013-09-26

点击量：10195

Ruijie-ACTIVE#sh cpu

=======================================

CPU Using Rate Information

CPU utilization in five seconds: 99.29%

CPU utilization in one minute : 55.20%

CPU utilization in five minutes: 18.05%

NO 5Sec 1Min 5Min Process

0 1.00% 1.01% 1.01% LISR INT

1 1.21% 1.44% 1.46% HISR INT

4 0.00% 0.01% 0.03% printk_task

11 93.64% 44.01% 8.88% snmpd //snmpd的cpu占用率很高

12 0.00% 0.00% 0.00% snmp_trapd

Ruijie-ACTIVE#sh cpu

=======================================

CPU Using Rate Information

CPU utilization in five seconds: 99.99%

CPU utilization in one minute : 99.98%

CPU utilization in five minutes: 66.60%

NO 5Sec 1Min 5Min Process

0 0.02% 0.60% 0.75% LISR INT

1 0.61% 0.68% 1.03% HISR INT

4 95.47% 91.14% 52.66% printk_task //当console口打印很多信息的时候，printk_task进程的cpu占用率很高

11 0.31% 0.47% 2.34% snmpd

12 0.00% 0.00% 0.00% snmp_trapd

show log有这样的刷屏的日志

*Jun 26 20:50:58: Ruijie-ACTIVE %SNMP-3-AUTHFAIL: Authentication failure for SNMP req from host 54.214.18.121

*Jun 26 20:50:59: Ruijie-ACTIVE %SNMP-3-AUTHFAIL: Authentication failure for SNMP req from host 54.214.18.122

snmpd：snmp模块初始化线程，接收、处理snmp请求报文并返回响应的报文，如果cpu占有率高的话，原因通常是受到网管端的报文攻击。

printk_task：打印日志信息/调试信息，如果cpu占有率高的话，原因通常是控制台在不停地打印日志信息或调试信息

SNMP模块的工作机制如下：

snmpd任务循环在监听客户端（也就是网管服务器）发送过来的snmp报文，当接收到报文后，会串行（因为是单任务处理）的处理各个从UDP缓冲中送到snmpd的报文，在处理报文过程，首先对报文进行解析，若发现报文携带的Community与设备上面配置的不合法，则会提示认证失败。若报文携带的Community与设备上面配置的相关合法，则会将报文送到具体的mib功能模块进行处理，等待处理完成后，返回处理结果，并响应respone报文。若外界网管发包的速率太快，1秒钟发送大量的报文，报文会先存放在udp socket缓冲区中，然后上层snmpd触发去获取udp缓冲区的报文，进行处理，大报文多的情况下，则有可能导致snmpd cpu占用较高。

printk_task任务的工作机制如下：

循环的监听是否有log信息要输出，当各个模块有log信息要输出时，则会触发printk_task打一条日志到终端控制台，在故障现象中，当一条SNMP请求报文认证失败时，会打出一条认证失败的log信息，若外界网管端，发送大量的snmp请求报文过来时，在都认证失败的情况下，将有可能导致设备一直需要输出SNMP认证失败的log信息，最终导致printk_task任务cpu升高。

故障原因：

通过以上信息可以初步判断是由校外地址54.214.18.121等非法的服务器不断发起SNMP扫描引起的，频率极高，因设备都开启了SNMP-AGENT功能，所以当COMMUNITY不对的时候就会不断送CPU处理，从而导致不断打印PRINT信息，使得CPU飙高，这时转发层面没有影响，但管理层面登陆很困难。

解决方法：

1）关于snmp的检测，print的控制台打印方面先前的版本做的不够优化，存在不合理，10.4（3b17）之后做了全面的优化，即使在遭受攻击或者有大量日志需要打印的时候也会使cpu保持一个良好的值，所以这个问题可以尝试通过升级软件到10.4（3b17）p3版本来优化解决。

2）如果不方便升级，那么还有另外一种方法，就是通过镜像抓包或者是了解到这些snmp报文从哪里端口发过来的，可以在相应的端口的IN方向配置ACL过滤掉snmp认证失败日志里面所提到的非法IP，这样报文在端口就被丢弃，不会送snmp模块处理，也就不会占用CPU，也就不会产品失败的log需要控制台消耗资源打印，例如

Ruijie(config)#ip access-list extended SNMPdeny

Ruijie(config-ext-nacl)#deny ip host 54.214.18.121 any

Ruijie(config-ext-nacl)#deny ip host 54.214.18.122 any

Ruijie(config-ext-nacl)#permit ip any any

Ruijie(config)#inter g1/1

Ruijie(config-if-GigabitEthernet 1/1)#ip access-group SNMPdeny in

注意：不能通过snmp-server community关联ACL的方式来解决，因为这样只是简单使snmp认证报文当不满足ACL条件的时候失败，但是实际snmp报文是已经送cpu处理了，虽然最终攻击者snmp认证失败，但是设备的cpu会因此还是很高，并且控制台还是会打印snmp失败log。