1、S20/S21怎么定义SNMP访问的合法主机
S20/S21无法通过snmp-server关联ACL的常规方法来控制合法主机访问交换机的SNMP服务。只能通过host参数控制一个合法的主机IP的访问，如果多次配置，后来的会覆盖原先的。
Ruijie(config)#snmp-server
community ruijie host 1.1.1.1 //这样只允许1.1.1.1的主机访问该设备的snmp服务。
2、设备配置多个snmp
community是否会存在冲突
我司设备允许配置多个不同的snmp
community的团体属性，以便满足不同的服务器或者应用对设备的网管需求，所以不同的community间是并存关系不会冲突。
snmp-server
community 123 rw
snmp-server
community 456 ro
snmp-server
community 789 rw
3、我司交换机默认snmp服务是不是开启的，能够关闭吗
1）我司所有交换机的snmp-agent代理功能是开启的，也就是默认可以处理所有snmp的报文，但是如果本交换机上面没有配置snmp
community团体字的话，或者是这个认证字与服务器配置的不匹配的话，也会产生类似这样的报错：%SNMP-3-AUTHFAIL: Authentication
failure for SNMP req from host 54.214.18.121
2）如果你发现交换机的cpu很高时，对应的snmpd进程占有率很高，并且控制台一直报上述的snmp认证失败的log。你的设备没有网管的需求，也不需要配snmp功能，有关闭这个功能的需要的话，希望降低cpu的话，命令如下：
Ruijie(config)#no
enable service snmp-agent
4、交换机show cpu发现snmpd，printk_task两个进程cpu近100%，怎么解决
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。
5、我司交换机上常用的一些MIB以及对应的OID说明
常见咨询中的MIB OID值见附件
a、常见节点的OID值如上，与产品型号无关，通常是软件版本一致即可，如果发现读取中存在问题，请先确保软件版本为最新的；
b、如果产品停产，或者是存在早期软件，或者是需要读取的节点上述表格没有列出的，可以直接去版本管理系统上面下载对应软件的MIB交互件，先自己尝试查找
c、关于MIB的问题，如果涉及的节点为公有的，那么MIB说明交互件（excel表格）+MIB库文件可以直接公开，OID值也可以直接告知，或者自行查找excel表格；
d、关于MIB的问题，如果涉及的节点为私有的，那么MIB说明交互件（excel表格）+OID值可以公开，但是MIB库文件都为保密不公开，一律需要呼入4008111000通过CMG与我司签订完保密协议后，再通过邮件方式发送MIB库文件于客户；
e、通常RUIJIE打头的MIB库文件都为私有节点。
6、2952G-E，配置snmp
community的时候为明文，但是show run是加密串
snmp-server
community 7 0132564a3d1103 rw
与配置enable等密码类似，如果需要明文，需要关闭密码加密显示功能：
Ruijie(config)#no
service password-encryption