路由表和FIB表这两个词很多人第一次听到是在教材的某一章背完定义就翻过去了。真正让人卡住的往往是动手之后冒出来的那个疑问书上说路由器转发靠查FIB表可我在设备上敲ip route看到的明明是路由表这两张表到底是一张还是两张更让人困惑的是有时候路由表里目标网段的路由写得清清楚楚下一跳也能通接口也是up可业务流量就是过不去。这类问题如果脑子里只有路由表一个概念基本查不出方向把路由表和FIB表分清楚很多看似玄学的故障会立刻变得有迹可循。下面这些内容我会按这两张表各自是什么、为什么要拆开、一条路由怎么从一张表走到另一张表、查表为什么这么快、以及表对不齐时怎么一步步排这条线来讲适合刚接触网络设备转发原理的新手也适合已经会用命令但没深想过内部机制的一线运维。1. 同一台设备里的两个分身控制平面想清楚转发平面跑得快1.1 一个包从进来到出去中间到底发生了什么先说结论路由表和FIB表不是同一份东西它们服务的是两个完全不同的目标。设备上的路由协议进程、静态配置、直连网段识别这一整套逻辑跑在控制平面里。控制平面的任务很重它要收集邻居信息、跑最短路径算法、比较不同来源的路由、处理路由抖动、做策略过滤最后得出一个结论——到达某个目的网段应该走哪条路。这个结论汇总起来就是路由表业内也常叫RIBRouting Information Base路由信息库。转发平面做的事情则简单得多。一个数据包进来设备只有极短的时间做决定看目的IP查一张已经预处理好、只包含最终结果的小表拿到出接口和下一跳的二层信息改包头发出去。这张小表就是FIB表Forwarding Information Base转发信息库。注意这里的关键差别路由表是候选集合加选优过程的产物FIB表是选优结束后的最终答案。打个生活化的比方。路由表像物流公司调度室墙上那张巨大的线路图上面标了所有可能的路线、每条路的时效、成本、拥堵情况、备用方案甚至还有几条已经废弃但没擦掉的线。FIB表则像贴在每个分拣工位上的速查卡只写一行——发往某片区走三号传送带。分拣工人不需要知道三号传送带为什么最优他只需要知道结果是三号。提示把路由表理解成决策依据把FIB表理解成执行指令后面所有的排错思路都是从这个划分里长出来的。1.2 为什么非要把它们拆开性能与确定性的双重压力有人会问既然最终都是要知道往哪发为什么不干脆让转发的时候直接查路由表答案藏在一个词里每秒查询次数。一台中等规模的设备满线速转发时每秒要做几百万次甚至上亿次查表。如果每次查询都要遍历包含多种路由来源、比较优先级、比较度量值、判断路由是否有效、再递归解析下一跳的完整路由表这个开销在硬件上根本无法承受。拆开之后控制平面可以慢可以用复杂算法可以容忍几秒钟的收敛时间转发平面必须快必须做成固定流水线必须用最简单的数据结构。这就是网络设备设计里最经典的控制与转发分离思想。软件定义的网络架构、路由器的主控板与线卡分工本质上都是这个思想的延伸。还有一层原因容易被忽略确定性。路由表在协议收敛期间是不断变化的如果转发直接依赖它那么收敛过程中的每一点抖动都会直接反映到数据通路上。而FIB表的下发是一个原子性的动作——要么这条路由整条装进去要么不装中间态不会暴露给转发引擎。这种快照式的下发方式让转发行为在网络动荡时依然保持可预测。1.3 混为一谈会踩的第一个坑最常见的误解是把路由表里有直接等同于流量能通。实际上从路由表到FIB表之间还隔着好几道关卡路由优选、下一跳递归解析、邻接信息建立、表项容量检查、硬件下发确认。任何一道关卡没过路由表里那条路由就只是一条记录而不是一条通路。我在后面第 6 节会把这几个关卡拆开讲这里先记住一点查不通的时候第一步不是怀疑路由写错了而是怀疑路由没被装进FIB。2. 拆开字段看差别路由表臃肿是因为它要讲道理FIB精简是因为它只干活2.1 路由表项里那些只影响选谁、不影响怎么转的字段一条典型的路由表项远不止目的网段和下一跳两个信息它通常还带着这些内容路由来源是直连、静态配置还是某个动态协议学来的、优先级或管理距离不同来源之间比大小用的权重、度量值同一来源内部比优劣的数值、路由年龄和时间戳、路由标记、在某些协议里还有AS路径和下一跳的原始属性。这些东西的共同特点是它们只参与选优选完之后对转发毫无用处。举个例子一条静态路由优先级是60一条动态学来的路由优先级是110静态胜出。可一旦静态胜出并被装进FIB转发引擎根本不需要知道这条路是静态配的或者它是60不是110它只需要知道出哪个口、下一跳MAC是多少。FIB表把这些决策痕迹全部剥掉了留下的正是纯粹的执行信息。2.2 FIB表项的三要素前缀、出接口、邻接一条FIB表项在大多数实现里核心就是三样东西目的前缀加掩码长度、出接口索引、邻接索引。邻接索引是个很关键的间接层它指向一张邻接表邻接表里存的是二层重写需要的信息——下一跳的MAC地址、本接口的MAC地址、VLAN标签等。为什么要多这一层因为多个不同的目的前缀可能指向同一个下一跳共享一份邻接信息既省空间也方便下一跳MAC变化时统一更新。除了这三样FIB表项往往还挂着一些附加信息转发统计计数器、QoS队列映射、ECMP组标识、是否允许分片的标志等。这些属于转发时需要顺手用一下的信息和路由表里那些决策时才用的信息完全是两回事。对比维度路由表RIBFIB表维护者控制平面协议进程、配置模块转发平面内核转发路径或芯片内容范围所有来源、所有候选路由仅优选后生效的路由典型字段前缀、下一跳、出接口、优先级、度量、来源、标记、年龄前缀、出接口、邻接索引、ECMP组、统计计数数据规模大含冗余和失效项小只留有效项更新节奏协议收敛时批量变化随优选结果逐条增量下发查询方式软件遍历、有序结构、带条件判断最长前缀匹配硬件并行或软件专用树存放位置主控内存芯片表项或内核转发数据结构这张表建议反复看几遍。后面所有的排错动作其实都是在判断问题出在左列还是右列。2.3 一个容易忽略的细节FIB里可能出现路由表里看不见的项反过来也有意思的情况FIB表里有时候会有一些路由表里翻不到对应记录的项。比如某些实现会为每个接口自动生成一条直连的主机路由或者为广播地址、组播地址生成特殊表项这些在常规的路由表展示里可能被折叠或省略。所以排错时如果发现FIB里的条目数比路由表多不必惊讶先确认那些多出来的项是不是系统自动生成的辅助表项。3. 一条路由从路由表走进FIB表的完整旅程3.1 第一关路由优选同前缀多来源打架时谁说了算同一个目的前缀完全可能同时被多种方式覆盖。比如一个网段既配了静态路由又被动态协议学到了一模一样的路由还可能有条默认路由也能覆盖它。这时候设备必须做选择选择规则通常是分层的第一步比优先级有的实现叫管理距离或preference。直连路由优先级最高静态路由次之各种动态协议按约定排开外部引入的路由通常优先级最低。这一步是跨来源的比较目的是让人工干预压过自动学习。第二步如果来源相同或优先级相同比度量值。度量值是同一种协议内部算出来的代价比如跳数、带宽开销、延迟累加值。第三步如果度量和优先级都相同就进入等价多路径处理也就是常说的ECMP——几条路一起用靠哈希分流。这里有个实操中很常见的误区有人以为路由表里显示的那条就是唯一的路其实展示出来的往往只是优选结果被淘汰的候选路由在详细视图里还能看到标记为无效或被抑制。排查路由选错方向的问题时一定要看详细视图而不是简略视图。3.2 第二关下一跳递归解析BGP场景下的高频翻车点动态协议里尤其是边界网关协议学到的路由给出的下一跳经常不是直连的地址而是一个再走几跳才能到的地址。设备必须做一次递归查找拿这个下一跳地址再去路由表里查一遍直到找到一个直连的下一跳为止然后把这条链路的最终出接口和邻接信息写进FIB。这一步是故障高发区。如果递归查不到结果这条路由就会被判定为不可达不会进FIB。表现出来就是路由表里明明有这条路由状态显示有效但流量就是不通。更隐蔽的情况是递归链在中途断了——比如中间某一段的下一跳接口down了整条链跟着失效但上层路由的状态更新有延迟。我的经验是遇到路由在但不通且涉及动态协议的场景先确认下一跳能不能递归到底。可以通过带递归解析的查表命令验证实际选中的出接口和下一跳而不是只看路由表里写的那个原始下一跳。3.3 第三关邻接建立与硬件下发看不见的那一半路由被优选、下一跳解析成功还不算完。转发平面要真正把包发出去必须知道下一跳的二层地址。这个信息存在邻居表里通过地址解析协议或者邻居发现协议动态获取。如果邻居表里没有对应条目或者条目处于不完整状态包会被暂存或者直接丢弃同时触发解析请求。这时候抓包能看到请求发出去了但没回应流量表现为发不出去。再往后是硬件下发。在带专用转发芯片的设备上控制平面算好的FIB还要通过驱动接口写进芯片的表项里。这一步可能因为芯片表项满、下发表项冲突、驱动队列堵塞而失败。失败之后的表现非常典型软件侧查询一切正常硬件侧实际转发却是黑洞。这类问题在路由规模突然增长、或者配置了大量细粒度前缀之后特别容易出现。注意如果你的设备同时有软件转发和硬件转发两条路径排错时一定要确认流量实际走的是哪一条。测试用的ping包可能走软件路径正常而业务大流量走硬件路径异常两者结论完全相反。4. 转发查表为什么能这么快最长前缀匹配与它的两种实现4.1 哈希表在这里为什么不好使很多人第一反应是查表嘛用哈希不就行了O(1)。这个思路在FIB上直接失效原因是转发需要的不是精确匹配而是最长前缀匹配Longest Prefix MatchLPM。设想目的地址是 192.168.1.5设备上同时存在 192.168.1.0/24、192.168.0.0/16、0.0.0.0/0 三条路由。这三条都能覆盖这个地址但必须选掩码最长的那条也就是 /24。哈希只能回答这个键存不存在回答不了在所有能覆盖它的前缀里哪个最长。所以FIB的查找结构必须是专门为前缀匹配设计的。4.2 软件实现压缩前缀树一层层往下走纯软件转发的主机或者软件路由器通常用各种变体的前缀树来做LPM。经典做法是把地址按比特展开成一棵树从根往下走沿途记录最后一个命中的有效前缀走到走不动为止。为了减少层数、提高缓存命中率实际实现会做路径压缩和多比特合并——把只有单个子节点的链压缩成一条边把连续几层合并成一次比较多个比特。这样树的高度大幅降低查询只需要几次内存访问。这类结构的特点是内存占用可控、支持大规模路由、更新相对灵活代价是查询要走多次内存访问靠缓存来弥补。在通用处理器上配合预取和缓存优化做到千万级每秒的查询是可行的但和专用芯片还是有数量级差距。4.3 硬件实现三态内容寻址存储器一次并行比较出结果专用转发芯片走的是另一条路。它用的存储结构每个比特可以存三种状态0、1、以及不关心。这个不关心就是关键——一条 /24 的路由前24位有效后8位全部标记为不关心那么任何前24位匹配的地址一次比较就能命中。所有表项并行比较一个时钟周期内出结果天然满足最长前缀匹配的需求把前缀长度也纳入比较维度长的优先。代价也很直接这种存储器单元面积大、功耗高、容量有限。所以硬件FIB的规模是硬约束IPv4通常能做到几万到几十万条量级IPv6因为前缀更长、表项更宽能装的条数还要再打折。这就是为什么核心设备上要精细规划路由规模也是为什么有些设备会提供把部分路由放到软件慢路径的降级方案。4.4 等价多路径查完之后还要再选一次FIB里一个前缀可能对应一组出接口和下一跳这就是等价多路径。查表命中之后还要在这组里挑一个通常用哈希哈希因子取五元组源目的地址、源目的端口、协议号。这里有个实测中很值得注意的现象哈希函数的分布不均会导致某条链路被打爆而其他链路空闲尤其是流量种类单一、源目的地址组合很少的场景。遇到链路利用率严重不均先别怀疑路由配错八成是哈希极化。5. 主机上的多张表与多条规则比一张路由表复杂得多的现实5.1 默认看到的那张表只是其中一张在通用操作系统上敲查看路由的命令默认展示的往往只是主表。而系统内部其实维护着多张表每张表有各自的编号和用途还有一套规则决定什么样的包查哪张表。这套机制叫策略路由。默认规则通常是这样排的优先级最高的规则把本地地址相关的流量导向本地表接着才是主表最后是默认表兜底。这意味着你配在主表里的路由不一定对某个包生效——如果前面有更高优先级的规则把它导向了别的表主表里那条路由就是摆设。这个机制解释了一个非常经典的困惑我明明在主表里加了路由为什么流量还是走老路答案往往是别的表里有条更具体的路由或者某条规则把流量提前截走了。5.2 本地表和那些看不见的主机路由本地表里存的是本机所有接口地址、广播地址、回环地址对应的表项作用是让发往本机地址的包走本地投递而不是往外转发。这些表项数量不少而且会随接口地址变化自动增减。排错时如果发现某个地址的流量被本地吞掉了多半是本地表里有对应条目——比如你给接口配了个地址恰好和你要访问的目的地址冲突。广播地址的处理也容易出问题。发往子网广播地址的包应该从对应接口发出去如果本地表或者主表里缺了相应条目包可能被直接丢弃。这类问题在多网卡、多子网的机器上尤其常见。5.3 策略路由实战什么时候真的需要多张表策略路由不是炫技它解决的是按源地址、按入接口、按标记分流这类需求普通的目的地址路由做不到。典型场景包括多线接入时让不同来源的流量走不同出口、把特定业务的流量强制导向某条专线、以及做流量牵引和黑洞。配置的时候有个顺序问题必须注意规则和表是两个独立的东西先有表里有路由再加规则指向这张表否则规则生效的瞬间流量会因为查不到路由而被丢弃。反过来删的时候要先删规则再清表避免中间出现一段指向空表的窗口期。这个顺序踩过一次坑就记住了。6. 表里有路由但流量不通一条可以照着走的排查链路6.1 第一步确认包实际查的是哪张表、命中了哪条不要一上来就翻路由表找那条路由先让系统告诉你如果现在发一个去某地址的包它会怎么走。带查表模拟功能的命令能直接给出选中的源地址、出接口、下一跳这个结果才是转发平面真正会用的答案比你自己在路由表里找要可靠得多。如果模拟结果和预期不符就顺着规则链往上找是哪条规则把查询导向了别的表那张表里又有什么更具体的条目。这一步能把配了没生效和配错了地方两类问题区分开。6.2 第二步下一跳能不能到邻居表里有没有对应条目模拟查表给出了下一跳地址之后紧接着要确认这个下一跳是不是活的。方法有两个方向一是看邻居表里有没有对应的二层地址映射状态是否完整二是直接对下一跳做连通性测试但要注意测试包可能走的是和业务不同的路径结论要谨慎采信。邻居表里的条目状态很能说明问题。如果条目一直处于待解析状态说明请求发出去了没回应可能是对端没开、中间有隔离、或者地址配错如果条目根本不存在说明从来没有触发过解析那就要回头看看是不是流量压根没走到这一步。6.3 第三步软件侧和硬件侧对齐了吗这一步针对带专用转发芯片的设备。判断方法通常是看接口的转发统计软件侧能查到包被正确转发但硬件侧接口计数器不动或者只有少量包动基本可以确定是硬件表项没下发成功。触发硬件下发失败的常见原因有三个表项容量满、下发表项时出现冲突、以及驱动或固件层面的异常。第一种最普遍尤其是在路由条目数量突然增长的场景下。验证方法是看当前已用表项数和上限的比值以及有没有相关的溢出计数或告警。有些设备在表项满时不会报错而是静默地把新路由丢在软件侧这种无声降级最难查。6.4 第四步反向路径检查和各类过滤是不是在偷偷丢包前面三步都正常流量还是不通就要考虑过滤机制了。反向路径检查的逻辑是收到一个包先看它的源地址从来的这个接口回不回得去回不去就丢。这个机制在多出口、非对称路由的环境里非常容易误伤表现就是单向通、或者特定来源的流量死活进不来。类似的还有各类访问控制列表、防火墙规则、以及接口上的方向性过滤。排查这类问题的效率取决于你有没有在关键节点上抓包——抓包能立刻告诉你包是没进来还是进来了被丢了这一个信息就能砍掉一半的排查范围。7. 容量、老化与规模那些文档里不会写、但天天要面对的事7.1 硬件表项的容量规划比想象中更紧张带专用芯片的设备FIB容量是硬指标而且这个指标通常是共享池的形式——IPv4路由、IPv6路由、访问控制列表、MAC表可能共用同一块存储。也就是说你多配几千条访问控制条目可能就把路由的可用空间挤掉了一部分。这个联动关系在很多产品文档里不会明说但它真实存在。规划的时候要留余量。我的习惯是实际路由规模不超过标称容量的六七成剩下的留给突发增长、协议收敛期间的临时表项、以及后续业务扩展。如果业务会引入大量细粒度前缀比如按目的地址做精细化调度更要提前算清楚别等到上线之后才发现装不下。7.2 邻居表老化带来的间歇性不通邻居表条目是有生命周期的长时间没有流量就会老化删除下次有流量时重新解析。正常情况下这个过程无感但在高负载或者对端响应慢的场景下会出现解析请求发出去了回包还没到包已经被丢了的短暂窗口。表现出来就是偶发的首包丢失或者间歇性不通用持续ping很难复现用高频短连接的业务最容易撞上。缓解办法一般有两个方向一是调整老化时间让条目活得久一点二是保证链路上有持续的低速保活流量让条目不被老化。前者要注意别设太长导致地址变更后残留错误映射后者要注意保活流量本身的开销。两边都要权衡。7.3 收敛期间的表项抖动以及一个实用的小习惯路由协议收敛的时候FIB表会经历一轮批量删除和批量下发。这个过程中如果表项数量接近容量上限可能出现删了旧的还没装新的的短暂空洞流量在这几百毫秒里会被丢弃。做变更窗口的时候如果业务对丢包敏感最好避开路由规模接近上限的时段或者提前清理掉不再使用的路由条目腾出空间。最后分享一个我自己养成的小习惯每次排查转发类问题先把路由表视图和实际查表结果两个东西并排打出来对比再看一眼邻居表状态。这三样东西放在一起八成的问题当场就能定位到是哪一层出了岔子。这个动作花不了两分钟但比我早期那种到处翻配置、凭感觉改参数的做法效率高太多了。
路由表和FIB表这两个词很多人第一次听到是在教材的某一章背完定义就翻过去了。真正让人卡住的往往是动手之后冒出来的那个疑问书上说路由器转发靠查FIB表可我在设备上敲ip route看到的明明是路由表这两张表到底是一张还是两张更让人困惑的是有时候路由表里目标网段的路由写得清清楚楚下一跳也能通接口也是up可业务流量就是过不去。这类问题如果脑子里只有路由表一个概念基本查不出方向把路由表和FIB表分清楚很多看似玄学的故障会立刻变得有迹可循。下面这些内容我会按这两张表各自是什么、为什么要拆开、一条路由怎么从一张表走到另一张表、查表为什么这么快、以及表对不齐时怎么一步步排这条线来讲适合刚接触网络设备转发原理的新手也适合已经会用命令但没深想过内部机制的一线运维。1. 同一台设备里的两个分身控制平面想清楚转发平面跑得快1.1 一个包从进来到出去中间到底发生了什么先说结论路由表和FIB表不是同一份东西它们服务的是两个完全不同的目标。设备上的路由协议进程、静态配置、直连网段识别这一整套逻辑跑在控制平面里。控制平面的任务很重它要收集邻居信息、跑最短路径算法、比较不同来源的路由、处理路由抖动、做策略过滤最后得出一个结论——到达某个目的网段应该走哪条路。这个结论汇总起来就是路由表业内也常叫RIBRouting Information Base路由信息库。转发平面做的事情则简单得多。一个数据包进来设备只有极短的时间做决定看目的IP查一张已经预处理好、只包含最终结果的小表拿到出接口和下一跳的二层信息改包头发出去。这张小表就是FIB表Forwarding Information Base转发信息库。注意这里的关键差别路由表是候选集合加选优过程的产物FIB表是选优结束后的最终答案。打个生活化的比方。路由表像物流公司调度室墙上那张巨大的线路图上面标了所有可能的路线、每条路的时效、成本、拥堵情况、备用方案甚至还有几条已经废弃但没擦掉的线。FIB表则像贴在每个分拣工位上的速查卡只写一行——发往某片区走三号传送带。分拣工人不需要知道三号传送带为什么最优他只需要知道结果是三号。提示把路由表理解成决策依据把FIB表理解成执行指令后面所有的排错思路都是从这个划分里长出来的。1.2 为什么非要把它们拆开性能与确定性的双重压力有人会问既然最终都是要知道往哪发为什么不干脆让转发的时候直接查路由表答案藏在一个词里每秒查询次数。一台中等规模的设备满线速转发时每秒要做几百万次甚至上亿次查表。如果每次查询都要遍历包含多种路由来源、比较优先级、比较度量值、判断路由是否有效、再递归解析下一跳的完整路由表这个开销在硬件上根本无法承受。拆开之后控制平面可以慢可以用复杂算法可以容忍几秒钟的收敛时间转发平面必须快必须做成固定流水线必须用最简单的数据结构。这就是网络设备设计里最经典的控制与转发分离思想。软件定义的网络架构、路由器的主控板与线卡分工本质上都是这个思想的延伸。还有一层原因容易被忽略确定性。路由表在协议收敛期间是不断变化的如果转发直接依赖它那么收敛过程中的每一点抖动都会直接反映到数据通路上。而FIB表的下发是一个原子性的动作——要么这条路由整条装进去要么不装中间态不会暴露给转发引擎。这种快照式的下发方式让转发行为在网络动荡时依然保持可预测。1.3 混为一谈会踩的第一个坑最常见的误解是把路由表里有直接等同于流量能通。实际上从路由表到FIB表之间还隔着好几道关卡路由优选、下一跳递归解析、邻接信息建立、表项容量检查、硬件下发确认。任何一道关卡没过路由表里那条路由就只是一条记录而不是一条通路。我在后面第 6 节会把这几个关卡拆开讲这里先记住一点查不通的时候第一步不是怀疑路由写错了而是怀疑路由没被装进FIB。2. 拆开字段看差别路由表臃肿是因为它要讲道理FIB精简是因为它只干活2.1 路由表项里那些只影响选谁、不影响怎么转的字段一条典型的路由表项远不止目的网段和下一跳两个信息它通常还带着这些内容路由来源是直连、静态配置还是某个动态协议学来的、优先级或管理距离不同来源之间比大小用的权重、度量值同一来源内部比优劣的数值、路由年龄和时间戳、路由标记、在某些协议里还有AS路径和下一跳的原始属性。这些东西的共同特点是它们只参与选优选完之后对转发毫无用处。举个例子一条静态路由优先级是60一条动态学来的路由优先级是110静态胜出。可一旦静态胜出并被装进FIB转发引擎根本不需要知道这条路是静态配的或者它是60不是110它只需要知道出哪个口、下一跳MAC是多少。FIB表把这些决策痕迹全部剥掉了留下的正是纯粹的执行信息。2.2 FIB表项的三要素前缀、出接口、邻接一条FIB表项在大多数实现里核心就是三样东西目的前缀加掩码长度、出接口索引、邻接索引。邻接索引是个很关键的间接层它指向一张邻接表邻接表里存的是二层重写需要的信息——下一跳的MAC地址、本接口的MAC地址、VLAN标签等。为什么要多这一层因为多个不同的目的前缀可能指向同一个下一跳共享一份邻接信息既省空间也方便下一跳MAC变化时统一更新。除了这三样FIB表项往往还挂着一些附加信息转发统计计数器、QoS队列映射、ECMP组标识、是否允许分片的标志等。这些属于转发时需要顺手用一下的信息和路由表里那些决策时才用的信息完全是两回事。对比维度路由表RIBFIB表维护者控制平面协议进程、配置模块转发平面内核转发路径或芯片内容范围所有来源、所有候选路由仅优选后生效的路由典型字段前缀、下一跳、出接口、优先级、度量、来源、标记、年龄前缀、出接口、邻接索引、ECMP组、统计计数数据规模大含冗余和失效项小只留有效项更新节奏协议收敛时批量变化随优选结果逐条增量下发查询方式软件遍历、有序结构、带条件判断最长前缀匹配硬件并行或软件专用树存放位置主控内存芯片表项或内核转发数据结构这张表建议反复看几遍。后面所有的排错动作其实都是在判断问题出在左列还是右列。2.3 一个容易忽略的细节FIB里可能出现路由表里看不见的项反过来也有意思的情况FIB表里有时候会有一些路由表里翻不到对应记录的项。比如某些实现会为每个接口自动生成一条直连的主机路由或者为广播地址、组播地址生成特殊表项这些在常规的路由表展示里可能被折叠或省略。所以排错时如果发现FIB里的条目数比路由表多不必惊讶先确认那些多出来的项是不是系统自动生成的辅助表项。3. 一条路由从路由表走进FIB表的完整旅程3.1 第一关路由优选同前缀多来源打架时谁说了算同一个目的前缀完全可能同时被多种方式覆盖。比如一个网段既配了静态路由又被动态协议学到了一模一样的路由还可能有条默认路由也能覆盖它。这时候设备必须做选择选择规则通常是分层的第一步比优先级有的实现叫管理距离或preference。直连路由优先级最高静态路由次之各种动态协议按约定排开外部引入的路由通常优先级最低。这一步是跨来源的比较目的是让人工干预压过自动学习。第二步如果来源相同或优先级相同比度量值。度量值是同一种协议内部算出来的代价比如跳数、带宽开销、延迟累加值。第三步如果度量和优先级都相同就进入等价多路径处理也就是常说的ECMP——几条路一起用靠哈希分流。这里有个实操中很常见的误区有人以为路由表里显示的那条就是唯一的路其实展示出来的往往只是优选结果被淘汰的候选路由在详细视图里还能看到标记为无效或被抑制。排查路由选错方向的问题时一定要看详细视图而不是简略视图。3.2 第二关下一跳递归解析BGP场景下的高频翻车点动态协议里尤其是边界网关协议学到的路由给出的下一跳经常不是直连的地址而是一个再走几跳才能到的地址。设备必须做一次递归查找拿这个下一跳地址再去路由表里查一遍直到找到一个直连的下一跳为止然后把这条链路的最终出接口和邻接信息写进FIB。这一步是故障高发区。如果递归查不到结果这条路由就会被判定为不可达不会进FIB。表现出来就是路由表里明明有这条路由状态显示有效但流量就是不通。更隐蔽的情况是递归链在中途断了——比如中间某一段的下一跳接口down了整条链跟着失效但上层路由的状态更新有延迟。我的经验是遇到路由在但不通且涉及动态协议的场景先确认下一跳能不能递归到底。可以通过带递归解析的查表命令验证实际选中的出接口和下一跳而不是只看路由表里写的那个原始下一跳。3.3 第三关邻接建立与硬件下发看不见的那一半路由被优选、下一跳解析成功还不算完。转发平面要真正把包发出去必须知道下一跳的二层地址。这个信息存在邻居表里通过地址解析协议或者邻居发现协议动态获取。如果邻居表里没有对应条目或者条目处于不完整状态包会被暂存或者直接丢弃同时触发解析请求。这时候抓包能看到请求发出去了但没回应流量表现为发不出去。再往后是硬件下发。在带专用转发芯片的设备上控制平面算好的FIB还要通过驱动接口写进芯片的表项里。这一步可能因为芯片表项满、下发表项冲突、驱动队列堵塞而失败。失败之后的表现非常典型软件侧查询一切正常硬件侧实际转发却是黑洞。这类问题在路由规模突然增长、或者配置了大量细粒度前缀之后特别容易出现。注意如果你的设备同时有软件转发和硬件转发两条路径排错时一定要确认流量实际走的是哪一条。测试用的ping包可能走软件路径正常而业务大流量走硬件路径异常两者结论完全相反。4. 转发查表为什么能这么快最长前缀匹配与它的两种实现4.1 哈希表在这里为什么不好使很多人第一反应是查表嘛用哈希不就行了O(1)。这个思路在FIB上直接失效原因是转发需要的不是精确匹配而是最长前缀匹配Longest Prefix MatchLPM。设想目的地址是 192.168.1.5设备上同时存在 192.168.1.0/24、192.168.0.0/16、0.0.0.0/0 三条路由。这三条都能覆盖这个地址但必须选掩码最长的那条也就是 /24。哈希只能回答这个键存不存在回答不了在所有能覆盖它的前缀里哪个最长。所以FIB的查找结构必须是专门为前缀匹配设计的。4.2 软件实现压缩前缀树一层层往下走纯软件转发的主机或者软件路由器通常用各种变体的前缀树来做LPM。经典做法是把地址按比特展开成一棵树从根往下走沿途记录最后一个命中的有效前缀走到走不动为止。为了减少层数、提高缓存命中率实际实现会做路径压缩和多比特合并——把只有单个子节点的链压缩成一条边把连续几层合并成一次比较多个比特。这样树的高度大幅降低查询只需要几次内存访问。这类结构的特点是内存占用可控、支持大规模路由、更新相对灵活代价是查询要走多次内存访问靠缓存来弥补。在通用处理器上配合预取和缓存优化做到千万级每秒的查询是可行的但和专用芯片还是有数量级差距。4.3 硬件实现三态内容寻址存储器一次并行比较出结果专用转发芯片走的是另一条路。它用的存储结构每个比特可以存三种状态0、1、以及不关心。这个不关心就是关键——一条 /24 的路由前24位有效后8位全部标记为不关心那么任何前24位匹配的地址一次比较就能命中。所有表项并行比较一个时钟周期内出结果天然满足最长前缀匹配的需求把前缀长度也纳入比较维度长的优先。代价也很直接这种存储器单元面积大、功耗高、容量有限。所以硬件FIB的规模是硬约束IPv4通常能做到几万到几十万条量级IPv6因为前缀更长、表项更宽能装的条数还要再打折。这就是为什么核心设备上要精细规划路由规模也是为什么有些设备会提供把部分路由放到软件慢路径的降级方案。4.4 等价多路径查完之后还要再选一次FIB里一个前缀可能对应一组出接口和下一跳这就是等价多路径。查表命中之后还要在这组里挑一个通常用哈希哈希因子取五元组源目的地址、源目的端口、协议号。这里有个实测中很值得注意的现象哈希函数的分布不均会导致某条链路被打爆而其他链路空闲尤其是流量种类单一、源目的地址组合很少的场景。遇到链路利用率严重不均先别怀疑路由配错八成是哈希极化。5. 主机上的多张表与多条规则比一张路由表复杂得多的现实5.1 默认看到的那张表只是其中一张在通用操作系统上敲查看路由的命令默认展示的往往只是主表。而系统内部其实维护着多张表每张表有各自的编号和用途还有一套规则决定什么样的包查哪张表。这套机制叫策略路由。默认规则通常是这样排的优先级最高的规则把本地地址相关的流量导向本地表接着才是主表最后是默认表兜底。这意味着你配在主表里的路由不一定对某个包生效——如果前面有更高优先级的规则把它导向了别的表主表里那条路由就是摆设。这个机制解释了一个非常经典的困惑我明明在主表里加了路由为什么流量还是走老路答案往往是别的表里有条更具体的路由或者某条规则把流量提前截走了。5.2 本地表和那些看不见的主机路由本地表里存的是本机所有接口地址、广播地址、回环地址对应的表项作用是让发往本机地址的包走本地投递而不是往外转发。这些表项数量不少而且会随接口地址变化自动增减。排错时如果发现某个地址的流量被本地吞掉了多半是本地表里有对应条目——比如你给接口配了个地址恰好和你要访问的目的地址冲突。广播地址的处理也容易出问题。发往子网广播地址的包应该从对应接口发出去如果本地表或者主表里缺了相应条目包可能被直接丢弃。这类问题在多网卡、多子网的机器上尤其常见。5.3 策略路由实战什么时候真的需要多张表策略路由不是炫技它解决的是按源地址、按入接口、按标记分流这类需求普通的目的地址路由做不到。典型场景包括多线接入时让不同来源的流量走不同出口、把特定业务的流量强制导向某条专线、以及做流量牵引和黑洞。配置的时候有个顺序问题必须注意规则和表是两个独立的东西先有表里有路由再加规则指向这张表否则规则生效的瞬间流量会因为查不到路由而被丢弃。反过来删的时候要先删规则再清表避免中间出现一段指向空表的窗口期。这个顺序踩过一次坑就记住了。6. 表里有路由但流量不通一条可以照着走的排查链路6.1 第一步确认包实际查的是哪张表、命中了哪条不要一上来就翻路由表找那条路由先让系统告诉你如果现在发一个去某地址的包它会怎么走。带查表模拟功能的命令能直接给出选中的源地址、出接口、下一跳这个结果才是转发平面真正会用的答案比你自己在路由表里找要可靠得多。如果模拟结果和预期不符就顺着规则链往上找是哪条规则把查询导向了别的表那张表里又有什么更具体的条目。这一步能把配了没生效和配错了地方两类问题区分开。6.2 第二步下一跳能不能到邻居表里有没有对应条目模拟查表给出了下一跳地址之后紧接着要确认这个下一跳是不是活的。方法有两个方向一是看邻居表里有没有对应的二层地址映射状态是否完整二是直接对下一跳做连通性测试但要注意测试包可能走的是和业务不同的路径结论要谨慎采信。邻居表里的条目状态很能说明问题。如果条目一直处于待解析状态说明请求发出去了没回应可能是对端没开、中间有隔离、或者地址配错如果条目根本不存在说明从来没有触发过解析那就要回头看看是不是流量压根没走到这一步。6.3 第三步软件侧和硬件侧对齐了吗这一步针对带专用转发芯片的设备。判断方法通常是看接口的转发统计软件侧能查到包被正确转发但硬件侧接口计数器不动或者只有少量包动基本可以确定是硬件表项没下发成功。触发硬件下发失败的常见原因有三个表项容量满、下发表项时出现冲突、以及驱动或固件层面的异常。第一种最普遍尤其是在路由条目数量突然增长的场景下。验证方法是看当前已用表项数和上限的比值以及有没有相关的溢出计数或告警。有些设备在表项满时不会报错而是静默地把新路由丢在软件侧这种无声降级最难查。6.4 第四步反向路径检查和各类过滤是不是在偷偷丢包前面三步都正常流量还是不通就要考虑过滤机制了。反向路径检查的逻辑是收到一个包先看它的源地址从来的这个接口回不回得去回不去就丢。这个机制在多出口、非对称路由的环境里非常容易误伤表现就是单向通、或者特定来源的流量死活进不来。类似的还有各类访问控制列表、防火墙规则、以及接口上的方向性过滤。排查这类问题的效率取决于你有没有在关键节点上抓包——抓包能立刻告诉你包是没进来还是进来了被丢了这一个信息就能砍掉一半的排查范围。7. 容量、老化与规模那些文档里不会写、但天天要面对的事7.1 硬件表项的容量规划比想象中更紧张带专用芯片的设备FIB容量是硬指标而且这个指标通常是共享池的形式——IPv4路由、IPv6路由、访问控制列表、MAC表可能共用同一块存储。也就是说你多配几千条访问控制条目可能就把路由的可用空间挤掉了一部分。这个联动关系在很多产品文档里不会明说但它真实存在。规划的时候要留余量。我的习惯是实际路由规模不超过标称容量的六七成剩下的留给突发增长、协议收敛期间的临时表项、以及后续业务扩展。如果业务会引入大量细粒度前缀比如按目的地址做精细化调度更要提前算清楚别等到上线之后才发现装不下。7.2 邻居表老化带来的间歇性不通邻居表条目是有生命周期的长时间没有流量就会老化删除下次有流量时重新解析。正常情况下这个过程无感但在高负载或者对端响应慢的场景下会出现解析请求发出去了回包还没到包已经被丢了的短暂窗口。表现出来就是偶发的首包丢失或者间歇性不通用持续ping很难复现用高频短连接的业务最容易撞上。缓解办法一般有两个方向一是调整老化时间让条目活得久一点二是保证链路上有持续的低速保活流量让条目不被老化。前者要注意别设太长导致地址变更后残留错误映射后者要注意保活流量本身的开销。两边都要权衡。7.3 收敛期间的表项抖动以及一个实用的小习惯路由协议收敛的时候FIB表会经历一轮批量删除和批量下发。这个过程中如果表项数量接近容量上限可能出现删了旧的还没装新的的短暂空洞流量在这几百毫秒里会被丢弃。做变更窗口的时候如果业务对丢包敏感最好避开路由规模接近上限的时段或者提前清理掉不再使用的路由条目腾出空间。最后分享一个我自己养成的小习惯每次排查转发类问题先把路由表视图和实际查表结果两个东西并排打出来对比再看一眼邻居表状态。这三样东西放在一起八成的问题当场就能定位到是哪一层出了岔子。这个动作花不了两分钟但比我早期那种到处翻配置、凭感觉改参数的做法效率高太多了。
