随着 RPKI 路由源验证（ROV）在一二层运营商普及，AFRINIC 服务区域仍有百余个 IPv4 前缀处于 RPKI 无效状态，主要源于 ROA MaxLength 配置错误与跨 AS 宣告不匹配。本文记录一次针对性清理行动，通过主动告警与修正建议，推动区域网络修正配置，降低因无效前缀导致的路由泄露与转发异常风险。
问题背景与无效成因
RPKI 验证结果分为有效、NotFound 与无效三类（RFC 6811）。过去三年 ROV（RFC 7115）加速落地，大量一二层网络启用丢弃无效前缀策略。AFRINIC 区域内无效前缀主要来自两类场景：一是合法前缀被非持有 ASN 宣告，形成路由泄露（RFC 7908）；二是持有 ASN 自身宣告时，因 ROA 的 MaxLength 字段小于实际宣告前缀长度（如持有 /16 却宣告 /24，而 MaxLength 设为 16），导致更具体路由被 ROV 丢弃。此类错误多为“手误”、设计疏忽或对 ROA 语义理解不足。当时统计显示，区域内 IPv4 无效前缀略超 100 个，均涉及 AFRINIC 分配的 ASN 或前缀。
清理行动与修正策略
发起人逐一识别无效前缀，向相关网络运营商发送告警并给出修正建议：针对跨 AS 宣告，要求撤回错误路由或补齐 ROA；针对 MaxLength 不足，建议调整 ROA 使其覆盖实际宣告的最长前缀，或按业务需求拆分 ROA。行动同时提示运营商检查多上游场景下的差异化宣告策略——若主链路走 /24、备链路走 /16，而 ROA 仅允许 /16，主链路流量将被 ROV 过滤，导致路由选择退化为次优路径。
运维启示与持续治理
案例表明，单一配置疏漏即可引发区域级路由异常。运维侧需建立 ROA 与 BGP 宣告的一致性巡检机制：上线前校验 MaxLength 覆盖范围、变更后对比 ROA 与实际宣告、定期抽查 RPKI 验证状态。同时，上游启用 ROV 后，下游若未同步修正，将直接面临流量黑洞或绕行。原文未给出清理后的具体无效前缀数量变化，但该行动演示了“主动发现-精准告警-指导修正”在资源受限区域的可行性。
对网络工程师而言，核心启示是将 ROA 视作与 BGP 配置同等重要的运维对象：每次前缀长度变更、上游调整或多路径策略部署，必须同步审视 MaxLength 设置。在 ROV 成为主流过滤基线的当下，消除无效前缀不再是最佳实践，而是保障流量按预期路径转发的生存门槛。
原文: APNIC Blog（2021-07-26）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog