企业官网建设流程全解析

简介：这份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、egress

Broadcom 交换芯片的内部结构，可以粗略切成三块：入方向处理（Ingress Pipeline）、缓存与调度（MMU，Memory 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，最长前缀匹配）用算法表或 TCAM；ACL 表用 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 到 64K，IPv6 减半甚至更少。

这些数字不是随便写的，它们直接决定你的网络设计能不能落地。比如你要在接入交换机上做基于源 IP 的限速，每个用户一条 ACL，1000 个用户就是 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 实现 LPM，ACL 也用 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单位是 kbps，10000 就是 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 共用同一个 stage，ACL 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 占用率，记下来。后面出问题时对比基线，就能快速判断是硬件资源耗尽还是配置变更引入的。这个习惯帮我省了很多排查时间，希望帮到你。

本文还有配套的精品资源，点击获取