iMC UAM EAD中常见用户下线原因分析

iMC UAM中常见用户下线原因分析

1 概述....................................................................................................................................................... 1-2 2 常见下线原因分析及总结 ...................................................................................................................... 2-3

2.1 user request ...................................................................................................................................... 2-3 2.2 lost carrier ......................................................................................................................................... 2-3 2.3 session-timeout ................................................................................................................................. 2-4 2.4 idle-timeout ........................................................................................................................................ 2-4 2.5 Nas-error ........................................................................................................................................... 2-4 2.6 online-check ...................................................................................................................................... 2-5 2.7 online-delete ...................................................................................................................................... 2-5 2.8 unknown error ................................................................................................................................... 2-5

1-1

1 概述

终端用户 身份认证协议 认证设备 RADIUS 3A （UAM）

上面说过，用户的下线原因绝大部分是由设备通过radius的计费结束报文通知3A服务器，具体一点是通过计费结束报文中的Acct-Terminate-Cause(49) 属性来标识用户的下线原因的，这个属性不同的值代表不同的含义，一个典型的radius计费结束报文如下所示。

% 2010-07-01 15:51:18 ; [L_DEBUG (4)] ; LAN ; 2008210837 ; 4 ; 1dc21663c68a4e22a4c404a0723e58f1 ; (NULL) ; RT[1]: Receive message from 10.128.2.232: CODE = 4. ID = 77. ATTRIBUTES:

User-Name(1) = \NAS-Identifier(32) = \NAS-Port(5) = 16797699.

NAS-Port-Id(87) = \NAS-Port-Type(61) = 15.

Calling-Station-Id(31) = \Acct-Status-Type(40) = 2. Acct-Authentic(45) = 1.

Acct-Session-Id(44) = \Framed-IP-Address(8) = 3232280600. NAS-IP-Address(4) = 176161512. Event-Timestamp(55) = 956586558. Acct-Session-Time(46) = 1897. Acct-Delay-Time(41) = 0.

Acct-Input-Octets(42) = 21914982. Acct-Input-Packets(47) = 120932. Acct-Output-Octets(43) = 164531446. Acct-Output-Packets(48) = 149499. Acct-Input-Gigawords(52) = 0. Acct-Output-Gigawords(53) = 0.

Acct-Terminate-Cause(49) = 1. \\\\这里为1表示user request(用户主动下线)。 hw_Connect_ID(26) = 787.

1-2

典型的认证模型如下图所示：终端用户与设备之前交互身份认证协议（比如802.1x,portal,l2tp）,认证

设备与iMC UAM交互radius.

hw_Input_Peak_Rate(1) = 0. hw_Input_Average_Rate(2) = 0. hw_Output_Peak_Rate(4) = 0. hw_Output_Average_Rate(5) = 0. hw_Priority(22) = 0.

hw_IP_Host_Addr(60) = \

在少数的情况下UAM或CAMS也会自己标识用户的下线原因，下面就将常见的下线原因总结一下作为参考，具体情况还需要具体分析。

2 常见下线原因分析及总结

2.1 user request

这是最常用的一种下线方式，user request表示用户主动下线，一般的情况有：

1. 用户手工点击连接中的“断开”主动下线。

2. 在启用策略服务器的情况下，iNode客户端与策略服务器不通造成iNode与策略服务器的心跳超时后主动下线。

这种情况下一般iNode会给出类似“代理服务器没有回应，即将强行下线”之类的提示。这时请检查iNode与策略服务器（UAM服务器）是否路由可达，可以通地ping, tracert等命令来进行排查。

如果iNode与策略服务器路由可达，请检查是否iNode与策略服务器通信的端口（udp 9019）被防火墙过滤,包括客户端PC上的软件防火墙，网络中的防火墙及UAM服务器上的软件防火墙。

2.2 lost carrier

在802.1x认证的组网中，用户认证成功后交换机主动与客户端保持EAP心跳，这个心跳由交换机主动发起，每隔一段时间（一般10几秒）发一次，如果连接一定次数收不到客户端的心跳回应，则交换机认为客户端已经不在线，交换机清空关于该用户的在线表，之后通知3A服务器该用户下线，下线原因为lost carrier.

从 lost carrier下线的原理来看，造成lost carrier下线的原因常见有如下几种：

1. 终端与认证交换机非直连，终端直接拔掉网线或待机

由于终端与认证交换机非直连，上述情况认证交换机连接该终端的端口还是up的，认证交换机会正常发送eap心跳报文，而终端已经拔掉网络或待机（比如直接合上笔记本），这时iNode回应不了eap的心跳报文，交换机经过心跳超时后将该用户lost carrier下线。

2-3

2. 交换机与iNode客户端之前的二层网络质量不好

常见比如起802.1x交换机与iNode客户端之间还隔着一层或几层二层交换机，导致eap报文被中间的交换机丢掉。

客户的网络中存在较多的ARP攻击，病毒等报文，导致EAP报文被丢弃。 终端PC网卡兼容性较差（多见于比较旧的PC），导致eap报文被丢弃。

终端PC的性能较差或者正在做占用大量CPU的工作导致iNode无法获取到CPU资源处理eap报文。 上述问题的最终解决方案还是优化组网，提高硬件性能。此外，还有一个比较好的规避解决方案： 交换机默认的心跳超时往往比较短，比如h3c较新型号的交换机往往默认15秒钟发送一次心跳，连接2次收不到就让终端用户lost carrier下线。此时可以通过调整心跳发送的间隔及超时次数来增加eap心跳的健壮性。具体的命令如下：

[全局]dot1x timer handshake-period xx --默认为15S，建议调整为60S或更高，注意请调整为15S的整数

[全局]dot1x timer retry xx --默认为2次超时，建议调整为6次或更高。

2.3 session-timeout

session-timeout顾名思义，表示用户已经没有可用的上网时间。session-timeout一般的原因有如下几种：

在计费的场景下，用户上网过程中的余额被用完，用户由于没有钱来继续上网而被设备下线。 账号申请的服务中配置了接入时段限制，到了接入时段后用户被下线，此时的下线原因也是session-timeout.

2.4 idle-timeout

在认证设备上配置在闲置时长命令（一般在domain视图下，idel-cut enable xx）超过闲置时长后，设备会上相关的用户下线，对应的下线原因为idle-timeout.

2.5 Nas-error

在有线802.1x或portal认证中，如果认证设备连接终端的端口down掉，则认证设备会让该端口下线所有用户下线，下线原因是nas-error.

有些情况下交换机认证的端口由于链路质量的原因会经常出现瞬时down/up的情况，会造成下面连接用户频繁的down/up下线。此时除了改善链路质量外对于802.1x认证还可以通过如下命令来规避： [端口视图]link-delay xx --比如配置为2表示端口down到up的时间如果小于2秒，交换机逻辑上不认为该端口down过，不会让用户nas-error下线。

该特性目前仅H3C交换机支持，具体交换机的支持情况请参考交换机的随机资料。

2-4

2.6 online-check

某些情况下UAM收不到设备的计费更新报文，比如认证设备与UAM之前的路由有问题，比如设备重启（设备上没有配置accounting-on），这时未了避免用户在UAM上挂死，UAM在如下图所示的老化时间时没有任何认证设备关于该账号的计费更新报文，则UAM将该用户的在线表清除，同时在接入明细中标识该用户的下线原因为online-check.

2.7 online-delete

UAM管理员手工在在线表中点击“清除在线信息”，此时UAM会直接清空该账号的在线表，同时将接入明细中用户的下线原因设置为online-delete.

2.8 unknown error

unknown error多由设备让用户下线引起，对应计费结束报文中acct-terminate-cause=255

常见的原因有：对于比较早版本的交换机其eap报文长度最大支持56Byte,这样到服务器通过hw-user-notify下发比较长的信息（比如用户提示信息）时，设备要将hw-user-notify转为eap报文传给客

2-5

户端，由于比较早版本的交换机其eap报文长度最大支持56Byte，如果超过这个长度认证设备会将用户unknown error下线。

解决的方法可以向设备侧确认是否有版本解决或者想法减少radius hw-user-notify报文的长度，比如减少用户提示信息的字数。

2-6

本文来源：https://www.bwwdw.com/article/k0p7.html