1. 课程导入与芯片架构总览
Broadcom 交换芯片是数据中心、园区网与运营商设备中最常见的转发核心之一。学习《Broadcom 交换芯片报文处理与表项资源工程》，目标不是记住某个寄存器地址，而是建立一条完整的心智链路：报文从端口进入，经过怎样的流水线被解析、查表、改写、调度，最终从某个端口发出；支撑这条流水线的表项资源如何组织、如何被占用、如何被耗尽。理解这条链路之后，读手册、看 SDK 代码、定位丢包与表项满问题，都会从"猜"变成"查"。
一、Broadcom 交换芯片家族与定位
Broadcom 的交换芯片大致可分为几个层次。面向高密度数据中心的是 Tomahawk 系列（如 Tomahawk 3/4/5），强调单芯片 12.8T～51.2T 的交换容量与 100G/400G/800G SerDes；面向企业园区与汇聚的是 Trident 系列（Trident 3/4/5），强调丰富的 L2/L3 特性、ACL、隧道与较完整的表项能力；面向接入与低成本场景的是 Helix、Hurricane 等系列。此外还有面向运营商与可编程场景的 Ramon、Jericho 系列，后者通过外部大容量缓存与分层表项支持运营商级队列与路由规模。
这些芯片虽然容量与端口形态不同，但内部结构高度同源：都包含 Ingress Pipeline（入向流水线）、MMU（Memory Management Unit，缓存与队列管理）、Egress Pipeline（出向流水线），以及围绕流水线的 表项内存子系统。学会一款芯片的报文处理与表项资源分析方法，迁移到同家族其他型号时，主要差异集中在容量、表项规格与特性开关，而非整体框架。
二、典型转发流水线
以 Trident/Tomahawk 这类芯片为例，一个单播报文从入端口到出端口，大致经历如下阶段：
- Parser（解析）：按端口配置的解析器图，逐层剥离以太头、VLAN、MPLS、IPv4/IPv6、TCP/UDP 等，生成内部报文头（通常称为 Module Header / System Header），携带入端口、VLAN、优先级、隧道信息等元数据。
- Ingress Pipeline：依次执行 VLAN 处理、L2 查表（MAC 表）、L3 查表（路由表/主机表）、ACL 匹配、隧道终结/封装、ECMP 选路等。每一步都可能读写表项，并更新内部头中的转发决定字段。
- MMU：根据内部头中的优先级与队列映射，把报文放入对应入队列，做缓存管理、拥塞控制（如 PFC、WRED）、调度，再送往出向。
- Egress Pipeline：执行出向 VLAN 编辑、ACL、镜像、计数等，最终由 MAC/SerDes 发出。
需要强调的是，流水线是"表项驱动"的：每一级能做什么，取决于该级可用的表项类型与容量。报文处理与表项资源不是两个独立话题，而是同一枚硬币的两面。
三、报文处理与表项资源在系统中的位置
从系统视角看，交换芯片只是转发面的一部分。它向上通过 PCIe 或内部 CPU 通道连接控制面 CPU，向下连接 PHY/光模块，向外通过 SDK（如 OpenNSL、SAI、Broadcom SDK）暴露配置接口。控制面负责把路由协议、MAC 学习、ACL 策略"写"进表项；转发面负责用这些表项"查"出转发决定。因此，表项资源既是转发面的执行依据，也是控制面与转发面的契约边界。
工程中最常见的三类问题，恰好对应这条边界：
- 表项写不进去：控制面下发失败，通常是表项容量耗尽、HASH 冲突过多或 TCAM 分区不足。
- 报文转发异常：表项存在但匹配不到，常见于 Key 字段配置不一致、VLAN 域不匹配、解析器未识别某层协议。
- 性能不达预期：表项命中但流水线级数过多、MMU 队列拥塞或 ECMP 哈希不均。
四、学习路径
本课程按"由外到内、由静到动"的顺序展开，建议按以下路径推进：
- 架构与流水线：先建立芯片内部结构、报文生命周期与表项资源分布的全局图景（即本节）。
- 解析与内部头：理解 Parser 如何把字节流变成带元数据的内部报文，这是后续所有查表的前提。
- L2/L3 转发与表项：MAC 表、路由表、主机表、ECMP 的组织方式、容量与老化机制。
- ACL 与 TCAM：三态匹配原理、Key/Mask 设计、分区与优先级。
- 隧道与可编程：VXLAN/Geneve 封装解封装、可编程流水线对表项的影响。
- MMU 与 QoS：缓存、队列、PFC、WRED 与调度。
- 排障与容量规划：表项耗尽、丢包、转发异常的定位方法与工程实践。
五、实验环境搭建
本课程后续示例默认基于以下环境，读者可按自身条件替换为等效环境。示例参数仅用于说明方法，不代表任何实测结果。
| 组件 | 建议配置 | 用途 |
|---|---|---|
| 交换平台 | 基于 Trident/Tomahawk 的白盒交换机或评估板 | 承载转发流水线与表项 |
| 控制面 | Linux + SAI/SDK 或 SONiC | 下发路由、ACL、VLAN 等表项 |
| 测试仪 | 支持 100G 的打流仪或两台服务器 + 高速网卡 | 构造报文、观察转发与丢包 |
| 抓包点 | 端口镜像或 TAP | 验证报文改写与转发路径 |
| 监控 | SDK 计数器 / gNMI / telemetry | 观察表项占用与队列状态 |
环境就绪后，建议先做一次最小验证：配置两个 VLAN、两条静态路由，用打流仪发送已知五元组的报文，确认能正确转发；再逐步增加 ACL 与 ECMP 条目，观察表项占用计数器的变化。这个"从空表到满表"的过程，是理解表项资源最直接的方式。
# 示例：查看表项占用（伪代码，具体命令随 SDK 版本变化）
sdk_l2_table_usage() # L2 MAC 表已用/总量
sdk_l3_host_usage() # 主机表已用/总量
sdk_acl_tcam_usage() # TCAM 分区占用
sdk_ecmp_group_usage() # ECMP 组与成员占用