WLAN无线网络维护及优化问题处理指导手册.doc
《WLAN无线网络维护及优化问题处理指导手册.doc》由会员分享，可在线阅读，更多相关《WLAN无线网络维护及优化问题处理指导手册.doc（107页珍藏版）》请在冰点文库上搜索。
WLAN无线网络维护问题处理
指导手册（V1.0）
目录
第一章设备维护篇 4
1.AC故障问题 4
1.1登陆成功率（非用户原因）低问题原因分析 4
1.2登陆成功率（非用户原因）低问题案例分析 5
1.3错误话单问题原因分析 11
1.4错误话单问题案例分析 12
1.5其他AC设备故障 16
2.AP故障问题 20
2.1AP设备问题 22
2.2POE交换机问题 24
2.3断电问题 26
2.4传输问题 27
2.5数据配置问题 29
第二章业务应用篇 33
1.无法搜索到移动信号问题 33
1.1无法搜索到网络问题处理流程 34
1.2无法搜索到网络问题案例 35
2.无法关联问题 45
2.1无法关联问题处理流程 46
2.2无法关联问题案例 46
3.无法上网问题 53
3.1无法上网问题处理流程 53
3.2无法上网问题案例 54
4.速度慢问题 67
4.1速度慢问题处理流程 67
4.2速度慢问题案例 68
5.掉线率高问题 94
5.1掉线率高问题处理流程 94
5.2掉线率高问题案例 95
6.用户不能正常登录问题 103
6.1用户不能正常登录问题处理流程 104
6.2用户不能正常登录问题案例 105
第一章设备维护篇
1.AC故障问题
1.1登陆成功率（非用户原因）低问题原因分析
登陆成功率（非用户原因）=1-上线bas错误/登陆申请总次数，所有登陆成功率（非用户原因）主要与上线bas错误有关。
上线bas错误的定义：
在认证过程中ac返回了网络错误的错误码（4），或者返回未知错误码，或者接收ACK-CHALLENGE或ACK_AUTH包超时15秒失败，一般认为是网络或设备原因。
在用户上线流程图中，和发生上线bas相关的交互步骤：
（1）如果查询成功，PortalServer向AC请求Challenge；
（2）AC分配Challenge给PortalServer；
（3）PortalServer向AC发起认证请求；
（4）而后AC进行Radius认证，获得Radius认证结果；
（5）AC向PortalServer送认证结果；
用户上线Chap认证流程图
上线bas错误包括以下四种情况：
（1）AC未发送Ack_challenge、Ack_auth或者发往Portal服务器的Ack_challenge、Ack_auth丢失。
（2）Portal服务器接收Ack_challenge、Ack_auth超时15秒。
（3）AC发往Portal服务器的Ack_challenge或者Ack_auth的报文带有errcode4信息。
以下2种情况AC将发送带有错误码4的报文：
AC在准备发送Ack_challenge时,发现Req_challenge报文中的保留字段不为0或者AC没有能产生16位的挑战值，此时AC将发送携带错误码为4的Ack_challenge报文到Portal,表示AC设备告诉PortalServer此用户请求Challenge失败。
AC在收到REQ_AUTH时,发现该报文中的REQ_ID和之前Req_challenge中的REQ_ID不相等，从而认为该用户登录操作出现异常，发送携带有错误码4的AUTH_ACK报文到Portal，表示AC设备告诉PortalServer此用户认证失败。
（4）AC设备设计缺陷，在发往Portal服务器的Ack_challenge或者Ack_auth的报文中带有其他未知errcode值信息。
上线bas错误产生的主要原因：
（1）AC设备问题
（2）参数设置问题
（3）设备性能问题
（4）网络丢包问题
1.2登陆成功率（非用户原因）低问题案例分析
1.2.1AC设备问题
主要原因：
（1）AC因设计缺陷，在发往Portal服务器的Ack_challenge、Ack_auth的报文中带有其他未知errcode值信息。
（2）AC内进程发生错误导致无法响应Portal服务器的请求，导致Portal服务器无法接收到响应报文，记录为上线bas错误。
（3）AC和Portal之间通过UDP报文进行交互，在交互过程中UDP端口学习错误，将导致Portal无法接收到正确的响应报文，发生上线bas错误。
（4）网络丢包导致AC和Portal之间的数据包丢失重传，因丢包重传引发超时，发生上线bas错误。
相关案例分析：
案例一：
AC响应Portal服务器的认证报文中携带有未知errcode值，发生上线bas错误。
故障描述：
某厂家现网AC发生认证接通率低的问题，通过抓包分析发现，在AC相应Portal的报文中存在errcode10。
AC设备版本设计缺陷导致在发往Portal服务器的Ack_challenge、Ack_auth的报文中存在错误代码errcode10，此代码不符合移动集团规范，Portal将带有errcode10消息的响应报文记录为上线bas错误。
导致用户认证失败。
解决方案：
依据《中国移动WLAN用户接入流程技术规范（WEB）V3.0.0》要求，在AC版本中，将errcode10值修改为符合规范的errcode值，解决因未知errcode值导致的上线bas错误。
案例二：
AC内认证模块异常退出，导致发生上线bas错误。
故障描述：
某厂家设备出现大量上线BAS错误通过AC日志分析发现AC认证模块发生重启的现象。
进一步根据AC调试信息进行定位：
分析认证代码后发现认证模块在发送停止计费时有空指针的现象。
如果进程发 生空指针那就会出现异常，从而引起进程退出。
分析认证逻辑后发现在认证模块启用了STOP机制，也就是防止用户吊死在RadiusServer的功能情况下发送STOP停止计费报文就会有空指针的风险，这就会导致认证模块异常退出。
在认证模块退出情况下，如果发起认证请求，则AC无法响应报文challenge或Auth报文导致认证，就会造成上线bas错误。
解决方案：
通过升级新版本，修改认证模块代码，解决因认证模块异常退出而发生上线bas错误的问题。
案例三：
交互过程中AC学习UDP端口号错误，导致发生上线bas错误。
故障描述：
AC和Portal之间通过UDP报文进行交互。
通过抓包发现AC存在UDP端口号学习错误的问题。
在交互过程中，如果期间有其他用户进行认证交互，AC会学习到其他用户的端口号。
以这个端口号给Portal回应确认报文，AC无法识别该确认消息，发生上线bas错误。
用户将显示认证失败，不能正常登录使用。
2011-03-0211:
18:
53.251408igw8021x[2248]:
[P]STA（10.0.20.75）ReceiveREQ_AUTHfromPortalServer（221.176.1.140）,port:
39777size:
47
2011-03-0211:
18:
53.291442igw8021x[2248]:
[P]STA（10.0.23.138）ReceiveREQ_LOGOUTfromPortalServer（221.176.1.140）,port:
54555size:
16
2011-03-0211:
18:
53.370251igw8021x[2248]:
[P]STA（10.0.20.75）SendACK_AUTHwithErrcode0toPortalServer（221.176.1.140）,destport:
54555size:
16
解决方案：
在认证模块中增加代码，记录下每一用户Portal请求报文的端口号，以该端口号响应Portal的请求，解决UDP端口学习错误的问题。
1.2.2参数设置问题
AC内关于认证计费的参数设置不当，增加AC内认证模块出现异常的机率，导致上线bas错误的发生。
相关案例分析：
案例一：
记账间隔时间设置太短，导致出现认证接通率低的问题。
故障描述：
AC内认证计费参数有一项记账间隔时间，该值作用为每隔一个记账间隔时间AC对所有用户进行一次检测其是否在线，如果在线则针对每用户给Radius发送一条续费报文。
表明该用户在线，对用户计费信息进行更新，确保计费的准确性。
如果记账间隔时间设置太短，将导致AC频繁对在线用户进行检测并向Radius发送续费报文。
当用户量大时，AC内认证模块将出现繁忙。
无法及时响应Portal服务器发出的请求报文，产生上线bas错误，导致用户登录失败。
抓包截图
记账间隔时间设置太短，导致AC和Radius之间进行大量的续费报文交互，从上面的截图可以看出，截图中的26个数据报文中仅有一个是AC和Portal服务器交互的报文，其他的25个数据包都是AC和Radius之间的续费报文。
占比达到了96%。
大量的续费报文导致了AC认证模块繁忙，消耗大量AC资源，无法AC及时响应Portal发出的认证请求报文。
从问题发生的AC和时间来看。
该问题发生在业务量较大的AC，且发生的时间点一般发生在上网的高峰期。
在5月份发现部分厂家AC内记账间隔时间采用默认值，且默认值设置太短，设置成了30秒，导致AC认证模块出现繁忙，无法及时响应Portal服务器发出的请求报文，产生了大量的上线bas错误，出现认证接通率低的问题。
解决方案：
将记账间隔时间设置为900秒或更长（注：
该参数raduis尚未使用，部分可以设置为0的厂家可以关闭该参数），防止认证模块出现繁忙导致发生大量上线bas错误。
1.2.3设备性能问题
AC内开启了某些功能（SNMP/NAT）后，导致AC内资源消耗过大或者功能实现效率不高。
从而导致出现上线bas错误。
相关案例分析：
案例一：
AC开启SNMP服务后，出现认证接通率低的问题。
故障描述：
某厂家AC设备在开启了SNMP服务后，SNMP进程对AC的CPU资源消耗较大；在业务量大的时候，将会因CPU利用率高而出现认证模块异常，出现上线bas错误。
解决方案：
通过优化AC内SNMP进程代码及资源调度机制，降低SNMP进程对资源的消耗。
避免因SNMP进程对资源的消耗，导致AC认证模块出现异常，导致出现上线bas错误。
案例二：
AC开启NAT地址转换功能后，出现接通率低的问题。
故障描述：
长沙市目前WLAN用户IP地址分配采取私网IP地址+NAT的实施方案，AC为用户分配私网IP地址，同时在AC上启用NAT功能进行地址转换。
AC实施地址转换需要通过软件功能实现，在地址转换时需要通过CPU计算处理。
存在地址转换产生时延和效率不高的问题。
地址转换产生的时延较大，从交互过程中AC收到用户登录请求开始计算，收到Ack_challenge、Ack_auth消息时间超过15秒超时将记录为上线bas错误。
解决方案：
WLAN用户使用公网地址。
通过NAT转换专业设备进行地址转换，解决地址转换存在时延和效率不高问题而产生上线bas错误。
案例三：
AC配置关联用户通过SSID匹配portal后，出现认证接通率低的问题。
故障描述：
某厂家AC配置关联用户通过SSID匹配portal后，产生的Wirelessstation表项数据非常庞大，如图：
用户关联成功后，AC上的Wirelessstation表中就会增加此用户的mac地址与SSID关联的信息，AC通过这个表项中的SSID来给用户推送相关的portal页面，当AC长时间运行后，关联的用户将会越来越多，最终导致CPU利用率高、内存溢出，出现上线bas错误。
解决方案：
AC通过命令removewireless-stationall来清除内存中的Wirelessstation表，同时关闭根据SSID域推送portal页面的开关，根据VLAN号来推送portal。
1.2.4网络丢包时延问题
网络因设备兼容性问题或网络不稳定，而出现丢包和时延大的问题。
AC和Portal之间的交互采用不可靠的UDP报文，UDP报文在传输过程中如果出现报文丢失，UDP协议层次将不会对其进行重传，因此在AC内设计了重传机制，如果AC发送报文后5秒钟未能收到下一步交互报文，则会对发出的数据进行重传。
虽然设计了重传机制，但是可能因为重传而导致超时。
可能导致AC和Portal之间交互的报文丢失，或者因时延大问题导致导致整个交互过程超时15秒，发生上线bas错误。
相关案例分析：
案例一：
网络设备端口匹配问题导致出现网络丢包现象，导致出现认证接通率低的问题。
故障描述：
AC出现了大量的上线bas错误。
从AC对Portal进行ping测试发现网络丢包率很高，达到了20%。
忙时21:
30—0:
00，丢包率为24%，AP出现闪断掉线。
通过分析发现，AC的端口状态为自适应状态，而AC的对端设备端口设置为速率强制1000M。
把端口属性改为自适应后：
忙时21:
30—0:
00,丢包率为3%--6%，AP闪断掉线的数量减少。
因各厂家设备之间兼容匹配问题，导致端口无法相互协商自适应。
导致出现网络丢包。
丢包导致AC和Portal之间交互报文丢失、重传。
因交互超时而发生大量的上线bas错误。
解决方案：
将AC对端设备同样设置为自适应状态，解决端口协商问题引发丢包导致的上线bas错误。
1.3错误话单问题原因分析
错单产生原因分析：
产生错误话单原因均为计费报文中未携带NAS-ID号或携带的NAS-ID错误，导致在BOSS系统内因NAS-ID值不合法而无法生成账单。
AC内NAS-ID值的对应关系主要有3中，基于AP、基于业务VLAN和基于用户IP地址，目前主要采用基于VLAN对应NAS-ID值。
Radius计费报文内容：
Radius计费报文中包含用户帐号（user-name）、NAS-ID、上网时长（acct-session-time）、计费报文类型（acct-status-type）等内容。
以下3类原因将产生错误话单：
（1）为当用户下线时，AC给Radius发送计费结束报文时，无法依据对应关系匹配到NAS-ID，如果无法匹配到NAS-ID，则会自动填入00-00-00-00-00-00到计费报文中。
（2）NAS-ID配置错误或者格式不正确，导致计费报文中携带的NAS-ID值错误。
（3）AC设备问题导致无法依据匹配关系携带正确的NAS-ID信息。
1.4错误话单问题案例分析
1.4.1NAS-ID匹配错误
AC内没有正确配置NAS-ID的对应信息，或者因对设备操作导致NAS-ID的配置信息丢失。
当有用户发起下线请求时，将无法携带正确的NAS-ID信息，产生NAS-ID为0类型的错误话单。
相关案例分析：
案例一：
AC内业务VLAN配置错误导致出现错误话单。
故障描述：
AC下出现F150类型的错误话单，错误话单原因为计费报文中NAS-ID值为00-00-00-00-00-00，经过对AC的数据检查发现站点明城公馆的6信道模板配置了一个业务VLAN3792，该VLAN在AC的VLAN列表中存在，但是该业务VLAN所对应的热点为工程期间热点，没有规划配置NAS-ID。
由于AP—AC之间的业务数据走私有CAPWAP隧道，因此即便VLAN配置错误，用户上网数据仍然可以通过交换机等传输设备，用户可以正常上网。
由于业务VLAN配置错误，导致出现无法匹配NAS-ID的问题。
因此该模板下的用户计费报文无法携带NAS-ID，出现错误话单。
VLAN配置错误
解决方案：
将瘦AP配置模板中业务VLAN修改正确即可解决问题。
案例二：
主备备份操作失误导致出现错误话单。
故障描述：
在对主备AC进行备份时需要定义一个心跳端口。
业务VLAN在AC内基于端口进行配置，对AC端口重新定义后，原有VLAN和NAS-ID将会丢失。
所有VLAN和NAS-ID需要重新配置。
如果在执行此项操作时，未将ACLAN口线缆拔掉。
如果此时有用户发起下线请求，计费报文将无法携带NAS-ID号，而产生错误话单。
如下图为用户15214394754的用户未携带NAS-ID的计费报文信息。
解决措施：
在进行设备主备配置操作时，选择在凌晨业务量小的时段进行，并严格按照流程执行，先将ACLAN口线缆拔掉，中断用户上网业务，再进行配置操作。
待全部配置完成后，再连接线缆恢复业务。
防止操作器件因AC内无NAS-ID配置信息而产生NAS-ID为0的错误话单。
1.4.2NAS-ID格式错误
AC内NAS-ID值配置错误或者格式不正确,比如NAS-ID配置为1200.0731.731.00.46（NAS-ID值多加了点）或者CMCC（不合法NAS-ID），导致计费报文中携带的NAS-ID值不合法而无法生成话单。
相关案例分析:
案例一：
NAS-ID配置错误导致出现错误话单。
故障描述：
AC（211.142.223.30）在2月份产生一条NAS-ID值为CMCC的错误话单，经过对该台AC的数据检查发现，有一个热点的业务VLAN对应的NAS-ID值配置成了CMCC。
因此该热点下用户上网的产生的计费报文NAS-ID值将为CMCC。
该值属于不合法的NAS-ID，正确的NAS-ID值应该为1200073173100460。
解决方案：
将NAS-ID值修改为正确的NAS-ID值即可解决问题。
案例二：
NAS-ID配置中包含了”.”导致出现错误话单。
故障描述：
AC产生一条NAS-ID值为1200.0731.731.00，经过对该台AC的数据检查发现，有一个热点的业务VLAN对应的NAS-ID值配置成了1200.0731.731.00.46。
由于”.”将占用一个字符，因此该热点下用户上网的产生的计费报文NAS-ID值将为1200.0731.731.00。
该值属于不合法的NAS-ID，正确的NAS-ID值应该为1200073173100460。
解决方案：
在配置NAS-ID值是不要把”.”字符配置进去。
1.4.3设备问题
AC设备问题导致无法依据匹配关系携带正确的NAS-ID信息。
相关案例分析：
案例一：
AC内NAS-ID存储空间不够导致出现错误话单。
故障描述：
AC下发现产生NAS-ID值为120007317310和120107317310的错误话单。
1200073173100460相对应的热点为柯达名居。
通过抓包发现是在AC上报这个热点的NAS-ID的时候上报的NAS-ID位数不全导致。
而导致此现象出现的原因是由于AC上NAS-ID的默认储存空间不够导致。
解决方案：
将NAS-ID值的储存空间改大，解决NAS-ID存储空间不够的问题，即可将问题解决。
案例二：
AC内CPU利用率持续较高导致出现错误话单。
故障描述：
升级AC时，须将新版本传到AC业务平台，业务平台加载新系统时CPU利用率持续较高
在CPU利用率高的情况下AC的radius认证模块将无法正常工作，在此过程中用户发起的计费报文将随机产生一些错误信息进行radius报文封装，认证报文携带的错误信息将产生错误话单。
解决方案：
新系统装载成功后，故障恢复。
在对AC进行数据割接时，必须在AC上没有认证用户的前提下进行，并且在割接期间先把用户的认证开关关闭，当割接完毕后，立即把认证开关打开。
这样保证了用户正常上网，也不会产生错误话单。
1.4.4错误话单问题小结
结合以上分析和我省设备实际情况，导致话单错误的原因主要有如下原因：
1、工程开局阶段VLAN和热点配置错误导致。
主要表现在京信公司和大唐公司，出现问题也不容易被发现，这主要和以上两厂家的AC机制有关（京信和大唐公司AP—AC之间的业务数据走私有CAPWAP隧道，因此即便VLAN配置错误，用户上网数据仍然可以通过交换机等传输设备，用户可以正常上网）。
防范措施：
（1）加强工程开局数据管理，在认证入网时除了对三元组数据进行重点审核外，对工程开局数据也安排专人进行审核核对。
（2）工程开局时所有热点均预配置一个默认NAS-ID，即使在误开启认证情况下也不会出现话单错误。
（3）鉴于京信和大唐公司AC机制的特殊性，后期在入网与计费验证测试中将针对1、6、11三个模板开展测试，避免因不能模板VLAN对应错误导致错单问题。
2、设备自身原因导致，主要表现如下：
（1）虹信测试阶段出现的话单错误（AC上的NASID的默认储存空间不够）。
（2）弘浩明传AC的FOA测试阶段出现的话单错误（业务平台加载新系统时CPU利用率持续较高，在CPU利用率高的情况下AC的radius认证模块将无法正常工作导致话单错误）。
（3）京信公司主备倒换测试阶段出现的话单错误（如果在执行主备倒换操作时，未将ACLAN口线缆拔掉。
若此时有用户下线，计费报文将无法携带NAS-ID号，而产生错单）。
防范措施：
此类由于设备自身原因导致的话单错误一般比较难以发现，只有在出现问题抓包分析排查问题并尽快汇报。
同时譬如日常升级、主备前尽量选择在用户闲时，升级或主备操作前制定详细的方案，避免因设备自身原因或操作原因导致话单出错。
3、NAS-ID设置错误：
主要表现在AC因权限管理不严，导致部分维护人员进入AC将NAS-ID误设置为CMCC导致话单错误。
预防措施：
（1）加强AC密码管理和控制，极少人掌握较高权限，其他仅开放查看权限。
（2）工程开局时所有热点均按照NAS-ID标准格式预配置一个默认NAS-ID，即使在误开启认证情况下也不会出现话单错误。
1.5其他AC设备故障
主要故障原因：
（1）AC内业务板卡故障；
（2）AC进程异常；
（3）AC参数配置问题都可能导致AC工作异常；
（4）AC接口故障。
以上AC故障可能导致AP离线退服、用户无法获取IP地址或用户无法认证上网。
1.6.1常见板卡故障及案例分析
常见板卡故障主要有业务板芯片损坏，接口模块损坏等；发生板卡故障在AC主控板上均会有相应的告警指示。
依据告警指示对故障板件进行更换处理。
相关案例分析：
案例一：
AC业务板芯片损坏导致设备无法正常启动工作。
故障描述：
AC下的所有热点网络都不可用，网管平台上出现SNMP不通告警。
所有热点网络均不可用且AC出现告警信息，此种情况很可能为AC出现故障导致。
前往机房对AC进行检查发现，AC出现OutofServiceLED指示灯告警，告警含义为设备不可用。
同时使用串口不能登录AC。
AC控制板工作正常，未出现告警。
此故障可能为业务板芯片损坏导致系统无法启动。
解决方案：
将设备断电后更换AC业务板卡，对AC进行数据配置后工作正常。
案例二：
AC接口模块损坏导致网络不可用。
故障描述：
AC下带的所有AP均离线退服，查看AC进程信息发现wltps、DHCP进程工作正常。
查看AC端口工作状态发现ACLAN口处于shutdown状态，使用noshutdown命令无法将端口打开。
前往机房查看发现LAN端口指示灯出现红灯告警指示。
为AC接口模块损坏导致AP全部离线。
解决方案：
设备断电后，将损坏的接口模块拔出，插入新的接口模块。
上电后，AC即可正常工作。
1.6.2进程异常故障及案例分析
AC内常见进程异常
升级会员 