自带 IP 源 ASN 与 RPKI

每个客户 CIDR 都携带一个源 ASN — 即互联网上的其他节点查找您的前缀时，AS-path 右侧最末尾的 ASN。两道关卡决定某个 (CIDR, ASN) 组合是否可以被宣告：平台层面的受支持 ASN 检查，以及 RPKI ROA 检查。

RPKI 验证关卡，在 CIDR 被接受前执行

源 ASN 的作用

源 ASN 是您前缀 AS-path 中的最后一个 ASN。它出现在 looking-glass 的输出中，是对等方导入策略的过滤依据，也是 RPKI 验证器进行比对的对象。选择源 ASN 是一项流量工程和身份标识决策：

• 如果您已经运营了一个 ASN，使用它可以使 AS-path 与您从该 ASN 宣告的其他内容保持一致。

• 如果您希望使用的 ASN 尚不在支持列表中，则无法选择它 — 平台只从已完成自动宣告上线的 ASN 进行宣告。

受支持 ASN 检查

选择 ASN 之前，请先确认其是否符合条件。Console 中列有当前支持自动宣告的源 ASN 列表。私有 ASN 范围会被拒绝；未启用该流程的 ASN 同样会被拒绝。

如果您的 ASN 不在列表中，这是需要首先解决的限制 — 可以改用已在支持列表中的 ASN，或通过 support 与 Zenlayer 合作将您的 ASN 加入支持列表。

RPKI 验证

RPKI 是第二道关卡，也是最容易出现意外的一关。在前缀被接受之前，Zenlayer 会针对您提交的 (CIDR, 源 ASN) 组合评估您的 ROA。验证结果必须为 Valid — NotFound 和 Invalid 均会阻止创建。

ROA 验证失败的常见原因：

原因	表现	修复方法
不存在 ROA	验证返回 NotFound	通过您的 RIR 发布覆盖该前缀和 ASN 的 ROA
ROA 中的 ASN 错误	验证返回 Invalid，且显示不同的源	发布或更新 ROA，以授权您希望使用的 ASN
maxLength 过短	存在有效的 ROA，但不覆盖您尝试宣告的具体前缀长度	将 maxLength 调整为 ≥ 前缀长度
ROA 已过期	验证在原本正确的 ROA 上返回 Invalid	通过您的 RIR 续期 ROA

发布新的 ROA 后，其在 RPKI 存储库中的传播时间为数分钟到数小时不等，具体取决于您的 RIR。确认新 ROA 已在公共验证器上可见后，再提交创建请求。

更新源 ASN

您可以更改已被接受的 CIDR 的源 ASN。规则与创建时相同：

1. 新 ASN 必须在支持列表中。

2. 必须存在授权 (CIDR, 新 ASN) 组合的有效 ROA。

3. CIDR 必须已在宣告系统中。

操作顺序至关重要：

1. 首先发布（或更新）针对新 ASN 的 ROA。

2. 等待 RPKI 传播。

3. 提交 ASN 变更请求。

如果操作顺序颠倒 — 先提交更新，再发布 ROA — 验证将失败，更新请求会被拒绝。更新期间，现有分配不受影响；变更只影响前缀的宣告方式。

---

常见问题

可以使用私有 ASN 吗？ 不可以。平台会验证源 ASN 值，私有 ASN 范围会被拒绝。

Zenlayer 可以告知我哪些 ASN 可用吗？ 可以。Console 中显示了当前支持自动宣告的源 ASN 列表。请从该列表中选择。

RPKI 是否只在创建时检查？ 不是。初次创建和源 ASN 更新都会重新运行 RPKI 检查。进入宣告系统没有任何可以跳过该检查的路径。

如果 ROA 在 CIDR 活跃后过期，宣告会停止吗？ 从 Zenlayer 侧看不会 — 前缀将继续被宣告。但执行 RPKI 的下游网络会在 ROA 变为 Invalid 后丢弃该路由，因此实际可达性会下降。请在 ROA 过期前提前续期。