什么是 HNDL（Harvest Now, Decrypt Later）攻击？

攻击者在今天大规模采集并存储加密流量（尤其是密钥协商阶段的报文），不尝试即时破解，而是等到未来具备密码分析能力的量子计算机（CRQC）可用时再统一解密。因此风险在数据发出的那一刻就已经产生，未来的补救对过去的数据完全无效。

量子计算机会让 AES-256 失效吗？

不会。对称密码的密钥没有可被数学利用的代数结构，量子计算机只能穷举，而 Grover 算法仅带来平方根级加速（2^256 降至 2^128），依然不可行。真正被击破的是非对称密钥交换与数字签名（RSA、ECDH、ECDSA），因此 PQC 改造的战场只在握手阶段。

为什么要用混合密钥交换而不是直接切换到纯 PQC？

两个原因：一是 PQC 算法虽被认为可靠，但软件实现与协议较新，混合方案让传统密钥交换提供 fallback 保护；二是 PQC 算法的 FIPS 认证平均需要两年以上，混合方案用已认证的传统算法建立初始密钥，可让合规与量子安全同时成立。

CNSA 2.0 对网络设备的时间表是什么？

PQC 固件/软件镜像签名与验签的建议采纳日期为 CY 2025；网络设备的建议采纳日期为 CY 2026；两者的强制采纳日期均为 CY 2030。NSA 表示更希望国家安全系统最早在 2027 年即获得保护。

如何判断一台设备是否真正支持全栈 PQC？

问三个问题：一、启动链用什么算法验签（应为 LMS 与 ML-DSA-87）；二、MACsec 的密钥从哪来（应为 EAP-TLS with ML-KEM，而非手工 PSK）；三、SSH 与管理面用什么密钥交换算法（应包含 mlkem 混合 KEX）。任何一项答不出，即为半栈。

如何验证一条 IPsec 隧道确实已经量子安全？

执行 show crypto ikev2 sa detailed，检查输出中的 PQC Key Exchange 字段是否显示 ML-KEM-768 或 ML-KEM-1024。隧道状态为 READY 并不构成量子安全证明，因为在 optional 模式下降级协商同样显示 READY。

量子风暴前夜：从第一性原理读懂 PQC、Cisco Trustworthy 与 8000 系列 Secure Routers

序章 · Prologue

一场没有警报响起的“抢劫”

我们先不谈技术。请想象一个场景。

某个周二凌晨 2 点，一家跨国企业的分支机构与总部之间，有一条平静运行了三年的 IPsec VPN 隧道。财务数据、并购意向书、员工身份信息、工控系统指令，都在这条隧道里流动。它使用 AES-256 加密，按今天的任何审计标准，这条隧道都是“合规且安全”的。

这一夜，某个国家级攻击组织在跨境骨干网的一个中转节点上， 没有破解任何东西——他们只是把流量原封不动地复制了一份，连同隧道建立时那几十毫秒的密钥协商报文，一起写进了硬盘，然后离开。

IDS 没有告警。防火墙日志干净。SIEM 里风平浪静。审计报告依然是绿色的。因为从纯技术意义上说，什么都没发生。

真正的问题是：这份硬盘，会在攻击者的仓库里安静地躺上 5 年、8 年，直到某一天，第一台CRQC 上线。那一刻，攻击者只需要几分钟，就能把当年那几十毫秒的密钥协商报文“反推”出会话密钥，然后把三年前的整条隧道，从头到尾解密一遍。

这就是 Cisco 白皮书《Cryptography in a Post-Quantum World》开篇就点明的核心威胁模型： “Harvest now, decrypt later (HNDL) attacks are happening today!” —— 注意时态：不是将会发生，而是正在发生（引自 BRKXAR-2027，Slide 34「HNDL Attack, CNSA 2.0 and Timelines」）。

这篇长文要回答的三个问题

基于 Cisco 官方的四份技术资料（BRKXAR-2027 技术分会材料、后量子密码白皮书、 Trustworthy Technologies 数据手册、8100/8200/8300 系列 Cheat Sheet），我们将沿着一条严格递进的逻辑链，回答三个层层嵌套的问题：

问题一 · 风险

PQC 时代的风险和挑战究竟是什么？为什么“等标准成熟再说”是错误答案？ Cisco 8000 系列具体是怎么应对的？

问题二 · 信任

什么是 Cisco Trustworthy？为什么在讨论加密之前，必须先讨论“这台设备本身值不值得信”？ Cisco 用什么机制保障它？

问题三 · 创新

抛开营销话术，8000 系列相比上一代 ISR1K / Catalyst 8000 究竟有哪些结构性创新？性能提升从物理上来自哪里？

关于本文的方法论

第一性原理意味着：我们不接受“因为 NIST 说了所以要用 ML-KEM”这种论证。我们要追问到“加密的安全性本质上建立在什么假设之上”，再看量子计算破坏了哪一条假设。

苏格拉底提问法意味着：每一小节都以一个问题开场。我不会直接给你答案，而是先让你意识到你原本以为理所当然的某件事，其实并不理所当然。

序章金句

加密从来不保证“永不被破解”，它只保证“在数据失去价值之前不被破解”。量子计算做的事，是把这个时间承诺一笔撕毁。

第一章 · Chapter 01

量子风暴：我们赖以生存的数学假设，正在被拆掉一根承重柱

本章要建立的认知：量子威胁不是“加密全废”，而是精准打击了整个安全体系中一个极小但极关键的环节。理解了这一点，你才能理解为什么 Cisco 的方案长成那个样子。

1.1 第一问：我们今天的“安全”，究竟建立在什么之上？

Socratic Question 01

当你说“这条链路是安全的”，你到底在断言什么？是断言“无法被破解”，还是断言了某种别的东西？

绝大多数人会脱口而出：“安全 = 破解不了。” 这是错的。从第一性原理出发，现代密码学从未承诺过“破解不了”。

第一性原理拆解：安全 = 经济学，而非物理学

任何加密算法在数学上都是可破解的——你只要有足够时间穷举所有密钥，一定能打开。所以密码学真正的命题不是“能不能破”，而是：

破解所需的计算成本，是否远大于攻击者能够承受的成本？

Cisco 白皮书中说 RSA-2048 “is considered invulnerable against brute force attacks using today's classical computers”—— 请注意这句话里的三个限定词：considered（被认为）、brute force（穷举）、today's classical computers（今天的经典计算机）。这不是一个数学定理，这是一个关于当前算力水平的工程判断。

精准定义

公钥密码（Public-Key Cryptography）

一类使用成对但不相同的密钥的算法：公钥可以公开发布用于加密或验签，私钥必须保密用于解密或签名。其安全性依赖于某个“正向容易、反向极难”的数学难题—— RSA 依赖“大整数分解”，ECDH/ECDSA 依赖“椭圆曲线离散对数”。

精妙类比

把两杯水倒在一起

把一杯红墨水和一杯清水混在一起（正向）：一秒钟就能完成。但要把混合液重新分离成原来的一杯红一杯清（反向）：几乎不可能。公钥密码就是在数学世界里造了这样一个“混合过程”—— 乘两个大素数很容易，把结果拆回两个素数极难。 整个互联网的信任，就架在这种“不对称的难度”之上。

1.2 第二问：量子计算到底改变了什么？

Socratic Question 02

如果量子计算机只是“更快的计算机”，那我们把密钥长度从 2048 位加到 4096 位不就行了吗？为什么这条路走不通？

这是最常见、也最危险的误解。量子计算机不是“更快”，它是“换了一种解题方式”。

第一性原理拆解：从“逐条试”到“同时试”

Cisco 白皮书对此的描述极为精炼：经典计算机的比特（bit）只能表示 0 或 1；量子计算机的量子比特（qubit）是亚原子粒子，可以同时是 0 和 1（“can be both 0 and 1 simultaneously”），因而“enabling them to process an incredible amount of information at once”。

关键结论：对于“大整数分解”和“离散对数”这两类问题，量子算法把复杂度从 指数级降到了多项式级。这意味着增加密钥长度带来的防护提升，从指数级退化为多项式级—— 想靠加长密钥把量子破解成本重新推回「不可行」区间，所需的密钥长度会膨胀到 工程上无法承受（密钥体积、握手时延、证书大小同时爆炸）。 不是没算完，是这条路在算术上就走不通。

所以白皮书给出的判断是残酷的： “a cryptanalytically relevant quantum computer (CRQC), when it becomes viable, could crack RSA-2048 in a matter of minutes.”

精准定义

CRQC（Cryptanalytically Relevant Quantum Computer）

“具备密码分析相关能力的量子计算机”。它不是“任何量子计算机”，而是特指规模与纠错能力已足以破解现行公钥密码体系的那一类。 Cisco 明确指出这样的机器今天并不存在（“does not exist and may still be years away”），而它出现的那一天被称为 Q-Day。

术语提示：白皮书写作 Cryptanalytically Relevant（与 NSA 用法一致）， BRKXAR-2027 Slide 34 写作 Cryptographically Relevant。两者指同一概念，业界文献中两种拼法并存。

精妙类比

迷宫里的“分身术”

经典计算机走迷宫：一条路走到底，撞墙返回，换下一条。哪怕它跑得再快，也是一次一条。量子计算机走迷宫：它同时铺满所有岔路，让所有路径一起向前推进，最后让“错误路径”相互抵消、“正确路径”相互增强。

把迷宫做大一倍，第一种方法要多花一倍时间；第二种方法只多花很少的一点时间。 这就是“加长密钥无效”的根本原因。

但请记住这个类比的边界：这套“分身术”只对有隐藏周期结构的迷宫有效（分解、离散对数正是这类）。对一个毫无结构的随机迷宫，量子计算机也只能一条条试 ——这正是下一节 AES-256 依然安全的原因。

1.3 第三问：那我们所有的加密都完蛋了吗？

Socratic Question 03

既然量子计算机这么强，AES-256 是不是也一起废了？如果不是——为什么？这两者的区别在哪里？

这个问题是整篇文章的逻辑枢纽。答案是：不，AES-256 依然安全。 而理解“为什么它安全、而 RSA 不安全”，你就掌握了 PQC 全部方案设计的底层动机。

第一性原理拆解：结构性弱点 vs 无结构强度

Cisco 白皮书的原话是： “Symmetric cryptography is quantum safe if the keys used are of sufficient size and quality (such as with AES-256). Unfortunately, asymmetric cryptography is used to establish these keys and quantum computers are well-suited to breaking asymmetric key pairs.”

为什么会有这种差别？因为：

非对称密码有“数学结构”。公钥和私钥之间存在一个精确的数学关系（比如 n = p×q）。有结构，就有“捷径”可以被量子算法利用。它不是被穷举打败的，是被“抄近路”打败的。
对称密码没有结构可言。AES 密钥就是一串 256 位的随机数，与密文之间没有任何可被数学利用的代数关系。量子计算机对它只能穷举，而量子穷举（Grover 算法）只能带来平方根级别的加速—— 把 2²⁵⁶ 降到 2¹²⁸，而 2¹²⁸ 依然是宇宙尺度上不可完成的任务。

推论（这是本文最重要的一步推理）： 既然数据本体由 AES-256 保护、而 AES-256 是量子安全的，那么攻击者唯一的入口，就是密钥是怎么被送到对方手上的那个瞬间。

BRKXAR-2027 用了连续两页幻灯片来讲这一件事（Slide 35「Key Exchange phase is Quantum-vulnerable」、 Slide 36「HNDL attack」）。其结论用一张图就能讲清：

请务必记住这张图的结论：整个量子安全工程的战场， 不在数据平面，而在控制平面的那几十毫秒。这解释了为什么后面 Cisco 的方案里，数据面依然是 AES-GCM-256（“Data Plane uses the same AES-GCM-256 cipher”，BRKXAR-2027 Slide 48）， 只改密钥协商。这是一个极其精准、极其克制的工程决策。

1.4 第四问：既然 Q-Day 还要等好几年，为什么现在就必须动手？

Socratic Question 04

如果一件事要 8 年后才发生，理性的做法难道不是“等标准更成熟、产品更便宜时再上”？在什么条件下，这个“理性”判断会变成灾难性错误？

第一性原理拆解：三个时间变量的赛跑

Cisco 白皮书把 HNDL 定义为“an additional and more immediate concern”—— 一个额外的、更迫近的隐患。为什么“更迫近”？因为它把风险发生的时点提前到了今天。我们可以把它形式化为三个变量：

X = 数据的保密年限。你的并购文件、患者档案、国家机密、工业配方，需要保密多少年？（通常 5–30 年）
Y = 你完成 PQC 迁移所需的年限。含选型、FIPS 认证等待、硬件刷新周期、全网割接。（通常 3–7 年）
Z = 距离 Q-Day 还有多少年。（不确定，业界估计 5–15 年）

如果 X + Y > Z，那么你已经在泄密了。 请注意：不是“未来会泄密”，而是“你今天发出的每一个数据包，都已经注定要在保密期内被解密”。

说明：这个不等式并非本文首创，它在密码学界被称为 Mosca 不等式 （由 Michele Mosca 提出），是评估 PQC 迁移紧迫性的通用框架。此处的三个取值区间为业界常见估计，非 Cisco 资料原文数据—— 请用你自己组织的真实数字代入。

而 Y 这个变量，往往被严重低估。Cisco 白皮书专门用一节讲这件事（“Challenges to Implementation”）：“FIPS certification, for instance, can take up to two years or more.” 光是等一张认证证书，就吃掉两年。

精准定义

HNDL（Harvest Now, Decrypt Later）

攻击者在今天大规模采集并存储加密流量（尤其是密钥协商阶段的报文）， 不尝试即时破解，而是等到未来 CRQC 可用时再统一解密。 Cisco 白皮书特别指出：考虑到当前由境外政府主导的大规模数据泄露事件的普遍程度， “it's not difficult to imagine the risk exposure inherent in HNDL”。

精妙类比

偷走一个打不开的保险箱

小偷进屋，没有撬锁，而是把整个保险箱搬回家放进仓库，然后耐心等待——等哪一天市面上出现了能开这型号锁的工具。

这时你会发现一个反直觉的事实：“换一把更好的锁”对已经被搬走的那个箱子毫无帮助。 这就是 HNDL 最残忍的地方——它让“未来的补救”对“过去的数据”完全无效。 你唯一能保护的，是从现在起发出的数据。

1.5 第五问：谁在定规则？时间表到底有多紧？

Socratic Question 05

如果这只是“安全厂商的焦虑营销”，为什么美国政府会为它发行政命令？为什么金融机构在没有强制要求时就已经动手？

资料给出的答案非常清晰：这已经不是技术圈的讨论，而是国家安全议程。根据白皮书「Government and Standards Bodies Respond to the Threat」一节：

2022 · 行政命令与国家安全备忘录美国政府发布 Executive Order (EO) 与 National Security Memorandum (NSM)，明确指令 NIST “publish new quantum-resistant cryptographic standards that can protect against these future attacks”。同年，NSA 发布 CNSA 2.0（Commercial National Security Algorithm Suite 2.0）。
2024 · NIST 三大算法定稿经过全球科学家与机构六年以上的评选，NIST 正式发布三个抗量子算法，成为新的 FIPS 标准（FIPS 203 / 204 / 205）。 BRKXAR-2027 Slide 34 将这一年标注为 “NIST PQC Standards Approved”。
2025 · 固件签名的建议采纳年 CNSA 2.0 时间表中，PQC image signing and verification 的 preferred date of adoption 为 CY 2025。注意：这一项已经过期
2026 · 网络设备的建议采纳年 Network Devices 的 preferred date of adoption 为 CY 2026。白皮书原文更进一步：NSA 表示“it prefers for NSS to be protected perhaps as soon as 2027”。这就是当下
2025–2030 · 迁移执行窗口（与上面两项重叠） BRKXAR-2027 Slide 34 标注为 “Adopt Post-Quantum Cryptography”—— 这是留给企业完成全网迁移的窗口。
2030 · 强制截止（Required date of adoption） NSA 要求所有与 National Security Systems (NSS) 相关的公司与政府机构，必须完成抗量子加密部署。2030 是“must have”日期。
2030–2035 · 量子计算机现身 BRKXAR-2027 Slide 34 标注为 “Emergence of Quantum Computers”。 请把这个区间与上面的 X + Y > Z 公式一起看。

CNSA 2.0 时间表（原始表格还原）

CNSA 2.0 采纳时间表
项目	建议采纳日期 Preferred date of adoption	强制采纳日期 Required date of adoption
PQC image signing and verification （固件/软件镜像的 PQC 签名与验签）	CY 2025	CY 2030
Network Devices （网络设备）	CY 2026	CY 2030

一个关键的合规洞察：白皮书明确指出，严格来说 NIST 与 NSA 标准 “only apply to entities that need to be FIPS compliant or work on NSS”。但接下来这句话才是重点：“for practical reasons, many organizations in both the private and public sector are pursuing the adoption of these standards, even if they are not mandated. Financial institutions, for example, feel an urgent need to be quantum safe, even if the government hasn't yet required it of them.”

翻译成决策语言：不要问“我被强制了吗”，要问“我的数据保密期有多长”。

1.6 第六问：NIST 究竟批了什么？三个算法各管什么事？

Socratic Question 06

为什么 NIST 需要三个算法，而不是一个“万能抗量子算法”？这背后反映了什么样的需求分层？

因为公钥密码本来就在干两件完全不同的事，白皮书把它们归为“two distinct categories: general encryption and digital signatures”：

密钥建立（Key Establishment）——“我们俩怎么在公开信道上商定一个只有我们知道的密钥？”
数字签名（Digital Signature）——“这份代码/证书/身份，真的是你签发的、且没被改过吗？”

原名（竞赛期）	NIST 正式名	FIPS 标准号	用途	技术原理
CRYSTALS-Kyber	ML-KEM	FIPS 203	通用加密 / 密钥封装（如保护网站、VPN 密钥交换）	格密码（lattice-based）密钥封装机制 KEM。NIST 选它的部分原因是密钥体积相对较小、易于交换，且运行速度快，适合大多数负载
CRYSTALS-Dilithium	ML-DSA	FIPS 204	数字签名 / 身份验证	Module-Lattice-Based Digital Signature Algorithm，格密码签名。白皮书判断：“it is probable that the lattice-based CRYSTALS-Dilithium will emerge as the predominant standard”（很可能成为主导标准）
SPHINCS+	SLH-DSA	FIPS 205	数字签名（备选路线）	Stateless Hash-Based Digital Signature Algorithm，基于哈希而非格。作为“数学路线多样化”的保险——万一格密码被攻破，哈希路线仍在

精准定义

KEM（Key Encapsulation Mechanism，密钥封装机制）

它不是传统意义上的“加密算法”。 KEM 干的事是：Bob 用 Alice 的公钥“封装”出一段密文 ct 和一个共享密钥 K； Alice 用私钥“解封”ct，得到一模一样的 K。 BRKXAR-2027 Slide 37 用三步画清了这个过程： KeyGen → Encaps → Decaps，最终 K = K'。

精妙类比

公开的邮筒与只有你有的钥匙

Alice 在广场上放了一个任何人都能往里投信、但只有她能打开的邮筒（公钥 = 邮筒，私钥 = 钥匙）。 Bob 想约定一个暗号：他在现场当场随机生成一个暗号，投进邮筒，然后自己也记住这个暗号。 Alice 回家打开邮筒，拿到同一个暗号。

关键点：暗号不是“交换”出来的，是 Bob 单方面“造”出来再安全送达的。 这就是 KEM 与传统 Diffie-Hellman“双方共同推导”的本质区别。

但请不要误读因果：抗量子性并不来自这个结构差异，而来自底层数学难题的更换 （格问题取代了离散对数）。KEM 结构带来的是工程性好处—— 接口边界干净，便于在不改动上层协议的前提下替换底层算法。

CNSA 2.0 具体要求了哪些算法？

白皮书「The Impact and Timeline of CNSA 2.0」一节给出了明确清单。这份清单极其重要，因为它决定了你未来采购设备时的验收标准：

用途场景	CNSA 2.0 要求的算法	说明
固件与软件签名 Signatures for firmware and software	LMS（Leighton-Micali Signatures）、XMSS（Extended Merkle Signature System）	两者都是有状态的、基于哈希（stateful and hash-based）。CNSA 2.0 现在也允许使用 ML-DSA-87 用于此目的
身份与认证签名（通用目的） Signatures for identity and authentication	ML-DSA-87	即 ML-DSA 的 Level 5 安全参数集——最高强度档
批量加解密 Bulk encryption/decryption	AES-256	注意：没有变。再次印证 1.3 节的结论——对称算法本就量子安全
系统级哈希 General system-wide hashing	SHA-384 或 SHA-512	哈希长度加倍以抵御量子搜索带来的平方根加速

1.7 第七问：为什么标准已定，却还要用“混合”方案？

Socratic Question 07

既然 NIST 已经批准了抗量子算法，为什么 Cisco、Google 等厂商不直接切换，反而要费力同时跑两套密钥交换？这不是浪费性能吗？

这是本章最能体现工程智慧的一问。白皮书给出的两条理由，逻辑严密到几乎无法反驳：

理由一：新算法可信，但新实现未必

白皮书原文：“While the PQC algorithms are believed to be solid, the software implementations and associated protocols are new. Even though they will be well tested, new vulnerabilities are typically uncovered over time.”

第一性原理：数学证明与代码实现是两回事。历史上绝大多数密码事故（Heartbleed、各种侧信道）都不是算法被破，而是实现出错。混合方案的作用是——“如果 PQC 实现出问题，我还有传统密钥交换作为兜底（fallback protection）”。

理由二：FIPS 认证等不起

白皮书原文：“the current average time to complete FIPS certification of the PQC algorithms is two years or more. A hybrid approach using a FIPS-certified legacy crypto algorithm for the initial key eliminates this delay.”

第一性原理：许多组织在采购上有硬性合规约束——必须 FIPS 认证。混合方案里，初始密钥来自已认证的传统算法，PQC 部分是叠加增强，从而合规与安全同时成立，不必等两年。

精准定义

混合密钥交换（Hybrid Key Exchange）

在一次会话建立中同时执行传统密钥交换（DH / ECDH）与 PQC 密钥交换（ML-KEM），将两者产出的共享秘密共同派生为最终会话密钥。 BRKXAR-2027 Slide 38 的图示极为直观： DH Shared Secret + ML-KEM Shared Secret → Session Key。 只要其中任意一个未被攻破，会话密钥就依然安全。

精妙类比

两把锁串联的银行金库

金库门上装两把完全不同原理的锁：一把是用了三十年、被无数次验证过可靠的机械锁（ECDH），一把是刚出厂、理论上更强但没经过实战的生物识别锁（ML-KEM）。

小偷必须同时打开两把才能进去。 老锁防的是“新锁有 bug”，新锁防的是“老锁被量子撬开”。 这不是浪费——这是在两种截然不同的风险之间买了双向保险。

支撑混合方案的 IETF 协议标准

BRKXAR-2027 Slide 39 与白皮书「Protecting Yourself Tomorrow」一节共同给出了完整的标准图谱。注意：算法标准由 NIST 出，协议怎么用算法由 IETF 出——两层必须都齐备。
下表中除 RFC 9242 外，其余条目均出现在 Slide 39； RFC 9242 来自白皮书并被本文补入，因为它是理解 PQC 报文体积问题（见 2.5 节）的必要背景。

协议	相关标准 / 草案	作用
IKEv2 / IPsec	RFC 9370 – Multiple Key Exchanges in IKEv2 注白皮书中该条目记为 RFC 9730，BRKXAR-2027 记为 RFC 9370，实施时请以最新 RFC 编号为准	使 IKEv2 支持多次密钥交换——混合方案的协议基础
	RFC 9242 – Intermediate Exchange in IKEv2	解决 PQC 公钥/密文体积大的问题，用于传输大数据量的中间交换
	IETF Draft – PQ Hybrid Key Exchange with ML-KEM in IKEv2	定义如何在 RFC 9370/9242 框架下具体使用 ML-KEM 的配置档（profile）
TLS 1.3	IETF Draft – Hybrid key exchange in TLS 1.3	同时使用多个密钥交换算法，“即使除一个之外全部被攻破，仍保持量子安全”
TLS 1.3	IETF Draft – ML-KEM Post-Quantum Key Agreement for TLS 1.3	TLS 1.3 中 ML-KEM 的原生（单一）密钥协商
SSH	IETF Draft – PQ/T Hybrid Key Exchange with ML-KEM in SSH	使用 Elliptic Curve + ML-KEM 组合作为密钥交换方法，目标是构造一个“即使用量子计算机也在计算上不可能破解”的离散问题
SSH	IETF Draft – Module-Lattice Key Exchange in SSH	SSH 中格密码密钥交换的原生形式

一个值得注意的行业信号：白皮书指出 “Multiple key exchange is required for IPsec and many in the industry, including Google, currently support it for TLS.” —— 也就是说，IPsec 场景下混合密钥交换是“必须”（required），而 TLS 场景下 Google 等巨头已在生产环境支持。这意味着：混合方案不是 Cisco 的一家之言，而是已经形成互操作生态的行业共识。选择混合，同时也是选择了可互通性（interoperability）。

1.8 第八问：如果我的设备今天还不支持 PQC，我就只能等着被 HNDL 吗？

Socratic Question 08

回到 1.3 节的结论——问题只出在“密钥是怎么送过去的”。那么，有没有一种办法，让密钥根本不经过公钥密码就到达对端？

有。而且这是白皮书「Protecting Yourself Today」一节的全部内容。这个思路极其漂亮，堪称第一性原理的教科书案例：

第一性原理拆解：既然“通道”危险，就绕开通道

逻辑链条是这样的：

数据由 AES-256 保护 → 量子安全。
AES-256 的密钥由非对称密码建立 → 量子脆弱。
所以：只要密钥的来源不是非对称密码，链条就补上了。

白皮书原文：“One solution is to use an alternative method for obtaining the keys used to encrypt/decrypt data—one that doesn't rely on asymmetric cryptography.” 它列出了三种今天就能落地的方法，三者的共同产物叫做 PPK（Postquantum Pre-shared Keys，后量子预共享密钥），用途明确：“to ensure that currently encrypted traffic is safe against an HNDL attack”。

精准定义

PPK（Postquantum Pre-shared Key）

一段不通过公钥密码协商、而是通过其他可信途径预先获得的量子安全密钥材料，用于参与 IPsec 会话密钥的派生。因为它从未在公开信道上以“可被数学反推”的形式出现过，所以攻击者即便完整录下了整条隧道的握手过程，也拿不到 PPK，从而无法还原会话密钥。

精妙类比

寄信之前先约好的“书页密码”

两个特工在面对面时约定：“以后所有暗号，都以《战争与和平》第 347 页第 12 行为基准。” 此后他们在公开电报里怎么聊，敌人都听得见—— 但敌人永远不知道那本书、那一页。

因为这个信息从未上过电报线。 没上过线的东西，再强的量子计算机也解不出来。 这就是 PPK 的全部智慧。

Cisco 给出的两阶段最佳实践

白皮书「Emerging Solutions and Best Practices for PQC」一节，把落地路径清晰地拆成了先后两步——这个先后顺序本身就是重要洞察：

近期 · Near Term 先搞定传输层

原文：“In the near term, deal with the transport layer”。最佳实践是按风险确定优先级（establish a priority for PQC implementation based on risk）—— 鉴于 HNDL 威胁，先保护最敏感的数据。

具体做法：把传统密码方法与替代性的量子安全密钥供给方法结合起来（即上文三种 PPK），等 PQC 方案可用后再迁移过去。

为什么先做这个？因为软件可升级，见效最快，而 HNDL 是正在发生的。

中长期 · Then 再落实硬件量子安全

原文：“Then, implement quantum safe computing in hardware”。涉及 secure boot、认证固件升级、设备身份等。

白皮书在此处有一句极其诚实、也极其重要的表述： “While many Cisco devices already include critical quantum-safe protections (such as LDWM for Secure Boot), no hardware exists today that is compliant with CNSA 2.0 algorithms.”

因此建议：把量子安全硬件纳入产品刷新周期（product refresh cycles），一旦上市就同步规划。

这句“no hardware exists today”是本文通往第三、四章的门票。 请把它记牢——因为 Cisco 8000 系列 Secure Routers 正是对这句话的直接回应：它把 PQC 从“传输层的软件补丁”，一路做进了芯片里的信任根。

BRKXAR-2027 Slide 8 用了一个词来概括它：Full-stack PQC（全栈后量子）。全栈的意思是——从加电的第一条指令，到 WAN 上的最后一个数据包，全部量子安全。

1.9 本章小结：把风险模型压缩成一页

分钟级CRQC 破解 RSA-2048 所需时间

2 年+仅 FIPS 认证的等待周期

2026CNSA 2.0 网络设备建议采纳年

2030NSS 强制合规截止年

维度	常见误解	第一性原理下的真相
威胁性质	“加密全部失效”	只有非对称密钥交换失效；AES-256 与哈希（加长后）依然安全。战场仅在握手阶段
应对手段	“把密钥加长到 4096 位”	无效。量子算法是结构性抄近路，不是暴力穷举。必须换数学问题（格 / 哈希）
紧迫性	“Q-Day 还早，等等再说”	X（保密年限）+ Y（迁移年限）> Z（距 Q-Day）即已在泄密。HNDL 让风险今天生效
迁移策略	“标准定了就直接切换到纯 PQC”	先用混合密钥交换：既防 PQC 新实现的未知漏洞，又绕开 2 年 FIPS 认证等待
实施顺序	“等新硬件一起换”	先传输层（软件，可即刻见效）→ 再硬件信任根（随刷新周期）。按数据敏感度排优先级
合规范围	“我不做政府项目，不受管”	标准法定适用于 FIPS/NSS，但金融等行业已自发采纳。真正的判断依据是你的数据要保密多久

第一章金句

量子威胁不是一场“加密的末日”，而是一次“信任的清算”——它逼我们回答一个从未认真回答过的问题：我们究竟凭什么，相信一条看不见的链路？

第二章 · Chapter 02

Cisco 的答卷：什么叫「Full-Stack PQC」，以及它凭什么敢这么说

第一章我们确立了病理诊断：病灶在密钥交换的那几十毫秒。本章要看的是处方——但请带着怀疑读。因为「支持 PQC」这四个字，在不同厂商口中的含金量可能相差十倍。

2.1 第九问：什么叫「全栈」？只在 VPN 上做 PQC，缺口在哪？

Socratic Question 09

假设一台路由器的 IPsec 隧道已经用上了 ML-KEM，量子安全了。那么请问：这台路由器上运行的操作系统镜像，是谁签的名？用什么算法签的？如果那个签名是 RSA-2048 呢？

这个问题一旦被问出来，整个「PQC 支持」的话语体系就会崩塌一半。因为答案是：如果镜像签名是量子脆弱的，那么攻击者根本不需要破解你的 IPsec 隧道—— 他只需要伪造一个签名，让你的路由器加载一个「看起来完全合法」的恶意镜像，然后直接从设备内部读取明文。

第一性原理拆解：安全链条的强度 = 最弱一环的强度

这不是新道理，但在 PQC 语境下它变得异常锋利。一台网络设备的安全，实际上由四条独立的信任链共同支撑：

启动链：加电 → 微加载器 → Bootloader → OS → 应用。每一步都需要验签。→ 需要 PQC 签名算法
身份链：这台设备是不是真的思科设备？它的身份证书用什么算法？→ 需要 PQC 设备身份
WAN 加密链：站点到站点的 IPsec / MACsec。→ 需要 PQC 密钥交换
管理链：SSH 登录、TLS 管理会话、SD-WAN 控制器通信。→ 需要 PQC 密钥交换

只做第三条，等于给一扇纸门装了防弹锁。 这就是为什么 BRKXAR-2027 Slide 8 在介绍 8650 时，把 PQC 拆成了四个并列条目：「NIST Compliant (FIPS-203) PQC IPsec VPN」、「Quantum-safe MACsec (LAN/WAN) with EAP-TLS」、「PQC SD-WAN」、 「PQC Secure Boot」。

精准定义

Full-Stack PQC（全栈后量子）

指在一个系统中，所有依赖公钥密码的环节—— 包括启动时的镜像验签、设备身份证明、WAN/LAN 数据加密的密钥协商、以及管理与控制平面的会话建立——全部迁移至 NIST 认可的抗量子算法。

判定标准很简单：找不到任何一处仍在裸用 RSA / ECDSA / ECDH 且无 PQC 保护的关键路径。

精妙类比

换锁，还是换整栋楼的门窗？

你家防盗门换了 C 级锁芯（= PQC IPsec）。但一楼窗户还是普通玻璃（= RSA 签名的固件）、门禁卡还是老式磁条（= 传统设备身份）、物业后台还能远程开门且密码是 123456（= 未加固的管理面）。

小偷会走哪儿？——他会走最省事的那一处。「全栈」的意思是：把整栋楼的每一个开口都同步升级，让攻击者找不到那个「最省事的地方」。

带着这个标准，我们来看 Cisco 8000 系列的 PQC 覆盖版图。这是 BRKXAR-2027 Slide 40「Secure WAN PQC Solutions」与 Slide 30「PQC Secure Boot」的整合视图：

请注意第 ① 层里的一个精妙设计： Microloader 用的是 LMS，而 OS 与应用用的是 ML-DSA-87。 为什么不统一？

因为 LMS 是有状态的哈希签名（stateful, hash-based），数学假设最保守、最不依赖新理论（其安全性只归结为哈希函数的单向性与抗第二原像性—— 这是密码学中被检验得最久、最少被推翻的假设之一），适合放在永不可变、一次烧死的硬件信任根里—— 你不希望信任链的第一环，建立在一个未来可能被证伪的新数学问题上。

而 ML-DSA-87 签名/验签效率更高、支持无状态大规模签发，适合需要频繁更新的软件镜像。这与 CNSA 2.0 的要求完全吻合：固件签名用 LMS/XMSS（也允许 ML-DSA-87），身份认证用 ML-DSA-87。 这是「用不同的数学假设分散风险」的典范。

2.2 第十问：ML-KEM 到底怎么工作？三步走通一次量子安全握手

Socratic Question 10

传统 Diffie-Hellman 是「双方各自算一半，凑出一个共同答案」。ML-KEM 换了什么玩法？为什么这个换法能抗量子？

BRKXAR-2027 Slide 37 用一张图讲清了 FIPS 203 定义的三步机制。我们把它完整还原并加上解释：

第一性原理拆解：为什么「格」抗量子？

白皮书对 CRYSTALS-Kyber（ML-KEM）的技术描述是： “a 'lattice-based' Key Encapsulation Mechanism (KEM) which uses highly complex mathematical structured lattice equations to create patterns of encryption that cannot be broken, even by a quantum computer.”

关键在于：格问题（如「最短向量问题」）目前不存在已知的高效量子算法。量子计算机之所以能打败 RSA 和 ECC，是因为它们的底层问题（分解、离散对数）都具有一种叫做「周期性」的隐藏结构，而量子傅里叶变换恰好极擅长找出周期。 格问题没有这种周期结构。

换句话说：PQC 不是「让量子计算机算得更慢」，而是「把题目换成了量子计算机没有专用工具的那一类」。 这是一个类型层面的转换，不是程度层面的加强。

白皮书还说明了 NIST 选择它的两个工程理由： ① 密钥体积相对较小、易于交换（“use of relatively small keys that can be easily exchanged”）； ② 运行速度快（“operates at high speed, which is advantageous for most workloads”）。 —— 对网络设备而言，这两点几乎是决定性的：密钥太大会撑爆 IKE 报文，太慢会拖垮隧道建立速率。

精准定义

Encaps / Decaps 与 DH 的本质差异

DH：双方各自生成私有随机数，交换公开值，各自计算得到相同结果。共享密钥是「共同推导」出来的。

KEM：共享密钥由发起封装的一方（Bob）单方面随机生成，再用对方公钥「装进箱子」（ct）送过去。共享密钥是「单方生成 + 安全投递」的。

这个差异有实际后果：KEM 的设计更容易获得严格的安全性证明（IND-CCA2），也更容易与现有协议做「叠加」而非「替换」。

精妙类比

DH = 调色，KEM = 快递保险箱

DH 像两人调色：两人各自往公共的黄色颜料里加入自己的秘密颜色，交换半成品，再各自加回自己的秘密色——最终得到同一种颜色。旁观者看得到所有交换过程，但调不出那个最终色。

KEM 像寄保险箱：Bob 自己写好一张暗号纸条，放进 Alice 给的、只有 Alice 能开的保险箱，寄出去。 Bob 手里留一份纸条副本。

为什么后者更容易抗量子？因为「箱子的锁」可以独立更换为任何抗量子设计，而不必改动「纸条怎么写」——接口清晰，改造范围可控。

2.3 第十一问：混合密钥交换在报文层面究竟发生了什么？

Socratic Question 11

如果一次握手里跑了两套密钥交换，产生了两个共享秘密——它们是「二选一」，还是「拼在一起」？这个细节为什么决定了整个方案是否真的安全？

答案必须是拼在一起（共同派生），绝不能是二选一。 BRKXAR-2027 Slide 38 的图示对此毫不含糊：

对比第一章 Slide 35 的那张图，你会发现一个漂亮的收束： 原本「Quantum-vulnerable」的标签贴在密钥交换阶段和会话密钥上；现在同一个位置的标签变成了「Quantum-resistant」。

而右侧的 AES-256 数据加密部分，一个字都没改。 这就是全部工程量所在——只动那几十毫秒，就把整条隧道的时间承诺延长了几十年。

2.4 落地一：IKEv2 IPsec 的 PQC 配置与验证（逐行解读）

理论讲完，看命令。这是 BRKXAR-2027 Slide 41 的完整配置示例，标注为 New XE 26.1.1。我把它拆开逐行解释——因为这里面藏着一个极其重要的设计决策。

crypto ikev2 proposal ikev2proposal
 encryption aes-cbc-256
 integrity  sha512
 group 21
 pqc mlkem768 optional          <-- 关键行
!
crypto ikev2 policy ikev2policy
 proposal ikev2proposal
!
crypto ikev2 keyring ikev2keyring
 peer HUB_PEER_KEYRING_NAME
  address [HUB_PUBLIC_IP]
  pre-shared-key Cisco@123
!
crypto ikev2 profile ikev2profile
 match identity remote address [HUB_PUBLIC_IP]
 authentication local  pre-share
 authentication remote pre-share
 keyring local ikev2keyring
!
crypto ipsec transform-set tset1 esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile ipsec_profile_vti
 set transform-set tset1
 set ikev2-profile ikev2profile
 set pfs

配置行	作用	第一性原理解读
`encryption aes-cbc-256`	IKE SA 的加密算法	对称算法，本身已量子安全，无需更改。这印证了第一章 1.3 节的结论
`integrity sha512`	完整性校验算法	选 SHA-512 而非 SHA-256：Grover 算法对哈希有平方根加速，512 位输出留出足够安全边际。与 CNSA 2.0 要求的 SHA-384/512 一致
`group 21`	传统 DH 组（521-bit ECP）	注意它没有被删掉。这就是混合方案——传统 DH 依然在跑，提供 FIPS 合规性与 fallback 保护
`pqc mlkem768`	启用 ML-KEM-768 作为额外密钥交换	FIPS 203 的 Level 3 参数集。与 `group 21` 并列存在 → 二者共享秘密共同派生会话密钥
`optional`	非严格 PQC 强制（non-strict PQC enforcement）	这是整段配置里最需要理解的一个词，见下方专门讨论
`set pfs`	启用完美前向保密	每次重新协商都产生全新密钥。PFS + PQC 是叠加防护：PFS 限制单次密钥泄露的时间窗口，PQC 保证该窗口内的密钥本身不可反推

深入：`optional` 这个关键字为什么至关重要？

延伸提问

如果 PQC 更安全，为什么 Cisco 要提供一个「可选」模式，而不是强制？这是妥协，还是深思熟虑？

第一性原理拆解：迁移期的「双语能力」

设想一个真实的企业网络：3000 个站点，其中 200 个已升级到 XE 26.1.1 支持 ML-KEM， 2800 个还在老版本上。如果 PQC 是强制（strict）的，会发生什么？

那 200 个新站点将无法与 2800 个老站点建立任何隧道。 网络在割接当天直接断裂。

optional 的语义是：「我支持 PQC，我优先用 PQC；但如果对端不支持，我退回传统模式，隧道照样建起来。」 这使得分阶段、无中断的渐进式迁移成为可能。

但请务必注意运维含义：optional 模式下， 你无法从「隧道是 UP 的」推断出「隧道是量子安全的」。必须逐条会话验证。这直接引出下面的 show 命令为什么不可或缺。

建议的迁移路径：全网升级期用 optional → 达到 100% 覆盖后 → 去掉 optional 转为强制， 关闭降级通道，防止攻击者通过降级攻击（downgrade attack）迫使会话退回量子脆弱模式。

精准定义

ML-KEM 参数集：768 vs 1024

ML-KEM-768 对应 NIST 安全强度 Level 3； ML-KEM-1024 对应 Level 5（最高档）。数字越大 = 格的维度越高 = 安全边际越大，但公钥与密文体积越大、计算开销越高。

BRKXAR-2027 中的取舍很有意思： DMVPN 示例用 mlkem768 + optional（大规模、海量隧道、需兼容）， FlexVPN 示例用 mlkem1024（无 optional）（强调标准化框架与最高强度）。

精妙类比

保险柜的钢板厚度

ML-KEM-768 像 10 厘米钢板，ML-KEM-1024 像 20 厘米钢板。两者今天都没人能撬开。

但 20 厘米的柜子更重、更贵、装不进小房间—— 对应到网络里就是：IKE 报文更大（可能触发分片）、隧道建立速率下降、CPU 开销上升。

专业的选择不是「越厚越好」，而是「与被保护资产的价值和保密年限匹配」。 存三年的营销数据用 768，存三十年的国防档案用 1024。

验证：如何证明这条隧道真的量子安全了？

BRKXAR-2027 Slide 42 给出了验证命令与输出。这是运维交付的关键证据。

Router# show crypto ikev2 sa detailed

IPv4 Crypto IKEv2 SA
Tunnel-id  Local        Remote       fvrf/ivrf   Status
4          1.1.1.2/500  1.1.1.1/500  none/none   READY

  Encr: AES-CBC, keysize: 256, PRF: SHA512, Hash: SHA512,
  DH Grp:21, Auth sign: PSK, Auth verify: PSK
  PQC Key Exchange: ML-KEM-768              <-- 证据 ①
  Life/Active Time: 86400/65905 sec
  CE id: 0, Session-id: 1
  Local  spi: 828DC8848548B23C
  Remote spi: D77638A21E177EF0
  Status Description: Negotiation done
  Local  id: 1.1.1.2      Remote id: 1.1.1.1
  Local req msg id: 44    Remote req msg id: 0
  Local next msg id: 44   Remote next msg id: 0
  Local req queued: 44    Remote req queued: 0
  Local window: 20        Remote window: 20
  DPD configured for 0 seconds, retry 0
  Fragmentation not configured.
  Quantum-safe Encryption using PQC: ML-KEM-768   <-- 证据 ②
  Dynamic Route Update: enabled
  Extended Authentication not configured.
  NAT-T is not detected
  Cisco Trust Security SGT is disabled
  Initiator of SA : Yes
  PEER TYPE: IOS-XE

输出字段	读法	运维意义
`Status: READY`	SA 已建立	但这不能说明是否 PQC。`optional` 模式下降级也是 READY
`DH Grp: 21`	传统 DH 组仍在使用	混合方案的直接证据——传统与 PQC 并存，非替换
`PRF: SHA512, Hash: SHA512`	伪随机函数与哈希	符合 CNSA 2.0 对系统级哈希的要求
`PQC Key Exchange: ML-KEM-768`	协商结果中包含 ML-KEM	这一行是你在审计报告里唯一能引用的硬证据。若此行缺失或为空 → 该隧道未量子安全
`Quantum-safe Encryption using PQC`	明确的量子安全声明	提供人类可读的确认，便于运维与合规团队快速判读

给运维团队的一条具体建议（基于上述输出推导）： 在 PQC 迁移期，把 show crypto ikev2 sa detailed 的输出纳入自动化巡检， 以「PQC Key Exchange 字段非空」作为量子安全隧道的判定条件，统计「PQC 覆盖率 = PQC 隧道数 / 总隧道数」作为迁移进度 KPI。

这个指标比「设备升级台数」有意义得多——因为设备升级了，不代表对端也升级了；隧道两端都支持，才真的算数。

注：BRKXAR-2027 在这两页均标注 “Some CLI implementation and show outputs may change”，实际部署时请以对应 XE 版本的官方配置指南为准。

本节金句

optional 这个关键字，是工程师对现实的一次诚实妥协——但迁移完成后不把它删掉，就变成了对安全的一次沉默背叛。

2.5 落地二：DMVPN 与 FlexVPN —— 为什么配置「几乎一样」？

Socratic Question 12

DMVPN 有 mGRE、有 NHRP、有动态 spoke-to-spoke 隧道；FlexVPN 有 IKEv2 框架、有虚拟模板。两者架构差异巨大。为什么它们的 PQC 配置几乎一字不差？这说明了什么？

BRKXAR-2027 Slide 43（DMVPN）与 Slide 44（FlexVPN）给出的配置，核心部分完全相同，两页幻灯片都用同一句话标注： “Same configuration as IKEv2 IPsec”，验证命令也都是 “Use show crypto ikev2 sa for verification”。

第一性原理拆解：分层解耦的回报

这不是偷懒，这是网络协议分层设计在 30 年后收到的一张回报单。

DMVPN 与 FlexVPN 都是叠加在 IKEv2/IPsec 之上的隧道编排方案：

DMVPN = mGRE（多点隧道封装）+ NHRP（下一跳解析）+ IPsec/IKEv2（加密）
FlexVPN = 标准化的 IKEv2 配置框架 + IPsec/IKEv2（加密）

它们各自解决的是「隧道怎么建、建给谁、什么时候建」的拓扑编排问题；而 PQC 解决的是「密钥怎么协商」的密码学问题。

这两个问题在架构上是正交的（orthogonal）。 因此，只要把 PQC 植入 IKEv2 这一层，所有建立在 IKEv2 之上的方案自动获得量子安全—— 无需为每种 VPN 方案单独开发。

这是一个极其重要的采购与规划洞察： 你不需要问「我的 DMVPN 支持 PQC 吗」「我的 FlexVPN 支持 PQC 吗」，你只需要问一个问题：「我的 IKEv2 栈支持 ML-KEM 吗？」

精准定义

DMVPN（Dynamic Multipoint VPN）

BRKXAR-2027 Slide 43 的原文定义： “DMVPN allows large scale IPsec VPNs deployment by combining mGRE, IPsec/IKEv2, and NHRP.”

核心价值是免除 N² 配置爆炸：只在 Hub 上做集中配置，Spoke 之间可根据流量需要按需建立直连隧道（on-demand tunnels），用完自动拆除。适合站点数量大、流量模式动态的企业网。

精妙类比

枢纽机场 + 临时直飞航线

传统 IPsec 点对点：要开通 100 个城市互飞，需要人工签 4950 条航线协议。

DMVPN：所有城市先都飞到一个枢纽机场（Hub）报到并登记自己的位置（NHRP）。当上海到成都突然有大量客流时，两地临时开一条直飞航线（spoke-to-spoke on-demand tunnel），客流结束航线自动取消。

PQC 在这个比喻里是什么？——它是登机口的安检标准。升级安检标准，不需要重画任何一条航线图。

DMVPN 场景配置（Slide 43）

! Configure
crypto ikev2 proposal ikev2proposal
 encryption aes-cbc-256
 integrity  sha512
 group 21
 pqc mlkem768 optional
!
crypto ikev2 policy ikev2policy
 proposal ikev2proposal
!
! 其余部分与 IKEv2 IPsec 完全相同
! 验证：show crypto ikev2 sa

FlexVPN 场景配置（Slide 44）

! Configure
crypto ikev2 proposal ikev2proposal
 encryption aes-cbc-256
 integrity  sha512
 group 21
 pqc mlkem1024          <-- 注意：Level 5 参数集，且无 optional
!
crypto ikev2 policy ikev2policy
 proposal ikev2proposal
!
! 其余部分与 IKEv2 IPsec 完全相同
! 验证：show crypto ikev2 sa

对比维度	DMVPN 示例	FlexVPN 示例	差异背后的工程逻辑（推导）
PQC 参数集	`mlkem768`（Level 3）	`mlkem1024`（Level 5）	DMVPN 典型场景是海量 Spoke + 按需隧道，隧道建立频率高、并发大 → 优先控制握手开销与报文体积。FlexVPN 更常用于结构化、强安全要求的站点互联 → 可承受更高强度
强制模式	`optional`（非严格）	无 `optional`（严格）	DMVPN 部署基数大、版本混杂 → 必须保留向下兼容以支持渐进迁移。FlexVPN 场景更可控 → 可直接强制，关闭降级通道
报文分片风险	较低	较高	ML-KEM-1024 公钥/密文更大。若路径 MTU 受限，需关注 IKEv2 分片；这也正是 RFC 9242（Intermediate Exchange）存在的原因——专门为传输大体积 PQC 材料而设计
拓扑	Hub-Spoke 隧道 + 按需 Spoke-Spoke 隧道	FlexVPN Tunnels（标准化框架）	拓扑与 PQC 完全解耦，这是上述配置雷同的根本原因

一个容易被忽略的部署提醒： DMVPN 的 spoke-to-spoke 按需隧道意味着任意两个 Spoke 之间都可能直接协商 IKEv2。因此在 optional 模式下，PQC 覆盖率的分母不是「Hub 隧道数」，而是「所有可能的 Spoke 对」。

换句话说：只要网络中还剩一个不支持 PQC 的 Spoke，它与任何其他 Spoke 之间的直连隧道就都是量子脆弱的。 DMVPN 的 PQC 迁移，木桶效应比 Hub-Spoke 架构更明显。

2.6 落地三：Quantum-safe MACsec —— 为什么它需要拉上 EAP-TLS？

Socratic Question 13

MACsec 是二层线速加密，它自己就有 MKA 协议来协商密钥。那为什么要引入 802.1X 和 EAP-TLS 这么一大套东西才能让它量子安全？

这个问题的答案，是本章最能体现「第一性原理」价值的一处。让我们按 BRKXAR-2027 Slide 45 的四步流程，把 MACsec 的信任来源一层层剥开。

第一性原理拆解：追问「MACsec 的密钥从哪来」

MACsec 用 MKA（MACsec Key Agreement）协议协商会话密钥（SAK）。但 MKA 本身不产生信任——它需要一个预先存在的 CAK（Connectivity Association Key）作为根。CAK 从哪来？两条路：

路线 A：预共享密钥（PSK）。手工配置。量子安全（因为它从未上过线），但存在第一章讨论过的所有手工密钥管理问题：熵不足、轮换困难、规模化噩梦。
路线 B：证书 / 802.1X 认证。可自动化、可规模化、可集中吊销。但它的信任建立在 TLS 握手之上——而 TLS 握手用的是公钥密码 → 量子脆弱！

于是问题浮现：企业既想要路线 B 的可运维性，又要路线 A 的量子安全性。怎么办？

Cisco 的答案：把 PQC 打进 EAP-TLS 的 TLS 1.3 握手里。 这样，产生 MSK（Master Session Key）的那次 TLS 密钥交换本身就是量子安全的，由它派生的 CAK、再由 CAK 派生的 SAK，整条派生链全部量子安全。

这就是为什么 Slide 8 在描述 8650 时，用词是「Quantum-safe MACsec (LAN/WAN) with EAP-TLS」—— with EAP-TLS 不是可选修饰，而是量子安全的必要条件。

精准定义

MACsec（IEEE 802.1AE）

在二层（以太网帧）实施加密与完整性保护的标准。与 IPsec（三层）的关键差异： MACsec 保护整个以太网帧（含 VLAN 标签），且通常由硬件在 PHY/MAC 层线速完成，几乎零性能损失、零延迟增加。

典型用途：数据中心互联、园区骨干、专线 / 波分链路加密、以及本文第五章将讨论的 Secure Networks 与 Cloud Edge 场景。

精妙类比

IPsec 是快递包裹，MACsec 是加密专线管道

IPsec：你把信装进一个新信封（隧道封装），写上新地址寄出去。安全，但每个包裹都要重新打包 → 有开销、有 MTU 损耗。

MACsec：不打包。而是把整条运输管道本身变成不透明的，任何东西进去就自动加密、出来自动解密。

代价是：管道只覆盖一段（点到点链路）。 所以两者不是替代关系——MACsec 保「一段链路」，IPsec 保「端到端路径」， Cisco 8000 系列的价值在于两者都做，且都量子安全。

配置全解（Slide 46）

! ---------- ① 定义 EAP 方法：使用 TLS + PKI 信任点 ----------
eap profile EAP-PROFILE
 method tls
 pki-trustpoint name
 exit

! ---------- ② 定义 802.1X 凭据（作为 supplicant 时使用）----------
dot1x credentials DOT1X-CREDS
 username <username>
 pki-trustpoint <name>
!
! ---------- ③ 全局：TLS 版本与 PQC 开关 ----------
access-session tls-version all
access-session pqc-type pqc        <-- 启用 EAP-TLS 的 ML-KEM 算法
!
! ---------- ④ 接口下启用 MACsec 与双向 802.1X ----------
interface <interface-id>
 macsec
 authentication periodic
 authentication timer reauthenticate interval
 access-session host-mode multi-domain
 access-session closed
 access-session port-control auto
 dot1x pae both                    <-- 同时作为认证方与被认证方
 dot1x credentials profile
 dot1x authenticator eap profile <name>
 dot1x supplicant eap profile <name>
 service-policy type control subscriber <control-policy name>
!

注：dot1x credentials profile 一行在原始材料（Slide 46）中即以此形式呈现，实际语法应为 dot1x credentials <凭据名称>（即上文定义的 DOT1X-CREDS）。幻灯片页脚亦标注 “Some CLI implementation and show outputs may change”， 请以对应 XE 版本的官方配置指南为准。

配置项	作用	为什么这行不能省
`eap profile / method tls`	指定 EAP 使用 TLS 方法	只有 EAP-TLS 才能承载 ML-KEM 混合密钥交换；EAP-MD5 / PEAP 等无此能力
`pki-trustpoint`	绑定证书信任点	证书化 MACsec 的前提。这是替代手工 PSK 的关键，带来可吊销、可自动轮换的运维能力
`access-session tls-version all`	允许全部 TLS 版本	ML-KEM 混合 KEX 依赖 TLS 1.3；此配置确保 1.3 可被协商
`access-session pqc-type pqc`	为 EAP-TLS 启用 PQC ML-KEM 算法	整段配置的灵魂。幻灯片原注：“Enables PQC ML-KEM algorithm for EAP-TLS”。缺此行 → MACsec 依然工作，但量子脆弱
`dot1x pae both`	PAE = Port Access Entity 双角色	路由器对路由器场景下，双方互相认证（不像交换机-终端的单向模型），故需同时具备两种角色
`authentication periodic` + `reauthenticate interval`	周期性重认证	密钥新鲜度机制。定期重跑 EAP-TLS → 定期刷新 MSK/CAK/SAK，限制单次密钥泄露的影响窗口
`access-session closed`	认证前端口关闭	Fail-close 安全姿态：认证未通过则不放行任何流量，而非降级为明文

验证输出解读

Router# show dot1x interface Te0/1/1 detail

Dot1x Info for TenGigabitEthernet0/1/1
PAE                       = BOTH            <-- 双角色已生效
QuietPeriod               = 60
ServerTimeout             = 0
SuppTimeout               = 30
ReAuthMax                 = 2
MaxReq                    = 2
TxPeriod                  = 30
EAP profile               = EAP-PROFILE

Dot1x Info for PAE = SUPPLICANT
StartPeriod               = 30
AuthPeriod                = 30
HeldPeriod                = 60
MaxStart                  = 3
Credentials profile       = DOT1X-CREDS

Dot1x Authenticator Client List
  EAP Method            = TLS         <-- 确认使用 EAP-TLS
  Supplicant            = 78bc.1a60.d28a
  Session ID            = 000000000000000C11F60339
  Auth SM State         = AUTHENTICATED  <-- 认证成功
  Auth BEND SM State    = IDLE

Dot1x Supplicant Client List

运维提示：show dot1x interface ... detail 可以确认「EAP 方法是 TLS」与「认证状态已通过」，但要确认该次 TLS 握手是否真的使用了 ML-KEM，需结合 access-session pqc-type 的配置状态与相应版本的 access-session 验证命令。

这是一个通用规律，值得单独记住： 在 PQC 迁移中，「功能正常」与「量子安全」是两个独立的验证维度。前者看 UP/DOWN，后者必须找到明确标注 PQC/ML-KEM 的字段。

2.7 落地四：SSH —— 别忘了那个你每天都在用的入口

Socratic Question 14

你花了大量精力让业务流量量子安全。但你每天用 SSH 登录设备、敲下 enable 密码的那条会话——它被录下来了吗？如果被录下来，未来解密出来的是什么？

答案让人不太舒服：解密出来的是你的运维密码、配置全文、以及你贴进终端的任何密钥材料。 SSH 会话是 HNDL 攻击价值密度最高的目标之一—— 因为一条 SSH 录像的价值，可能等于全网的控制权。

BRKXAR-2027 Slide 47 的配置极为简洁，但命名规则里藏着信息：

! 客户端方向（本设备 SSH 到别处）
ip ssh client algorithm kex <algorithm-list>

! 服务端方向（别处 SSH 到本设备）
ip ssh server algorithm kex <algorithm-list>

! 新增的三个 KEX 算法选项：
!   mlkem768nistp256-sha256
!   mlkem1024nistp384-sha384
!   mlkem768x25519-sha256

Router# show ip ssh
SSH Enabled - version 2.0
<<< output removed for brevity >>>

KEX Algorithms: mlkem1024nistp384-sha384, mlkem768nistp256-sha256,
                mlkem768x25519-sha256

<<< output removed for brevity >>>

第一性原理拆解：从算法名字读出整个混合结构

这三个算法名不是随机字符串，它们是自描述的（self-describing）。以 mlkem768nistp256-sha256 为例，拆成三段：

mlkem768 → PQC 组件：ML-KEM Level 3
nistp256 → 传统组件：NIST P-256 椭圆曲线（ECDH）
-sha256 → 用于密钥派生的哈希函数

看到了吗？名字本身就证明了这是混合方案。 每一个算法名里都同时包含一个 PQC 组件和一个传统椭圆曲线组件—— 这正是白皮书所述 SSH 草案的设计： “uses Elliptic Curve and ML-KEM schemes as key exchange methods with the goal of creating a discrete algorithm problem that is computationally impossible for hackers to crack, even using quantum computers.”

三个选项对应三种取舍：

mlkem768nistp256-sha256 — 平衡型，NIST 曲线，兼容性最好
mlkem1024nistp384-sha384 — 最高强度型，全线 Level 5 对齐（CNSA 2.0 风格）
mlkem768x25519-sha256 — 性能型，X25519 曲线运算更快、实现更抗侧信道

精准定义

KEX（Key Exchange）算法协商

SSH 连接建立的第一步，客户端与服务端交换各自支持的 KEX 算法列表， 按顺序选出双方共同支持的第一个。

这个「按顺序」有安全含义： show ip ssh 输出中的算法顺序即优先级。上例中 mlkem1024nistp384-sha384 排在最前，意味着优先协商最高强度。

精妙类比

两人见面前先对语言清单

你和对方各自报出「我会说的语言」列表，然后挑第一个双方都会的开始交谈。

安全隐患在哪？如果你的列表里还留着「明语」（弱算法），而对方只会明语——你就降级了。

所以 PQC 加固 SSH 的完整动作是两步： ① 把 PQC 算法加进列表且排在前面； ② 把纯传统算法从列表里移除（在兼容性允许的前提下）。只做第一步，攻击者仍可通过降级攻击迫使你退回。

给安全架构师的一条具体建议： 把「SSH KEX 算法列表」纳入配置基线合规检查（如通过 NETCONF/YANG 或 show ip ssh 巡检）。

理由：SSH 加固通常是成本最低、见效最快的 PQC 动作之一—— 它只需一条配置命令，不需要对端业务系统改造（只需运维终端支持），却直接保护了 HNDL 价值密度最高的目标。 在制定迁移路线图时，这应该是「快速见效」象限里的第一项。

2.8 落地五：SD-WAN 三平面 —— 为什么数据面「一个字都不用改」？

Socratic Question 15

SD-WAN 有管理面、控制面、数据面三层。如果我要让 SD-WAN 量子安全，是不是三层都要大改？如果有一层不用改，是哪一层，为什么？

BRKXAR-2027 Slide 48（标注 Coming XE 26.2.1）给出的答案，是对第一章 1.3 节结论的完美闭环验证：

平面	协议基础	PQC 改造方式	为什么这样改
管理平面 Edge ↔ SD-WAN Manager	标准化 TLS	IETF draft「Hybrid key exchange in TLS 1.3」 `DH/ECDH + PQC (ML-KEM)`	管理面承载配置、模板、策略下发——泄露即等于泄露全网架构与策略。混合 KEX 保证 FIPS 合规与量子安全并存
控制平面 Edge ↔ Controller	标准化 IKEv2 / IPsec	RFC 9370 Multiple Key Exchanges in IKEv2 `IKEv2 with DH/ECDH + PQC (ML-KEM)`	控制面承载 OMP 路由信息、TLOC、加密密钥分发。它是整个 overlay 的信任中枢，必须优先加固
数据平面 Edge ↔ Edge	IPsec ESP	无需改动继续使用 AES-GCM-256	因为对称加密本身量子安全。数据面的量子安全性，是通过「控制面用 PQC 分发密钥」间接获得的 —— 完美对应第一章 1.3 节的推论

这张表值得反复看，因为它是整个 PQC 工程哲学的缩影：

改造范围 = 「所有依赖公钥密码建立信任的地方」，而不是「所有加密的地方」。

识别出这个精确的边界，就把一场看似要「重做整个网络加密体系」的浩大工程，压缩成了「升级握手协议 + 更新固件签名机制」的可控项目。 这就是第一性原理带来的实际价值：不是让方案更炫，而是让工程量少一个数量级。

2.9 全栈 PQC 能力矩阵：一页看清覆盖版图

把 2.1 – 2.8 的全部内容压缩成一张验收清单。 建议将此表直接用作 PQC 相关设备的采购问询表与迁移检查表。

信任层	能力项	算法 / 标准	关键配置或验证点	状态
① 硬件信任根	PQC Secure Boot — Microloader 验 Bootloader	LMS RFC 8554 / NIST SP 800-208	硬件固化，不可配置。设备选型时确认	8000 系列内建
① 硬件信任根	PQC Secure Boot — Bootloader 验 OS、OS 验应用	ML-DSA-87 FIPS 204	随镜像签名机制生效	8000 系列内建
② 设备身份	SUDI 设备唯一身份、安全存储、RNG	X.509v3 · RSA / ECDSA · NIST SP 800-90A/B	Trust Anchor module（TAm）	详见第三章
③ 数据加密	IKEv2 IPsec	ML-KEM FIPS 203 RFC 9370 / 9242	`pqc mlkem768 optional` 验：`show crypto ikev2 sa detailed` → PQC Key Exchange 字段	XE 26.1.1
	DMVPN	同上（mGRE + NHRP 之下）	配置同 IKEv2 IPsec；示例用 `mlkem768 optional`	XE 26.1.1
	FlexVPN / IKEv2 CLB	同上	配置同 IKEv2 IPsec；示例用 `mlkem1024`（严格）	XE 26.1.1
	MACsec（LAN / WAN）线速加密	ML-KEM via EAP-TLS IEEE 802.1AE / RFC 9190 / TLS 1.3	`access-session pqc-type pqc` `dot1x pae both` + `macsec`	XE 26.1.1
④ 管理与控制	SSH	ML-KEM + ECDH 混合 KEX	`ip ssh server algorithm kex mlkem1024nistp384-sha384 ...` 验：`show ip ssh`	XE 26.1.1
	SD-WAN 管理面	TLS 1.3 Hybrid KEX（IETF draft）	Edge ↔ SD-WAN Manager	XE 26.2.1
	SD-WAN 控制面	IKEv2 + RFC 9370	Edge ↔ Controller	XE 26.2.1
	SD-WAN 数据面	AES-GCM-256（不变）	无需配置——对称算法本已量子安全	本已安全

哪些型号具备 PQC 能力？

根据 BRKXAR-2027 各型号页与三份 Cheat Sheet，PQC 能力在新一代（G2）全系列中是基线配置，而非高端选配：

8100 系列小型分支

PQC IPsec / SD-WAN
PQC Secure Boot

Cheat Sheet 中每一个型号（C8130-G2 至 C8161-G2）的 Product Highlights 都明确列出「Post Quantum Cryptography — NIST PQC based Q-Safe encryption」。

8200 / 8300 系列中大型分支

PQC IPsec / MACsec / SD-WAN
PQC Secure Boot

Cheat Sheet 标注「PQC Capable — Quantum-safe solution: IPsec, MACsec, SSH, TLS」。注意：从 8200 起，MACsec 支持全部内建端口（LAN/WAN MACsec on all FPGE）。

8650 100G 数据中心

Full-stack PQC

Slide 8 的四项并列：NIST 合规（FIPS-203）PQC IPsec VPN、 Quantum-safe MACsec with EAP-TLS、PQC SD-WAN、PQC Secure Boot。 在整份材料中，「Full-stack PQC」这一表述仅出现于此（Slide 8）。

回到本章开头那个苏格拉底问题的答案： 判断一台设备是否「真的支持 PQC」，只需问三个问题——

它的启动链用什么算法验签？（若答不出 LMS / ML-DSA-87 → 半栈）
它的 MACsec 密钥从哪来？（若答「手工 PSK」→ 可用但不可规模化；若答「EAP-TLS with ML-KEM」→ 全栈）
它的 SSH 与管理面协商用什么 KEX？（若仍是纯 ECDH → 你的运维通道正在被录像）

这三个问题，构成了「Full-Stack」与「PQC-washing」之间的分界线。

第二章金句

「支持 PQC」是一个营销声明，「找不到任何一处裸用 RSA 的关键路径」才是一个工程结论。全栈的意义，不在于覆盖得多，而在于没有留下那个最省事的入口。

第三章 · Chapter 03

Cisco Trustworthy：在讨论加密之前，先讨论「这台设备值不值得信」

第二章我们把 PQC 讲透了。但有一个问题一直悬在空中没有回答—— 所有这些加密，都是由一台设备上的软件执行的。那么，谁来保证这个软件是真的？ 本章要论证的是：Trustworthy 不是 PQC 的补充，而是 PQC 的前提。

3.1 第十六问：如果设备内核被换了，加密还有意义吗？

Socratic Question 16

假设你的路由器完美部署了 ML-KEM-1024，隧道显示「Quantum-safe」。但攻击者往这台设备里刷入了一个被篡改过的 IOS XE 镜像——它会正确地执行 PQC 握手，只是额外把每一个会话密钥都发到一个境外地址。

请问：你的 show crypto ikev2 sa detailed 会看出任何异常吗？

不会。输出会显示得完美无缺。因为是这台被篡改的设备自己在告诉你「我是安全的」。

第一性原理拆解：一切安全声明，都需要一个「声明者」

这是逻辑学上的一个基本困境： 你无法用一个系统自身的输出，来证明这个系统没有被篡改。 因为如果它被篡改了，它的输出也就不可信了。

Cisco Trustworthy 数据手册开篇就精准指出了这个攻击面： “Today's sophisticated cyberattacks increasingly seek to compromise the network infrastructure by attacking devices like routers and switches. By doing so, attackers can eavesdrop on sensitive communications, steal or manipulate data, and launch attacks against other parts of the network. This includes advanced persistent threats that modify the hardware or software of network devices.”

然后是最刺骨的一句： “These threats can go unnoticed for months, or even years, inflicting devastating damage.”
—— 数月甚至数年不被发现。

推论：加密解决的是「链路上的窃听者」； Trustworthy 解决的是「链路两端的窃听者」。 后者不解决，前者形同虚设。

精准定义

Cisco Trustworthy Technologies

数据手册定义： “an integrated set of policies, processes, and technologies to help ensure code running on Cisco hardware is authentic and unmodified, with unique device identity and validation of all levels of software, establishing a chain of trust for the entire system.”

注意这个定义里的三个要素：①「真实且未被修改」的代码 ②「唯一的设备身份」③ 对「所有层级软件」的验证—— 三者共同建立起覆盖整个系统的信任链。

精妙类比

你怎么知道保安是真保安？

你把公司大门交给一位穿制服的保安。他每天报告「一切正常」。

但如果穿制服的那个人，在某个夜里被换成了小偷呢？ 他会一样认真地站在门口，一样每天报告「一切正常」—— 甚至比真保安更认真，因为他需要你不去检查。

Trustworthy 要解决的，就是「保安的入职验证」问题： 他的工牌是真的吗？（SUDI）他今天穿的制服和入职那天是同一件吗？（镜像签名）有没有人在他上岗前偷偷改过他的工作手册？（Secure Boot）

3.2 第十七问：信任链必须有一个「不可被验证的起点」——为什么？

Socratic Question 17

如果每一段代码都要被上一段代码验证，那第一段代码由谁验证？如果说「由更前面的代码验证」——那再往前呢？这个递归会在哪里停下来？

这是整个可信计算领域最优美的一个问题。答案是： 递归必须停在一个「无法被软件验证、只能被物理保护」的点上。 这个点，就叫做 Root of Trust（信任根）。

第一性原理拆解：从「验证」到「不可篡改」的范式切换

数据手册对信任链的定义是： “A chain of trust exists when the integrity of each element of code on a system is validated before that piece of code is allowed to run. A chain of trust starts with a root of trust element. The root of trust validates the next element in the chain (usually firmware) before it is allowed to start, and so on.”

关键在于信任根本身不被验证——它靠物理不可篡改性来保证。数据手册对 Cisco Secure Boot 的描述精确到了这一点： “Cisco hardware-anchored secure boot protects the microloader (the first piece of code that boots) in tamper-resistant hardware, establishing a root of trust that helps prevent Cisco network devices from executing tainted network software.”

请注意这里两个词的分工：

hardware-anchored（硬件锚定） —— 微加载器不在可刷写的 Flash 里，而在抗篡改硬件中。
the first piece of code that boots（第一段执行的代码） —— 它是整条链的第一环，必须最小、最简、最不可变。

这解释了 2.1 节末尾那个「为什么 Microloader 用 LMS 而不是 ML-DSA」的谜题： 因为信任根是一次烧死、终身不可换的。你必须为它选择数学假设最保守、最不可能在未来被证伪的算法—— 而基于哈希的 LMS，其安全性只归结为「哈希函数的单向性与抗第二原像性」—— 这是密码学中被检验得最久、也最少被推翻的一类假设。

对可以升级的东西用高效算法，对永不可换的东西用最保守算法。 这是一个教科书级的风险分散决策。

精准定义

Root of Trust（信任根）

信任链中唯一不接受验证的元素。它的可信性不来自密码学验证，而来自物理特性：固化在抗篡改硬件中、只读、无法通过任何软件手段改写。

它的作用是把「我无法验证一切」这个无解问题，转化为「我只需要物理保护一个极小的东西」这个可解的工程问题。

精妙类比

国际千克原器

过去全世界的「1 千克」，都要追溯到巴黎郊外一个保险库里的那一块铂铱合金圆柱。

你怎么知道它真的是 1 千克？你不知道，也不需要知道——它「就是」1 千克，因为定义如此。 全世界所有的秤，都是通过一级一级的校准链，最终追溯到它。

它的可信性不来自「被检验」，而来自「被严密物理保护 + 全球共同承认」。 Microloader 在硅片里的地位，与它完全一致。

而这也揭示了信任链最大的风险：如果那块金属被人偷偷换掉，全世界的秤都会一起错——而且没人能发现。 这就是为什么它必须放在抗篡改硬件里。

3.3 镜像签名（Image Signing）：两步创造一个「防伪水印」

Socratic Question 18

一个 IOS XE 镜像有好几个 GB。要验证它「没被改过一个字节」，难道要把整个原始镜像也存在设备里做逐字节比对吗？如果不用——那用什么？

第一性原理拆解：把「巨大」压缩成「唯一」

数据手册的描述极为精确，我们把它拆成两步：

哈希（Hashing）： “a hashing algorithm, similar to a checksum, is used to compute a hash value of the block of code.” —— 把几 GB 的镜像压缩成一个固定长度的指纹。
关键属性：输入改动一个比特，输出指纹完全不同（雪崩效应）。
签名（Signing）： “The hash is then encrypted with a Cisco private key, resulting in a digital signature that is attached to and delivered with the image.” —— 用只有 Cisco 拥有的私钥加密这个指纹。

为什么这两步组合就足够了？

攻击者可以修改镜像 → 但指纹会变 → 与签名中的指纹不符 → 被发现。
攻击者可以重新计算新指纹 → 但无法用 Cisco 私钥加密它 → 签名无效 → 被发现。
攻击者可以连签名一起替换 → 但设备用 Cisco 公钥解密时会失败 → 被发现。

整个体系的安全性，最终压缩到一个点上：Cisco 私钥的保密性。 —— 而这也正是量子威胁的攻击点：如果这个私钥是 RSA 的，CRQC 就能从公钥反推出私钥，然后合法地签署任意恶意镜像。

这就是为什么 CNSA 2.0 把「PQC image signing and verification」的建议采纳日期定在 2025 年—— 比网络设备本身还早一年。因为签名体系一旦被攻破，所有其他防护都失去意义。

精准定义

Image Signing / 运行时验签

数据手册特别补充了一句常被忽略的话： “Signed images may be checked at runtime to verify that the software has not been modified.”

注意「at runtime」：验签不只发生在启动那一刻， 运行期间也可以复查。这抵御的是一类特定攻击——启动时用合法镜像通过验证，运行中再向内存注入篡改。

精妙类比

公证处的火漆封印

你要寄一份 500 页的合同。收件人怎么确认一页都没被换？

笨办法：他手里也留一份 500 页原件，逐页比对。（= 存储原始镜像，不现实）

聪明办法：公证处读完全部 500 页，写下一句只有这份合同才会得出的摘要（哈希），然后用公证处独有的火漆印章盖在摘要上（私钥签名）。

收件人只需：① 自己读一遍算出摘要 ② 确认火漆印章是真的。 500 页的问题，被压缩成了一枚印章的问题。

而量子计算做的事，是让人能伪造那枚火漆印章。

3.4 硬件锚定安全启动：六步全流程

现在我们把 Trustworthy 数据手册 Figure 1 与 BRKXAR-2027 Slide 30（PQC Secure Boot） 合并成一张图。这是本章最重要的一张图—— 因为它同时展示了「经典 Trustworthy 流程」与「PQC 时代的算法替换」。

请特别注意第 5 步的顺序设计，这是一个极容易被忽略但极精妙的细节。

数据手册明确说：硬件真实性检查 “runs only after the secure boot process has been completed and the software has been verified to be trusted.”

为什么不先验硬件？因为验证硬件这件事，本身是由软件执行的。如果软件不可信，那么「硬件验证通过」这个结论也不可信—— 一个恶意软件当然会告诉你「硬件是正品」。

所以顺序必须是：物理保护的信任根 → 验证软件 → 用可信软件验证硬件。 这个顺序不是随意的，而是逻辑上唯一正确的顺序。

3.5 Trust Anchor module（TAm）：一颗芯片里的四项服务

Socratic Question 19

如果我用一个软件模块来存储密钥、生成随机数、保管设备身份证书——功能上完全一样。为什么 Cisco 非要为此单独做一颗物理芯片？多花的成本买到了什么？

第一性原理拆解：软件的边界 vs 硅片的边界

软件模块的隔离边界是逻辑的——由操作系统的内存保护、权限模型来维持。一旦攻击者获得内核权限，所有逻辑边界同时消失。

物理芯片的隔离边界是物理的——即使攻击者完全控制了主 CPU，他也只能通过芯片预定义的接口与它对话。 他能请求「用私钥签个名」，但拿不到私钥本身。

数据手册对 TAm 的定义强调了这一点： “This proprietary, tamper-resistant chip is found in many Cisco products and features nonvolatile secure storage, Secure Unique Device Identifier, and crypto services, including random number generation (RNG), secure storage, key management, and crypto services to the running OS and applications.”

结论：多花的成本，买到的是「即使 OS 被完全攻陷，密钥依然不泄露」这个能力。

① SUDI — 不可变的设备身份

X.509v3 证书，包含产品标识（PID）与序列号，在制造时植入，并链接到一个公开可识别的根 CA。

用途：configuration、security、auditing、management 中作为不可更改的身份。

技术细节：凭据可基于 RSA 或 ECDSA；证书、关联密钥对及整条证书链都存储在抗篡改的 TAm 芯片内。

② 高安全存储 — Highly Secure Storage

为设备的密钥、口令、客户凭据及其他关键安全信息提供高安全存储。

数据手册强调的优势： “the ability to store private encryption keys and passwords for even greater security.”

灵活性：也支持在 TAm 之外分配安全存储（“Allocating secure storage outside the Trust Anchor module is also possible”），以应对容量或性能需求。

③ RNG — 随机数生成与熵源

数据手册在此处的论述值得完整引用： “Strong random number generation (RNG) is at the core of encryption, while weak RNG can undermine the entire encryption system.”

为什么至关重要：RNG 参与创建加密密钥、建立用户与网站间的高安全通信、重置邮箱密码。 “Without assured randomness, an attacker can predict what the system will generate and undermine the algorithm.”

合规：符合 NIST 规范，提供 NIST SP 800-90A 与 B 可认证的 RNG，从 TAm 内部的真随机源提取熵。

④ 加密服务与密钥管理

TAm 可生成密钥对，用于客户自控证书——通常称为 LSC（Locally Significant Certificate）或 LDevID（Local Device Identity）证书。

SUDI 支持的非对称操作：加密、解密、签名、验签，允许传入待处理的数据 → 使设备的远程认证成为可能。

业务价值（原文列举）：为资产管理、provisioning、版本可见性、服务权益（service entitlement）、质量反馈、库存管理提供准确、一致、电子化的产品识别。

TAm 支持的客户身份功能（数据手册明确列举）

功能	说明	实际场景价值（推导）
Retrieval of LDevID RSA public keys	获取本地设备身份的 RSA 公钥	使企业能建立自有 PKI 体系，不完全依赖厂商证书链
Authentication with a CA before LSC enrollment	LSC 注册前先与 CA 完成认证	防止未授权设备获取企业证书——注册前先证明「你是正品思科设备」
Zero-touch provisioning authentication	零接触部署时的认证	分支设备开箱上电即可安全入网，无需现场工程师。这是大规模分支部署的成本关键
Secure boot posture assessment	安全启动态势评估	使管理平台能远程确认某台设备的启动链完整性状态，纳入合规审计

3.6 SUDI 深入：「私钥永不导出」为什么是整个体系的基石？

Socratic Question 20

如果一台设备的身份证书可以被复制，会发生什么？零接触部署（ZTP）在这种情况下还成立吗？

不成立——而且后果远比想象严重。 ZTP 的全部逻辑基础是「设备能自证身份」。 如果身份可复制，攻击者只需克隆一个身份，就能让一台完全受他控制的伪造设备，自动从你的 SD-WAN Manager 上拉取全套配置、证书、密钥和策略——合法地加入你的网络。

第一性原理拆解：三重绑定，让克隆在数学上不可能

数据手册用一句话说明了 SUDI 的防克隆机制，这句话需要逐段拆解： “Furthermore, the key pair is cryptographically-bound to a specific Trust Anchor chip and the private key is never exported. This feature makes cloning or spoofing the identity information virtually impossible.”

三重防护：

制造时植入（implemented at manufacturing） —— 身份在出厂前就已固化，不是后期配置的，因此无法通过任何配置手段更改。
密码学绑定到特定芯片 —— 密钥对与这一颗硅片绑定。把证书文件拷到另一台设备上，它也无法使用，因为对应的私钥不在那颗芯片里。
私钥永不导出 —— 这是最关键的一条。 私钥从生成到销毁，从未离开芯片。签名操作是「把数据送进芯片、把签名取出来」， 私钥本身没有任何合法的出口。

推论：要伪造一台设备的身份，攻击者必须物理破解那颗抗篡改芯片—— 这已经不是网络攻击，而是实验室级别的硬件攻击，成本、风险和可规模化程度都完全不同。

安全工程的本质，正是把攻击者的成本推到不可承受的量级。

精准定义

SUDI 与 LDevID / LSC 的分工

SUDI（Secure Unique Device Identifier）： 厂商赋予的身份，回答「这是一台真的思科设备吗」。制造时植入，不可变。

LDevID / LSC： 企业赋予的身份，回答「这台设备是我们公司的哪一台、属于哪个部门、有什么权限」。由企业自己的 CA 签发，可轮换、可吊销。

两者的接力点：设备先用 SUDI 向企业 CA 证明「我是正品」， CA 才为它签发 LSC。SUDI 是获得 LSC 的入场券。

精妙类比

出生证明 vs 员工工牌

SUDI = 出生证明：在医院（工厂）出生时就开具，终身不变，无法伪造（因为登记在国家系统里，链接到公开可查的根）。

LSC / LDevID = 公司工牌：入职时公司发的，写着你的部门、工位、门禁权限。离职可以收回，丢了可以重发。

入职流程是什么？你拿着出生证明去 HR， HR 核验它是真的，才给你发工牌。 ——这正是「Authentication with a CA before LSC enrollment」的含义。

而「私钥永不导出」相当于：你的出生证明上有一枚只有你的手指能激活的生物印记。别人抄走证明上的所有文字，也无法激活它。

3.7 运行时防御（Runtime Defenses）：启动之后的战场

Socratic Question 21

Secure Boot 保证了启动时加载的是正确代码。那么，运行了三个月之后，攻击者通过一个缓冲区溢出漏洞向正在运行的进程注入了恶意代码——Secure Boot 能拦住吗？

不能。Secure Boot 是时间点防护（启动那一刻），而代码注入是运行期攻击。这就是 Runtime Defenses 存在的原因。

第一性原理拆解：让漏洞「存在但不可利用」

数据手册定义： “Runtime defenses target injection attacks of malicious code into running software.” 并明确列出三种手段，且强调它们是互补的（complementary）—— “you can implement these individually or deploy several runtime defenses together.”

核心思路的转变值得注意： Runtime Defenses 并不试图消灭漏洞（那是代码审计与补丁的工作），而是让漏洞变得无法被稳定利用。数据手册的表述是： “Makes it harder or impossible for attackers to exploit vulnerabilities in running software.”

这是一个非常成熟的安全哲学：接受「漏洞必然存在」这个现实，然后把工程重点从「零漏洞」（不可能）转向「零可利用性」（可实现）。

技术	全称	防御原理（第一性原理解读）	类比
ASLR	Address Space Layout Randomization 地址空间布局随机化	攻击者要跳转到注入的恶意代码，必须知道它在内存的哪个地址。ASLR 让每次启动时程序各段的内存地址随机变化 → 攻击者的硬编码地址失效	每天把大楼里所有房间号重新打乱一次。小偷即使知道「财务室有钱」，也不知道今天财务室在哪
BOSC	Built-in Object Size Checking 内建对象大小检查	缓冲区溢出的本质是「往一个能装 10 个字节的容器里塞了 100 个字节」。BOSC 在操作前主动检查目标对象的实际大小 → 溢出在发生前被拒绝	快递柜在放件前先量一下包裹尺寸。放不进去就直接拒收，而不是硬塞导致把隔壁柜门撑坏
X-space	Executable Space Protection 可执行空间保护	把内存区域严格区分为「可写但不可执行」与「可执行但不可写」。攻击者可以把恶意代码写进数据区，但那片区域根本不允许执行	图书馆规定：阅览区不能带笔，写作区不能取书。你可以在写作区写一本假书，但没人会在写作区读书

3.8 不实施 Trustworthy 的代价，以及供应链这条隐形战线

Socratic Question 22

「缺少硬件锚定的信任根」——这听起来像是一个理论风险。有实际发生过的案例吗？

数据手册对此的回答毫不含糊： “The lack of a hardware-anchored root of trust has resulted in known hacks.” —— 已经导致了已知的入侵事件。 随后列出了具体的攻击路径：

展开：不实施 Trustworthy 的具体攻击路径与后果（数据手册原文梳理）

攻击手法

“Third parties can tamper with BIOS, boot loader, or ROM monitor (ROMMON) boot code to:”

加载被修改的软件镜像（load modified software images）
绕过硬件、真实性与许可检查（bypass hardware, authenticity, and licensing checks）
执行带有恶意意图的额外功能（perform additional functions with malicious intent）

后续后果

“Tampered code can also result in:”

数据篡改（data manipulation）
数据窃取（data theft）
提供发起攻击的平台，包括拒绝服务攻击（provide a platform to launch attacks, including denial of service）

第三点最值得警惕：被攻陷的网络设备不只是受害者，它会变成攻击者在你网络内部的合法据点—— 一个拥有网络最高可见性、被所有安全策略信任、且极少被端点检测工具覆盖的据点。

Cisco 的结论

“Cisco trustworthy technologies help close these potential security gaps.”

供应链：在设备到达你手上之前的那段旅程

第一性原理拆解：信任链必须延伸到工厂之前

我们花了整章讨论「设备启动后的信任」。但有一个更早的问题： 如果设备在从工厂到你机房的路上就被动了手脚呢？

数据手册对此有专门的段落： “Cisco also works with our suppliers as well as our manufacturing and distribution partners to address supply chain risks through our Value Chain Security program.”

该项目采用多层安全方法（multi-layered approach），使用三类手段来应对三类威胁：

手段	应对的威胁
Physical security practices 物理安全实践	Taint（植入/污染） Counterfeit（假冒） Misuse of intellectual property（知识产权滥用）
Logical security processes 逻辑安全流程
Security technology 安全技术

并且是全生命周期的： “Our comprehensive program continually assesses, monitors, and improves security across the entire lifecycle of our solutions.”

这一节的意义在于：Trustworthy 不只是硅片里的技术，它是「policies, processes, and technologies」三者的集合—— 技术管设备上电之后，流程与策略管设备上电之前。

精准定义

Taint（污染 / 植入）

指在制造、运输、仓储或分销环节，向正品设备中植入未授权的硬件或软件成分。

它与「假冒（counterfeit）」的关键区别是： 被 taint 的设备是真品——序列号真、外观真、甚至可能连 SUDI 都真。只是内部多了一点东西。

这是最难检测的一类供应链攻击。

精妙类比

正品药盒里换了一片药

假冒（counterfeit）：整盒都是假药。防线是查防伪码——相对容易。

污染（taint）：盒子是真的，说明书是真的，批号能在官网查到，29 片药都是真的——只有第 30 片被换了。

怎么防？只有一条路： 从原料到药房的每一个环节，都必须有人对完整性负责且可追溯。 这就是 Value Chain Security 存在的理由—— 它防的不是「你收到的东西是不是真的」，而是「真的东西里有没有多出来的东西」。

3.9 Trustworthy 与 PQC 的交汇点：两条线在哪里合并？

现在把第二章和第三章拼在一起。你会发现， Cisco 8000 系列的 PQC Secure Boot，正是这两条技术线的交汇产物。

Trustworthy 能力	经典实现（上一代）	PQC 时代的实现（8000 系列）	为什么必须改
Microloader 验 Bootloader	LDWM（Lamport–Diffie–Winternitz–Merkle 哈希签名， LMS 标准化之前的同族早期方案）白皮书原文：“such as LDWM for Secure Boot”	LMS（RFC 8554 / NIST SP 800-208）	符合 CNSA 2.0 对固件签名的明确要求。基于哈希，数学假设最保守，适合永不可换的信任根
Bootloader 验 OS	RSA / ECDSA 签名	ML-DSA-87（FIPS 204）	RSA 签名可被 CRQC 伪造 → 攻击者能签署恶意镜像并通过验证。这是整个信任链最致命的单点
OS 验应用镜像	RSA / ECDSA 签名	ML-DSA-87（FIPS 204）	IOS XE 支持 Native Apps / Container Apps / VM 托管（见第四章），应用层也必须在信任链内
设备身份 SUDI	X.509v3，RSA 或 ECDSA	白皮书指出：“Evolving standards here include unique device identity certificates”； “Industry availability for PQC-capable hardware components such as CPUs and TPMs is also evolving”	身份证书若被量子伪造 → 设备身份可被克隆 → ZTP 与远程认证失效。此领域标准仍在演进中
RNG / 熵源	NIST SP 800-90A/B 认证的真随机源	无需更改	真随机源不依赖任何数学难题假设 → 本质上量子安全。这是 TAm 设计前瞻性的体现
安全存储	抗篡改芯片内的非易失存储	无需更改	物理隔离与数学难题无关 → 量子计算机撬不开一颗物理芯片
Runtime Defenses	ASLR / BOSC / X-space	无需更改	内存布局随机化与量子计算无关。再次印证：只有依赖公钥密码的环节才需要 PQC 改造

这张表揭示了一个贯穿全文的规律，值得作为整篇文章的核心方法论记住：

「哪些东西需要 PQC 改造？」有一个极其简洁的判据——
凡是安全性建立在「某个数学问题很难」之上的，都需要改造；
凡是安全性建立在「物理特性」或「无结构随机性」之上的，都不需要。

对称加密（AES）、哈希（加长后）、真随机源、抗篡改芯片、内存随机化 → 不需要改。
密钥交换（DH/ECDH）、数字签名（RSA/ECDSA）、身份证书 → 必须改。

掌握这一条判据，你就能独立判断任何一个安全组件是否需要进入 PQC 迁移清单—— 而不必依赖任何厂商的说法。

白皮书那句「no hardware exists today」的完整含义

让我们回到第一章 1.8 节留下的那个悬念。白皮书原文是：

“While many Cisco devices already include critical quantum-safe protections (such as LDWM for Secure Boot), no hardware exists today that is compliant with CNSA 2.0 algorithms. It is, therefore, recommended that organizations consider including quantum-safe hardware into their product refresh cycles as they become available.”

这句话的三层含义：

现有设备并非毫无保护——LDWM（Lamport–Diffie–Winternitz–Merkle 哈希签名，与 LMS 同属基于哈希的签名家族，是其标准化之前的早期形态）已提供关键的量子安全保护。不必恐慌性替换。
但「完全符合 CNSA 2.0」需要新硬件——这不是软件升级能解决的，因为信任根固化在硅片里。
行动建议是「纳入刷新周期」，而非「立即全网替换」—— 这是理性的资本支出策略：在设备自然到期时，选择具备 PQC 信任根的型号。

但这里需要一个诚实的限定，否则整章的严谨性会被自己推翻： 资料中对 8000 系列的用词是 「NIST Compliant (FIPS-203)」、「PQC ready」、 「Post-Quantum Safe」——这些都不等同于「已通过 CNSA 2.0 / FIPS 认证」。

回顾第一章 1.4 节的那个成本：FIPS 认证平均需要两年以上。「实现了 NIST 标准算法」与「拿到认证证书」是两件在时间上严重错位的事。

因此本节的准确表述应当是： 8000 系列是资料中给出的、朝「CNSA 2.0 就绪硬件」方向落地的产品答案。 如果你的采购受硬性合规约束，请以设备在采购时点的实际认证状态（CMVP 证书编号、CNSA 2.0 声明）为准，而不是以「支持 PQC 算法」这句话为准。

带着这个限定，我们进入第四章：为了把 PQC 做进硅片、同时不牺牲性能，Cisco 重新设计了整颗芯片。

第三章金句

加密保护的是「你说的话」，Trustworthy 保护的是「说话的那个人」。前者被破解，你失去一段对话；后者被替换，你失去整个网络——而且你不会知道。

第四章 · Chapter 04

架构创新：为了让「更安全」不再意味着「更慢」，Cisco 重做了一颗芯片

第二、三章我们确立了「要做什么」。本章回答「凭什么能做到」—— 因为在传统架构下，这两章的要求是物理上不可能同时满足的。

4.1 第二十三问：为什么「加密更强」和「转发更快」在传统架构下是矛盾的？

Socratic Question 23

企业想要：PQC 加密 + 深度包检测 + IPS + URL 过滤 + NetFlow + QoS，同时还要 10G 线速。

请问：这些功能在一台设备里，是并行发生的，还是排队发生的？如果是排队——那么每加一个安全功能，性能会发生什么？

答案是：在通用 CPU 架构里，它们基本是排队的。每个数据包必须依次经过每一个功能模块，每一步都消耗 CPU 周期。这导致一个所有网络工程师都熟悉的痛苦现实：

第一性原理拆解：安全功能的性能税

我们可以从 BRKXAR-2027 的性能数据中反推出这个「税率」。以 C8235-G2 为例（Cheat Sheet 数据）：

启用的功能组合	吞吐量	相对纯转发的比例
纯转发（Unencrypted Traffic / CEF）	19 Gbps	100%
+ IPsec 加密	5 Gbps	约 26%
+ SD-WAN AAR（IPsec + QoS + DPI + FNF）	4 Gbps	约 21%
+ Threat Protection（100% DIA-NAT + App Aware FW + IPS + URLF + AMP）	2.4 Gbps	约 13%

这就是「安全功能的性能税」：每加一层保护，可用带宽就掉一截。

传统的解决方案只有两条，且都不理想：

方案一：买更大的设备。用性能过剩来吸收税负 → 成本与功耗爆炸。
方案二：关掉一些安全功能。为了保带宽牺牲防护 → 这是所有安全事故的开端。

Cisco 选择了第三条路：改硅片。 把这些功能从「软件里排队执行」变成「硬件里并行执行」。

这就是 BRKXAR-2027 Slide 20-21 反复强调的那句话的真正含义： “Foster security and networking convergence” —— 安全与网络的融合，不是在管理界面上融合，而是在硅片上融合。

精准定义

secure networking processor（安全网络处理器）

BRKXAR-2027 Slide 20 将其定位为 8000 系列分支与园区产品线的核心构件（数据中心线使用 Cisco Quantum Flow Processor）。

它是一个 System-on-Chip（SoC），将安全加速、网络加速、以太网控制器、流量管理器、AI/ML 引擎、信任锚 全部集成在同一颗硅片上。

核心设计目标（Slide 21 原文归纳）： Security（在线加密、PQC 就绪加密引擎、Cisco Secure Firewall 加速、AI/ML 引擎）与 Networking（集成硬件加速器、集成以太网控制器、性能定义的功耗、可编程微码）的融合。

精妙类比

安检的两种做法

传统 CPU 做法 = 机场安检串行流水线： 每位旅客依次经过身份核验 → 行李 X 光 → 金属探测 → 液体检查 → 人工复检。 每增加一道检查，队伍就变长一截。

专用芯片做法 = 全息扫描通道： 旅客正常走路通过，通道两侧的多组传感器同时完成所有检测。 再增加一种检测项目，通行速度不变——因为新增的是一组并行的传感器，不是队伍里的又一个环节。

这就是为什么 8000 系列能宣称「Up to 10x faster」而不是「10% faster」—— 它不是把队伍推快了，而是取消了排队这件事。

4.2 Secure Networking Processor 架构全解

这是 BRKXAR-2027 Slide 22 的完整架构还原。请注意其中五个「集成」（Integrated）—— 每一个都是一次「本来要外挂的东西，现在做进了硅片」。

第一性原理拆解：为什么「Programmable uCode」是这个架构最聪明的一笔？

专用硬件（ASIC）的传统困境是：快，但僵化。一旦流片，功能就固定了。要支持新协议，只能等下一代芯片——通常是 2-3 年。

而通用 CPU 的困境相反：灵活，但慢。

可编程微码（Programmable uCode）是第三条路： 硬件提供高度并行的执行单元，但「这些单元执行什么逻辑」是可以通过微码更新来改变的。

Slide 21 给出的两个价值点极其精准：

protect IP（保护知识产权） —— 功能逻辑以微码形式存在，不暴露于硅片逆向分析。
feature parity（功能对等） —— 这一点是运维视角的关键：新平台可以通过微码更新，快速达到与老平台功能完全对等，避免「新硬件跑得快但缺功能」这个所有网络工程师都痛恨的迁移陷阱。

这也是 PQC 能落地的技术前提： ML-KEM 是 2024 年才定稿的算法。如果加密引擎是硬编码的，那么支持 PQC 就必须等新一代芯片。 而「PQC ready crypto engine」的含义正是：加密引擎的算法逻辑可通过微码演进。

4.3 Dynamic Resource Provisioning：同一颗芯片，按「意图」重新分配算力

Socratic Question 24

一台部署在 MPLS CPE 场景的路由器，几乎不跑防火墙，但要处理海量转发；另一台部署在 DIA 分支的同型号路由器，要跑满 IPS 与 AMP。

同一个硬件，怎么可能对两种完全相反的负载都最优？

BRKXAR-2027 Slide 23 给出的答案是一个漂亮的设计： 让算力分配本身成为可配置项。

资源类型	缩写	承载的功能（Slide 23 原文）
Control Plane	CP	Routing / SD-WAN — 路由协议、控制器通信、管理
Packet Processor Engine	PPE	数据面转发、IPsec 加解密、QoS、NAT — 纯粹的包处理
Service Plane	SP	On-box security（NGFW / IPS）、WAN Insights、AppQoE、Voice、TE、TCPOpt/DRE、vDSP
Rx + TM	—	接收处理 + 流量管理（队列与调度）— 固定分配，不参与模板切换

这个设计的运维含义，在第六章会得到印证。 BRKXAR-2027 Slide 76 展示的命令输出中，有这样一行：

G2#sh platform software cpu alloc
CPU alloc information:
  Control plane cpu alloc: 0-1
  Data plane cpu alloc:    0,10-23
  Service plane cpu alloc: 2-9
  Template used: CLI-service_plane_heavy

看到 Template used 这一行了吗？ 这就是动态资源分配的实证——「我的意图」被固化成了一个可查询、可审计的模板名。

给架构师的实践建议：在设备上线前的设计阶段，就应该根据该站点的主导流量特征（转发为主 vs 安全检测为主）选定模板，而不是等到性能出问题再排查。模板选错，可能损失 30-50% 的有效性能。

4.4 一个数据包的生命周期，与那张「功能调用矩阵」

Socratic Question 25

一个数据包进入路由器后，究竟经历了什么？如果它需要同时被 ACL 检查、NAT 转换、加密、打标记、计入 NetFlow——这些操作的顺序是谁决定的？能改吗？

BRKXAR-2027 Slide 24 与 Slide 25 分别回答了这个问题的两个层面： 物理路径与逻辑路径。

精准定义

FIA（Feature Invocation Array，功能调用数组）

Slide 25 展示的是 IOS XE 数据面的功能调用链—— 一个数据包在 PPE 内部依次经过的功能列表。它包含了 L2/L3 Classify、IPv4 validation、ACL、QoS Classify/Police、 IPsec、NAT、Firewall、Netflow、uRPF、PBR、Forwarding、Marking、Policing、 Accounting、TCP MSS Adjust、SSLVPN、WCCP、MPLS 处理、Tunnels 等数十项功能。

可查询命令（Slide 25 原文给出）： show platform hardware qfp active interface if-name <name>

精妙类比

工厂流水线的「工序卡」

每个包进入 PPE 时，都附带一张工序卡，上面按顺序列着这个包需要经过的所有加工步骤：「先验身份 → 再查黑名单 → 打优先级标签 → 加密 → 记账 → 出货」。

为什么这张卡如此重要？ 因为工序的顺序会改变结果。「先 NAT 再 ACL」和「先 ACL 再 NAT」， 会导致完全不同的匹配结果—— 这是所有网络工程师排查「明明配了 ACL 为什么不生效」时的经典陷阱。

FIA 的价值就在于：它让这条隐形的流水线变得可见、可查、可排障。

给排障场景的实用提示： 当遇到「配置看起来正确但流量行为异常」的问题时， show platform hardware qfp active interface if-name <name> 可以显示该接口上实际生效的功能调用顺序。

这比逐条检查配置更有效——因为它展示的是硬件实际在做什么，而不是配置意图是什么。两者不一致的情况，比想象中常见。

4.5 3rd Gen QFP：8650 的 540 Gbps 从哪里来？

Socratic Question 26

540 Gbps 转发、220 Gbps IPsec——这个数量级不可能靠「更快的时钟频率」实现。那它靠什么？

靠规模化并行。Slide 26 给出的数字令人印象深刻，我们把它拆开算一遍：

224PPE 数量

× 4每 PPE 线程数

= 896并发处理线程总数

16独立加密引擎

第一性原理拆解：把「一个难题」变成「896 个简单问题」

Slide 26 列出了 3rd Gen QFP（Quantum Flow Processor）的五项关键能力：

Multi-threaded Parallel Processing — 224 个 PPE，每个 4 线程 → 896 线程。
含义：芯片可以同时处理 896 个数据包的完整功能链，而非依次处理。
Hardware Accelerated Crypto — 16 个加密引擎，各有独立资源（dedicated resources）。
「独立资源」是关键：加密引擎之间不争抢，因此加密性能可线性叠加。
Scalable Traffic Manager — 提供流队列（flow queues）支持复杂的有状态功能。
有状态功能（如防火墙会话跟踪）传统上是硬件加速的死穴，因为需要维护上下文。
Integrated L2 MACs & Mesh — 最大 240G 聚合 I/O，含 L2 MACs w/ MACsec / Interlaken & Mesh。
MACsec 在 MAC 层集成 → 这就是「线速 MACsec、零性能损失」的物理来源。
Enable 4x QFP Cascading — 支持 4 颗 QFP 级联。
240G × ... → 这才是 540 Gbps 的真正来源：不是一颗芯片变快，而是多颗协同。

数学上的印证：单颗 QFP 最大 240G 聚合 I/O，支持 4 颗级联 → 理论聚合能力远超 540 Gbps 的转发需求。 8650 的 540 Gbps 转发 / 220 Gbps IPsec，正是这套级联架构的实际交付值。

展开：3rd Gen QFP 架构组件明细（Slide 26 完整还原）

组件	功能
DRAM × 4 + DRAM Controllers	大容量表项与会话状态存储（支撑 16M 路由、32M NAT/FW 会话）
Last Level Caches	末级缓存，降低 DRAM 访问延迟
Packet Processor Engine（224 个）	包处理主力，每个 4 线程
Crypto Engine（16 个）	加密加速，各有独立资源
HW Assist：DST / FLB / PLU / RLB / ARL / TCM	专用硬件辅助单元，卸载特定查找与负载均衡运算
Pkt Buffer Mgr + GPM	包缓冲管理与全局包内存管理
sTCAM	专用三态内容寻址存储器，用于高速 ACL/分类匹配（支撑 380K ACEs）
Traffic Manager	入向：Ingress Classification, Accounting, Policing & Oversubscription Buffer 出向：Egress Buffering, Scheduling & Flow Control, Time Stamp
L2 MACs w/ MACsec / Interlaken & Mesh	集成二层 MAC 与 MACsec 引擎 → 线速 MACsec 的物理基础
PKT / xBAF 接口	芯片间互联，实现 4x QFP 级联

Cisco 8650 Secure Router：规格全解

Slide 8 完整定义了这款产品，标注 Coming XE 26.1.2。定位是 Post-Quantum Cryptography (PQC) Ready 100G Secure Router。

接口与形态

6× 100/40G QSFP28
20× 10/1G SFP+
所有端口线速 WAN MACsec（Line-rate WAN MACsec on all ports）
3RU 机架高度
搭载 3rd Gen QFP

Full-stack PQC 四项能力

NIST Compliant (FIPS-203) PQC IPsec VPN
Quantum-safe MACsec (LAN/WAN) with EAP-TLS
PQC SD-WAN
PQC Secure Boot

—— 在整份材料中，「Full-stack PQC」这一表述仅出现于此（Slide 8，参见第二章 2.9）。

High Performance · 高性能

转发	540 Gbps
IPsec	220 Gbps
SD-WAN	82 Gbps

High Scale · 高扩展

ACEs	380K
路由	16M
NAT/FW 会话	32M
SD-WAN IPsec 隧道	12K

请注意 8650 规格中一个容易被忽略但意义重大的细节：
「Line-rate WAN MACsec on all ports」——所有端口，线速。

对比第 4.1 节的「性能税」表格：加密通常意味着 74% 的性能损失。而 MACsec 在这里零损失。

为什么？因为它不在 PPE 里做——它在 L2 MAC 层做（Slide 26 的「L2 MACs w/ MACsec」）。 数据包在进入包处理流水线之前就已经解密，在离开之后才加密。对整条处理流水线而言，MACsec 是「不存在」的。

这是一个重要的架构选择洞察： 如果你的加密需求是「点到点链路保护」（如 DCI、专线、园区骨干）， MACsec 在性能上完胜 IPsec——而 8000 系列让 MACsec 从「高端专属」变成了全系标配。

4.6 Open IOS XE：一个镜像，两种人格

Socratic Question 27

如果一台设备今天要跑传统路由（MPLS CPE），明年要转成 SD-WAN 边缘——需要换设备吗？需要换镜像吗？需要重新做资产登记吗？

Slide 27 与 Slide 28 给出的答案是：都不需要。

Single Image：`universalk9`

Slide 28 标题即为「Easy Operations with Single Image」。同一个 universalk9 镜像，可运行于两种模式：

IOS XE 'Autonomous' mode — 传统自治模式 → Cloud-scale Applications
IOS XE SD-WAN 'Controller' mode — 控制器模式 → Accelerate SD-WAN（加速 SD-WAN）
Single Image 本身 → Simplify Deployments（简化部署）

运维价值：镜像库只需维护一份、软件资产管理简化、模式切换无需重新采购或替换硬件。

Modern OS 架构（Slide 27）

三大价值主张：TCO Savings · Automation · Continuous Innovation

架构分层：

I/O + Forwarding（CPP 与 DPDK）— 数据面，对应 TCO Savings
Control and Management — IOSd、SD-WAN、Confd、Telemetry、IOS XE Database，对应 Automation
应用托管三形态：Native Apps / Container Apps / VM，对应 Continuous Innovation
Kernel — Linux 内核基座

注意「应用托管」——这正是第三章中「OS 验应用镜像用 ML-DSA-87」的对象。

可编程性：Day 0 到 Day n 的完整生命周期

Slide 29 用一个「Intent / Context」为核心的循环图，展示了 IOS XE 的可编程性覆盖：

阶段	能力	具体技术	解决什么问题（推导）
Day 0	Device Onboarding 设备上线	Zero-Touch, PNP Provisioning	分支设备开箱上电自动入网 — 依赖第三章的 SUDI 完成身份自证
Day 1	Device Configuration 设备配置	YANG Data Models、Network Configuration	用结构化数据模型代替 CLI 脚本，配置可版本化、可校验、可回滚
Day 2	Device Monitoring 设备监控	Telemetry	从「轮询式 SNMP」转向「推送式遥测」，秒级可见性
Day n	Device Optimization 设备优化	Guest Shell / Python Scripting / Application Hosting	在设备上直接运行自定义逻辑与容器化应用 — 边缘计算能力

Slide 6 还提到了一个新的管理入口： 「Meet Cisco Cloud Control — The unified interface for AgenticOps」。并在 Slide 78「Key Takeaways」中明确： Operational Simplicity – Managed by SD-WAN Manager and Cloud Control。

结合 Slide 49 的安全管理视图（SD-WAN Manager / Cloud Control / Splunk），可以看出管理平面的演进方向：从「设备管理」向「意图驱动 + AI 辅助运维」过渡。

此外，Slide 14 提到 Unified Edge 场景下将实现「Management plane integration between Intersight and SD-WAN Manager」—— 网络域与计算域的管理平面开始打通，这是「One Cisco advantage」的具体体现。

本节金句

硬件决定了性能的天花板，软件决定了这个天花板能被用到几成。一个镜像两种人格的设计，本质是把「今天买的设备」和「明年的架构决策」解耦。

4.7 新产品全家族：一次覆盖从「10G 铜缆分支」到「100G 数据中心」的补齐

Socratic Question 28

如果只是「性能更强」，为什么 Cisco 要一次性发布这么多新型号？它们各自在填补什么缺口？换个问法：这些型号的差异，反映了客户网络正在发生什么变化？

答案藏在 BRKXAR-2027 Slide 9 与 Slide 16 的标题里。这两页在介绍新型号时，各用一行小字点明了动机：

8200 系列扩展的动机（Slide 9）

Growing adoption of 10G WAN (Copper & Fiber)
—— 10G WAN 正在快速普及，且铜缆与光纤两种介质都有需求
SD-WAN + Threat Protection enterprise branch up to 2 Gbps
Ethernet only —— 纯以太网型号（无需 DSL/蜂窝模块的场景）
Dual PSU (external) —— 冗余电源，外置
PQC IPsec/MACsec/SD-WAN + PQC Secure Boot

8100 系列扩展的动机（Slide 16）

Growing adoption of 10G Copper WAN
—— 小型分支也开始用 10G 铜缆接入
Embedded 5G Rel 17 variant —— 内嵌 5G Release 17
SD-WAN + Threat Protection enterprise branch with 1Gbps throughput
PQC IPsec/SD-WAN + PQC Secure Boot

第一性原理拆解：从产品线变化，反推客户网络的三个趋势

产品规格是需求的镜像。从这批新型号中可以读出三个明确的行业变化：

WAN 带宽从 1G 迈向 10G，且铜缆成为主流选项。
过去 10G WAN 几乎等同于光纤，需要专线。现在 10GBASE-T 铜缆端口出现在 C8221L-G2（8200 系列）与 C8151H-C-G2、C8130H-G2（8100 系列）上—— 说明运营商正在以铜缆形式交付 10G 接入，客户不愿为此升级到光纤设备。 Slide 32 明确将此列为一项硬件创新：mGig/10GE —「Migration from 1GE」。
Threat Protection 吞吐成为分支选型的核心指标。
注意 C8225-G2 的定位描述：「2x 10G Fiber WAN w/ 2G Threat Protection」—— 威胁防护吞吐被写进了产品名称的定位语。这反映出「Secure Internet-only branch」（Slide 4 的客户趋势之一）已成为主流架构： 分支不再回传总部过防火墙，而是本地上网、本地检测。
计算与网络在边缘融合。
Unified Edge Network Node（C8255-G2-UCSXE）的出现，以及 Slide 14 提到的「Enable deploying AI at the edge securely and at scale」—— 说明边缘节点开始承载 AI 推理负载，网络设备必须与计算平台共处一个机箱。

8200 系列四款新变体逐一详解

型号	定位	WAN 接口	LAN 接口	转发	IPsec	SD-WAN	Threat Protection	版本
C8221L-G2	2× 10G 铜缆 WAN	2× 10G WAN（Copper）	8× 1G Ethernet WAN(L3) / LAN(L2) / Flex(L3/L2)	19 Gbps	5 Gbps	4 Gbps	1 Gbps	XE 26.1.2
C8221-G2	2× 10G 光纤 WAN	2× 10G WAN（Fiber）	8× 1G Ethernet	19 Gbps	5 Gbps	4 Gbps	1 Gbps	XE 26.1.2
C8225-G2	2× 10G 光纤 WAN + 2G 威胁防护	2× 10G WAN（Fiber）	8× 1G Ethernet	19 Gbps	5 Gbps	4 Gbps	2.2 Gbps	XE 26.1.2
C8211-G2	2× 1G 光/铜 WAN （入门型）	2× 1G WAN（combo）	4× 1G Ethernet	5.6 Gbps	3 Gbps	2 Gbps	1 Gbps	XE 26.2.1

注意：前三款为 XE 26.1.2，而 C8211-G2 为 XE 26.2.1（Slide 13）—— 同一批发布的变体上市时间并不一致，做迁移排期时需按型号分别确认。

四款型号的共同物理特征（Slide 10–13 一致标注）：

Redundant PSU (external) —— 冗余电源，外置适配器形式
OOB Mgmt —— 带外管理端口（C8211-G2 未标注此项）
RJ45 console + USB3.0 Type C
Kensington Lock —— 物理防盗锁孔（C8211-G2 未标注）
Ground —— 接地端子
System LED / Reset button / Power button

C8225-G2 与 C8221-G2 的差异值得单独讨论。 两者接口完全相同、转发/IPsec/SD-WAN 性能完全相同—— 唯一差异是 Threat Protection：1 Gbps vs 2.2 Gbps（2.2 倍）。

这说明什么？ 结合 4.3 节的 Dynamic Resource Provisioning，可以推断： 差异来自资源分配能力与授权/许可层面，而非物理接口差异。

选型建议（基于上述推导）： 如果分支采用 DIA（本地直接上网）+ 完整威胁防护栈，应直接选 C8225-G2；如果分支流量主要是回传总部的加密隧道（威胁检测在总部完成）， C8221-G2 已足够。 关键判断依据：本地需要做深度检测的流量占比。

脚注定义：这些性能数字到底是怎么测的？

第一性原理：不理解测试条件的性能数字，等于没有数字

BRKXAR-2027 在多处给出了性能指标的精确定义。 这些定义至关重要——它们决定了你能否把这些数字用于实际容量规划。

指标	精确定义（原文）	解读
SD-WAN 吞吐	「SD-WAN feature combination: IPsec + QoS + Deep Packet Inspection + Flexible NetFlow」亦称 AAR（App Aware Routing）或 IQDF	这是四项功能同时开启的吞吐，非单纯 IPsec。 Cheat Sheet 中的 `SD-WAN IQDF` 即此含义
Threat Protection (TP)	「100% DIA-NAT + App Aware FW + IPS + URLF + AMP」	「100% DIA-NAT」意味着全部流量都做本地上网 NAT —— 这是最严苛的假设。五项安全功能全开
50% DIA-TP	「IPsec + QoS + DPI + FNF + DIA-NAT50% + ZBFW + IPS + URL-F + AMP + TG」	更接近真实分支：50% 流量本地上网、50% 走隧道回传，且同时叠加 SD-WAN 功能与 Threat Grid
测试包长	转发/IPsec/AAR：@512B； Threat Protection：@EMIX	512 字节是行业常用的中等包长基准。EMIX 是模拟真实企业流量的混合包长分布
数字性质	「All numbers are interim, final numbers subject to change at FCS」	临时数据，正式发布（FCS）时可能变化 —— 正式方案设计请以 FCS 数据为准

为什么这一段这么重要？ 因为「19 Gbps 转发」与「1 Gbps 威胁防护」是同一台设备的两个数字。 如果你按 19 Gbps 规划容量，却开启了完整威胁防护栈，实际可用带宽只有 1 Gbps —— 相差 19 倍。

容量规划的正确做法：先确定要开启的功能组合，再查对应的性能数字。

8100 系列两款新变体

型号	定位	WAN 接口	LAN	蜂窝	转发	IPsec	SD-WAN	TP	版本
C8151H-C-G2	10G 铜缆 WAN + 内嵌 5G	1× 10GBASE-T 1× GE RJ45/SFP Combo	最多 8 口 (6 专用 + 2 L2/L3)	Embedded 5G Rel 17	5.6 Gbps	1.5 Gbps	1 Gbps (900 Mbps IQDF)	1 Gbps	XE 26.1.3
C8130H-G2	10G 铜缆 WAN 仅路由（Routing only）	1× 10GBASE-T 1× GE RJ45/SFP Combo	最多 4 口 (2 专用 + 2 L2/L3)	—	1.9 Gbps	1.5 Gbps	N/A	N/A	XE 26.1.3

C8130H-G2 的「Routing only」定位值得注意。 Slide 51 的产品组合图把 8100 系列明确分为两栏： 左栏「Routing only」（C8140-G2、C8130H-G2、C8130-VAI/P-G2、C8130-G2）与 右栏「Routing/SD-WAN」（C8151H-C-G2、C8161-G2、C8151-G2、C8151-[CVAI/P]-G2、C8131-G2）。

但请注意一个关键事实： 即使是「Routing only」的 C8130H-G2，Cheat Sheet 也明确列出 「Post Quantum Cryptography — NIST PQC based Q-Safe encryption」，并具备 1.5 Gbps IPsec。

这印证了第二章 2.9 节的结论：PQC 在 8000 系列中是基线能力，不是高端选配。 即使是最入门的纯路由型号，也具备量子安全的 IPsec 与 PQC Secure Boot。

采购含义：你不需要为「量子安全」支付溢价去买高端型号。你需要判断的只是性能与功能等级。

Unified Edge Network Node：网络与计算的融合节点

Socratic Question 29

为什么要把路由器做成「计算平台里的一块板卡」？这与传统的「路由器 + 服务器分别摆放」相比，除了省空间，还改变了什么？

第一性原理拆解：AI 推理把「数据引力」推到了边缘

Slide 14 对 Cisco Unified Edge 的定义是： 「Modular platform converges compute, LAN, WAN, and SASE」，目标是 「Enable deploying AI at the edge securely and at scale」。

为什么 AI 推理必须在边缘？ 因为推理的输入数据（摄像头、传感器、POS 终端、工控信号）产生于边缘。把它们全部回传云端推理，代价是：带宽成本 + 延迟 + 隐私合规风险。

而一旦推理放在边缘，就产生了一个新问题： 这个边缘计算节点需要 LAN 接入（连接摄像头/终端）、需要 WAN 出口（回传结果/接收模型更新）、需要 SASE 安全（保护这些新增的攻击面）。

传统做法：摆三个盒子，配三套线，做三套管理。
Unified Edge 做法：一个机箱，模块化插入。

Secure Router Node 的四项价值（Slide 14）

Brings LAN, WAN, and SASE into the Unified Edge platform
1U half-width Unified Edge node 形态
Management plane integration between Intersight and SD-WAN Manager
—— 计算域与网络域管理平面打通
Full feature parity with existing 8200 Secure Router variants
—— 与独立 8200 型号功能完全对等，无功能妥协

定位表述：Delivers a 「One Cisco」advantage with seamless integration across domains

C8255-G2-UCSXE 规格（Slide 15）

背板接口	2× 25G backplane interface
LAN (PoE+)	14× 1G L2，30W PoE+
LAN (UPoE+)	2× 2.5mG L2，90W UPoE+
Flex 口	2× 2.5mG Flex ＋ 2× 10G Flex
PoE 总预算	360W
转发	19 Gbps
IPsec	5 Gbps
SD-WAN	4 Gbps
Threat Protection	2.2 Gbps
PQC	IPsec / MACsec / SD-WAN + Secure Boot
版本	XE 26.2.1

请对照 C8255-G2-UCSXE 与 C8225-G2 的性能数字： 转发 19 Gbps、IPsec 5 Gbps、SD-WAN 4 Gbps、TP 2.2 Gbps —— 完全一致。

这正是 Slide 14 所承诺的 「Full feature parity with existing 8200 Secure Router variants」 的量化证明。

它的意义在于：选择融合形态不需要接受任何性能或功能妥协。这在过去的「刀片式网络模块」产品中往往是做不到的—— 融合形态通常意味着功能子集。

另一个值得注意的细节：360W PoE 总预算 + 14 个 PoE+ 口 + 2 个 90W UPoE+ 口。 90W UPoE+ 足以驱动高功耗设备（如带云台的 AI 摄像头、边缘 AP、数字标牌）—— 这进一步印证了「边缘 AI 场景」的设计意图。

4.8 创新总表：硬件、安全，以及一页看清的全系列性能矩阵

Slide 32 与 Slide 33 用两页把 8000 系列的创新点做了系统归纳。我们把它们整理成两张对照表。

硬件创新（Slide 32：Hardware Innovations）

创新点	覆盖范围	解决的实际问题（第一性原理解读）
Secure networking processor HW accelerated Security & Networking	Small, medium, large branch	打破 4.1 节的「安全性能税」——把串行软件处理变为并行硬件处理
Fanless model 无风扇型号	Small, medium, large branch	无风扇 = 无活动部件 = 无灰尘敏感性 = MTBF 大幅提升，且静音。适合零售门店、办公区、工业现场。C8231-G2、C8235-G2、C8355-G2 均为 fanless
25GE WAN	Campus Router（8400 系列）	园区 WAN 上行从 10G 迈向 25G，Slide 57 指出 8400「Up to 3x faster · 25GE WAN」
mGig / 10GE	Migration from 1GE	支持从 1GE 平滑迁移。mGig（多速率千兆）可在同一物理口协商 1G/2.5G/5G/10G，保护现有布线投资
Secure boot （图标标注 TAm，副标题 Post-Quantum Safe）	全系列	第三章的信任链基础。8000 系列为 PQC Secure Boot，由 TAm（Trust Anchor module）提供 SUDI 身份、安全存储、RNG 与加密服务
Dying gasp	Small, medium, large branch	「临终喘息」：设备在断电瞬间用残余电能发出最后一条告警。为什么重要？它把「设备失联」这个模糊状态，区分为「断电」还是「链路故障」——直接决定了运维派单方向

注：Slide 32 共列出六项硬件创新。上表中 TAm 与 Post-Quantum Safe 在原页面上并非独立条目，而是「Secure boot」一项的图标标注与副标题，此处合并呈现以保持与原页一致。

安全创新（Slide 33：Security Innovations）

创新点	具体内容	意义解读
Consistent Security Policy Construct 一致的安全策略构造	Built-in Secure Firewall（内建 Cisco Secure Firewall）	路由器上的防火墙策略与专用防火墙使用同一套策略模型。价值：避免「同一条业务规则在两套系统里写两遍、两边不一致」这个经典运维陷阱
NIST Compliant PQC	IPsec / MACsec	符合 NIST 标准（非私有算法）→ 保证跨厂商互操作性与合规审计可通过
Throughput Improvement	10x IPsec、6x Threat Protection	相对上一代的倍数提升。注意：这两个数字是产品线整体的最大提升幅度，具体型号见下方性能矩阵
Line-rate MACsec	LAN/WAN MACsec on all FPGE （8200 secure routers and onward）	这是一个巨大的变化。见下方专门讨论
Security AI/ML	Ready to offload (8300/8400)	8300/8400 已具备将安全 AI/ML 运算卸载到硬件引擎的能力（Slide 21/22 中的 AI/ML engine）
Tamper Detection	Physical (open chassis) Intrusion Detection	物理开箱入侵检测。见下方专门讨论

深入：为什么「全端口 MACsec」是一次质变？

Slide 65 的脚注揭示了上一代的窘境：「In previous gen branch routers WAN/LAN MACsec is only supported on 8300-2N2S-4T2X built-in 10GE ports, other models require specific NIM modules, it is fully supported in prev gen campus and DC routers.」

翻译成运维语言：

过去：想在分支用 MACsec？只有一个特定型号的特定端口支持，其他型号必须加购专用 NIM 模块 → 增加 BOM 成本、占用插槽、增加备件种类
现在：8200 及以上所有内建端口（all FPGE）原生支持 → 零额外成本、零规划约束

这直接改变了架构可能性：过去 MACsec 只能用在骨干核心的少数链路上；现在可以作为默认策略应用于所有分支链路。

深入：Tamper Detection —— 把物理安全接入监控体系

Physical (open chassis) Intrusion Detection —— 检测机箱是否被打开。

为什么这值得作为一项「安全创新」列出？回顾第三章 3.8 节的 taint（污染/植入）威胁：

Secure Boot 能检测软件被篡改； SUDI 能检测设备被冒充；但如果有人打开机箱、加装一个硬件监听装置—— 这两者都检测不到。

Tamper Detection 补上的正是这一环。 它把「机房门禁」这类传统物理安全手段， 下沉到了单台设备粒度，并接入了可远程监控的告警体系。

对于部署在无人值守站点（变电站、路侧机柜、远端工厂）的设备，这项能力的价值尤为突出。

全系列性能矩阵：一页看清整个产品线

整合 Slide 51（小型分支）、Slide 52（中大型分支）、Slide 53（园区与数据中心）与三份 Cheat Sheet 的数据。 图例说明：CEF = 转发吞吐；IPsec = 加密吞吐；TP = Threat Protection（100% DIA-NAT + App Aware FW + IPS + URLF + AMP）。

层级	型号	CEF 转发	IPsec	TP 威胁防护	关键特征
8100 小型分支 Routing only	C8140-G2	5.6 Gbps	1.5 Gbps	N/A	2× 1GE Combo WAN，最多 8 LAN 口
	C8130H-G2	1.9 Gbps	1.5 Gbps	N/A	10GBASE-T WAN XE 26.1.3
	C8130-G2 / -VAI-G2 / -VAP-G2	1.9 Gbps	1.5 Gbps	N/A	VAI = VDSL over ISDN；VAP = VDSL over POTS；VAI/P 型号含 XGSPON/10GBASE-T + RJ11 xDSL
8100 小型分支 Routing / SD-WAN	C8151H-C-G2	5.6 Gbps	1.5 Gbps	1 Gbps	10GBASE-T WAN + Embedded 5G Rel 17 XE 26.1.3
	C8161-G2	5.6 Gbps	1.5 Gbps	1 Gbps	含 PoE（4 PoE / 2 PoE+，输出最大 80W），150W 电源
	C8151-G2 / C8151-[CVAI/P]-G2	5.6 Gbps	1.5 Gbps	1 Gbps	C 型号含 Embedded 5G Rel 17；非 C 型号为 5G/CAT7 LTE 可插拔
	C8131-G2	1.9 Gbps	1.5 Gbps	1 Gbps	入门 SD-WAN 型号，30W/66W 电源
8200 中型分支	C8235-E-G2 / C8235-G2 / C8225-G2	19 Gbps	5 Gbps	2.4 Gbps^*	Slide 52 该组标注 19/5/2.4（组内最高值）；单机 C8225-G2 为 2.2 Gbps（Slide 12）
	C8231-E-G2 / C8231-G2 / C8221-G2 / C8221L-G2	19 Gbps	5 Gbps	1 Gbps	C8221L-G2 = 10G 铜；C8221-G2 = 10G 光；-E 为模块化 XE 26.1.2
	C8211-G2	5.6 Gbps	3 Gbps	1 Gbps	2× 1G Combo WAN，4 LAN 口 XE 26.2.1
8300 大型分支	C8375-E-G2	38 Gbps	20 Gbps	7 Gbps	模块化：1× NIM + 1× SM；2× UPoE+（最大 720W）；AC/AC+PoE/DC 内置电源；SD-WAN AAR 12 Gbps
8300 大型分支	C8355-G2	38 Gbps	20 Gbps	3.9 Gbps	Fanless；4× UPoE+（最大 120W）；4× 10GE 连接；全端口 MACsec；SD-WAN AAR 8.7 Gbps
8400 园区	C8475-G2	88 Gbps	45 Gbps	11 Gbps	25GE WAN；TP 定义为 100% DIA-NAT + ZBFW + IPS + URLF + AMP
8400 园区	C8455-G2	67 Gbps	31 Gbps	9.5 Gbps	25GE WAN
8500 / 8600 数据中心	C8650-G2	540 Gbps	220 Gbps	N/A	3rd Gen QFP；6× 100/40G + 20× 10/1G；3RU；全端口线速 MACsec；Full-stack PQC XE 26.1.2
	C8570-G2	190 Gbps	63 Gbps	N/A	—
	C8550-G2	115 Gbps	48 Gbps	N/A	—

^* 注：Slide 52 的产品组合图按性能分组显示，同组内多个型号共享该组的最高数值； Cheat Sheet 提供了单一型号的具体数值。两者存在差异时，请以对应型号的 FCS 正式规格为准。所有数字均标注为 interim（临时），正式发布时可能调整。

第三方独立验证：安全效力的实证

性能数字可以自测，但安全效力必须由第三方验证。 Slide 50 给出了 NetSecOpen 认证结果：

99.23% Intrusion Prevention (IPS) Effectiveness
入侵防御有效率

99.79% Malware Detection Rate
恶意软件检测率

2 份 NetSecOpen 认证报告
C8375-E-G2 与 C8235-G2

Slide 50 用三个词概括了这份认证的价值： Independent Evaluation（独立评估）· Trusted Organization（可信机构）· Deploy with Confidence（放心部署）。
此外，Slide 63 提到 Cisco 8000 系列亦有 Miercom 的独立分析、研究与评测报告。

为什么第三方认证在安全采购中不可替代？

因为「防火墙吞吐 2.2 Gbps」这个数字， 在检测规则集只开 100 条时和开 30000 条时完全不同；在只做端口匹配和做深度应用识别时完全不同。

NetSecOpen 的价值在于：它规定了统一的测试方法、统一的规则集、统一的流量模型。 使得「99.23% IPS 有效率」这个数字可以与其他厂商横向比较—— 而厂商自测数据无法比较。

建议：在安全设备采购的技术评分表中，将「是否有近期第三方独立认证报告」作为一项独立指标，而非仅接受厂商自述的性能与检出率。

第四章金句

把加密引擎、流量管理器、以太网控制器和信任锚做进同一颗硅片，改变的不只是性能数字——它改变了一个更根本的事：安全从此不再是需要用带宽去购买的奢侈品。

第五章 · Chapter 05

落地：七种 Secure WAN 用例，以及每一种的性能账本

前四章都在讲「是什么」和「为什么」。本章只讲一件事： 把这台设备放进真实网络里，它到底解决谁的什么问题，快了多少倍。

5.1 第三十问：为什么同一个产品线要覆盖七种截然不同的用例？

Socratic Question 30

MPLS CPE 需要 VRF 和分层 QoS；Internet Gateway 需要百万级 NAT 会话和全互联网路由表；Secure Networks 需要 50 毫秒内的快速重路由。这三种需求在硬件资源上几乎是互相冲突的。为什么不做三个专用产品线？

因为客户的网络不是按用例划分的，而是按站点划分的。而同一个站点，往往同时是好几种用例。

第一性原理拆解：真实网络的「用例叠加」

BRKXAR-2027 Slide 4 描绘的客户趋势图，本身就是答案。它展示了一张「Secure Network powered by Cisco」的全景，其中包含：

Campus / Datacentres · Branch / SMB Offices · Factory / Substation · Remote Home
连接对象：Hyperscalers（超大规模云）· SaaS · SSE · Private DC · Untrusted Internet

并列出了五个转型驱动力： Multi-hybrid / neo / sovereign-cloud acceleration（多混合云、新云、主权云加速）、 Work from anywhere、 Application / digital experience、 Secure, internet-only branch、 Simplify IT → centralized management, distributed enforcement（集中管理、分布式执行）。

看最后一条：「集中管理，分布式执行」。 这句话正是七种用例必须由同一产品线覆盖的根本原因——

如果七种用例对应七个产品线、七种操作系统、七套管理平台，那么「集中管理」在物理上就不可能实现。

反过来说：正是因为有了 4.6 节的「单镜像 + 双模式」与 4.3 节的「动态资源分配」，同一颗硅片才能通过配置而非换型来适配不同用例——「集中管理」才成为可能。

这是第四章与第五章之间的逻辑桥梁：架构上的统一，是运维上简化的前提。

七大用例总览（Slide 55 原文定义）

#	用例	Cisco 原文定义（完整还原）	典型客户
1	MPLS CPE	CPE managed by enterprise or MSP, establish routing peering with MPLS provider PE for sites connectivity, provides VRF segmentation and QoS capabilities.	使用运营商 MPLS 专线的企业 / 托管服务商（MSP）
2	Overlay VPN	Enterprise want to have more control of their own network topology, build Overlay VPN on top of providers' transport network, typically in a Hub & Spoke topology with on-demand tunnels.	希望摆脱运营商拓扑约束的企业
3	SD-WAN	Software-defined WAN to route the application to the best path to satisfy Application Aware Routing (AAR) policy.	多链路、应用体验敏感的分布式企业
4	Secure Branch DCA/DIA	Secure Branch direct cloud access (DCA) or direct Internet access (DIA) w/ Threat Protection (TP) using built-in Secure Firewall.	SaaS 优先、不愿回传总部上网的分支
5	Secure Networks	Build highly resilient, secure and scalable network for Military protected core, Utility, Transportation & Govt agencies. It is typically deployed with Segment Routing solution.	军事、电力/能源、交通、政府机构
6	Internet Gateway	BGP peering with multiple Internet service providers to learn full internet route table, provide resilient Internet access, network address translation and protect against Denial-of-Service Attack.	自建互联网出口的大型企业 / 数据中心
7	Cloud Edge	Connect on-prem sites at Colo or DC to multi-cloud via private, high-speed connections such as AWS DX, Azure ER, which are encrypted by IPsec or MACsec.	多云架构企业 / Colo 托管场景

5.2 用例 ① MPLS CPE：VRF 分段与分层 QoS 的经典战场

Socratic Question 31

MPLS 专线是「上一代技术」，为什么它还在七大用例里排第一？什么样的需求，是 SD-WAN 与互联网 VPN 至今无法替代的？

第一性原理拆解：SLA 的物理来源

互联网 VPN 的带宽和延迟是「尽力而为」（best-effort）的—— 没有人对你承诺任何延迟上限。

MPLS 专线卖的不是带宽，而是合同化的 SLA：延迟、抖动、丢包率都写在协议里，违约有赔偿。

因此，凡是「延迟违约即业务违约」的场景，MPLS 至今不可替代： 实时交易撮合、工业控制回路、语音核心网互联、医疗影像实时传输。

而 CPE 在这个场景里的职责非常明确，就两件事：

VRF 分段（VRF segmentation） —— 让不同业务/租户的流量在同一条物理专线上逻辑隔离。
HQoS（分层服务质量） —— 因为专线带宽昂贵且固定，必须精确控制谁优先。

这也解释了为什么 Slide 57 的性能指标不是「转发吞吐」，而是特定的「VRF + HQoS Throughput @512B」—— 因为在这个用例里，裸转发性能毫无意义；只有「开着 VRF 和分层队列时还能跑多快」才有意义。

精准定义

VRF 与 HQoS 三要素

VRF（Virtual Routing and Forwarding）： 在同一台物理路由器上维护多份完全独立的路由表。不同 VRF 的流量即使 IP 地址重叠也不会互通。

Priority Queue（PQ）：严格优先队列——只要队列里有包，就抢先发送。用于语音/控制信令。

BRR%（Bandwidth Remaining Ratio）：按剩余带宽比例分配。PQ 用完后，其余队列按比例瓜分。

Tail Drop / RED：队列满时的丢包策略。Tail Drop 直接丢尾部； RED（Random Early Detection）在队列快满前就随机提前丢弃，避免 TCP 全局同步。

精妙类比

一条收费高速公路的车道管理

VRF = 用不透明隔离墙分出的独立车道群。 财务部的车永远看不到、也进不了研发部的车道—— 即使两边的车牌号完全一样。

Priority Queue = 应急车道。 救护车（语音）一来，所有车让行。

BRR% = 剩余车道的分配协议。 救护车走完，剩下的通行能力按「货车 60%、客车 40%」分配。

RED = 提前限流的电子牌。 不等到堵死才封路，而是在快堵时随机劝返一部分车—— 因为如果等全堵死再一起放行，所有车会同时启动、再次同时堵死（TCP 全局同步）。

MPLS CPE 场景的性能提升（Slide 57）

系列	相比上一代的提升	关键新增能力	VRF + HQoS 吞吐 @512B
8100	Up to 2x faster	10GE Copper 与 XGSPON WAN	Up to 2.9 Gbps
8200	Up to 4x faster	10GE & mGig WAN	Up to 13.5 Gbps
8300	Up to 2x faster	4× 10GE & mGig connectivity	Up to 28 Gbps
8400	Up to 3x faster	25GE WAN	Up to 65 Gbps
8500 / 8600	Continued perf excellence	—	Up to 420 Gbps

关于「x 倍更快」的对比基准（Slide 57 脚注，全章通用）：
这些倍数不是营销修辞，Cisco 给出了明确的对比对象：

新系列	对比的上一代产品
8100	ISR1K
8200	Catalyst 8200 Series
8300	Catalyst 8300 Series
8400	C8500L-8S4X
8500	C8500-12X、C8500-12X4QC
8600	C8500-20X6C

为什么这个脚注重要？ 因为「快 4 倍」这句话在没有基准时毫无意义。 有了明确基准，你就可以拿自己现网的实测数据去做同比推算—— 这才是能用于容量规划的信息。

5.3 用例 ② Overlay VPN：把拓扑控制权从运营商手里拿回来

Socratic Question 32

如果运营商已经提供了 MPLS VPN，企业为什么还要在它之上再叠一层自己的 VPN？这不是重复劳动吗？

第一性原理拆解：谁掌握拓扑，谁掌握敏捷性

Slide 55 的定义已经点出了动机： 「Enterprise want to have more control of their own network topology」。

在纯 MPLS VPN 中，拓扑由运营商配置： 你想新增一个站点、改变某两站点的互通关系、调整路由策略—— 都需要给运营商开工单，等数天到数周。

而 Overlay VPN 把这层控制权收回： 运营商网络退化为纯粹的 Underlay（承载层）——它只需负责「把包从 A 送到 B」。 拓扑、路由策略、加密、隧道建立与拆除，全部由企业自己的设备决定。

三个直接收益：

敏捷性 —— 新增站点只需配置 CPE，无需运营商介入。
传输无关性 —— Underlay 可以是 MPLS、也可以是互联网、也可以是 5G。更换运营商不影响 Overlay 拓扑。
端到端加密 —— 流量在离开企业设备时就已加密，运营商看不到内容。 这一点在 HNDL 语境下尤其重要——见下方讨论。

Overlay VPN 场景的性能提升（Slide 59）

系列	提升幅度	关键新增能力	IPsec 吞吐 @512B	PQC
8100	Up to 2x faster	10GE Copper 与 XGSPON WAN	Up to 1.5 Gbps	NIST Compliant PQC Slide 59 明确标注
8200	Up to 5x faster	10GE & mGig WAN	Up to 5 Gbps
8300	Up to 10x faster	4× 10GE & mGig connectivity	Up to 20 Gbps
8400	Up to 3x faster	25GE WAN	Up to 45 Gbps
8500 / 8600	Continued perf excellence	—	Up to 220 Gbps

注意 8300 系列的「Up to 10x faster」——这是全部七个用例中最大的单项提升。

为什么加密场景的提升幅度最大？ 回到 4.2 节的架构图：In-line Crypto engine。上一代 Catalyst 8300 的加密需要数据包在处理流水线与加密模块之间往返；新一代的加密引擎在数据面在线（in-line），PPE 可直接调用。

10 倍提升不是频率提升，是路径缩短。

对 Overlay VPN 用户的实际含义： 过去因为「加密性能不够」而不得不选择更高型号、或不得不对部分流量放弃加密的取舍， 在新一代上基本消失了。 这直接支撑了第一章的核心建议——「先保护最敏感的数据」现在可以升级为「全部加密」。

5.4 用例 ③ SD-WAN：让应用自己选路

Socratic Question 33

传统路由的选路依据是「目的 IP 地址」。但一条链路对语音来说不可用（延迟太高），对文件备份来说完全够用。为什么路由协议看不到这个差别？

第一性原理拆解：路由协议缺失的两个维度

传统 IP 路由的决策模型极其简单：查目的地址 → 选最优下一跳。它有两个根本盲区：

盲区一：不知道「这是什么流量」。 路由表里只有 IP 前缀，没有「这是 Teams 语音」还是「这是 Windows 更新」的信息。
盲区二：不知道「这条路现在好不好」。 路由协议只知道链路 UP/DOWN 和管理员配置的 metric，不知道实时延迟、抖动、丢包。

SD-WAN 的 AAR（Application Aware Routing）就是同时补上这两个维度：

用 DPI（深度包检测）+ AppID 识别「这是什么应用」。
用持续探测测量每条路径的实时延迟/丢包/抖动。
用策略把两者关联：Slide 60 的示例策略是 「App A path must have latency <150ms and loss <1%」。

决策模型的转变： 从「去这个地址走哪条路」变成「这个应用需要什么样的路，哪条路现在满足条件」。

精准定义

AAR（Application Aware Routing）

Slide 55 定义：route the application to the best path to satisfy AAR policy。

它的技术前提是四项功能必须同时运行—— 这也正是 Slide 61 中「AAR Throughput」的定义： IPsec + QoS + DPI + FNF。

为什么四项都必需？ IPsec 提供安全、QoS 提供优先级执行、 DPI 提供应用识别、FNF（Flexible NetFlow）提供可见性与统计。 缺任何一项，AAR 都无法完整成立。

精妙类比

导航 App vs 纸质地图

传统路由 = 纸质地图。 它告诉你「从 A 到 B 有三条路，其中这条最短」。 但它不知道今天哪条路在堵车，也不知道你开的是救护车还是货车。

AAR = 实时导航 App。 它同时知道三件事： ① 你是什么车（AppID / DPI） ② 每条路现在堵不堵（实时 SLA 探测） ③ 你的规则是什么（策略：救护车必须走 <150ms 的路）

而且当所有路都堵时，它不会「不导航」—— 它会选一条相对最好的，并把这个降级事件记录下来（Netflow）。

SD-WAN 场景的性能提升（Slide 61）

系列	提升幅度	关键新增能力	AAR 吞吐 @512B
8100	Up to 3x faster	10GE Copper 与 XGSPON WAN	Up to 1 Gbps
8200	Up to 4x faster	10GE & mGig WAN	Up to 4 Gbps
8300	Up to 4x faster	4× 10GE & mGig connectivity	Up to 12 Gbps
8400	Up to 2x faster	25GE WAN	Up to 20 Gbps
8500 / 8600	Continued perf excellence	—	Up to 82 Gbps

5.5 用例 ④ Secure Branch DCA/DIA：把防火墙搬进路由器

Socratic Question 34

分支员工访问 Microsoft 365。传统做法：流量加密回传总部 → 过总部防火墙 → 出总部互联网出口 → 再绕回微软云。

这条路径上有多少公里是纯粹浪费的？如果不绕，代价是什么？

第一性原理拆解：回传架构的三重成本

「回传总部上网」（backhaul）这个架构，在 SaaS 时代产生了三重成本：

延迟成本 —— 用户体验直接受损。绕行可能增加数十到上百毫秒。
带宽成本 —— SaaS 流量占据了昂贵的 WAN 专线带宽，而这些流量的目的地根本不是总部。
集中式瓶颈 —— 总部出口成为所有分支的共享瓶颈与单点故障域。

所以答案很明显：让分支直接上网（DIA）或直连云（DCA）。

但代价是什么？ 回传架构存在的唯一理由，就是「安全检测集中在总部」。 一旦分支直连互联网，分支就成了一个暴露的攻击面——需要在本地具备完整的安全检测能力。

这就是「Built-in Secure Firewall」的存在价值： 它不是一个「简化版防火墙」，而是把总部级别的检测能力下沉到每一个分支。

而这也回到了 Slide 4 的客户趋势：「Secure, internet-only branch」—— 分支只有互联网连接，但依然安全。

请注意 SSE 生态中一个很有分量的规格：「Auto Tunnel + HA — 8 Active / 8 Standby」。

为什么隧道数量这么重要？ 当分支把安全检测卸载到云端 SSE 时，那条通往 SSE 的隧道就成了整个分支的生命线。 它一断，分支就上不了网。

8 主 + 8 备的自动隧道意味着： ① 可以向多个 SSE PoP 同时建隧道以做负载分担与就近接入； ② 单个 PoP 或单条隧道故障时有充足的备用路径； ③ 「Auto」意味着这些隧道由系统自动建立与维护，而非手工配置 16 条隧道。

这是一个典型的「规格数字背后是运维负担」的例子—— 评估云安全方案时，隧道自动化程度与冗余数量应当与检测能力同等重要。

DIA/DCA 场景的性能提升（Slide 63）

系列	提升幅度	关键新增能力	TP 吞吐 @EMIX	50% DIA-TP 吞吐 @EMIX
8100	Up to 6x faster	TLS Decryption 脚注：TLS 解密对小型分支路由器是全新能力，上一代中大型分支与园区路由器已支持	Up to 1 Gbps	Up to 1 Gbps
8200	Up to 2x faster	—	Up to 2.4 Gbps	Up to 1.9 Gbps
8300	Up to 3x faster	—	Up to 7 Gbps	Up to 7 Gbps
8400	Up to 3x faster	—	Up to 11 Gbps	Up to 11 Gbps

值得深挖：为什么 8100 的提升幅度高达 6 倍？

对比其他系列的 2–3 倍，8100 的 6 倍显得异常突出。Slide 63 的关键能力栏给出了线索：TLS Decryption。

第一性原理推导： 今天绝大多数互联网流量是 TLS 加密的。 如果设备不能解密 TLS，那么 IPS、URL-F、AMP 都只能看到「有一条加密连接」，看不到里面的内容——安全检测的有效性大幅下降。

而 TLS 解密是极其消耗算力的操作（需要为每条会话做密钥协商与流式解密/重加密）。上一代小型分支路由器不支持它，很可能正是因为算力不足。

因此「6x faster」的实际含义可能是双重的： 不仅是同样功能跑得更快，更是「过去做不到的功能现在能做了」。

对小型分支的架构含义： 过去小分支要做完整的 TLS 可见性检测，必须回传总部或依赖云端 SSE。 现在本地即可完成 → DIA 架构真正可以下沉到最小规模的站点。

展开：内建 Secure Firewall 的完整能力清单（Slide 49）

Next Generation Firewall 核心能力

能力	Cisco 原文描述
NGFW	L3 – L7 + Identity FW — Manage traffic traversing the branch
IPS / IDPS	Protect assets from bad actors
AMP	Protect against malware
Sandboxing	File Analysis using Threat Grid
URL-F	Filter Internet traffic
TLS Decryption	Traffic Decryption
DNS / SWG	Protect web servers / applications

管理、监控与分析（Management, Monitoring & Analytics）

Slide 49 列出三个平台：SD-WAN Manager、Cloud Control、Splunk。

Splunk 的出现值得注意——它意味着分支路由器上的安全事件可以直接进入企业级 SIEM 分析体系， 而不是停留在设备本地日志里无人查看。

两个贯穿性主张

Consistent Security Policy Construct — 一致的安全策略构造
Built-in Secure Firewall — 内建（而非外挂）

5.6 用例 ⑤⑥⑦：关键基础设施、互联网出口、多云边缘

用例 ⑤ Secure Networks：为「不能断」的网络而设计

Socratic Question 35

普通企业网的路由收敛时间是几百毫秒到几秒，通常可接受。但对一个电网继电保护回路来说，几百毫秒意味着什么？

第一性原理拆解：50 毫秒这个数字从哪来？

Slide 55 定义此用例的服务对象是： Military protected core、Utility（公用事业）、Transportation（交通）、Govt agencies（政府机构），并指出「typically deployed with Segment Routing solution」。

Slide 65 为 8400 系列列出的两项关键能力，精确指向了这类客户的核心诉求：

Fast Reroute (<50msec convergence) —— 快速重路由，收敛时间小于 50 毫秒
Ingress Classification (e2e QoS treatment) —— 入向分类，实现端到端一致的 QoS 处理

为什么是 50 毫秒？ 这个数字来自传统电信与工业控制领域的经验阈值： 50ms 这个数字并非来自量子或安全领域，而是沿袭自传统传输网（SDH/SONET）保护倒换的工程惯例，并被电力、交通、军事等行业采纳为「故障对上层业务保持透明」的经验阈值。 超过它，业务会「感知到故障」；低于它，故障对业务是「透明的」。

而「Ingress Classification」为什么重要？ 因为在多跳网络中，如果每一跳都重新分类流量， 就可能因为某一跳的配置不一致而导致优先级丢失。 在入口处一次分类、全程携带 → 保证端到端（e2e）的 QoS 一致性。 —— 这对跨越数十跳的电力/交通骨干网尤为关键。

系列	提升幅度	关键新增能力（Slide 65）	IPsec 吞吐 @512B
8100	Up to 2x faster	—	Up to 1.5 Gbps
8200	Up to 5x faster	WAN/LAN MACsec on all built-in ports	Up to 5 Gbps
8300	Up to 10x faster	WAN/LAN MACsec on all built-in ports	Up to 20 Gbps
8400	Up to 3x faster	Fast Reroute (<50msec) Ingress Classification (e2e QoS)	Up to 45 Gbps
8500 / 8600	Continued perf excellence	—	Up to 220 Gbps

Slide 65 同样标注 NIST Compliant PQC。 对于军事与政府客户，这一项不是加分项，而是 CNSA 2.0 下的硬性合规要求—— 回顾第一章：NSS 相关系统的强制截止日期是 2030 年。

用例 ⑥ Internet Gateway：规模的三重考验

第一性原理拆解：自建互联网出口的三个规模瓶颈

Slide 55 的定义列出了四项职责：与多个 ISP 建立 BGP 对等、学习完整互联网路由表、提供NAT、以及防御 DoS 攻击。

这四项职责对应三个截然不同的规模维度—— 而 Slide 67 的能力提升正好精确对应：

路由表规模：完整互联网路由表已超过百万条前缀，且持续增长。
→ Slide 67：8500 具备 2x BGP route scale（8M）；8650 规格为 16M Routes。
NAT 会话规模：企业所有用户的所有并发连接都要占用一个 NAT 表项。
→ Slide 67：8400 具备 2x NAT session scale（4M）；8650 规格为 32M NAT/FW sessions。
NAT 转发性能：NAT 是有状态操作，每个包都要查表并可能改写头部。
→ 见下表。

关键洞察：这个用例的瓶颈往往不是带宽，而是「表项容量」。 一台设备可能带宽还有余量，但因为 NAT 表满而开始丢弃新连接—— 表现为「网速正常但打不开新网站」这种极难排查的故障。

这也正是第六章要讲的运维监控为什么必须包含 NAT 表项使用率。

系列	提升幅度	关键新增能力（Slide 67）	NAT 吞吐 @512B
8300	Up to 2x faster	4× 10GE & mGig connectivity	Up to 26 Gbps
8400	Up to 2x faster	25GE WAN 2x NAT session scale（4M）	Up to 59 Gbps
8500 / 8600	Continued perf excellence	2x BGP route scale（8M）on 8500	Up to 300 Gbps

注意：Internet Gateway 用例的产品覆盖从 8300 起（Slide 67 未列 8100/8200）—— 因为该用例的表项规模需求，超出了小型分支平台的设计范围。

用例 ⑦ Cloud Edge：多云高速互联的加密选择

Socratic Question 36

AWS Direct Connect 和 Azure ExpressRoute 是「私有专线」，不经过公共互联网。既然是私有的，为什么还要加密？

第一性原理拆解：「私有」不等于「加密」

Slide 55 的定义已经明确回答了： 「Connect on-prem sites at Colo or DC to multi-cloud via private, high-speed connections such as AWS DX, Azure ER, which are encrypted by IPsec or MACsec」。

为什么私有专线也必须加密？三个理由：

「私有」是逻辑隔离，不是物理独占。 DX/ER 的物理链路由运营商和云商共享，你的流量在他们的设备上以明文形式经过。
责任边界问题。 数据泄露时，「我们用了私有专线」不是一个能被审计接受的答案；「数据全程加密」才是。
HNDL 威胁不区分链路类型。 回顾第一章：攻击者只需在任何一个可触及的中转节点录下密钥协商报文即可。 私有专线的中转节点数量更少，但并非零——而「更少」不等于「没有」。

那么，IPsec 还是 MACsec？ 这是 Cloud Edge 场景最实际的架构决策。判断依据来自 2.6 节的类比：

判断维度	选 MACsec	选 IPsec
加密范围	点到点单段链路（如本端设备 ↔ 云商接入设备）	端到端路径（跨越多跳、跨越三层网络）
性能代价	零（线速，L2 MAC 层硬件完成）	有（占用 IPsec 吞吐预算）
MTU 影响	极小	有隧道封装开销
前提条件	对端必须支持 MACsec 且为直连二层链路	只要三层可达即可

结论：能用 MACsec 的地方优先用 MACsec（性能免费），无法直连的路段用 IPsec 兜底。 而 8000 系列「全内建端口支持 MACsec」这一点，正是让这个策略从「理论最优」变为「实际可行」的关键。

系列	提升幅度	关键新增能力（Slide 69）	IPsec 吞吐 @512B
8300	Up to 10x faster	WAN/LAN MACsec on all built-in ports	Up to 20 Gbps
8400	Up to 3x faster	—	Up to 45 Gbps
8500 / 8600	Continued perf excellence	—	Up to 220 Gbps

Slide 68 的架构图展示了典型部署位置： DC / Colo 内部为 Switch → FW → Cloud Edge 路由器 → 云商专线。 注意 Cloud Edge 路由器位于防火墙之外（更靠近云侧）—— 因为它的职责是「加密与高速传输」，而非「策略检测」。

5.7 七大用例性能提升总表：一页看清全景

建议将此表用作方案设计的第一步：先定位用例，再读取对应指标。 因为如 4.7 节所述——不理解测试条件的性能数字等于没有数字，而「用例」正是最重要的测试条件。

用例	核心指标	8100	8200	8300	8400	8500/8600
① MPLS CPE	VRF + HQoS @512B	2.9 Gbps 2x	13.5 Gbps 4x	28 Gbps 2x	65 Gbps 3x	420 Gbps
② Overlay VPN	IPsec @512B	1.5 Gbps 2x	5 Gbps 5x	20 Gbps 10x	45 Gbps 3x	220 Gbps
③ SD-WAN	AAR @512B (IPsec+QoS+DPI+FNF)	1 Gbps 3x	4 Gbps 4x	12 Gbps 4x	20 Gbps 2x	82 Gbps
④ Secure DIA/DCA	TP @EMIX (100%DIA-NAT+FW+IPS+URLF+AMP)	1 Gbps 6x	2.4 Gbps 2x	7 Gbps 3x	11 Gbps 3x	—
⑤ Secure Networks	IPsec @512B	1.5 Gbps 2x	5 Gbps 5x	20 Gbps 10x	45 Gbps 3x	220 Gbps
⑥ Internet Gateway	NAT @512B	—	—	26 Gbps 2x	59 Gbps 2x	300 Gbps
⑦ Cloud Edge	IPsec @512B	—	—	20 Gbps 10x	45 Gbps 3x	220 Gbps

横向扫这张表，会发现一个清晰的规律：

提升幅度最大的三处，都与加密相关： Overlay VPN、Secure Networks、Cloud Edge 的 8300 系列均为 10x。 → In-line Crypto engine 的架构红利。
唯一另一个 6x，出现在 8100 的威胁防护。 → TLS Decryption 从「不支持」到「支持」的能力跃迁。
纯转发类指标（MPLS CPE）的提升相对温和（2-4x）。 → 因为上一代在纯转发上本已不弱；瓶颈从来不在转发，而在安全。

这个规律指向一个明确的采购判断： 如果你的痛点是「开了安全功能就跑不动」，那么这一代产品对你的价值是数量级的；如果你的痛点只是「带宽不够」，那么价值是线性的。

第五章金句

七个用例，一个共同前提：安全不再需要用带宽去购买。当加密的边际成本趋近于零时，「只加密最敏感的数据」这句妥协，才终于可以被「全部加密」取代。

第六章 · Chapter 06

运维最佳实践：当设备的能力越来越多，你该盯着哪几个数字？

前五章讲的都是「能力」。本章讲一件更朴素但更决定成败的事： 这些能力在运行时会消耗资源，而资源耗尽的前一秒，往往没有任何告警。

6.1 第三十七问：一台路由器有几种「资源」会耗尽？

Socratic Question 37

提到路由器资源，多数人第一反应是「CPU 和内存」。但如果 CPU 只有 2%、内存只用了 25%，设备却在丢包——问题会在哪里？

第一性原理拆解：控制面与数据面是两套独立的资源体系

回顾 4.2–4.3 节的架构：8000 系列的算力被明确划分为 Control Plane（CP）、Data Plane（PPE）、Service Plane（SP）。

它们的资源池是相互隔离的。这意味着：

控制面 CPU 100% → BGP 邻居震荡、SSH 卡顿、配置无响应，但转发可能完全正常。
数据面 PPE 100% → 大量丢包、延迟飙升，但 show proc cpu 可能只显示个位数。
QFP DRAM 耗尽 → 新的 NAT 会话/防火墙会话/NetFlow 记录无法创建，表现为「老连接正常、新连接失败」——最难排查的一类故障。

结论：只监控 show proc cpu 和 show mem stat，会完全看不见数据面与服务面的健康状况。

这就是为什么 BRKXAR-2027 Slide 71 把监控对象明确分成了两大块：「Control Plane」与「Data Plane / Service Plane」。

一条命令看全局：`show platform resources`

这是 Slide 71 给出的最重要的一条命令—— 它在一屏内同时展示了控制面与数据面的健康状态：

G2#show platform resources
**State Acronym: H - Healthy, W - Warning, C - Critical
Resource                        Usage             Max         Warning  Critical  State
--------------------------------------------------------------------------------------
RP0 (ok, active)                                                                   H
  Control Processor             1.75%             100%        80%      90%         H
    DRAM                        3941MB(25%)       15755MB     88%      93%         H
ESP0(ok, active)                                                                   H
  QFP                                                                              H
    DRAM                        48320KB(2%)       2326528KB   85%      95%         H

输出行	监控对象	阈值设计	耗尽后的症状（推导）
`RP0 → Control Processor`	控制面 CPU（Route Processor）	Warning 80% / Critical 90%	路由协议超时、邻居翻动、管理会话失去响应
`RP0 → DRAM`	控制面内存	Warning 88% / Critical 93%	进程分配内存失败、路由表无法容纳新前缀、可能触发进程重启
`ESP0 → QFP → DRAM`	数据面内存（QFP）	Warning 85% / Critical 95%	NAT/FW 会话、FNF 缓存无法新建 → 新连接失败但老连接正常

精准定义

三个健康状态标识（State Acronym）

H = Healthy（健康）· W = Warning（警告）· C = Critical（严重）

这个设计的价值在于「分级预警」： W 状态是给你留出的行动窗口——此时业务仍正常，但你已经知道必须开始规划扩容或优化。

运维建议： 告警系统应对 W 状态触发工单（非紧急），对 C 状态触发值班响应（紧急）。 只在 C 时才告警，等于放弃了这个分级设计的全部价值。

精妙类比

汽车的三块仪表

控制面 CPU = 转速表。发动机转得多快，反映「决策系统忙不忙」。

控制面 DRAM = 油箱。存量资源，用完就停。

QFP DRAM = 载货舱容量。 这块表最容易被忽略——因为发动机（CPU）明明还很轻松，油箱（内存）明明还满着。 但货舱一满，就再也装不进新货了。

而「新连接建不起来、老连接却很正常」这个症状，正是「货舱满了但发动机还在轻松运转」的完美写照。

纳入自动化监控：SNMP MIB 映射

手工敲 show 命令不可持续。Slide 71 明确给出了三个 MIB：

MIB 名称	监控对象	来源
CISCO-PROCESS-MIB	监控 RP 上的 CPU 与内存	Slide 71
CISCO-ENTITY-QFP-MIB	监控 QFP 内存	Slide 71
CISCO-ENTITY-PERFORMANCE-MIB	监控加密引擎利用率（Crypto Engine Util）	Slide 75

补充建议：虽然 Slide 71 给出的是 SNMP MIB，但结合 4.6 节提到的 IOS XE 可编程性能力（Telemetry、YANG Data Models）， 在新建监控体系时应优先考虑推送式遥测（streaming telemetry）而非轮询式 SNMP—— 因为资源耗尽往往在秒级发生，而 SNMP 的典型轮询间隔是 5 分钟。

6.2 第三十八问：资源已经快满了，但预算要等下个财年——怎么办？

Socratic Question 38

监控告警显示 QFP DRAM 已达 92%（Critical 阈值 95%）。升级平台需要采购流程、需要窗口期，最快也要一个月。这一个月怎么活下来？

Slide 72 专门为此设计，标题即为「Mitigation Plan when run out of resources」，开篇明确了它的定位： 「Before upgrading platform/memory, customer can immediately take following actions to reduce system resources utilization」—— 在升级之前，可立即采取的降耗动作。

第一性原理拆解：所有缓解手段的本质，都是「主动放弃一部分能力」

请务必理解这一点： 这六条缓解措施没有一条是「免费优化」。它们的本质都是——用「主动、可控地放弃某项能力」，来换取「避免被动、不可控的全面崩溃」。

这是一个典型的风险管理决策： 与其让设备在资源耗尽时以不可预测的方式失效（丢哪些包？拒绝哪些连接？无法预知）， 不如由你自己决定「先放弃什么」。

IOS / 控制面 CPU 与内存：三条缓解措施

#	措施	命令	代价（第一性原理分析）
1	Shutdown routing peers 关闭路由邻居	`neighbor {ip-address} shutdown graceful <seconds>`	放弃该邻居带来的路由信息与路径冗余。注意 `graceful` 关键字：它允许在指定秒数内优雅关闭，让对端有时间收敛，而非硬性断开导致流量黑洞。
2	Reduce prefixes received from a peer 限制从邻居接收的前缀数	`neighbor {ip-address} maximum-prefix <number of prefixes>`	放弃超出限额的路由前缀 → 可能造成部分目的地不可达。优于措施 1 的地方：粒度更细，保留了邻居关系与主要路由。这也是防御「邻居误发全表」的标准防护配置。
3	Turn off Software Redundancy 关闭软件冗余	`redundancy` `mode none`	放弃软件级冗余 → 失去进程级故障切换保护。释放的资源相当可观（备用进程占用的内存），但这是把「可用性保险」换成了「当下的可用性」。应作为最后手段。

QFP 数据面 DRAM：三条缓解措施

#	措施	命令	代价（第一性原理分析）
1	Reduce NAT max-entries 降低 NAT 表项上限	`ip nat translation max-entries <number of entries>` `nat64 translation max-entries <number of entries>`	放弃超额的并发 NAT 会话 → 用户新建连接可能失败。但这是「可控的失败」：你知道上限在哪，可以据此规划。回顾 5.6 节 Internet Gateway 用例——这正是那里的核心瓶颈资源。
2	Reduce FW session limit 降低防火墙会话上限	`parameter-map type inspect global` `session total <count>`	放弃超额的防火墙会话。直接影响 DIA/DCA 用例（第五章用例 ④）的并发承载能力。
3	Reduce FNF cache limit 降低 NetFlow 缓存上限	`flow monitor M1` `cache entries <number of entries>`	放弃部分流量可见性（统计精度下降）。这通常是三条中代价最小的一条—— 因为它牺牲的是「观测能力」而非「业务能力」。如需紧急降耗，建议从这一条开始。

基于上述分析的缓解措施优先级建议（从代价最小到最大）：

FNF 缓存上限 — 只损失可见性，不损失业务
BGP maximum-prefix — 细粒度，保留邻居关系
NAT / FW 会话上限 — 影响业务并发，但可控可预测
Shutdown routing peers — 损失路径冗余
关闭软件冗余 — 损失高可用保护，最后手段

注：此优先级为基于资料的推导性建议，实际执行请结合具体业务权重与变更管理流程评估。

6.3 数据面利用率：两条命令，以及一个求平均包长的技巧

Socratic Question 39

show platform resources 告诉你 QFP 内存的使用率。但 QFP 的处理能力用到几成了？这个数字在哪里看？

命令一：全局数据面利用率概览

G2#show platform hardware qfp active datapath utilization summary

CPP 0:
                       5 secs        1 min        5 min       60 min
Input:  Total (pps)   2247717      1429213      1533059       212076
              (bps)  9134674616   5808330472   6230309296    861840936
Output: Total (pps)   2247875      1430428      1532668       212095
              (bps)  9135341648   5813199336   6228747712    861932720
Processing:
        Load (pct)         99           61           67            9
Crypto/IO:
        RX Load (pct)       0            0            0            0
        TX Load (pct)      41           26           28            5
        Idle    (pct)      58           73           71           94

字段	含义	如何解读（关键）
`Input / Output Total (pps)`	入向/出向包速率（每秒包数）	pps 是数据面的真实负载指标，比 bps 更重要——因为每个包的处理开销大致固定，与包大小关系不大
`Input / Output Total (bps)`	入向/出向比特速率	带宽视角。与 pps 结合可求平均包长（见下方技巧）
`Processing: Load (pct)`	包处理负载百分比	这是本命令最关键的一行。示例中 5 秒值为 99% — 已接近饱和，而 60 分钟值仅 9% → 典型的突发型负载
`Crypto/IO: RX / TX Load`	收发方向的 I/O 负载	示例中 RX 恒为 0、TX 为 41% → 说明该设备出方向压力显著大于入方向
`Idle (pct)`	空闲百分比	与 Load 互补。注意 Processing Load 99% 时 Idle 仍为 58% → 这两个指标衡量的是不同维度，不可简单相加
四个时间窗口 `5 secs / 1 min / 5 min / 60 min`	不同粒度的滑动平均	四列并排是本命令的精髓：它让你一眼看出「这是持续高负载，还是瞬时突发」——两者的处置方式完全不同

Slide 73 明确给出的实用技巧：`bps / pps / 8 = 平均包长（字节）`

为什么这个技巧重要？回顾 4.7 节—— 所有性能指标都标注了测试包长（@512B 或 @EMIX）。 但你现网的真实平均包长是多少？如果不知道，性能指标就无法用于容量规划。

用示例数据算一遍（5 分钟窗口）：

Input bps = 6,230,309,296
Input pps = 1,533,059

平均包长 = 6,230,309,296 ÷ 1,533,059 ÷ 8
         = 4,063.6 ÷ 8
         ≈ 508 字节

结论：该设备现网平均包长约 508 字节，与官方 @512B 测试基准高度接近。 这意味着可以直接采用官方 @512B 的性能数字进行容量规划，无需折算。

反之，如果算出来的平均包长明显偏小（例如 200 字节）： 说明现网小包占比高，实际可达吞吐将低于 @512B 的标称值—— 因为同样的带宽下 pps 更高，而 pps 才是数据面的真实负载。

这是一个把「厂商标称值」翻译成「我这台设备的真实余量」的必备步骤。

命令二：逐核心利用率明细

G2#show platform hardware qfp active datapath infrastructure sw-cio

Core Utilization over preceding 5767441.1701 seconds
----------------------------------------------------

ID:        0      1      2      3      4      5      6      7      8      9     10     11     12     13
% PP:   0.71   0.15   0.16   0.18   0.16   0.17   0.17   0.17   0.16   0.16   0.17   0.16   0.00   0.00
% RX:   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00
% TM:   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00   1.40   1.59
% IDLE:99.29  99.85  99.84  99.82  99.84  99.83  99.83  99.83  99.84  99.84  99.83  99.84  98.60  98.41

从这个输出能读出架构信息

仔细看 Core 12 和 13： 它们的 % PP（Packet Processing）为 0.00，但 % TM（Traffic Manager）分别为 1.40 和 1.59。 而 Core 0–11 完全相反：有 PP 负载，TM 为 0。

这直接印证了 4.3 节的 Dynamic Resource Provisioning 架构： 核心是有明确角色分工的—— Core 0–11 承担包处理，Core 12–13 专职流量管理（队列与调度）。

三个字段的含义：

% PP — Packet Processing，包处理占用
% RX — 接收方向处理占用
% TM — Traffic Manager（队列/调度）占用
% IDLE — 空闲

排障价值（推导）： 如果发现某几个核心的 IDLE 明显低于其他核心（负载不均），这可能指向流分发不均——例如少数大流量「大象流」（elephant flow）被哈希到了同一个核心上。

而这也解释了 4.2 节架构图里那个不起眼的标注：「Non-Strict Flow Based Distribution」（非严格基于流的分发）—— 正是为了缓解这种因严格按流哈希而导致的负载倾斜问题。

6.4 加密引擎与 Secure Firewall：两个专项监控

加密引擎利用率（Slide 75）

Socratic Question 40

你正在推进 PQC 迁移，全网启用 ML-KEM。如何在迁移过程中判断「加密引擎是否已成为新的瓶颈」？

G2#show platform hardware crypto-device utilization
Past crypto device utilization: utilization is for each crypto device,
                                pkts are combined number.

 1 min (percentage) : 7%
        (decrypt pkt): 19744614
        (encrypt pkt): 35508495

 5 min (percentage) : 8%
        (decrypt pkt): 98761304
        (encrypt pkt): 177577353

15 min (percentage) : 7%
        (decrypt pkt): 292639607
        (encrypt pkt): 526899471

观察点	示例数据	解读
利用率百分比	1min 7% / 5min 8% / 15min 7%	三个窗口高度一致 → 负载平稳，无突发。加密引擎余量充足
加密 vs 解密包数比	encrypt 35.5M vs decrypt 19.7M（1min）约 1.8 : 1	出向加密流量约为入向解密的 1.8 倍 → 该站点是流量发送方为主（如分支上传数据、或作为 Hub 向多 Spoke 分发）
命令输出的重要说明	「utilization is for each crypto device, pkts are combined number」	这句注释极其关键：百分比是单个加密设备的，包数是所有加密设备的合计。不要用「总包数 ÷ 单设备百分比」做任何推算
SNMP 监控	CISCO-ENTITY-PERFORMANCE-MIB	可用于纳入自动化监控体系

PQC 迁移期的专项监控建议（基于本节推导）：

回顾 2.4 节——ML-KEM 增加的开销主要在密钥协商阶段，而非数据加解密阶段（数据面仍是 AES-GCM-256）。

因此在迁移期应分别关注两个不同的指标：

加密引擎利用率（本命令）→ 反映数据面加解密压力。 PQC 迁移对此影响应当很小——如果显著上升，需排查是否有其他变更。
控制面 CPU（show platform resources）→ 反映密钥协商压力。 PQC 迁移的开销主要体现在这里，尤其在隧道大规模重协商时（如 DMVPN 海量 spoke 同时重建，或 IKE SA 生命周期到期集中重协商）。

因此建议：在 PQC 割接窗口期，同时监控这两个指标，并特别关注 IKE SA 生命周期到期时刻的控制面 CPU 峰值。

Secure Firewall（Snort）资源监控（Slide 76）

内建 Secure Firewall 的检测引擎运行在服务面，有一套独立的监控命令。Slide 76 给出了三条：

! ---------- ① 确认 CPU 资源分配模板 ----------
G2#sh platform software cpu alloc
CPU alloc information:
  Control plane cpu alloc: 0-1
  Data plane cpu alloc:    0,10-23
  Service plane cpu alloc: 2-9
  Template used: CLI-service_plane_heavy

! ---------- ② 检查 UTD 引擎健康状态 ----------
G2#show utd engine standard status
Engine version     : 1.14.16_SV3.1.81.0_XEmain
Profile            : Cloud-High
System memory      :
    Usage : 5.8%
    Status: Green

Number of engines : 6
Engine    Running    Health    Reason
==============================================
Engine(#1):  Yes      Green     None
Engine(#2):  Yes      Green     None
Engine(#3):  Yes      Green     None
Engine(#4):  Yes      Green     None
Engine(#5):  Yes      Green     None
Engine(#6):  Yes      Green     None
==============================================
Overall system status: Green

! ---------- ③ 查看 Snort 进程 CPU 占用 ----------
G2#show processes cpu platform sorted | sec snort
20468  12655  451%   352%   248%  S  2319156  snort3

命令	关键字段	运维意义（第一性原理解读）
`sh platform software cpu alloc`	三类 CPU 的具体核心编号 CP: 0-1；DP: 0,10-23；SP: 2-9	验证 4.3 节的动态资源分配实际生效情况。注意 Core 0 同时出现在 CP 与 DP 列表中——说明存在共享核心
`sh platform software cpu alloc`	`Template used: CLI-service_plane_heavy`	确认当前采用的资源模板。如果一台设备开满了威胁防护但模板是 data_plane_heavy，这就是性能问题的根因，且改配置即可解决，无需换硬件。这是排查安全吞吐不达标时应第一个检查的项目。
`show utd engine standard status`	`Profile: Cloud-High`	检测规则集的资源档位。档位越高，检测越深入，资源消耗越大。这是「检测深度 vs 性能」的核心调节旋钮
	`System memory Usage: 5.8% / Status: Green`	UTD 子系统内存使用与健康状态
	`Number of engines: 6`	六个并行检测引擎实例。印证 4.1 节的结论——安全检测通过并行化而非串行化来获得性能
	`Overall system status: Green`	一行判定整体健康。建议将此字段作为安全服务可用性的核心监控项
`show processes cpu platform sorted \| sec snort`	`451% 352% 248%`	请注意：百分比超过 100% 是正常的。因为 snort3 是多核多进程运行——451% 意味着约占用 4.5 个核心的算力。三个数字通常对应不同时间窗口的平均值。判断依据不是「是否超过 100%」，而是「是否接近 Service plane 分配的核心总数 × 100%」（本例 SP 分配了 Core 2-9 共 8 核 → 上限约 800%）

精准定义

UTD（Unified Threat Defense）与 Snort

UTD 是 IOS XE 中承载威胁检测能力的容器化子系统，其检测引擎基于 Snort 3（业界标准的开源 IDS/IPS 引擎）。

为什么用容器化架构？ 回顾 4.6 节 —— IOS XE 支持 Container Apps 托管。 把检测引擎容器化的好处是：规则集与引擎版本可以独立于 IOS XE 主版本更新，安全响应速度不受操作系统升级周期的束缚。

而这也回到了第三章：这些容器镜像同样在 PQC 信任链内，由 OS 使用 ML-DSA-87 验签。

精妙类比

451% 是什么意思？

想象一家餐厅有 8 名厨师（Service plane 8 核）。

「451%」的意思是：某道菜的制作，平均同时占用了 4.5 名厨师。

这不是问题——除非它接近 800%。 因为那意味着所有 8 名厨师全部被这一道菜占满，再来订单只能排队。

所以监控这个数字的正确方式，是把它与「Service plane 分配了几个核心」放在一起看—— 单看百分比毫无意义。

6.5 运维检查清单：PQC 迁移期专用

整合第二章的验证方法与本章的资源监控，形成一份可直接执行的清单。

阶段一 · 迁移前基线采集（Before）

检查项	命令 / 方法	记录什么
控制面 CPU / 内存基线	`show platform resources`	正常时段与忙时的 Control Processor 与 DRAM 使用率
QFP DRAM 基线	`show platform resources`	QFP DRAM 使用率与绝对值
数据面处理负载基线	`show platform hardware qfp active datapath utilization summary`	四个时间窗口的 Processing Load
现网平均包长	用 `bps ÷ pps ÷ 8` 计算	用于校准官方 @512B 性能指标的适用性
加密引擎基线	`show platform hardware crypto-device utilization`	三个时间窗口的利用率、加解密包数比
资源分配模板	`sh platform software cpu alloc`	确认 Template 与该站点用例匹配
隧道总数	IKEv2 SA 统计	作为 PQC 覆盖率的分母
SSH KEX 算法列表	`show ip ssh`	迁移前的算法清单

阶段二 · 迁移中验证（During）

检查项	命令 / 方法	合格判据
PQC 隧道验证	`show crypto ikev2 sa detailed`	`PQC Key Exchange` 字段非空，且显示 ML-KEM-768/1024。仅 `Status: READY` 不构成量子安全证明
PQC 覆盖率 KPI	PQC 隧道数 ÷ 隧道总数	作为迁移进度的唯一有效指标。「设备升级台数」不等价
MACsec / EAP-TLS	`show dot1x interface <intf> detail`	`EAP Method = TLS`、`Auth SM State = AUTHENTICATED`、`PAE = BOTH`；并确认 `access-session pqc-type pqc` 已配置
SSH PQC KEX	`show ip ssh`	KEX Algorithms 列表中 mlkem 算法排在前列
控制面 CPU 峰值	`show platform resources`（高频采样）	重点观察 IKE SA 生命周期到期时刻——集中重协商是 PQC 开销的峰值时点
IKE 报文分片	IKEv2 SA 详情中的 Fragmentation 状态	使用 mlkem1024 时尤需关注。参考 RFC 9242 Intermediate Exchange 的设计动机

阶段三 · 迁移后收尾（After）—— 最容易被遗漏的一步

检查项	动作	为什么不能省
移除 `optional` 关键字	确认 PQC 覆盖率达 100% 后，将 `pqc mlkem768 optional` 改为 `pqc mlkem768`	关闭降级通道。保留 `optional` 意味着攻击者可通过降级攻击迫使会话退回量子脆弱模式——见 2.4 节
清理 SSH 弱 KEX 算法	在兼容性允许前提下，从 KEX 列表中移除纯传统算法	同上——算法协商列表里留着弱算法，等于给降级攻击留了门。见 2.7 节
资源对比复盘	将迁移后各项资源指标与阶段一基线对比	量化 PQC 的真实资源开销，为其他站点的迁移提供依据
纳入常态化巡检	将 `PQC Key Exchange` 字段检查加入自动化巡检	防止配置漂移。设备重装、配置回滚、新增站点都可能引入非 PQC 隧道
MIB / Telemetry 接入	CISCO-PROCESS-MIB、CISCO-ENTITY-QFP-MIB、CISCO-ENTITY-PERFORMANCE-MIB	从人工巡检转为自动化监控，覆盖控制面、QFP 内存、加密引擎三个维度

本章的核心方法论，可以浓缩成三句话：

控制面与数据面是两套独立的资源体系——只看 show proc cpu 会漏掉一半。
「功能正常」与「量子安全」是两个独立的验证维度——UP/DOWN 不构成安全证明。
所有缓解措施都是「主动放弃一部分能力」——请按代价从小到大依次使用，并知道自己放弃了什么。

第六章金句

再先进的架构，也需要有人知道该盯着哪几个数字。资源耗尽从不发出警报——它只会在某个周二凌晨，让新连接静静地建不起来。

结语 · Epilogue

回到那个周二凌晨

让我们回到本文开头的那个场景。同一条隧道，同一个凌晨 2 点，同一个攻击者。 只有一件事变了。

攻击者依然在跨境骨干网的中转节点上，把流量原封不动地复制了一份，连同隧道建立时那几十毫秒的密钥协商报文，一起写进了硬盘，然后离开。 IDS 依然没有告警。防火墙日志依然干净。

五年后，第一台 CRQC 上线。攻击者打开那块硬盘，用量子计算机从 ECDH 公开值中反推出了私钥——这一步他成功了。

然后他停在了那里。

因为那次握手的会话密钥，不是由 ECDH 单独派生的。它由 DH Shared Secret ＋ ML-KEM Shared Secret 共同派生。

而 ML-KEM 的那一半，从来没有以可被数学反推的形式出现在信道上。

攻击者手里有一块塞满了密文的硬盘，以及一把只能打开其中一半锁的钥匙。 而这把锁，是需要两把钥匙同时转动的。

这就是全文六章推导出的那一件事

我们花了六章的篇幅，从「加密的本质是经济学而非物理学」开始，一路推到「哪几个 show 命令必须纳入巡检」。如果只能带走一条结论，我希望是这一条：

安全工程的价值，不在于让攻击者「无法开始」，而在于让攻击者「无法完成」。

HNDL 攻击的前半段——窃取——我们阻止不了。能阻止的，只有后半段：解密。

而阻止后半段的唯一时机，是在数据被发出去的那一刻。

三条可以立刻开始的行动

本周算一道减法

不需要采购、不需要立项。只需要回答第一章 1.4 节那个公式：

X（数据保密年限）＋ Y（迁移所需年限）＞ Z（距 Q-Day）？

挑出你最敏感的三类数据（并购、研发、身份、工控），分别填入 X。如果任何一类的结果为「是」，你就已经获得了立项所需的全部论据。

这一步的成本是零，但它决定了后两步是否会被批准。

本季度从 SSH 开始

成本最低、见效最快、价值密度最高。

回顾 2.7 节：一条 SSH 录像的价值，可能等于全网的控制权。而加固它只需一条配置命令：

ip ssh server algorithm kex mlkem1024nistp384-sha384 ...

然后是隧道：在 IKEv2 proposal 中加入 pqc mlkem768 optional，用 show crypto ikev2 sa detailed 的 PQC Key Exchange 字段统计覆盖率。

本财年改一条采购标准

白皮书的建议是「纳入产品刷新周期」，而非全网替换。所以真正要改的不是预算， 而是采购技术规范书里的一行字。

把 2.9 节末尾那三个问题写进去：

启动链用什么算法验签？
MACsec 密钥从哪来？
管理面 KEX 是什么？

答不出 LMS / ML-DSA-87 / ML-KEM 的设备，就是半栈。

Key Takeaways（Slide 78 还原）

BRKXAR-2027 最后一页用五条要点收束了整场分享。读完前六章之后，你应该能看出每一条背后对应的是哪一章的推导：

Cisco 官方要点	对应本文章节	一句话解读
Secure Networking Processor Leapfrogs up to 10x higher throughput, AI-ready	第四章 4.1–4.2	10 倍不是频率提升，是路径缩短——In-line Crypto engine 让加密不必绕道 CPU
Post-quantum Secure WAN Full-stack PQC	第二章全章	「全栈」的判定标准：找不到任何一处裸用 RSA 的关键路径
Advanced Security NGFW & SASE with 6x threat protection throughput	第五章 5.5	8100 的 6 倍提升实质是能力跃迁——TLS Decryption 从「不支持」到「支持」
Operational Simplicity Managed by SD-WAN Manager and Cloud Control	第四章 4.6 · 第六章全章	架构上的统一（单镜像 + 动态资源分配），是运维上简化的前提
Industry's most advanced Secure Router Connect Secure WAN to every site	第五章 5.1	七种用例必须由同一产品线覆盖，因为客户网络按站点而非按用例划分

全文终章金句

你今天加密的每一比特，都可能在 2032 年被公开朗读。
但也可能不会——这取决于你在 2026 年的这一周，做了什么。

继续阅读：完整术语表 →

附录 A · Glossary

完整术语表

按六个类别分组，共 94 条。建议在阅读过程中随时回查，或作为团队内部培训与采购问询的标准词汇表。

A · 量子计算与密码学基础

术语	全称 / 中文	定义
Qubit	量子比特	亚原子粒子，可同时处于 0 和 1 的叠加态，使量子计算机能一次操作作用于指数级数量的状态组合
CRQC	Cryptanalytically Relevant Quantum Computer 具备密码分析相关能力的量子计算机	规模与纠错能力已足以破解现行公钥密码体系的量子计算机。今天并不存在。可在数分钟内破解 RSA-2048
Q-Day	量子日	CRQC 变为现实可用的那一天。业界估计出现在 2030–2035 年区间
HNDL	Harvest Now, Decrypt Later 先窃取，后解密	攻击者今天大规模采集并存储加密流量（尤其密钥协商报文），等 CRQC 可用后再统一解密。正在发生的攻击
PQC	Post-Quantum Cryptography 后量子密码	能够抵御量子计算机攻击的密码算法体系。核心思路是更换数学难题类型（格 / 哈希），而非加长密钥
Public-Key Cryptography	公钥（非对称）密码	使用成对但不相同的密钥。安全性依赖「正向易、反向极难」的数学难题。量子脆弱
Symmetric Cryptography	对称密码	加解密使用同一密钥。密钥无代数结构 → 量子穷举仅带来平方根加速 → AES-256 量子安全
Lattice-based	格密码	基于高度复杂的数学结构化格方程。目前不存在已知的高效量子算法可破解格问题
KEM	Key Encapsulation Mechanism 密钥封装机制	共享密钥由封装方单方面随机生成，再用对方公钥「封装」送达。与 DH 的「共同推导」模型不同
Hybrid Key Exchange	混合密钥交换	同时执行传统（DH/ECDH）与 PQC（ML-KEM）密钥交换，两者共享秘密共同派生会话密钥。任一未被攻破即安全
PPK	Postquantum Pre-shared Key 后量子预共享密钥	不通过公钥密码协商、而通过其他可信途径预先获得的量子安全密钥材料。从未上过公开信道 → 无法被反推
QKD	Quantum Key Distribution 量子密钥分发	使用外部密钥管理系统生成量子安全密钥。网络设备可通过 SKIP API 按需请求
SKIP	Secure Key Integration Protocol	网络设备向 QKD 系统按需请求密钥的 API 协议
KMS / SKS	Key Management Service Session Key Service	集成于网络设备自身、按需提供量子安全密钥的服务。Cisco 的实现称为 SKS，无需额外基础设施
PFS	Perfect Forward Secrecy 完美前向保密	每次重协商产生全新密钥。与 PQC 叠加防护：PFS 限制泄露时间窗口，PQC 保证窗口内密钥不可反推
Entropy	熵	随机性的度量。弱随机数生成（weak RNG）可瓦解整个加密体系——攻击者可预测系统将生成什么

B · 标准、算法与合规

术语	标准号	定义与用途
ML-KEM 原名 CRYSTALS-Kyber	FIPS 203	Module-Lattice-Based Key-Encapsulation Mechanism。通用加密 / 密钥封装。NIST 选它因密钥体积小、速度快。参数集：768（Level 3）、1024（Level 5）
ML-DSA 原名 CRYSTALS-Dilithium	FIPS 204	Module-Lattice-Based Digital Signature Algorithm。数字签名 / 身份认证。ML-DSA-87 为 Level 5 参数集。很可能成为主导标准
SLH-DSA 原名 SPHINCS+	FIPS 205	Stateless Hash-Based Digital Signature Algorithm。基于哈希的签名，作为数学路线多样化的保险
LMS	RFC 8554 NIST SP 800-208	Leighton-Micali Signatures。有状态、基于哈希的签名。CNSA 2.0 要求用于固件/软件签名。数学假设最保守 → 适合永不可换的硬件信任根
XMSS	—	Extended Merkle Signature System。与 LMS 并列，CNSA 2.0 允许用于固件签名
LDWM	Lamport–Diffie–Winternitz–Merkle	基于哈希的签名方案，与 LMS 同族，是其标准化之前的早期形态。白皮书指出许多现役 Cisco 设备已用它保护 Secure Boot——即现有设备并非在此环节完全暴露
CNSA 2.0	NSA 发布（2022）	Commercial National Security Algorithm Suite 2.0。规定 NSS 用产品的算法与时间表：网络设备建议 2026、强制 2030；固件签名建议 2025
NSS	—	National Security Systems。CNSA 2.0 的法定适用范围
FIPS	—	Federal Information Processing Standards。认证周期平均 2 年以上——这是混合方案存在的重要现实理由
RFC 9370	IETF	Multiple Key Exchanges in IKEv2。混合密钥交换的协议基础。注：白皮书中该条目记为 RFC 9730，实施请以最新 RFC 编号为准
RFC 9242	IETF	Intermediate Exchange in IKEv2。专为传输大体积 PQC 公钥/密文而设计，缓解 IKE 报文分片问题
RFC 9190	IETF	EAP-TLS 相关标准，用于证书化 MACsec 加密
AES-256 / AES-GCM-256	CNSA 2.0 指定	批量加解密算法。PQC 迁移中无需更改——对称算法本已量子安全
SHA-384 / SHA-512	CNSA 2.0 指定	系统级哈希。哈希长度加倍以抵御量子搜索的平方根加速
NetSecOpen	第三方认证机构	统一测试方法的安全效力认证。8375-E-G2 与 8235-G2 获认证：IPS 有效率 99.23%、恶意软件检出率 99.79%

C · Trustworthy 与硬件信任

术语	全称 / 中文	定义
Root of Trust	信任根	信任链中唯一不接受验证的元素。可信性来自物理不可篡改性而非密码学验证
Chain of Trust	信任链	每一段代码在被允许运行前，都由上一段已验证的代码验证其完整性。始于 Root of Trust
Microloader (ML)	微加载器	CPU 执行的第一段代码，受抗篡改硬件保护。8000 系列使用 LMS 签名验证 Bootloader
Secure Boot	安全启动	逐级验签的启动流程。检测到篡改则直接终止启动（fail-closed），而非降级运行
Hardware-Anchored	硬件锚定	指微加载器不存放于可刷写 Flash，而固化在抗篡改硬件中
Image Signing	镜像签名	两步：① 哈希算法计算镜像指纹 ② 用 Cisco 私钥加密该指纹生成数字签名。可在运行时（at runtime）复查
TAm	Trust Anchor module 信任锚模块	专有抗篡改芯片。提供四项服务：SUDI 身份、非易失安全存储、RNG、密钥管理与加密服务
SUDI	Secure Unique Device Identifier 安全唯一设备标识	X.509v3 证书，含 PID 与序列号，制造时植入，链接至公开可识别根 CA。三重防护：制造时植入 + 密码学绑定特定芯片 + 私钥永不导出
LDevID / LSC	Local Device Identity Locally Significant Certificate	企业自签发的设备身份证书，可轮换、可吊销。设备需先用 SUDI 向企业 CA 证明「我是正品」才能获取
Runtime Defenses (RTD)	运行时防御	针对运行期代码注入攻击。三种互补手段：ASLR、BOSC、X-space。思路是让漏洞「存在但不可利用」
ASLR	Address Space Layout Randomization	地址空间布局随机化。使攻击者硬编码的内存地址失效
BOSC	Built-in Object Size Checking	内建对象大小检查。在操作前检查目标对象实际大小 → 缓冲区溢出在发生前被拒绝
X-space	Executable Space Protection	可执行空间保护。严格区分「可写不可执行」与「可执行不可写」内存区域
Taint	污染 / 植入	在制造、运输、仓储环节向正品设备植入未授权硬件或软件成分。比假冒更难检测——设备本身是真的
Value Chain Security	价值链安全	Cisco 供应链安全项目。三类手段（物理安全实践、逻辑安全流程、安全技术）应对三类威胁（taint、counterfeit、IP 滥用），覆盖全生命周期
Tamper Detection	篡改检测	物理开箱入侵检测（open chassis）。补上 Secure Boot 与 SUDI 都无法覆盖的硬件植入盲区

D · 芯片与系统架构

术语	全称 / 中文	定义
secure networking processor	安全网络处理器	8000 系列分支与园区线的核心 SoC。五大集成：In-line Crypto engine、AI/ML engine、Traffic Manager、NIC、Trust Anchor
QFP	Cisco Quantum Flow Processor	数据中心线的高性能 ASIC。3rd Gen：224 PPE × 4 线程 = 896 线程、16 加密引擎、240G 聚合 I/O、支持 4x 级联
PPE	Packet Processor Engine	包处理引擎。承担转发、IPsec、QoS、NAT 等数据面功能
In-line Crypto engine	在线加密引擎	加密引擎位于数据面，PPE 可直接调用，无需绕道 CPU。这是 IPsec 性能提升最高达 10 倍的物理原因
Programmable uCode	可编程微码	硬件加速的同时保留软件灵活性。价值：protect IP（保护知识产权）与 feature parity（功能对等）。也是 PQC 能落地于既有硅片的前提
Dynamic Resource Provisioning	动态资源分配	按「意图」在 CP / PPE / SP 之间重分配算力。两种模板：data-plane-heavy 与 service-plane-heavy
CP / DP / SP	Control / Data / Service Plane	三类资源平面。CP：路由与 SD-WAN；DP：转发与加密；SP：NGFW、IPS、AppQoE、TCPOpt/DRE、vDSP
FIA	Feature Invocation Array 功能调用数组	数据包在 PPE 内依次经过的功能链。可查：`show platform hardware qfp active interface if-name <name>`
MCAM / sTCAM	硬件查找表	高速匹配存储器，用于 ACL 与转发查找。8650 支持 380K ACEs
Traffic Manager (TM)	集成流量管理器	入向：分类、计费、限速、超订缓冲；出向：缓冲、调度、流控、时间戳。提供流队列支持有状态功能
Non-Strict Flow Based Distribution	非严格基于流的分发	硬件包分发策略，缓解因严格按流哈希导致的核心负载倾斜（大象流问题）
Dying gasp	临终喘息	设备断电瞬间用残余电能发出最后一条告警。区分「断电」与「链路故障」，直接决定运维派单方向
Single Image (universalk9)	单一镜像	同一镜像支持两种模式：Autonomous mode（传统自治）与 SD-WAN Controller mode
UTD	Unified Threat Defense	IOS XE 中承载威胁检测的容器化子系统，引擎基于 Snort 3。规则集与引擎可独立于 OS 版本更新

E · 网络协议与用例

术语	全称 / 中文	定义
IKEv2	Internet Key Exchange v2	IPsec 的密钥协商协议。PQC 通过 RFC 9370 + 9242 在此层植入 → 所有基于 IKEv2 的方案自动获得量子安全
DMVPN	Dynamic Multipoint VPN	结合 mGRE + IPsec/IKEv2 + NHRP 实现大规模 IPsec VPN。支持 Hub-Spoke 与按需 Spoke-Spoke 隧道，避免 N² 配置
FlexVPN	—	基于标准的 IKEv2 框架，用于站点加密互联
MACsec	IEEE 802.1AE	二层线速加密。由硬件在 L2 MAC 层完成 → 零性能损失。8200 系列起全内建端口支持（上一代需专用 NIM 模块）
MKA	MACsec Key Agreement	MACsec 会话密钥协商协议。密钥派生链：MSK → CAK → SAK
EAP-TLS	Extensible Authentication Protocol - TLS	802.1X 认证方法。PQC MACsec 的必要条件——ML-KEM 植入此处的 TLS 1.3 握手，使整条派生链量子安全
VRF	Virtual Routing and Forwarding	同一物理设备上维护多份完全独立的路由表。不同 VRF 即使 IP 重叠也不互通
HQoS	Hierarchical QoS 分层服务质量	三要素：Priority Queue（严格优先）、BRR%（剩余带宽比例）、Tail Drop / RED（丢包策略）
RED	Random Early Detection	队列快满前随机提前丢弃，避免 TCP 全局同步（所有连接同时重传导致再次拥塞）
AAR	Application Aware Routing 应用感知路由	SD-WAN 核心能力。补上传统路由的两个盲区：不知道是什么流量、不知道路径实时质量。吞吐定义 = IPsec + QoS + DPI + FNF
DIA / DCA	Direct Internet / Cloud Access	分支直接上网 / 直连云，不回传总部。前提是本地具备完整威胁防护能力
TP	Threat Protection	性能指标定义：100% DIA-NAT + App Aware FW + IPS + URLF + AMP，测试包长 @EMIX
50% DIA-TP	—	更接近真实分支的指标：IPsec + QoS + DPI + FNF + DIA-NAT 50% + ZBFW + IPS + URL-F + AMP + TG
SSE	Security Service Edge	云安全服务边缘。8000 系列支持 Auto Tunnel + HA：8 Active / 8 Standby，含 CASB、FWaaS、DLP、SWG 等
Fast Reroute (FRR)	快速重路由	<50ms 收敛。50ms 沿袭自传输网（SDH/SONET）保护倒换惯例，是「故障对上层业务透明」的行业经验阈值
Ingress Classification	入向分类	在入口一次分类、全程携带，保证跨多跳的端到端（e2e）QoS 一致性
mGig	Multi-Gigabit	同一物理口协商 1G/2.5G/5G/10G。保护现有布线投资，支撑从 1GE 平滑迁移
XGS-PON / VAI / VAP	—	接入介质类型。VAI = VDSL over ISDN；VAP = VDSL over POTS

F · 运维与监控

命令 / 术语	用途	关键字段或要点
`show platform resources`	一屏总览控制面与数据面健康	Control Processor（W 80% / C 90%）、RP DRAM（W 88% / C 93%）、QFP DRAM（W 85% / C 95%）；状态：H / W / C
`show ... qfp active datapath utilization summary`	数据面处理负载	Processing Load (pct) 为核心指标；四个时间窗口（5s/1m/5m/60m）用于区分持续高负载 vs 瞬时突发
bps ÷ pps ÷ 8	求现网平均包长	用于校准官方 @512B 性能指标是否适用于你的流量特征。平均包长偏小 → 实际吞吐低于标称值
`show ... datapath infrastructure sw-cio`	逐核心利用率	% PP / % RX / % TM / % IDLE。可发现核心负载倾斜与核心角色分工
`show platform hardware crypto-device utilization`	加密引擎利用率	百分比是单个加密设备的，包数是所有设备的合计——不可互相推算。加解密包数比可判断流量方向特征
`sh platform software cpu alloc`	确认资源分配模板	`Template used` 是排查安全吞吐不达标时应第一个检查的项目
`show utd engine standard status`	威胁检测引擎健康	`Profile`（规则集档位）、`Number of engines`、`Overall system status: Green`
`show processes cpu platform sorted \| sec snort`	Snort 进程 CPU 占用	百分比超过 100% 是正常的（多核多进程）。判据是「是否接近 SP 核心数 × 100%」
`show crypto ikev2 sa detailed`	PQC 隧道验证	`PQC Key Exchange: ML-KEM-768` 字段非空 = 唯一可用于审计的硬证据。`Status: READY` 不构成安全证明
`show ip ssh` / `show dot1x interface ... detail`	SSH 与 MACsec 验证	KEX 算法列表顺序即优先级；`EAP Method = TLS`、`PAE = BOTH`、`AUTHENTICATED`
PQC 覆盖率	迁移进度 KPI	PQC 隧道数 ÷ 隧道总数。「设备升级台数」不是等价指标——隧道两端都支持才算数
CISCO-PROCESS-MIB	SNMP 监控	RP 上的 CPU 与内存
CISCO-ENTITY-QFP-MIB	SNMP 监控	QFP 内存
CISCO-ENTITY-PERFORMANCE-MIB	SNMP 监控	加密引擎利用率
`optional`	PQC 非严格强制	迁移期必需（保证兼容），迁移完成后必须移除——否则留下降级攻击通道

附录 B · References

资料来源与免责说明

本文全部技术论断均来自以下四份 Cisco 官方文档。推导性内容（标注为「推导」「推断」「建议」处）为基于资料的分析延伸，非官方声明。

① BRKXAR-2027

Inside Cisco 8000 Series Secure Routers: Architecture, Use Cases, and Innovation

Jason Yang, Principal Technical Marketing Engineer · Cisco Live 技术分会材料（共 82 页）

本文引用范围：第一章（Slide 34–36）、第二章（Slide 8–18, 30, 37–48）、第三章（Slide 30）、第四章（Slide 20–33, 51–53）、第五章（Slide 4, 49–50, 55–69）、第六章（Slide 71–76, 78）

已逐页核对本文所有 Slide 编号、配置示例、性能数值与英文引文均已与原始 PDF 逐页比对。

② Cryptography in a Post-Quantum World

How organizations can safeguard against the looming quantum threat

Cisco 后量子密码白皮书

本文引用范围：第一章全章（Q-Day、HNDL、NIST 算法、CNSA 2.0 时间表、实施挑战、PPK 三方案、两阶段最佳实践）、第三章 3.9

③ Cisco Trustworthy Technologies Data Sheet

Trustworthy 技术数据手册

本文引用范围：第三章全章（信任链、镜像签名、Secure Boot 六步、TAm 四项服务、SUDI 三重防护、Runtime Defenses、风险清单、Value Chain Security）

④ Cheat Sheets（8100 / 8200 / 8300 系列）

Cisco 8000 Series Secure Router Cheat Sheet

本文引用范围：第四章 4.7–4.8（各型号接口、性能、扩展性、物理规格、PQC 能力标注）

重要免责说明

性能数据为临时值。BRKXAR-2027 多处标注 「All numbers are interim, final numbers subject to change at FCS」。正式方案设计与容量规划请以 FCS 正式发布规格为准。
CLI 与输出格式可能变化。PQC 配置相关页面标注 「Some CLI implementation and show outputs may change」。实施前请查阅对应 IOS XE 版本的官方配置指南。
版本可用性。本文标注的 XE 26.1.1 / 26.1.2 / 26.1.3 / 26.2.1 为资料中的计划版本，实际可用性请与 Cisco 确认。
RFC 编号差异。关于 IKEv2 多重密钥交换，白皮书记为 RFC 9730，BRKXAR-2027 记为 RFC 9370。实施时请以最新 RFC 编号为准。
规格数据差异。产品组合图（Slide 51–53）按性能分组显示，同组内多型号共享该组最高值；Cheat Sheet 提供单型号具体值。两者不一致时以具体型号的 FCS 规格为准。
推导性内容标识。文中所有「第一性原理拆解」「推导」「建议」「基于上述分析」等标注段落，为作者基于资料的分析延伸，不代表 Cisco 官方立场。
合规认证状态。资料中的「NIST Compliant」「PQC ready」「Post-Quantum Safe」描述的是算法实现，不等同于已取得 FIPS / CNSA 2.0 认证。受硬性合规约束的采购，请以设备在采购时点的实际认证状态为准（参见第三章 3.9）。

返回文首 ↑

一场没有警报响起的“抢劫”

这篇长文要回答的三个问题

问题一 · 风险

问题二 · 信任

问题三 · 创新

关于本文的方法论

量子风暴：我们赖以生存的数学假设，正在被拆掉一根承重柱

1.1 第一问：我们今天的“安全”，究竟建立在什么之上？

第一性原理拆解：安全 = 经济学，而非物理学

公钥密码（Public-Key Cryptography）

把两杯水倒在一起

1.2 第二问：量子计算到底改变了什么？

第一性原理拆解：从“逐条试”到“同时试”

CRQC（Cryptanalytically Relevant Quantum Computer）

迷宫里的“分身术”

1.3 第三问：那我们所有的加密都完蛋了吗？

第一性原理拆解：结构性弱点 vs 无结构强度

1.4 第四问：既然 Q-Day 还要等好几年，为什么现在就必须动手？

第一性原理拆解：三个时间变量的赛跑

HNDL（Harvest Now, Decrypt Later）

偷走一个打不开的保险箱

1.5 第五问：谁在定规则？时间表到底有多紧？

CNSA 2.0 时间表（原始表格还原）

1.6 第六问：NIST 究竟批了什么？三个算法各管什么事？

KEM（Key Encapsulation Mechanism，密钥封装机制）

公开的邮筒与只有你有的钥匙

CNSA 2.0 具体要求了哪些算法？

1.7 第七问：为什么标准已定，却还要用“混合”方案？

理由一：新算法可信，但新实现未必

理由二：FIPS 认证等不起

混合密钥交换（Hybrid Key Exchange）

两把锁串联的银行金库

支撑混合方案的 IETF 协议标准

1.8 第八问：如果我的设备今天还不支持 PQC，我就只能等着被 HNDL 吗？

第一性原理拆解：既然“通道”危险，就绕开通道

PPK（Postquantum Pre-shared Key）

寄信之前先约好的“书页密码”

Cisco 给出的两阶段最佳实践

近期 · Near Term 先搞定传输层

中长期 · Then 再落实硬件量子安全

1.9 本章小结：把风险模型压缩成一页

Cisco 的答卷：什么叫「Full-Stack PQC」，以及它凭什么敢这么说

2.1 第九问：什么叫「全栈」？只在 VPN 上做 PQC，缺口在哪？

第一性原理拆解：安全链条的强度 = 最弱一环的强度

Full-Stack PQC（全栈后量子）

换锁，还是换整栋楼的门窗？

2.2 第十问：ML-KEM 到底怎么工作？三步走通一次量子安全握手

第一性原理拆解：为什么「格」抗量子？

Encaps / Decaps 与 DH 的本质差异

DH = 调色，KEM = 快递保险箱

2.3 第十一问：混合密钥交换在报文层面究竟发生了什么？

2.4 落地一：IKEv2 IPsec 的 PQC 配置与验证（逐行解读）

深入：optional 这个关键字为什么至关重要？

第一性原理拆解：迁移期的「双语能力」

ML-KEM 参数集：768 vs 1024

保险柜的钢板厚度

验证：如何证明这条隧道真的量子安全了？

2.5 落地二：DMVPN 与 FlexVPN —— 为什么配置「几乎一样」？

第一性原理拆解：分层解耦的回报

DMVPN（Dynamic Multipoint VPN）

枢纽机场 + 临时直飞航线

DMVPN 场景配置（Slide 43）

FlexVPN 场景配置（Slide 44）

2.6 落地三：Quantum-safe MACsec —— 为什么它需要拉上 EAP-TLS？

第一性原理拆解：追问「MACsec 的密钥从哪来」

MACsec（IEEE 802.1AE）

IPsec 是快递包裹，MACsec 是加密专线管道

配置全解（Slide 46）

验证输出解读

2.7 落地四：SSH —— 别忘了那个你每天都在用的入口

第一性原理拆解：从算法名字读出整个混合结构

KEX（Key Exchange）算法协商

两人见面前先对语言清单

2.8 落地五：SD-WAN 三平面 —— 为什么数据面「一个字都不用改」？

2.9 全栈 PQC 能力矩阵：一页看清覆盖版图

哪些型号具备 PQC 能力？

8100 系列 小型分支

8200 / 8300 系列 中大型分支

8650 100G 数据中心

Cisco Trustworthy：在讨论加密之前，先讨论「这台设备值不值得信」

深入：`optional` 这个关键字为什么至关重要？

8100 系列小型分支

8200 / 8300 系列中大型分支

Single Image：`universalk9`