安顺市傲天动联个别AP双向峰值流量过大问题分析.docVIP

安顺市傲天动联个别AP双向峰值流量过大问题分析 故障发生地点：贵州移动安顺分公司 故障发生时间：2012年1月31日 设备型号：AQ2000-E2AN2、AQ3110-H、AQ2110-H 设备版本号：NX-V1.3.19 问题处理人：韦韬 问题现象描述： 1月31日接到安顺移动焦工电话，描述称在神州泰岳的网管上采集我司AP的流量数据时发现个别AP数据流量较大，请求解决。 问题定位过程： 接到客户电话后，立即着手排查故障产生的原因，联系神州泰岳工程师了解问题的具体现象，从网管上看出个别AP的无线侧峰值数据流量较大，每秒达到了2G左右，截图如下： 针对网管采集数据流量异常，一般来源于以下几个方面： AP由于硬件原因造成收发包异常 网管上的OID值和设备OID值不一致； AC上针对流量采集数据配置有误； AP软件Bug 首先登录到从网管上提取到数据流量较大的AP上，查看设备端口数据流量状态是否异常， 采集如下几个站点的AP数据： 区域 MAC 长安大厦 00:1f:64:e4:12:cd 长安大厦 00:1f:64:e4:19:93 长安大厦 00:1f:64:e4:12:b7 设备端口流量状态截图： AP01 MAC：00:1f:64:e4:12:cd AP02 MAC：00:1f:64:e4:19:93 AP03 MAC：00:1f:64:e4:12:b7 设备端口数据流量采集说明： 设备MAC 无线侧接收流量 无线侧发送流量 时长 00:1f:64:e4:12:cd 15.9Mib 275.9Mib 24H 00:1f:64:e4:19:93 4Gib 2.1Mib 24H 00:1f:64:e4:12:b7 1.4Mib 1.4Mib 24H 从上面所采集的数据可以看出无线侧数据流量最大的一台是00:1F:64:E4:19:93为4Gib，分析每秒数据流量为4096Mib/24/3600 0.047Mbps，数值在正常范围内。至此可以排除由于AP本身硬件原因造成的收发包异常的情况。 如果网管上OID值和我司产品的OID值不致也有可能导致问题的产生，因此随即前往省公司联系神州泰岳工程师核对双方数据采集OID值是否一值，从神州泰岳网管上提取出OID数值如下： AP无线侧流量 名称 OID 备注 ifInAvgSignal 1.3.6.1.4.1.31656.6.1.1.3.5.1.1 接收的信号平均强度 ifInErrors 1.3.6.1.4.1.31656.6.1.1.3.5.1.21 信道接收的总错包数 ifInHighSignal 1.3.6.1.4.1.31656.6.1.1.3.5.1.2 接收的最高信号强度 ifInLowSignal 1.3.6.1.4.1.31656.6.1.1.3.5.1.3 接收的最低信号强度 ifInOctets 1.3.6.1.4.1.31656.6.1.1.3.5.1.10 接收的数据包字节数 ifInPkts 1.3.6.1.4.1.31656.6.1.1.3.5.1.9 接收的数据包数 ifOutOctets 1.3.6.1.4.1.31656.6.1.1.3.5.1.11 发送的数据包字节数 ifOutPkts 1.3.6.1.4.1.31656.6.1.1.3.5.1.8 发送的数据包数 当前我司在贵州移动共部署了3台AC，分别为安顺、凯里、铜仁，从神州泰岳的网管数据分析出，目前仅安顺有个别AP数据峰值异常，为了更进一步查找出原因，再次对安顺、凯里、铜仁的数据配置进行分析，重点检查SNMP简单网络管理协议这一块，通过对三个地市的数据检查，安顺和凯里、铜仁的数据配置均一致；通过和总部研发沟通，这样的配置是没有问题的。 从目前已排查完的原因看出，网管上只有个别AP数据流量峰值异常，安顺、凯里、铜仁三个地方的AC型号、版本均一致，凯里和铜仁的AP型号中也包括了所有安顺AP的型号。至此初步怀疑可能由于AP版本（1.3.19）存在Bug，导致部分AP数据采集异常。 将目前AP的型号、版本号、组网架构和问题现象发回总部，要求研发对其故障现象进行浮现并定位问题所在。 通过2月4日一天时间的紧张排查，已经发现此故障是由于AP版本（1.3.19）在针对数据流量采集时算法问题导致上传到网管的数据异常，具体原因如下： 针对数据流理采集报文，在对报文计数时没有判断报文减去报头后的长度是否大于零，这样有些报文减去报头后变成了负数，而这个负数表示为无符号的整数即是一个很大的数，导致结果不合理。 由于只有在报文计数长度小于0为负数时，此种情况才会发生。这也就是为什么只有个别AP在网管上的无线则数据峰值不正常。 至此（2月6日），安顺移动个别AP网管无线侧峰值数