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

iMC UAM 中常见用户下线1 概述 1..-22 常见下线原因分析及总结 2.-32.1 user request 2-32.2 lost carrier 2-32.3 session-timeout 2-42.4 idle-timeout 2-42.5 Nas-error 2-42.6 online-check 2-5概述早期的CAMS产品及iMC的UAM都是扩展的3A服务器，可以和设备配合实际多种认证方式的接入 CAMS或iMC UAM会记录终端用户的接入明细，终端用户的接入明细中有一项是用户的“下线原因”， 用于标识用户认证过程中的因何而下线下面就总结一些常见的下线原因，供大家在产品实际的应用过程 中维护使用首选澄清一个误区：终端用户接入明细（CAMS中叫上网明细）中的下线原因是客户端通知服务器的 其实不是这样的，用户的下线原因绝大部分是认证设备通过radius的计费结束报文通知3A服务器的，极 少数是3A服务器自己填写的典型的认证模型如下图所示：终端用户与设备之前交互身份认证协议（比如802.1x,portal,l2tp），认证 设备与iMC UAM或CAMS交互radius.上面说过，用户的下线原因绝大部分是由设备通过radius的计费结束报文通知3A服务器，具体一点是通 过计费结束报文中的Acct-Termi nate-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) = "..PWNqT05RMCZ/SUgwfAN6Lwf7ldo= 2008210837".NAS-Identifier(32) = "0023897102ac". NAS-Port(5) = 16797699.NAS-Port-Id(87) = "unit=1;subslot=0;port=5;vlanid=3". NAS-Port-Type(61) = 15.Calling-Station-Id(31) = "0024-1d38-e38a". 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.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) = "192.168.176.24 00:24:1d:38:e3:8a".在少数的情况下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. 交换机与iNode客户端之前的二层网络质量不好常见比如起802.1X交换机与iNode客户端之间还隔着一层或几层二层交换机，导致eap报文被中间的交 换机丢掉。

客户的网络中存在较多的ARP攻击，病毒等报文，导致EAP报文被丢弃终端PC网卡兼容性较差（多见于比较旧的PC），导致eap报文被丢弃终端PC的性能较差或者正在做占用大量CPU的工作导致iNode无法获取到CPU资源处理eap报文 上述问题的最终解决方案还是优化组网，提高硬件性能此外，还有一个比较好的规避解决方案： 交换机默认的心跳超时往往比较短，比如h3c较新型号的交换机往往默认15秒钟发送一次心跳，连接2 次收不到就让终端用户lost carrier下线此时可以通过调整心跳发送的间隔及超时次数来增加eap心跳的 健壮性具体的命令如下：［全局］dot1x timer handshake-periodxx --默认为15S,建议调整为60S或更高，注意请调整为15S 的整数［全局］dot1x timer retry xx --默认为2次超时，建议调整为6次或更高2.3 session-timeoutsession-timeout顾名思义，表示用户已经没有可用的上网时间session-timeout一般的原因有如下几种： 在计费的场景下，用户上网过程中的余额被用完，用户由于没有钱来继续上网而被设备下线。

账号申请的服务中配置了接入时段限制，到了接入时段后用户被下线，此时的下线原因也是session-timeout.2.4 idle-timeout在认证设备上配置在闲置时长命令（一般在domain视图下，idel-cut enable xx）超过闲置时长后，设备 会上相关的用户下线，对应的下线原因为idle-timeout.2.5 Nas-error在有线802.1X或portal认证中，如果认证设备连接终端的端口 down 掉,则认证设备会让该端口下线所有 用户下线，下线原因是n as-error.有些情况下交换机认证的端口由于链路质量的原因会经常出现瞬时down/up的情况，会造成下面连接用户 频繁的down/up下线此时除了改善链路质量外对于802.1X认证还可以通过如下命令来规避：［端口视图］li nk-delay xx --比如配置为 2 表示端口 down 到 up 的时间如果小于 2 秒，交换机逻辑上不认为 该端口 down过，不会让用户nas-error下线该特性目前仅H3C交换机支持，具体交换机的支持情况请参考交换机的随机资料2.6 online-check某些情况下UAM收不到设备的计费更新报文，比如认证设备与UAM之前的路由有问题,比如设备重启（设 备上没有配置accounting-on）,这时未了避免用户在UAM上挂死，UAM在如下图所示的老化时间时没 有任何认证设备关于该账号的计费更新报文，则UAM将该用户的表清除，同时在接入明细中标识该 用户的下线原因为 online-check.。