简介面向数据中心网络工程师与思科技术学习者的技术讲座资料聚焦 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 / TomahawkX9600-R / X9600-RX 用 JerichoDNX后者是多芯片架构、大转发表、深包缓冲与 VOQ、基于信元的 fabric。两条路线并存说明选型时不能只看「是不是 Nexus 9000」还要看具体型号背后是哪颗芯片。维度Cloud Scale自研Broadcom XGS / DNX商用代表平台X9700-EX/FX、9300-EX/FX/FX2X9400/X9400-S、X9600-R/RX核心卖点特性深度、遥测、智能缓冲生态可得性、公开 SDK、大表深缓冲转发特性ACI、Segment Routing、单次 VXLAN 路由通用数据中心转发遥测流表、流事件通知、SSX依平台而定提示复习时把「平台型号」和「芯片家族」做成两张对照表分别记不要混在一张表里背否则很容易把某个型号的特性安到错误的芯片上。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 个 100GLS1800FX 是 1.8T 芯片单个 Slice18 个 100G带 MACsecS6400 是 6.4T 芯片四个 Slice每个 Slice 16 个 100GLS3600FX2 是 3.6T 芯片两个 Slice每个 Slice 18 个 100G带 MACsec 和 CloudSec。ASIC总容量Slice 数每 Slice 端口加密能力典型承载LSE1.8T29 × 100G无X9700-EX 线卡、9300-EXLS1800FX1.8T118 × 100GMACsecX9700-FX 线卡、9300-FXS64006.4T416 × 100G无9364C TOR、E2 fabric 模块LS3600FX23.6T218 × 100GMACsec CloudSec9300-FX2这张表要背到什么程度至少要能回答「哪颗芯片是单 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 LookupTCAM / Flex Tile→ Ingress MAC → Load BalancingAFD / 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 LookupDMAC 是否为 Router MAC Step 2 Route Lookup(VRF, IPDA) → 精确匹配 VRF 最长匹配 IPDA 结果 ADJ_PTR 或 ECMP_PTR Step 3 MAC TableADJ_PTR → (输出 BD, 重写 MAC, 输出端口) Step 4 ECMP TableECMP_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 存储器位于灵活转发查表的前端。存储方式适用条目表项来源作用HRTIPv4 /32、IPv6 /128Flex Tile主机路由高速匹配LPM其他前缀长度Flex Tile含 pivot/trie常规前缀匹配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 不支持模块化 9500Multicast NBM 不支持 TOR。模板在系统初始化时定义改模板需要重启。# 查看当前路由模板示意具体命令以所用版本为准 show system routing template # 切换模板属于初始化配置需重启生效 # 复习重点记住模板名与「是否支持组播」「是否支持模块化平台」的对应关系提示模板这一节是考试高频点尤其容易考「哪个模板不支持组播」「哪个模板不支持 9500」。建议把模板名、组播支持、平台限制做成三列表格默写一遍。4.4 查表失败时看什么复习到这一层要能回答一个实操问题包没转发出去怎么判断卡在哪一步。按链路倒推先确认 Router MAC 是否命中未命中说明包根本没进 L3 流程再确认路由查表是否返回指针未返回说明前缀缺失或模板分配的表项不足再确认 MAC 表或 ECMP 表是否有对应条目缺失说明邻接未建立或组成员配置不全。这个倒推顺序比盲目抓包高效得多也是把架构知识转成排障能力的典型例子。5. 平台映射与易错点型号、模板与表项的对应关系架构知识最终要落到具体平台上否则复习就停在概念层。这一章把 ASIC 和平台型号对上再把最容易记错、漏记的点单独拎出来。梳理下来会发现大部分错误不是不理解原理而是把「芯片能力」和「平台能力」混为一谈或者忽略了模板和平台的限制条件。5.1 ASIC 到平台的映射LSE 对应 X9700-EX 模块化线卡和 9300-EX TORLS1800FX 对应 X9700-FX 线卡和 9300-FX TORS6400 对应 9364C TOR 和 E2 fabric 模块LS3600FX2 对应 9300-FX2 TOR。这个映射要能双向回忆给型号说芯片给芯片说型号。平台所用 ASIC形态X9700-EX 线卡LSE模块化线卡X9700-FX 线卡LS1800FX模块化线卡9300-EXLSETOR9300-FXLS1800FXTOR9300-FX2LS3600FX2TOR9364CS6400TORE2 fabric 模块S6400模块化 fabric映射记牢后很多判断题就变成查表题某型号是否支持 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 主机条目其余前缀长度归 LPMTCAM 兜底冲突。易漏点四以为查表结果是「先邻接后 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 交换机」开始把路径、查表、结果、缓冲、出口一路写下来写不下去的地方就是漏洞。下面这份清单按这个思路组织可以逐项打勾。检查项能复述的标准对应章节两条芯片路线说出自研与商用的代表平台和核心差异2.1四颗 ASIC默写容量、Slice 数、每 Slice 端口、加密能力3.1Slice 路径画出入向到出向的模块顺序3.2单播查表说出四步查表和两种指针的区别4.1三种 IP 表说清 HRT、LPM、TCAM 的分工4.2路由模板默写模板名及组播、平台限制4.3平台映射给型号说 ASIC给 ASIC 说型号5.1易错五条每条能说出「为什么错、怎么补」5.2查漏补缺的具体做法先做 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 指针和邻接指针记成了先后关系画到第三步就卡住回头重读才发现是二选一这个错误后来再没犯过。希望这份清单帮到你把地图装进脑子比背下所有命令都值。本文还有配套的精品资源点击获取 
长河君 · 2026/10/30 5:11:46 · 阅读 1.2k Nexus 9000 Cloud Scale架构解析：从ASIC芯片到Packet Walk转发全流程
简介面向数据中心网络工程师与思科技术学习者的技术讲座资料聚焦 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 / TomahawkX9600-R / X9600-RX 用 JerichoDNX后者是多芯片架构、大转发表、深包缓冲与 VOQ、基于信元的 fabric。两条路线并存说明选型时不能只看「是不是 Nexus 9000」还要看具体型号背后是哪颗芯片。维度Cloud Scale自研Broadcom XGS / DNX商用代表平台X9700-EX/FX、9300-EX/FX/FX2X9400/X9400-S、X9600-R/RX核心卖点特性深度、遥测、智能缓冲生态可得性、公开 SDK、大表深缓冲转发特性ACI、Segment Routing、单次 VXLAN 路由通用数据中心转发遥测流表、流事件通知、SSX依平台而定提示复习时把「平台型号」和「芯片家族」做成两张对照表分别记不要混在一张表里背否则很容易把某个型号的特性安到错误的芯片上。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 个 100GLS1800FX 是 1.8T 芯片单个 Slice18 个 100G带 MACsecS6400 是 6.4T 芯片四个 Slice每个 Slice 16 个 100GLS3600FX2 是 3.6T 芯片两个 Slice每个 Slice 18 个 100G带 MACsec 和 CloudSec。ASIC总容量Slice 数每 Slice 端口加密能力典型承载LSE1.8T29 × 100G无X9700-EX 线卡、9300-EXLS1800FX1.8T118 × 100GMACsecX9700-FX 线卡、9300-FXS64006.4T416 × 100G无9364C TOR、E2 fabric 模块LS3600FX23.6T218 × 100GMACsec CloudSec9300-FX2这张表要背到什么程度至少要能回答「哪颗芯片是单 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 LookupTCAM / Flex Tile→ Ingress MAC → Load BalancingAFD / 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 LookupDMAC 是否为 Router MAC Step 2 Route Lookup(VRF, IPDA) → 精确匹配 VRF 最长匹配 IPDA 结果 ADJ_PTR 或 ECMP_PTR Step 3 MAC TableADJ_PTR → (输出 BD, 重写 MAC, 输出端口) Step 4 ECMP TableECMP_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 存储器位于灵活转发查表的前端。存储方式适用条目表项来源作用HRTIPv4 /32、IPv6 /128Flex Tile主机路由高速匹配LPM其他前缀长度Flex Tile含 pivot/trie常规前缀匹配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 不支持模块化 9500Multicast NBM 不支持 TOR。模板在系统初始化时定义改模板需要重启。# 查看当前路由模板示意具体命令以所用版本为准 show system routing template # 切换模板属于初始化配置需重启生效 # 复习重点记住模板名与「是否支持组播」「是否支持模块化平台」的对应关系提示模板这一节是考试高频点尤其容易考「哪个模板不支持组播」「哪个模板不支持 9500」。建议把模板名、组播支持、平台限制做成三列表格默写一遍。4.4 查表失败时看什么复习到这一层要能回答一个实操问题包没转发出去怎么判断卡在哪一步。按链路倒推先确认 Router MAC 是否命中未命中说明包根本没进 L3 流程再确认路由查表是否返回指针未返回说明前缀缺失或模板分配的表项不足再确认 MAC 表或 ECMP 表是否有对应条目缺失说明邻接未建立或组成员配置不全。这个倒推顺序比盲目抓包高效得多也是把架构知识转成排障能力的典型例子。5. 平台映射与易错点型号、模板与表项的对应关系架构知识最终要落到具体平台上否则复习就停在概念层。这一章把 ASIC 和平台型号对上再把最容易记错、漏记的点单独拎出来。梳理下来会发现大部分错误不是不理解原理而是把「芯片能力」和「平台能力」混为一谈或者忽略了模板和平台的限制条件。5.1 ASIC 到平台的映射LSE 对应 X9700-EX 模块化线卡和 9300-EX TORLS1800FX 对应 X9700-FX 线卡和 9300-FX TORS6400 对应 9364C TOR 和 E2 fabric 模块LS3600FX2 对应 9300-FX2 TOR。这个映射要能双向回忆给型号说芯片给芯片说型号。平台所用 ASIC形态X9700-EX 线卡LSE模块化线卡X9700-FX 线卡LS1800FX模块化线卡9300-EXLSETOR9300-FXLS1800FXTOR9300-FX2LS3600FX2TOR9364CS6400TORE2 fabric 模块S6400模块化 fabric映射记牢后很多判断题就变成查表题某型号是否支持 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 主机条目其余前缀长度归 LPMTCAM 兜底冲突。易漏点四以为查表结果是「先邻接后 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 交换机」开始把路径、查表、结果、缓冲、出口一路写下来写不下去的地方就是漏洞。下面这份清单按这个思路组织可以逐项打勾。检查项能复述的标准对应章节两条芯片路线说出自研与商用的代表平台和核心差异2.1四颗 ASIC默写容量、Slice 数、每 Slice 端口、加密能力3.1Slice 路径画出入向到出向的模块顺序3.2单播查表说出四步查表和两种指针的区别4.1三种 IP 表说清 HRT、LPM、TCAM 的分工4.2路由模板默写模板名及组播、平台限制4.3平台映射给型号说 ASIC给 ASIC 说型号5.1易错五条每条能说出「为什么错、怎么补」5.2查漏补缺的具体做法先做 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 指针和邻接指针记成了先后关系画到第三步就卡住回头重读才发现是二选一这个错误后来再没犯过。希望这份清单帮到你把地图装进脑子比背下所有命令都值。本文还有配套的精品资源点击获取