交换机802.1X认证不成功

发布时间:  2016-06-14 浏览次数:  271 下载次数:  0
问题描述
网络设备中提示mac漂移,现网排查环路,却无法找到环点,无法解决MAC漂移告警问题,经确认为此MAC非网络环路所致,而是因为二层网络中存在相同MAC设备。
处理过程
<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:08.420.15-05:13 HQ-CR-ACC-C11-C02 CM/7/DEBUG:
[CM DBG]Interface is down.
<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:08.430.1-05:13 HQ-CR-ACC-C11-C02 CM/7/DEBUG:
[CM DBG]Interface is down /////////////////////////////////////////////////无盘工作站此时重启,导致端口down,认证无法进行下去

<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:09.490.1-05:13 HQ-CR-ACC-C11-C02 DOT1X/7/DEBUG:
[EAPOL-timer] Authentication response timeout.(ulIndex=116)   /////////////////////////////////////配置了server-timeout时间,当时间到,
                                                             /////////////////////////////////////radius-server没响应或者本场景(认证到UCM模块时端口down,认证无法进行),eap模块当作认证失败。

<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:09.490.3-05:13 HQ-CR-ACC-C11-C02 DOT1X/7/DEBUG:
[EAPOL-info] Send cut request message to UCM module successfully.(local index:116)
        //////////////////////////server-timeout时间到了,向UCM模块请求cut用户
<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:09.490.8-05:13 HQ-CR-ACC-C11-C02 DOT1X/7/DEBUG:
[EAPOL-message] Receive message:
MsgType: Cut ack, CM index: 4294967295, local index: 116, user MAC: d4be-d9c6-8c7f.
                                                                 ////////////////////////////////d4be-d9c6-8c7f用户认证失败
<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:12.470.6-05:13 HQ-CR-ACC-C11-C02 DOT1X/7/DEBUG:
[EAPOL-error] User is still in quiet status.(MAC:d4be-d9c6-8c7f)     //////////////////////////由于上次认证失败,加入静默周期,再次来认证,eap不处理,再次触发失败

<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:12.470.7-05:13 HQ-CR-ACC-C11-C02 DOT1X/7/DEBUG:
[EAPOL-error] Failed to check packet,drop the packet.                    //////////////////////////eap丢弃来认证的dhcp报文,第二次认证失败
<HQ-CR-ACC-C11-C02>
May 10 2013 13:50:20.530.1-05:13 HQ-CR-ACC-C11-C02 DOT1X/7/DEBUG:
[EAPOL-stack] Packets enter eap module queue successfully.(ucPacketType=2,ulLay2Type=1)  ///////////////////////第三次来认证,认证成功。


抓包分析,正常认证终端DHCP DISCOVER包发包间隔周期为:2S,4S,8S,16S。不正常无盘终端DHCP DISCOCVER的间隔时间为4S,8S,16S,跟正常周期不一样,在认证时首先因为认证过程中端口down了,会将用户加入静默中,静默到期后再通过认证,第四个DHCP DISCOCVER报文被交换机转发出去。而正常时不会把用户加入到静默中,马上会认证通过,在第二个DHCP DISCOCVER报文就被转发出去了。这可能是终端网卡DHCP发包的问题,所以不正常时认证会通过可DHCP获取地址时间太长。
根因
1.交换机配置问题;
2.在radius服务器没有添加相应用户名;
3.无法触发认证
建议与总结
遇到802.1X认证不通过时,可以通过802.1X认证原理进行处理,排除配置问题后,可以考虑debug+抓包确认问题,一般问题现象都比较明显,方便快速定位并处理问题。

END