简介面向数据中心网络工程师与思科技术学习者的技术讲座资料聚焦 Nexus 9000 系列模块化与 TOR 交换机的架构解析帮助读者理解云规模 ASIC 的硬件设计逻辑与高性能转发机制。内容围绕数据中心与硅策略、Cloud Scale 架构与 ASIC、转发特性、9500/9300 平台对比及 Packet Walks 展开涉及 Trident2、Tomahawk、Jericho 等商用芯片方案与 Cisco 自研芯片的差异并讲解硬件 QoS、拥塞管理、VXLAN 隧道支持与流式遥测等关键能力。资源包共 1 个 PDF 文件约 3.56MB为英文原版演讲课件适合按章节系统研读或作为选型参考。已有 286 人学习适合希望深入掌握思科数据中心交换硬件细节、补齐架构认知的中高级网络从业者。1. 云规模交换芯片为什么 100G 端口密度不是靠堆端口堆出来的一台 1U 交换机前面板塞满 36 个 100G 端口这件事本身不稀奇。稀奇的是这些端口背后的转发芯片并不是一个“36 进 36 出”的大开关而是被切成了若干个自包含的转发复合体每个复合体只管一部分端口彼此之间再通过一个片内互连结构做任意到任意的无阻塞连接。这个设计叫“切片”Slice是理解云规模交换 ASIC 的第一把钥匙。很多人看数据中心交换机习惯从端口数、吞吐量、时延这些指标切入但真正决定一台设备能不能在云规模场景下扛住东西向流量、能不能在拥塞时保住关键业务、能不能把遥测数据吐出来的是芯片内部的分区方式和查表资源的组织方式。这份 2018 年的芯片级架构资料把转发流水线、弹性表项、缓冲区调度和报文走查拆得很细值得逐层拆开看。搞懂切片和弹性表项这两件事再看任何一台标称“云规模”的交换机心里都会有一杆秤。2. 切片架构一个 ASIC 为什么要拆成多个独立转发域2.1 切片不是物理分区是转发逻辑的自包含单元切片Slice的定义很干脆单个 ASIC 内部一个自包含的转发复合体控制该芯片上的一部分端口。每个切片内部再分为入方向Ingress和出方向Egress两套功能入方向切片连接到所有出方向切片切片互连Slice Interconnect负责提供非阻塞的任意到任意互连。这个结构解决的是一个很实际的问题如果整个芯片是一个巨大的统一转发域那么端口数量一多入方向查表引擎和出方向排队引擎之间的交叉连接就会变成组合爆炸。拆成切片之后每个切片内部的入到出路径是局部的跨切片的流量走互连结构互连结构按切片粒度做调度复杂度从“端口数平方”降到“切片数平方”。常见的实现思路是切片数量随芯片规格变化但切片的内部结构保持一致。比如 1.8T 的芯片做成 2 个切片、每切片 9 个 100G或者 1 个切片 18 个 100G6.4T 的芯片做成 4 个切片、每切片 16 个 100G。切片数量不同但每个切片里都有完整的解析器、查表流水线、入方向转发控制器、出方向缓冲排队调度、出方向策略和报文重写。这种“同构复制”让芯片设计可以按切片做验证也让软件侧看到的转发行为在不同规格平台上保持一致。提示切片互连是非阻塞的意味着跨切片流量的带宽不会因为切片划分而打折。但非阻塞指的是互连结构本身不代表端口的线速承诺在所有流量模式下都成立缓冲区行为是另一回事。2.2 入方向流水线解析、分类、查表、负载均衡入方向转发控制器的职责链条是报文解析器Packet Parser先拆包头入方向分类Ingress Classification做初步归类然后进入转发查表Forwarding Lookup查表结果交给负载均衡和拥塞感知逻辑AFD / DPP最后送到出方向切片。这里有个容易被忽略的细节查表流水线里除了常规的 TCAM 和弹性表项Flex Tiles在部分芯片型号上还有一张流表Flow Table。流表的存在意味着芯片可以在硬件层面维护流级别的状态而不是每个报文都从头做一次完整查表。对于需要做流级遥测、流级策略或者流级负载均衡的场景这张表是硬件加速的关键。报文解析器的深度决定了芯片能识别多少层封装。单次隧道封装single-pass tunnel encapsulation这类能力前提就是解析器能在一次穿越流水线的过程中把外层隧道头和内层原始头都解析出来查表时同时拿到内外层信息。如果解析器只能剥一层那就得回环一次时延和吞吐都会受影响。2.3 出方向缓冲、排队、调度、复制、重写出方向切片负责的事情比入方向更“重”缓冲Buffering、排队Queuing、调度Scheduling、报文复制Replication、出方向策略Egress Policy、报文重写Packet Rewrites、出方向 MAC。缓冲区是共享的出方向缓冲配合动态的流量优化机制。为什么出方向要做复制因为组播和广播流量在入方向查表时只查一次但需要在多个出端口上各发一份。如果复制放在入方向做入方向切片的带宽会被复制放大放在出方向做每个出方向切片只负责自己端口的那一份复制成本被分摊到各个出方向切片上。这是切片架构在组播场景下的一个隐性优势。报文重写放在出方向也有讲究。入方向查表拿到的是转发决策出端口、重写 MAC、BD 等真正的包头改写发生在出方向这样入方向的查表结果可以更早地进入排队减少入方向流水线的占用时间。常见的实现思路是把重写信息作为查表结果的一部分携带到出方向出方向在发送前统一执行。2.4 切片互连的调度语义切片互连不是一根简单的总线它要处理的是多个入方向切片同时向多个出方向切片发送流量的仲裁问题。由于每个出方向切片有自己的缓冲和排队互连结构只需要把报文送到目标出方向切片的入口剩下的排队和调度由出方向切片自己完成。这种“互连只负责搬运、出方向负责排队”的分工让互连结构可以做得相对简单而把复杂的缓冲管理下放到每个出方向切片。从报文走查的角度看一个跨切片转发的报文路径是入方向 MAC → 解析器 → 入方向查表 → 查表结果 → 切片互连 → 目标出方向切片 → 出方向缓冲排队调度 → 出方向策略 → 报文重写 → 出方向 MAC → 发送。同切片转发的报文则不走互连直接在切片内部从入方向走到出方向。这个差异在分析时延时要注意跨切片和同切片的时延不完全一样。3. 弹性表项为什么查表资源要做成可配置的池子3.1 Flex Tile 的本质是“表项池 功能模板”传统交换芯片的查表资源是硬划分的LPM 表多大、主机路由表多大、MAC 表多大、ECMP 表多大出厂就定了。云规模场景的问题是不同客户、不同部署位置对表项的需求差异极大。一个互联网对等互联的边缘设备需要海量 LPM 前缀一个虚拟化数据中心内部的 TOR 需要海量主机路由和邻接表一个组播密集的场景需要大量 (*,G) 和 (S,G) 表项。硬划分意味着总有一类表项不够用另一类闲置。弹性表项Flexible Forwarding Tiles简称 Flex Tile的做法是芯片里有一批同构的表项存储块每个块叫一个 tiletile 的数量和每个 tile 的条目数随芯片型号不同。这些 tile 组成一个可 fungible 的池子通过“路由模板”Routing Template在系统初始化时决定每个 tile 承担什么功能。功能包括 IPv4/IPv6 单播最长前缀匹配LPM、IPv4/IPv6 单播主机路由表HRT、IPv4/IPv6 组播 (*,G) 和 (S,G)、MAC 地址/邻接表、ECMP 表、ACI 策略等。这个设计的精妙之处在于硬件只提供同构的存储和查表能力功能分配是软件在启动时通过模板决定的。模板在系统初始化时定义更改需要重启。这不是缺陷是取舍——运行中动态重配表项划分会带来转发中断和一致性风险启动时一次性划分换来的是运行期的确定性和可预测性。3.2 路由模板的几种典型取向资料里列出的模板包括Default、Dual-stack host scale、Internet peering、LPM heavy、MPLS heavy、Multicast heavy、Multicast NBM。每个模板对应一种表项配比取向。Default 是均衡配置适合大多数通用场景。Dual-stack host scale 把更多 tile 分配给主机路由表适合虚拟化环境里大量 /32 和 /128 主机条目的场景但这个模板不支持 IP 组播且在模块化平台上不可用。Internet peering 偏向 LPM适合需要大量外部前缀的边缘位置。LPM heavy 进一步加重 LPM 配比。MPLS heavy 给 MPLS 标签相关表项更多空间。Multicast heavy 和 Multicast NBM 偏向组播表项后者在 TOR 上不支持。选模板这件事血泪经验是不要等到上线后发现表项不够再改。模板变更要重启生产环境重启的代价不用多说。规划阶段就要按业务画像估算表项需求比如一个跑容器网络的环境主机路由条目可能比预期多一个数量级Default 模板大概率不够。3.3 HRT、LPM 和 TCAM 的三层配合IP 表项的存储不是单一结构而是三层配合。HRTHost Route Table是哈希表专门存 IPv4 /32 和 IPv6 /128 主机条目从 flex tile 里划资源。LPM 是传统的前缀/掩码条目或者用“pivot”加“trie”的 tile 组合来存其他前缀长度也从 flex tile 划资源。TCAM 则处理溢出和哈希冲突是传统 TCAM 存储器前置在弹性转发查表之前。这个三层结构的分工逻辑是主机路由是精确匹配哈希表最合适查得快、存得密非主机前缀是范围匹配用 LPM 结构哈希冲突和表项溢出兜底给 TCAM。TCAM 容量有限、功耗高所以只做兜底不做主力。这种“哈希为主、LPM 为辅、TCAM 兜底”的配比是在容量、速度、功耗之间做的平衡。从查表流程看一个 IP 单播报文进来先做路由器 MAC 匹配判断目的 MAC 是不是路由器 MAC命中则触发 L3 查表。硬件对 VRF 做精确匹配、对目的 IP 做最长匹配查表结果返回邻接指针索引进 MAC 表或 ECMP 指针。MAC 表里存的是输出 BD、重写 MAC、输出端口。ECMP 指针则进入 ECMP 表选组。这条链路里HRT 和 LPM 都在 flex tile 池子里TCAM 在池子前面做兜底三者的容量配比由模板决定。3.4 模板选择的实际约束几个硬约束值得记下来Dual-stack host scale 不支持 IP 组播且在模块化 Nexus 9500 上不支持Multicast NBM 在 TOR 上不支持模板在系统初始化时定义更改需要重启。这些约束不是随便写的背后是 tile 数量和芯片规格的物理限制——某些模板需要的 tile 组合在特定芯片或特定平台上凑不齐。规划时的做法是先列出业务需要的表项类型和大致规模再对照模板的能力矩阵选最接近的留出余量。如果业务画像在部署后会快速变化宁可一开始选一个偏保守的模板也不要频繁重启改模板。常见的实现思路是把模板选择纳入开局基线配置和软件版本一起锁定变更走严格的审批流程。4. 缓冲区与拥塞感知共享出方向缓冲怎么不变成黑匣子4.1 共享出方向缓冲的基本模型出方向切片的缓冲是共享的不是每个端口固定分一块。共享缓冲的好处是突发流量可以借用空闲端口的内存提高缓冲利用率坏处是一个端口的突发可能挤占其他端口的缓冲导致无辜流量被丢。所以共享缓冲必须配一套动态的、先进的流量优化机制资料里提到的 DBP、AFD、DPP 就是这类机制。DBPDynamic Buffer Protection的思路是给缓冲使用设动态上限防止单个端口或队列把共享池吃干。AFDApproximate Fair Dropping的思路是在拥塞初期做近似公平的丢弃让多个流分担拥塞成本而不是让某个大流把缓冲占满后触发全局丢弃。DPPDynamic Packet Prioritization则是在缓冲紧张时按优先级做取舍保住关键流量。这些机制的名字听起来像玄学但底层逻辑是一致的共享缓冲是一个有限资源必须有准入和淘汰策略否则就是先到先得突发流量会把稳态流量挤死。硬件把这些策略做进芯片好处是决策在纳秒级完成不依赖软件轮询代价是策略参数需要调调不好就是黑匣子。4.2 拥塞感知与流片负载均衡资料里提到 ACI 策略模型加拥塞感知的流片负载均衡congestion-aware flowlet switching。流片flowlet的思路是把一条大流按时间间隔切成若干片不同片可以走不同路径利用 ECMP 的多路径能力。拥塞感知则是在选路径时参考链路拥塞状态而不是纯哈希。这个机制解决的是 ECMP 哈希不均的问题。传统 ECMP 按五元组哈希大流之间哈希碰撞会导致某些链路拥塞、某些链路空闲。流片切换让大流可以在多个路径间动态迁移拥塞感知让迁移决策有依据。硬件支持这件事的前提是芯片能维护流片状态和路径拥塞信息这又回到前面说的流表和遥测能力。4.3 遥测流表、事件通知和流式统计导出云规模交换芯片的遥测能力分几层。流表Flow Table在 LSE、LS1800FX、LS3600FX2 这些芯片上有用来做流级别的状态维护支撑流表事件通知和 Tetration Analytics 这类分析系统。流式统计导出SSX在 S6400 和 LS3600FX2 上有把统计数据持续推出去而不是等轮询。遥测这件事的价值在于数据中心网络的故障和性能问题很多不是“断了”而是“慢了”或者“某类流量被丢了”。传统 SNMP 轮询的粒度和频率都不够流式遥测把芯片内部的计数器、流表状态实时吐出来才能做容量规划、安全分析和故障定位。硬件内置这些能力比软件采样准确得多因为软件采样会漏掉瞬时的微突发。注意遥测数据量大导出通道和采集端的处理能力要匹配。开了全量流表遥测但采集端扛不住结果就是采集端丢数据反而制造盲区。5. 避坑与排查切片和表项配置里最容易翻车的几件事5.1 模板选错导致表项耗尽现象业务上线后主机路由条目增长突然新虚机无法通信查表显示主机路由表满但 LPM 表还有大量空闲。原因开局用了 Default 模板主机路由表HRT分配的 tile 不够而 LPM 分配的 tile 闲置。Default 是均衡配置不偏向主机路由密集场景。解决规划阶段按业务画像估算 HRT 需求虚拟化或容器环境优先考虑 Dual-stack host scale 模板注意该模板不支持 IP 组播模块化平台不可用。已经上线的环境改模板需要重启安排在维护窗口改之前先导出当前表项使用率做对比基线。5.2 跨切片流量时延高于预期现象同样端口速率下某些端口对的转发时延比另一些高出一截抓包看路径没有异常。原因跨切片转发要走切片互连同切片转发不走。端口在芯片上的切片归属决定了流量是同切片还是跨切片。规划时如果没注意端口到切片的映射关键低时延业务可能被分到跨切片路径上。解决查芯片的端口到切片映射表把时延敏感且互访频繁的端口尽量放在同一切片内。这不是总能做到但至少要知道哪些流量是跨切片的做容量和时延预算时留出余量。5.3 共享缓冲被单端口突发打爆现象一个端口跑大流量突发时其他端口的流量出现丢弃但总缓冲使用率看起来没到 100%。原因共享出方向缓冲没有配好动态保护单个端口或队列把共享池吃到接近上限触发其他端口的丢弃。总使用率没到 100% 是因为丢弃发生在准入阶段不是缓冲真的耗尽。解决检查 DBP、AFD、DPP 相关配置确认动态缓冲上限和优先级策略生效。对已知的突发源端口做单独的缓冲配额限制避免它挤占共享池。监控要按端口和队列看缓冲使用不能只看总量。5.4 遥测开启后采集端丢数据现象开了流表遥测和 SSX 之后分析平台的数据出现缺口时间戳不连续。原因遥测导出速率超过采集端处理能力或者导出通道本身有带宽限制。芯片侧遥测是硬件持续吐数据不会因为采集端慢就自动降速。解决先算清楚导出数据量按流表条目数和统计项估算每秒字节数再对照采集端的摄入能力。必要时做采样或聚合牺牲部分粒度换完整性。导出通道的配置也要检查别让遥测流量和业务流量抢同一个出口。5.5 哈希冲突把流量打到 TCAM 兜底现象某些前缀的转发查表时延偏高或者表项监控显示 TCAM 使用率异常增长。原因HRT 是哈希表哈希冲突的表项溢出到 TCAM。如果主机路由条目分布导致哈希冲突率高TCAM 会被大量占用而 TCAM 查表比哈希表慢、功耗高。解决监控 TCAM 使用率作为预警指标不要等它满了才看。如果冲突率持续偏高考虑调整模板给 HRT 更多 tile或者评估前缀分布是否异常比如大量同掩码长度的条目集中哈希到少数桶。TCAM 是兜底资源长期高水位说明前面的哈希层没配好。6. 设计取舍为什么“启动时定模板”比“运行中动态调”更靠谱把切片架构和弹性表项放在一起看会发现这套设计有一个共同的哲学把不确定性挡在启动之前。切片数量、每切片端口数、tile 数量、模板配比这些在芯片出厂和系统初始化时就定了运行期不再变。换来的是转发行为的确定性——查表时延可预测、缓冲行为可建模、遥测数据可解释。动态调整听起来更灵活但代价是什么表项重划分意味着查表结构在运行中改变已经学到的表项要迁移迁移期间转发可能中断或者走慢路径缓冲区配额动态调整意味着排队行为在运行中变化时延和丢弃的基线漂移故障定位失去参照。对于数据中心这种要求可预测性的环境运行期确定性比运行期灵活性更值钱。这个取舍也解释了为什么模板变更要重启不是实现偷懒是设计上就不打算支持热改。规划阶段把业务画像做准比运行期频繁调参更符合这套架构的脾气。我一般会这么理解云规模交换芯片把复杂度从“运行期动态适应”转移到了“规划期精确建模”用前期的规划成本换运行期的稳定和可观测。验证这套设计是否按预期工作方法也围绕确定性展开。表项使用率要按类型分别监控不能只看总量跨切片和同切片的时延要分开测建立各自的基线缓冲使用要按端口和队列看配合丢弃计数器做交叉验证遥测数据的完整性和导出速率要定期核对。这些指标建立起来之后任何偏离基线的变化都是信号而不是黑匣子里猜。从那以后我每次规划这类平台都强制先把业务表项画像和端口互访矩阵画出来再对照模板能力矩阵选型最后把监控基线一起定好才上线。希望帮到你。本文还有配套的精品资源点击获取
