BGP本地有路由但未通告给邻居：Adj-RIB-Out、策略与Community排查指南

发布于 2026-08-26 · routecfg.com 编辑部

设备本地路由表能看到前缀，BGP 会话也是 Established，但对端始终收不到路由，这是典型的“路由存在不等于路由可通告”。BGP 会先选择本地可用路径，再按目标邻居、地址族和策略生成 Adj-RIB-Out。出站 route-map、prefix-list、AFI/SAFI 未激活、community、iBGP 传播规则、聚合以及下一跳可达性都可能让某个前缀停在通告链路中间。

本文目录（29 节）

先固定前缀、邻居和地址族

记录问题前缀、邻居地址、local/remote AS、VRF、AFI/SAFI、会话类型（iBGP/eBGP）与期望传播方向。例如：

VRF=blue
AFI/SAFI=IPv4 unicast
PREFIX=203.0.113.0/24
PEER=192.0.2.2
SESSION=eBGP

“所有路由都没发”与“某个前缀没发”的路径不同。前者优先检查地址族与默认拒绝策略，后者优先检查前缀状态、属性和精确策略命中。

区分内核RIB、BGP Loc-RIB与Adj-RIB-Out

RFC 4271 将路由信息分为 Adj-RIB-In、Loc-RIB 和 Adj-RIB-Out。内核或 Zebra 中存在静态/OSPF 路由，不代表 BGP 已起源该前缀；BGP Loc-RIB 中存在路径，也不代表它已被某个邻居的出站策略接受。

在 FRRouting 中分别查看：

show ip route 203.0.113.0/24
show bgp ipv4 unicast 203.0.113.0/24
show bgp ipv4 unicast neighbors 192.0.2.2 advertised-routes

三个视图对应三个不同问题阶段，不能互相替代。

先确认路由真的进入BGP表

如果 show ip route 有前缀但 BGP 表没有，先检查起源方式：network、redistribute、aggregate 或其他协议导入。确认命令位于正确 VRF 和 address-family 下，前缀长度完全一致。

不要为了快速出现路由就开放 redistribute connected 或 redistribute static 的全部前缀。应使用明确 route-map/prefix-list 限制可起源范围，避免路由泄漏。

network声明与底层路由的关系

实现和配置模式通常要求与 network 声明精确匹配的路由存在于相应 RIB，才会起源。203.0.113.0/24 与主机路由或更具体前缀不是同一条匹配。

检查：

show running-config
show ip route 203.0.113.0/24
show bgp ipv4 unicast self-originate

不要通过创建指向错误接口的黑洞路由来伪造可达性。需要聚合/丢弃路由时应明确设计、监控并防止吸走真实流量。

路由必须是可通告候选

BGP 决策过程会选择用于 Loc-RIB 和后续通告的路径。若路径无效、下一跳不可解析或不是当前最佳路径，默认行为可能不会把它通告给邻居。

查看详细前缀输出中的 valid、best、next-hop、RIB failure 或策略状态。不要只看一行前缀存在。多路径转发也不意味着所有路径都会向每个邻居逐条通告。

检查下一跳可达性

RFC 4271 要求 Loc-RIB 路由的 NEXT_HOP 可解析。下一跳缺少 IGP 路由、递归解析进入错误 VRF、接口失效或地址族不一致，都可能让路径失去有效性。

从相同 VRF 查询下一跳的精确路由和递归链。不要用一个全局 ping 成功替代 VRF 内解析证据，也不要盲目设置 next-hop-self 来隐藏底层 IGP 缺口。

邻居是否激活了正确AFI/SAFI

TCP 会话 Established 只证明 BGP 传输连接存在。IPv4 unicast、IPv6 unicast、VPNv4、EVPN 等地址族需要在对应上下文协商和激活。

检查邻居的协商能力、每个 AFI/SAFI 的收发计数与配置位置。IPv4 路由不会因为 IPv6 会话正常就自动通告，错误 VRF 下的邻居也看不到目标 Loc-RIB。

从advertised-routes确认Adj-RIB-Out

FRR 支持查看特定邻居的 advertised-routes。若目标前缀不在其中，问题仍在本端通告决策；若已在其中，则继续检查 UPDATE 计数、线路抓包（经授权）和对端 Adj-RIB-In/策略。

输出最好使用 JSON 保存脱敏快照，便于前后对比。注意不同版本的命令和 route-refresh/soft-reconfiguration 能力可能不同，应以当前 FRR 文档为准。

出站route-map是首要检查点

查看邻居 address-family 下应用的 route-map out，以及每个 sequence 的 match/set 与命中计数。route-map 通常按顺序处理；未命中 permit 或显式 deny 都可能阻止前缀。

使用具体前缀做策略模拟或只读匹配测试。不要临时移除整个出站策略接入公网邻居；若必须验证，先在隔离会话、实验 VRF 或维护窗口使用仅允许单个测试前缀的最小策略。

prefix-list要检查精确长度

prefix-list 的 ge、le 和精确前缀语义容易误读。例如只 permit 一个聚合前缀，不一定允许其 more-specific。检查顺序号、隐式拒绝、IPv4/IPv6 列表类型以及 route-map 引用的实际名称。

同时确认配置已加载到运行实例，未被自动化系统随后覆盖。用 show 命令读取生效对象，不只查看 Git 中的模板。

RFC8212默认拒绝的影响

遵循 RFC 8212 的 eBGP 安全策略可能要求显式导入和导出策略；缺少策略时不交换路由。某些实现或配置 profile 的默认行为不同，升级后尤其容易出现会话 Established 但前缀为零。

检查邻居策略状态和日志，不要通过全允许 route-map 长期绕过。建立明确的客户、上游、对等体前缀和 AS 路径约束。

NO_ADVERTISE为何彻底阻止传播

RFC 1997 定义的 NO_ADVERTISE community 表示收到带该属性的路由后，不应向任何其他 BGP 邻居通告。如果路由经导入策略或上游继承了该 community，它可能在本地可用但不会进入目标 Adj-RIB-Out。

显示完整 community 列表和设置策略，追踪属性从哪里添加。不要全局删除所有 community；只在确认业务意图后对特定路由做变更。

NO_EXPORT的边界

NO_EXPORT 限制路由向本地联盟范围之外传播。它在 iBGP 内可能仍可见，但向外部邻居不通告，因此常表现为“内部有，公网没有”。

结合 AS、confederation 和邻居类型解释，不要把 NO_EXPORT 当成 NO_ADVERTISE。若该属性用于安全控制，移除前必须评估泄漏风险。

AS路径环路检查

向 eBGP 邻居通告时，策略和对端会检查 AS_PATH。若路径已包含对端 AS，对端可能拒绝；若本端策略引入自身 AS 或构造异常 AS_PATH，路径也可能不可用。

查看通告前后的 AS_PATH 与 route-map set 动作。不要用 allowas-in、as-override 或 replace-as 作为通用修复，这些功能有明确的 MPLS/VPN、迁移或特殊拓扑用途。

iBGP分割水平规则

RFC 4271 的基本行为是：从一个内部 BGP 邻居学到的路由，不再通告给其他普通内部邻居。大规模 iBGP 需要全互联、路由反射器或 confederation 等设计。

如果路由从 iBGP A 学到，却期望普通 iBGP B 收到，先检查拓扑角色，而不是增加出站 permit。缺少 route-reflector-client 关系时，策略放行也不会改变基本传播模型。

路由反射器的client与cluster检查

RFC 4456 定义路由反射以减少 iBGP 全互联。检查 RR 是否把目标邻居配置为 client、路由来自 client 还是 non-client、ORIGINATOR_ID 与 CLUSTER_LIST 是否触发环路防护，以及多 RR 的 cluster-id 是否按设计设置。

错误地把所有邻居设为 client 可能改变传播与环路边界。应以拓扑设计为依据逐项验证。

聚合可能替代明细前缀

启用 aggregate-address 与 summary-only 后，明细路由可能被抑制，只通告聚合。检查聚合条目、suppress-map、unsuppress-map 和实际 advertised-routes。

如果业务需要向某邻居同时发布聚合与部分明细，应显式设计并验证。不要仅关闭 summary-only，因为这可能突然泄露大量 more-specific。

默认路由需要专门配置

FRR 文档说明，默认不会仅因路由表中存在 0.0.0.0/0 就自动向邻居通告默认路由。可用 neighbor ... default-originate，并可由 route-map 控制起源条件。

默认路由影响面很大。应将上游可用性或特定探测路由作为条件，并测试撤销时是否及时 withdraw，不能永久无条件下发。

maximum-prefix不只是入站问题

对端可能因收到前缀数量超过限制而关闭会话或停止接收，导致本端看似通告、对端却无路由。检查双方会话通知、前缀计数与重置原因。

调整上限前先确认预期路由规模和泄漏保护，不要简单设置极大值。若是本端 accidental full table，应先修复导出策略。

策略修改后如何安全生效

更改出站策略后，应使用实现支持的 route refresh、soft clear 或相应命令重新评估邻居 Adj-RIB-Out。硬 clear 会中断会话并撤销全部路由，影响更大。

先确认版本与邻居能力，备份运行配置，选择单邻居、单地址族操作，并观察 UPDATE/withdraw 计数。不要在不知道命令语义时复制其他厂商语法。

通告有延迟不等于丢失

BGP 可能受最小通告间隔、决策过程和事件队列影响。策略变更后立即查询一次没有看到前缀，不足以证明失败。

记录时间、队列和 UPDATE 计数，在预期收敛窗口内持续观察。若路由反复添加/撤销，应先处理不稳定源和下一跳，而不是缩短所有定时器。

对端也要分Adj-RIB-In和Loc-RIB

本端 advertised-routes 有前缀，但对端主 BGP 表没有，可能是对端入站过滤、AS_PATH 环路、RPKI/策略拒绝或路由不可用。查看对端 received/filtered-routes 与日志，证明 UPDATE 是否到达。

“对端路由表没有”不能反推本端没通告。双方应使用同一前缀、时间和会话方向对齐证据。

抓包只在必要时使用

若两端控制面证据矛盾，可在授权维护窗口对 TCP/179 做限定接口、邻居和时长的抓包，确认 UPDATE 中是否含目标 NLRI。BGP 会话可能使用 TCP MD5/AO 或网络设备镜像限制，抓包也不一定能完整解析。

抓包文件可能包含完整路由和拓扑信息，应加密保存、限制访问并按期限删除。

修复后的验收清单

目标前缀在本端 advertised-routes 中出现；对端收到并按预期安装或保留；无额外前缀泄漏；NO_EXPORT/NO_ADVERTISE 等控制属性符合设计；主备路径切换与撤销能在目标时间内收敛；会话不发生 reset；重载配置后行为保持一致。

还要执行负向测试：一个不允许的前缀必须继续被拒绝。只有“该发的发出、不该发的仍不发”同时成立，策略修复才算通过。

常见错误

看到内核路由就认定 BGP 一定会起源。
只看会话 Established，不看 AFI/SAFI。
直接删除全部出站策略验证猜测。
忽略 NO_ADVERTISE/NO_EXPORT community。
期望普通 iBGP 邻居转发另一个 iBGP 邻居的路由。
用 clear bgp * 代替单邻居软刷新。
关闭聚合抑制而未评估明细泄漏。
只看对端 Loc-RIB，未检查 received/filtered。

FAQ

本地show ip route有前缀，为什么BGP表没有？

内核 RIB 与 BGP Loc-RIB 不同。检查 network 精确匹配、redistribute/route-map、VRF 和地址族，证明该路由已被 BGP 起源或学习。

advertised-routes里有，对端仍看不到怎么办？

检查 UPDATE 是否到达，以及对端 Adj-RIB-In、入站策略、AS_PATH、RPKI 和地址族。对端主表没有不代表本端未发送。

route-map最后没有permit会怎样？

未匹配允许项的路由通常会被拒绝，但具体需按实现与配置对象验证。应为允许和拒绝前缀建立显式测试，不要依赖模糊默认。

NO_EXPORT和NO_ADVERTISE有什么区别？

NO_ADVERTISE 禁止向任何其他 BGP 邻居通告；NO_EXPORT 限制向本地联盟边界之外通告。传播范围不同，不能互换。

为什么默认路由在表中却不通告？

FRR 通常需要针对邻居配置 default-originate；还可能受 route-map 条件控制。默认路由应结合上游可用性安全设计。

总结

BGP 本地有路由但不通告，必须沿 RIB 链逐级定位：底层路由进入 BGP、成为有效最佳路径、通过下一跳解析和地址族检查，再经邻居专属策略进入 Adj-RIB-Out。随后还要验证 community、iBGP/RR 传播、聚合与对端入站策略。通过正向目标前缀与负向禁止前缀双重验收，才能既恢复通告又避免路由泄漏。