ROA（Route Origin Authorization）是 RPKI 体系里声明“某前缀授权给某 ASN 发起”的签名对象。本文覆盖在 MyAPNIC 创建 ROA、maxLength 的取舍、用 Routinator 验证，以及两个最常见的翻车点。
ROA 解决什么问题
传统 BGP 只校验可达性，不校验“这个前缀是不是真的属于你”。路由劫持（无论是恶意还是配置错误）本质上就是别人以你的前缀发起 BGP 通告。ROA 是你作为资源持有者，用 RPKI 私钥签发的一条声明：前缀 X、前缀长度范围 L，授权给 ASN A 发起。下游的 RPKI 验证方（Routinator、GoRTR、FRR、Cisco/Juniper 的 RPKI cache 功能）拿到全球 ROA 数据后，对收到的 BGP 路由做 Origin Validation：Valid / Invalid / Unknown 三态。主流骨干网和大型 IXP 已普遍对 Invalid 路由执行过滤，所以配好 ROA 等于给劫持上了第一道闸。
注意两点边界：ROA 只验证起源 ASN，不验证路径；未签 ROA 的前缀是 Unknown，不会被过滤。所以 ROA 要覆盖你所有对外通告的前缀，否则反而制造 Unknown 盲区。
前置条件检查
创建 ROA 前确认三件事，缺一不可：
- 你在 MyAPNIC 账号下持有对应 IPv4/IPv6 前缀，且资源状态不是 reserved/hold。
- RPKI 密钥对（Key Pair）已生成并处于 active 状态。MyAPNIC → Resource Certificates → Key Pairs 里确认。若从未生成过，直接在页面生成即可，私钥由 APNIC 托管（hosted 模式），不需要自己跑 rtr-mgmt。
- 你清楚每个前缀实际由哪个 ASN 通告。多 homed 或有转售客户的场景尤其要逐条核对，这是后面 ASN 填错问题的根源。
机房侧（如我们在南方數據为客户做 BGP 托管时）通常会在交付时提供一份“前缀-ASN 通告对照表”，没有这份表的话，先在路由器上确认：show ip bgp summary 看每条 received route 的 origin AS，或 show ip bgp <prefix> 看最后一条 AS path 的末尾 ASN。
在 MyAPNIC 创建 ROA 的步骤
- 登录 MyAPNIC，进入 Resource Certificates → Route Origin Authorizations。
- 点击 Create ROA，选择资源类型（IPv4 或 IPv6）。
- 在 Prefix 栏填入要保护的前缀，如
203.0.113.0/24或2001:db8:100::/48。注意填的是你持有的精确前缀，不能填聚合之外的更短前缀。 - Origin ASN 填实际对外通告该前缀的 ASN，如
64512。多个 ASN 通告同一前缀（如双 provider）就创建多条 ROA，每条一个 ASN。 - Max Length 按下一节的规则填写，不确定就先留空（等于 maxLength = prefix length）。
- 提交后对象进入签名队列，通常几分钟内发布到 APNIC 的 RPKI repository。可在同一页面看到 ROA 状态变为 published。
修改和删除也在同一页面操作。变更后同样需要等待发布同步，验证侧的缓存刷新周期默认约 10 分钟（Routinator 默认 refresh interval）。
maxLength 怎么填
maxLength 定义“这条 ROA 允许通告的最长前缀长度”。填得越宽，攻击者可劫持的粒度越细，同时你自己误配更具体前缀时反而会被自己的 ROA 判成 Invalid。原则：能不填就不填，需要填就按实际通告的最长前缀填。
| 场景 | 建议填法 | 理由 |
|---|---|---|
| 只通告 /24，无子拆分 | 留空（= /24） | 最严格，任何更长前缀的通告都是 Invalid |
| /22 但内部拆成 /24 通告给不同 peer | maxLength = /24 | 覆盖实际通告粒度，/25 及更长仍被过滤 |
| IPv6 /48 给下游客户拆 /64 通告 | 按客户实际最长前缀，通常 /64 | 不要图省事填 /128 |
| 不确定 | 先留空，跑通后再按需放宽 | 宁可先严后松，不要先松后紧 |
一个经典误区：填了 /22 的 ROA 但 maxLength 留空，然后业务侧把 /24 通告出去——这条 /24 会变成 Invalid 被下游过滤，流量黑洞。反过来，把 maxLength 填到 /32（IPv4）或 /128（IPv6）“图省事”，等于给劫持者开了从 /22 到 /32 的全部通告许可，ROA 的保护价值大打折扣。
用 Routinator 验证
验证分两层：先确认你的 ROA 已进入全球 RPKI 数据库，再确认实际 BGP 通告的验证状态。
第一步，在一台装好 Routinator 的机器上拉取并查询 VRP（Validated ROA Payload）：
routinator update routinator vrps --prefix 203.0.113.0/24 routinator vrps --asn 64512
输出中应看到你的前缀、origin ASN 和 maxLength。如果查不到，等 repository 同步，或检查 Routinator 的 TAL 配置（至少要有 APNIC 的 TA 证书，routinator vrps --select-as 64512 也可按 ASN 全量过滤）。
第二步，验证真实路由。以 Cisco IOS-XR 为例：
show bgp ipv4 unicast 203.0.113.0/24 detail # 关注 Origin validation state: Valid
Juniper 则看 show route 203.0.113.0/24 detail 中的 Validation state 字段。若你在自己的边界路由器上收到了来自第三方的、与你 ROA 冲突的路由，它会显示 Invalid——这正是 ROA 生效的证据。也可以用 routinator validate --asn 64512 --prefix 203.0.113.0/24 快速判断某条“ASN+前缀”组合是 Valid 还是 Invalid。
常见错误：ASN 填错与前缀过宽
ASN 填错是最高频事故。典型场景：前缀由你的上游（如南方數據这类提供 BGP 通告服务的 IDC）代为通告，origin ASN 应填上游的 ASN 而不是你自己的；或者双 provider 场景只给一家建了 ROA，另一家的通告被下游判成 Invalid，导致单边断流。排查方法：在每台出口路由器上跑 show ip bgp <prefix> 确认实际 origin，逐条对齐 ROA。修复方式是补建缺失的 ROA，而不是删掉现有的。
前缀过宽指 ROA 声明的前缀比实际通告的更短（更聚合），且没配 maxLength。例如持有 /22 只建了 /22 的 ROA，实际却通告 /24——下游会判 Invalid。反过来“ROA 前缀比通告的更长”是允许的（更聚合的 ROA 覆盖更具体的通告），但前提是 maxLength 放得开。排查口诀：每一条实际对外通告的前缀，都必须能被某条 ROA 覆盖为 Valid。用 routinator vrps --output-format json | jq 导出全量 VRP，与你的 BGP export policy 做一次 diff，是上线前最有效的自查手段。
另外提醒：ROA 变更不是即时生效的，repository 发布 + 验证方缓存刷新有 10-30 分钟延迟，变更后别急着下结论。
常见问题
ROA 和 IRR 的 route/route6 对象是什么关系？
两者是独立机制。IRR 对象供传统过滤（很多 IXP 和 peer 仍在用），RPKI ROA 供 Origin Validation。建议两者都维护且保持一致，只配 IRR 不配 ROA，在执行严格 RPKI 过滤的网络里你的前缀就是 Unknown，保护缺位。
ROA 配错了导致流量被过滤，怎么快速回滚？
在 MyAPNIC 删除或修正错误 ROA 后，等待 repository 发布和验证方缓存刷新（默认约 10 分钟，最长可到 30 分钟以上）。如果下游执行的是 strict 模式过滤，恢复时间取决于对方缓存刷新周期，可主动联系对端手动触发 cache refresh。
我需要自己跑 RPKI 验证服务器吗？
作为被保护方不是必须的，但强烈建议至少跑一个 Routinator 用于自查（一台小虚机即可）。作为提供 transit 的 ISP 则应该跑，并通过 RTR 协议向客户路由器分发验证结果，这也是南方數據对 BGP 托管客户的标准交付项之一。