园区网NAC方案故障处理

发布时间:  2015-03-18 浏览次数:  459 下载次数:  0
问题描述
用于提供TSM策略管理中心策略管理中心、ESAP、WLAN共同使用时,出现问题后快捷高效的分析定位问题的办法。
处理过程
TSM策略管理中心策略管理中心故障定位:

1、在TSM策略管理中心策略管理中心安装目录找到并打开“PolicyCenter\radius\logs\tomcat.log”,分析RADIUS服务器在处理认证时出现的异常情况,查看RADIUS服务器统计认证计费相关的信息。

2014-05-26 22:28:19,566 -RadiusStat:150 INFO  - recvRadiusPacketCount = 309709 在接收报文环节,统计接收报文的数量。

2014-05-26 22:28:19,566 -RadiusStat:151 INFO  - sendRadiusPacketCount = 309454 在发送报文环节,统计发送RADIUS报文的数量。

2014-05-26 22:28:19,567 -RadiusStat:153 INFO  - recvRadiusAccountRequest = 35983 接收到的Radius计费的报文的个数。

2014-05-26 22:28:19,567 -RadiusStat:155 INFO  - sendRadiusSuccess = 14684 统计RADIUS SUCCESS的数量。

2014-05-26 22:28:19,567 -RadiusStat:156 INFO  - sendRadiusFailure = 1619 统计RADIUS FAILURE的数量。

2014-05-26 22:28:19,568 -RadiusStat:158 INFO  - sendRadiusChallenge = 293151 发送Radius询问的次数。

2014-05-26 22:28:19,569 -RadiusStat:164 INFO  - dropBySessionNotFound = 170 因为查找不到会话导致丢包的个数。

2014-05-26 22:28:19,569 -RadiusStat:167 INFO  - pakcetDropVerifyFail = 255 统计因为报文校验失败,导致报文被丢弃的数量。

2014-05-26 22:28:19,570 -RadiusStat:169 INFO  - packetDropQueueFull = 0 统计因为队列满导致报文被丢弃的RADIUS报文数量


通过上面统计数据大致得出如下结论:

recvRadiusPacketCount = sendRadiusPacketCount + pakcetDropVerifyFail
出现pakcetDropVerifyFail就需要详细分析报文为什么会出现丢包。

sendRadiusChallenge < sendRadiusPacketCount
出现sendRadiusChallenge小于sendRadiusPacketCount就需要详细分析报文为什么客户端没有回应RADIUS服务器的挑战报文。客户端回复RADIUS报文的路径依次是终端主机、AP、AC、TSM策略管理中心策略管理中心。

2、在Web浏览器打开https://TSM策略管理中心策略管理中心IP地址:8443并登录TSM策略管理中心策略管理中心,选择“用户与终端 > 部门用户 > RADIUS日志 > RADIUS认证日志”,单击“查询”,查询所有RADIUS认证结果为失败的日志。



3、单击“确定”查筛选认证结果为失败的记录,并把鼠标移动“失败原因”查看失败原因及处理建议。



ESAP故障定位:

在AC上查看到用户的上线失败记录信息。

<AC6605> system-view
[AC6605] diagnose
[AC6605-diagnose] display aaa online-fail-record all

  • 如果出现wireless authentication fail,需与WLAN组件进行联系,该消息码是WLAN组件发送cut请求导致;
  • 如果是Authentication fail,一般该错误是由RADIUS服务器回应拒绝报文导致,请检查用户名密码是否正确。
  • 如用户名密码无误,请在RADIUS服务器上进行抓包,看是否有回应拒绝报文,如有,请与RADIUS服务器进行联系。
对于PEAP认证,由于是客户端直接与RADIUS服务器进行认证交互,ESAP平台所起的作用只是报文透传,所以从抓包分析是最直接能找到问题所在。

RADIUS服务器发送的报文中,携带着EAP协议报文。



该报文会与AP-AC侧抓包的报文所对应。



在出现问题时,可以先收集下AC-AP侧以及RADIUS服务器的报文,通过报文比较,来界定问题。
  • 报文都可以对应,RADIUS发送的报文未收到回应,确认是否都通过AP发送出去,AP-AC侧抓到相应的发送报文,但无相应回应报文,联系WLAN产品AP侧进行确认,是客户端没回应报文,还是报文在AP或空口被丢掉;
  • 报文对应不上,存在两种情况:首先RADIUS发送的报文,在AP-AC侧未抓到相应的报文,其次AP-AC侧接受到的报文,在RADIUS服务器上的抓包未抓到相应的报文,对于上述两种情况,请联系ESAP平台进行确认,再做进一步分析。
  • 用户认证成功,在AP-AC侧所抓到的报文中,EAP-Request报文总数应该是与EAP-response报文总数相匹配的,如出现EAP-Request报文比EAP-Response报文多的情况,请于WLAN产品AP侧进行确认。
WLAN故障定位:

用户上线失败的常见原因:
  • 关联失败
  • 认证失败
认证失败常见的原因有:
       1.  域名与有效认证服务器没有绑定在一起。
       2.  RADIUS服务器上没有配置设备的IP地址做AAA Client。
       3.  RADIUS服务器与设备之间的share-key不一致。
       4.   对于Portal认证,还有可能Portal服务器上没有将客户端的IP地址加入到客户端认证表列中。
  • 终端无法获取IP地址。
常用的认证失败查看命令:
  • display aaa abnormal-offline-record xxx
  • display aaa online-fail-record
  • display aaa offline-record
终端关联失败、认证失败和获取不到IP地址都可以通过全流程跟踪来定位,确认是在那个模块出的问题。

AC侧STA全流程跟踪命令:

trace enable brief

trace object mac-address xxx

AP侧STA关联过程跟踪:

station-trace probe station xxx

station-trace assoc station xxx

用户上不了线组件诊断命令:

debugging wlan wsta all

debugging wlan wsec all

常见问题举例

通过RADIUS-AC侧的抓包报文,AP-AC侧的抓包报文分析,找到认证失败的原因。
  • 认证超时(无缺省认证规则)
首先根据PolicyCenter章节中的RADIUS认证日志,找到认证超时记录并找到用户的MAC地址。

报文过滤条件为 radius.Called_Station_Id == ’11-11-11-11-11-11’ || radius.State == 01:46:38:32:86:af:00:00:01:46:38:32:86:af

以上的01:46:38:32:86:af:00:00:01:46:38:32:86:af是先根据过滤条件radius.Called_Station_Id == ’11-11-11-11-11-11’先找到的一个request报文,找到其中的RADIUS 属性值 t=State(24) : 01:46:38:32:86:af:00:00:01:46:38:32:86:af。

过滤完后,剩下的交互报文为一个完整的交互过程。

认证超时是因为客户端无回应报文。





AP-AC侧抓包进行分析,也发现是客户端没有进行报文回应。

报文过滤条件为 eapol && eth.addr == 00:00:52:e4:50:2e。

以上的eapol是先过滤AP-AC之间进行EAP协议交互的报文;eth.addr 是根据用户的MAC地址将该用户在AP-AC侧交互的EAP报文过滤出来。





根据上图,可看出AC发出报文给客户端,未收到客户端的回应;并进行了2次重传,此时就需要AP侧进行分析。
  • 认证超时(有缺省认证规则)
认证流程快走完时,客户端无回应报文,此时已经有认证规则,报文过滤条件如下。





AP-AC侧抓包分析,确认是客户端没有回应报文。
  • The radius server is not reachable
RADIUS报文分析,在认证过程中,客户端发送的请求报文有误(出现alert报文),导致后边服务器无回应。




通过AP-AC侧抓包,已确认客户端回应报文有误;根据RADIUS报文中携带的EAP报文,可相应找到AP-AC侧EAP报文,进行问题确认,从报文图中可看出客户端回应的报文有误。












根因
整体业务交互流程图



客户定位流程图



工程师定位流程图




确定故障范围:

如果RADIUS服务器侧没有正常回应报文,则可确定TSM策略管理中心策略管理中心出现故障。
如果RADIUS服务器侧有正常回应报文,而AC/AP没有相应的报文,则可确定ESAP或WLAN出现故障。
如果AC/AP接收到RADIUS服务器发出的相应报文,而RADIUS服务器侧没有收到正常的回应报文,则可确定ESAP或WLAN出现故障。
如果RADIUS服务器发出的相应报文与AC侧接收的报文匹配,而RADIUS服务器发出的报文与终端主机发出的报文无法匹配,则可确定WLAN(Wi-Fi/AP)出现故障。

END