SKNK 中文技术指南
拿到 ASN 之后怎么上线？从资源登记到 BGP 可见的完整清单
ASN 获批只是开始。本文按实际顺序说明如何确认资源、准备上游、配置 IRR 与 ROA、建立 BGP Session、发布前缀并验证公网可达性。
技术内容
由 Shikanoko Networks 编写与维护
拿到 ASN 之后，网络不会自动出现在互联网路由表里。你还需要准备可宣告的 IP 前缀、能够接受客户 BGP 的上游、正确的 IRR 与 RPKI 记录，以及真正运行 BGP 的路由设备。完成这些工作后，才能把“数据库中的编号”变成一个可以从公网到达的网络。
下面按实际依赖关系梳理一套通用上线流程，不绑定具体云厂商或路由软件。
ASN 只是起点；前缀、授权、过滤和上游都准备好，路由才算真正进入互联网。
先确认交付给你的到底是什么
ASN、IP 地址和网络接入是三种不同的东西。常见的交付内容可能包括：
| 项目 | 作用 | 需要确认的问题 |
|---|---|---|
| 公共 ASN | 标识对外运行独立路由策略的网络 | ASN 是否已经登记到最终使用组织名下 |
| IPv6 或 IPv4 前缀 | 实际被 BGP 宣告的地址范围 | 是 PA、PI 还是上游地址，是否允许由你的 ASN 宣告 |
| Sponsoring LIR 关系 | 维持独立资源的合同和登记关系 | 年费、续费、退出及数据更新由谁处理 |
| LOA 或授权材料 | 向部分上游证明你有权使用资源 | 上游是否要求，谁可以出具 |
| IRR 与 RPKI 操作权限 | 让路由策略与来源授权可以被验证 | 由你、地址持有方还是 Sponsoring LIR 维护 |
只有 ASN、没有地址前缀，通常无法发布自己的服务网络；只有地址前缀、没有愿意接收客户 BGP 的上游，也无法把路由送入公网。
上线顺序为什么不能颠倒
一套稳妥的顺序是：
- 核对 ASN、前缀和登记主体；
- 确认上游支持客户 BGP；
- 写清准备发布的精确前缀；
- 建立 IRR
route或route6对象； - 创建或核对 ROA；
- 配置只允许预期前缀通过的路由策略；
- 与上游建立 BGP Session；
- 先验证接收路由，再发布自己的前缀；
- 从多个外部观察点检查可见性和可达性；
- 配置监控、告警和变更记录。
这样安排的原因很简单：一旦先把 BGP Session 建起来，却没有准备过滤策略和授权记录，错误前缀就可能被意外发布；如果只看到 Session 变成 Established 就宣布“上线完成”，也可能忽略上游过滤、RPKI 状态和回程路由问题。
第一步：核对登记信息
先在相应 RIR 的公开数据库中检查：
- ASN 对象是否存在；
- 组织名称和联系角色是否正确；
admin-c、tech-c、abuse-c是否指向可用的角色对象；- 维护者和资源管理关系是否符合实际；
- 地址前缀的登记对象是否存在；
- 公开信息中有没有旧邮箱、旧公司名或无效联系人。
公共数据库不是装饰。上游、同行、滥用处理人员和自动化过滤系统都可能依赖这些信息。错误联系人在平时不明显，遇到路由异常或滥用事件时却会直接拖慢处理。
第二步：确认上游真的支持客户 BGP
“服务器支持 BGP”不能只凭商品页面上一句话判断。下单前应向上游确认：
- 是否允许使用自有 ASN；
- 是否允许宣告自有或经授权的前缀；
- 支持 IPv4、IPv6 还是两者；
- BGP Session 使用公网地址、私网地址还是 IPv6 Link-local；
- 提供默认路由、部分路由还是完整路由表；
- 对前缀长度、数量和 RPKI 状态有什么限制；
- 是否依据 IRR 自动生成过滤器；
- 是否支持 BGP Community；
- 是否提供 BFD、Graceful Restart 或最大前缀限制；
- 建立 Session 前需要哪些授权材料。
如果上游只提供普通 VPS 网络，或者要求地址必须来自它自己的地址池，那么即使你已经有 ASN，也未必能在那里发布自己的前缀。
第三步：列出唯一允许发布的前缀
在写路由配置之前，先形成一份明确清单：
Origin ASN: AS64496
IPv6 prefix: 2001:db8:1200::/48
Maximum intended announcement: /48
Upstream A: AS64497
Upstream B: AS64498
这里使用的是文档示例编号，不能用于真实网络。
清单必须区分“持有的地址范围”和“计划在 BGP 中发布的路由”。例如，你可能管理一个 /48，内部划分出很多 /64，但对公网只发布聚合的 /48。不要因为内部有多个子网，就把大量 /64 全部送进全球路由表。
第四步：准备 IRR 路由对象
IRR 中的 route 或 route6 对象记录“哪个 ASN 计划起源哪个前缀”。IPv6 示例可以写成：
route6: 2001:db8:1200::/48
origin: AS64496
source: RIPE
真实对象还会包含维护者、联系信息和更新时间。具体由谁创建，取决于地址资源、维护者权限和 Sponsoring LIR 的操作边界。
许多运营商会根据 IRR 数据生成客户前缀过滤器。如果对象不存在、Origin ASN 不一致或对象位于上游不采信的 IRR，BGP Session 即使正常建立，前缀仍可能被上游拒绝。
IRR 记录表达的是公开路由意图，不是加密授权。它不能替代 ROA。
第五步：创建或核对 ROA
ROA 记录“哪个 ASN 被授权起源哪个前缀”，用于 RPKI Route Origin Validation。
上线前至少核对三个字段：
- Prefix 是否与实际地址范围一致；
- Origin ASN 是否是准备发布路由的 ASN；
maxLength是否符合真实发布计划。
如果准备只发布 /48，就没有必要为了方便把 maxLength 放宽到 /64。过宽的授权会扩大可被视为 Valid 的更具体路由范围。
需要注意：
- 存在匹配 ROA 且 Origin 和长度都符合时，路由通常是 Valid；
- 没有任何覆盖该路由的 ROA 时，通常是 NotFound；
- 存在覆盖 ROA，但 Origin 或长度不符合时，通常是 Invalid。
NotFound 不等于 Invalid，不同网络对两者的处理策略也可能不同。不能简单写成“没有 ROA 就一定被全球丢弃”，但在今天的新网络上线流程中，提前建立正确 ROA 已经是合理的基本操作。
对于 LIR 提供的 PA 前缀，RPKI 证书权限通常掌握在地址持有方。以 SKNK 管理的 PA 前缀为例，SKNK 负责按实际 Origin ASN 创建、维护和撤销 ROA，客户不能把这项权限理解为自己的 RIPE Portal 权限。
第六步：先写过滤策略，再建立 Session
新网络最危险的配置不是“路由没发出去”，而是“把不该发的路由发出去了”。
出口策略至少应做到：
- 默认拒绝；
- 只允许清单中的自有或获授权前缀；
- 限制前缀长度；
- 不把从一个上游学到的完整路由表转发给另一个上游；
- 不发布默认路由、私有地址、文档地址或其他保留范围；
- 为每个邻居设置合理的最大前缀数量。
入口策略至少应考虑：
- 只接受双方约定的路由类型；
- 设置最大前缀限制；
- 拒绝明显异常的 AS_PATH 和保留 ASN；
- 根据需要执行 RPKI Origin Validation；
- 明确默认路由、部分路由或全表的使用方式。
RFC 8212 提出的核心原则是：没有明确 Import 和 Export Policy 时，EBGP 默认不交换路由。即使所用软件没有采用这一默认行为，也应在配置中主动实现。
第七步：建立 BGP Session
双方通常需要交换：
- 本地 ASN 和对端 ASN；
- 本地与对端邻居地址；
- 地址族；
- Session 密钥（如双方使用）；
- 接收和发布的前缀范围；
- 最大前缀数量；
- BGP Community 说明；
- 维护窗口和故障联系人。
BGP 状态常见变化为：
Idle → Connect → OpenSent → OpenConfirm → Established
Established 只表示两端完成了 BGP 会话协商，可以交换 Update。它不表示：
- 你的前缀已被对端接受；
- 路由已传播到公网；
- RPKI 状态正确；
- 双向数据包可以到达；
- 多上游故障切换已经生效。
因此，Session 建立只是检查点，不是上线终点。
第八步：分阶段发布路由
第一次发布时，建议把变化控制在最小范围：
- 先确认从上游接收的路由符合约定；
- 检查入口最大前缀和默认路由；
- 确认本地只生成计划中的聚合前缀；
- 向一个上游发布；
- 检查上游是否接受；
- 从外部 Looking Glass 验证；
- 确认可达后再启用第二个上游；
- 最后测试故障切换和恢复。
不要在第一次操作时同时修改 ROA、IRR、两个上游和多个更具体前缀。变量越多，出现问题时越难判断是哪一层造成的。
第九步：同时检查路由可见和数据可达
至少从三个角度验收：
控制面
检查：
- 前缀是否出现在 RIPE RIS、RouteViews 或公开 Looking Glass；
- Origin ASN 是否正确；
- AS_PATH 是否符合预期；
- 是否从不同地区和不同上游可见；
- 路由是否稳定，有没有频繁 Withdraw 和重新发布。
路由安全
检查：
- RPKI 状态是否为 Valid；
- ROA 的 Prefix、Origin 和
maxLength是否准确； - IRR
route或route6是否存在； - 公开数据库联系人是否可用。
数据面
检查：
- 从多个外部网络 Ping 或 Traceroute 到前缀内的测试地址；
- 回程路径是否存在；
- 防火墙是否允许必要的 ICMPv6；
- MTU 和 Path MTU Discovery 是否正常；
- DNS、反向 DNS 和实际服务是否能访问。
“路由表里能看到”与“业务真的能访问”是两项不同的验收。
第十步：建立最低限度的持续监控
上线后至少监控：
| 监控项 | 需要发现的问题 |
|---|---|
| BGP Session 状态 | 邻居断开、反复重连 |
| 接收前缀数量 | 上游误发全表、路由数量突变 |
| 出口前缀数量 | 意外多发或漏发 |
| 外部路由可见性 | 某些地区或上游看不到路由 |
| RPKI 状态 | ROA 修改错误、Origin 或长度不匹配 |
| IRR 数据 | 上游变化后记录仍然陈旧 |
| 数据面探测 | 路由存在但服务不可达 |
| 配置与联系人 | 变更无记录、故障时找不到责任人 |
监控不能只盯着本地路由器。路由器认为自己已经发布，不代表外部网络实际接受。至少保留一个独立于本地网络的观察点。
常见故障怎么定位
Session 一直无法 Established
依次检查邻居地址可达性、TCP 179、防火墙、双方 ASN、地址族、密码和上游是否已经完成配置。
Session 正常，但上游收不到前缀
检查本地是否真的生成了该路由，出口过滤器是否允许，Next Hop 是否可达，以及前缀是否符合上游长度限制。
上游收到，但公网看不到
检查 IRR 过滤、ROA 状态、上游是否只接收但未对外发布，以及是否需要等待过滤器刷新。不要把所有问题都归因于“BGP 传播慢”。
公网能看到，但业务访问不了
检查回程路由、防火墙、ICMPv6、MTU、服务器地址配置和服务监听地址。BGP 解决的是前缀可达信息，不负责自动配置服务器。
一个上游故障后没有切换
检查另一个 Session 是否正常、两边是否都发布了同一聚合前缀、本地路由优先级和健康检测是否正确。双线路不等于自动具备经过验证的冗余。
一页式上线检查表
资源
- ASN 和地址登记正确
- 联系人和维护者有效
- 地址属性和迁移边界清楚
上游
- 明确支持客户 ASN 与自有前缀
- 邻居参数和路由策略书面确认
- 前缀长度、数量及 IRR 要求明确
路由安全
-
route或route6对象正确 - ROA 的 Prefix、Origin、
maxLength正确 - 对外状态不是 Invalid
BGP
- Import 和 Export 默认拒绝
- 只允许预期前缀
- 设置最大前缀限制
- Session 达到 Established
验收
- 多个外部观察点可见
- 双向数据面可达
- 故障切换经过测试
- 告警、联系人和变更记录就绪
小结
ASN 获批后，真正的工作是把资源、策略、上游和运维连接起来。正确顺序不是“先把 BGP 跑起来再说”，而是先核对资源和授权，再限制允许发布的内容，最后建立 Session 并从外部验证。
最终验收标准可以写成：
预期前缀由正确 ASN 发布，IRR 与 ROA 相互一致，多个外部网络既能看到路由，也能真正到达服务。
参考资料
- RIPE NCC：Autonomous System Number Assignment Policies（RIPE-679）
- RIPE Database：route6 对象说明
- RFC 8212：EBGP 默认拒绝路由
- RFC 7454：BGP Operations and Security
- RFC 4271：BGP-4