简介这份PDF资料聚焦博通BCM系列交换芯片的工作原理面向网络设备研发、驱动开发及数据中心运维工程师帮助读者理解芯片内部架构与寄存器配置逻辑。资源共1个PDF文件压缩包约3.15MB内容以架构图、寄存器说明与流程解析为主适合作为芯片手册的辅助阅读材料。资料从Architectural系统逻辑视图切入依次讲解Ingress Chip的报文解析、隧道终结与VRF分配Switch Fabric基于HiGig头部的交换选路以及Egress Chip的出端口决策与出口ACL处理同时覆盖TCAM三态匹配与FM特性管理器、GPIC端口模式、CMIC与CPU通信等硬件组件。处理流程部分串联Intelligent Parser、Security Engine、L2交换、L3路由、CAP内容感知处理、Buffer Management与Modification等模块并说明8个CoS队列的调度仲裁与带宽保证机制。目前已有870人学习适合希望系统掌握BCM交换芯片转发链路与调试思路的读者参考。1. 从一次链路不通说起Broadcom 交换芯片到底在交换机里干什么机房里一台 48 口千兆接入交换机上联两个万兆光口做汇聚业务侧反馈某个 VLAN 内主机互 ping 丢包但跨 VLAN 走三层又正常。换过模块、换过跳线、重启过端口问题依旧。最后抓包发现问题出在芯片内部的二层转发表项老化时间配置不一致——一个端口组用默认 300 秒另一个被改成了 30 秒导致单播流量在老化窗口内被泛洪撞上风暴抑制阈值后丢包。这类问题不看芯片手册、不理解 Broadcom 交换芯片的转发流水线光靠命令行是查不出来的。Broadcom 的交换芯片业内常说的 StrataXGS、Trident、Tomahawk 系列以及接入侧的 Robo 系列是绝大多数商用交换机的转发核心。它负责的事情很具体MAC 学习、VLAN 处理、ACL 匹配、三层路由查表、流量镜像、QoS 调度、拥塞管理。你敲的每一条show mac address-table、每一条 ACL 规则最终都要翻译成芯片的寄存器配置和表项写入。理解它的原理不是为了去写驱动而是为了在排障时知道“这条命令背后芯片在做什么”以及“为什么有些配置组合芯片根本不支持”。这份《Broadcom 交换芯片原理介绍》适合三类人一是网络运维工程师想搞懂交换机内部转发逻辑排障时不再靠猜二是嵌入式/驱动开发人员需要对接 SDK 做表项下发三是网络方案设计者选型时要判断某颗芯片能不能满足 ACL 规模、表项深度、缓存大小的硬性要求。下面按“芯片架构 → 转发流水线 → 表项与资源 → 配置落地 → 避坑”的顺序拆开讲。2. 芯片架构与转发流水线从端口进来一个包到从另一个端口出去2.1 交换芯片的三大功能块 ingress、MMU、egressBroadcom 交换芯片的内部结构可以粗略切成三块入方向处理Ingress Pipeline、缓存与调度MMUMemory Management Unit、出方向处理Egress Pipeline。一个包从端口 PHY 进来先经过 ingress 做解析、查表、ACL 匹配然后决定送到哪个出端口如果出端口拥塞包会进 MMU 排队最后从 egress 出去前还要再做一次 VLAN 编辑、ACL 匹配和镜像判断。Ingress 阶段的核心动作是解析Parser和查表Lookup。Parser 把包头的各层字段拆出来——目的 MAC、源 MAC、VLAN Tag、以太类型、目的 IP、源 IP、TCP/UDP 端口号形成一个内部的解析结果向量。这个向量会同时喂给多张表MAC 表L2 转发、路由表L3 转发、ACL 表策略匹配。查表结果合并后得到一个转发决定Forwarding Decision包含出端口、是否丢弃、是否镜像、优先级等。MMU 是很多人忽略但排障时最常背锅的部分。它管理芯片内部的包缓存Packet Buffer负责入队、出队、丢弃决策。当出端口队列超过阈值或者全局缓存被某个端口吃满MMU 会触发 WRED加权随机早期检测或者尾丢弃。你看到的show interface counters里的 output drops大概率就是 MMU 丢的而不是端口物理层丢的。Egress 阶段做的是“出门前的最后检查”VLAN Tag 的添加或剥离、ACL 的二次匹配有些芯片支持 egress ACL、镜像目的端口的复制、以及 QoS 的最终调度。理解这三段的顺序很重要因为 ACL 在 ingress 和 egress 匹配的字段范围不一样比如 ingress ACL 可以匹配入端口egress ACL 通常不能。2.2 转发流水线的关键表项MAC 表、路由表、ACL 表Broadcom 芯片的转发表项不是软件里的哈希表而是 TCAM三态内容寻址存储器和 SRAM 的组合。MAC 表通常用哈希表实现支持几万到几十万条路由表LPM最长前缀匹配用算法表或 TCAMACL 表用 TCAM容量有限通常几千条到几万条不等。MAC 表的写入流程是这样的芯片收到一个源 MAC 未知的包会在 ingress 阶段触发 MAC 学习把源 MAC、VLAN ID、入端口写入 MAC 表。如果目的 MAC 查不到包会在 VLAN 内泛洪。这里有个常见误区很多人以为 MAC 表老化是软件定时器控制的实际上老化时间由芯片寄存器配置软件只是读回来显示。所以当你改老化时间时是在写芯片寄存器不是改内核参数。路由表的关键是 LPM。芯片用一棵前缀树或者 TCAM 来实现最长前缀匹配。IPv4 和 IPv6 的表项深度不一样IPv6 通常更吃 TCAM 资源。如果你在一台交换机上同时跑 IPv4 和 IPv6 双栈ACL 又配了很多TCAM 可能不够用表现为部分 ACL 规则不生效或者路由表项下发失败。这时候show platform或者 SDK 的调试命令能看到 TCAM 使用率。ACL 表是排障时最容易翻车的地方。Broadcom 芯片的 ACL 通常分多个 stage每个 stage 能匹配的字段和能执行的动作有限。比如你写了一条 ACL 要同时匹配源 IP、目的 IP、TCP 端口和 DSCP芯片可能因为字段跨了多个 stage 而无法用一条表项实现SDK 会把它拆成多条或者直接返回不支持。这就是为什么有些 ACL 在软件模拟器上能过在真实芯片上不生效。2.3 一个包在芯片里的完整路径从入端口到出端口的逐步拆解假设一个包从端口 1 进来VLAN 10目的 MAC 是端口 2 下挂的主机。路径如下第一步PHY 层把电信号转成比特流MAC 层做 FCS 校验去掉前导码和帧间隙把包交给 ingress pipeline。第二步Parser 解析包头提取目的 MAC、源 MAC、VLAN ID。如果端口是 trunk 模式VLAN Tag 会被保留如果是 access 模式会打上端口默认 VLAN。第三步Ingress 查 MAC 表。用目的 MAC VLAN ID 做 key查到出端口是端口 2。同时源 MAC VLAN ID 入端口 1 被写入 MAC 表如果之前没学过。第四步Ingress ACL 匹配。如果配了 ACL芯片会用 TCAM 并行匹配所有规则命中第一条后执行动作permit、deny、redirect、mirror、count。第五步转发决定送到 MMU。如果端口 2 的队列没满包直接进队列如果满了根据队列阈值决定丢弃还是标记 ECN。第六步Egress pipeline 处理。检查出端口是否允许该 VLAN 通过是否需要剥离 Tag是否有 egress ACL 或镜像规则。第七步包从端口 2 的 PHY 发出去。这个路径里每一步都可能出问题。比如第三步 MAC 表查不到包会泛洪第四步 ACL 命中 deny包被丢第五步 MMU 队列满包被丢第六步出端口不允许 VLAN包被丢。排障时要知道看哪一步的计数器而不是盲目重启。3. 表项资源与硬件限制为什么有些配置在模拟器上能过在芯片上不行3.1 TCAM 与哈希表的容量边界ACL 和 MAC 表的硬上限Broadcom 不同型号的芯片TCAM 和哈希表容量差别很大。接入级芯片可能只有 1K 到 2K 条 ACL 表项汇聚级能到 4K 到 8K核心级 Tomahawk 系列能到几十 K。MAC 表通常 16K 到 128K 不等路由表 IPv4 可能 16K 到 64KIPv6 减半甚至更少。这些数字不是随便写的它们直接决定你的网络设计能不能落地。比如你要在接入交换机上做基于源 IP 的限速每个用户一条 ACL1000 个用户就是 1000 条 TCAM 表项。如果芯片只有 2K TCAM再算上系统预留和其他策略可能到 800 个用户就满了。满了之后新用户上线ACL 下发失败表现为“部分用户限速不生效”。查 TCAM 使用率的方法因厂商而异。常见做法是看 SDK 的调试命令比如bcm shell下的show acl或者show tcam。有些厂商会在show platform resources里暴露。如果你拿不到这些命令可以看日志里有没有“table full”或者“resource exhausted”的关键字。3.2 表项下发失败怎么查从 SDK 日志到寄存器读回表项下发失败通常有三个原因TCAM 满了、字段组合不支持、优先级冲突。排查顺序建议从软件日志开始再到 SDK 调试最后到寄存器读回。软件日志里搜error、fail、full、unsupported。很多厂商的 SDK 在表项下发失败时会打一条 warning但默认可能被限流或关闭。你需要确认日志级别。如果日志没线索进 SDK shell。Broadcom SDK 通常提供bcm shell或者diag shell里面可以查表项占用、查端口状态、查寄存器。比如show acl看 ACL 表项数和命中计数show l3看路由表show mac看 MAC 表。寄存器读回是最后手段。比如你想确认某个端口的 VLAN 成员关系可以读端口 VLAN 寄存器。但这一步需要芯片手册不同型号寄存器地址不一样风险也高读错地址可能触发异常。我一般只在前面两步都查不出时才动寄存器而且先备份配置。3.3 常见资源冲突场景ACL 与路由表争抢 TCAM最典型的冲突是 ACL 和路由表抢 TCAM。有些芯片的路由表用 TCAM 实现 LPMACL 也用 TCAM两者共享资源池。当你配了大量 ACL 后路由表项可能下发失败表现为“部分路由丢失”或者“新路由学不到”。另一个场景是 IPv6 和 IPv4 共享 TCAM。IPv6 前缀长度 128 位占用的 TCAM 宽度是 IPv4 的四倍。如果你同时跑双栈IPv6 路由表可能把 TCAM 吃光导致 IPv4 ACL 无法下发。还有一种隐蔽的冲突镜像和 ACL 共用同一个 stage。你配了端口镜像又配了 ACL redirect两者可能互相覆盖。表现为镜像流量时有时无或者 ACL 重定向不生效。避免这类问题的办法是提前算账。选型时问清楚芯片的 TCAM 总容量、IPv4/IPv6 各占多少、ACL 和路由表是否共享。部署时留 20% 余量不要等到 100% 才扩容。4. 配置落地从命令行到芯片表项的映射与验证4.1 用 SDK 命令查看芯片表项以 MAC 表和 ACL 表为例不同厂商的 SDK 命令不一样但思路一致找到进入 SDK shell 的方式然后用 show 命令查表。下面以常见的 Broadcom SDK 风格举例具体命令名以你手上的设备为准。# 进入 SDK shell不同厂商入口不同常见是 bcm shell 或 diag shell bcm shell # 查看 MAC 表项数量和前几条 show mac # 查看 ACL 表项占用和命中计数 show acl # 查看 TCAM 使用率 show tcam # 查看端口 VLAN 成员关系 show vlan # 退出 exit逻辑说明show mac会列出芯片当前学到的 MAC 表项包括 MAC 地址、VLAN、端口、老化状态。如果你发现某个 MAC 学不到先看这张表里有没有。show acl会列出 ACL 表项和每条规则的命中计数命中计数为 0 说明规则没匹配到流量可能是字段写错或者流量没经过这个 stage。show tcam看 TCAM 使用率接近 100% 就要警惕。参数说明不同 SDK 版本的show命令参数可能不同比如show mac可能支持port参数过滤某个端口。建议先敲show mac ?看帮助。如果命令不存在说明你的 SDK 版本不支持或者被厂商裁剪了需要找厂商要调试手册。4.2 配置 VLAN 和 ACL 后怎么确认芯片真的写进去了配完 VLAN 和 ACL不要只看show running-config那只是软件配置不代表芯片表项写成功了。验证分三步第一步看软件层面的表项。比如show vlan看 VLAN 成员show acl看 ACL 规则。这一步确认软件配置没被静默丢弃。第二步看芯片层面的表项。进 SDK shell用show vlan和show acl对比。如果软件有、芯片没有说明下发失败去日志里找原因。第三步打流验证。用测试仪或者两台主机对打看 ACL 命中计数有没有涨看 VLAN 内流量是否按预期转发或丢弃。# 软件层面查看 VLAN 和 ACL show vlan 10 show acl # 芯片层面查看进 SDK shell 后 bcm shell show vlan show acl exit # 打流后看 ACL 命中计数 show acl counters逻辑说明软件和芯片两层对比能快速定位是配置没下发还是芯片没执行。打流验证是最终确认因为有些表项写进去了但字段匹配不对只有真实流量能暴露。参数说明show acl counters可能不是所有平台都支持有些平台用show acl直接带计数。如果计数不涨检查 ACL 绑定的方向ingress 还是 egress和端口是否正确。4.3 一个完整的验证流程配 ACL 限速并确认芯片生效假设你要在端口 1 上对源 IP 192.168.1.100 做限速限速 10Mbps。配置步骤和验证流程如下# 第一步配 ACL 匹配源 IP acl number 3000 rule 10 permit ip source 192.168.1.100 0 quit # 第二步配流分类和流行为 traffic classifier c1 if-match acl 3000 quit traffic behavior b1 car cir 10000 quit traffic policy p1 classifier c1 behavior b1 quit # 第三步应用到端口 1 入方向 interface GigabitEthernet 0/0/1 traffic-policy p1 inbound quit # 第四步软件层面确认 show acl 3000 show traffic-policy p1 # 第五步芯片层面确认进 SDK shell bcm shell show acl show meter exit # 第六步打流验证看限速是否生效 # 用测试仪发 20Mbps 流量看接收端是否降到 10Mbps 左右逻辑说明ACL 匹配源 IP流行为做 CAR承诺访问速率流策略把两者绑定后应用到端口入方向。软件层面确认配置存在芯片层面确认 ACL 和 meter 表项写进去了最后打流验证限速效果。参数说明car cir 10000单位是 kbps10000 就是 10Mbps。不同厂商的 CAR 参数可能还有 CBS承诺突发尺寸和 PBS峰值突发尺寸默认值可能不适合你的流量模型需要根据包大小调整。如果限速不生效先看 ACL 命中计数涨不涨不涨说明 ACL 没匹配到涨了但限速没效果看 meter 表项有没有写进去。5. 避坑与常见问题那些年我们在 Broadcom 芯片上踩过的坑5.1 现象ACL 规则配了但不生效计数为 0原因最常见的是 ACL 绑定的方向错了。比如流量是从端口 1 进、端口 2 出你在端口 2 的 ingress 方向绑 ACL但端口 2 在这个流量里是出方向ingress ACL 匹配不到。另一个原因是 ACL 字段跨了多个 stage芯片无法用一条表项实现SDK 静默丢弃了规则。解决先确认流量方向ingress ACL 绑在入端口egress ACL 绑在出端口。然后进 SDK shell 看 ACL 表项有没有写进去没写进去就查日志里的 unsupported 关键字。如果字段太复杂拆成多条简单规则或者用流分类替代。5.2 现象MAC 表学不到流量一直泛洪原因可能是端口安全port security限制了 MAC 学习数量或者 VLAN 没放通导致包在 ingress 就被丢了。也可能是老化时间设得太短MAC 刚学到就老化表现就是一直泛洪。解决先看端口安全配置show port-security看有没有超限。然后看 VLAN 成员确认入端口和出端口都在同一个 VLAN 里。最后看老化时间show mac aging-time如果设成 10 秒这种极端值改回 300 秒试试。5.3 现象TCAM 满了新 ACL 或路由下发失败原因ACL 和路由表共享 TCAM或者 IPv6 表项占用太多。也可能是之前删掉的 ACL 没有真正释放 TCAM存在残留表项。解决先看 TCAM 使用率确认是不是真的满了。如果是删掉不用的 ACL 和路由然后看使用率有没有降。如果删了不降可能是残留需要重启芯片或者找厂商要清理命令。长期方案是选型时留足 TCAM 余量或者把 ACL 下沉到更靠近用户的设备。5.4 现象端口镜像时有时无或者镜像流量不全原因镜像和 ACL 共用同一个 stageACL redirect 可能覆盖镜像规则。另一个原因是镜像目的端口带宽不够镜像流量被 MMU 丢弃。解决检查镜像和 ACL 的优先级调整 stage 顺序。镜像目的端口要用足够带宽的端口比如万兆镜像千兆流量。如果还是不全看 MMU 丢弃计数确认是不是缓存满了。5.5 现象改了配置后芯片行为没变重启才生效原因有些表项下发是异步的软件配置改了但芯片表项没更新可能是 SDK 的缓存机制或者下发队列堵了。也可能是配置命令本身不支持热生效需要重启芯片或者重启设备。解决先看日志有没有下发失败。然后进 SDK shell 看芯片表项是不是旧值。如果是异步问题等几秒再看。如果确认不支持热生效只能重启。我一般改完关键配置后都会进 SDK shell 确认一遍芯片表项避免“以为改了其实没改”。6. 进阶技巧用 SDK 调试命令定位转发异常与性能瓶颈6.1 用计数器定位丢包点从端口到 MMU 到 ACL丢包排查的核心是看计数器。Broadcom 芯片的计数器分几层端口层RMON 计数器、MMU 层队列丢弃计数、ACL 层规则命中计数、流水线层各 stage 的丢弃计数。定位丢包点时从入端口开始逐层往出端口查。# 端口层计数器 show interface GigabitEthernet 0/0/1 counters # MMU 层队列丢弃 bcm shell show mmu show cosq exit # ACL 层命中计数 show acl counters # 流水线各 stage 丢弃计数部分平台支持 bcm shell show pipeline exit逻辑说明端口层看物理层和 MAC 层丢包MMU 层看缓存丢弃ACL 层看策略丢弃流水线层看解析或查表异常丢弃。逐层对比哪一层计数在涨问题就在哪一层。参数说明show mmu和show cosq的具体输出因芯片型号而异重点看每个队列的丢弃计数和当前深度。如果某个队列丢弃计数持续涨说明该队列对应的出端口拥塞需要调整 QoS 调度或者扩容。6.2 用镜像和 ACL 计数做流量分析不抓包也能定位有时候现场不方便抓包可以用镜像加 ACL 计数做粗粒度分析。比如你怀疑某个 IP 在发大量异常流量可以配一条 ACL 匹配该 IP看命中计数涨得多快。如果计数涨得很快说明流量确实大如果计数不涨说明流量没经过这个端口或者字段匹配不对。# 配 ACL 匹配可疑 IP 并计数 acl number 3001 rule 10 permit ip source 192.168.1.200 0 quit # 应用到入端口 interface GigabitEthernet 0/0/1 traffic-policy p2 inbound quit # 看计数 show acl 3001逻辑说明ACL 计数是芯片硬件计数不消耗 CPU适合在线分析。你可以同时配多条 ACL 匹配不同 IP 或协议对比计数涨速快速定位异常流量来源。参数说明ACL 计数是累计值看的时候要间隔几秒看两次算差值。如果计数不涨检查 ACL 绑定的端口和方向是否正确。6.3 性能瓶颈判断什么时候是芯片限制什么时候是配置问题芯片限制和配置问题的区分看三个指标TCAM 使用率、MMU 队列深度、CPU 占用率。TCAM 接近 100% 说明表项资源不够是芯片限制MMU 队列持续满说明缓存不够或者调度不合理可能是配置问题CPU 占用率高说明有大量包上送 CPU可能是协议报文或者异常流量。我一般会先看 TCAM 和 MMU这两个是硬件资源满了就是满了只能优化配置或者换芯片。CPU 占用率高通常是配置问题比如 ACL 没匹配到导致包上送 CPU或者协议报文被泛洪。从那以后我每次上架新设备都会先跑一遍基线看 TCAM 初始使用率、MMU 队列深度、CPU 占用率记下来。后面出问题时对比基线就能快速判断是硬件资源耗尽还是配置变更引入的。这个习惯帮我省了很多排查时间希望帮到你。本文还有配套的精品资源点击获取