Ad-campus上mac地址认证问题

这个现象大概率不是 AD-Campus 的 BUG，而是一个在 MAC 认证场景里非常典型、而且容易被"换 VLAN 就好使"这个线索一眼看穿的问题链。拆开来解释你这个现场到底卡在哪。
一句话结论
你在 EIA / 控制器上清了"在线用户 + 名址绑定"，但这并不等于在终端网卡的认知里触发了一次"重新申请 IP"；同时交换机侧可能还残留 DHCP Snooping / 表项状态，导致 DHCP 报文被吞或不被转发到正确 VLAN/VXLAN 里——于是终端退化到 169.254.x.x。
换 VLAN 之所以立刻好，是因为 VLAN 一变，终端检测到网络环境变化，重做完整 DHCP（Discover→Offer→Request→ACK）；同时端口 VLAN/VSI 上下文也跟着硬切换了一遍，把残留状态一块儿刷掉。
为什么会走到 169（逐层拆解）
1）终端这边：链路没"断"，DHCP 就不会自觉重发
MAC 认证强制下线后，很多实现方式是：
端口把 MAC 认证状态清掉 → 回到未认证/Guest/Free VLAN
然后再触发重认证 → 认证通过 → 切到授权 VLAN
但对 Windows/macOS 来说：网线没拔、接口没 Down/Up，它就觉得"我还连着呢"，于是：
旧 IP 的租约已经被你清掉/失效
它尝试续租失败
最终走 APIPA → 169.254.x.x
这就是你看到的核心表象。
2）交换机侧：你清的不够"深"（DHCP Snooping / 绑定表残留）
H3C 自己的排障文档也点到这个点：
"DHCP snooping entry carries the old IP…device sends old IP to EIA via accounting…EIA binds that IP again"，以及 Option 82 策略不匹配导致 DHCP 服务器不回 Offer
在 AD-Campus（VXLAN + 授权 VLAN 由 EIA Tunnel-Private-Group-ID 下发）里，常见残留包括：
DHCP Snooping binding table​ 里还有旧 MAC→旧IP→旧VLAN 的记录（尤其在 Leaf/接入开启 snooping 时）
这些残留会让 DHCP Offer/ACK 被 snooping 校验丢包，表现为：你能看到 Discover 出去，但终端就是拿不到地址
3）授权 VLAN 没"变"：就不会产生让终端重新 DHCP 的触发条件
你清的是 EIA 在线/绑定，终端重认证后：
如果这次 EIA 下发的授权 VLAN 和刚才一模一样​ → 端口 VLAN 上下文可能没有明显"切换事件"
于是终端更没有理由重发 Discover
而你说手动在接入交换机上更换 VLAN 后能拿到——这就直接对上了：换 VLAN = 强制终端感知网络变化 = 完整 DHCP 四次握手重新跑一遍。
你现在该怎么"彻底清"才有用（建议操作顺序）
下面这些才是对应这个问题的正确清法，而不是只在 EIA 页面点"强制下线/解绑"。
Step 1：在接入交换机（或 Leaf）上把 MAC 认证用户真正踢下线
# 用户视图
reset mac-authentication access-user mac xxxx-xxxx-xxxx
# 或按接口踢
reset mac-authentication access-user interface GigabitEthernet 1/0/X
对应文档里的用法说明：踢下线后会删用户信息，下次需要重新认证。
Step 2：清掉 DHCP Snooping 可能残留的绑定（如果现场开了 snooping）
# 看一眼有没有
display dhcp snooping binding mac xxxx-xxxx-xxxx

# 有的话清
reset dhcp snooping binding mac xxxx-xxxx-xxxx
Step 3：让终端强制重获（最关键的一步）
做完上面两步后，别只等它自动恢复，直接在终端侧：
# Windows
ipconfig /release
ipconfig /renew

# Linux
dhclient -r; dhclient
如果你不方便碰终端，也可以把接入口 shutdown → 等 2s → undo shutdown​ 人工制造一次链路事件（效果等同于"换 VLAN"触发的那种重 DHCP）。
什么时候才算"疑似 BUG / 需要开 Case"
符合下面任一情况时，再去怀疑版本缺陷或控制组件瞬态问题（并准备抓包找 H3C 400）：
即便你把接口 shutdown/undo shutdown（强制链路Down/Up），终端发 DHCP Discover 出去，但在 Leaf/网关侧抓不到该 VLAN/VSI 的 Discover​ → 说明 VXLAN service-instance/映射或 DHCP relay agent 没跟上授权 VLAN 切换
同一个终端、同一根线、什么都不改，每天固定复现（比如重认证周期一到就 169）​ → 要查 MAC 重认证时授权 VLAN 瞬态是否会短暂把 DHCP 报文丢掉
你确认没开 DHCP Snooping / 也没 Option 82 策略问题，但 Offer 明明回来了却被交换机丢弃​ → 需要看具体设备型号+软件版本
给你一个"现场最快验证"的判定法
在你复现 169 的那一刻，接入口抓一次（或做端口镜像看）：
能看到 DHCP Discover（广播）出去，但永远没有 Offer 回来​ → 问题在：授权 VLAN/VXLAN 转发路径 / DHCP 服务器不可达 / Option 82 不匹配
连 Discover 都看不到（交换机没把它放进业务 VLAN/VSI）​ → 问题在：MAC 认证状态还没到授权成功（还在 Guest/Free VLAN 或 Drop 状态），或者 Free VLAN 没放通 DHCP（有些版本需要关注 pre-auth 放通策略/trust）
有 Discover 也有 Offer，但终端仍 169​ → 99% 是终端没真重发（你看到的 169 是旧续租失败的终态），回到上面的 ipconfig /renew验证
如果你愿意把两点信息贴出来，我可以把结论从"大概率不是 BUG"进一步收敛到"就是你这个版本/配置组合里的哪一个环节"：
接入是 Leaf 直接接终端​ 还是 传统接入交换机 → Leaf uplink（VXLAN）？
现场 DHCP Snooping / IPSG / Option 82 策略​ 开了没有？（哪怕不确定也行，我教你一条 display看）
另外：你说的"在接入交换机更换 VLAN 后，可以拿到地址"——是在接口上手动改 port access vlan X还是改的 Underlay/Overlay 映射？这个区别会影响到底是"终端触发"还是"VSI/服务实例刷新"在起作用。

联系办事处或者400协助吧

SDN都是办事处实施 

首先在交换机上查下有没有终端的认证表项，一般拿不到地址是因为mac认证没通过

 为什么更换 VLAN 就能解决？

1. 终端的网卡、网线、物理端口都是正常的。
2. 新 VLAN 对应的 DHCP 服务器或中继是正常的。
3. 问题出在旧 VLAN 及其关联的底层网络策略上。

 导致旧 VLAN 拿不到地址的核心原因

• 当你在平台强制下线并清除绑定时，这些下发到交换机底层的动态 ACL 或安全策略可能没有同步清除。
• 这些残留策略可能会继续拦截该终端的 DHCP 请求报文（UDP 67/68 端口），导致 DHCP 请求根本发不出去，或者响应包被拦截。
• 为什么换 VLAN 就好了？ 因为换了 VLAN 后，终端匹配到了新的接口策略，绕过了旧 VLAN 下残留的拦截规则。

• 旧 VLAN 的 DHCP Snooping 绑定表中，可能还残留着这台终端 MAC 地址的旧记录。当终端重新请求地址时，交换机会发现请求报文进来的接口或 VLAN 与表中的记录不匹配，从而判定为非法报文并直接丢弃。

 后续排查与解决建议

1. 在接入交换机上清理动态表项（最有效）：
   登录到终端连接的接入交换机，执行以下命令清除该 MAC 地址相关的动态残留：
   • reset access-user mac-address <终端MAC> （清除接入用户信息）
   • reset portal user mac <终端MAC> （清除 Portal 用户信息，如有）
   • reset dhcp snooping user-bind mac-address <终端MAC> （清除 DHCP Snooping 绑定表项）
   • reset acl dynamic all （谨慎操作，清除所有动态 ACL，或者根据具体情况查找并删除针对该 MAC 的动态 ACL）
2. 终端侧刷新网络：
   在电脑上以管理员身份打开 CMD，执行 ipconfig /release 然后 ipconfig /renew，强制重新发起 DHCP 请求。