802.1X认证无线终端偶发掉线

无线采用本地转发，IMC做radius服务器，配合深信服设备做单点登录。终端通过802.1X认证上线后，IMC服务器将用户上线记录通告给深信服设备，此时设备完成完整的上线流程。设备下线也是由IMC服务器向深信服设备通告。

实施开局后发现部分终端会出现不可上网的情况，此时用户不能访问互联网，但是可以访问内网资源。现象偶发，不区分终端类型。

由于现象偶发，不好在设备上debug和抓包，只有在IMC服务器收集UAM的debug日志。多次采集信息后，收集到一个问题终端的日志，uam日志显示在老化时间内未收到该设备的计费更新报文，IMC将该终端老化，并且将下线信息同步到深信服单点登录设备，导致终端访问外网失败。此时终端需要手动重连无线，再次经过802.1X认证后业务才恢复正常，对用户使用体验不友好。针对IMC给的结论我们可以确定两种情况；

1，AC在终端老化时间内的确没有发计费更新报文，IMC上终端老化时间为30分钟，AC上计费更新报文周期为12分钟。

2，AC正常发了计费更新报文，但是丢在了中间链路上。

由于现象偶发，对抓包和debug不太友好。我们可以通过以下手段排查确定；

通过命令display radius scheme命令查看AAA信息，具体名词解释见链接。截图可见1813计费端口有过block状态，说明我们AC能会正常发计费报文，造成该问题的原因还是中间链路不稳定导致。

03-AAA命令-新华三集团-H3C

通过display radius statistics 查看radius报文统计信息，具体解释见链接。

03-AAA命令-新华三集团-H3C

针对IMC是未收到AC发的计费更新报文导致终端老化，从AC侧可以通过修改radius计费报文的周期以及重传次数来优化。IMC侧也可以增加终端的老化时间来解决，两种方法只是针对计费报文重传周期以及频率优化，根本解决办法还是需要保证中间链路的稳定性。

1，修改AC配置。 

#

radius scheme 111

retry 6

 timer realtime-accounting 6

#

将计费报文重传次数改为6次，默认为3次。将计费报文周期改为6分钟，默认12分钟。

2，将IMC上终端老化时间修改为60分钟，默认30分钟。