下线原因为online-check的问题分析

无特殊需要，满足radius认证基础要求即可。

radius认证，用户本文主要讲述EIA中接入用户异常掉线，下线原因为online-check场景下的排查分析。

检查iMC所在服务器的硬件性能信息符合要求规范，iMC部署中EIA组件与PLAT的适配关系是否满足版本说明书的适配要求，然后保证iMC监控代理中uam进程进程正常启动。再检查接入设备的计费相关的配置，之后排查接入设备与iMC侧网络情况。EIA服务器计费报文接收情况检查，确认服务器正常接收该报文后，检查EIA的日志中该报文是否正常接收，若报文未正常接收，则需要检查服务器防火墙的配置是否放通服务器的相应端口。若上述步骤未能解决服务器异常下线原因为online-check的问题，需要联系400-810-0504的热线进行问题受理。

1、 设备计费配置检查

由于iMC EIA产品实现机制的调整，使用iMC EIA 7.2之前版本时，EIA接收设备发送的计费请求报文后，才会生成在线用户的表项；使用iMC EIA 7.2之后的版本时，EIA接受到设备发送的认证报文并处理完成后，就会生成在线表项。而对于已生成的在线表项信息，服务器会定期检测收到该用户计费报文的频次。若超过会话老化时长的时间未收到该用户的计费报文时，iMC EIA会清除该用户的在线用户信息。并记录下线原因为online-check。

因此设备侧必须配置计费相关的功能。以H3C V5设备为例，配置举例如下：

radius scheme 1x 
 primary authentication 192.168.113.126
 primary accounting 192.168.113.126
 key authentication simple admin
 key accounting simple admin
 nas-ip 192.168.205.1

#创建认证域1x，配置802.1X用户使用RADIUS方案1x进行认证、授权、计费。

domain 1x 
 authentication lan-access radius-scheme 1x
 authorization lan-access radius-scheme 1x
 accounting lan-access radius-scheme 1x

具体设备配置以设备相关的命令手册为准。

2、 接入设备与iMC EIA侧网络情况检查

由于设备radius认证期间，需要认证设备与iMC EIA交互认证报文。因此终端认证过程和维持终端在线的过程中需要保证认证设备与iMC EIA的网络可达。正常交互radius报文，如果需要使用EAD配合iNode等私有功能时需要认证设备配置为扩展模式。即在radius scheme中配置server-type extended。

在网络设备未禁ping的情况下，可以使用ping 检测开启认证的接入设备与iMC EIA之间的网络可达情况。

同时可以在设备上通过命令查看radius scheme中配置的radius server的状态。以H3C MSR 30-20 V5设备为例，使用display radius scheme xxx（其中xxx为radius scheme的名称）查看radius server的状态。

3、 iMC EIA服务器配置检查

由于online-check的下线原因是由于在老化时间间隔内，未收到设备发送的计费更新报文。

iMC EIA服务器侧的老化时间间隔的配置合理性，显得尤为重要。服务器侧缺省的老化时长为30分钟。该参数在用户>接入策略管理>业务参数>系统配置>系统参数配置中，可以看到该参数配置。由于该参数设置过小时可能导致设备未达到计费更新周期时，服务器侧已经将该用户的表项老化，导致用户异常下线；若该参数设置的过大，服务器侧需要一定的资源处理该用户的在线信息，并且可能会导致服务器侧的在线表长时间残留的问题。因此，未经专业的产品线工程师评估的情况下，不建议直接修改该参数。

4、 EIA服务器计费报文接收情况检查

由于online-check的下线原因是由于在老化时间间隔内，未收到设备发送的计费更新报文。因此在确保设备配置正确，且设备与服务器侧网络可达的前提下，需要在服务器侧抓包确认iMC EIA服务器侧网卡已经正常接收该用户的radius计费更新报文。

以Windows系统为例，可以安装wireshark软件抓取出现问题期间的报文信息。获取该报文信息后，可以过滤radius报文配合其余属性信息，获取服务器侧radius报文的接收情况。Radius报文中code=4代表计费报文，Acct_Status_Type属性值为3时，表示该报文为计费更新报文。

5、 EIA进程计费报文接收情况检查

确认iMC EIA服务器侧收到radius报文后，需要检查uam进程日志中报文的接收情况，将uam日志级别配置为debug。复现问题收集iMC/uam/log下 出现问题当天的uam日志信息。

打开日志以账号名为过滤条件显示当前账号的认证相关的报文信息

以上可以分析uam最后一次收到该用户计费报文的时间点为11:08。

且在10:20收到该用户的认证请求时，可以看到创建的在线用户的ID为756。

最后一次收到该账号的计费更新报文是在11:08分，服务器配置的会话老化时长为30分钟，所以服务器在11:40分的定时任务中，清除该账号的在线信息。账号的在线时长以最近一次收到该账号的计费更新报文为准即48分钟，记录下线原因为online-check。

根据上述分析可以确认，uam在11:08后未正常接收该设备的计费报文，导致服务器侧达到老化时长后将该用户的下线表项老化。需要进一步对比服务器侧的抓包和日志中报文的数量，确认问题原因为服务器接收的radius报文数量少，或程序处理的报文数量少，最终判断是服务器侧程序功能异常或其他原因。

6、 服务器防火墙配置检查

若上述步骤中判断服务器网卡抓包中有报文，但是程序的日志中显示未收到任何报文信息记录。此时需要重点排查服务器侧防火墙的配置，确认服务器操作系统的防火墙是否将radius 1813端口的报文过滤，导致进程未正常获取到程序的文件信息。

9、联系400热线处理

若上述信息故障处理方法均无法判断下线原因为online-check的问题原因，则需要收集如下信息联系400-810-0504进行处理。

需要收集的信息如下：

1) 用户接入详细信息截图；

2) DEBUG级别的iMC安装目录下iMC/uam/log文件夹下的文件；

3) iMC服务器侧的抓包信息；

4) 设备侧的定位信息以具体设备的定位意见为准，通常需要抓包和设备debug信息；

5) iMC版本信息截图