在日常的 BGP 运维中，常见的问题之一是明明已经对外宣告了前缀，却发现上游或其他对等体并未接受或转发该路由。这种情况往往导致流量无法正常到达，影响服务稳定性。本文将从三个角度切入，帮助网路工程师系统性排查此问题：ROA（Route Origin Authorization）验证、IRR（Internet Routing Registry）资料缺失，以及上游过滤策略（max-prefix 与社群标签控制）。
一、ROA 验证：RPKI 是前缀生效的基石
RPKI（Resource Public Key Infrastructure）是目前主流的路由安全机制，透过数位签章验证宣告前缀的合法性。ROA 是 RPKI 的核心文件，定义了哪些 AS 可以宣告特定的 IP 前缀。
若前缀已宣告，但对方路由器启用了 RPKI 验证，且没有对应的有效 ROA，该路由将被标记为 Invalid，甚至被直接丢弃。这是导致前缀「宣告了但没生效」的常见原因。
检查要点：
- 确认你的 IP 前缀是否已在 RPKI 系统中建立有效 ROA，且 AS 号码正确。
- 利用公开工具（如
rpki-validator或各大路由器的 RPKI 状态命令）查看路由的 RPKI 状态，确保不是因 Invalid 而被过滤。 - 注意 ROA 的最大长度（MaxLength）设定是否允许你宣告的子前缀。
二、IRR 对象缺失：路由过滤的隐形陷阱
IRR 是另一种路由政策管理工具，许多 ISP 使用 IRR 来建立路由过滤清单（prefix-lists、route-maps）。如果你的前缀没有在 IRR 中正确注册，或者对应的 AS 对象缺失，可能导致上游过滤器拒绝接受你的路由。
例如，一个典型的过滤策略会先查询 IRR 中是否存在你的前缀和 AS-PATH 的对应关系，若无匹配，则不接受该路由。
检查要点：
- 确保你的 IP 前缀和 AS 对象已在 IRR 注册，且资料完整正确。
- 使用
whois查询 IRR 记录，检查是否存在route或route6对象对应你的前缀。 - 若上游使用 IRR 过滤，请与对方确认过滤策略，并依需求更新 IRR 记录。
三、上游过滤策略：max-prefix 与社群标签控制
除了验证机制外，上游 ISP 常会设定 max-prefix 限制，防止意外或攻击导致大量路由宣告，影响网路稳定。若你的 BGP session 宣告的前缀数量超过该限制，路由会被拒绝或 session 被重置。
此外，社群标签（BGP Community）也是常见的流量控制工具。透过特定社群标签，上游可能会对路由进行策略调整，如过滤特定前缀或调整优先权。
检查要点：
- 确认与上游的 max-prefix 设定，确保你的前缀数量未超过限制。
- 检查 BGP session 的状态，是否有因超过 max-prefix 而被断线的纪录。
- 了解并核对是否有社群标签被上游用于过滤或优先权控制，尤其是自动化过滤策略。
结论与检查清单
面对「前缀宣告了但没生效」的问题，系统化的三重检查能有效缩短排查时间：
- ROA 验证：确认 ROA 是否存在且有效，避免 RPKI 验证失败。
- IRR 注册：确保 IRR 中有正确的前缀与 AS 对象，符合对方的过滤策略。
- 上游过滤：检视 max-prefix 设定与社群标签的影响，避免因策略限制导致路由被拒。
建议网路工程师定期检查并同步更新 RPKI 与 IRR 资料，与上游维持良好沟通，确保前缀能顺利生效，保障网路服务的稳定与安全。
本文由 南方数据技术博客编辑整理，涉及具体环境时请以官方文档与实际配置为准。