让 AGV 永不掉线

AGV 到底对网络要什么？

讨论任何"漫游优化"之前，我们必须先回答一个最基础的问题：AGV 的车载控制系统，对无线网络究竟有什么硬性要求？如果答不上来，所有优化都只是"凭感觉"。

1.1 第一性原理：先看 AGV 在网络上"说什么话"

一辆典型的 AGV，其无线流量主要来自三类应用：

真正决定整车队"生死"的，是 ①。AGV 一旦失去调度信令，就像一辆失去方向盘的车——出于安全设计，它会立即停车。这一点制造现场的工程师有切肤之痛：一次 MQTT 中断 1 秒，可能造成全场 200 辆 AGV 集体停摆 5–10 秒；恢复后还要等任务重新分配，物料断流可达数分钟。

1.2 MQTT 到底是什么？为什么 AGV 都爱它？

1.3 MQTT 对网络的"硬性指标"

很多人误以为 MQTT 是 UDP 的"轻量协议"，其实它跑在 TCP 上——有连接、有重传、有顺序保证。这就带来了三个"硬约束"：

请注意：这里最容易"杀死" AGV 的，不是带宽不足，而是连续几百毫秒的"完全静默"。带宽再大，只要中间断开 800 ms，MQTT 上层就会拉响警报。

1.4 把数字落到现场：一次漫游意味着什么？

1.5 互动 Lab：MQTT 为什么怕"认证空窗"？

道理讲清楚了，但只有动手拖滑块才能真正建立直觉。下面这个小实验把三个关键变量——ISE 响应延迟、漫游认证空窗、无线丢包率——开放给你调节，链路颜色与业务健康度会实时变化。

为什么 OKC 看起来"没生效"？

用户的配置看起来很合理：开启 OKC、802.11k、802.11v，没有开 802.11r。理由也很标准——"照顾不支持 11r 的老旧终端"。可现实却是：每次漫游 ISE 都看到一条完整认证记录。OKC 仿佛没生效。问题出在哪里？我们先把 OKC 是什么，讲清楚。

2.1 OKC 是什么？

2.2 OKC 的"生效前提"——三个常被忽略的条件

OKC 是 非 IEEE 标准的"事实标准"，由 Cisco/Aruba 等厂商各自实现。要让它真正工作，必须同时满足：

用户场景中"ISE 上有完整认证记录"——这是一个非常清晰的信号：OKC 没有真正发挥作用。最常见、也最需要优先验证的原因是条件 ② 没满足（PMKID absent）；但仍需通过空口抓包与 WLC trace 进一步区分以下三种 cache-miss 情形：

• PMKID Absent：终端 supplicant 根本没在 Reassoc 中携带 PMKID
• PMKID Mismatch：终端携带了 PMKID，但与 WLC 算出的不一致（常见于 WLC 端 SSID/AKM/Mobility Domain 不匹配，或终端用错 BSSID 哈希）
• WLC Cache Miss：PMKID 正确，但 WLC 端因 Mobility Group 跨边界、FlexConnect 配置、Site Tag 划分等原因没缓存到这个 PMK

2.3 当前漫游过程的时序解剖

来看一次"OKC 失效"状态下，AGV 漫游到底发生了什么——从决策、扫描，到完整 802.1X 认证，再到业务恢复：

2.4 为什么这条路径"必然出事"？

把上面那张图压缩成一句话：每一次漫游，AGV 都把自己的"生死"押在了 ISE 的响应时间上。而 ISE 在大型园区中常常需要查询会计数据库、CRL/OCSP、Active Directory……任何一环延迟，都会被忠实地传递到 AGV 的网卡上，最终表现为一次 MQTT 中断。

802.11k / v / r 与 Adaptive FT

"漫游慢"这件事，802.11 标准早就给出了药方。只是这三剂药——k、v、r——分工不同、作用不同，常常被混为一谈。我们用一个统一的类比把它们说清楚。

3.1 802.11k：邻居报告（Neighbor Report）

效果：5 GHz 全频段扫描可达 2 秒+；启用 11k 后可压缩到 30 ms——10–60 倍的提速，而且彻底回避了 DFS 信道被动扫描的耗时陷阱。

3.2 802.11v：BSS 过渡管理（BTM）

11v 解决了一个老顽疾——"粘性客户端"。许多终端会一直死磕原 AP 不肯走，哪怕信号已经差到无法承载业务。BTM 是 WLC 的"礼貌建议"机制；要让它对 AGV 这种顽固终端真正起作用，务必启用 Disassociation Imminent，否则会出现"开了 11v、AGV 还是粘性不走"的常见困惑。

3.3 802.11r：快速 BSS 切换（FT）—— 真正的"零等待"

3.4 用户的真正顾虑：“老终端不支持 11r 怎么办？”

这是当年 Cisco 决定不默认启用 11r 的根本原因——启用 11r 后，原本的 RSN AKM 会出现新的 AKM 套件（FT-802.1X）。某些老网卡识别到陌生 AKM 后会直接拒绝关联，整个 SSID "全军覆没"。

方案 A：标准 802.11r Mixed Mode（推荐）

在 C9800 上，FT 可以以 Mixed Mode 启用：WLAN 同时广播 AKM=802.1X 和 AKM=FT-802.1X，支持 11r 的终端走 FT，不支持的终端理论上回退到普通 802.1X。但"理论可回退"不等于"全部兼容"——某些老旧 supplicant 看到未知 AKM 仍可能异常，必须逐型号验证。

! C9800 配置片段 — 两种 AKM 配置变体，按目标 SSID 安全等级选其一

! ① WPA2-Enterprise + 11r Mixed Mode（当前主流过渡形态，AKM 1 + AKM 3）
wlan AGV-WLAN 10 AGV-SSID
 security wpa akm dot1x                ! WPA2-Enterprise（AKM 1）
 security wpa akm ft dot1x             ! FT over 802.1X（AKM 3）
 security ft
 security ft
 no shutdown

! ② WPA3-Enterprise + 11r（面向 6 GHz / Wi-Fi 6E/7，AKM 5 + AKM 13）
wlan AGV-WLAN-WPA3 11 AGV-SSID-WPA3
 security wpa akm dot1x-sha256         ! WPA3-Enterprise（AKM 5）
 security wpa akm ft dot1x-sha256      ! FT over 802.1X SHA-256（AKM 13）
 security ft
 security pmf mandatory                ! WPA3 强制 PMF
 no shutdown

方案 B：Adaptive 802.11r（曾经的妥协方案，今天不建议）

Cisco 早年和 Apple/Samsung 联合搞了 Adaptive FT：在 Beacon 的 RSN IE 中隐藏 FT AKM，仅通过 MDIE（Mobility Domain IE）做外部标记。iOS 10+ 和 Samsung S10+ 通过私有握手感知并启用 FT；老终端则完全察觉不到，依然走普通 802.1X。这看起来是完美解决方案。

3.5 三剂药一起吃，效果如何？

3.6 Cisco WLC 9800 的"自适应"机制

除了 Mixed Mode，C9800 还有几个常被忽略的"自适应"开关，配合 11r 一起使用效果最佳：

• FT Over-the-DS（ODS）—— 默认建议关闭：ODS 让终端把 FT Authentication Request 封装成 Action 帧，通过当前 AP 的有线侧（DS）透传给目标 AP，使认证阶段无需先切到目标信道。听起来美好，但 Cisco C9800 Best Practices 明确建议——"For best client interoperability, it's recommended to keep the 'over the DS' setting disabled"。原因是部分终端对 ODS 的实现不一致，开启后反而出兼容性问题。在 AGV 现场建议默认关闭；只有当 DFS 信道密集且现场 POC 验证所有 AGV 终端均兼容时，才考虑选择性启用。
• 11v BSS Transition with Disassoc Imminent：强制粘性终端按 WLC 指挥漫游，避免 AGV 在弱信号区域死撑。
• Aggressive Load Balancing：AGV 场景建议关闭——Cisco C9800 Best Practices 明确指出该特性 "might have negative impact on voice or interactive video traffic"，AGV 控制流属于交互式实时业务，应禁用以避免漫游受扰。
• Band Select：AGV 场景建议关闭——Cisco C9800 Best Practices 明确说明 "Do not use band select if you will deploy voice or video services (any interactive traffic), as it may impair roaming performance on some client types"。Band Select 通过延迟低优先级频段的 Probe Response 把客户端推向 5 GHz，但对漫游中的 AGV 是干扰源。

3.7 务实路径：能不能"先 OKC 止血，再 11r 收敛"？

有运维负责人问过一个非常合理的问题——11r Mixed Mode 涉及 WLC AKM 改造与全终端兼容性验证，周期长；如果 AGV 模组只是没在 Reassoc 中携带 PMKID，能不能先把它"配开"，让 OKC 真正生效？这样能不能阶段性达标？

答案是：可以——但必须先做严肃的可行性判断，不能盲目承诺周期。原因来自上一节揭示的协议事实：OKC 的 PMKID 不是从缓存"读"出来的，而是 supplicant 必须用 HMAC-SHA1-128 为从未握手过的目标 AP 主动哈希计算。这意味着——不是所有终端都能靠"打开一个配置开关"启用 OKC，关键看 supplicant 代码本身是否实现了这套预测逻辑。

A-1 三场景可行性判断

在排期前，请先对自己的 AGV 车队做下面的"分类登记"——三种场景下的 A-1 可行性差异极大：

OKC vs 11r：完整能力对比

AAA Cache：给 ISE 一个"喘息"的机会

即便 11r 把"漫游本身"压到了 10 ms，仍有一类场景会强制把请求送到 ISE——比如终端重启、PMK 老化、Session-Timeout 到期、跨 Mobility Group 漫游。这时 ISE 一旦抖动，AGV 还是会断。能不能让 WLC "短暂代替 ISE 做决定"？这就是 AAA Cache 的价值。

4.1 第一性原理：ISE 真正不可替代的是什么？

ISE 在 802.1X 流程中干了两件事：

1. 身份判定：你是不是合法证书？CN/SAN 是否匹配？吊销了吗？（一次性的“开门动作”）
2. 授权决策：你应该进哪个 VLAN？拿什么 dACL？SGT 多少？（基于策略的“分配动作”）

这两件事，对于"5 分钟前刚刚通过的同一台 AGV"，其实结果不会变。那为什么每次都要再问一次 ISE？因为传统设计把"判定权"完全外包了。AAA Cache 的思路是：WLC 本地缓存这个判定结果，在 ISE 不可达或慢响应时直接复用。

4.2 C9800 上的 AAA Cache 工作机制

4.3 一张图看懂 AAA Cache 的"挡箭"效果

4.4 配置要点（C9800，IOS-XE 17.18.1+）

下面给出与 IOS-XE 17.18.x 官方 Configuration Guide 一致的 Wireless AAA Authentication Survivability Cache 配置骨架。整套配置分 6 步，全部在 WLC 全局/server-group/wlan 层级，不要误用任何 Catalyst 交换机有线 IBNS 的 dot1x critical eapol / authentication critical recovery 指令——那些命令在 C9800 上会直接报 Invalid input detected。

! ========================================================
! Wireless AAA Authentication Survivability Cache —— C9800
! 参考：Cisco Catalyst 9800 17.18.x Config Guide
!       "Wireless AAA Authentication Survivability Cache"
! ========================================================

! 1) 配置 RADIUS server（指向 ISE PSN）
radius server ISE-PSN-1
 address ipv4 10.x.x.x auth-port 1812 acct-port 1813
 key <your-shared-secret>

! 2) 配置 AAA cache profile（"all" = 缓存全部 AVP）
aaa cache profile AGV-CACHE
 all

! 3) RADIUS server group：绑定 server + cache profile + 过期时间
aaa group server radius AGV-RADIUS
 server name ISE-PSN-1
 cache authentication profile AGV-CACHE
 cache authorization profile AGV-CACHE
 cache expiry 24                      ! 单位：小时；0 = 不过期
 !  ⚠ 注：一个 AAA group 只能绑一个 AAA cache profile

! 4) 配置 Local EAP Profile（用于 EAP-TLS 本地兜底）
eap profile AGV-EAP
 method tls
 pki-trustpoint AGV-WLC-TP            ! 必须同时含 WLC 服务器证书 + CA 链

! 5) WLAN：启用 local-auth，关联认证/授权列表
wlan AGV-WLAN 10 AGV-SSID
 local-auth AGV-EAP
 security dot1x authentication-list default
 security dot1x authorization-list default
 no shutdown

! 6) AAA Dead-Server Detection（让 WLC 快速判定 ISE 不可达，触发 survivability 命中）
radius-server dead-criteria time 5 tries 3
radius-server deadtime 5              ! 单位：分钟（对应 Cisco C9800 Best Practices 推荐值）

4.5 EAP-TLS 场景的隐藏前提：Local EAP Profile + Trustpoint

这是一个极易被忽略但非常关键的技术细节：对于 EAP-TLS 这种"安全 EAP 类型"，AAA Cache 不能像 PAP/CHAP 那样简单地"把 Access-Accept 复制一遍"。原因是——EAP-TLS 是双向证书认证（Mutual Authentication）的有状态握手，必须有一方真正具备处理 TLS 双向认证的能力。

因此，当 ISE 不可达、WLC 要用本地缓存放行 AGV 时，C9800 自己必须具备：

1. Local EAP Profile：声明本地能跑 EAP-TLS 方法
2. PKI Trustpoint（CA 证书链）：持有签发 AGV 客户端证书的 CA 链，能验证 AGV 上送的客户端证书
3. WLC 自身的 Identity Certificate（服务器证书）：这一条最容易被遗漏——EAP-TLS 是双向认证，AGV 在 TLS ClientHello 之后会收到 WLC 的 ServerHello + Certificate，必须能用本机信任的 CA 链验证。如果 WLC 上只配了验证 client 用的 CA、没有自己的服务器证书，AGV 的 wpa_supplicant 会在 ServerHello 阶段直接抛 Unknown CA 或 Bad Certificate，单方面撕毁 TLS 隧道

! 此处只展示 §4.4 中第 4 步绑定的 Trustpoint 与 EAP Profile 细节，
! 完整 WLAN 配置请回到 §4.4。

! 1) Trustpoint：装载 WLC 自身的服务器证书 + 信任的 CA 链
crypto pki trustpoint AGV-WLC-TP
 enrollment terminal
 revocation-check none
 ! 该 Trustpoint 必须同时包含：
 !   (a) WLC 自身的 Identity Certificate（私钥 + 服务器证书）
 !   (b) 能验证 AGV 客户端证书的 Root/Sub CA 链
 ! AGV 端的 supplicant 必须信任 (a) 所在 CA

! 2) Local EAP Profile（与 §4.4 步骤 4 一致，方法为 TLS）
eap profile AGV-EAP
 method tls
 pki-trustpoint AGV-WLC-TP

4.6 AAA Cache 与 11r 的协同

这两个特性互补，不冲突：

Cisco URWB：当 Wi-Fi 漫游不够好时

Wi-Fi 标准的漫游优化做到极致，仍然是"断开旧 AP → 协商新 AP → 重新建立加密链路"的逻辑——这是 802.11 协议骨子里的"Break-Before-Make"，无论 11r/11k/11v 怎么优化，本质上无法做到"完全零中断"。对于高速 AGV、AMR、自动驾驶矿车、列车 CBTC 这类应用，毫秒级中断也不可接受。这是 Cisco URWB 的用武之地。

5.1 URWB 是什么？

5.2 URWB 与 Wi-Fi 的"同"与"异"

5.3 URWB 的四大核心技术

① Underlay：MPLS over Wireless

URWB 网络底层是一张 MPLS（多协议标签交换）网络，运行在 AP 间的无线/有线链路上。每个 AP 既是无线基础设施，也是 MPLS LSR（标签交换路由器）。客户端的报文进入 URWB 网络的瞬间，被打上 MPLS 标签，在 AP 之间按标签转发，到达出口 AP 再剥离。

这意味着什么？对客户端而言，整个 URWB 网络呈现为一个巨大的 L2 交换机——它走过 100 个 AP，IP 地址、ARP 表、TCP/MQTT 会话全部不变。

② Overlay：L2 透传隧道

在 MPLS Underlay 之上，URWB 建立 VPLS/L2 隧道（Overlay），把每一个客户端的数据帧端到端透传。无论 AGV 漫游到哪一个 AP，它的 L2 帧总是被"装进同一根管道"送回汇聚点——VLAN、ARP、广播域完全保留。

③ Make-Before-Break（MBB）：先建后断

这是 URWB 最核心的差异化能力。客户端在切换时：

④ MPO（Multipath Operation）：多径冗余

对于关键任务场景（如有轨车辆、自动化采矿），URWB 还可以让客户端同时连接多个 AP 并行收发同一份数据——这就是 MPO。即便某一条无线链路瞬时遭遇干扰或 RF 阴影，另一条仍能保证报文送达。MPO 把"可靠性"从概率上升为结构性保证。

5.4 URWB 在 AGV 场景下的定位

URWB 不是 Wi-Fi 的替代品，而是对"标准 Wi-Fi 力所不及的场景"的补充。更成熟的架构思维是分层承载——根据业务的 SLA 等级，让不同业务跑在最适合它的无线技术上。

它的部署成本（专用 AP、专用控制器）显著高于普通 Wi-Fi，但带来的"零中断"价值，在以下场景无可替代：

互动演示：Make-Before-Break 的真实体感

道理讲得再多，不如自己动手拖一下。下面是一个 URWB MBB 漫游的交互示意图——你可以用鼠标或手指拖动那辆 AGV 从 A 端走到 B 端，观察它如何在 Mobility Base A 与 Base B 之间无缝切换。重点关注过渡区域：在那一刻，两条链路同时存在，这就是 Make-Before-Break。

6.1 你刚刚看到了什么？

当 AGV 进入 Handoff 区域（约 400 像素附近），两条链路同时存在——这就是 MBB 的精髓。底部的"MPLS Overlay"标签提示你：尽管无线链路在切换，上层 L2 隧道始终保持，客户端的 IP、ARP、TCP 会话完全不变。

6.2 同样的动作，传统 Wi-Fi 会怎么演？

ISE 分角色部署：把 MNT 从 PSN 中"独立出去"

Ch5 / Ch6 我们展示了 URWB 这条"换维打击"——但它是另辟蹊径，不是釜底抽薪。无论你是否上 URWB，ISE 自身仍是 AGV 准入路径上的关键单点。前面我们一直在说"让 AGV 不要太依赖 ISE"——本章我们直面 ISE 本身：它为什么会高延迟？根因找到了，整个系统才稳。这是回归本源的一章，也是与 Ch4 AAA Cache 形成"标本兼治"闭环的最后一块拼图。

7.1 ISE 的三种"人格"：PAN、PSN、MNT

很多人把 ISE 当成一个黑盒——"一个认证服务器"。其实 ISE 内部由三种"角色（Persona）"组成，可以合一也可以分开：

7.2 根因剖析：MNT 是怎么把 PSN "拖下水"的？

当 PSN 和 MNT 合并部署（典型小型部署）时，一台 ISE 节点同时承担：

1. 实时认证：每条认证必须 100 ms 内响应（PSN 工作）
2. 海量记账写入：每分钟数千条 Accounting Start/Update/Stop（MNT 工作）
3. SQL 查询：管理员/审计员的 Live Logs、报表查询（MNT 工作）

问题出在 ②③——MNT 的数据库写入和复杂 SQL 查询，会推高磁盘 I/O Wait 与 CPU 占用。当车间里 200 辆 AGV 同时漫游 + 班次报表查询同时发起，MNT 的数据库锁与 I/O Wait 拖累整台 ISE 的 CPU——PSN 排队，RADIUS 响应延迟，AGV 被"卡"在认证里。

7.3 解决方案：MNT 与 PSN 物理分离

7.4 分离部署的工程参考

Cisco 官方建议中型以上部署使用 "分布式部署（Distributed Deployment）"：

7.5 配套优化措施

• WLC 端配置 PSN 负载均衡：使用 radius-server load-balance method least-outstanding，让 RADIUS 请求自动分流到多台 PSN，避免单点过载。
• 关闭不必要的 Accounting Update：将 Interim Update Interval 从默认 5 分钟调整到 30 分钟或更长，减少 MNT 写入压力。
• 限制 Live Logs 保留时长：MNT 数据库的 Live Logs 保留窗口越长，索引体积越大、查询越慢。请按合规与审计需求设到能满足的最小值（典型生产建议 7～14 天），更长的历史归档到外部 SIEM。
• 启用 ISE Profile Service 单独 Persona：如有大量 IoT 终端，profiling 服务也建议独立到专门的 PSN。
• 磁盘选 SSD/NVMe：MNT 节点对随机写入敏感，传统机械盘是性能杀手。

7.6 从 WLC / NAD 侧减少"日志洪水"（Turn Down the Firehose）

Cisco 在 ISE 最佳实践中反复强调一句话——"Turn Down the Firehose"：认证系统不该被错误的定时器、过度的重试、过量的 Interim Accounting 与无意义的探针淹没。对 AGV 场景而言，必须从无线控制器与 NAD（Network Access Device）侧一起治理。

7.7 ISE 治理三阶段路线：止血 → 重构 → 治理

从制造业运维视角看，AGV 停摆问题不能靠一个配置项修复。我们建议将 ISE 侧动作切成三层：

决策建议与最佳实践

到这里，我们已经把"为什么 AGV 会掉线"、"OKC 怎么先止血"、"802.11r 怎么收敛"、"AAA Cache 怎么解耦"、"URWB 何时上"、"ISE 怎么分"全部讲完了。现在把决策权交还给你——你需要在"投入成本"与"业务收益"之间做选择。下面是四档路径，按从轻到重排列：

8.1 四档决策路径

8.2 不论选哪条路径，Cisco 建议的"无悔动作"

以下几条是"做了不亏，不做必坑"的最佳实践，建议立刻执行：

8.3 可验证的成功指标（SLA）

8.4 实施路线图建议（90 天）

回到最开始的问题

我们出发时，问题是这样的：一次 ISE 高延迟，让大量 AGV 停摆。

经过八章拆解，我们得到了一组结构性的答案：

1. AGV 的命门不是带宽，是断网容忍——MQTT 的 KeepAlive 决定了你只有几百毫秒；
2. OKC 看似配上了，但终端可能没声明 PMKID，或携带的 PMKID 与 WLC 缓存不匹配——这是当前根因；
3. 真正的解药是 802.11r Mixed Mode，配合 11k/11v，把漫游压到 10 ms；
4. 对 ISE 的耦合用 AAA Survivability Cache 解开——让 ISE 抖动不再传染 AGV；
5. ISE 自身的高延迟，来自 MNT 拖累 PSN——分角色部署是治本之策；
6. 当 Wi-Fi 协议本身的天花板限制了你，Cisco URWB 用 MBB + MPO + 工业级 Overlay 做到了"业务无感的毫秒级切换"；
7. 四档路径（A-1 即时止血 → A-2 标准化收敛 → B 中度加固 → C 工业级跨越），可以按业务关键度逐步落地。

制造业的网络运维，不是"没出事就是好"，而是"出事时仍然不停摆"。从一次漫游优化开始，你正在建设的，是一张对业务真正可信的网络。

附录 A：工业无线模组 OKC / 11r 经验性支持矩阵

本附录回答一个常见的现场问题："AGV 上装的是工业级模组，它到底支持不支持 OKC？"

A.1 先承认一个事实：没有"权威清单"

市面上不存在一份由 Cisco 或 IEEE 维护的、可直接查阅的"OKC 支持网卡清单"。原因有三：

1. OKC 不是 IEEE 标准——它是 Cisco/Aruba 当年的事实标准，各家厂商各自实现；同一颗芯片在不同驱动 / 不同固件版本下行为可能完全不同。
2. 工业模组厂商的数据手册通常只写"Supports WPA2-Enterprise / 802.11r"，对 OKC 是否启用、是否默认开启基本不提。
3. OKC 是否生效高度依赖 supplicant 配置——例如 Linux wpa_supplicant 必须显式设置 proactive_key_caching=1，不是网卡硬件能力问题。

A.2 经验性参考矩阵（按芯片家族与驱动栈分类）

下表汇总在 AGV / AMR 现场可见的常见模组类别。表中"通常表现"基于公开资料与典型部署经验，不能替代您在自己环境中的实际验证。

A.3 给采购与运维的两条务实建议

A.4 wpa_supplicant 的关键配置示例（Linux AGV 控制器）

下面给出两个分场景示例——分别对应"WPA2-Enterprise 当前过渡期"与"WPA3-Enterprise 终态"。请勿混用，PMF 策略必须与 WLAN 侧一致。

示例 ①：WPA2-Enterprise + 11r 过渡期（当前主流 AGV 现网）

# /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1

# === PMK 缓存与机会式漫游 ===
okc=1                          # 启用 Opportunistic Key Caching
proactive_key_caching=1        # 等同于 okc=1（部分发行版用此名）
ft_eap_pmksa_caching=1         # 11r FT-EAP 场景下复用 PMKSA

network={
    ssid="AGV-SSID"
    key_mgmt=FT-EAP WPA-EAP        # 同时声明 FT 与普通 EAP，AKM 协商
    eap=TLS
    identity="AGV-001"
    ca_cert="/etc/agv/ca.pem"
    client_cert="/etc/agv/client.pem"
    private_key="/etc/agv/client.key"
    private_key_passwd="********"
    # PMF 策略必须与 WLAN 侧匹配
    # WPA2 SSID 通常为 PMF Optional：
    ieee80211w=1
    bgscan="simple:30:-65:300"
}

示例 ②：WPA3-Enterprise + 11r 终态（面向 6 GHz / Wi-Fi 6E/7）

# /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
update_config=1

okc=1
proactive_key_caching=1
ft_eap_pmksa_caching=1

network={
    ssid="AGV-SSID-WPA3"
    # WPA3-Enterprise + FT 的 SHA-256 AKM
    key_mgmt=FT-EAP-SHA256 WPA-EAP-SHA256
    eap=TLS
    identity="AGV-001"
    ca_cert="/etc/agv/ca.pem"
    client_cert="/etc/agv/client.pem"
    private_key="/etc/agv/client.key"
    private_key_passwd="********"
    # WPA3 / 6 GHz 强制 PMF Required
    ieee80211w=2
    bgscan="simple:30:-65:300"
}

附录 B：抓包验证 PMKID 的完整方法

本附录回答另一个常见的现场问题："我配了 OKC / 11r，怎么确认它真的生效了？"唯一可信的方法是抓 802.11 管理帧的原始字节流，查看 Reassociation Request 帧里的 RSN IE 是否含 PMKID。

B.1 整体思路：两条主流路径

B.2 方案 A：在 C9800 上配置 Sniffer Mode AP

步骤 1：选一个 AP 转为 Sniffer 模式

GUI 路径：Configuration → Wireless → Access Points → 选定 AP → Mode = Sniffer，或使用 CLI（下面命令为示意，具体语法以您所部署的 C9800 IOS-XE 版本配置指南为准）：

configure terminal
ap name AP-Sniffer mode sniffer
ap name AP-Sniffer dot11 5ghz shutdown        ! 退出业务模式
ap name AP-Sniffer dot11 5ghz channel 36      ! 锁到目标信道
ap name AP-Sniffer no dot11 5ghz shutdown
ap name AP-Sniffer sniff 5ghz 36 <WIRESHARK_PC_IP>

AP 会把抓到的 802.11 帧用 PEEKREMOTE / AiroPeek 封装，发送到指定主机的 UDP 端口。常见接收端口为 UDP 5000（AireOS / 部分 IOS-XE 版本）或 5555（其他场景）——实际端口随 AP 型号 / 软件版本 / 平台而异，请以当前 C9800 release guide 和 AP Sniffer 文档为准。
建议做法：先在 Wireshark 端用 udp and host <AP-IP> 过滤捕获，看实际命中的端口号，再 Decode As PEEKREMOTE。

步骤 2：在 PC 端（Wireshark）配置接收

步骤 3：在 Wireshark 中验证 PMKID

应用以下显示过滤器（请把 aa:bb:cc:dd:ee:ff 替换为 AGV 网卡 MAC）：

# 只看目标终端发出的 Reassociation Request（subtype 0x02）
wlan.fc.type_subtype == 0x02 && wlan.sa == aa:bb:cc:dd:ee:ff

# 进一步只看声明了 PMKID 的帧
# 注：字段名因 Wireshark 版本而异；若下述不工作，可尝试 wlan.rsn.ie.pmkid.count（点号形式）
wlan.rsn.ie.pmkid_count >= 1

在帧详情中展开：

IEEE 802.11 Reassociation Request
└─ Tagged parameters
   └─ Tag: RSN Information
      └─ PMKID Count: 1            ← ★ 必须 ≥ 1
      └─ PMKID List
         └─ PMKID: 5a3e2f...       ← ★ 看到这一行 = OKC 真正发挥作用

备选：用 C9800 的 Radioactive Trace 做 WLC 视角诊断

如果暂时无法部署 Sniffer AP，可用 RA Trace 从 WLC 视角验证：

! 启用对该客户端的 Radioactive Trace
debug wireless mac aa.bb.cc.dd.ee.ff monitor-time 600

! 让 AGV 漫游……完成后导出

show logging profile wireless filter mac aa.bb.cc.dd.ee.ff to-file flash:agv-trace.log

! 关闭
no debug wireless mac aa.bb.cc.dd.ee.ff

在生成的 trace 中搜索关键字：PMKID、PMK Cache hit、PMK Cache miss、FT，即可判断 WLC 侧是否命中缓存。

B.3 方案 B：MacBook 直接 OTA 抓包（最便携）

macOS 内置了原生的 802.11 监控模式，无需任何第三方驱动或硬件。

方法 B-1：图形界面（推荐给一线工程师）

方法 B-2：命令行 airport（脚本化场景）

# 锁定 5 GHz 36 信道开始抓包
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport en1 sniff 36

# Ctrl+C 停止后，文件输出到 /tmp/airportSniffXXX.cap

注意：en1 是 Wi-Fi 接口名，可用 networksetup -listallhardwareports 确认。

方法 B-3：Wireshark macOS 监控模式

Wireshark → 选 Wi-Fi 接口 → Capture Options → 勾选 "Monitor Mode" → 选信道 → 开始

B.4 Wireshark 验证过滤器速查表

B.5 一张表完成"判读"

把上面的过滤器结果对照下表，即可一句话定性当前漫游状态：

B.6 推荐的现场诊断流程（30 分钟可完成）

术语表（Glossary）

AGV / AMR

自动导引车 / 自主移动机器人。制造业、物流业用于自动搬运的无人载具。

MQTT

轻量级发布/订阅消息协议，运行在 TCP 之上。AGV 主要的调度信令协议。

QoS（MQTT）

消息服务质量等级：QoS 0（至多一次）、QoS 1（至少一次）、QoS 2（恰好一次）。

LWT（Last Will & Testament）

MQTT 客户端预先注册的"遗嘱消息"，在异常断连时由 Broker 代为发布。

KeepAlive

MQTT 客户端的心跳间隔（典型 30–60 秒）；超过 1.5× 该间隔无消息或心跳，Broker 判定会话死亡。它检测的是 TCP/MQTT 会话级断连，不应被误用作 AGV 业务停摆计时器——后者由 AGV 应用层心跳与安全 watchdog 决定。

802.1X

IEEE 端口接入认证标准，配合 EAP 框架实现网络准入控制。

EAP-TLS

基于 TLS 证书的 EAP 方法，客户端与服务器双向证书认证，AGV 场景的事实标准。

RADIUS

认证、授权、计费协议；WLC 与 ISE 之间承载 EAP 的传输协议。

PMK / PMKID

成对主密钥 / 其标识符；用于客户端与 AP 间派生加密会话密钥。

4-Way Handshake

WPA2/WPA3 中客户端与 AP 协商 PTK 的 4 条消息交换，是漫游延迟的来源之一。

OKC

Opportunistic Key Caching，机会式密钥缓存。在 Cisco Central Switching 架构下，PMK 集中驻留在 WLC 内存中（不下发到 AP）；终端漫游时由 supplicant 主动为目标 AP 计算 PMKID 并上送 Reassoc 帧，WLC 命中后代终端完成 4-Way HS。非 IEEE 标准。

802.11r / FT

Fast BSS Transition。IEEE 标准的快速漫游协议，把密钥确认嵌入 FT Auth + Reassoc 两次往返（共 4 帧管理报文），不再需要独立的 EAPOL 4-Way Handshake，达成 < 50 ms 漫游（最佳 < 10 ms）。

802.11k

IEEE Radio Resource Measurement 标准，提供 Neighbor Report，让客户端只扫描邻居信道。

802.11v / BTM

IEEE BSS Transition Management，AP 主动向客户端建议漫游目标。本质是 advisory 协议——客户端可回复 Reject 拒绝；只有带 Disassociation Imminent 标志的 BTM Request 才具实质强制力。

Adaptive FT

Cisco + Apple/Samsung 的 11r 兼容机制；隐藏 FT AKM。不支持 WPA3，当前已不推荐。

MDIE / MDID

Mobility Domain Information Element / ID；用于标识同一 FT 移动域，仅同域 AP 间可 FT 漫游。

DFS

Dynamic Frequency Selection，雷达共享信道；规定客户端只能被动扫描，单信道 ≥102 ms。

AAA Cache

C9800 在本地缓存 ISE 授权结果的能力，其在无线场景的完整名称为 AAA Authentication Survivability Cache for Wireless。关键词是 Survivability（韧性）——它不是常态绕过 ISE 的捷径，而是在 AAA 服务器不可达 / 响应超时 / 被标记 dead 时，为已认证终端延续准入。从 IOS-XE 17.18.1 起支持，17.15.x 及更早版本不具备该能力。

WFA OCE（Optimized Connectivity Experience）

Wi-Fi Alliance 进阶认证项目，将 802.11r FT 作为强制项。注意 OCE 与 MBO 的边界：MBO 强制 802.11k + 802.11v，不强制 802.11r；OCE 才把 802.11r 列为强制项。

WFA MBO（Multi-Band Operation / Agile Multiband）

Wi-Fi Alliance 多频段协同认证，强制 802.11k（邻居报告）+ 802.11v（BTM）；不强制 802.11r。

Critical VLAN / AAA-Failure Policy（C9800）

C9800 在 RADIUS 服务器不可达且 AAA Cache 未命中时的兜底策略，配置在 Wireless Policy Profile 内（不是有线交换机的 dot1x critical eapol）。具体语法以 IOS-XE 17.18.x Policy Profile 配置指南为准。

ISE PAN / PSN / MNT

Cisco ISE 的三种角色：策略管理、策略服务、监控与日志。生产环境推荐物理分离。

URWB

Cisco Ultra-Reliable Wireless Backhaul。源自 Fluidmesh，集成于 IW 系列与 Catalyst IW AP，提供工业级零中断无线。

MBB（Make-Before-Break）

URWB 漫游模型：先建立新链路、再断开旧链路，实现零丢包切换。

MPO（Multipath Operation）

URWB 的多径冗余技术：客户端同时连接多个 AP 并行收发，提升可靠性。

MPLS Underlay / Overlay

URWB 底层使用 MPLS 在 AP 间转发数据，并在其上构建 L2 隧道（Overlay）以实现 L2 透传。

Mobility Tunnel

C9800 间用于跨 WLC 漫游的隧道，承载 PMK 同步与客户端上下文。

FlexConnect

C9800 的本地交换模式，AP 在 WLC 不可达时仍可本地转发数据，提升故障域韧性。

IOS-XE 17.15.5 / 17.18.3

Cisco TAC 当前推荐的 C9800 控制器软件版本（参考 Doc-ID 214749）。其中 17.18.1 起引入 AAA Authentication Survivability Cache for Wireless 特性；17.18.3 是 17.18 训练线的当前 TAC 推荐 GA。

Local EAP Profile

C9800 上声明的本地 EAP 处理能力（如 EAP-TLS / PEAP 方法），使 WLC 在 ISE 不可达时仍能独立完成 EAP 协议交互。

PKI Trustpoint

Cisco 设备上的证书信任锚配置实体，承载一对设备证书 + 信任的 CA 链。C9800 做 Local EAP 时需绑定与 ISE 同信任域的 Trustpoint。

Firehose（日志洪水）

Cisco ISE 最佳实践术语，特指被过量 Accounting、错误重试、健康探针淹没的认证系统流量；治理目标是"Turn Down the Firehose"。

Calling-Station-ID

RADIUS 标准属性（Attribute 31），承载终端 MAC 地址；常作为 RADIUS 负载均衡的粘滞键，确保同一会话的所有 EAP 报文落到同一 PSN。

Interim Accounting

RADIUS Accounting 在会话生命周期中周期性发出的中间更新报文；过短的 Interim 间隔会导致 MNT 写入压力骤增，是常见的"日志洪水"源头。

Deadtime

RADIUS Server 被标记为 "DEAD" 后，WLC/NAD 在该时间窗口内不再向其发送请求；Cisco C9800 Best Practices 推荐 5 分钟（radius-server deadtime 5），避免对异常 PSN 反复重试造成级联延迟。

Logging Suppression

ISE 的重复事件抑制机制：对相同终端在短时间内重复出现的失败事件做聚合写入，避免 MNT 数据库被瞬时风暴淹没。