【交换/认证】MAC认证部分通过部分不通过

这是一个非常经典且棘手的MAC认证故障。您已经做了很多正确的排查，问题很可能出在细节和流程配合上。debug无回显是关键线索，说明认证流程可能未被成功触发。以下是系统的排查思路和命令。
核心排查思路
“部分能过，部分不能过”通常源于终端行为差异或设备安全机制干扰，导致交换机未能正常学习MAC或触发认证。请按以下顺序排查。
第一步：确认MAC是否被交换机成功学习（根本）
这是最关键的一步。MAC认证的前提是交换机数据平面（MAC地址表）先学到MAC，控制平面（认证模块）才能据此发起认证。
在故障端口接入一台认证失败的哑终端。
在交换机上持续ping该终端的IP，或让终端持续ping网关，以产生流量。
执行以下命令，查看MAC地址表：
# V7设备
display mac-address interface GigabitEthernet 1/0/2
# 或查看所有MAC，关注该终端MAC的状态
display mac-address | include aaaa-bbbb-cccc
如果完全看不到该MAC：证明问题在链路层或安全特性，认证流程根本不会启动。请跳至 链路层与安全特性排查。
如果看到MAC状态为BLOCK/STICKY/等：证明MAC被学习但被安全模块阻止。请跳至 安全特性排查。
如果看到MAC状态为动态（DYNAMIC）：说明MAC学习正常，但认证未触发或失败。请跳至 认证流程与服务器联动排查。
第二步：链路层与安全特性排查（针对“学不到MAC”）
如果display mac-address看不到终端MAC，问题出在更底层。
检查端口基础状态与错误包：
display interface GigabitEthernet 1/0/2 brief
display interface GigabitEthernet 1/0/2 | include error|discard|CRC
确认端口Status为UP，Protocol为UP，且错误包极少。
检查并临时关闭可能的一层安全功能（测试后恢复）：
# 查看是否有端口安全、MAC地址学习限制
display current-configuration interface GigabitEthernet 1/0/2 | include security|mac-limit|mac-learn
# 常见命令如：port-security, mac-address max-mac-count, mac-address sticky-learning
重要测试：在故障接口下，尝试临时取消mac-authentication和dot1x，只做纯Access口，看能否学习到MAC。如果此时能学到，则证明是认证功能与某些特性冲突。
第三步：认证流程与服务器联动排查（针对“学到但不过”）
如果MAC能被学到但认证失败，需深入查看认证流程。
获取详细的认证会话信息：
# V7设备关键命令
display mac-authentication connection interface GigabitEthernet 1/0/2 verbose
# 查看该接口下所有MAC认证的详细状态，包括认证阶段、失败原因码

display access-user interface GigabitEthernet 1/0/2
# 查看该接口上已上线用户，与失败终端形成对比
启用更深入的Debugging（请在业务闲时进行，并准备终止命令）：
terminal monitor
terminal debugging
debugging mac-authentication event
debugging mac-authentication error
debugging radius packet
然后触发故障终端的认证（插拔网线或重启终端）。观察控制台输出，重点关注Radius报文交互。无回显或服务器无响应是关键线索。
测试user-name-format（您思路正确！）：
MAC地址中的字母大小写和分隔符必须与Radius服务器上配置的完全一致。这是最常见的原因之一。
# 在系统视图或MAC认证视图下尝试修改格式
mac-authentication user-name-format mac-address with-hyphen lowercase
# 常用格式：
# mac-address with-hyphen lowercase (aa-bb-cc-dd-ee-ff) *最常用*
# mac-address without-hyphen lowercase (aabbccddeeff)
# mac-address with-hyphen uppercase (AA-BB-CC-DD-EE-FF)
必须与奇安信Radius服务器上配置的用户名格式（大小写、分隔符）100%匹配。这是排查的重点。
第四步：服务器端协调排查
这是解决“部分不通过”的最终环节。需要奇安信管理员配合。
提供失败终端的详细信息：将认证失败的终端MAC、连接交换机IP/端口、故障时间点提供给奇安信管理员。
查询Radius服务器日志：让管理员在奇安信平台查询该时间段、该MAC地址的认证日志。服务器拒绝的原因（如“用户不存在”、“密码错误”实际上对应MAC不在名单）​ 会明确记录在案。
确认白名单策略：确认奇安信上配置的MAC认证策略（如认证域、用户名格式）与交换机配置完全匹配。确保失败终端MAC确实被添加到了正确的认证策略/用户组中。
总结与建议操作清单
立即执行：在故障端口，用 display mac-address interface确认故障终端的MAC学习状态。这是分水岭。
核心测试：在交换机上修改 mac-authentication user-name-format为另一种格式（如改为带横杠小写），并与奇安信管理员确认服务器期望的格式。这能解决50%以上的问题。
深入诊断：在业务低峰期，开启 debugging mac-authentication event error和 debugging radius packet，重现故障，捕捉交换机和服务器之间的具体交互报文。
寻求最终证据：务必联系奇安信管理员，从服务器日志中查找认证失败记录，获取明确的拒绝原因码。
您遇到的“部分能过”说明整体配置和流程是通的，问题极有可能出在终端MAC地址在传递到服务器时格式不一致，或服务器端针对这些特定MAC存在不同的策略判定。请优先从用户名格式和服务器日志两头进行核对。