标准组网
iNode E0549
EIA版本不限
现场使用iNode拨号做802.1x认证,终端出现频繁上下线,服务器侧记录下线原因为lostcarrier
1、首先分析EIA服务器侧UAM日志,日志记录如下,这个是设备侧发来的计费结束报文,下线原因是2,代表lost carrier方式下线,说明服务器侧是收到设备侧发送要求下线才进行的下线操作,因改下线原因非服务器侧主动触发,需要排查认证设备和终端之间的报文交互。
%% 2020-12-18 10:49:36.821 ; [LDBG] ; [23684] ; LAN ; YDBZTUhTZnsiHE02fwEpctaxE2U= test ; 4 ; ff785937bbe246d7a94c1beccbabbfcb ; ; Received message from 10.10.2.253:
CODE = 4 ID = 164.
User-Name(1) = ..YDBZTUhTZnsiHE02fwEpctaxE2U= test
hw_ISP_ID(17) = ldyy
Framed-Protocol(7) = 1.
Called-Station-Id(30) = 00-0F-E2-07-F2-E0
NAS-Port-Type(61) = 15.
hw_IP_Host_Addr(60) = 0.0.0.0 f4:4d:30:96:3a:49
H3C_NAS_PORT_NAME(230) = Bridge-Aggregation28
NAS-Port(5) = 114800.
NAS-Port-Id(87) = slot=0;subslot=0;port=28;vlanid=112
H3C_AVPair(210) = nas:ifindex=18687
Acct-Session-Id(44) = 00000004202012180248160000dedf2048100543
NAS-Identifier(32) = LDYY_WAI_Leaf_S7506E-X
Class(25) = JKMCoyqI
NAS-IP-Address(4) = 168428285.
Calling-Station-Id(31) = F4-4D-30-96-3A-49
hw_Priority(22) = 1.
Acct-Terminate-Cause(49) = 2. //设备发送下线原因
Acct-Session-Time(46) = 78.
Acct-Authentic(45) = 1.
Acct-Status-Type(40) = 2.
Acct-Delay-Time(41) = 0.
Event-Timestamp(55) = 1608259774.
hw_Product_ID(255) = H3C S7506E
hw_Nas_Startup_Timetamp(59) = 1606642980.
2、在802.1x认证的组网中,用户认证成功后交换机主动与客户端保持EAP心跳,这个心跳由交换机主动发起,每隔一段时间(一般10几秒)发一次,如果连接一定次数收不到客户端的心跳回应,则交换机认为客户端已经不在线,交换机清空关于该用户的在线表,之后通知3A服务器该用户下线,下线原因为lost carrier.
从 lost carrier下线的原理来看,接着我们需要确认eap心跳报文丢失在哪个模块,是客户端没有发送出去,还是认证设备没有回应,还是中间链路丢掉此报文。现场同时在终端和认证交换机上进行抓包,过滤eapol, 报文交互如下:
其中设备MAC:HangZhou_07:f2:e0 终端MAC:F4:4D:30:96:3A:49
交换机侧抓包如下:
其中EAP request Identity即是心跳报文,可以看到在红圈标注处,交换机先发送一个eap 心跳报文给终端,没有收到终端回复,等待15秒后,再发送第二个EAP心跳报文给终端,等待15秒后仍然没有收到终端回复,此时发送eap failure给终端,认证失败。
看交换机侧抓包可以确认,和终端侧有报文丢失,需要继续在终端侧抓包看是终端没有发出报文还是中间链路将报文丢失。
3、看终端侧抓包其中终端时间比设备时间快4S如下:
可以看到终端是收到交换机发送过来的eap request 心跳报文,且终端也进行了 EAP Respone Identity回复(此处抓包有重复报文可忽略,是该终端环境特殊导致的)。
4、通过对比终端侧抓包和交换机侧抓包可以看到终端有发,但是设备未收到,怀疑是中间设备将报文丢失,现场进行流统发现中间设备未丢失报文。将终端和认证交换机进行直连,重复刚才的抓包过程,发现仍热是终端有发报文但是交换机侧没有收到,正常直连环境下,不应该出现链路丢失报文的问题。
5、因为我们wireshake抓包,只能证明抓到了二层协议上的报文,但是不能确认是否从链路层发出去。本问题就是PC侧显示有发包,但是实际缺没有发出去,是个iNODE的已知问题,iNode调用的二层发包驱动W32N55.DLL和系统兼容有问题导致,需要使用INODE 0548U01版本解决。
1、如果遇到lostcarrier频繁下线,且抓包发现PC有发,设备未收到,直连测试也是这种情况,可能是inode已知问题,建议使用inode E0548U01版本进行测试
2、还有一个比较好的规避解决方案:
交换机默认的心跳超时往往比较短,比如h3c较新型号的交换机往往默认15秒钟发送一次心跳,连接2次收不到就让终端用户lost carrier下线。此时可以通过调整心跳发送的间隔及超时次数来增加eap心跳的健壮性。具体的命令如下,其他厂商交换机建议咨询相应命令进行配置
[全局]dot1x timer handshake-period xx --默认为15S,建议调整为60S或更高,注意请调整为15S的整数
[全局]dot1x timer retry xx --默认为2次超时,建议调整为6次或更高。
该案例暂时没有网友评论
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作