企业官网建设流程全解析

简介：面向数据中心网络工程师与思科技术学习者的技术讲座资料，聚焦 Nexus 9000 系列模块化与 TOR 交换机的架构解析，帮助读者理解云规模 ASIC 的硬件设计逻辑与高性能转发实现方式。压缩包内为 1 个 PDF 文件，约 3.56MB，完整收录 Cisco Live BRKARC-3222 演讲内容，由杰出工程师 Tim Stevenson 主讲。内容涵盖数据中心与硅策略、云规模架构与 ASIC、转发特性、Nexus 9500/9300 平台对比以及 Packet Walks 数据包路径分析，并对比 Broadcom XGS、DNX 与思科自研 Cloud Scale 芯片的差异，涉及智能缓冲区、流式遥测、隧道封装等硬件能力。已有 286 人学习，适合希望深入掌握思科数据中心交换硬件细节、排查转发路径问题或规划网络架构的从业者参考。

1. 数据中心交换芯片的体系地图：从 Cloud Scale 架构到 Packet Walk

很多人复习数据中心交换时，习惯从命令行和配置手册入手，结果背了一堆 show 命令，却说不清一个包从入口到出口到底经过了哪些硬件模块。真正系统的复习路径应该反过来：先建立芯片级的知识地图，再往上叠配置和特性。这份笔记围绕 Nexus 9000 的 Cloud Scale 架构展开，核心线索只有一条——数据包在 ASIC 内部怎么走。把这条线走通，转发查表、Flex Tile、缓冲区、遥测这些模块自然各归其位。适合正在系统学数据中心网络、准备认证考试，或者需要给团队做技术梳理的人。下面按「架构总览 → ASIC 与 Slice → 转发查表 → 平台映射 → 易错点 → 复习清单」逐层展开。

2. Cloud Scale 架构总览：自研芯片与商用芯片的分界线

复习 Nexus 9000 最先要建立的一个认知是：这个产品线不是铁板一块，它内部按芯片来源分成两条技术路线。搞混这两条线，后面所有关于表项容量、缓冲区行为、遥测能力的判断都会跟着错。Cloud Scale 是自研 ASIC 路线，Broadcom XGS 和 DNX 是商用芯片路线，两者在架构取舍上差异很大，考试和实际选型都绕不开这个分界。

2.1 两条芯片路线的定位差异

自研 Cloud Scale ASIC 的出发点是把硬件设计和软件特性绑在一起做差异化。原文列出的优势包括：硬件与软件、产品方向的紧密对齐，ACI 策略模型与拥塞感知的 flowlet 交换，灵活的转发 tile，单次隧道封装，内置加密（MACsec、CloudSec），智能缓冲区（DBP / AFD / DPP），以及面向遥测的流表与流统计导出。这些能力不是通用商用芯片能随手给的，它们需要芯片层面预留结构和接口。

商用芯片路线则强调另一套价值：Broadcom SOC 方案、广泛的行业可得性、公开的 SDK。X9400 / X9400-S 用 Trident2+ / Tomahawk，X9600-R / X9600-RX 用 Jericho（DNX），后者是多芯片架构、大转发表、深包缓冲与 VOQ、基于信元的 fabric。两条路线并存，说明选型时不能只看「是不是 Nexus 9000」，还要看具体型号背后是哪颗芯片。

提示：复习时把「平台型号」和「芯片家族」做成两张对照表分别记，不要混在一张表里背，否则很容易把某个型号的特性安到错误的芯片上。

2.2 为什么自研芯片值得单独复习

自研芯片的意义不在于「自己造的」这四个字，而在于它决定了哪些特性是硬件原生、哪些是软件模拟。原文点出的几个方向值得逐条理解：ACI 策略模型配合拥塞感知 flowlet 交换，意味着策略执行和负载均衡在转发面完成；灵活转发 tile 意味着同一颗芯片可以通过模板切换表项用途；单次隧道封装意味着 VXLAN 等封装在一次查表流程内完成，不需要二次环回；内置加密意味着 MACsec 和 CloudSec 不依赖外挂器件。

这些特性组合起来，构成了「云规模」的实际含义：高端口密度减少设备占地、多速率接口（100M/1/10/25/40/50/100G）提供灵活性、富转发特性支撑 ACI 与 Segment Routing、灵活转发规模让同一平台有多种扩容选择、智能缓冲做动态流量优化、内置遥测支撑容量规划与故障定位。复习时如果只能记住一句话，就记「自研芯片把差异化特性下沉到了转发面」。

2.3 本笔记的覆盖边界

原文明确划定了范围：只讲采用 Cloud Scale ASIC 的最新一代 Nexus 9000，包括 9500 模块化交换机的 Cloud Scale 线卡和 9300 Cloud Scale TOR。不覆盖第一代 Nexus 9000 的 ASIC 与平台架构、9500 的商用硅架构、其他 Nexus 平台以及另一条产品线。这个边界很重要，因为第一代和商用硅平台的表项组织方式与 Cloud Scale 不同，拿旧笔记套新平台是复习中最常见的翻车方式之一。后面所有关于 Slice、Flex Tile、查表流程的描述，都限定在 Cloud Scale 范围内。

3. Cloud Scale ASIC 与 Slice：芯片内部的并行结构

理解 Cloud Scale 的关键概念是 Slice。原文对它的定义很克制：一个自包含的转发复合体，控制单颗 ASIC 上的一部分端口，内部分为入向和出向功能，每个 Slice 的入向连接到所有 Slice 的出向，Slice 之间的互连提供无阻塞的任意到任意连接。这段话信息密度很高，拆开来看就是芯片的并行化设计思路。

3.1 四颗芯片的 Slice 组织方式

Cloud Scale 家族有四名成员，它们的区别主要体现在 Slice 数量和每 Slice 的端口能力上。LSE 是 1.8T 芯片，两个 Slice，每个 Slice 9 个 100G；LS1800FX 是 1.8T 芯片，单个 Slice，18 个 100G，带 MACsec；S6400 是 6.4T 芯片，四个 Slice，每个 Slice 16 个 100G；LS3600FX2 是 3.6T 芯片，两个 Slice，每个 Slice 18 个 100G，带 MACsec 和 CloudSec。

这张表要背到什么程度？至少要能回答「哪颗芯片是单 Slice」「哪颗是四 Slice」「哪两颗带加密」。单 Slice 意味着没有 Slice 间互连开销，四 Slice 意味着更高的并行度和更复杂的互连结构，这个差异会直接影响对转发路径的理解。

3.2 Slice 内部的两级转发路径

每个 Slice 的转发路径可以拆成入向和出向两段。入向依次经过包解析器（Packet Parser）、查表流水线（Lookup Pipeline）、入向 MAC；查表流水线内部又分入向分类、转发查表、查表键生成，其中 TCAM 和 Flex Tile 承担具体表项匹配，部分芯片还有流表（仅 LSE / LS1800FX / LS3600FX2）。查表结果出来后，经过负载均衡与 AFD / DPP 处理，送往出向 Slice。

出向则经过出向缓冲、排队、调度，然后是复制、出向 MAC、包重写、出向策略。S6400 和 LS3600FX2 还支持 SSX（流统计导出）。这条路径的复习价值在于：它把「查表」和「缓冲」两个最容易混淆的阶段分开了。查表决定包去哪里，缓冲决定包什么时候走，两者在硬件上是不同模块，故障现象也不同。

入向：Parser → Ingress Classification → Forwarding Lookup（TCAM / Flex Tile）→ Ingress MAC → Load Balancing（AFD / DPP）→ Slice Interconnect 出向：Egress Buffering / Queuing / Scheduling → Replication → Egress MAC → Packet Rewrites → Egress Policy

注意：上面用文本块表示路径是为了避免图形依赖，实际复习时建议自己手画一遍，把 TCAM、Flex Tile、流表三个查表组件标在入向流水线的正确位置上。

3.3 Slice 互连为什么是无阻塞的

原文强调 Slice 互连提供非阻塞的任意到任意连接。这句话的实际含义是：任何一个 Slice 的入向都能以线速把流量送到任何其他 Slice 的出向，不会因为跨 Slice 转发而产生内部拥塞瓶颈。对复习者来说，这个设计解释了一个常见疑问——为什么多 Slice 芯片在跨端口转发时性能不下降。答案在于互连结构本身是按全互联设计的，而不是靠调度算法弥补。

理解这一点后，再看 S6400 的四 Slice 结构就顺了：64 个 100G 端口被分成四组，每组 16 个，组内转发走本 Slice，组间转发走互连，互连不成为瓶颈。反过来，如果某平台在跨 Slice 场景下出现异常，排查方向应该是互连与调度，而不是端口本身。

4. 转发查表与 Flex Tile：一次查表的完整链路

转发是这份材料里最值得反复读的部分，因为它把「硬件怎么查表」讲到了表项级别。复习时如果只记住「有路由表」，等于没学；要记住的是查表键是什么、查表结果是什么、结果又指向哪张表。这条链路走通，IP 单播转发、ECMP、主机路由这些概念就串起来了。

4.1 IP 单播转发的四步查表

原文给出的流程是：收到包后先做 Router MAC 查表，判断目的 MAC 是不是路由器 MAC；如果是，触发 L3 查表。L3 查表在硬件上对 VRF 做精确匹配、对目的 IP 做最长匹配，查表结果返回邻接指针（指向 MAC 表）或 ECMP 指针。MAC 表里存的是输出 BD、重写 MAC 和输出端口；如果是 ECMP 指针，则再查 ECMP 表决定用哪个 ECMP 组。

Step 1 Router MAC Lookup：DMAC 是否为 Router MAC？ Step 2 Route Lookup：(VRF, IPDA) → 精确匹配 VRF + 最长匹配 IPDA 结果 = ADJ_PTR 或 ECMP_PTR Step 3 MAC Table：ADJ_PTR → (输出 BD, 重写 MAC, 输出端口) Step 4 ECMP Table：ECMP_PTR → 选择 ECMP 组成员

这四步里最容易记错的是第二步的匹配方式：VRF 是精确匹配，IPDA 是最长匹配，两者在同一级查表里完成。另一个易错点是查表结果的两种形态——邻接指针和 ECMP 指针是二选一，不是先后关系。理解这一点，才能解释为什么 ECMP 场景下 MAC 表查的是组成员而不是单一端口。

4.2 三种 IP 表存储方式的分工

Cloud Scale 用三种方式存 IP 前缀，分工明确。HRT 是哈希表，用于 IPv4 /32 和 IPv6 /128 的主机条目，由 Flex Tile 提供表项。LPM 是传统的前缀加掩码条目，或者「pivot + trie」tile 的组合，用于其他前缀长度，同样由 Flex Tile 提供。TCAM 则处理溢出和哈希冲突，是传统 TCAM 存储器，位于灵活转发查表的前端。

这个分工解释了一个常见困惑：为什么主机路由和普通前缀路由要分开存。哈希表适合精确匹配、查得快，但只对固定长度有效；LPM 适合变长前缀，但结构更复杂。两者配合，再让 TCAM 兜底，构成完整的 IPv4/IPv6 单播查表能力。

4.3 Flex Tile 与路由模板的对应关系

Flex Tile 是「可互换的表项池」，tile 的数量和每个 tile 的条目数因 ASIC 而异。它承载的功能包括 IPv4/IPv6 单播 LPM、IPv4/IPv6 单播主机路由表、IPv4/IPv6 组播 (*,G) 和 (S,G)、MAC 地址与邻接表、ECMP 表、ACI 策略。所谓「灵活」，指的是同一批 tile 可以通过模板重新分配用途。

模板通过system routing template配置，截至 NX-OS 7.0(3)I7(2) 有这些选项：Default、Dual-stack host scale、Internet peering、LPM heavy、MPLS heavy、Multicast heavy、Multicast NBM。其中 Dual-stack host scale 和 Internet peering 不支持 IP 组播；Dual-stack host scale 不支持模块化 9500；Multicast NBM 不支持 TOR。模板在系统初始化时定义，改模板需要重启。

# 查看当前路由模板（示意，具体命令以所用版本为准） show system routing template # 切换模板属于初始化配置，需重启生效 # 复习重点：记住模板名与「是否支持组播」「是否支持模块化平台」的对应关系

提示：模板这一节是考试高频点，尤其容易考「哪个模板不支持组播」「哪个模板不支持 9500」。建议把模板名、组播支持、平台限制做成三列表格默写一遍。

4.4 查表失败时看什么

复习到这一层，要能回答一个实操问题：包没转发出去，怎么判断卡在哪一步。按链路倒推：先确认 Router MAC 是否命中，未命中说明包根本没进 L3 流程；再确认路由查表是否返回指针，未返回说明前缀缺失或模板分配的表项不足；再确认 MAC 表或 ECMP 表是否有对应条目，缺失说明邻接未建立或组成员配置不全。这个倒推顺序比盲目抓包高效得多，也是把架构知识转成排障能力的典型例子。

5. 平台映射与易错点：型号、模板与表项的对应关系

架构知识最终要落到具体平台上，否则复习就停在概念层。这一章把 ASIC 和平台型号对上，再把最容易记错、漏记的点单独拎出来。梳理下来会发现，大部分错误不是不理解原理，而是把「芯片能力」和「平台能力」混为一谈，或者忽略了模板和平台的限制条件。

5.1 ASIC 到平台的映射

LSE 对应 X9700-EX 模块化线卡和 9300-EX TOR；LS1800FX 对应 X9700-FX 线卡和 9300-FX TOR；S6400 对应 9364C TOR 和 E2 fabric 模块；LS3600FX2 对应 9300-FX2 TOR。这个映射要能双向回忆：给型号说芯片，给芯片说型号。

映射记牢后，很多判断题就变成查表题：某型号是否支持 CloudSec，看它用的 ASIC 是否带 CloudSec；某型号是否支持 SSX，看 ASIC 是否在 SSX 支持列表里。

5.2 易漏点：五个最容易记混的地方

易漏点一：把 Slice 数当成端口组数随便记。为什么漏：Slice 是转发复合体，不是简单的端口分组，单 Slice 芯片（LS1800FX）没有 Slice 间互连，四 Slice 芯片（S6400）有。怎么补：记 Slice 时同时记「有无互连」和「每 Slice 端口数」，用 3.1 的表格默写。

易漏点二：忽略路由模板的平台限制。为什么漏：模板列表看起来只是名字，限制条件藏在脚注里。怎么补：把「Dual-stack host scale 不支持组播且不支持 9500」「Multicast NBM 不支持 TOR」单独抄成两行，考前只看这两行。

易漏点三：把 HRT 和 LPM 的适用范围记反。为什么漏：两者都由 Flex Tile 提供，容易笼统记成「Flex Tile 存路由」。怎么补：记住 HRT 只管 /32 和 /128 主机条目，其余前缀长度归 LPM，TCAM 兜底冲突。

易漏点四：以为查表结果是「先邻接后 ECMP」。为什么漏：流程图上两个指针画在一起，容易理解成顺序关系。怎么补：明确二者是二选一，邻接指针直接进 MAC 表，ECMP 指针进 ECMP 表再选成员。

易漏点五：把第一代 Nexus 9000 的架构套到 Cloud Scale 上。为什么漏：平台同名，笔记混用。怎么补：复习前先确认材料覆盖范围，第一代 ASIC 与商用硅架构不在本笔记范围内，遇到不确定的型号先查它用哪颗芯片。

注意：这五条里前三条是记忆型错误，后两条是理解型错误。记忆型的靠默写表格解决，理解型的要靠把 4.1 的查表链路亲手画一遍。

5.3 缓冲区与遥测的复习位置

智能缓冲（DBP / AFD / DPP）和遥测（流表、流事件通知、SSX）在原文里属于 Cloud Scale 的特性清单，复习时容易只记名词不记归属。正确的记法是：智能缓冲位于出向的缓冲、排队、调度阶段，解决的是拥塞时的丢包与公平性问题；遥测的流表和 SSX 位于查表与出向路径上，解决的是可视性问题。把这两个特性挂到 3.2 的路径图上，比单独背名词牢固得多。

6. 复习清单：从 Packet Walk 倒推查漏补缺

复习到最后，最有效的方法不是再读一遍材料，而是拿一张白纸，从「一个包进入 Cloud Scale 交换机」开始，把路径、查表、结果、缓冲、出口一路写下来，写不下去的地方就是漏洞。下面这份清单按这个思路组织，可以逐项打勾。

查漏补缺的具体做法：先做 3.1 和 5.1 两张表的默写，错一个就回到对应小节重读；再做 4.1 的查表链路口述，卡在哪一步就重点看那一步的匹配方式和结果形态；最后做 5.2 的五条自测，能说出「为什么漏」才算过关。整个过程控制在半小时内，比通读一遍材料效率高。

自测顺序（建议）： 1. 默写 ASIC 表（3.1）→ 错项回读 2. 默写平台映射表（5.1）→ 错项回读 3. 口述单播查表四步（4.1）→ 卡点回读 4. 复述路由模板限制（4.3）→ 错项回读 5. 过一遍易错五条（5.2）→ 能解释原因即通过

我自己的习惯是每次复习这类芯片架构材料，都强制先画一遍 Packet Walk 再翻笔记，画不出来的地方就是这次要补的地方。有一次自测时把 ECMP 指针和邻接指针记成了先后关系，画到第三步就卡住，回头重读才发现是二选一，这个错误后来再没犯过。希望这份清单帮到你，把地图装进脑子，比背下所有命令都值。

本文还有配套的精品资源，点击获取