• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

802.1x认证频繁掉线,服务器侧看下线原因为LostCarrier

2020-12-23 发表
  • 1关注 ,2146浏览
粉丝:2人 关注:1人

组网及说明

标准组网

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, 报文交互如下:

其中设备MACHangZhou_07:f2:e0  终端MACF4: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或更高

0 个评论

该案例暂时没有网友评论

编辑评论

举报

×

侵犯我的权益 >
对根叔知了社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔知了社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明

提出建议

    +

亲~登录后才可以操作哦!

确定

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作