1. 为什么我要把交换芯片从头捋一遍真正让我下决心系统学一遍交换芯片的不是某本教材而是一次很普通的现网排查。当时机房里有几台服务器跑批量任务网络时不时抽一下抓包看延迟不高可业务侧就是感觉慢半拍。链路利用率看着只有六成端口没跑满队列也没溢出的明显迹象。折腾了半天最后定位到的是转发芯片在突发流量下的内部缓存分配策略——瞬时微突发把共享缓存吃掉了出口端口排队时间被拉长。那次之后我意识到光会敲交换机命令和真正理解交换机芯片中间还差着一整个底层世界。数据中心交换机芯片简单说就是一台交换机里负责看包头、查表、决定往哪送、排队送出去的核心器件。它是一颗专用的转发ASIC管的是二层的MAC转发、三层的路由、ACL过滤、隧道封装解封装、流量统计、QoS调度这些活儿。我们平时在CLI里敲的那些配置本质上都是在往这颗芯片的表项里写数据或者修改它查表时的匹配优先级。理解它能解决三类很实际的问题一是容量规划知道这台机器到底能存多少条路由、多少条ACL二是性能调优明白瓶颈在带宽、缓存还是调度三是故障定位能判断问题是硬件表项满了、HASH冲突了还是微突发把队列打爆了。这篇总结适合谁看如果你是刚接触数据中心网络、会配华为或H3C三层交换机但没往下钻过的运维它能帮你建立从配置到芯片的映射关系如果你是做硬件或者嵌入式、平时摸STM32、RK3588这类芯片想横向了解网络芯片的设计思路也能当个参考如果你正在做交换机的选型或者测试中间那几张参数对照表和排查清单可以直接拿去用。我会尽量把术语讲成人话用生活里的例子类比同时把关键参数和计算过程摆出来让你看完能自己动手验证而不是只记住几个名词。整个学习路径我是这么设计的先建立整体架构图——数据从端口进来到底走了哪几站再拆核心模块重点吃透表项系统、缓存和调度这三块然后是参数怎么看配一份能直接用的对照表接着是实操怎么搭一个最小环境把学到的验证一遍最后是踩坑记录和排查清单。这个顺序符合从知道它是什么到会用它、能修它的认知规律也方便你按需跳读。下面就从架构开始。2. 交换芯片的整体架构拆解2.1 数据从端口进来到底走了哪几站一颗典型的交换芯片内部可以粗分成几个大块端口侧的SerDes和MAC层、入口处理流水线Ingress Pipeline、交换/缓存/调度单元Fabric与Buffer、出口处理流水线Egress Pipeline以及外围的CPU接口和管理通道。数据包从物理端口进来第一步是SerDes把串行的高速信号还原成并行数据这一层决定了单端口能跑多快——10G、25G、100G甚至400G本质是SerDes的速率和编码方式不同。接着MAC层做帧的定界、CRC校验把坏帧直接扔掉这一步在很多人眼里是透明的但它其实是丢包统计里很多计数的来源。然后包进入Ingress流水线这是交换芯片最核心的部分。它要做的事按顺序大致是解析Parse、查表Lookup、决策Resolve。解析阶段把包头按协议逐层拆开提取出源MAC、目的MAC、VLAN、IP地址、TCP/UDP端口、甚至隧道字段形成一个内部的关键字Key。查表阶段用这个Key去查各种表比如MAC表、路由表、ACL表、隧道表。这一块的关键在于芯片是硬件并行查表用的是TCAM或者HASH结构能在一个时钟周期或者有限几个周期内出结果这就是它能跑到线速的原因。决策完之后包会被打上一个内部标签通常叫元数据或头部信息标明它的出端口、优先级、是否要做特殊处理然后送到缓存和调度单元排队。出口流水线再从缓存取包做必要的改写比如改MAC、减TTL、压入VLAN或隧道头最后从对应端口的MAC和SerDes发出去。整条路径里每一个环节都有自己的资源限制解析器能识别的协议深度有限表项容量有限缓存有限调度器的队列数有限。学交换芯片本质就是搞清楚这些有限分别在什么位置、什么量级、触发时会有什么现象。我习惯把这条路径画成一张过关图记在脑子里SerDes关、MAC关、解析关、查表关、缓存关、调度关、出口改写关。任何一关的资源出现瓶颈都会在转发行为上留下痕迹。比如解析关过不去常见于封装层次太深、芯片识别不了查表关过不去表现为表项溢出、老流被踢掉缓存关和调度关过不去才是大多数网络偶发卡顿的真正原因。2.2 表项系统是理解配置的钥匙你在交换机上敲的每一条配置几乎都能对应到某一类表项。二层转发对应FDBMAC地址表三层路由对应FIB转发表和邻接表ACL对应TCAM里的规则表VLAN对应VLAN表多播对应多播组表隧道对应各种tunnel表。这些表的容量、结构和查找方式截然不同理解它们的差别能解释很多为什么配置是这样的。拿最常见的问题举例为什么三层交换机比二层交换机贵那么多一个直接原因是它要把FIB和邻接表装进芯片。FIB负责去某个网段该走哪个下一跳邻接表负责这个下一跳对应的出接口和重写后的MAC是什么。路由条目数一多FIB表项就成了瓶颈这也是一些中低端设备标称支持的路由条数远小于高端设备的根本原因。再比如为什么有些ACL配多了会提示资源不足因为ACL走的是TCAM而TCAM是一种又贵又耗电的存储容量天然有限一条规则往往要占用多个TCAM表项取决于掩码和匹配字段的宽度。HASH表和TCAM的区别值得单独说一下。HASH表用于精确匹配比如MAC地址、五元组精确流查找快、容量大、成本低但遇到HASH冲突需要处理冲突极端时会退化成链表查找影响性能。TCAM用于带掩码的模糊匹配比如ACL里的源IP属于某网段、通配符规则它能在一次查找里对所有规则并行比较出结果极快代价是容量小、功耗高。所以设计上的一般原则是能用精确匹配解决的绝不放进TCAM。这也解释了为什么很多平台会把精确五元组ACL和带掩码的ACL分开处理目的就是省TCAM。提示排查路由或MAC学了又丢的问题时先确认是表项容量满了还是老化时间设得太短。很多所谓的网络抖动其实是表项在容量边缘频繁进出的表现。2.3 缓存与调度端口一忙就丢包的真相如果说表项决定能不能转发那缓存和调度决定的是转发得顺不顺。交换芯片里的缓存是共享的所有端口抢同一块内存这带来一个问题一个出口端口拥塞会挤占其他端口可用的缓存进而影响到不相干业务的转发质量这就是常说的头阻塞或者缓存争抢。工程师能做的是通过阈值配置和调度策略来限制这种影响范围但从芯片层面看共享缓存永远是稀缺资源。调度这一块核心概念是队列和优先级。每个端口通常有多个队列一般4到8个映射到不同的优先级比如8个优先级映射到队列。调度器负责在多个队列之间决定下一个发谁的包常见算法有严格优先级SP、加权轮询WRR、加权公平队列WFQ。SP的好处是重要业务绝对优先坏处是低优先级业务可能被饿死WRR能给每个队列分配权重兼顾公平但突发下的时延没有严格保证。选哪种取决于业务对时延和抖动的容忍度。微突发是这里最容易被忽视的杀手。假设一个100G端口理论上1微秒能传12.5KB的数据但一个TCP突发可能瞬间来200KB如果出口只有10G那就需要20微秒才能消化完这20微秒里后来的包就得排队甚至被丢。链路平均利用率再低瞬时也能把队列打满。理解了这个你就明白为什么有些网络平均负载很低却偶发丢包——问题不在平均值在瞬时值。解决方向要么是加大出口带宽、要么是配置合理的缓存阈值和流控、要么在端侧做流量整形让突发变平滑。3. 核心参数怎么看一份选型对照表3.1 交换容量、包转发率与端口形态挑交换机时最常被问到的两个参数是交换容量Switching Capacity和包转发率Packet Forwarding Rate。交换容量通常用Gbps或Tbps表示是芯片所有端口收发的总带宽理论值注意很多厂家标的是双向之和也有标单向的比较时一定要看口径。包转发率用Mpps百万包每秒表示指的是芯片能处理的最小包64字节的转发速率这个参数比带宽更能反映芯片的真实处理能力因为小包对查表和调度的压力最大。这两者之间有个换算关系可以记一下一个64字节的最小以太网帧加上前导码、帧间隔这些开销实际上占用线缆上的时间是84字节加上7字节前导1字节SFD12字节IFG共84字节。所以1Gbps线速对应的包转发率约为 1,000,000,000 / (84 × 8) ≈ 1.488 Mpps。这个1.488这个数字很重要它意味着一个千兆口满线速转发小包时需要约1.488Mpps的处理能力。一台24口千兆交换机要达到全线速芯片的包转发率就得接近 24 × 1.488 ≈ 35.7Mpps。很多标称千兆的设备实际达不到线性转发原因就在这里。端口形态上数据中心现在主流是25G、100G、400G。25G的出现主要是因为单通道SerDes跑到25G时性价比最高100G就是4个25G通道捆绑400G是8个50G或4个100G通道。理解这个通道结构有助于判断为什么有的100G端口能拆成4个25G用拆通道有的不能为什么某些光电模块必须配对使用。下面这张表是我整理的一个简化对照方便快速估算。端口速率单通道速率典型通道数线速包转发率约常见应用场景1G1.25G11.488 Mpps管理口、带外管理10G10.3125G114.88 Mpps服务器接入、存储25G25.78G137.2 Mpps服务器接入主流100G25.78G4148.8 Mpps骨干、汇聚、存储400G53.125G8595.2 Mpps核心骨干、AI集群3.2 表项规模与缓存深度怎么估表项规模这一块选型时最该关注的三个数字是MAC表容量、路由表容量FIB、ACL表项数。MAC表容量决定了这台设备能挂多少终端一个接入层设备如果MAC表只有8K接几千台虚拟机立刻就会出问题。路由表容量决定了它在三层网络里能扛多大体量的路由做核心或者边界设备时表项必须留够余量因为路由一旦超限要么老的被踢要么新的学不进来都会引发流量中断。缓存深度常被忽略但对数据中心尤其关键因为它直接关系到微突发的吸收能力。缓存通常用MB或者按每个端口多少KB来标需要注意是共享缓存还是每端口独享缓存。共享缓存灵活但会互相影响独享缓存隔离性好但利用率低。经验值是接入层对缓存要求不高汇聚和核心层如果承担存储、AI训练这类流量缓存给足能明显减少丢包。参数典型区间接入典型区间汇聚/核心关注点MAC表8K ~ 32K64K ~ 256K挂载终端/虚拟机数量FIB表4K ~ 16K64K ~ 1M路由收敛后的条目总量ACL表项1K ~ 4K8K ~ 32K安全策略复杂度共享缓存4MB ~ 16MB32MB ~ 128MB微突发吸收能力队列数/端口4 ~ 88 ~ 16QoS策略精细度3.3 时延、功耗与可编程性时延Latency在数据中心里越来越重要尤其是AI训练和分布式存储这类对往返时间敏感的业务。交换芯片的时延一般分直通Cut-through和存储转发Store-and-forward两种模式。直通模式收到包头就转发时延可以低到几百纳秒但对坏帧没有过滤能力存储转发要收完整个帧才发时延高一些但能过滤坏帧。现在很多芯片支持智能直通小帧直通、大帧存储转发兼顾了两者。选型时看到的时延1微秒之类的指标通常是在特定包长和模式下测的别直接拿来横向比。功耗是数据中心越来越绕不开的话题尤其在大规模部署下。交换芯片的功耗和它的SerDes速率、TCAM规模、缓存大小直接相关400G芯片单颗功耗动辄几百瓦散热和供电成了机柜设计的一部分。近两年液冷技术进入数据中心很多方案就是对高功耗交换芯片和服务器芯片的散热回应。这也解释了为什么液冷和交换芯片这两个话题经常一起出现。可编程性方面传统交换芯片是固定功能Fixed-function的流水线写死新协议出来只能等厂商出新芯片。近几年可编程流水线常见说法是P4可编程逐渐普及允许通过描述语言定义解析和处理的逻辑灵活性大大提升代价是资源和性能的权衡以及开发门槛变高。选型时要问清楚这块芯片是固定功能还是可编程如果可编程支持的上限在哪里很多场景下固定功能芯片性价比更高不要盲目追求可编程。4. 可编程能力与生态芯片之外的另一半4.1 固定功能与可编程流水线怎么选固定功能芯片的优势是成熟、稳定、单位成本低软件生态也完整厂商的SDK和文档都比较靠谱。它的短板是遇到新协议、新封装、私有标签时要么靠现有字段拼凑要么直接不支持。可编程芯片把流水线的部分可配置化理论上你能自己定义怎么解析、怎么匹配、怎么改写。听起来很美但实际落地时有几个现实问题可编程流水线的资源比如阶段数、表项大小是有上限的写复杂逻辑时容易撞墙开发人员需要同时懂网络协议和芯片架构人才稀缺调试工具和生态不如固定功能成熟出问题排查成本高。我的建议是分场景看。标准数据中心网络跑的是VXLAN、EVPN这些成熟协议固定功能芯片完全够用没必要上可编程。如果你所在的环境有大量私有协议、需要做网络遥测INT带内遥测、或者需要快速试验新转发逻辑可编程才值得投入。判断标准很简单你想实现的转发行为现有芯片的SDK能不能通过配置搞定能就用固定功能不能再考虑可编程。4.2 SDK、驱动与管理通道交换芯片本身不会自己工作它需要一套软件把它驱动起来。这套软件通常分几层最底层是芯片的固件和初始化代码中间的SDK提供操作表项和寄存器的API上层是协议栈和CLI/网管系统。你敲的每一条命令最终都要翻译成对芯片寄存器和表项的读写。理解这个调用链能帮你在出问题时判断是配置没生效还是配置生效了但芯片没执行。举一个具体的场景在交换机上配一条静态路由命令敲下去返回成功但流量就是不通。排查思路是分层确认——先看路由表里有没有这条条目软件层再看FIB里有没有芯片转发表再看邻接表里下一跳的MAC解析出来没有。很多时候问题出在邻接表下一跳的ARP还没学到或者学到的MAC和实际不符芯片就没法完成重写。这类问题用三层对照法能很快定位比盲目抓包高效得多。管理通道方面交换芯片通常有一个CPU接口把上送CPU的包比如ARP、协议报文、需要软件处理的异常包送到主控CPU。这个通道的带宽和限速处理很关键。如果上送CPU的流量被限速太低协议报文会丢导致邻居震荡如果限得高又可能被异常流量打满CPU。数据中心里常见的CPU使用率飙升很多就是上送通道被泛洪流量冲击。合理配置CoPPControl Plane Policing控制平面限速是必备操作。注意别把配置成功等同于芯片生效。配置是写数据库芯片生效是写硬件表项中间隔着驱动和SDK。排查疑难问题时一定要确认最终硬件表项的状态。5. 实操搭一个最小环境把学到的东西验证一遍5.1 环境准备与拓扑设计光看文档学不会交换芯片必须有能动手的环境。最低配的方案是两台支持三层转发的交换机加上两台测试主机。拓扑设计成这样主机A接交换机1主机B接交换机2两台交换机之间用一条链路互联分别在交换机上配不同网段让流量经过三层转发。这个拓扑虽小但足以覆盖二层转发、三层路由、ACL、QoS这四类核心功能的验证。如果预算有限也可以用一台支持多VLAN的三层交换机和两台主机把主机放在不同VLAN里交换机的VLAN接口做网关这样也能模拟三层转发。再进一步如果想观察芯片表项最好选一台能dump表项的交换机很多企业级设备支持通过命令查看FIB、FDB、ACL的实际占用情况。我测试时用的是华为和华三的设备命令略有差异但思路一致下面给的示例以通用形式为主。准备工作还包括抓包工具在主机的镜像口或交换机的端口镜像上抓打流工具可以用专业的打流仪也可以用Linux上的工具构造流量以及一份记录本——芯片相关的问题往往需要对照时间点记录每次改动和现象非常有帮助。5.2 关键配置与流量验证先配基础转发。以两台三层交换机互联为例假设交换机1用VLAN 10网关地址为192.168.10.1/24交换机2用VLAN 20网关地址为192.168.20.1/24互联接口用VLAN 100地址为10.0.0.1/30和10.0.0.2/30。配置大致如下不同厂商命令有差异这里用示意风格# 交换机1 vlan 10 vlan 100 interface vlan 10 ip address 192.168.10.1 255.255.255.0 interface vlan 100 ip address 10.0.0.1 255.255.255.252 ip route-static 192.168.20.0 255.255.255.0 10.0.0.2 # 交换机2 vlan 20 vlan 100 interface vlan 20 ip address 192.168.20.1 255.255.255.0 interface vlan 100 ip address 10.0.0.2 255.255.255.252 ip route-static 192.168.10.0 255.255.255.0 10.0.0.1配完后主机A192.168.10.100ping主机B192.168.20.100应该能通。这时去看交换机1的FIB表应该能看到去192.168.20.0/24的条目下一跳是10.0.0.2看邻接表应该能看到10.0.0.2对应的MAC。如果这里看不到邻接八成是互联链路的ARP没通先查物理链路和VLAN配置。接下来验证ACL。配一条规则禁止主机A访问主机B的某个端口比如禁止访问192.168.20.100的22端口。ACL匹配字段是五元组注意它占用的是TCAM资源。配置后观察表项命令看TCAM占用数有没有增加同时用主机A去连B的22端口应该被拒绝。这一步的意义是让你亲眼看到配置一条规则等于占用一条硬件表项建立资源意识。最后做一次突发测试。用打流工具或者脚本从一个口以接近线速打小包同时观察出端口的队列统计和丢包计数。如果看到出口队列有丢弃再对照缓存配置尝试调整缓存阈值或队列权重看丢弃是否变化。这个过程能让你真实体会到调度和缓存的作用比读十遍文档都管用。5.3 关键指标怎么测才准测时延要注意方法。用ping测的是RTT包含了两端主机的处理时间和往返路径不能代表芯片的单向转发时延。想看芯片时延专业做法是用打流仪在两个端口同时打上时间戳测单向转发时间。没有专业仪表时可以用支持硬件时间戳的网卡做近似测量但要注明是端到端含主机处理的口径别混用。测吞吐也一样要区分转发率和吞吐量。转发率是包数吞吐量是比特数。测试小包64字节时转发率才是瓶颈指标测试大包1518字节时带宽才是瓶颈。很多标称参数是在大包下测的实际业务小包多的时候性能会打折。我个人的习惯是测三组64字节、512字节、1518字节分别记录转发率和丢包率这样对芯片能力的画像最完整。提示做性能测试时务必关闭主机的省电和网卡聚合相关特性否则测出来的数据会受主机侧干扰误判成芯片问题。6. 常见问题与排查实录6.1 问题速查表下面这张表是我这些年遇到的高频问题以及对应的排查方向都是从实际工作里攒下来的不是照抄手册。现象可能原因排查方向处理思路表项学了又丢表项容量满或老化过快查看FDB/FIB占用率与老化时间扩大表项或调整老化平均负载低却丢包微突发打满出口队列看队列丢包和端口突发统计加缓存阈值或端侧整形跨网段不通邻接表未解析查ARP与邻接表状态修复下一跳解析ACL不生效规则顺序或TCAM资源不足查TCAM占用与命中计数调整顺序、精简规则CPU占用高上送CPU流量被泛洪冲击查CoPP与上送流量配置限速、定位泛洪源端口时通时断光模块或SerDes问题查端口误码与光功率更换模块或跳线新协议不支持固定功能芯片无此能力查芯片规格与SDK换可编程平台或升级6.2 我踩过的那些坑第一个坑是过分相信端口利用率这个指标。早期我以为利用率低就不会丢包直到遇到微突发才发现采样周期太长通常5分钟完全掩盖了毫秒级的突发。后来我改用更细粒度的采样或者直接看芯片的瞬时队列深度才把问题暴露出来。经验是跟交换芯片打交道别只看平均值要看分布和峰值。第二个坑是忽略HASH冲突。有一次现网里某条流的转发时延明显高于其他流查了半天表项都正常最后发现是HASH冲突导致查表退化成多次比较。交换芯片的HASH算法通常是固定的但你可以在选型时关注它对冲突的处理能力在组网时避免大量同源同目的的高并发流挤在一起。第三个坑是配了CoPP却没验证。CoPP限速值设得随意结果把正常的协议报文也限掉了导致邻居关系反复中断现象看着像链路故障其实是限速误伤。教训是上送CPU的限速必须基于实际协议流量测算留足余量并且配完后要观察协议邻居的稳定性。第四个坑是忽视温度。高密度交换芯片功耗大散热跟不上时会降频或者触发保护导致转发性能下降。这个问题在夏天特别容易冒头表现为平时好好的午后开始丢包。定期检查进风口温度、风扇转速、芯片温度传感器是运维手册里容易被跳过的步骤。6.3 给不同基础读者的上手建议如果你是从网络运维转过来的建议先把你手头设备的管理手册翻到硬件规格和表项容量部分对着实际业务量算一算余量再去看架构章节理解会快很多。如果你是从嵌入式或芯片方向转过来的你对SerDes、流水线、寄存器这些概念不陌生可以直接从第2章架构和第3章参数入手把网络侧的术语FIB、ACL、QoS和硬件概念对应起来学起来会很顺。如果你是完全的新手别一上来就啃芯片手册那玩意儿几百上千页全是寄存器位定义。正确路径是先搞懂二层和三层转发的基本原理会配基本的VLAN和路由然后再回头看这些配置在芯片里对应什么。我见过太多初学者一上来就钻寄存器结果耗了几个月还是不会排查实际问题。先会用再懂原理最后才是抠细节这个顺序对绝大多数人都成立。最后再说个自查方法。学完一个知识点试着不看资料回答三个问题这件事在芯片里的哪个模块完成它消耗的是哪类资源资源不够时会出现什么现象能顺畅答出来说明真的理解了答不出来就回去把对应的章节再过一遍。这个方法我用到现在比刷题管用。注意交换芯片的很多参数是条件成立的比如表项容量往往是在特定配置组合下的最大值。选型和评估时一定要看完整的前提条件别被单一数字带偏。数据中心网络这几年变化很快速率从100G往800G走封装从VXLAN往更复杂的可编程隧道走芯片的可编程能力也在往上堆。但底层的逻辑没怎么变解析、查表、缓存、调度四个词概括了大部分工作。把这一层吃透上层再多的新名词你都能快速找到它落在哪一步、消耗什么资源、可能在哪里出问题。这套思路我用了很多年到现在依然有效。 
长河君 · 2026/9/18 1:30:57 · 阅读 1.2k 数据中心交换芯片学习笔记：架构、表项、缓存调度与故障排查
1. 为什么我要把交换芯片从头捋一遍真正让我下决心系统学一遍交换芯片的不是某本教材而是一次很普通的现网排查。当时机房里有几台服务器跑批量任务网络时不时抽一下抓包看延迟不高可业务侧就是感觉慢半拍。链路利用率看着只有六成端口没跑满队列也没溢出的明显迹象。折腾了半天最后定位到的是转发芯片在突发流量下的内部缓存分配策略——瞬时微突发把共享缓存吃掉了出口端口排队时间被拉长。那次之后我意识到光会敲交换机命令和真正理解交换机芯片中间还差着一整个底层世界。数据中心交换机芯片简单说就是一台交换机里负责看包头、查表、决定往哪送、排队送出去的核心器件。它是一颗专用的转发ASIC管的是二层的MAC转发、三层的路由、ACL过滤、隧道封装解封装、流量统计、QoS调度这些活儿。我们平时在CLI里敲的那些配置本质上都是在往这颗芯片的表项里写数据或者修改它查表时的匹配优先级。理解它能解决三类很实际的问题一是容量规划知道这台机器到底能存多少条路由、多少条ACL二是性能调优明白瓶颈在带宽、缓存还是调度三是故障定位能判断问题是硬件表项满了、HASH冲突了还是微突发把队列打爆了。这篇总结适合谁看如果你是刚接触数据中心网络、会配华为或H3C三层交换机但没往下钻过的运维它能帮你建立从配置到芯片的映射关系如果你是做硬件或者嵌入式、平时摸STM32、RK3588这类芯片想横向了解网络芯片的设计思路也能当个参考如果你正在做交换机的选型或者测试中间那几张参数对照表和排查清单可以直接拿去用。我会尽量把术语讲成人话用生活里的例子类比同时把关键参数和计算过程摆出来让你看完能自己动手验证而不是只记住几个名词。整个学习路径我是这么设计的先建立整体架构图——数据从端口进来到底走了哪几站再拆核心模块重点吃透表项系统、缓存和调度这三块然后是参数怎么看配一份能直接用的对照表接着是实操怎么搭一个最小环境把学到的验证一遍最后是踩坑记录和排查清单。这个顺序符合从知道它是什么到会用它、能修它的认知规律也方便你按需跳读。下面就从架构开始。2. 交换芯片的整体架构拆解2.1 数据从端口进来到底走了哪几站一颗典型的交换芯片内部可以粗分成几个大块端口侧的SerDes和MAC层、入口处理流水线Ingress Pipeline、交换/缓存/调度单元Fabric与Buffer、出口处理流水线Egress Pipeline以及外围的CPU接口和管理通道。数据包从物理端口进来第一步是SerDes把串行的高速信号还原成并行数据这一层决定了单端口能跑多快——10G、25G、100G甚至400G本质是SerDes的速率和编码方式不同。接着MAC层做帧的定界、CRC校验把坏帧直接扔掉这一步在很多人眼里是透明的但它其实是丢包统计里很多计数的来源。然后包进入Ingress流水线这是交换芯片最核心的部分。它要做的事按顺序大致是解析Parse、查表Lookup、决策Resolve。解析阶段把包头按协议逐层拆开提取出源MAC、目的MAC、VLAN、IP地址、TCP/UDP端口、甚至隧道字段形成一个内部的关键字Key。查表阶段用这个Key去查各种表比如MAC表、路由表、ACL表、隧道表。这一块的关键在于芯片是硬件并行查表用的是TCAM或者HASH结构能在一个时钟周期或者有限几个周期内出结果这就是它能跑到线速的原因。决策完之后包会被打上一个内部标签通常叫元数据或头部信息标明它的出端口、优先级、是否要做特殊处理然后送到缓存和调度单元排队。出口流水线再从缓存取包做必要的改写比如改MAC、减TTL、压入VLAN或隧道头最后从对应端口的MAC和SerDes发出去。整条路径里每一个环节都有自己的资源限制解析器能识别的协议深度有限表项容量有限缓存有限调度器的队列数有限。学交换芯片本质就是搞清楚这些有限分别在什么位置、什么量级、触发时会有什么现象。我习惯把这条路径画成一张过关图记在脑子里SerDes关、MAC关、解析关、查表关、缓存关、调度关、出口改写关。任何一关的资源出现瓶颈都会在转发行为上留下痕迹。比如解析关过不去常见于封装层次太深、芯片识别不了查表关过不去表现为表项溢出、老流被踢掉缓存关和调度关过不去才是大多数网络偶发卡顿的真正原因。2.2 表项系统是理解配置的钥匙你在交换机上敲的每一条配置几乎都能对应到某一类表项。二层转发对应FDBMAC地址表三层路由对应FIB转发表和邻接表ACL对应TCAM里的规则表VLAN对应VLAN表多播对应多播组表隧道对应各种tunnel表。这些表的容量、结构和查找方式截然不同理解它们的差别能解释很多为什么配置是这样的。拿最常见的问题举例为什么三层交换机比二层交换机贵那么多一个直接原因是它要把FIB和邻接表装进芯片。FIB负责去某个网段该走哪个下一跳邻接表负责这个下一跳对应的出接口和重写后的MAC是什么。路由条目数一多FIB表项就成了瓶颈这也是一些中低端设备标称支持的路由条数远小于高端设备的根本原因。再比如为什么有些ACL配多了会提示资源不足因为ACL走的是TCAM而TCAM是一种又贵又耗电的存储容量天然有限一条规则往往要占用多个TCAM表项取决于掩码和匹配字段的宽度。HASH表和TCAM的区别值得单独说一下。HASH表用于精确匹配比如MAC地址、五元组精确流查找快、容量大、成本低但遇到HASH冲突需要处理冲突极端时会退化成链表查找影响性能。TCAM用于带掩码的模糊匹配比如ACL里的源IP属于某网段、通配符规则它能在一次查找里对所有规则并行比较出结果极快代价是容量小、功耗高。所以设计上的一般原则是能用精确匹配解决的绝不放进TCAM。这也解释了为什么很多平台会把精确五元组ACL和带掩码的ACL分开处理目的就是省TCAM。提示排查路由或MAC学了又丢的问题时先确认是表项容量满了还是老化时间设得太短。很多所谓的网络抖动其实是表项在容量边缘频繁进出的表现。2.3 缓存与调度端口一忙就丢包的真相如果说表项决定能不能转发那缓存和调度决定的是转发得顺不顺。交换芯片里的缓存是共享的所有端口抢同一块内存这带来一个问题一个出口端口拥塞会挤占其他端口可用的缓存进而影响到不相干业务的转发质量这就是常说的头阻塞或者缓存争抢。工程师能做的是通过阈值配置和调度策略来限制这种影响范围但从芯片层面看共享缓存永远是稀缺资源。调度这一块核心概念是队列和优先级。每个端口通常有多个队列一般4到8个映射到不同的优先级比如8个优先级映射到队列。调度器负责在多个队列之间决定下一个发谁的包常见算法有严格优先级SP、加权轮询WRR、加权公平队列WFQ。SP的好处是重要业务绝对优先坏处是低优先级业务可能被饿死WRR能给每个队列分配权重兼顾公平但突发下的时延没有严格保证。选哪种取决于业务对时延和抖动的容忍度。微突发是这里最容易被忽视的杀手。假设一个100G端口理论上1微秒能传12.5KB的数据但一个TCP突发可能瞬间来200KB如果出口只有10G那就需要20微秒才能消化完这20微秒里后来的包就得排队甚至被丢。链路平均利用率再低瞬时也能把队列打满。理解了这个你就明白为什么有些网络平均负载很低却偶发丢包——问题不在平均值在瞬时值。解决方向要么是加大出口带宽、要么是配置合理的缓存阈值和流控、要么在端侧做流量整形让突发变平滑。3. 核心参数怎么看一份选型对照表3.1 交换容量、包转发率与端口形态挑交换机时最常被问到的两个参数是交换容量Switching Capacity和包转发率Packet Forwarding Rate。交换容量通常用Gbps或Tbps表示是芯片所有端口收发的总带宽理论值注意很多厂家标的是双向之和也有标单向的比较时一定要看口径。包转发率用Mpps百万包每秒表示指的是芯片能处理的最小包64字节的转发速率这个参数比带宽更能反映芯片的真实处理能力因为小包对查表和调度的压力最大。这两者之间有个换算关系可以记一下一个64字节的最小以太网帧加上前导码、帧间隔这些开销实际上占用线缆上的时间是84字节加上7字节前导1字节SFD12字节IFG共84字节。所以1Gbps线速对应的包转发率约为 1,000,000,000 / (84 × 8) ≈ 1.488 Mpps。这个1.488这个数字很重要它意味着一个千兆口满线速转发小包时需要约1.488Mpps的处理能力。一台24口千兆交换机要达到全线速芯片的包转发率就得接近 24 × 1.488 ≈ 35.7Mpps。很多标称千兆的设备实际达不到线性转发原因就在这里。端口形态上数据中心现在主流是25G、100G、400G。25G的出现主要是因为单通道SerDes跑到25G时性价比最高100G就是4个25G通道捆绑400G是8个50G或4个100G通道。理解这个通道结构有助于判断为什么有的100G端口能拆成4个25G用拆通道有的不能为什么某些光电模块必须配对使用。下面这张表是我整理的一个简化对照方便快速估算。端口速率单通道速率典型通道数线速包转发率约常见应用场景1G1.25G11.488 Mpps管理口、带外管理10G10.3125G114.88 Mpps服务器接入、存储25G25.78G137.2 Mpps服务器接入主流100G25.78G4148.8 Mpps骨干、汇聚、存储400G53.125G8595.2 Mpps核心骨干、AI集群3.2 表项规模与缓存深度怎么估表项规模这一块选型时最该关注的三个数字是MAC表容量、路由表容量FIB、ACL表项数。MAC表容量决定了这台设备能挂多少终端一个接入层设备如果MAC表只有8K接几千台虚拟机立刻就会出问题。路由表容量决定了它在三层网络里能扛多大体量的路由做核心或者边界设备时表项必须留够余量因为路由一旦超限要么老的被踢要么新的学不进来都会引发流量中断。缓存深度常被忽略但对数据中心尤其关键因为它直接关系到微突发的吸收能力。缓存通常用MB或者按每个端口多少KB来标需要注意是共享缓存还是每端口独享缓存。共享缓存灵活但会互相影响独享缓存隔离性好但利用率低。经验值是接入层对缓存要求不高汇聚和核心层如果承担存储、AI训练这类流量缓存给足能明显减少丢包。参数典型区间接入典型区间汇聚/核心关注点MAC表8K ~ 32K64K ~ 256K挂载终端/虚拟机数量FIB表4K ~ 16K64K ~ 1M路由收敛后的条目总量ACL表项1K ~ 4K8K ~ 32K安全策略复杂度共享缓存4MB ~ 16MB32MB ~ 128MB微突发吸收能力队列数/端口4 ~ 88 ~ 16QoS策略精细度3.3 时延、功耗与可编程性时延Latency在数据中心里越来越重要尤其是AI训练和分布式存储这类对往返时间敏感的业务。交换芯片的时延一般分直通Cut-through和存储转发Store-and-forward两种模式。直通模式收到包头就转发时延可以低到几百纳秒但对坏帧没有过滤能力存储转发要收完整个帧才发时延高一些但能过滤坏帧。现在很多芯片支持智能直通小帧直通、大帧存储转发兼顾了两者。选型时看到的时延1微秒之类的指标通常是在特定包长和模式下测的别直接拿来横向比。功耗是数据中心越来越绕不开的话题尤其在大规模部署下。交换芯片的功耗和它的SerDes速率、TCAM规模、缓存大小直接相关400G芯片单颗功耗动辄几百瓦散热和供电成了机柜设计的一部分。近两年液冷技术进入数据中心很多方案就是对高功耗交换芯片和服务器芯片的散热回应。这也解释了为什么液冷和交换芯片这两个话题经常一起出现。可编程性方面传统交换芯片是固定功能Fixed-function的流水线写死新协议出来只能等厂商出新芯片。近几年可编程流水线常见说法是P4可编程逐渐普及允许通过描述语言定义解析和处理的逻辑灵活性大大提升代价是资源和性能的权衡以及开发门槛变高。选型时要问清楚这块芯片是固定功能还是可编程如果可编程支持的上限在哪里很多场景下固定功能芯片性价比更高不要盲目追求可编程。4. 可编程能力与生态芯片之外的另一半4.1 固定功能与可编程流水线怎么选固定功能芯片的优势是成熟、稳定、单位成本低软件生态也完整厂商的SDK和文档都比较靠谱。它的短板是遇到新协议、新封装、私有标签时要么靠现有字段拼凑要么直接不支持。可编程芯片把流水线的部分可配置化理论上你能自己定义怎么解析、怎么匹配、怎么改写。听起来很美但实际落地时有几个现实问题可编程流水线的资源比如阶段数、表项大小是有上限的写复杂逻辑时容易撞墙开发人员需要同时懂网络协议和芯片架构人才稀缺调试工具和生态不如固定功能成熟出问题排查成本高。我的建议是分场景看。标准数据中心网络跑的是VXLAN、EVPN这些成熟协议固定功能芯片完全够用没必要上可编程。如果你所在的环境有大量私有协议、需要做网络遥测INT带内遥测、或者需要快速试验新转发逻辑可编程才值得投入。判断标准很简单你想实现的转发行为现有芯片的SDK能不能通过配置搞定能就用固定功能不能再考虑可编程。4.2 SDK、驱动与管理通道交换芯片本身不会自己工作它需要一套软件把它驱动起来。这套软件通常分几层最底层是芯片的固件和初始化代码中间的SDK提供操作表项和寄存器的API上层是协议栈和CLI/网管系统。你敲的每一条命令最终都要翻译成对芯片寄存器和表项的读写。理解这个调用链能帮你在出问题时判断是配置没生效还是配置生效了但芯片没执行。举一个具体的场景在交换机上配一条静态路由命令敲下去返回成功但流量就是不通。排查思路是分层确认——先看路由表里有没有这条条目软件层再看FIB里有没有芯片转发表再看邻接表里下一跳的MAC解析出来没有。很多时候问题出在邻接表下一跳的ARP还没学到或者学到的MAC和实际不符芯片就没法完成重写。这类问题用三层对照法能很快定位比盲目抓包高效得多。管理通道方面交换芯片通常有一个CPU接口把上送CPU的包比如ARP、协议报文、需要软件处理的异常包送到主控CPU。这个通道的带宽和限速处理很关键。如果上送CPU的流量被限速太低协议报文会丢导致邻居震荡如果限得高又可能被异常流量打满CPU。数据中心里常见的CPU使用率飙升很多就是上送通道被泛洪流量冲击。合理配置CoPPControl Plane Policing控制平面限速是必备操作。注意别把配置成功等同于芯片生效。配置是写数据库芯片生效是写硬件表项中间隔着驱动和SDK。排查疑难问题时一定要确认最终硬件表项的状态。5. 实操搭一个最小环境把学到的东西验证一遍5.1 环境准备与拓扑设计光看文档学不会交换芯片必须有能动手的环境。最低配的方案是两台支持三层转发的交换机加上两台测试主机。拓扑设计成这样主机A接交换机1主机B接交换机2两台交换机之间用一条链路互联分别在交换机上配不同网段让流量经过三层转发。这个拓扑虽小但足以覆盖二层转发、三层路由、ACL、QoS这四类核心功能的验证。如果预算有限也可以用一台支持多VLAN的三层交换机和两台主机把主机放在不同VLAN里交换机的VLAN接口做网关这样也能模拟三层转发。再进一步如果想观察芯片表项最好选一台能dump表项的交换机很多企业级设备支持通过命令查看FIB、FDB、ACL的实际占用情况。我测试时用的是华为和华三的设备命令略有差异但思路一致下面给的示例以通用形式为主。准备工作还包括抓包工具在主机的镜像口或交换机的端口镜像上抓打流工具可以用专业的打流仪也可以用Linux上的工具构造流量以及一份记录本——芯片相关的问题往往需要对照时间点记录每次改动和现象非常有帮助。5.2 关键配置与流量验证先配基础转发。以两台三层交换机互联为例假设交换机1用VLAN 10网关地址为192.168.10.1/24交换机2用VLAN 20网关地址为192.168.20.1/24互联接口用VLAN 100地址为10.0.0.1/30和10.0.0.2/30。配置大致如下不同厂商命令有差异这里用示意风格# 交换机1 vlan 10 vlan 100 interface vlan 10 ip address 192.168.10.1 255.255.255.0 interface vlan 100 ip address 10.0.0.1 255.255.255.252 ip route-static 192.168.20.0 255.255.255.0 10.0.0.2 # 交换机2 vlan 20 vlan 100 interface vlan 20 ip address 192.168.20.1 255.255.255.0 interface vlan 100 ip address 10.0.0.2 255.255.255.252 ip route-static 192.168.10.0 255.255.255.0 10.0.0.1配完后主机A192.168.10.100ping主机B192.168.20.100应该能通。这时去看交换机1的FIB表应该能看到去192.168.20.0/24的条目下一跳是10.0.0.2看邻接表应该能看到10.0.0.2对应的MAC。如果这里看不到邻接八成是互联链路的ARP没通先查物理链路和VLAN配置。接下来验证ACL。配一条规则禁止主机A访问主机B的某个端口比如禁止访问192.168.20.100的22端口。ACL匹配字段是五元组注意它占用的是TCAM资源。配置后观察表项命令看TCAM占用数有没有增加同时用主机A去连B的22端口应该被拒绝。这一步的意义是让你亲眼看到配置一条规则等于占用一条硬件表项建立资源意识。最后做一次突发测试。用打流工具或者脚本从一个口以接近线速打小包同时观察出端口的队列统计和丢包计数。如果看到出口队列有丢弃再对照缓存配置尝试调整缓存阈值或队列权重看丢弃是否变化。这个过程能让你真实体会到调度和缓存的作用比读十遍文档都管用。5.3 关键指标怎么测才准测时延要注意方法。用ping测的是RTT包含了两端主机的处理时间和往返路径不能代表芯片的单向转发时延。想看芯片时延专业做法是用打流仪在两个端口同时打上时间戳测单向转发时间。没有专业仪表时可以用支持硬件时间戳的网卡做近似测量但要注明是端到端含主机处理的口径别混用。测吞吐也一样要区分转发率和吞吐量。转发率是包数吞吐量是比特数。测试小包64字节时转发率才是瓶颈指标测试大包1518字节时带宽才是瓶颈。很多标称参数是在大包下测的实际业务小包多的时候性能会打折。我个人的习惯是测三组64字节、512字节、1518字节分别记录转发率和丢包率这样对芯片能力的画像最完整。提示做性能测试时务必关闭主机的省电和网卡聚合相关特性否则测出来的数据会受主机侧干扰误判成芯片问题。6. 常见问题与排查实录6.1 问题速查表下面这张表是我这些年遇到的高频问题以及对应的排查方向都是从实际工作里攒下来的不是照抄手册。现象可能原因排查方向处理思路表项学了又丢表项容量满或老化过快查看FDB/FIB占用率与老化时间扩大表项或调整老化平均负载低却丢包微突发打满出口队列看队列丢包和端口突发统计加缓存阈值或端侧整形跨网段不通邻接表未解析查ARP与邻接表状态修复下一跳解析ACL不生效规则顺序或TCAM资源不足查TCAM占用与命中计数调整顺序、精简规则CPU占用高上送CPU流量被泛洪冲击查CoPP与上送流量配置限速、定位泛洪源端口时通时断光模块或SerDes问题查端口误码与光功率更换模块或跳线新协议不支持固定功能芯片无此能力查芯片规格与SDK换可编程平台或升级6.2 我踩过的那些坑第一个坑是过分相信端口利用率这个指标。早期我以为利用率低就不会丢包直到遇到微突发才发现采样周期太长通常5分钟完全掩盖了毫秒级的突发。后来我改用更细粒度的采样或者直接看芯片的瞬时队列深度才把问题暴露出来。经验是跟交换芯片打交道别只看平均值要看分布和峰值。第二个坑是忽略HASH冲突。有一次现网里某条流的转发时延明显高于其他流查了半天表项都正常最后发现是HASH冲突导致查表退化成多次比较。交换芯片的HASH算法通常是固定的但你可以在选型时关注它对冲突的处理能力在组网时避免大量同源同目的的高并发流挤在一起。第三个坑是配了CoPP却没验证。CoPP限速值设得随意结果把正常的协议报文也限掉了导致邻居关系反复中断现象看着像链路故障其实是限速误伤。教训是上送CPU的限速必须基于实际协议流量测算留足余量并且配完后要观察协议邻居的稳定性。第四个坑是忽视温度。高密度交换芯片功耗大散热跟不上时会降频或者触发保护导致转发性能下降。这个问题在夏天特别容易冒头表现为平时好好的午后开始丢包。定期检查进风口温度、风扇转速、芯片温度传感器是运维手册里容易被跳过的步骤。6.3 给不同基础读者的上手建议如果你是从网络运维转过来的建议先把你手头设备的管理手册翻到硬件规格和表项容量部分对着实际业务量算一算余量再去看架构章节理解会快很多。如果你是从嵌入式或芯片方向转过来的你对SerDes、流水线、寄存器这些概念不陌生可以直接从第2章架构和第3章参数入手把网络侧的术语FIB、ACL、QoS和硬件概念对应起来学起来会很顺。如果你是完全的新手别一上来就啃芯片手册那玩意儿几百上千页全是寄存器位定义。正确路径是先搞懂二层和三层转发的基本原理会配基本的VLAN和路由然后再回头看这些配置在芯片里对应什么。我见过太多初学者一上来就钻寄存器结果耗了几个月还是不会排查实际问题。先会用再懂原理最后才是抠细节这个顺序对绝大多数人都成立。最后再说个自查方法。学完一个知识点试着不看资料回答三个问题这件事在芯片里的哪个模块完成它消耗的是哪类资源资源不够时会出现什么现象能顺畅答出来说明真的理解了答不出来就回去把对应的章节再过一遍。这个方法我用到现在比刷题管用。注意交换芯片的很多参数是条件成立的比如表项容量往往是在特定配置组合下的最大值。选型和评估时一定要看完整的前提条件别被单一数字带偏。数据中心网络这几年变化很快速率从100G往800G走封装从VXLAN往更复杂的可编程隧道走芯片的可编程能力也在往上堆。但底层的逻辑没怎么变解析、查表、缓存、调度四个词概括了大部分工作。把这一层吃透上层再多的新名词你都能快速找到它落在哪一步、消耗什么资源、可能在哪里出问题。这套思路我用了很多年到现在依然有效。