BGP已收到路由但未装入内核路由表：RIB-Failure排查指南
先固定 VRF、AFI/SAFI、前缀和 peer，保存 BGP 邻居状态及该前缀的所有路径。确认路由是“收到但被策略拒绝”、已进入 BGP 表但非 best，还是 best 但显示 RIB-failure。检查入站 route-
本文目录（28 节）
直接答案
先固定 VRF、AFI/SAFI、前缀和 peer，保存 BGP 邻居状态及该前缀的所有路径。确认路由是“收到但被策略拒绝”、已进入 BGP 表但非 best，还是 best 但显示 RIB-failure。检查入站 route-
一、先定义“收到”出现在哪一层
设备可能展示邻居发来的原始路由、经过 inbound policy 后的 BGP 路径、Loc-RIB 选出的 best，或全局 RIB/FIB 中的最终路由。不同命令的“received”含义不同，且是否启用 soft-
记录所用命令、FRR 版本、VRF、地址族和 JSON 输出。不要用 IPv4 unicast 的结果推断 VPNv4、IPv6 或 EVPN 地址族。
二、确认邻居与地址族真正激活
邻居 Established 只说明 BGP TCP/FSM 建立。检查目标 AFI/SAFI 是否激活、收发前缀计数是否非零、是否出现通知或更新错误。一个邻居可以在 IPv4 正常、IPv6 未激活。
同时核对 peer-group 继承和 VRF 实例。配置写在默认 BGP 实例但邻居属于另一个 VRF 时，看似相同的地址不会作用到目标会话。
三、固定一个前缀追踪
选择一个已知受影响的精确前缀，记录 prefix length、来源 peer、path ID 与所有属性。避免先看汇总计数；几万条路由中只缺一条通常是策略或更具体的属性问题。
若问题是默认路由，也要明确是 0.0.0.0/0 或 ::/0，并检查是否由 network、redistribute、default-
四、检查入站过滤
prefix-list、access-list、AS-path list、community list 和 route-map 都可能拒绝路由。FRR 的策略通常有明确 permit/deny 与顺序；没有命中允许项时，结果可能是隐式拒绝。
导出目标邻居实际应用的 inbound policy，并用精确前缀和属性逐条匹配。修改后通过 route refresh 或受控 soft clear 重新评估，不要直接重置整个会话。
五、区分过滤与属性修改
route-map 不仅能 deny，也能 set local-
比较接收前后属性，并记录匹配的 route-map sequence。不要只搜索 deny 语句而忽略 set 动作。
六、确认路由进入BGP表
若前缀完全不在本地 BGP 表，问题仍在邻居通告、地址族或 inbound policy。若存在多条路径，查看 valid、best、internal/
命令输出符号会随版本或平台变化，优先读取结构化字段和官方说明，不要凭单个字符猜测。
七、检查NEXT_HOP可达性
BGP 路径要成为有效候选，下一跳必须能通过本地路由递归解析。iBGP 默认可能保留 eBGP 学到的下一跳，内部路由器若没有到该地址的 IGP/静态路由，路径会 invalid。
查询精确 next-hop 在相同 VRF 与地址族中的路由，并检查出接口状态、邻居解析和 scope。需要时在正确边界使用 next-hop-self，但不要无条件改写所有邻居。
八、排查递归解析环路
到 BGP next-hop 的路由若本身依赖当前待安装的 BGP 前缀，可能形成递归循环。隧道、策略路由和多 VRF 泄漏也会让解析落入错误表。
画出每一级递归：next-hop、选中路由、下一网关和接口，直到 connected。任何一步回到原前缀或错误 VRF 都需修复。
九、理解BGP最佳路径选择
同一前缀多条有效路径中，BGP 按实现定义的顺序比较 weight、LOCAL_PREF、本地产生、AS_PATH、origin、MED、eBGP/iBGP 等属性，并继续使用后续决胜条件。不能只看到较短 AS_PATH 就认定它应胜出。
使用 FRR 提供的 bestpath reason 或详细输出，保存所有候选属性。一次只调整一个属性，避免产生不可预测的全网选路变化。
十、MED与比较范围
MED 通常只在特定来源 AS 条件下比较，相关配置可改变行为。来自不同 AS 的两条路径即使 MED 数值不同，也未必在该步骤比较。
检查 peer 所属 AS、confederation 与 bestpath 相关全局选项。不要把 MED 当跨运营商的绝对优先级。
十一、路由反射与Originator属性
路由反射环境中，ORIGINATOR_ID、CLUSTER_LIST 和 iBGP 防环规则会影响路径接受与选择。cluster ID 配置冲突或路由被反射回 originator 时，路径可能被丢弃。
记录反射器路径和 cluster list。不要为了“让路由出现”关闭防环逻辑，应修复拓扑或标识配置。
十二、检查AS_PATH防环
收到的路径包含本地 AS 时通常会被拒绝，以防环路。allowas-in 等选项可改变此行为，但会增加环路风险。先确认路径为何包含本 AS：双归属、站点复用 ASN、路由泄漏或错误 prepend。
只有明确设计需要时才有限度允许，并配合最大次数、community 和前缀策略。不能作为通用修复。
十三、检查最大前缀与抑制状态
邻居超过 maximum-prefix 可能停止接收、发送 warning 或重置会话。路由聚合、dampening 或 graceful restart stale 状态也会改变路由可见性。
查看邻居日志、前缀计数阈值、restart timer 与抑制信息。不要在未评估内存和路由规模时无限提高最大前缀。
十四、解释RIB-Failure
BGP 选出 best 后，全局 RIB 仍可能选择另一协议的同前缀路由，例如 connected、static 或 IGP 路由拥有更优管理距离。此时 BGP 路径可以保留为 best，却未被选为实际 RIB 路由，常被标记为 RIB-failure。
查询主 RIB 的同一精确前缀，比较 protocol、distance、metric、nexthop 和 VRF。RIB-failure 不一定是软件故障，而可能是预期的协议优先级结果。
十五、不要混淆最长前缀与管理距离
最长前缀匹配用于实际转发时在不同 prefix length 中选择；管理距离用于同一前缀长度的候选路由。一个 /24 BGP 路由不会因为 /16 connected 距离更低而被同前缀竞争淘汰，转发时 /24 仍更具体。
排障时分别比较“相同前缀的 RIB 选择”和“目标 IP 的最长匹配”，避免错误调整距离。
十六、检查Zebra连接与状态
在 FRR 中，bgpd 通常通过 Zebra 将路由提交给 RIB 和内核。检查 daemon 是否都在运行、bgpd 与 zebra 的连接、ZAPI 错误、重启时间和配置加载状态。
若 BGP 表正常但所有新路由都不进 RIB，公共 Zebra 链路比单条策略更可疑。不要只重启 bgpd；先保存日志和 daemon 状态。
十七、确认VRF与内核Table
同一前缀可以存在于多个 VRF 和 Linux routing table。命令未指定 VRF 时可能查询默认表，从而误判“没安装”。记录 FRR VRF、接口绑定、table ID 和 namespace。
检查路由是否被安装到了预期表，规则是否将业务流量查向该表。跨 VRF 泄漏需要显式设计，不能靠默认路由偶然连通。
十八、检查内核拒绝与Netlink错误
Zebra 选中路由后，内核仍可能因网关不可达、接口不存在、无效 nexthop、资源限制、重复对象或权限错误拒绝。查看 Zebra 与内核日志中的 netlink 返回码。
不要手工用 ip route add 长期绕过 FRR。它只适合受控对照，最终配置必须由单一控制平面管理，否则重载后会漂移。
十九、ECMP与Multipath差异
BGP 可以选出多条等价路径，但 FRR、Zebra 和内核各有最大 multipath 数量与资格条件。只看到一条安装不一定是失败，可能是配置的 maximum-paths 或属性不完全等价。
比较所有候选的 nexthop、AS_PATH、MED 和 IGP metric，并检查内核 nexthop group。验证负载分担要基于流哈希，而不是期望每个包轮流走不同链路。
二十、策略路由会改变实际转发
即使主 FIB 已有正确 BGP 路由，Linux policy rules、源地址、fwmark 或 VRF 仍可能让数据包查询另一张表。用与业务相同的源、标记和接口执行路由查询。
因此“route get 成功”也必须带真实上下文。默认源地址的查询可能无法重现业务容器或 VRF 流量。
二十一、数据平面验证
选一个受控目的地址，检查内核 route lookup、邻居项、出接口和抓包。确认包实际从预期接口发出、下一跳回应，并检查返回路径。BGP 控制面正确不保证 ACL、MTU 或回程正常。
不要用 traceroute 一次失败就断定路由未安装；中间设备可能不回 TTL 超时报文。结合内核查路和接口计数。
二十二、安全变更与回滚
先保存 running config、路由表和邻居状态；在一个 peer 或单个前缀范围内调整；使用 route-map sequence 和 prefix-list 精确约束；软刷新；观察 best、RIB、FIB 和流量；再扩展变更。
修改 local-pref、distance、next-hop-self 或 multipath 都可能影响大量流量。必须准备回滚命令和带外访问，避免远程把管理路径切断。
二十三、常见错误
常见误区包括：把 Established 当作路由一定安装；查询错误 AFI/SAFI 或 VRF；只看 received-routes；忽略 inbound policy 的隐式 deny；看到 AS_PATH 短就认定 best；不查 next-hop；把 RIB-failure 当 daemon 崩溃；混淆最长前缀和管理距离；手工写内核路由掩盖 Zebra 问题；通过 reset 邻居代替软刷新。
另一个危险做法是为解决单前缀故障全局降低 BGP distance。它可能让大量 BGP 路由压过 IGP 或静态路由，造成更广泛中断。
二十四、修复后的验收清单
确认目标地址族激活；前缀经 inbound policy 接受；所有属性符合预期；next-hop 在正确 VRF 可递归；BGP best reason 可解释；主 RIB 同前缀竞争结果正确；bgpd 与 Zebra 连接正常；内核目标表包含预期路由；ECMP 数量符合设计；真实源地址的 route lookup 与数据包转发通过；回滚路径未受影响。
最后进行一次受控路由撤回与恢复，验证 BGP、RIB、FIB 和监控在收敛过程中一致更新。
FAQ
1. BGP表里有best为什么ip route看不到？
可能主 RIB 选择了同前缀更优距离的其他协议，或 Zebra/内核安装失败，也可能查询了错误 VRF/table。逐层检查而不是只看 best 标记。
2. RIB-failure是否代表BGP路由无效？
不一定。它常表示 BGP 已选 best，但全局 RIB 选择了同前缀的其他路由。查看主 RIB 的 protocol 和 distance 才能判断是否符合设计。
3. 下一跳ping得通为何路由仍invalid？
ping 可能走不同 VRF、源地址或策略表。检查 BGP 进程所在 VRF 对精确 next-hop 的递归解析和出接口。
4. 修改策略后必须重置BGP邻居吗？
通常可使用 route refresh 或适当的 soft clear 重新应用策略，避免硬重置带来的路由中断。先确认邻居能力和命令影响。
5. 可以降低BGP管理距离解决吗？
只有路由设计确实要求 BGP 胜出时才精确调整。全局降低 distance 会改变大量同前缀竞争，应先查清现有路由为何优先。
总结
“BGP 已收到但未装入内核”是一条多阶段控制链问题。可靠排查从特定 VRF、地址族和前缀开始，依次证明入站策略、BGP 有效路径、最佳路径、下一跳递归、全局 RIB 选择、Zebra 提交和内核 FIB 安装。区分 RIB-failure 的预期竞争结果与真正的 netlink 故障，再用真实源上下文验证数据平面，才能避免通过重置邻居或全局改距离制造新的路由事故。