简介思科Nexus 9000系列交换机芯片级技术讲座PDF由思科杰出工程师Tim Stevenson主讲面向数据中心网络架构师、网络运维与学习人士。内容聚焦最新一代Nexus 9000模块化与机架顶部TOR交换机的硬件设计涵盖数据中心硅策略、云规模架构与ASIC、转发特性、X9400/X9600-R及9300系列平台并辅以Packet Walks数据包在交换机内部的完整转发路径分析可帮助读者理解高性能数据中心网络的实现原理与关键功能同时涉及单遍隧道封装、智能缓冲与流式遥测等硬件特性能弥补通用文档在底层细节上的不足。包内为1个PDF文件压缩包约3.56MB内容为2018 Cisco Live技术讲座编号BRKARC-3222的完整幻灯片结构清晰、图文并茂。已有283人学习特别适合希望从系统架构层面深入理解Nexus 9000硬件方案、云规模转发、VXLAN等特性的网络工程师可作为日常方案设计、选型评估或故障排查时的高价值参考资料。1. N9K 芯片级介绍先确认你手里那台 N9K 用的是哪颗 ASICNexus 9000 从来不是一个“一个型号一套芯片”的系列。同样是 N9K9300 平台和 9500 平台内部走的转发路径完全不同有的用 Cisco 的 CloudScale 系列有的用 Broadcom 的 Tomahawk还有一批早期型号挂了 Trident。做芯片级介绍第一步不是背参数表而是先学会在设备上确认“这台机器里面是什么”。2018 年前后的 N9K 文档重点其实是两件事一是 CloudScale 如何做到 100G 端口的低延迟和可编程表项二是 Tomahawk 线卡如何在模块化机箱里把整机容量堆上去。对运维和做网络设计的人来说搞清楚芯片决定了你遇到丢包时查哪里、调表项时改什么、买新设备时看什么。本文按芯片型号、转发流水线、验证命令、调优参数四个层面展开最后给几个能直接用的巡检习惯。2. N9K 的芯片家族与转发流水线CloudScale、Tomahawk 与 Trident 的分工2.1 三款 ASIC 的定位差异N9K 的芯片级介绍绕不开三款 ASIC 的区分。它们都不是“某一款固定芯片”的单点而是一族产品但大方向可以归纳为CloudScale 主打低延迟和可编程表项Tomahawk 主打高密度和模块化机箱吞吐Trident 则覆盖低成本固定端口场景。芯片常见平台端口最高速率特征CloudScaleNexus 9232DC、9300 部分型号100GE低延迟、可编程表项、VXLAN 硬件卸载CloudScaleNexus 9500 部分线卡400GE后置扩展队列深度与 ACL 规模TomahawkNexus 9500 线卡如 X9636C100GE高密度、大缓冲、固定线卡使用Trident II/IIINexus 9200、9300 早期型号40GE/25GE常规 L3 转发、成本较低注意同一平台不同子型号的芯片可能不同所以“N9K 芯片级介绍”必须先看模块型号而不是看系列名。如果手头有一台 N9K可以先用show module看产品 PID。比如N9K-X9636C是 36 口 100GE 线卡走的是 TomahawkN9K-C9236C是固定端口 36 口 100GE走的是 CloudScale。这不是绝对的不同软件版本可能会有同芯片不同命名的模式但 2018 年前后的产品线大致按这个分类。做选型时如果端口密度优先选 Tomahawk 线卡如果单端口低延迟优先选 CloudScale 或 CloudScale 的固定设备更合适。2.2 数据包从入口到出口的芯片级路径无论哪颗 ASIC转发流水线都可以抽象成三个阶段Ingress 解析与查找、交换矩阵转发、Egress 调度与整形。Ingress 阶段芯片从 SerDes 拿到串行信号转换成并行数据然后做前导码处理、校验、字段提取。N9K 的 CloudScale 和 Tomahawk 都支持将 VXLAN 的外层和内层字段同时解析这样 VTEP 解封装和路由查找可以在同一个芯片周期内完成而不是像早期软件转发那样拆成两步。芯片内部的 TCAM 表用于匹配 ACL、QoS 和转发条目Hash 表用于 MAC/IP 路由查找。这里的细节会直接影响性能TCAM 是有限的多条 ACL 重叠时会消耗多个 entry而且不同平台的 TCAM 分配粒度不同。所以看到路由表没用多少但 ACL 占满了不能觉得奇怪。交换矩阵阶段模块化机箱里的线卡会把包切成 cell通过背板送到出线卡。这里的关键是 VoQVirtual Output Queue。每张入线卡为每个出线卡维护一组队列避免队头阻塞。Tomahawk 线卡的内部 cell 长度通常固定为 256 字节因此其转发延迟可以用“包长 cell 化开销 排队时延”来估算。对短包比如 64 字节包居多时芯片花费的 header 处理时间占比高整机吞吐会明显受限于包速率pps。这也是为什么核心设备看规格不能只看 bps还要看 pps 的原因。Egress 阶段芯片根据队列优先级做加权轮询WRR或严格优先级调度同时执行整形和标记。这里能看到拥塞丢包的真实位置如果出接口的 buffer 被占满那么丢包计数器会出现在出方向的队列上而不是入方向物理口。很多人一开始就在物理口抓 CRC 或 runts结果什么都查不到就是因为丢包发生在芯片的队列缓冲区而不是光电转换层。2.3 表项规模与芯片级可调参数芯片级介绍不能只讲架构还要讲“表项能用多大”。N9K 的 MAC 表、IPv4/6 路由表、VXLAN 表项并不是芯片出厂确定不变的而是由 NX-OS 在启动时根据 profile 分配 TCAM 和 DRAM。比如 CloudScale 支持把 IPv4 前缀表从默认的 256K 调到 512K但这是以牺牲其他表项为代价的。常见可调整的 profile 包括 IPv4 单播前缀数量、IPv6 长前缀数量、ACL 条目数量、邻居ARP/ND条目数量。N9K# show hardware profile IPv4 Unicast Table Size : 256K IPv6 Unicast Table Size : 128K L2 MAC Table Size : 128K ACL TCAM Size : 64K Neighbor Table Size : 64K上面这个输出只是展示格式具体数值会随型号和版本变化。你需要关注的是“当前 reach limit”与“max entries”的差距。如果已经到 90% 以上就要开始规划调整。调整 profile 的命令在 4.1 节会展开但这里先记住一个原则修改 profile 通常需要重启设备不能在现网直接热改。所以每次变更前都要先看当前占用再评估调整影响最后在维护窗口执行。3. 用命令把 N9K 芯片级状态摸一遍型号、表项、丢包位置3.1 先确认 ASIC 型号show module 与 show platform拿到一台未知的 N9K第一件事就是确认模块 PID。show module会列出每个插槽的模块类型和序列号而show platform部分版本是show system internal能读到芯片名称。常见的输出类似N9K# show module Mod Ports Module-Type Model Status 1 36 100G Ethernet Module N9K-X9636C ok 2 36 100G Ethernet Module N9K-X9636C ok PWR ... ...看到这个输出就知道里面是 Tomahawk 线卡而不是 CloudScale。如果show platform能直接给到 ASIC 名称比如Tomahawk或CloudScale更好。不过不同 NX-OS 版本对show platform的支持程度不同有些只能在内部调试命令里看到现场可以先show version再结合 PID 从文档里对一下。另一个快速办法是看光口速率如果一块线卡上所有端口都是 100GE且形态是 QSFP28大概率是 Tomahawk 或 CloudScale如果同一个模块内混了 10G/40G/100G 的多速率端口可能是 CloudScale因为它的端口配置更加灵活。3.2 查看芯片表项占用show hardware capacityshow hardware capacity是检查芯片表项是否打满的第一入口。它会把 L2 表、L3 路由表、ACL、QoS 策略等分别显示当前用量与最大值并标记超限风险。比如N9K# show hardware capacity L2 Forwarding Table: Max entries: 128000, Used: 104230, Reach limit: 95% IPv4 Unicast Route Table: Max entries: 256000, Used: 207000, Reach limit: 81% ACL TCAM Partition: Used / Max: 31457 / 65536 Port ACL : Used / Max: 1024 / 8192看到 “Used” 接近 “Max” 时就要考虑调 profile 或拆分区。注意这里的表项占用是芯片级的不受协议邻居数量的直接影响比如一条 VXLAN 隧道可能消耗多个转发表项不能只看隧道数量。另外show hardware capacity显示的 reach limit 通常不是 100%厂商会留一部分余量用于系统内部转发比如多播复制和链路本地流量。如果你的路由表已经到 95%实际可用的突发空间已经很小要提前做计划。3.3 丢包是芯片内部丢还是接口丢show interface counters排查丢包时要分清楚丢包发生在物理层、MAC 层还是队列层。下面这张表是现场最常用的三个定位点计数器位置典型命令常见原因物理层show interface counters errors光模块、光纤、SerDes 信号转发表show forwarding ipv4 summary路由未下发芯片、符号表耗尽队列层show queuing interface拥塞、缓冲区满、WRED 丢弃物理层丢包show interface ethernet 1/1 counters errors看 CRC、runts、symbol error。这类丢包一般是光模块、光纤或对端信号问题。MAC 层丢包看到 rx error 或 tx error通常是芯片 SerDes 在恢复数据时出错。队列丢包show queuing interface ethernet 1/1看 wr 丢弃计数或 wred 丢弃。我通常会在一台 N9K 的链路两端同时抓计数对比入方向和出方向的差值。如果入方向物理口正常但转发表项卡在某个 wait 状态那就要看show forwarding adjacency来确认邻居下发到芯片没有。N9K# show forwarding ipv4 summary IPv4 FIB: Total routes: 182344 Direct routes: 233 Indirect routes: 182111 Downloaded to hardware: 182344如果 “Downloaded to hardware” 小于 “Total routes”说明有前缀未下发到芯片芯片级转发缺失。这个命令在一些平台上可能是show ip fib或者show forwarding route但思路一致比较 RIB 与 FIB 的数量。这里要注意RIB 里有不代表 FIB 里有比如递归路由的下一跳未解析、ECMP 下一跳超过芯片支持的路径数、前缀长度超过芯片最长匹配能力都会导致“路由存在但不转发”。这种情况下先查硬件表不足以解释要再查show forwarding route里有没有具体前缀的 hw index。4. N9K 芯片级参数调整路由表、队列与缓冲区设置4.1 调整转发 profile 扩大路由表在 N9K 上hardware forwarding ipv4 unicast这类命令可以用来选择路由表规模。不同平台命令不同常见做法是在配置模式里用N9K(config)# hardware forwarding ipv4 unicast max-path ? 1-8 maximum number of paths这里我们先看一个更常见的场景把 IPv4 长前缀表从 256K 提升到 512K。在 NX-OS 上可以通过system routing mode或hardware profile来切换。由于平台差异大最稳妥的方式是先看show hardware profile支持哪些选项再在配置模式下修改。修改后需要保存配置并重新加载不然不生效。下面是一个可能存在的配置过程N9K(config)# system routing mode ipv4-lpm-heavy N9K(config)# exit N9K# copy running-config startup-config N9K# reload注意调大路由表会减少 MAC 或 ACL 的可用空间。如果设备同时跑大量 BGP 和 VXLAN不能只盯一个方向。调整前把show hardware capacity输出保存下来和调整后做对比。4.2 用 QoS 模板绑定芯片队列N9K 的 QoS 模板会直接映射到芯片的队列硬件。以典型的数据中心场景为例把网络管理流量放到高优先级队列把存储流量放到中等优先级剩下走默认队列。可以这样写policy-map type qos INPUT-MARKING class type qos MANAGEMENT set qos-group 1 class-map type qos match-any MANAGEMENT match dscp 48 policy-map type queuing OUTPUT-QUEUE class type queuing MANAGEMENT bandwidth percent 20 queue-limit percent 10这里的set qos-group和bandwidth percent最后会映射到芯片内部的队列调度器。不同 ASIC 支持的 queue-limit 粒度和带宽精度不同Tomahawk 的队列数量通常比 CloudScale 多但优先级调度器在 burst 场景下同样会因为 buffer 溢出丢包。所以观察队列丢弃计数时要结合show queuing查看是哪个 class 在丢。如果看到高优先级队列本身在丢包那就是 queue-limit 配得太小或者开启了 WRED 且阈值太低。要确认设备当前生效的 QoS 模板可以使用show policy-map type queuing和show queuing interface对照看。4.3 缓冲区与 PFC/ECN芯片级拥塞控制N9K 支持在端口上开启 PFC优先流控制和 ECN。它们生效的根基都在芯片 buffer 和队列深度上。如果开启 PFC每个优先级都有一块独立的 buffer 区域不能和其他优先级混用。这时如果某个优先级的 buffer 被打满PFC 会向上游发送 pause 帧而不是丢包。ECN 则靠 WRED 检测队列深度并打 CE 标记触发 TCP 拥塞窗口收敛。配置示例interface Ethernet1/1 priority-flow-control mode on no shutdown在芯片级开启 PFC 后 buffer 被划分成若干个 lossless 池。如果发现对端网络延迟变大不能只看 ECN 配置还要看 PFC 暂停帧计数是否在增长。show interface ethernet 1/1输出里的PFC Tx与PFC Rx计数器会告诉你哪个方向在被迫暂停。下表汇总了这几个参数在芯片级调整时的特点调整项命令位置生效方式主要消耗IPv4 路由表大小system routing mode / hardware profilereload内存与 TCAM 分区QoS 队列带宽policy-map type queuing动态生效芯片调度器带宽PFC 开关interface priority-flow-control动态生效每优先级 buffer 池ECN 阈值interface / policy-map动态生效WRED 曲线配置调整这些参数后不能只看配置是否 commit还要回到show hardware capacity和show queuing interface验证实际占用。如果你把 IPv4 表调大ACL 表变小但现网正在跑大量端口 ACL那么重启后会出现 ACL 下发失败。这种情况在变更窗口里很难提前发现因为show hardware profile不会直接告诉你哪些 ACL 会受影响只能靠表项占用估算。5. 把 N9K 芯片级视角落进现网选型、基线记录和三次排障习惯5.1 选型时先看表项和 Buffers而不是只看端口数买 N9K 固定端口设备时不要只看 100G 口数量。同一品牌同一系列端口越多芯片的包处理能力越可能共享。你要问三个问题IPv4 前缀表最大能配多大ACL 条目在开启 VXLAN 后还剩多少每端口 buffer 是独立分配还是共享池如果业务主要是 64 字节小包转发优先选 pps 高的型号如果是存储流量优先选有独立 lossless buffer 和 PFC 能力的型号。芯片决定能力上限配置文件决定能力释放。5.2 上线前记录芯片级基线新设备上线前把三样输出保存到一个文件里show module、show hardware capacity、show queuing interface。保存时标注日期和软件版本。以后出现“网络变慢但又没断”的故障时拿当前输出和基线比重点看表项使用率增长了多少、队列丢弃是否从无到有。这个基线比流量图更早暴露问题因为路由表溢出和 ACL 占用升高往往发生在流量高峰之前。记录基线不需要额外系统直接在本地终端回显保存即可但要注意把show hardware capacity的版本信息也带上避免跨版本对比时看到的是命令输出格式差异。5.3 丢包排障的“三步定位法”遇到丢包先不要抓包先按顺序执行三条命令show interface counters errors show forwarding ipv4 summary show queuing interface ethernet 1/1第一看物理层有没有 CRC第二看 FIB 有没有缺项第三看队列丢弃发生在哪个 class。如果三步都没有问题再去看 ACK 包和对端重传计数问题可能不在本机芯片上。这个顺序能快速把问题范围从“物理层错误”缩小到“芯片表项没下发”再到“芯片内部拥塞”。记住一个容易踩的坑show interface的错包计数清零只在clear counters后生效自己在排障前不要手滑清了计数器否则基线就没了。下次再遇到端口拥塞先看队列计数器再看上调的是哪个 class 的 queue-limit最后回到show hardware capacity确认表项没有挤爆转发表。本文还有配套的精品资源点击获取