交换机配置了mac重认证，但是重认证超时时间后服务器未收到重认证数据包

现象复盘
终端 MAC 认证失败 → 进入 Guest VLAN；预期30s 周期发起重认证，实际等待约 20 分钟才再次发起认证，RADIUS 服务器长时间收不到交换机重认证报文。
核心机制区分（绝大多数人配置混淆根源）
两套完全独立定时器，不能混用
在线成功用户周期性重认证
plaintext
mac-authentication re-authenticate enable
mac-authentication timer reauth-period xxx
作用：认证成功、正常在线的用户周期性重认证；
⚠️ 对 Guest VLAN 内认证失败用户不生效！
Guest VLAN 内失败用户重认证（你需要的功能）
plaintext
# 接口视图下
mac-authentication guest-vlan re-authenticate
mac-authentication guest-vlan auth-period 30
缺省开启，默认间隔 30 秒，专门针对认证失败进入 Guest VLAN 的终端。
导致 “等待 20 分钟才重认证” 四大根因（按排查优先级排序）
根因 1：未关闭【未认证用户老化定时器】（最高概率）
plaintext
# 系统视图全局命令
display mac-authentication | include aging
存在一条定时器：
User aging period for guest VLAN : 1200s（20分钟）
命令：
mac-authentication unauthenticated-user aging enable
功能解释：
当终端进入 Guest VLAN 后，如果持续无流量，交换机内部的 Guest 用户表项最多存活guest-vlan aging period（默认很多平台是 1200 秒 = 20 分钟）；
👉 表项存在期间，不会持续按照 guest-vlan auth-period 发起重认证；表项老化删除后，终端重新触发首次 MAC 认证。
现象表现：正好 20 分钟左右才重新上线，和你现象完全吻合！
通俗理解：
终端进 Guest-VLAN → 生成 Guest 用户表项；
若无流量，交换机暂停主动重认证；等到 20 分钟表项老化消失；
终端再次收发流量，交换机重新发起第一次 MAC 认证。
✅ 解决方案：
plaintext
system-view
undo mac-authentication unauthenticated-user aging enable
关闭未认证用户老化，Guest 内用户持续按照guest-vlan auth-period周期发起重认证。
根因 2：混淆两套重认证命令
只配置了全局mac-authentication re-authenticate，没有在接口确认 Guest VLAN 重认证开启
核查接口配置：
plaintext
interface GigabitEthernet 1/0/X
display this | include guest-vlan
确保存在：
plaintext
mac-authentication guest-vlan re-authenticate
mac-authentication guest-vlan auth-period 30
根因 3：静默定时器 quiet-period 干扰
全局 MAC 认证存在静默周期：
plaintext
mac-authentication timer quiet 60
认证失败后，MAC 进入静默期，静默期内交换机不再主动发起认证。
⚠️ 注意：静默 MAC 与 Guest VLAN 存在互斥，部分固件版本逻辑异常叠加会抑制重认证。
根因 4：终端在 Guest VLAN 长时间无上下行流量
MAC 地址老化、交换机认为终端离线，暂停重认证触发；
可以在交换机侧开启终端保活（ARP 探测）辅助。
完整核查命令清单（登录交换机逐条执行）
plaintext
# 1、查看全局MAC认证所有定时器
display mac-authentication

# 重点观察字段
Guest VLAN auth-period
User aging period for guest VLAN
Quiet period

# 2、查看接口Guest重认证状态
display this interface GigabitEthernet 1/0/X | include mac-authentication guest

#3、查看当前Guest VLAN内在线用户表项
display mac-authentication guest-vlan-user
标准修正配置模板
plaintext
system-view
mac-authentication
# 关闭未认证用户老化（关键！解决20分钟延迟）
undo mac-authentication unauthenticated-user aging enable
# 按需调整静默时间，不要过大
mac-authentication timer quiet 30

interface GigabitEthernet 1/0/1
mac-authentication guest-vlan 40
# 开启Guest VLAN重认证（缺省开启，建议显式配置）
mac-authentication guest-vlan re-authenticate
# 设置30秒重认证周期
mac-authentication guest-vlan auth-period 30
补充验证手段
在交换机上联口抓 RADIUS 报文（UDP 1812）；
终端进入 Guest VLAN 后观察抓包：
修复前：30s 无 RADIUS 报文，20 分钟后出现；
修复后：每 30s 交换机主动向 RADIUS 服务器发送 MAC 认证请求。
极简总结
你遇到的 20 分钟延迟，90% 是开启了 mac-authentication unauthenticated-user aging enable 未认证用户老化功能。
Guest VLAN 内失败用户表项 20 分钟老化删除，之后终端流量才重新触发首次认证，造成 “重认证失效” 假象；关闭该老化定时器即可恢复 30s 周期性重认证。

你遇到的这个问题，核心原因很可能是混淆了两种不同的重认证定时器。

你配置的“30秒重认证”是针对Guest VLAN内用户的定时器，而你观察到的“20分钟”现象，则是由另一个针对未认证用户老化的定时器触发的。

🎯 问题根源：两套独立的定时器

H3C交换机为MAC地址认证设计了两个独立定时器，分别服务于不同状态的用户。

1. Guest VLAN重认证定时器（你配置的）

   • 作用对象：已经认证失败、并被移入Guest VLAN的用户。

   • 配置命令：在接口视图下使用 mac-authentication guest-vlan auth-period 30。

   • 功能：每隔30秒，交换机应该会向RADIUS服务器发起一次重认证请求，尝试让该用户重新上线。

2. 未认证用户老化定时器（真正的原因）

   • 作用对象：所有处于“未认证”状态的用户，包括Guest VLAN内的用户。

   • 默认值：在很多平台上，默认值为 1200秒，正好是20分钟。

   • 功能：这是一个老化机制。当用户进入Guest VLAN后，交换机会创建一个表项。如果该用户持续没有流量，这个定时器就会开始倒计时。在表项老化（20分钟）之前，交换机不会主动发起重认证。只有表项老化被删除后，用户再次产生流量，才会触发新的首次认证。

💡 解决方案：调整正确的定时器

要解决这个问题，需要根据你的实际需求，调整对应的定时器。

方案一：缩短“未认证用户老化定时器”（推荐）

如果你想实现“认证失败后，每隔30秒就重试一次”的效果，需要将未认证用户的老化时间也调整为30秒或更短，使其与Guest VLAN重认证定时器匹配。

• 查看当前配置：使用命令 display mac-authentication | include aging 查看当前的“未认证用户老化时间”。

• 修改配置：在系统视图下，使用命令 mac-authentication unauthenticated-user aging enable 开启老化功能，并通过 mac-authentication timer unauthenticated-user aging 命令将时间设置为需要的值（例如30秒）。

方案二：关闭“未认证用户老化定时器”

如果希望用户进入Guest VLAN后，由交换机根据 guest-vlan auth-period 定时器主动发起重认证，不受无流量影响，可以尝试关闭老化功能。

• 关闭老化：在系统视图下，使用命令 undo mac-authentication unauthenticated-user aging enable。

🛠️ 诊断与排查步骤

1. 检查当前配置

   • 使用 display mac-authentication 命令，检查输出中的 Reauth period（在线用户重认证周期）、Guest VLAN auth-period（Guest VLAN重认证周期）等关键参数。

   • 使用 display mac-authentication interface [接口名] 确认接口下的MAC认证及重认证功能是否已开启。

2. 检查RADIUS计费配置

   • 确认RADIUS方案下是否配置了计费。有案例指出，重认证可能依赖计费报文进行计时，若计费未配置或更新失败，可能导致重认证无法发起。

   • 可以尝试调整计费更新间隔 timer realtime-accounting（默认12分钟）。

3. 抓包验证

   • 在交换机的上联口进行抓包，过滤RADIUS报文（端口1812），观察是否存在Code=11的重认证请求，以确认问题出在交换机未发送，还是服务器未收到。