SNMP网管测试指导书.docx
《SNMP网管测试指导书.docx》由会员分享，可在线阅读，更多相关《SNMP网管测试指导书.docx（43页珍藏版）》请在冰豆网上搜索。
SNMP网管测试指导书
网管测试指导书
（二）
------张晨悦
目录
一．.测试前的准备工作1
①.搭建环境2
②.MIB工具的使用2
二．部分节点的测试方法及技巧4
①.普通节点4
②.告警10
（1）告警制造前的准备工作11
（2）部分告警制造过程及告警读出值11
1．CPU使用率过高告警11
2．CPU使用率过高告警清除12
3．内存利用率过高告警13
4．内存使用率过高告警清除14
5．AP无线监视工作模式变更告警15
6．SSID密钥冲突告警16
7．AP间同频干扰告警16
8．AP间同频干扰告警清除17
9．AP邻频干扰告警18
10．AP邻频干扰告警清除19
11．非法AP告警20
12．非法AP告警清除21
13．终端干扰告警22
14．终端干扰告警清除23
15．无线链路终端告警24
16．无线链路终端告警清除25
17．AP无法增加新关联用户告警25
18．AP无法增加新关联用户告警清除26
19．无线链路变更通告27
20．终端鉴权失败通告28
21．终端关联失败告警29
22．软件升级失败通告30
③.测试中规避项测试说明31
三．网管测试总结32
一．.测试前的准备工作
经过了两个月的学习，学到了很多东西，其中，网管测试是重中之重，并且去乌鲁木齐出差所做的工作也是网管测试。
下面，我就浅谈一些我对网管测试的理解以及测试中的一点总结。
①.搭建环境
网管测试我们使用的是MIB工具。
进行一个网管测试，需要的是测试的版本（img文件或bin文件），因为特定的版本对应特定的MIB文件，如果不匹配，测试就不能进行。
其次需要的是MIB文件，也就是测试的核心文件。
首先先进行连线
②.MIB工具的使用
连好线后，安装MIB工具。
安装好MIB工具后，打开MIB文件，如：
打开后，点击“File”“Compile”进行编译。
此处注意：
要先在串口上cat/etc/.sys.bin以下，看看需要升级后的版本中的企业码和该处的是否一样，不是则选择替换，替换成和版本相同的企业码。
进行编译（Compile）时，应该会弹出如下窗口：
如果没弹出，原因是该MIB文件放在了中文目录下。
只需将其放在英文目录下便可成功编译。
编译成功后保存编译后的文件。
接着打开MIBBrowser
进入页面后，在此处填写该型号AP的IP地址
在MIB目录下找到刚刚编译过的文件，将其导入到上面。
填好后点击右边的连接按键，后应出现如图所示界面
此时，证明MIBBrowser已经成功连接上了AP
接下来就是按照节点表来读节点值了。
二．部分节点的测试方法及技巧
①.普通节点
在测试中，我遇到了以下几个节点是比较难测的，经过多方询问，最终搞清楚了这些节点的测试方法，在此分享一下。
密钥值
1.3.6.1.4.1.3902.1.6.2.1.7
问题：
测试出来的值为
1:
presharekey.1.1（octetstring）<1D><1C><18><1D><19><1C><1D><1C><18><1C><1C>[1D.1C.18.1D.19.1C.1D.1C.18.1C.1C（hex）]
该节点设置了密钥，为什么显示不出来？
答：
该节点的显示方式是以密文方式显示出来的。
这样其安全性更高。
接收到的管理帧的数量
1.3.6.1.4.1.3902.1.5.2.1.173
测试方法：
1．开启无线接口，添加一个SSID
2．查询“接收到的管理帧的数量”节点数值
3．使用一个STA连接上该SSID
4．再次查询“接受到的管理帧的数量”
5．有合理增加即可
这里的合理增加是指增加量相对于读出的值而定的，比如读出值为200，但是增加量达到了150，这就存在问题。
相反，如果读出值为20000000，增加量达到了150，就属于合理增加。
另外，如果读出值过大也应当注意，此时的读出值也可能是不正常的值。
接收到的控制帧的数量
1.3.6.1.4.1.3902.1.5.2.1.174
测试方法：
1．开启无线接口，添加一个SSID，使用一个STA连接上该SSID。
2．查询“接收到的控制帧的数量”节点数值
3．使用该STA向APPING大包
4．查询“接收到的控制帧的数量”节点数值
5．有合理增加即可（ping几个包，就增加几个）
AP接收到的终端的当前信号强度
1.3.6.1.4.1.3902.1.5.4.1.116
测试方法：
1．将一个STA关联到该AP，并且PING包
2．查询“AP接收到的终端的当前信号”节点值
3．将STA远离AP，但是不至于无线断掉
4．查询“AP接收到的终端的当前信号”节点值
5．节点值减少
这里其实不好测，如果离得距离远了或者周边的干扰过大，都连不上，这还是要看平时对AP无线有效范围的理解。
无线端口updown次数
1.3.6.1.4.1.3902.1.5.2.1.216
测试方法：
1．打开AP页面，找到无线配置页面
2．查询“无线端口updown次数”节点值
3．将无线配置页面中的启用无线勾掉。
4．查询“无线端口updown次数”节点值
5．节点值加1，视为正常。
这个还比较好测试，但是如果是有线端口的updown怎么测试呢？
端口updown次数
1.3.6.1.4.1.3902.1.5.1.31
这里我试验过，如果使用瘦AP，测试不出来，需要使用胖AP。
1．查询“端口updown次数”节点值
2．将网线拔掉再接上
3．查询“端口updown次数”节点值
4．节点值增加2视为正常
如果使用瘦AP，将网线拔掉后再接上，该AP从AC获得的地址就会改变，因此需要在MIB浏览器上填入新的IP，这样许多数据就会清空。
这时读出来的端口updown次数节点值为0，但是使用胖AP的时候就不会发生这个情况。
发射功率配置
1.3.6.1.4.1.3902.1.4.1.1.105
功率调整步长
1.3.6.1.4.1.3902.1.4.1.1.106
比如，读取功率调整步长节点值为2
则在发射功率配置节点上set-1表示当前功率+（-1）X步长
这样设置后的功率就为原来基础上减去2dBm
更改后为了证实验证后的结果，可以在串口查询
输入iwconfig后，查询STA的接入点下的TX-Power
最大允许的关联终端数量
1.3.6.1.4.1.3902.1.6.2.1.23
测试方法：
1．查询“最大允许的关联终端数量”，并设置值为1
2．使用一个STA关联上该AP。
接着使用其他多个STA去关联该AP
3．预期结果是其他AP都无法关联上该AP
丢包率
1.3.6.1.4.1.3902.1.5.2.1.101
测试方法：
使用STA关联上AP后，STA对着APping大包，如ping172.25.4.42-t–l40000，这样有的时候就会出现requesttimedout。
出现了很多，就以为丢包率很大。
但是我问了研发人员，他们说，有的时候网络不通，包并没有发到AP上，这时也会出现requesttimedout，这样就不算是丢包了。
因此，丢包率很低属于正常情况。
终端上行最大速率
1.3.6.1.4.1.3902.1.6.2.1.34
终端下行最大速率
1.3.6.1.4.1.3902.1.6.2.1.35
测试方法：
1．查询“终端上行最大速率”和“终端下行最大速率”的节点值。
2．使用STA连接上AP的一个SSID，使用chariot进行吞吐量测试，得出结果。
3．设置“终端上行最大速率”和“终端下行最大速率”中对应的SSID值（合理值，比如第一次chariot测试的值是18，在此，设置为10就可，但是设置为30，40就没效果了），其中，设置出的值的单位默认为Kbps
4．使用chariot测试出更改后的值
5．后者测出的值的大小范围应当和设置值相差不大
可疑终端列表
1.3.6.1.4.1.8458.1.4.9.5
测试方法：
这里需要设置多个节点值。
1．打开节点wlanFloodCheckEnable，将其值设置为enable。
2．wlanFloodCheckInterval节点的意思是时间范围，AP会在这个时间范围内扫描符合设置的STAmac地址。
将其值设置为100左右即可，表示100秒。
3．wlanActiveBlackThreld节点的意思是无线包的门限值，如果在特定时间内无线包的数量超过了该门限值，AP便会加入黑名单。
设置为2即可，不能设置为1
4．wlanActiveBlackTime节点的意思是mac加入黑名单中持续的时间。
时间设置为稍微大一点，比如60即可。
5．将这些值设定好以后，还需要做的是将AP的一个VAP中的最大客户数设定为1，这样只有一个STA能够加入该AP。
6．使用STA1连接上AP后，使用STA2持续连接该AP，这时，STA2便会向AP发送特定的无线包。
当发送的无线包数大于2时，该STA的MAC便自动加入了黑名单中。
例如其节点读出值为1:
wlanActiveBlackMac.0（octetstring）#1（）#2（）#3（6,00:
19:
d2:
97:
b7:
84,1292467858,1292467858,06:
11:
22:
11:
22:
11,0,-22;）#4（）#5（）
这个节点中，读出值中的#1（）#2（）#3（）#4（）#5（）指的是泛洪攻击类型。
其类型分别是：
#1认证#2解除认证#3关联#4解除关联#5重关联，共五种。
这里在#3的后面，说明该SSID加入黑名单的原因是在关联的过程中被泛洪攻击。
括号中的“6”指6信道；“00:
19:
d2:
97:
b7:
84”指被泛洪攻击的STAmac地址；“1292467858，1292467858”指的是第一次探测到的时间和最后一次探测到的时间（秒），这个时间是从1970年1月1日为0秒计算至今的时间；“06:
11:
22:
11:
22:
11”是指BSSID；“0”指的是AdHoc状态为0；“-22”指的是此时的信号强度。
用户重关联成功次数
1.3.6.1.4.1.8458.3.1.1.3.23.1.12
测试方法：
该节点的测试需要用到AP的漫游。
就是使用两台AP（记为AP1，AP2），连接上AC后，加入相同的分组，这样就能下发到相同的SSID。
使用STA连接上AP1，然后开启AP2，使用MIB浏览器读取AP2的该节点值。
记做a。
AP1和AP2都要放在STA能够连接上的范围内。
这时将AP1断电，此时的STA会产生短暂的断电，接着又连接上了AP。
此时再读取AP2的节点值，记做b。
b的值应该在a的基础上有增加。
如图所示：
①.开启AP1，使用STA连接上AP1。
读取AP2的该节点值。
②.开启AP2
③.关闭AP1，STA便会自动连接上AP2
端口发送非单播包数
1.3.6.1.4.1.32870.1.5.1.33
端口接收非单播包数
1.3.6.1.4.1.32870.1.5.1.32
测试方法：
由于是端口发送和接收的非单播包数，节点名称为ethernetTxNonUnicasPtks和ethernetRxNonUnicasPtks，因此这里使用一台AP与PC连接，假设使用的胖模式，AP的地址为192.168.0.228，PC的地址为192.168.0.100。
这时在PC上运行telnet192.168.0.228。
进入AP后，Ping192.168.0.1。
然后读取端口发送的非单播包数，能发现节点值在不断增加。
同样的，使用PC去ping192.168.0.1，然后查询端口接收的非单播包数，能发现节点值在不断增加。
接收到的管理帧的数量
1.3.6.1.4.1.32870.1.5.2.1.173
测试方法：
启用AP的无线接口，使之正常工作。
然后查询“接收到的管理帧的数量”节点值，记录该值。
此时将一个STA连接上该AP，会发现该节点值有增加。
发送的管理帧的数量
1.3.6.1.4.1.32870.1.5.2.1.176
测试方法：
启用AP的无线接口，使之正常工作。
然后查询“发送到的管理帧的数量”节点值，记录该值。
将STA连接到此AP，在该STA上向APping包。
然后再次查询“发送的管理帧的数量”会发现节点值有所增加。
接收到的控制帧的数量
1.3.6.1.4.1.32870.1.5.2.1.174
测试方法：
启用AP的无线接口，使之正常工作。
然后查询“接收到的控制帧的数量”节点值，记录该值。
然后使用STA连接上AP。
然后查询节点1.3.6.1.4.1.3902.1.4.1.1.6，该节点为RTS门限值，默认为最大的2347。
修改其值为500，意思是发送或接收的包的长度如果大于500，将被剪切成几部分。
然后使用STA项APping包，例如ping192.168.0.228–l1000。
然后查询“接收到的控制帧的数量”节点值，发现有增加。
发送的控制帧的数量
1.3.6.1.4.1.32870.1.5.2.1.177
测试方法：
启用AP的无线接口，使之正常工作。
然后查询“发送到的控制帧的数量”节点值，记录该值。
然后使用STA连接上AP。
然后查询节点1.3.6.1.4.1.3902.1.4.1.1.6，该节点为RTS门限值，默认为最大的2347。
修改其值为500，意思是发送或接收的包的长度如果大于500，将被剪切成几部分。
然后telnet192.168.0.228，登陆上AP，由AP向PCping包，如ping192.168.0.100–l1000，然后查询“发送的控制帧的数量”节点值，发现有增加。
接收到的数据帧的数量
1.3.6.1.4.1.32870.1.5.2.1.175
测试方法：
启用AP的无线接口，使之正常工作。
然后查询“接收到的数据帧的数量”节点值，记录该值。
使用STA连接上AP后，向APping包。
随后查询“接收到的数据帧的数量”节点值，发现有一定增加。
发送的数据帧的数量
1.3.6.1.4.1.32870.1.5.2.1.178
测试方法：
启用AP的无线接口，使之正常工作。
然后查询“发送的数据帧的数量”节点值，记录该值。
使用STA连接上AP后，telnet上AP后，使用AP向STAping包。
然后查询“发送的数据帧的数量”节点值，发现有一定增加。
用户侧（无线侧）接收流量
1.3.6.1.4.1.32870.1.5.2.1.33
测试方法：
启动AP的无线接口，使之正常工作。
然后查询“用户侧（无线侧）接收流量”。
然后使用STA连接上AP。
打开chariot，进行吞吐量测试。
然后在如图所示的地方查询数值。
由于节点的读出值的单位为KBps，则在chariot的页面上也要做相应的更改。
选择成KBps，这样页面中也会呈现相同的单位。
只要节点读出值和chariot读出值的差异在10%以内就算测试通过。
②.告警
在进行网管测试时，关于系统信息配置方面，接口配置方面之类的固定了的节点还是很好能读出来的，但是有些节点值需要人为的创造环境才能测试出来。
给我影响最深，也是我最不好把握的就是告警的测试。
告警包括很多，比如CPU利用率过高告警，内存利用率过高告警，AP上下线告警，AP无线监控工作模式变更告警，AP间的同频邻频干扰告警，终端干扰告警，无线信道变更告警以及无线链路终端告警等等，这些告警都需要人为的制造环境才能将其一一演示出。
下面我谈谈几个告警的制造方法。
（1）告警制造前的准备工作
告警测试前，首先应当确认的是AP发送的告警能否传达至自己的PC。
因此需要进行设置。
可疑在MIB浏览器上读取节点1.3.6.1.4.1.XXXX.1.7.5，然后将该节点值更改为自己PC的IP地址。
接着读取该节点值，确认读出的IP是自己PC的IP。
也可以通过页面修改。
使用浏览器登录AP的管理页面，在如下界面修改TRAP服务器地址。
（2）部分告警制造过程及告警读出值
1．CPU使用率过高告警
Step1：
读取1.3.6.1.4.1.XXXX.1.1.23节点值，记录当前CPU利用率
Step2：
读取1.3.6.1.4.1.XXXX.1.1.121节点值，设置其值为1。
意思是当CPU的使用率超过1%的时候AP会告警。
Step3：
使用STA关联上AP后，向APping包，多ping几个。
确定节点中是否出现CPUHighTrap。
告警读出值
radiusAuthPrimaryServerPort.52
Messagereceptiondate:
2010-12-16
Messagereceptiontime:
18:
45:
47.140
Timestamp:
0days00h:
01m:
24s.75th
Messagetype:
Notification（Trap）
Protocolversion:
SNMPv2c
Transport:
IP/UDP
Agent
Address:
172.25.6.45
Port:
3076
Manager
Address:
172.25.39.29
Port:
162
Community:
public
Bindings（14）
Binding#1:
sysUpTime.0***（timeticks）0days00h:
01m:
24s.75th
Binding#2:
internet.6.3.1.1.4.1.0***（oid）radiusAuthPrimaryServerPort.52
Binding#3:
zt.2.1.1.2.1.0***（octets）00251263b02a
Binding#4:
zt.2.1.1.2.2.0***（octets）00000000ZTEZXV10W815
Binding#5:
zt.2.1.1.2.3.0***（int32）2
Binding#6:
zt.2.1.1.2.4.0***（octets）devicetrap
Binding#7:
zt.2.1.1.2.5.0***（int32）21042
Binding#8:
zt.2.1.1.2.6.0***（octets）CPUHighTrap&Usage=83%
Binding#9:
zt.2.1.1.2.7.0***（octets）10/12/1618:
46:
38
Binding#10:
zt.2.1.1.2.8.0***（int32）1
Binding#11:
zt.2.1.1.2.9.0***（octets）CPUHighTrap
Binding#12:
zt.2.1.1.2.10.0***（octets）Usage=83%
Binding#13:
zt.3.1.3.1.0.0***（octets）00:
25:
12:
63:
B0:
2A
Binding#14:
zt.3.1.3.3***（octets）CPUHighTrap&Usage=83%
2．CPU使用率过高告警清除
Step1：
当出现CPUHighTrap后，设置1.3.6.1.4.1.XXXX.1.1.121节点值为99。
意思是当CPU使用率超过99%的时候告警。
Step2：
确认告警中是否出现CPUHighRecovTrap
告警读出值
wlanBasicSettingTable.2.56
Messagereceptiondate:
2010-12-16
Messagereceptiontime:
18:
51:
16.656
Timestamp:
0days00h:
06m:
53s.86th
Messagetype:
Notification（Trap）
Protocolversion:
SNMPv2c
Transport:
IP/UDP
Agent
Address:
172.25.6.45
Port:
3076
Manager
Address:
172.25.39.29
Port:
162
Community:
public
Bindings（14）
Binding#1:
sysUpTime.0***（timeticks）0days00h:
06m:
53s.86th
Binding#2:
internet.6.3.1.1.4.1.0***（oid）wlanBasicSettingTable.2.56
Binding#3:
zt.2.1.1.2.1.0***（octets）00251263b02a
Binding#4:
zt.2.1.1.2.2.0***（octets）00000000ZTEZXV10W815
Binding#5:
zt.2.1.1.2.3.0***（int32）2
Binding#6:
zt.2.1.1.2.4.0***（octets）devicetrap
Binding#7:
zt.2.1.1.2.5.0***（int32）21042
Binding#8:
zt.2.1.1.2.6.0***（octets）CPUHighRecovTrap&Usage=52%
Binding#9:
zt.2.1.1.2.7.0***（octets）10/12/1618:
52:
03
Binding#10:
zt.2.1.1.2.8.0***（int32）1
Binding#11:
zt.2.1.1.2.9.0***（octets）CPUHighRecovTrap
Binding#12:
zt.2.1.1.2.10.0***（octets）Usage=52%
Binding#13:
zt.3.1.3.1.0.0***（octets）00:
25:
12:
63:
B0:
2A
Binding#14:
zt.3.1.3.3***（octets）CPUHighRecovTrapusage0%
3．内存利用率过高告警
Step1：
读取1.3.6.1.4.1.XXXX.1.1.24节点值，读出当前内存的使用率
Step2：
设置1.3.6.1.4.1.XXXX.1.1.122的值为1。
意思是当内存的使用率超过1%时，AP告警
Step3：
使用STA关联上AP后，向APping包，多ping几个。
确定节点中是否出现
MemoryHighTrap
告警读出值
radiusAuthPrimaryServerPort.53
Messagereceptiondate:
2010-12-16
Messagereceptiontime:
18:
44:
47.625
Timesta
升级会员 