那几年在运营商侧做核心路由器维护最怕半夜接到一个电话“某条业务流不通了但路由表看着是齐的。”这种问题十有八九不是协议没收敛而是硬件转发表出了状况。等你登上设备一查才发现TCAM利用率已经顶到99%新学到的路由根本下不进去或者更隐蔽一点表项下进去了但因为掩码规则冲突实际命中的是另一条旧路由。从那时起我就意识到搞路由协议只是入门真正决定一台设备能不能稳定转发十万条路由的是TCAM里那点“方寸之地”怎么规划、怎么写、怎么释放。这篇东西不打算讲太虚的架构图就围绕“基于TCAM的路由查找及表项管理”这个主题把硬件查找原理、表项怎么组织、更新时怎么保证一致、现网踩过的坑以及我自己总结的一套容量管理方法一次说清楚。适合正在做数通设备研发、测试或者日常维护核心网络设备的朋友参考。1. 为什么路由查找离不开TCAM1.1 三态存储和普通存储器的本质区别先说说TCAM到底是什么。普通的RAM每个bit只能存0或者1你给它一个地址它返回那个地址里的数据。TCAM不一样它每个bit有三种状态0、1还有X这个X就是“dont care”也就是通配。你可以把某一位设成X那么在查找的时候这一位无论输入是0还是1都算匹配。这种能力看起来只是多了一个状态实际上彻底改变了查找方式。普通RAM是你告诉它“东西放在几号柜子”它去柜子里拿给你TCAM是你告诉它“我要找一件红色、圆领、纯棉的T恤”它自己在一堆衣服里同时翻一遍把所有符合条件的都挑出来。而且这个“同时翻一遍”不是比喻是真的在一个时钟周期里把所有表项全部比对完。这意味着无论表里有100条还是10万条规则单次查找的耗时基本不变这种并行比对能力正是路由查找最需要的。路由查找的核心语义是“最长前缀匹配”也就是一个IP地址可能同时匹配好几条路由必须挑出前缀最长的那条。这种“多个命中取最优”的查找用普通RAM实现很别扭但用TCAM天然合适——因为X位可以表示前缀里的通配部分。1.2 一次并行比对TCAM和哈希方案的差距有人会问现在软件转发用哈希表、用基数树不是也挺快吗为什么还要花大价钱上TCAM这里面有个“每包查找”的时间预算问题。在40G甚至100G端口上一个64字节小包的时间预算只有几纳秒到十几纳秒。软件算法再快查一次路由表也要几百纳秒甚至微秒级根本赶不上线速。哈希表适合精确匹配比如查MAC地址表、查五元组会话表但IP路由是前缀匹配哈希没法直接处理“192.168.0.0/16”和“192.168.1.0/24”这种包含关系。你可以用哈希做最长前缀匹配的辅助索引但最坏情况还是得回溯多条前缀时延抖动无法保证。TCAM的并行比对能力把查找时间从“取决于表项数量”变成了“固定常量”。一次查找所有表项同时比较硬件直接返回命中优先级最高的那条索引。这个特性让TCAM成为数通设备转发面不可替代的部件尤其是核心路由器、数据中心交换机的路由表查找基本都绕不开它。1.3 最长前缀匹配在TCAM里是怎么“排”出来的这是TCAM路由查找里最重要、也最容易理解错的一个设计。TCAM表项本身不分优先级但它有个物理特性地址越靠前命中优先级越高。于是硬件工程师想出一个很巧妙的办法——把长前缀放在低地址短前缀放在高地址。举个例子有三条路由10.1.0.0/16、10.1.1.0/24、0.0.0.0/0。在TCAM里的排列顺序是地址010.1.1.0/24掩码长度24地址110.1.0.0/16掩码长度16地址20.0.0.0/0掩码长度0这样当查找10.1.1.5时三条都匹配但硬件取地址最小的那条也就是10.1.1.0/24正好就是最长前缀匹配的结果。默认路由0.0.0.0/0放在最后因为它的掩码全是X永远排在最后兜底。理解了这个“倒序排列”原则后面讲表项管理里的插入、移动、碎片问题就都有了基础。TCAM里做一次插入操作如果中间有个空洞你当然可以直接写进去但一旦需要把一条更长的前缀插到更靠前的位置就可能要把后面一堆表项整体往后挪这就是表项管理的复杂度来源之一。2. TCAM表项管理的核心细节2.1 容量、分区和bank路由表不是想放哪就放哪TCAM不是一大块连续内存随便用它内部会分成若干个bank或者slice你可以理解为一个大仓库被隔成了多个独立的小隔间。路由表、ACL、流表、组播表往往各自占用一个或多个隔间。我在实际设备上看到过一个很典型的配置某芯片的TCAM总共能放十几K条IPv4路由但如果ACL也使用同一片TCAM区域路由容量就会被压缩。曾经遇到一次现场故障工程师在设备上加了数百条ACL规则结果BGP路由一震荡几千条路由因为TCAM空间不足而下发失败业务直接受损。查到最后才发现ACL规则占用的恰好是路由表预设的高优先级区域。所以表项管理的第一课不是“怎么写”而是“怎么分”。规划阶段就要计算路由表占多少区域ACL占多少区域流表占多少区域这些区域之间是否有硬件级隔离IPv4和IPv6是否共用一个查找表还是各有独立bank掩码规则的消耗怎么算后面会专门讲。2.2 表项生命周期从RIB到TCAM的完整路径一条路由从协议学习到最终进入TCAM要经过好几道工序。控制面路由协议BGP、OSPF把路由放进RIB路由信息库然后路由进程做选路、加表生成FIB转发信息库最后驱动层把FIB里的前缀和下一跳信息翻译成TCAM表项和关联的SRAM数据。关键点在于RIB里有几十万条路由TCAM里通常只有几万条不是所有路由都会进硬件。哪些进、哪些不进由策略决定。常见做法是默认全部下发满了之后按前缀长度、协议优先级、流量热度做过滤也有设备支持“硬件转发表只保留活跃路由”的模式把不活跃的长尾路由留在软件转发面。这个过程并不总是自动的。很多设备上有“路由下发模式”的配置项选错了会导致部分路由彻底无法硬件转发。我自己踩过的坑是开启IPv6后忘了检查IPv6路由表所在的TCAM分区是否足够结果IPv6前缀全堆在CPU软件转发路径上转发性能直接崩了。2.3 掩码规则和精确规则容量要分开算TCAM的容量统计有个容易混淆的地方。一条“精确匹配规则”掩码全是0或1即前缀长度等于32的IPv4路由通常只占一个entry但一条“范围匹配”或“部分掩码”的规则在硬件里可能要拆成多条entry来表示。这也是为什么有时你看到TCAM利用率才60%但新加一条ACL却说“硬件资源不足”。因为ACL里如果写了端口范围、IP范围硬件可能要把一个范围拆成好几个掩码项消耗的entry数量会翻倍甚至翻几倍。路由表里也有类似问题——一条/24的前缀占一个entry但一条不以字节边界对齐的/23可能就要占两个entry。不同芯片处理方式不同但思路是一致的规划容量时不能只看“路由条数”要看“掩码规则数”。我习惯在做容量评估时用“最坏情况掩码规则数”而不是“前缀条数”来做计算。比如预计要上10万条IPv4路由按最坏情况每个前缀产生1.5个entry那就得预留15K以上的TCAM entry空间否则上线后路由一增长就容易顶满。2.4 分配与释放碎片、空洞和归还策略TCAM表项管理有个和内存管理很像的问题碎片化。路由不断up/down前面说过长前缀在低地址、短前缀在高地址如果某条长前缀被删除腾出来的空洞在中前部而新学到的短前缀通常只能加在尾部那中间的空洞就浪费了。更麻烦的是一些芯片要求TCAM表项在物理上连续存放或者要求同一个前缀家族的条目不能跨bank边界。这时候空洞可能因为尺寸不合适而根本没法被利用需要用“压缩”机制把后面的表项整体前移。压缩操作不是免费午餐。它会中断转发面一小段时间甚至引起丢包。我见过某些低端设备在路由震荡频繁时反复触发TCAM压缩结果表现为“CPU不高但转发时通时断”。这就是碎片化导致的整理风暴。所以好的表项管理一定要做“预碎片”插入前先按前缀长度分组尽量把同长度的前缀集中放置删除时做延迟回收不是立刻清空而是标记成“待回收”等攒到一定量再统一整理减少压缩次数。3. 路由更新时的表项一致性问题3.1 增量更新和批量下发的取舍路由表的变化是持续不断的BGP邻居一抖动可能瞬间产生几千条更新。TCAM写入本身很快但每次写入都可能涉及表项移动如果一条一条地操作效率非常低。业界的做法是“收拢”和“合并”。软件层面先把一个短暂窗口内的所有路由变化收集起来统一算出差量生成一个最小的更新集合再一次性下发硬件。比如30秒内某个BGP邻居断连又恢复如果逐条处理TCAM可能要被折腾好几轮合并后可能只需要把最终状态下发一次。但增量更新有个前提软件里的表项模型必须和硬件TCAM布局完全同步。如果软件认为某条路由在地址100硬件实际在地址85更新时就可能覆盖到错误的条目。我们调试过的一个bug就是删除路由时软件按前缀内容去找硬件地址正好碰到重复前缀的另一个表项结果把不该删的删了下一条路由全部错乱。所以一个严谨的TCAM驱动一定会有“前缀-硬件地址”的反向映射表每次操作前先查映射而不是直接全表扫描。3.2 原子切换先改数据还是先改索引TCAM命中之后得到的只是一个索引真正的下一跳信息存在关联的SRAM里。所以一次路由更新至少涉及两个动作写TCAM表项前缀和掩码写SRAM数据下一跳、出接口、封装信息。这两个动作如果不做原子切换就会出大问题。假设你先把TCAM里的前缀从/24改成/16但SRAM里对应的下一跳还是旧的那么在“TCAM已改、SRAM未改”的窗口期所有匹配这个前缀的流量都会按旧下一跳转发可能直接送到一个已经撤销的邻居那里。处理方式有几种。一种是硬件支持“提交”机制你可以先把所有表项写入shadow区域最后下发一条commit命令一次性切换这样中间态不会生效。另一种是软件控制顺序新增时先写SRAM再写TCAM删除时先删TCAM再清SRAM这样任何时刻TCAM里的有效表项都有正确的下一跳可查。我自己写驱动时最喜欢“新增先SRAM后TCAM删除先TCAM后SRAM”这个顺序虽然听起来简单但能避免绝大多数中间态问题。不过要注意有些老芯片没有shadow机制TCAM写入是即时生效的这时候只能靠上层设计来规避。3.3 路由震荡时的保护机制路由震荡flapping是TCAM管理员的噩梦。一个BGP邻居反复up/down或者某条前缀被频繁撤销和重新通告TCAM会跟着反复写删。硬件写入虽然快但频繁写TCAM会带来两个风险一是写入电流大导致芯片发热二是短时间内表项不断移动导致查询出现短暂错误。常见的保护机制是“惩罚”和“抑制”。控制面对flapping路由做阻尼转发面对反复删除的前缀做“黑洞保持”之类的保护比如一条路由在短时间内被删除又重新出现驱动层可以暂时保持旧表项不删等新状态稳定后再更新避免无谓的硬件抖动。这种策略在部署时要注意和路由协议的配合。有一次我们把“删除保护”时间设成10秒结果一条路由已经从BGP里消失了但TCAM里还有一个“幽灵表项”在转发流量导致路由黑洞变成了路由环路。最后是把保护时间调短并增加了“保护表项必须通过外力刷新”的逻辑才算解决。4. 常见问题与排查实录4.1 硬件表项“写不进”的几种典型原因TCAM下发失败的报错不同厂商叫法不同但根因基本就几类。第一种就是空间不足最直接表项计数器顶满新表项下发直接返回错误。第二种是掩码资源不足空间计数器看着还有空闲但可以用的掩码模式已经用完很多芯片对“掩码规则类型”有数量限制。第三种是资源冲突比如ACL和路由表共享bankACL突然增加导致路由表区域被抢占。排查这类问题一定要学会看硬件的表项占用明细命令而不是只看汇总。汇总只告诉你“用了60%”明细才能告诉你“路由表用了30%、ACL用了25%、流表用了5%”以及掩码规则计数器到底爆没爆。遇到“空间明明够但写不进”的情况优先查掩码规则数。4.2 查得到表项但转发不对问题出在哪另一种更隐蔽的问题是show命令显示表项存在但流量转发结果不对。这种场景下硬件查表很可能命中了另一条优先级更高的重复前缀。TCAM允许多条匹配取低地址者如果你在新增路由时没有检查是否存在同样的前缀就可能出现两条相同的/24一条指向旧下一跳、一条指向新下一跳硬件永远选旧的那条。我处理过的一个案例就是自动脚本批量下发静态路由遇到已存在的重复前缀时没有先删旧表项而是直接尝试写入驱动返回“success”但实际写入到了另一个空闲位置结果新旧两条/24同时在表里流量一直走旧路径。所以重复前缀检查是TCAM写入逻辑里绝对不能省的一步必须在软件层就拦截掉。4.3 一张速查表症状、原因、处理方式下面这张表我把这些年遇到比较典型的TCAM问题归纳了一下覆盖“现象-原因-处理”三个视角方便大家排查时对照参考。现象可能原因排查手段与处理方式新路由学不到CPU转发飙升TCAM空间不足查看TCAM分区利用率明细做路由汇总/老化清理表项写入报错但空间看着够掩码规则数超限查掩码计数器减少范围/非对齐掩码规则路由存在但流量走旧路径重复前缀占坑检查重复前缀表项先删旧再增新软件层做唯一性检查路由震荡时转发频繁抖动表项碎片化触发压缩调整删除保护时间合并批量更新减少单条操作ACL加了之后路由容量骤降共享bank被ACL抢占重新规划TCAM分区设置硬性资源隔离IPv6路由导致IPv4容量不够双栈规划不足开启分区隔离IPv6路由汇总或升级更多TCAM资源4.4 一个小脚本把容量问题挡在上线前靠肉眼巡检肯定不够我后来养成了写脚本的习惯。每台设备、每个芯片的TCAM容量基线都不同我会定期采集这些计数器的值存成历史基线并在路由协议邻居上线前跑一次容量预检。核心逻辑很简单收集设备当前的TCAM分区利用率、掩码规则数、剩余entry数再结合计划新增的路由数量做预估。如果新增后可能超过阈值就提前告警而不是等路由学进来发现写不进去才处理。这里是伪代码思路供参考# 伪代码TCAM容量预检 current_entries get_tcam_used(ipv4-rib) total_entries get_tcam_total(ipv4-rib) planned_prefixes get_bgp_prefix_count() * 1.2 # 预留20%增长 if current_entries planned_prefixes total_entries * 0.85: alarm(TCAM容量即将耗尽请检查路由汇总或扩容方案)5. 上线前必做的TCAM容量管理与调优实践5.1 容量基线先弄清自家设备的“可用面积”不同芯片的TCAM容量差异很大有的十几K条路由有的几十K条而且IPv4和IPv6的消耗比可能是1:1也可能是1:2取决于掩码对齐方式。做容量管理第一步就是把自家设备的TCAM“地形图”摸清楚总共有多少个bank、每个bank支持哪些类型的规则、路由表可以占用哪些bank、ACL和路由表是否完全隔离。摸清之后把它固化成一份基线文档。我见过很多团队设备上线之后才知道TCAM分区还可以重新配置但为时已晚只能停机维护窗口调整。这个文档至少要包含设备型号、芯片型号、TCAM总容量、各分区分配比例、IPv4/IPv6路由容量预估、ACL占用规则、掩码规则上限。每半年或者大版本升级前对照基线重新核对一遍。5.2 让路由表“瘦身”的实用手段如果路由量确实超过TCAM容量就只能从路由本身下手。最朴素也最有效的是路由汇总把多个连续的子网聚合成一条大前缀下发。但要注意汇总必须基于真实的拓扑可达性不能为了省空间盲目汇总否则会产生路由黑洞或次优路径。第二个手段是控制下发策略。不是所有路由都需要硬件转发的比如某些边缘设备的BGP full table90%以上的前缀可能根本没有活跃流量。这种情况下可以配置“只下发活跃路由”把长尾路由留在软件慢路径虽然极端流量场景下有性能风险但对很多业务来说完全够用。第三个手段是定期清理。老的静态路由、已失效的隧道路由、重复的默认路由都会悄悄侵蚀TCAM容量。养成每个维护窗口做一次“表项体检”的习惯把无效表项坚决清掉。5.3 更新框架设计把表项操作做成可控事务最后讲讲软件层面的表项管理框架。我比较推荐把TCAM操作抽象成“预留-提交-回滚”三个动作。预留阶段在软件层分配好硬件地址和SRAM索引提交阶段一次性下发并校验结果回滚阶段在下发失败或校验失败时自动恢复旧状态。这个框架看起来很常规但实际执行中有几个细节值得注意。一是校验不能只校验“写入成功”要回读确认有些芯片写入接口返回成功但实际数据有误。二是预留的地址不能直接写入硬件要等所有依赖项都就绪后再提交避免半成品表项生效。三是回滚必须是幂等的重复执行不会产生副作用这样即使控制面发生异常重启也能恢复到一个已知的稳定状态。按照这个框架我把之前遇到的重复前缀、覆盖错误、中间态引入转发黑洞等一票问题都从架构上规避掉了。虽然写得时候麻烦一点但上线后的半夜电话数量明显减少。我自己这几年的体会是TCAM这个东西看着是个硬件部件实际上是一门“如何在有限资源下保持确定性”的工程学问。它不复杂但每个细节都能要命。尤其是当你面对十万条路由、几十个邻居、随时可能发生的震荡时真正靠得住的不是某条命令而是你对这片存储空间从底到顶的掌控力。最后分享一个我一直在用的土办法每次大版本升级或路由策略调整之后强制对比一次“调整前”和“调整后”的TCAM容量基线数据。一旦发现某个分区的增长趋势异常宁可多花一小时查清楚也不要带着隐患上线。TCAM资源这东西平时不显山不露水真到耗尽那一天往往已经是业务受影响之后了。
