801.1x认证失败问题排查

背景说明： S5130S‑52P‑EI（V7 版本）支持display aaa online‑fail‑record，可以直接查看认证失败记录；S3600、S3100 属于 Comware V5 老平台，没有这条查询历史失败记录的命令，需要依靠统计、日志、debug 调试来定位失败原因H3C。

一、通用基础查看命令（V5、V7 全部机型都支持）

1. 查看 802.1X 全局 & 端口配置、会话、统计计数

重点看Fail Packets数值持续增长，代表该端口持续出现认证拒绝H3C。

2. 查看系统日志（优先，无需开启 debug）

日志关键字：DOT1X_LOGOFF_ABNORMAL、PORT_AUTH_FAIL，可看到异常下线、认证失败事件；

⚠️V5 老设备默认不会记录全部 802.1X 登录失败日志，日志缓冲区有限，故障过后旧日志会被冲刷覆盖，故障复现时要立刻导出日志。

V7 新设备可以开启认证用户日志（V5 无这条命令）

二、V5 设备（S3600、S3100）无 online‑fail‑record，故障复现时用 debug 调试

⚠️注意：debug 不要在业务高峰长时间开启，故障复现的瞬间打开，拿到信息立刻关闭全部 debug，避免 CPU 升高；建议 Console 本地操作，SSH 会话容易被调试输出刷屏。

复现认证失败，观察输出；排查结束务必关闭调试：

debug 输出解读

1. 看不到 EAP‑Start 报文：终端客户端没有发送认证报文，排查终端配置、网线、端口是否被隔离；
2. 交换机发出 RADIUS 请求，收不到回复：检查 RADIUS 服务器 IP、密钥、路由、防火墙放行 UDP1812；
3. RADIUS 返回 Reject 拒绝报文：账号密码错误、账号未授权、服务器侧策略拒绝。

三、配套 RADIUS 服务器侧排查（非常关键）

交换机 V5 无法保存历史失败记录，优先看 RADIUS 服务器日志，服务器会完整记录每一条认证请求的拒绝原因：账号错误、密码错误、黑名单、时间策略、客户端 NAS 配置不匹配。

四、快速区分故障位置

表格

对于你手头不支持 display aaa online-fail-record 命令的交换机（如 S5130S-52P-EI 及更早的 S3600、S3100 系列），排查 802.1X 认证失败的核心思路需要从“查询失败记录”转向 “实时状态检查”与“动态调试”。以下是针对这些设备的通用排查方法。

 第一步：基础状态检查（所有型号通用）

在开启调试命令前，先通过 display 命令快速确认基础配置和运行状态，这能排除大部分低级错误。

1. 检查 802.1X 全局与接口配置：执行 display dot1x 命令，确认全局 802.1X 功能已开启，并查看认证接口下的具体配置，如认证模式（Authentication Mode）、端口控制类型（Port Control Type）以及是否配置了强制认证域等。

2. 检查认证域与RADIUS方案：执行 display domain 命令，确认用户使用的认证域下是否正确关联了 RADIUS 方案，以及方案中指定的RADIUS服务器IP、端口和密钥是否正确。

3. 检查用户在线状态：执行 display dot1x connection 或 display connection，查看当前是否有用户成功上线。如果完全没有连接记录，说明问题出在认证交互阶段。

 第二步：开启实时调试（关键手段）

当基础检查无误但问题依然存在时，动态调试（Debugging）是定位认证失败原因最有效的方法。

 重要操作规范：debugging 命令会消耗设备CPU资源，严禁在设备正常运行时长期开启。务必在故障复现时开启，收集信息后立即关闭。

标准操作流程如下：

1. 开启调试开关：

   bash

   <H3C> terminal monitor # 开启终端监控，以便在屏幕上显示调试信息 <H3C> terminal debugging # 开启终端调试信息输出 <H3C> debugging dot1x all # 开启802.1X所有调试信息[reference:4] <H3C> debugging radius all # 开启RADIUS所有调试信息，用于观察与服务器的交互[reference:5]

2. 复现故障：让终端用户尝试连接网络，触发认证失败。

3. 分析调试输出：观察屏幕上打印的调试信息。重点查找以下关键词：

   • Authentication failed：认证失败。

   • RADIUS server unreachable：RADIUS服务器不可达。

   • Failed to add MAC address：添加MAC地址表失败（这是S3100等老型号的常见问题）。

   • queue is full：队列满，通常由MAC地址表冲突引起。

   • UserRequest：通常表示客户端主动下线。

4. 关闭调试开关（务必执行）：

   bash

   <H3C> undo debugging all <H3C> undo terminal debugging

 第三步：针对老型号（S3600/S3100）的专项排查

老型号设备在处理大量MAC地址时可能出现性能瓶颈，导致认证失败。

• MAC地址表冲突/哈希冲突：这是 S3100 系列的一个已知问题。当上行端口允许过多VLAN通过，导致MAC表项过多（如超过1700条）时，可能引发MAC地址哈希冲突，使认证过程中添加MAC地址失败，进而导致CPU升高、认证超时。

  • 排查方法：检查上行端口的VLAN配置（display interface），确认是否 permit vlan all。如果存在，应裁剪VLAN，只允许必要的VLAN通过，以减少MAC表项数量。

• 连接超时问题：老型号认证时可能报 dot1x连接超时。除了MAC表问题，还需检查设备与RADIUS服务器的路由可达性，以及中间网络设备是否拦截了RADIUS的1812/1813端口。

display aaa online-fail-record 是较新 V7 版本才新增的特性：

• S5130S-48P6X-EI-G-v2（新版本 V7）支持；
• S5130S-52P-EI V7.1.070 R6318P01、S3600（V5）、S3100（V5 老平台）不支持这条命令，没有固化的 “认证失败记录表”，需要用：802.1x 用户日志 + dot1x 统计 + RADIUS 日志 + debugging 调试 + RADIUS 服务器侧日志这几套组合排障。

S3600 / S3100 是 V5 平台，命令体系和 V7 不一样，很多 V7 的 aaa/dot1x 日志命令不支持。

一、V7 老版本 S5130S-52P-EI（V7.1.070 R6318P01）可用方案

1. 开启 802.1X 接入用户日志（重点，替代 online-fail-record）

日志会写入 logbuffer，也可以输出到 syslog 服务器推荐部署 syslog，不然本地缓冲区容易被冲掉H3C

查看日志：

常见日志关键字：

• DOT1X_LOGIN_FAIL：认证失败；日志携带 MAC、用户名、失败原因（RADIUS 拒绝 / 超时 / 域配置错误）
• DOT1X_LOGOFF_ABNORMAL：异常下线（重认证失败、计费失败、握手超时）

2. 查看 802.1X 统计，看失败计数器

重点看：EAP 报文收发、认证拒绝报文、重认证失败计数。

3. 查看 RADIUS 模块日志与统计（账号密码 / 服务器不通优先查这个）

RADIUS 日志可以区分：

• RADIUS 服务器拒绝（密码错、账号禁用、未绑定接入策略）
• RADIUS 超时（交换机和 RADIUS 服务器不通、端口 1812 被拦截）

4. Debug 实时抓交互（现场临时排障，业务高峰期慎用）

排完故障务必关闭：undo debugging all

二、S3600 / S3100（V5 平台，老款）排障方案

V5没有 dot1x access-user log，也没有display aaa online-fail-record。

1. 基础状态与统计

可以看到 EAP 报文收发，判断客户端有没有发 EAPoL，交换机是否转发给 RADIUS。

2. V5 Debug 命令（最核心排障手段）

V5 的 debug 会直接打印 EAP 应答、RADIUS Access-Reject/Access-Accept。

• 收到 Access-Reject：RADIUS 服务器拒绝，去 RADIUS 服务器查日志（最常见）
• 一直无 RADIUS 回应：交换机到 RADIUS 服务器网络不通、密钥错误、端口 1812 不通

3. 日志方式（V5 日志能力弱，不记录详细失败原因）

V5 只会记录很简单告警，不会带详细失败原因，只能辅助看端口 up/down。

V5 老交换机排 802.1x 认证失败，优先在 RADIUS 服务器上查日志（IMC / 第三方 RADIUS），RADIUS 侧会记录拒绝原因（账号不存在、密码错误、用户过期、接入限制），交换机本身记录能力有限。

三、通用排查流程（不分 V5/V7，标准化步骤）

1. 确认端口全局、端口下 dot1x 开启，端口控制模式（port-control auto）
2. 确认认证域、radius-scheme 配置，共享密钥、RADIUS 服务器 IP / 端口正确
3. 客户端抓 EAPoL 报文：看客户端是否发送 EAP-Start
4. 交换机侧 debug：看交换机是否收到 EAP 报文、是否发出 RADIUS 请求
5. RADIUS 服务器日志（IMC 最关键）：
   • Access-Reject：服务器拒绝（账号 / 密码 / 权限）
   • 无请求到达：交换机和 RADIUS 之间网络问题
6. 检查 Quiet-period（认证失败静默周期，输错密码后端口静默，短时间不能重试） display dot1x timer

四、常见失败原因对照表（日志 /debug 识别）

1. RADIUS Access-Reject：账号密码错误、账号禁用、用户不在接入策略、MAC 绑定失败（IMC）
2. RADIUS 超时无应答：RADIUS 服务器不可达、路由 / ACL 拦截 1812 端口、密钥不一致
3. EAP 握手超时：客户端 802.1x 客户端异常、网卡 / 驱动问题、中间设备丢弃 EAPoL
4. 重认证失败、实时计费失败：认证成功后异常下线，RADIUS 计费端口 1813 不通
5. 域错误、强制认证域配置错误：用户使用错误的认证域提交认证

五、长期运维优化建议

1. 部署 Syslog 服务器：所有交换机把日志外送到 syslog，V5/V7 都支持，不用登录每台设备看本地 buffer；V7 开启dot1x access-user log enable failed-login，syslog 集中存储所有认证失败记录，替代 online-fail-record。
2. IMC 场景：直接在 IMC 接入管理页面查看 802.1x 认证失败日志（IMC 记录最完整，优先查 IMC）
3. 版本规划：如果需要display aaa online-fail-record，V7 交换机需要升级到支持该特性的版本。

补充命令速查表

表格

(1) 配置RADIUS 方案
# 创建RADIUS 方案radius1 并进入其视图。
[SwitchA] radius scheme radius1
New Radius scheme
# 配置主认证/计费RADIUS 服务器的IP 地址。
[SwitchA-radius-radius1] primary authentication 10.1.1.1 1645 key abc
# 配置发送给RADIUS 服务器的用户名不携带域名。
[SwitchA-radius-radius1] user-name-format without-domain
# 配置发送RADIUS 报文的源接口IP。
[SwitchA-radius-radius1] nas-ip 10.1.1.2
#
(2) 配置ISP 域
# 创建域test 并进入其视图。
[SwitchA] domain test
# 配置802.1X 用户使用RADIUS 方案radius1 进行认证、授权方法。
SwitchA-isp-test] authentication lan-access radius-scheme radius1
[SwitchA-isp-test] authorization lan-access radius-scheme radius1
#
（3） 指定域test 为缺省的ISP 域。如果用户在登录时没有提供ISP 域名，系统将把它归于该缺省的ISP
域。
[SwitchA] domain default enable test

#

#
# 开启全局802.1X 特性。
[SwitchA] dot1x
#
# 开启指定端口GigabitEthernet1/0/1 的802.1X 特性。
[SwitchA] interface gigabitethernet 1/0/1
[SwitchA-GigabitEthernet1/0/1] dot1x

这三步是有顺序的，2引用1,3引用2.  802.1X配置就这些内容，你挨个检查