简介这份 PDF 是思科 Nexus 9000 系列交换机的芯片级架构讲义面向数据中心网络工程师、Cisco 认证备考者以及希望深入理解云规模交换硬件的技术人员重点说明新一代模块化交换机和 TOR 交换机如何借助定制 ASIC 实现高吞吐、低时延与可扩展转发。压缩包共 1 个 PDF 文件大小约 3.56MB内容取自 Cisco Live 技术分享由杰出工程师 Tim Stevenson 讲解便于按章节查阅。资料围绕数据中心与硅策略、Cloud Scale 架构与 ASIC、关键转发特性、9500/9300 平台对比及 Packet Walks 展开并涉及智能缓冲、流式遥测、VXLAN、ACI 策略模型等硬件加速能力。已有 286 人学习适合在选型、排错和架构复盘时查阅。1. N9K 芯片级资料不是产品彩页先看清它到底拆什么很多人拿到《N9K 芯片级介绍 - 2018.pdf》第一反应是找配置命令翻两页却发现满篇都是切片、Flex Tile、HRT/LPM、Packet Walk于是把它归到“架构科普”里吃灰。这份资料真正值钱的地方是把 9000 系列 Cloud Scale 平台从“端口数量和转发性能”拉回到芯片内部一个包从入端口进来经过哪个 slice、查哪张表、命中 HRT 还是 LPM、什么时候走 TCAM、ECMP 指针怎么落到 MAC 表全部串成一条可验证的路径。它适合正在做数据中心交换机选型、线卡能力核对、路由规模规划的人也适合排障时想弄明白“为什么模板一改就要重启”的一线工程师。别把它当配置手册把它当芯片级排障地图用后面几章的表格和检查点才有意义。2. 从自研硅片到 Slice 架构为什么先看这张“芯片地图”2.1 自研 ASIC 的差异不在跑分而在单次隧道封装和智能缓冲这份资料开篇没有急着列型号而是先讲数据中心和硅策略。原因很直接同样标称 1.8T 或 6.4T 的交换芯片商用硅方案和自研硅方案在功能落点上差别很大。商用硅通常强调广泛行业可用性、公开 SDK 和多芯片架构适合快速铺产品线自研硅则把硬件设计和软件功能绑得更紧资料里点名了几个关键能力策略化数据中心的拥塞感知 flowlet 切换、灵活的转发 tile、单次隧道封装、内置加密、智能缓冲以及流表遥测和流统计导出。对做网络规划的人来说这些词不是营销话术它们决定了你在 VXLAN 路由、MACSEC 加密、Telemetry 采集和突发流量缓冲上要不要额外加板卡、要不要绕开某些线卡。单次隧道封装值得单独说。传统叠加网络里一个包从接入到核心可能要经历多次封装和解封装每次都要查表、改写、排队时延和芯片资源都被吃掉。自研芯片把这步做在硬件转发路径里好处是转发面少一次“拆包再包”的往返坏处是它对芯片流水线有强依赖你在规划时如果只看端口密度不看这个平台是否支持单次封装和对应的隧道终结能力后面做跨 Pod 流量模型就容易翻车。智能缓冲也是同理资料里提到的 DBP、AFD、DPP 不是三个缩写摆在一起好看而是分别对应动态缓冲、近似公平丢弃和动态优先级调整这类拥塞管理动作。它们的价值在突发流量和 incast 场景下才显现平时看接口利用率看不出来。我把自研硅和商用硅的差异压成一张表方便选型时对照维度自研 Cloud Scale 芯片商用硅方案功能与软件耦合硬件按策略模型和遥测需求定制依赖商用芯片路线图和 SDK隧道封装强调单次隧道封装多按芯片能力分阶段实现加密内置 MACSEC/CloudSec 能力按芯片型号分布取决于具体芯片和板卡缓冲与拥塞智能缓冲DBP/AFD/DPP 等机制通常提供标准缓冲配置遥测流表、流表事件、流统计导出能力随芯片和软件版本变化这张表不是让你背参数而是提醒你看到“支持 VXLAN”不等于“支持单次 VXLAN 路由”看到“支持 Telemetry”也不等于“支持流表级遥测”。资料里把 flow table 限定在 LSE、LS1800FX、LS3600FX2 这几颗芯片上S6400 则对应 SSX 流统计导出。选型时把芯片型号和功能表对一遍比只看整机 datasheet 靠谱。2.2 Slice 不是分区Ingress/Egress 与 Slice Interconnect 的非阻塞关系这份资料里最容易读错的概念是“Slice”。很多人把它理解成把端口切成几个 VLAN 组或者把芯片分成几个独立分区。资料的定义更硬Slice 是单颗 ASIC 上自包含的转发复合体控制该 ASIC 的一部分端口内部再分为 Ingress 和 Egress 功能每个 Slice 的 Ingress 都连接到所有 Slice 的 EgressSlice Interconnect 提供任意到任意的非阻塞互连。换句话说Slice 是芯片内部的“转发子系统”不是外部业务分区。你在一台交换机上看到 18 个 100G 端口可能来自 1 个 18 端口的 Slice也可能来自 2 个 9 端口的 Slice这两种账本对突发流量和故障域的影响不一样。资料给了四个芯片的切片账本我整理成下面这张表芯片总容量切片结构典型落点加密能力LSE1.8T2 个切片每切片 9 x 100GX9700-EX 模块化线卡、9300-EX TOR资料未强调 MACSECLS1800FX1.8T1 个切片18 x 100GX9700-FX 模块化线卡、9300-FX TOR带 MACSECS64006.4T4 个切片每切片 16 x 100G9364C TOR、E2 fabric modules资料未强调 MACSECLS3600FX23.6T2 个切片每切片 18 x 100G9300-FX2 TORMACSEC CloudSec这张表最容易被误读的是“1.8T 芯片有两个 9 x 100G 切片”和“1.8T 芯片有一个 18 x 100G 切片”。两者总容量一样但前者把端口分散到两个 slice后者把 18 个 100G 放在一个 slice 里。Slice 内部有独立的 ingress 查表、缓冲、队列和调度资源slice 之间通过 interconnect 做非阻塞互连。对大多数东西向流量这种设计没问题但如果你做的是单流大带宽或者多打一场景就要看单个 slice 的 ingress 到 egress 路径会不会成为局部热点。资料里反复画 Ingress Slice 到 Egress Slice 的连线不是为了好看而是让你在 Packet Walk 时能指出包从哪个 slice 进、到哪个 slice 出、中间有没有跨 interconnect。还有一个细节Slice 的 Ingress 连接到所有 Slice 的 Egress这意味着跨 slice 转发在芯片内是允许的而且设计目标是非阻塞。但“非阻塞”说的是芯片互连能力不等于整机所有端口在任何流量模式下都不丢包。出端口方向的缓冲、队列和调度仍然按 slice 分配拥塞时还是要看智能缓冲和 AFD/DPP 怎么动作。把 Slice 当成“芯片内的小交换机”来理解很多现象就顺了同一个 slice 内的端口互访路径短跨 slice 的端口互访要过 interconnect如果某个 slice 的 egress 队列被打满其他 slice 的 ingress 再空也可能在这一个出端口上排队。2.3 从系统初始化到模板路由模板为什么必须重启才生效Flex Tile 是这份资料里另一个高频词。它不是一张固定的表而是一个“可 fungible 的表项池”芯片型号不同tile 数量和每个 tile 的表项数不同同一颗芯片也可以通过“system routing template”把 tile 配置成不同功能组合比如 IPv4/IPv6 单播最长前缀匹配、主机路由表、组播 (*,G) 和 (S,G)、MAC/邻接表、ECMP 表、策略表等。资料列出的模板包括 Default、Dual-stack host scale、Internet peering、LPM heavy、MPLS heavy、Multicast heavy、Multicast NBM。这里面有几个限制必须记牢Dual-stack host scale 不支持模块化 9500Internet peering 不支持 IP 组播Multicast NBM 不支持 TOR带星号的模板还有各自的适用边界。模板为什么必须重启因为它在系统初始化时决定 Flex Tile 的功能划分等于在芯片启动阶段把表项池切成不同用途。运行中改模板不是改一个软件开关而是改转发面表项的组织方式已经下发的路由、邻接和组播表项都要重新分布所以资料明确写“defined at system initialization – reboot required to change profile”。血泪经验是变更窗口里只留了配置回滚时间没留重启时间模板改完业务没起来最后只能整机重启影响面比预期大。我的做法是先把当前模板、当前前缀规模、当前主机路由数量记录下来再评估目标模板的限制最后把重启和回滚步骤写进变更单。配置片段可以这样示意实际命令以设备帮助为准# 查看当前路由模板与表项使用情况命令名随版本可能略有差异 show system routing template show forwarding tables # 规划变更先记录业务前缀和主机路由规模 # 再切换模板切换后必须重启才生效 system routing template dual-stack-host-scale # 重启设备使模板生效 reload这段配置的逻辑是先用查看命令确认当前模板和表项水位再切换模板最后通过重启让芯片按新模板重新初始化。参数说明上模板名不是随便选的dual-stack host scale 适合 IPv4/IPv6 主机路由多的场景但资料明确它不支持模块化 9500LPM heavy 适合大量长前缀路由但会挤占其他表项空间Multicast heavy 适合组播表项多的场景但 Internet peering 模板又不支持 IP 组播。选模板的本质是“把 Flex Tile 的表项池往你最需要的表上倾斜”没有全能模板。提示改模板前先把当前配置和表项水位导出重启后再对比一次。不要只看模板名字先看资料里那张“模板支持矩阵”尤其是模块化和 TOR 的差异。3. ASIC 家族与平台映射LSE、LS1800FX、S6400、LS3600FX2 怎么对号入座3.1 四个芯片的切片与端口账本1.8T/6.4T/3.6T 不是唯一指标选型时最容易犯的错是只看总容量。1.8T、3.6T、6.4T 当然重要但这份资料把切片结构、端口组合、加密能力和遥测能力放在同一张桌上意思很明确同样容量芯片的“形状”不同适合的场景也不同。LSE 是 1.8T、2 个切片、每切片 9 x 100G落在 X9700-EX 模块化线卡和 9300-EX TOR 上LS1800FX 也是 1.8T但它是 1 个切片、18 x 100G并且带 MACSEC落在 X9700-FX 线卡和 9300-FX TOR 上S6400 是 6.4T、4 个切片、每切片 16 x 100G落在 9364C TOR 和 E2 fabric modules 上LS3600FX2 是 3.6T、2 个切片、每切片 18 x 100G带 MACSEC CloudSec落在 9300-FX2 TOR 上。把这四颗芯片放在一起看你会发现两个分水岭。第一个分水岭是“切片数量与单切片端口数”LSE 和 LS3600FX2 都是多切片S6400 是四切片LS1800FX 是单切片。单切片的好处是 18 个 100G 端口在芯片内部走同一个 ingress/egress 复合体路径简单多切片的好处是单个 slice 的端口数少故障域和局部拥塞的影响面可能更小跨 slice 流量走 interconnect。第二个分水岭是“加密与遥测”LS1800FX 和 LS3600FX2 明确带 MACSECLS3600FX2 还带 CloudSecflow table 只在 LSE、LS1800FX、LS3600FX2 上出现S6400 对应的是 SSX 流统计导出。你在做加密组网或者流表遥测时不能拿 S6400 的端口密度去套 LS3600FX2 的加密能力反过来也不行。资料里还有一条平台边界这份内容聚焦 Cloud Scale ASIC 的新一代 9500 模块化线卡和 9300 TOR不覆盖第一代 9000 平台架构也不覆盖 9500 商用硅架构和其他平台。这句话在选型时很关键。你如果在现网里混用了 X9400、X9600-R 这类商用硅线卡再拿这份资料的切片和 Flex Tile 逻辑去套就会对不上。正确做法是先确认线卡和芯片家族再看对应章节。资料里把 X9400/X9400-S 归到商用 Broadcom XGS 方案把 X9600-R/X9600-RX 归到商用 DNX 多芯片架构这两类和 Cloud Scale 的转发模型不是一套账本。选型会上如果有人拿“都是 9500 机箱”来论证线卡可以混插、能力可以平移这份资料就是最好的反例。3.2 模块化 9500 与 TOR 9300 的选型边界别把线卡能力当成整机能力模块化 9500 的选型逻辑和 TOR 完全不同。TOR 看的是单机端口组合、切片结构、加密和遥测模块化机箱则要看线卡、fabric module 和整机转发能力之间的匹配。资料里 X9700-EX 对应 LSEX9700-FX 对应 LS1800FX这两类线卡都走 Cloud Scale 芯片X9700-EX/FX 的切片账本和 TOR 上的同族芯片一致但落到机箱后还要看 fabric module 怎么连、线卡之间怎么跨 slice 转发。S6400 除了 9364C TOR还出现在 E2 fabric modules 里这说明同一颗芯片在不同形态里的角色不一样在 TOR 上是转发芯片在 fabric module 上是机箱互连的一部分。选型时如果把“线卡支持多少端口”直接当成“整机支持多少端口”忽略 fabric 侧的能力和收敛比后面扩容就会卡在互连上。9300 TOR 的边界更直接9300-EX 用 LSE9300-FX 用 LS1800FX9300-FX2 用 LS3600FX2。三者的端口组合和加密能力不同模板限制也不同。资料特别标注 Dual-stack host scale 不支持模块化 9500Multicast NBM 不支持 TOR这些限制在纯 TOR 组网和混合组网里影响不一样。我的习惯是先把业务按“主机路由多、长前缀多、组播多、加密多、遥测多”五类打标再拿芯片表去匹配而不是先选机箱再补功能。比如一个 Pod 里 IPv6 主机路由占比很高Default 模板可能很快把 HRT 用满这时候要看 Dual-stack host scale 能不能上如果这个 Pod 又是模块化 9500资料明确该模板不支持那就得回到 LPM heavy 或其他组合上做取舍或者调整主机路由的部署方式。3.3 端口速率与加密能力MACSEC、CloudSec 落在哪一层资料在芯片家族部分反复提多速率 100M/1/10/25/40/50/100G这是 Cloud Scale 系列的一个卖点同一平台可以通过不同端口形态适配服务器接入、存储接入和叶脊互连。但多速率不等于所有端口都能任意组合切片结构和端口宏才是最终约束。LSE 的 2 个 9 x 100G 切片、LS1800FX 的 1 个 18 x 100G 切片、S6400 的 4 个 16 x 100G 切片、LS3600FX2 的 2 个 18 x 100G 切片这些数字决定了你在一台机器上能拆出多少组 40G/100G也决定了跨切片流量的比例。做布线规划时把高速端口尽量均匀落到不同 slice 上可以减少单个 slice 的 egress 热点但如果你需要单切片内高密度互连LS1800FX 这种单切片 18 x 100G 反而更直接。加密能力要单独拉出来看。资料里 LS1800FX 标注 MACSECLS3600FX2 标注 MACSEC CloudSecLSE 和 S6400 没有在这个表里强调加密。MACSEC 是链路层加密CloudSec 更偏向隧道加密两者落点不同。你在做跨站点或跨租户加密时不能只问“这台交换机支不支持加密”要问“这条链路的加密是在端口上做还是在隧道上做芯片有没有内置能力会不会吃掉额外表项或吞吐”。资料把加密归到自研硅的差异化能力里和单次隧道封装放在一起讲意思就是加密不是外挂而是转发路径的一部分。选型时把加密能力写进芯片对照表比在配置阶段才发现某型号不支持要省很多事。4. 转发流水线拆解Parser、Flex Tile、HRT/LPM/TCAM 与 ECMP 怎么串起来4.1 Ingress 三段分类、查表、负载均衡与 AFD/DPP资料把 Ingress Forwarding Controller 拆成几块Packet Parser、Ingress Classification、Forwarding Lookup、Lookup Key、TCAM、Flex Tiles、Flow Table以及 Load Balancing 和 AFD/DPP。这个顺序不是画着好看它对应一个包进来后的真实动作。Parser 先解析报文头识别二层、三层、隧道字段Ingress Classification 给包打分类标记决定后续查哪类表、用什么 keyForwarding Lookup 拿 Lookup Key 去查 Flex Tile 和 TCAM命中后返回转发结果Load Balancing 和 AFD/DPP 则在出方向或拥塞时决定队列和丢弃策略。Flow Table 只在 LSE、LS1800FX、LS3600FX2 上出现用来支持流表级遥测和事件通知S6400 走的是 SSX 流统计导出这是两颗芯片在可观测性上的分叉。这段流水线对排障的意义是你不能一上来就怀疑芯片转发能力先看包在哪个阶段被改了。Parser 解析不出隧道字段后面的 Lookup Key 就不对Classification 没打对标记策略表就查不中Flex Tile 里没有对应表项包可能走 TCAM 溢出路径或者被丢ECMP 哈希不均衡可能是 Load Balancing 的哈希字段选得不对也可能是 AFD/DPP 在拥塞时做了调整。资料里把 AFD 和 DPP 放在 Ingress 负载均衡旁边说明它们不是单纯的出队列丢弃算法而是和芯片的缓冲管理、流感知调度绑在一起。你在看接口计数器时如果只看出方向丢包不看 ingress 侧的负载均衡和缓冲动作很容易把问题归错到“上联带宽不够”。4.2 IP 单播查表链Router MAC - VRFIPDA - ADJ/ECMP - MAC 表资料给了一条非常清晰的 IP 单播转发链先做 Router MAC Lookup判断目的 MAC 是不是路由器 MAC如果是触发 L3 查表。硬件对 VRF 做精确匹配对目的 IP 做最长匹配查表结果返回 adjacency pointer 或者 ECMP pointer。Adjacency pointer 指向 MAC 表MAC 表里有输出 BD、重写 MAC 和输出端口ECMP pointer 指向 ECMP 表选出 ECMP 组后再落到具体邻接。这个链条看起来简单但它把“路由表”和“邻接表”在硬件里的分工讲透了路由表负责“往哪走”邻接表负责“怎么改写、从哪出”ECMP 表负责“多路径选哪条”。排障时按这个链条逐段查比凭感觉快。第一步看 Router MAC 是否命中如果目的 MAC 不是路由器 MAC包可能走二层转发不会进 L3 查表第二步看 VRF 和 IPDA 的 Lookup Key 是否正确VRF 配错或者隧道终结后 VRF 映射错最长匹配再对也没用第三步看返回的是 ADJ 还是 ECMP如果业务预期走 ECMP 但返回的是单邻接说明路由或哈希配置有问题第四步看 MAC 表里的重写 MAC 和输出端口是否符合预期重写 MAC 错会导致对端收包后不知道怎么回第五步看 ECMP 表的成员和哈希字段成员状态不对或者哈希字段选得太窄都会让流量挤在一条链路上。资料里把这条链画成“Route Lookups - MAC Table - ECMP Table”的闭环实际排障时也要按闭环走不要跳步。4.3 HRT、LPM 与 TCAM 的分工/32、/128 和溢出路径资料把 IP 前缀在硬件里的存储方式分成三类HRT、LPM 和 TCAM。HRT 是哈希表主要放 IPv4 /32 和 IPv6 /128 主机条目表项来自 Flex TileLPM 放传统前缀/掩码条目或者用 pivot 和 trie tile 的组合放其他前缀长度同样来自 Flex TileTCAM 处理溢出和哈希冲突是传统 TCAM 内存前接灵活转发查表。这个分工决定了你的路由规模规划不能只看“总路由条数”还要看前缀长度分布。主机路由多HRT 压力大长前缀多LPM 的 trie 结构压力大两者都多TCAM 溢出风险就高。TCAM 不是免费扩容它容量有限而且命中 TCAM 的路径和命中 HRT/LPM 的路径在表项组织和更新频率上也不一样。这里有一个常见误判看到“支持 IPv6”就以为 IPv6 主机路由可以随便加。IPv6 /128 走 HRTHRT 来自 Flex Tile而 Flex Tile 的总量由芯片型号和路由模板决定。资料里把 Dual-stack host scale 单独列成一个模板就是给 IPv4/IPv6 主机路由双栈场景用的但它不支持模块化 9500。你在模块化机箱上做大规模 IPv6 主机路由就要提前算 HRT 水位必要时用 LPM heavy 或其他模板做平衡而不是等 TCAM 溢出后再改模板。TCAM 溢出的现象不一定是“路由全丢”可能是部分前缀查不到、流量走默认路由、或者哈希冲突导致某些主机条目不稳定排障时很容易被当成“偶发丢包”。4.4 Flex Tile 模板与规模换算default、dual-stack host scale、LPM heavy 的取舍把模板和表项放在一起看选型就变成一道算术题。Default 是基线适合大多数场景Dual-stack host scale 把表项往主机路由倾斜适合 IPv4/IPv6 双栈主机路由多的环境但资料明确它不支持模块化 9500Internet peering 适合互联网对等场景但不支持 IP 组播LPM heavy 适合长前缀路由多的场景MPLS heavy 适合 MPLS 标签多的场景Multicast heavy 适合组播表项多的场景Multicast NBM 不适合 TOR。每个模板都是“把 Flex Tile 的池子往某个方向切”切多了另一边就少。资料里带星号的限制不是脚注是选型边界。我一般用下面这张表做初筛模板主要倾斜方向关键限制适用场景Default均衡无特殊限制通用数据中心Dual-stack host scaleIPv4/IPv6 主机路由不支持模块化 9500双栈主机路由多Internet peering互联网前缀不支持 IP 组播出口对等LPM heavy长前缀 LPM挤占其他表项大量长前缀MPLS heavyMPLS 标签按平台支持MPLS 场景Multicast heavy组播表项按平台支持组播多的环境Multicast NBM组播非广播不支持 TOR特定组播场景这张表只能做初筛最终还要回到芯片型号和业务前缀分布。比如同样是“主机路由多”LSE 的 2 切片结构和 LS1800FX 的 1 切片结构在 Flex Tile 总量上可能不同模板支持也不一样同样是“组播多”模块化 9500 和 TOR 的模板限制又不同。选模板的正确姿势是先统计当前和未来 12 个月的前缀长度分布、主机路由数量、组播组数量、MPLS 标签数量再拿模板限制去卡最后把重启窗口和回滚方案写进变更。不要等 TCAM 溢出、路由抖动、组播丢包一起出现时才想起模板那时候改模板要重启代价比提前规划大得多。5. 避坑与排查路由模板、TCAM 溢出、切片带宽和加密能力5.1 模板改完不重启现象是配置显示成功转发还是旧账本现象很典型模板命令下去了show输出显示目标模板但业务表项水位没变新前缀还是加不进去或者主机路由还是查不到。原因不复杂资料写得很清楚模板在系统初始化时定义 Flex Tile 功能运行中改模板不会重新切表项池必须重启才生效。很多人看到命令没报错就以为生效了变更窗口里没留重启时间最后只能二次停机。解决方法是把模板变更当成“重启类变更”处理先记录当前模板和表项水位切模板安排重启重启后对比水位和业务前缀再决定是否回滚。回滚同样要重启所以变更单里要写两次重启窗口别只写一次。5.2 TCAM 溢出与哈希冲突现象是偶发丢包原因不一定是链路现象是部分主机不通、部分前缀走默认路由、或者监控里看到偶发丢包但链路利用率不高。原因可能有两个HRT 哈希冲突或 LPM 表项不足包被送到 TCAM 溢出路径TCAM 也满时就丢或者模板把 Flex Tile 切给了别的功能HRT/LPM 可用表项变少。排查时先看前缀长度分布和主机路由数量再看当前模板是否匹配业务如果主机路由多但用的是 Default或者双栈主机路由多但模块化 9500 上了不支持的模板就要调整模板或部署方式。解决不是“加一条静态路由”能糊过去的要把表项水位和模板限制一起看。血泪经验是TCAM 溢出不会给你一个漂亮的告警它往往藏在“偶发”两个字里等用户报障时已经很难复现。5.3 切片间带宽误判单切片 18 x 100G 不等于整机任意端口无阻塞现象是整机端口利用率不高但某些跨端口流量就是跑不满或者多打一场景下出端口排队严重。原因是把“芯片总容量”当成“任意端口组合都能线速”。Slice 是自包含转发复合体单切片内的端口共享该切片的 ingress/egress 资源跨切片流量要走 Slice Interconnect。LS1800FX 的 1 个 18 x 100G 切片和 LSE 的 2 个 9 x 100G 切片总容量一样但端口分布和跨切片比例不同。解决方法是做流量模型时把端口按 slice 分组高速互连尽量均匀落片多打一场景提前算出端口组的收敛比如果业务必须单切片高密度互连选型时就要看单切片端口账本而不是只看整机容量。5.4 加密能力错配MACSEC/CloudSec 不是全系标配现象是规划时按“全系支持加密”做了组网配置时发现某型号没有 MACSEC或者 CloudSec 只在 LS3600FX2 上出现。原因是把平台能力当成了系列能力。资料里 LS1800FX 带 MACSECLS3600FX2 带 MACSEC CloudSecLSE 和 S6400 在芯片对照表里没有强调这两项。解决方法是选型阶段就把加密能力写进芯片对照表按链路类型区分“端口加密”和“隧道加密”不要把 MACSEC 和 CloudSec 混为一谈。如果现网已经混布先确认每条链路的加密终结点落在哪颗芯片上再决定是换线卡、换端口还是调整加密方案。5.5 遥测能力误用flow table 和 SSX 不是同一张表现象是设计遥测方案时按“全系支持 flow table”写了采集点落地时发现某些平台只能走流统计导出。原因是资料里 flow table 只出现在 LSE、LS1800FX、LS3600FX2S6400 对应 SSX。两者都能做可观测性但采集粒度、事件通知方式和后端对接不一样。解决方法是先确认芯片型号再确认遥测路径要流表事件就选支持 flow table 的芯片要流统计导出就按 SSX 设计采集周期和聚合方式。不要用同一个采集模板套所有平台否则会出现“配置下去了但没数据”的黑匣子状态。6. 用一次 Packet Walk 验证设计从入端口到出端口的检查表Packet Walk 是这份资料里最实用的部分也是很多人翻得最快、忘得最快的部分。我的用法不是从头到尾读一遍而是拿一个真实流量模型按包走一遍把每个检查点落到芯片资源上。下面这张检查表可以直接抄检查点看什么常见异常入端口与切片入端口属于哪个 sliceingress 资源是否共享端口落片不均单切片 ingress 热点Parser 与分类隧道字段、VRF、ACL 标记是否解析正确隧道终结后 VRF 映射错查表 key 不对转发查表命中 HRT、LPM 还是 TCAM主机路由多但 HRT 不足TCAM 溢出邻接与 ECMP返回 ADJ 还是 ECMP成员和哈希字段ECMP 成员状态不对哈希字段太窄出方向缓冲出端口队列、AFD/DPP 动作只看链路利用率忽略队列和丢弃重写与出端口MAC 表里的重写 MAC、输出 BD、端口重写 MAC 错对端回包异常跨切片互连是否跨 sliceinterconnect 是否非阻塞把总容量当任意端口无阻塞走完这张表你会发现很多“玄学”问题都能落到具体表项上。比如同样是丢包入端口 slice 的 ingress 队列满、HRT 哈希冲突、ECMP 成员 down、出端口 AFD 丢弃对应的解决动作完全不同。资料里把 Packet Walk 放在平台和转发功能之后不是让你背流程而是让你在设计阶段就能预判这个流量模型会不会跨 slice跨几次出端口缓冲够不够模板切出来的表项够不够。从那以后我每次改路由模板或者加新的加密链路都强制走一遍 Packet Walk先在图上看清楚包从哪进、查哪张表、从哪出再动手配置。这份 N9K 芯片级资料我一般放在手边选型时翻芯片对照表排障时翻查表链和 Packet Walk改模板前翻模板限制。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/3 19:38:54 · 阅读 1.2k N9K芯片级解析：Cloud Scale ASIC切片与转发排障
简介这份 PDF 是思科 Nexus 9000 系列交换机的芯片级架构讲义面向数据中心网络工程师、Cisco 认证备考者以及希望深入理解云规模交换硬件的技术人员重点说明新一代模块化交换机和 TOR 交换机如何借助定制 ASIC 实现高吞吐、低时延与可扩展转发。压缩包共 1 个 PDF 文件大小约 3.56MB内容取自 Cisco Live 技术分享由杰出工程师 Tim Stevenson 讲解便于按章节查阅。资料围绕数据中心与硅策略、Cloud Scale 架构与 ASIC、关键转发特性、9500/9300 平台对比及 Packet Walks 展开并涉及智能缓冲、流式遥测、VXLAN、ACI 策略模型等硬件加速能力。已有 286 人学习适合在选型、排错和架构复盘时查阅。1. N9K 芯片级资料不是产品彩页先看清它到底拆什么很多人拿到《N9K 芯片级介绍 - 2018.pdf》第一反应是找配置命令翻两页却发现满篇都是切片、Flex Tile、HRT/LPM、Packet Walk于是把它归到“架构科普”里吃灰。这份资料真正值钱的地方是把 9000 系列 Cloud Scale 平台从“端口数量和转发性能”拉回到芯片内部一个包从入端口进来经过哪个 slice、查哪张表、命中 HRT 还是 LPM、什么时候走 TCAM、ECMP 指针怎么落到 MAC 表全部串成一条可验证的路径。它适合正在做数据中心交换机选型、线卡能力核对、路由规模规划的人也适合排障时想弄明白“为什么模板一改就要重启”的一线工程师。别把它当配置手册把它当芯片级排障地图用后面几章的表格和检查点才有意义。2. 从自研硅片到 Slice 架构为什么先看这张“芯片地图”2.1 自研 ASIC 的差异不在跑分而在单次隧道封装和智能缓冲这份资料开篇没有急着列型号而是先讲数据中心和硅策略。原因很直接同样标称 1.8T 或 6.4T 的交换芯片商用硅方案和自研硅方案在功能落点上差别很大。商用硅通常强调广泛行业可用性、公开 SDK 和多芯片架构适合快速铺产品线自研硅则把硬件设计和软件功能绑得更紧资料里点名了几个关键能力策略化数据中心的拥塞感知 flowlet 切换、灵活的转发 tile、单次隧道封装、内置加密、智能缓冲以及流表遥测和流统计导出。对做网络规划的人来说这些词不是营销话术它们决定了你在 VXLAN 路由、MACSEC 加密、Telemetry 采集和突发流量缓冲上要不要额外加板卡、要不要绕开某些线卡。单次隧道封装值得单独说。传统叠加网络里一个包从接入到核心可能要经历多次封装和解封装每次都要查表、改写、排队时延和芯片资源都被吃掉。自研芯片把这步做在硬件转发路径里好处是转发面少一次“拆包再包”的往返坏处是它对芯片流水线有强依赖你在规划时如果只看端口密度不看这个平台是否支持单次封装和对应的隧道终结能力后面做跨 Pod 流量模型就容易翻车。智能缓冲也是同理资料里提到的 DBP、AFD、DPP 不是三个缩写摆在一起好看而是分别对应动态缓冲、近似公平丢弃和动态优先级调整这类拥塞管理动作。它们的价值在突发流量和 incast 场景下才显现平时看接口利用率看不出来。我把自研硅和商用硅的差异压成一张表方便选型时对照维度自研 Cloud Scale 芯片商用硅方案功能与软件耦合硬件按策略模型和遥测需求定制依赖商用芯片路线图和 SDK隧道封装强调单次隧道封装多按芯片能力分阶段实现加密内置 MACSEC/CloudSec 能力按芯片型号分布取决于具体芯片和板卡缓冲与拥塞智能缓冲DBP/AFD/DPP 等机制通常提供标准缓冲配置遥测流表、流表事件、流统计导出能力随芯片和软件版本变化这张表不是让你背参数而是提醒你看到“支持 VXLAN”不等于“支持单次 VXLAN 路由”看到“支持 Telemetry”也不等于“支持流表级遥测”。资料里把 flow table 限定在 LSE、LS1800FX、LS3600FX2 这几颗芯片上S6400 则对应 SSX 流统计导出。选型时把芯片型号和功能表对一遍比只看整机 datasheet 靠谱。2.2 Slice 不是分区Ingress/Egress 与 Slice Interconnect 的非阻塞关系这份资料里最容易读错的概念是“Slice”。很多人把它理解成把端口切成几个 VLAN 组或者把芯片分成几个独立分区。资料的定义更硬Slice 是单颗 ASIC 上自包含的转发复合体控制该 ASIC 的一部分端口内部再分为 Ingress 和 Egress 功能每个 Slice 的 Ingress 都连接到所有 Slice 的 EgressSlice Interconnect 提供任意到任意的非阻塞互连。换句话说Slice 是芯片内部的“转发子系统”不是外部业务分区。你在一台交换机上看到 18 个 100G 端口可能来自 1 个 18 端口的 Slice也可能来自 2 个 9 端口的 Slice这两种账本对突发流量和故障域的影响不一样。资料给了四个芯片的切片账本我整理成下面这张表芯片总容量切片结构典型落点加密能力LSE1.8T2 个切片每切片 9 x 100GX9700-EX 模块化线卡、9300-EX TOR资料未强调 MACSECLS1800FX1.8T1 个切片18 x 100GX9700-FX 模块化线卡、9300-FX TOR带 MACSECS64006.4T4 个切片每切片 16 x 100G9364C TOR、E2 fabric modules资料未强调 MACSECLS3600FX23.6T2 个切片每切片 18 x 100G9300-FX2 TORMACSEC CloudSec这张表最容易被误读的是“1.8T 芯片有两个 9 x 100G 切片”和“1.8T 芯片有一个 18 x 100G 切片”。两者总容量一样但前者把端口分散到两个 slice后者把 18 个 100G 放在一个 slice 里。Slice 内部有独立的 ingress 查表、缓冲、队列和调度资源slice 之间通过 interconnect 做非阻塞互连。对大多数东西向流量这种设计没问题但如果你做的是单流大带宽或者多打一场景就要看单个 slice 的 ingress 到 egress 路径会不会成为局部热点。资料里反复画 Ingress Slice 到 Egress Slice 的连线不是为了好看而是让你在 Packet Walk 时能指出包从哪个 slice 进、到哪个 slice 出、中间有没有跨 interconnect。还有一个细节Slice 的 Ingress 连接到所有 Slice 的 Egress这意味着跨 slice 转发在芯片内是允许的而且设计目标是非阻塞。但“非阻塞”说的是芯片互连能力不等于整机所有端口在任何流量模式下都不丢包。出端口方向的缓冲、队列和调度仍然按 slice 分配拥塞时还是要看智能缓冲和 AFD/DPP 怎么动作。把 Slice 当成“芯片内的小交换机”来理解很多现象就顺了同一个 slice 内的端口互访路径短跨 slice 的端口互访要过 interconnect如果某个 slice 的 egress 队列被打满其他 slice 的 ingress 再空也可能在这一个出端口上排队。2.3 从系统初始化到模板路由模板为什么必须重启才生效Flex Tile 是这份资料里另一个高频词。它不是一张固定的表而是一个“可 fungible 的表项池”芯片型号不同tile 数量和每个 tile 的表项数不同同一颗芯片也可以通过“system routing template”把 tile 配置成不同功能组合比如 IPv4/IPv6 单播最长前缀匹配、主机路由表、组播 (*,G) 和 (S,G)、MAC/邻接表、ECMP 表、策略表等。资料列出的模板包括 Default、Dual-stack host scale、Internet peering、LPM heavy、MPLS heavy、Multicast heavy、Multicast NBM。这里面有几个限制必须记牢Dual-stack host scale 不支持模块化 9500Internet peering 不支持 IP 组播Multicast NBM 不支持 TOR带星号的模板还有各自的适用边界。模板为什么必须重启因为它在系统初始化时决定 Flex Tile 的功能划分等于在芯片启动阶段把表项池切成不同用途。运行中改模板不是改一个软件开关而是改转发面表项的组织方式已经下发的路由、邻接和组播表项都要重新分布所以资料明确写“defined at system initialization – reboot required to change profile”。血泪经验是变更窗口里只留了配置回滚时间没留重启时间模板改完业务没起来最后只能整机重启影响面比预期大。我的做法是先把当前模板、当前前缀规模、当前主机路由数量记录下来再评估目标模板的限制最后把重启和回滚步骤写进变更单。配置片段可以这样示意实际命令以设备帮助为准# 查看当前路由模板与表项使用情况命令名随版本可能略有差异 show system routing template show forwarding tables # 规划变更先记录业务前缀和主机路由规模 # 再切换模板切换后必须重启才生效 system routing template dual-stack-host-scale # 重启设备使模板生效 reload这段配置的逻辑是先用查看命令确认当前模板和表项水位再切换模板最后通过重启让芯片按新模板重新初始化。参数说明上模板名不是随便选的dual-stack host scale 适合 IPv4/IPv6 主机路由多的场景但资料明确它不支持模块化 9500LPM heavy 适合大量长前缀路由但会挤占其他表项空间Multicast heavy 适合组播表项多的场景但 Internet peering 模板又不支持 IP 组播。选模板的本质是“把 Flex Tile 的表项池往你最需要的表上倾斜”没有全能模板。提示改模板前先把当前配置和表项水位导出重启后再对比一次。不要只看模板名字先看资料里那张“模板支持矩阵”尤其是模块化和 TOR 的差异。3. ASIC 家族与平台映射LSE、LS1800FX、S6400、LS3600FX2 怎么对号入座3.1 四个芯片的切片与端口账本1.8T/6.4T/3.6T 不是唯一指标选型时最容易犯的错是只看总容量。1.8T、3.6T、6.4T 当然重要但这份资料把切片结构、端口组合、加密能力和遥测能力放在同一张桌上意思很明确同样容量芯片的“形状”不同适合的场景也不同。LSE 是 1.8T、2 个切片、每切片 9 x 100G落在 X9700-EX 模块化线卡和 9300-EX TOR 上LS1800FX 也是 1.8T但它是 1 个切片、18 x 100G并且带 MACSEC落在 X9700-FX 线卡和 9300-FX TOR 上S6400 是 6.4T、4 个切片、每切片 16 x 100G落在 9364C TOR 和 E2 fabric modules 上LS3600FX2 是 3.6T、2 个切片、每切片 18 x 100G带 MACSEC CloudSec落在 9300-FX2 TOR 上。把这四颗芯片放在一起看你会发现两个分水岭。第一个分水岭是“切片数量与单切片端口数”LSE 和 LS3600FX2 都是多切片S6400 是四切片LS1800FX 是单切片。单切片的好处是 18 个 100G 端口在芯片内部走同一个 ingress/egress 复合体路径简单多切片的好处是单个 slice 的端口数少故障域和局部拥塞的影响面可能更小跨 slice 流量走 interconnect。第二个分水岭是“加密与遥测”LS1800FX 和 LS3600FX2 明确带 MACSECLS3600FX2 还带 CloudSecflow table 只在 LSE、LS1800FX、LS3600FX2 上出现S6400 对应的是 SSX 流统计导出。你在做加密组网或者流表遥测时不能拿 S6400 的端口密度去套 LS3600FX2 的加密能力反过来也不行。资料里还有一条平台边界这份内容聚焦 Cloud Scale ASIC 的新一代 9500 模块化线卡和 9300 TOR不覆盖第一代 9000 平台架构也不覆盖 9500 商用硅架构和其他平台。这句话在选型时很关键。你如果在现网里混用了 X9400、X9600-R 这类商用硅线卡再拿这份资料的切片和 Flex Tile 逻辑去套就会对不上。正确做法是先确认线卡和芯片家族再看对应章节。资料里把 X9400/X9400-S 归到商用 Broadcom XGS 方案把 X9600-R/X9600-RX 归到商用 DNX 多芯片架构这两类和 Cloud Scale 的转发模型不是一套账本。选型会上如果有人拿“都是 9500 机箱”来论证线卡可以混插、能力可以平移这份资料就是最好的反例。3.2 模块化 9500 与 TOR 9300 的选型边界别把线卡能力当成整机能力模块化 9500 的选型逻辑和 TOR 完全不同。TOR 看的是单机端口组合、切片结构、加密和遥测模块化机箱则要看线卡、fabric module 和整机转发能力之间的匹配。资料里 X9700-EX 对应 LSEX9700-FX 对应 LS1800FX这两类线卡都走 Cloud Scale 芯片X9700-EX/FX 的切片账本和 TOR 上的同族芯片一致但落到机箱后还要看 fabric module 怎么连、线卡之间怎么跨 slice 转发。S6400 除了 9364C TOR还出现在 E2 fabric modules 里这说明同一颗芯片在不同形态里的角色不一样在 TOR 上是转发芯片在 fabric module 上是机箱互连的一部分。选型时如果把“线卡支持多少端口”直接当成“整机支持多少端口”忽略 fabric 侧的能力和收敛比后面扩容就会卡在互连上。9300 TOR 的边界更直接9300-EX 用 LSE9300-FX 用 LS1800FX9300-FX2 用 LS3600FX2。三者的端口组合和加密能力不同模板限制也不同。资料特别标注 Dual-stack host scale 不支持模块化 9500Multicast NBM 不支持 TOR这些限制在纯 TOR 组网和混合组网里影响不一样。我的习惯是先把业务按“主机路由多、长前缀多、组播多、加密多、遥测多”五类打标再拿芯片表去匹配而不是先选机箱再补功能。比如一个 Pod 里 IPv6 主机路由占比很高Default 模板可能很快把 HRT 用满这时候要看 Dual-stack host scale 能不能上如果这个 Pod 又是模块化 9500资料明确该模板不支持那就得回到 LPM heavy 或其他组合上做取舍或者调整主机路由的部署方式。3.3 端口速率与加密能力MACSEC、CloudSec 落在哪一层资料在芯片家族部分反复提多速率 100M/1/10/25/40/50/100G这是 Cloud Scale 系列的一个卖点同一平台可以通过不同端口形态适配服务器接入、存储接入和叶脊互连。但多速率不等于所有端口都能任意组合切片结构和端口宏才是最终约束。LSE 的 2 个 9 x 100G 切片、LS1800FX 的 1 个 18 x 100G 切片、S6400 的 4 个 16 x 100G 切片、LS3600FX2 的 2 个 18 x 100G 切片这些数字决定了你在一台机器上能拆出多少组 40G/100G也决定了跨切片流量的比例。做布线规划时把高速端口尽量均匀落到不同 slice 上可以减少单个 slice 的 egress 热点但如果你需要单切片内高密度互连LS1800FX 这种单切片 18 x 100G 反而更直接。加密能力要单独拉出来看。资料里 LS1800FX 标注 MACSECLS3600FX2 标注 MACSEC CloudSecLSE 和 S6400 没有在这个表里强调加密。MACSEC 是链路层加密CloudSec 更偏向隧道加密两者落点不同。你在做跨站点或跨租户加密时不能只问“这台交换机支不支持加密”要问“这条链路的加密是在端口上做还是在隧道上做芯片有没有内置能力会不会吃掉额外表项或吞吐”。资料把加密归到自研硅的差异化能力里和单次隧道封装放在一起讲意思就是加密不是外挂而是转发路径的一部分。选型时把加密能力写进芯片对照表比在配置阶段才发现某型号不支持要省很多事。4. 转发流水线拆解Parser、Flex Tile、HRT/LPM/TCAM 与 ECMP 怎么串起来4.1 Ingress 三段分类、查表、负载均衡与 AFD/DPP资料把 Ingress Forwarding Controller 拆成几块Packet Parser、Ingress Classification、Forwarding Lookup、Lookup Key、TCAM、Flex Tiles、Flow Table以及 Load Balancing 和 AFD/DPP。这个顺序不是画着好看它对应一个包进来后的真实动作。Parser 先解析报文头识别二层、三层、隧道字段Ingress Classification 给包打分类标记决定后续查哪类表、用什么 keyForwarding Lookup 拿 Lookup Key 去查 Flex Tile 和 TCAM命中后返回转发结果Load Balancing 和 AFD/DPP 则在出方向或拥塞时决定队列和丢弃策略。Flow Table 只在 LSE、LS1800FX、LS3600FX2 上出现用来支持流表级遥测和事件通知S6400 走的是 SSX 流统计导出这是两颗芯片在可观测性上的分叉。这段流水线对排障的意义是你不能一上来就怀疑芯片转发能力先看包在哪个阶段被改了。Parser 解析不出隧道字段后面的 Lookup Key 就不对Classification 没打对标记策略表就查不中Flex Tile 里没有对应表项包可能走 TCAM 溢出路径或者被丢ECMP 哈希不均衡可能是 Load Balancing 的哈希字段选得不对也可能是 AFD/DPP 在拥塞时做了调整。资料里把 AFD 和 DPP 放在 Ingress 负载均衡旁边说明它们不是单纯的出队列丢弃算法而是和芯片的缓冲管理、流感知调度绑在一起。你在看接口计数器时如果只看出方向丢包不看 ingress 侧的负载均衡和缓冲动作很容易把问题归错到“上联带宽不够”。4.2 IP 单播查表链Router MAC - VRFIPDA - ADJ/ECMP - MAC 表资料给了一条非常清晰的 IP 单播转发链先做 Router MAC Lookup判断目的 MAC 是不是路由器 MAC如果是触发 L3 查表。硬件对 VRF 做精确匹配对目的 IP 做最长匹配查表结果返回 adjacency pointer 或者 ECMP pointer。Adjacency pointer 指向 MAC 表MAC 表里有输出 BD、重写 MAC 和输出端口ECMP pointer 指向 ECMP 表选出 ECMP 组后再落到具体邻接。这个链条看起来简单但它把“路由表”和“邻接表”在硬件里的分工讲透了路由表负责“往哪走”邻接表负责“怎么改写、从哪出”ECMP 表负责“多路径选哪条”。排障时按这个链条逐段查比凭感觉快。第一步看 Router MAC 是否命中如果目的 MAC 不是路由器 MAC包可能走二层转发不会进 L3 查表第二步看 VRF 和 IPDA 的 Lookup Key 是否正确VRF 配错或者隧道终结后 VRF 映射错最长匹配再对也没用第三步看返回的是 ADJ 还是 ECMP如果业务预期走 ECMP 但返回的是单邻接说明路由或哈希配置有问题第四步看 MAC 表里的重写 MAC 和输出端口是否符合预期重写 MAC 错会导致对端收包后不知道怎么回第五步看 ECMP 表的成员和哈希字段成员状态不对或者哈希字段选得太窄都会让流量挤在一条链路上。资料里把这条链画成“Route Lookups - MAC Table - ECMP Table”的闭环实际排障时也要按闭环走不要跳步。4.3 HRT、LPM 与 TCAM 的分工/32、/128 和溢出路径资料把 IP 前缀在硬件里的存储方式分成三类HRT、LPM 和 TCAM。HRT 是哈希表主要放 IPv4 /32 和 IPv6 /128 主机条目表项来自 Flex TileLPM 放传统前缀/掩码条目或者用 pivot 和 trie tile 的组合放其他前缀长度同样来自 Flex TileTCAM 处理溢出和哈希冲突是传统 TCAM 内存前接灵活转发查表。这个分工决定了你的路由规模规划不能只看“总路由条数”还要看前缀长度分布。主机路由多HRT 压力大长前缀多LPM 的 trie 结构压力大两者都多TCAM 溢出风险就高。TCAM 不是免费扩容它容量有限而且命中 TCAM 的路径和命中 HRT/LPM 的路径在表项组织和更新频率上也不一样。这里有一个常见误判看到“支持 IPv6”就以为 IPv6 主机路由可以随便加。IPv6 /128 走 HRTHRT 来自 Flex Tile而 Flex Tile 的总量由芯片型号和路由模板决定。资料里把 Dual-stack host scale 单独列成一个模板就是给 IPv4/IPv6 主机路由双栈场景用的但它不支持模块化 9500。你在模块化机箱上做大规模 IPv6 主机路由就要提前算 HRT 水位必要时用 LPM heavy 或其他模板做平衡而不是等 TCAM 溢出后再改模板。TCAM 溢出的现象不一定是“路由全丢”可能是部分前缀查不到、流量走默认路由、或者哈希冲突导致某些主机条目不稳定排障时很容易被当成“偶发丢包”。4.4 Flex Tile 模板与规模换算default、dual-stack host scale、LPM heavy 的取舍把模板和表项放在一起看选型就变成一道算术题。Default 是基线适合大多数场景Dual-stack host scale 把表项往主机路由倾斜适合 IPv4/IPv6 双栈主机路由多的环境但资料明确它不支持模块化 9500Internet peering 适合互联网对等场景但不支持 IP 组播LPM heavy 适合长前缀路由多的场景MPLS heavy 适合 MPLS 标签多的场景Multicast heavy 适合组播表项多的场景Multicast NBM 不适合 TOR。每个模板都是“把 Flex Tile 的池子往某个方向切”切多了另一边就少。资料里带星号的限制不是脚注是选型边界。我一般用下面这张表做初筛模板主要倾斜方向关键限制适用场景Default均衡无特殊限制通用数据中心Dual-stack host scaleIPv4/IPv6 主机路由不支持模块化 9500双栈主机路由多Internet peering互联网前缀不支持 IP 组播出口对等LPM heavy长前缀 LPM挤占其他表项大量长前缀MPLS heavyMPLS 标签按平台支持MPLS 场景Multicast heavy组播表项按平台支持组播多的环境Multicast NBM组播非广播不支持 TOR特定组播场景这张表只能做初筛最终还要回到芯片型号和业务前缀分布。比如同样是“主机路由多”LSE 的 2 切片结构和 LS1800FX 的 1 切片结构在 Flex Tile 总量上可能不同模板支持也不一样同样是“组播多”模块化 9500 和 TOR 的模板限制又不同。选模板的正确姿势是先统计当前和未来 12 个月的前缀长度分布、主机路由数量、组播组数量、MPLS 标签数量再拿模板限制去卡最后把重启窗口和回滚方案写进变更。不要等 TCAM 溢出、路由抖动、组播丢包一起出现时才想起模板那时候改模板要重启代价比提前规划大得多。5. 避坑与排查路由模板、TCAM 溢出、切片带宽和加密能力5.1 模板改完不重启现象是配置显示成功转发还是旧账本现象很典型模板命令下去了show输出显示目标模板但业务表项水位没变新前缀还是加不进去或者主机路由还是查不到。原因不复杂资料写得很清楚模板在系统初始化时定义 Flex Tile 功能运行中改模板不会重新切表项池必须重启才生效。很多人看到命令没报错就以为生效了变更窗口里没留重启时间最后只能二次停机。解决方法是把模板变更当成“重启类变更”处理先记录当前模板和表项水位切模板安排重启重启后对比水位和业务前缀再决定是否回滚。回滚同样要重启所以变更单里要写两次重启窗口别只写一次。5.2 TCAM 溢出与哈希冲突现象是偶发丢包原因不一定是链路现象是部分主机不通、部分前缀走默认路由、或者监控里看到偶发丢包但链路利用率不高。原因可能有两个HRT 哈希冲突或 LPM 表项不足包被送到 TCAM 溢出路径TCAM 也满时就丢或者模板把 Flex Tile 切给了别的功能HRT/LPM 可用表项变少。排查时先看前缀长度分布和主机路由数量再看当前模板是否匹配业务如果主机路由多但用的是 Default或者双栈主机路由多但模块化 9500 上了不支持的模板就要调整模板或部署方式。解决不是“加一条静态路由”能糊过去的要把表项水位和模板限制一起看。血泪经验是TCAM 溢出不会给你一个漂亮的告警它往往藏在“偶发”两个字里等用户报障时已经很难复现。5.3 切片间带宽误判单切片 18 x 100G 不等于整机任意端口无阻塞现象是整机端口利用率不高但某些跨端口流量就是跑不满或者多打一场景下出端口排队严重。原因是把“芯片总容量”当成“任意端口组合都能线速”。Slice 是自包含转发复合体单切片内的端口共享该切片的 ingress/egress 资源跨切片流量要走 Slice Interconnect。LS1800FX 的 1 个 18 x 100G 切片和 LSE 的 2 个 9 x 100G 切片总容量一样但端口分布和跨切片比例不同。解决方法是做流量模型时把端口按 slice 分组高速互连尽量均匀落片多打一场景提前算出端口组的收敛比如果业务必须单切片高密度互连选型时就要看单切片端口账本而不是只看整机容量。5.4 加密能力错配MACSEC/CloudSec 不是全系标配现象是规划时按“全系支持加密”做了组网配置时发现某型号没有 MACSEC或者 CloudSec 只在 LS3600FX2 上出现。原因是把平台能力当成了系列能力。资料里 LS1800FX 带 MACSECLS3600FX2 带 MACSEC CloudSecLSE 和 S6400 在芯片对照表里没有强调这两项。解决方法是选型阶段就把加密能力写进芯片对照表按链路类型区分“端口加密”和“隧道加密”不要把 MACSEC 和 CloudSec 混为一谈。如果现网已经混布先确认每条链路的加密终结点落在哪颗芯片上再决定是换线卡、换端口还是调整加密方案。5.5 遥测能力误用flow table 和 SSX 不是同一张表现象是设计遥测方案时按“全系支持 flow table”写了采集点落地时发现某些平台只能走流统计导出。原因是资料里 flow table 只出现在 LSE、LS1800FX、LS3600FX2S6400 对应 SSX。两者都能做可观测性但采集粒度、事件通知方式和后端对接不一样。解决方法是先确认芯片型号再确认遥测路径要流表事件就选支持 flow table 的芯片要流统计导出就按 SSX 设计采集周期和聚合方式。不要用同一个采集模板套所有平台否则会出现“配置下去了但没数据”的黑匣子状态。6. 用一次 Packet Walk 验证设计从入端口到出端口的检查表Packet Walk 是这份资料里最实用的部分也是很多人翻得最快、忘得最快的部分。我的用法不是从头到尾读一遍而是拿一个真实流量模型按包走一遍把每个检查点落到芯片资源上。下面这张检查表可以直接抄检查点看什么常见异常入端口与切片入端口属于哪个 sliceingress 资源是否共享端口落片不均单切片 ingress 热点Parser 与分类隧道字段、VRF、ACL 标记是否解析正确隧道终结后 VRF 映射错查表 key 不对转发查表命中 HRT、LPM 还是 TCAM主机路由多但 HRT 不足TCAM 溢出邻接与 ECMP返回 ADJ 还是 ECMP成员和哈希字段ECMP 成员状态不对哈希字段太窄出方向缓冲出端口队列、AFD/DPP 动作只看链路利用率忽略队列和丢弃重写与出端口MAC 表里的重写 MAC、输出 BD、端口重写 MAC 错对端回包异常跨切片互连是否跨 sliceinterconnect 是否非阻塞把总容量当任意端口无阻塞走完这张表你会发现很多“玄学”问题都能落到具体表项上。比如同样是丢包入端口 slice 的 ingress 队列满、HRT 哈希冲突、ECMP 成员 down、出端口 AFD 丢弃对应的解决动作完全不同。资料里把 Packet Walk 放在平台和转发功能之后不是让你背流程而是让你在设计阶段就能预判这个流量模型会不会跨 slice跨几次出端口缓冲够不够模板切出来的表项够不够。从那以后我每次改路由模板或者加新的加密链路都强制走一遍 Packet Walk先在图上看清楚包从哪进、查哪张表、从哪出再动手配置。这份 N9K 芯片级资料我一般放在手边选型时翻芯片对照表排障时翻查表链和 Packet Walk改模板前翻模板限制。希望帮到你。本文还有配套的精品资源点击获取