干网络这个行当几乎每天都在跟“路由表”打交道。上联业务不通、两个机房互访失败、设备重启后流量直接沉默大多数人第一反应都是登录设备敲命令看看路由表里有没有那条路由。但真被问一句“你看的到底是协议路由表、核心路由表还是FIB转发表”很多干了两三年的兄弟也容易卡壳。RIB、FIB、协议路由表、核心路由表这四样东西名字看着像职责其实完全不同搞混了轻则排查半天白费劲重则判断错方向把链路问题当成路由问题处理。这篇文章就把这几个概念彻底拆开用实际排障的场景讲清楚谁生成谁、谁优先谁、转发时到底查哪张表。无论你是刚入门网络的新人还是被路由问题折磨过的运维老兵把这条控制面到转发面的链路理顺再遇到“路由表里有路由但业务不通”这类玄学问题基本都能稳准狠地定位到根因。1. 先理清体系四张表的角色分工与数据流向1.1 协议路由表、核心路由表、RIB、FIB之间到底是什么关系很多人被这四个词绕晕是因为把它们当成四张并列的表。实际上它们是一条流水线上的四个工位。数据包要到达目的地路由系统内部先要完成一次“信息汇聚”OSPF、BGP、IS-IS、静态路由、直连路由都在各自维护自己的协议路由表每个协议把自己认为最优的路径提交上来系统把这些候选路由收齐后通过选路规则裁决出一个最终版本放进核心路由表核心路由表再被压缩、整理成适合转发引擎快速查询的形态也就是FIBFIB最终下发到转发芯片或软件转发进程里成为数据包真正要查的清单。RIB是Routing Information Base即路由信息库更偏控制面概念本质上是系统维护的“全部有效路由集合”核心路由表就是最常见的RIB形态。FIB是Forwarding Information Base即转发信息库更偏数据面概念是转发时实际查的表。协议路由表则更“基层”是每个路由协议自己算出来的结果还没经过全局裁决。要理解这条路可以记一句话协议路由表是投票核心路由表是计票结果RIB是结果存档FIB是给执行人员看的操作指令。1.2 协议路由表和核心路由表控制平面的分工逻辑协议路由表是分散的。OSPF进程会维护一张OSPF路由表里面是SPF算法算出来的OSPF域内、域间路由BGP会维护一张BGP路由表里面是从各个对等体学到的前缀和属性静态路由则是管理员手工配置的一组条目。这张表是协议自己视角里的世界只认自己的算法和度量值不关心别的协议怎么想。协议路由表并不直接用于转发。它们只是“候选池”各协议从中挑出自己最好的路由提交给系统级的核心路由表。核心路由表就像是各协议代表开完会之后的最终决议每个目的网段最终只能留下一条最优路由或者少数几条等价路由。如果OSPF和BGP同时提交了同一条路由系统必须有一个裁决机制来决定谁赢这就是后文要讲的路由优先级。核心路由表里装的是系统全局最优的路由条目每个条目至少包含目的网段、掩码、协议来源、优先级、度量值、下一跳和出接口。日常敲命令查看的“IP路由表”绝大多数情况下指的就是这张核心路由表。1.3 RIB与FIB控制面和转发面的分界线RIB和FIB的分工本质上就是控制面和数据面的分界。RIB负责“想清楚怎么走”包含的是路由的全部属性协议来源、优先级、度量值、可能存在的备份路径、路由标签等FIB只负责“照着走”保存的是转发的必要信息目的前缀、掩码、下一跳、出接口以及转发方式。为什么不能直接用RIB转发最直接的原因是性能。RIB的查询逻辑复杂条目里带着一堆协议属性数据结构适合增删改查但不适合每来一个数据包就做一次完整匹配。FIB经过专门设计用前缀树、哈希桶、TCAM等结构把这些信息组织起来保证硬件可以在纳秒级完成最长前缀匹配。把两者分开还有个工程上的好处路由协议震荡、OSPF重新收敛、BGP路由频繁更新时控制面可以慢慢算不影响已经在转发表的稳定条目继续工作。只有最终选路结果变化了才需要更新FIB。这也是设备能保证转发不中断的关键。提示很多设备的“路由表”命令查出来是RIB而转发芯片真正查的是FIB。两者概念混淆是“路由表有路由但流量不通”这类问题最容易被忽略的起点。2. 从协议路由表到核心路由表选路裁决的核心机制2.1 路由优先级跨协议选路的第一刀不同协议提交了同一条路由怎么裁决靠路由优先级也叫管理距离。所有厂商的主流设备都遵循同一个规则数值越小优先级越高路由越优。不同厂商的默认数值体系有差异但典型含义一致直连路由一定优先静态路由通常高于动态路由动态路由内部按协议特性再分高低。举个例子“某厂商的默认值是直连路由0、静态路由60、OSPF 110、BGP 200”、“另一套常见体系是直连0、静态1、OSPF 10、BGP 20”数值不同但判决结果基本一致。如果OSPF和BGP同时学到10.1.1.0/24系统会选优先级数值更小的那个协议提交的路由进入核心路由表。这里用生活类比理解协议路由表就像几个不同外卖平台各自推荐的商家每个平台都有自己的打分体系。路由优先级相当于平台外的总评判标准——不看你的打分规则先看平台等级等级高的平台推荐的候选直接晋级。为什么必须有这么一刀因为各协议的度量值根本不可比。OSPF的cost是接口开销累计BGP的metric可能是AS路径长度或者MED属性静态路由甚至没有度量值。没有统一度量单位就必须有一个管理层单独用优先级做裁判。2.2 同协议内比度量值先内部选拔再对外提交跨协议看优先级同一协议内部就看度量值。每个协议有自己的度量算法OSPF根据接口带宽计算cost开销越小越优RIP看跳数BGP主要看AS路径长度路径越短越优必要时再参考MED等扩展属性。这个内部选拔发生在协议自己的路由表里。OSPF在区域内算出到达某个网段的多个路径后先选cost最小的放进OSPF路由表BGP从多个对等体收到同一前缀后先按选路规则选出一条最优路径放进BGP路由表。协议表只提交内部最优结果给核心路由表不会把一堆备选全交上去。实际操作中这个逻辑有个影响如果你想让某个协议的某条路由被核心路由表选中不仅要保证它在该协议内部最优还要保证该协议在所有协议里优先级够高。两极都要赢缺一不可。2.3 路由迭代与递归下一跳BGP路由生效的关键障碍核心路由表还有个隐藏要求每一条被接受的路由下一跳必须能被解析为直连可达的“出接口下一跳”。可BGP路由的下一跳经常是远端对等体的IP并不直连。这时候系统必须做一次递归解析先查BGP路由表发现下一跳是10.0.1.1但10.0.1.1不在直连网段于是再查IGP路由表或核心路由表看怎么到达10.0.1.1最终翻译成直连的出接口和实际下一跳。这个翻译过程就是路由迭代也叫递归路由。问题就出在递归失败上BGP对等体状态正常、BGP路由表里明明有这条前缀但核心路由表里死活不出现该路由或者出现了但状态异常。最常见的根因是BGP路由的下一跳没有被IGP宣告或者IGP路由不稳定被撤回导致递归缺少中间跳支持。排查这类问题时不要只盯BGP表。要先确认BGP路由的下一跳IP再检查核心路由表里到该下一跳的路由是否存在且有效。两个条件都满足BGP路由才能正常挂载并生成转发条目。这也是BGPIGP联动排障里最需要盯住的环节。注意配置静态路由时也有类似的递归问题。静态路由下一跳如果写入了一个不存在的、不可达的IP这条静态路由可能存在于路由表中但始终无法被下发到FIB参与转发。3. 从核心路由表到FIB数据面转发的实现细节3.1 核心路由表如何压缩成FIB条目核心路由表里的条目带着协议属性、优先级、度量值这些信息对转发没有直接帮助。FIB要做的事情是“瘦身”丢掉协议来源、丢掉优先级权重、丢掉度量值只保留目的网段、掩码、下一跳、出接口以及转发方式。这个压缩过程不是简单的复制删减而是重新组织数据结构。软件转发设备上FIB常组织成前缀树或者多级哈希桶结构保证查询时间可控硬件转发设备上FIB条目要写入ASIC关联的TCAM表项TCAM天然支持并行匹配可以同时比对所有条目。TCAM资源有限所以FIB条目还要考虑表项合并、资源统计、是否用默认路由兜底等因素。我见过不少设备上核心路由表只有几百条但FIB表项数却远高于路由条数就是因为路由迭代和等价路由拆分会在FIB生成多个实际转发条目。看表项数量不能只看路由表。3.2 最长前缀匹配FIB查询的第一原则数据包到达转发引擎后FIB要确定它匹配哪一条转发条目。规则只有一个最长前缀匹配。FIB里同时存在10.1.1.0/24和10.1.1.1/32两条条目来一个目的地址是10.1.1.1的包系统必须匹配更长的/32条目因为它更精确。这个原则容易理解但工程实现上有个隐藏技巧在TCAM表里前缀长度长的条目通常排位更靠前在软件前缀树里查询路径本身就是按位伸展的天然支持最长匹配。理解这一点对配置排障有意义——某些特殊场景下调试工具会告诉你匹配到了哪条具体条目如果你发现匹配的是比预期更短或更长的条目就需要检查是不是前缀规划有问题。3.3 ECMP等价路由一条逻辑路由、多条物理路径FIB里还有一种常见情况核心路由表里同一个目的网段存在多条完全等优的路由系统把它们合并为等价路由。逻辑上核心路由表只有一条记录但实际转发时可能走链路A也可能走链路B取决于哈希计算结果。FIB对等价路由的实现方式因设备而异但常见做法是把等价路由的多个下一跳都放进转发条目里转发时根据数据包的哈希因子选一个。哈希因子通常包含IP五元组至少包含源目IP地址。这意味着五元组相同的流量会稳定走同一条物理链路而不是每包轮询。这也解释了为什么等价路由链路利用率会出现不均衡如果流量里大流量连接数量少、HASH分布又不均匀某些链路的利用率可能长期偏高另一条长期空闲。这不一定是有路由故障而是哈希分布特性。排查带宽问题时看到ECMP拓扑必须考虑哈希均衡问题。3.4 软件FIB与硬件FIB两套表怎么协同很多中高端设备上FIB其实有两套一套在路由引擎的软件转发面负责控制和管理另一套在接口板/线卡上的硬件转发表负责真正的数据包转发。路由计算单元把核心路由表生成FIB后需要把硬件表项下发到各接口板的转发芯片上。两套表之间存在下发延迟和资源差异。硬件表项空间有限TCAM容量紧张时部分路由可能只在软件FIB里有条目硬件FIB里却没有导致流量要么被送到CPU处理要么直接被丢弃。某些设备上人眼看“路由表有、FIB也有”但硬件资源统计里已经出现表项溢出告警这类问题就得靠监控资源占用才能发现。这也是为什么大型网络里路由前缀规划必须考虑表项规模默认路由汇总、精确聚合、控制BGP路由条目数量很大程度上就是为了让硬件FIB别被塞爆。提示检查设备状态时不仅要看“路由条目是否存在于FIB”还要看“硬件转发表项是否成功下发”。两者之间任何一个环节断掉表象都是路由不通。4. 实操查证如何分别查看路由表与FIB并判断问题环节4.1 查看协议路由表和核心路由表的命令套路主流设备查看核心路由表的命令虽然名词有差异但形式基本是“display ip routing-table”或“show ip route”这一类的变体。输出里最关键的信息是Destination/Mask、Protocol、Preference/Administrative Distance、Metric、NextHop、Interface。每次看到一条路由先回答四个问题这条路由是谁学来的优先级多少下一跳是谁出接口是哪个如果只想看某一条具体路由可以加目的地址参数精确查看该网段的选路结果。这样能快速判断目的网段是否在核心路由表中、协议来源是否正常。查看协议路由表则要进入协议视图。OSPF相关命令通常能查到OSPF的数据库和OSPF路由表BGP相关命令能查到BGP路由表及路径属性。这些协议路由表是“第一现场”能看到核心路由表看不到的备选路径被拒绝的原因。4.2 确认FIB表项是否正常存在查看FIB的命令在主流设备上也常见比如“display fib”或“show ip cef”这类形式。FIB输出比路由表更精简通常只包含前缀、下一跳、出接口、转发类型。如果核心路由表里有某条路由FIB里却没有问题就出在RIB到FIB的下发环节。在一些支持硬件转发的设备上还可以继续查看硬件转发表项细节确认条目是否真正写入了TCAM或转发芯片。关注点包括条目类型是硬件转发还是软件转发、资源计数器是否异常、表项是否被其他策略过滤。某些情况下还要看硬件表项的老化状态比如等价路由成员变化后旧硬件条目是否还在占用资源。4.3 现场案例双上联切换时观察四张表的变化我用一个常见的双出口场景演示查证步骤。假设设备有两条上联链路分别接到两台路由器对应两个不同下一跳同时运行静态协议做默认路由。业务要求正常情况下流量走主链路主链路故障后切到备链路。第一步查看协议路由表确认两条静态默认路由都存在于协议层。第二步查看核心路由表看主用静态路由优先级是否更优、状态是否正常。第三步查看FIB确认主用下一跳已生成转发条目。第四步模拟主链路故障比如断开主链路接口。此时再查协议路由表静态路由可能因下一跳不可达而消失或失效查核心路由表应当看到备链路路由接管查FIB应当看到转发条目已切换。这个流程里最容易踩的坑是只看核心路由表以为“有路由就正常”结果FIB没刷新流量照样断着。养成同时看两张表的习惯排障效率会高很多。5. 常见问题排查与避坑经验5.1 路由表里有路由FIB里却没有表项现象最典型也最容易被误判为“设备转发异常”。先别急着重启或换设备按顺序检查三件事第一查看路由状态确认它是否被标记为无效或不可达如果下一跳递归失败路由虽然在RIB里但不会被FIB接受第二查看FIB下发日志或资源状态确认是否存在下发失败或TCAM空间不足第三确认是否存在策略或过滤规则某些设备支持对RIB到FIB的条目做过滤配置不当会拦掉正常路由。5.2 静态路由下一跳不可达导致路由“假活”手动配置静态路由时下一跳地址写错了或者指向了一个需要递归才能到达但对端不存在的主机地址。核心路由表里能看到这条静态路由但它始终处于无效状态FIB里不会生成对应转发条目。很多新手看到“路由表里有”就以为配置没问题实际上一查协议状态全是“invalid”。解决办法有两条一是确保静态路由的下一跳真实可达如果下一跳需要在另一个网段要保证递归路径存在二是尽量写成“出接口下一跳”同时指定这样依赖递归的概率会降低。配置任何一条静态路由后都应该回查核心路由表状态列确认它是正常“active”状态再继续。5.3 等价路由下哈希不均导致单链路拥塞ECMP场景里路由表显示两条等价路由状态正常但监控发现一条链路利用率90%另一条只有10%。这不是路由故障而是哈希分布问题。解决思路有几种调整哈希因子的组合方式增加哈希扰动检查是否因为大流量连接数太少导致分布偏斜对于专线负载场景可以考虑调整等价路由权重如果设备支持加权ECMP让流量按比例分担。排查时先确认流量确实走了ECMP桶再分析流量的连接特征。如果大多是长连接大流量哈希不均非常正常不要轻易怀疑链路质量。5.4 协议邻居正常但路由不优选的隐蔽原因OSPF邻居Full、BGP对等体Established但核心路由表里就是没有期望的路由或者选出来的是另一条备份路由。这通常是三类原因一是协议路由表内部选路失败可能因为区域设计问题导致路由没有进入该协议路由表二是路由被入方向或出方向的路由策略过滤三是管理距离配置被人为改动导致某协议的优先级失效。比如同时配置了OSPF和静态路由管理员希望OSPF为主。如果静态路由优先级被调得更优OSPF路由再正确也只能躺在协议路由表里。所以排查优先类问题一定要回看核心路由表的Protocol列和优先级数值而不是凭记忆判断谁该优先生效。5.5 转发表资源耗尽带来的隐性风险中大型网络最常见的长期隐患是硬件转发表资源逼近极限尤其是IPv4和IPv6双栈场景下ECMP条目和递归条目会成倍消耗TCAM。资源耗尽时最典型的表现是部分路由随机消失重启后恢复一阵又复发日志里可能出现“表项下发失败”一类提示。提前规划是唯一的解药严格控制BGP宣告的前缀数量能用聚合路由就不要放明细默认路由能兜底就不要每个网段都写满定期监控FIB使用率和硬件资源水位。等硬件表满了再排查影响面往往已经扩散到整网。把协议路由表、核心路由表、RIB、FIB这条链路彻底理顺之后再回来看网络排障会明显感觉“路由表有但业务不通”这类问题的探查路径清晰了很多。我现在的固定动作是先看接口状态和协议邻居再看协议路由表有没有学到接着看核心路由表有没有选中最后看FIB和硬件资源有没有成功下发。四个环节逐段确认绝大多数路由类故障都能在十分钟内定位到具体环节。这套思路不一定是最快的但一定是最不容易被表象带偏的。