AGV漫游的"认证之旅"
从痛点到极速漫游的五幕剧

为什么一次漫游会让整条产线瘫痪？

想象这样一幕：总装车间里，数十台 AGV 如同训练有素的快递员，沿着虚拟轨道穿梭， 将零件精准送往每一个工位。整个流程行云流水，直到某一刻，MQTT 调度心跳包忽然沉默—— AGV 们像被施了魔法，就地停摆。

根源追查下来，不是无线信号问题，而是 ISE（身份验证服务器）遭遇了高延迟。 每次 AGV 从一块 AP 的覆盖区漫游到另一块，都要重新进行完整的 802.1X EAP-TLS 证书握手—— 这个过程完全依赖 ISE，ISE 一旦慢了，AGV 就断网了。

问题一：没有任何辅助的情况下，漫游到底发生了什么？

思考一个基本问题：为什么 AGV 在没有开启 802.11K/V 的情况下，漫游会更慢、更不稳定？

答案藏在"侦察成本"里。没有 802.11K 的邻居列表，AGV 的无线网卡就像一个没有地图的外卖员—— 不知道附近哪个 AP 信号更好，只能暂停送餐、挨个敲门（主动扫描所有信道）， 扫描完才能决定去哪家"驻扎"。扫描本身就要耗费数百毫秒。

找到目标 AP 之后，麻烦还没完——没有 OKC / 802.11R，之前在旧 AP 上做的 EAP-TLS 证书握手 完全作废，必须从头来过。这等于每次漫游都要重新"入职面试"，不论已经工作多久。

完整时序图

逐步分析

1. 主动盲扫（无地图的外卖员）

   AGV 不知道周围有哪些 AP，必须逐信道广播 Probe Request。2.4GHz 有 13 个信道，5GHz 有更多 DFS 信道，盲扫耗时 150~400ms。
   150~400ms
2. 802.11 关联（全新入网）

   没有 PMKID 缓存，Association Request 中不携带任何身份凭证。WLC 检查：无匹配 PMKID → 触发完整 EAP 认证。
   20~40ms
3. EAP-TLS 完整握手（完全依赖 ISE）

   包括：EAP Identity 交换 → TLS ClientHello → ISE ServerHello + 证书下发 → 客户端证书上传 → ISE 证书验证（CRL/OCSP）→ Access-Accept。 约 10~15 轮 RADIUS 往返。ISE 每增加 100ms 延迟，整体延迟线性增加。
   物理根因（Fragmentation）：EAP-TLS 证书通常 2~8 KB，远超 EAP 链路 MTU（实测 Framed-MTU = 1485），握手报文被切成 4~6 个 EAP 分片传输。AGV 在弱信号边缘只要丢掉任意一片，整段 TLS 就要重传或推倒重来，这是漫游时延不可控的根本原因。
   200~600ms+
4. 四步握手（4-Way Handshake）

   基于 EAP-TLS 生成的 MSK 派生 PMK，再通过 4-Way Handshake 生成 PTK/GTK，建立加密数据信道。此阶段不依赖 ISE。
   20~40ms
5. 端口放行，数据流恢复

   802.1X 端口状态转为 Authorized，AGV 重建 TCP 连接，MQTT 心跳恢复。
   20~50ms

问题二：有了 802.11K/V，漫游到底快了哪里？

802.11K 给了 AGV 一份"附近 AP 信号排行榜"——当 AGV 向当前 AP 请求邻居列表时， WLC 会根据 RF 关系精心计算一份候选名单，AGV 只需扫描名单上的几个 AP，而不必盲扫所有信道。 这相当于从"挨家敲门"升级为"按图索骥"，扫描时间从数百毫秒缩短到 20~50ms。

802.11V 则是 AP 主动"推一把"——当 AGV 的 RSSI 跌破阈值，WLC 通过 BSS Transition Management Request 告诉 AGV："你该换 AP 了，去找 AP2 吧。" 这解决了"粘性客户端"问题，让漫游时机更精准。

但关键矛盾未解决：漫游时机和目标选择都优化了， 然而到达新 AP 之后，因为终端不支持 OKC（Opportunistic Key Caching，机会性密钥缓存）， 新 AP 和 WLC 无法找到任何有效的 PMK 缓存，仍然必须触发完整的 EAP-TLS 认证。 就像换了一条更好走的路，但到了目的地还是要重新过安检。

完整时序图

逐步分析

1. 802.11K 邻居列表（精准导航）

   WLC 根据每块 AP 的 RF 邻居关系，为 AGV 定制候选 AP 排行榜。AGV 只需扫描名单内的 2~3 个 AP，精准快速。
   5~15ms
2. 802.11V BSS Transition（主动推送）

   当 AGV 信号质量下降，AP 主动发送 BSS Transition Request，告知最佳目标 AP，解决"粘性客户端"不肯漫游的问题。
   10~20ms
3. 定向 Probe + 重新关联

   只 Probe 候选 AP2，耗时 20~50ms。关联时 Association Request 中无有效 PMKID（终端不支持 OKC），WLC 触发完整 EAP 流程。
   20~50ms
4. EAP-TLS 完整认证（瓶颈不变）

   与场景一完全相同：10~15 轮 RADIUS 交互，ISE 证书验证是关键路径。ISE 延迟直接决定本阶段时长。证书分片丢包风险也与场景一相同——11K/V 只解决了"怎么找到下家"，并没有解决"为什么过桥那么慢"。
   200~600ms+
5. 四步握手 + 数据流恢复

   与场景一相同，不依赖 ISE。
   40~90ms

问题三：AAA Cache 的本质是什么？它真的消除了 EAP-TLS 认证吗？

先回答第二个问题：不，AAA Cache 并未消除 EAP-TLS 握手，它消除的是对远端 ISE 的依赖。

理解这一点需要先弄清 AAA Cache 的工作机制。当 AGV 第一次成功通过 ISE 认证后， WLC（WNCD 进程）会在本地存储这份认证结果——包括用户名、Profile、授权属性（VLAN、dACL）等， 有效期默认 24 小时（可配置，设为 0 则永不过期）。

当 AGV 下次漫游时，WLC 会按照方法列表的优先级检查： 先去问 ISE（如果 ISE 可达）；ISE 不可达或超时，再用本地缓存。 若配置为"cache first"，则先查缓存、缓存命中直接用，ISE 只是候补。

但有一个关键细节（来自 Cisco TAC 文档的重要提示）： 对于 EAP-TLS 这类"安全类型 8"，缓存命中后 WLC 并不能直接放行—— TLS 握手涉及证书双向验证，密钥材料不可复用， WLC 会转用 Local EAP 在本地完成 TLS 握手， 无需将报文转发给远端 ISE。整个过程对 AGV 透明，认证速度更快也更稳定。

完整时序图

逐步分析

1. 802.11K/V 加速扫描（同场景二）

   精准定向扫描候选 AP，耗时 30~70ms。
   30~70ms
2. AAA Cache 命中查询

   AGV 提交 Identity 后，WLC 先查本地缓存（WNCD AAA Cache）。命中用户 SYLYD02173 的 Profile，确认用户存在，但 EAP-TLS 握手仍需在本地执行。
   1~5ms（本地查询）
3. Local EAP-TLS 握手（WLC 本地完成）

   WLC 使用配置的 EAP Profile（Trustpoint）作为 EAP Server，与 AGV 完成 TLS 双向握手。 全程在 WLC 本地处理，无需任何 RADIUS 往返 ISE。 延迟稳定、可预期，不受 ISE 负载影响。 隐性收益：证书分片（见场景一）只在 WLC↔AP 的空口 / CAPWAP 这一段传输，跨 WAN 抖动不再放大丢包概率。
   100~200ms
4. 从缓存读取授权属性

   TLS 握手成功后，WLC 从 AAA Cache 读取预存的授权属性（VLAN ID、dACL、SGT），无需 ISE 下发 Access-Accept。
   1~3ms
5. 四步握手 + 数据流恢复

   标准 4-Way Handshake，端口放行，MQTT 恢复。
   40~90ms

问题四：OKC 的魔法究竟是什么？PMK 怎么"传递"到新 AP？

要理解 OKC，先要理解一个基本事实：EAP-TLS 认证成功后，最终产物是一个 PMK（Pairwise Master Key，成对主密钥）——这是双方身份验证的"信任结晶"。 有了 PMK，就可以直接做四步握手，推导出加密数据用的 PTK，而无需重新证明身份。

场景一和二的问题：PMK 只保存在原来的 AP 和 WLC 上。AGV 漫游到新 AP 时， 新 AP 不认识这把"钥匙"，只能重新认证。

OKC 的解法：Catalyst 9800 WLC 将 PMK 缓存在 WLC 的全局缓存中， 所有 AP 共享访问。当 AGV 漫游到新 AP 时，会在 Association Request 中携带 PMKID（PMK 的指纹哈希）。WLC 一查全局缓存，命中！ 直接跳过整个 EAP 认证流程，进入四步握手。

这就像酒店的万能门卡系统——前台认证一次，生成房卡（PMK）， 之后在酒店任何一层楼、任何一个副卡读卡器（任何 AP）都能直接刷卡进门， 不需要每次都回前台重新办理。

完整时序图

逐步分析

1. 初次认证（一次性成本）

   AGV 首次接入时完整执行 EAP-TLS，成功后 WLC 将 PMK 存入全局缓存。此后所有漫游均可复用。
   一次性
2. 802.11K/V 精准导航（同前）

   邻居列表 + BSS Transition，快速定位目标 AP2。
   30~70ms
3. 携带 PMKID 的 Association Request（OKC 核心）

   AGV 在 Association Request 的 RSN IE 中携带 PMKID = HMAC-SHA1(PMK, AP MAC + AGV MAC)。WLC 比对全局 PMK Cache，命中即免 EAP。
   10~20ms
4. 四步握手（EAP-TLS 完全跳过）

   直接用复用的 PMK 推导 PTK/GTK，完成加密信道建立。整个流程不涉及 ISE，延迟稳定极短。
   20~40ms

为什么 OKC 没有写进 IEEE 标准？

① 出身：WPA2 PMKID 缓存的"私自增强"

标准 WPA2 只规定了"客户端连过某 AP 才能缓存这台 AP 的 PMK"（SKC，Strict Key Caching）。 OKC 把它扩大到"整个 WLAN 基础设施共享同一把 PMK"——一台 AP 上算出的 PMK，其他 AP 直接复用。 这个"扩展"从未进入 IEEE 802.11 规范，技术上是 Cisco / Aruba 等厂商的事实标准（de facto），不是法定标准（de jure）。

② IEEE 的选择：另起炉灶

面对相同的漫游慢问题，IEEE 没有照搬 OKC，而是发布了两个完全不同的官方机制：

• 预认证（Preauthentication，802.11i 内置）：终端在还连着旧 AP 时，通过骨干网提前与目标 AP 完成 802.1X 认证。和 OKC「共享密钥」的思路完全不同——这边是「提前认证」。
• 802.11r FT（Fast BSS Transition）：2008 年正式发布的独立修正案，重构了密钥层级（PMK-R0 / PMK-R1）和漫游状态机，关联前就已经协商好密钥。这条路线最终成为快速安全漫游的官方答案，也就是本文的场景五。

③ 工程现实：终端支持的"碎片化反噬"

没有 RFC、没有 IEEE 强制规范，意味着没有任何官方文档要求网卡驱动必须实现 OKC。直接后果：

• 桌面 / 手机阵营：Intel / Apple / Microsoft 出于行业默契普遍支持，部署成功率较高。
• 工业 IoT 阵营：AGV、扫码枪、PLC 网卡等芯片厂商追求极致成本，没有任何动力去实现一个非标准协议。这就是为什么你在产线上经常发现"WLC 明明开了 OKC，但 AGV 仍然走完整 EAP-TLS"。

→ 下一章回到主线，进入 场景五：802.11r FT 在关联前完成密钥协商

问题五：802.11r 与 OKC 都能跳过 EAP-TLS，它们有什么本质区别？

两者解决的是同一个问题（避免漫游时重复 EAP 认证），但切入点不同：

OKC（场景四）：在 Association 时携带 PMKID，WLC 验证缓存命中后免 EAP， 然后再做四步握手。密钥推导发生在 关联完成之后。

802.11r FT（场景五）：AGV 在还连接着 AP1 时，就提前与目标 AP2 通过 FT 预认证（Over-the-DS 或 Over-the-Air）完成密钥协商， 生成 PTK 所需的 ANonce/SNonce。漫游时的 Reassociation Request/Response 同时完成关联和密钥确认，实现真正的"无缝切换"。密钥推导发生在 关联之前。

类比：OKC 是"到了新门口，掏出备用钥匙开门"； 802.11r 是"还没离开旧房间，就已经在门口等好了，钥匙都对好了，一步跨进去"。

完整时序图（支持 802.11r 的 AGV）

逐步分析

1. 初次认证（一次性成本）

   完整 EAP-TLS，WLC（R0KH）生成 PMK-R0，分发给各 AP（R1KH）。此后漫游无需重复。
   一次性
2. FT 预协商（Over-the-DS，仍在 AP1 连接中）

   AGV 通过 AP1 的 DS（分布式系统）向目标 AP2 发送 FT Auth Request， 携带 MDE + FTE。WLC 作为中转，完成 PMK-R1 推导和 ANonce 生成。 AGV 收到 FT Auth Response 后，已具备推导 PTK 的全部材料。
   20~40ms
3. Reassociation（关联即完成，无需额外四步握手）

   AGV 向 AP2 发送 Reassociation Request，同时携带 FTE（含 SNonce + MIC）， AP2/WLC 验证后回复 Reassociation Response。 此时 PTK 已确认，端口立即放行，数据流可立即恢复。
   10~20ms

Catalyst 9800 的 Mixed Mode 真的能让新旧 AGV 共存吗？

① 第一性原理：终端如何判断 AP 支不支持 11r？

关键在 Beacon 帧内部的 RSN IE（Robust Security Network IE），其中包含一份 AKM 套件列表（Authentication and Key Management）：

• 老旧终端只认 802.1X、PSK 这类基础 AKM。
• 支持 11r 的新终端会找 FT+802.1X、FT+PSK 这类带 FT 标识的 AKM。

致命陷阱：如果 WLAN 配置为 Fast Transition = Enabled 且只勾选 FT+802.1X， 旧终端读 Beacon 时根本不认识这个 AKM，连 Association Request 都不会发——直接判定网络不兼容，完全无法上线。

② 三种部署模式对比

③ 历史插曲：Adaptive 11r 为什么被淘汰

早年（2015 前后）一批劣质工业网卡无法正确解析含多个 AKM 套件的 RSN IE，会直接拒绝连接。 Cisco 联手 Apple / 三星搞出 Adaptive 11r 这套"暗号"机制：表面只广播基础 AKM 骗过老网卡，私下用 MDIE 与 Apple / 三星协商 FT。

到了 2025，这种劣质网卡几乎已退役；反而 Adaptive 自己暴露出两大新问题： (1) 与 WPA3-Enterprise / 6 GHz 强制要求显式 FT AKM 的规则冲突； (2) 部分不支持 FT 的现代设备反而因为看不到熟悉的 RSN IE 出现连接故障。 Cisco 因此在 17.x 后的官方最佳实践中明确：停用 Adaptive，回归标准 Mixed Mode。

④ Catalyst 9800 推荐配置（GUI 路径 + CLI 片段）

GUI 路径：Configuration → Tags & Profiles → WLANs → 选中 WLAN → Security → Layer2

• Fast Transition Status：Enabled
• Over the DS：Enabled（适合大部分场景）
• Auth Key Management：同时勾选 802.1X + FT 802.1X（PSK 场景则同时勾 PSK + FT PSK）

等效 CLI 片段：

wlan W19L5000 21 W19L5000
  security ft
  security ft over-the-ds
  security wpa akm dot1x       ! 非 FT，老终端走这条
  security wpa akm ft dot1x    ! FT，新终端走这条
  ! 如需 WPA3，继续叠加：security wpa akm sae 与 security wpa akm ft sae

版本提示：示例基于 IOS-XE 17.18.x；不同版本下 CLI 顺序与子命令可能略有差异，请以设备 ? 上下文提示为准。

→ 接下来落到硬件层：给 AGV 选支持 802.11r 的网卡

给 AGV 选支持 802.11r 的网卡，看这张表

为 AGV 选合适的无线网卡芯片，是决定整条产线网络 SLA 的绝对基石。 到了 Wi-Fi 6 及更高世代，底层芯片对 IEEE 802.11r（Fast BSS Transition）的支持力度， 直接决定了 AGV 跨越 AP 时的交互时延与稳定性。

主流支持 802.11r 的工业级 Wi-Fi 6 / 6E / 7 芯片清单

下表覆盖适用于工业及 AGV 场景的主流芯片。除无线协议本身外，重点关注宽温支持与驱动生态。

架构侧实施避坑清单（Checklist）

硬件选型敲定后，必须在试产阶段验证下面三条软件栈链路，否则芯片的 802.11r 能力将一直处于"休眠"状态：

→ 至此五场景 + 三个深度问答全部讲完，进入 五场景全景对比 形成系统性判断

五场景全景对比

用一张表，看清五个场景在每个关键维度上的差异—— 从扫描到认证，从 ISE 依赖到最终断网时长，一目了然。

时延构成可视化对比

Glossary — 核心术语速查

本文涉及的所有关键术语，每条都有精准定义。建议收藏备查。