SKNK 中文技术指南
什么是 Multihoming?申请 ASN 前为什么要确认多上游
解释 Multihoming 如何通过多个外部网络提高韧性,RIPE ASN 申请为什么要求独立路由策略,以及双线路、双 Transit 和实际故障隔离的区别。
技术内容
由 Shikanoko Networks 编写与维护
Multihoming(多宿主)是让一个网络同时连接两个或更多外部网络,并通过统一的路由策略维持可达性。它的主要价值是减少对单一上游的依赖,而不是自动增加带宽或保证零中断。
在 RIPE NCC 的 ASN 分配政策中,网络需要具备 Multihoming,并提交自己的路由策略,才能申请公共 ASN。申请前写清上游关系不是形式工作,而是在证明这个网络确实需要独立的全局路由身份。

多上游的价值不在于线路数量,而在于一处故障发生后,另一条独立路径仍能维持可达。
什么样的网络算 Multihomed
一个典型结构是:
Transit A / AS64497
|
你的网络 / AS64496
|
Transit B / AS64498
你的网络向两个外部自治系统发布自己的前缀,也从两边接收约定的路由。当一个外部路径不可用时,另一条路径仍可能维持连接。
实际关系不一定都是两家付费 Transit,也可能是:
- 两家 Transit;
- 一家 Transit 加一个 IXP Peer;
- 多个地点分别连接不同上游;
- 一个原生上游加一个远程 Tunnel 上游;
- 两个云平台的 BGP 接入;
- Transit、Peering 和私有互联的组合。
是否满足 ASN 申请政策,要以真实外部路由关系、网络需求和 RIPE NCC 个案审核为准,不能只在申请表里写两个供应商名字。
Multihoming 和普通双宽带有什么区别
办公室装两条宽带,再用防火墙做主备,也能提高联网可靠性,但不一定属于全球 BGP 意义上的 Multihoming。
普通双宽带常见特点:
- 两家运营商分别提供自己的地址;
- 出口使用 NAT;
- 外部用户不能通过同一个自有前缀从两边到达;
- 切换后公网源地址可能改变;
- DNS、白名单和长连接可能受到影响;
- 不需要自己的公共 ASN。
BGP Multihoming 常见特点:
- 使用自己的公共 ASN;
- 使用可以由该 ASN 对外发布的前缀;
- 同一前缀可从多个外部网络到达;
- 通过路由策略控制主备和流量方向;
- 上游故障时,外部网络可以重新选择 AS_PATH。
两种方案都可能合理。是否需要 BGP Multihoming,取决于业务是否需要稳定的网络身份、入站可达和独立路由策略。
RIPE NCC 为什么要求 Multihoming
公共 ASN 会进入全球路由系统。为了减少不必要的 ASN 和路由复杂度,RIPE-679 规定:
- 只有在需要新的独立外部路由策略时才应使用新 ASN;
- 网络必须是 Multihomed;
- 申请时必须提供该自治系统的路由策略。
这也解释了为什么“我想要一个好看的 ASN”或“以后可能会用”不是合适的申请理由。
申请材料通常需要清楚表达:
- 网络在哪里运行;
- 计划连接哪些外部网络;
- 对方 ASN;
- 哪些关系已经确认,哪些仍在准备;
- 准备发布哪些前缀;
- 为什么现有上游 ASN 或私有 ASN 不能满足;
- 路由 Import 和 Export Policy。
提供虚构上游、借用他人 ASN 或夸大网络需求,不仅可能导致申请失败,也会给后续合规和运维留下问题。
Multihoming 真正解决什么
上游故障
当一个 Transit 的 BGP Session 或网络路径失效,路由可以从另一个上游继续传播。
商业依赖
网络不再完全受单一供应商的价格、政策、维护窗口和支持能力限制。
路径选择
不同目的网络可能通过不同上游获得更合适的路径。运营者可以按成本、容量、地区和关系设置策略。
迁移
使用独立资源时,可以先建立新上游,再逐步撤下旧上游,降低一次性切换风险。实际迁移仍需处理合同、IRR、ROA、过滤和设备配置。
Multihoming 不能自动解决什么
不能保证零中断
BGP 收敛需要时间,应用连接也可能在切换中中断。自己的路由器、电源、交换机和机房仍然可能故障。
不能自动增加单流带宽
一条 TCP 连接通常只经过选中的一条路径。两条 1 Gbps Transit 不会自动变成一条 2 Gbps 单流链路。
不能自动抵御 DDoS
攻击可能同时从多个上游进入,甚至让备用线路更快被打满。DDoS 需要容量、过滤、黑洞、清洗和应急流程。
不能自动获得更低延迟
如果没有合理策略,新增上游也可能带来绕路。性能必须通过测量验证。
不能替代内部冗余
如果两个上游都接入同一台路由器、同一交换机、同一电源或同一条楼宇光缆,任一共同故障点仍可让整个网络中断。
双线路不等于真冗余
评估 Multihoming 时,应沿着完整路径检查故障域:
| 层级 | 需要核对 |
|---|---|
| 上游公司 | 是否为真正不同的自治系统和运营主体 |
| 物理线路 | 是否共用同一管道、光缆或本地接入商 |
| 机房入口 | 是否从不同 Meet-me Room 或路径进入 |
| 路由设备 | 是否只有一台边界路由器 |
| 交换网络 | 是否共用同一交换机或 VLAN |
| 电源 | 是否共用 PDU、UPS 或供电线路 |
| 控制面 | 是否有独立 Session、过滤和最大前缀 |
| 地址资源 | 是否能从两边发布同一前缀 |
| 监控 | 是否能独立发现一边失效 |
合同上“两家供应商”不代表底层没有共同承载。远程 Peering 和 Tunnel 尤其需要确认底层路径。
常见部署方式
两家 Transit,单台路由器
优点是起步简单,可以降低上游单点。缺点是路由器、电源和机房仍然是单点。
两家 Transit,两台路由器
边界设备也实现冗余,但需要设计 IBGP、IGP、First-hop Redundancy、状态同步和故障切换。
Transit 加 IXP
Transit 提供全网可达,IXP Peering 提供特定网络的直接路径。它增加了路径多样性,但 IXP 通常不能代替第二家全网 Transit。
两个机房
可以减少站点级故障,但要解决:
- 两地之间的内部连接;
- 同一前缀从两地如何发布;
- 入站流量如何分配;
- 应用和数据是否真正跨站点可用;
- 一地失效时另一地是否有足够容量。
Tunnel Multihoming
两条 Tunnel 可以让实验网络快速连接不同上游,但必须确认底层是否独立。如果两条 Tunnel 都依赖同一个本地 ISP,最后一公里仍然是单点。
出站流量怎么选
出站流量由本地路由器根据收到的路由和本地策略决定。
常见方法:
- 用 Local Preference 设置主备;
- 对客户、Peer、Transit 采用不同优先级;
- 接收默认路由减少设备资源;
- 接收全表实现更细的目的地选路;
- 根据 Community 标记路由来源;
- 在容量不足时降低某一路径优先级。
出站策略相对容易控制,因为决策发生在自己的网络内。
入站流量怎么影响
入站流量由互联网其他网络决定,不能像出站一样直接控制。
常见影响方式包括:
- 向不同上游发布或不发布某些前缀;
- 使用上游定义的 BGP Community;
- 在特定上游执行 AS_PATH Prepend;
- 在合适场景发布更具体前缀;
- 调整多个地点的公告策略。
这些方法只是影响,不是命令。其他网络仍会按照自己的 Local Preference 和商业关系选路。
过度使用 AS_PATH Prepend 可能没有效果,也可能导致意料之外的绕路。发布更具体前缀还会增加全球路由表条目,并受上游长度过滤与 ROA maxLength 约束。
申请 ASN 前怎么写路由策略
一个简化示例:
AS64496 plans to be multihomed with AS64497 and AS64498.
Import:
- Accept an IPv6 default route from AS64497.
- Accept an IPv6 default route from AS64498.
Export:
- Announce 2001:db8:1200::/48 to AS64497.
- Announce 2001:db8:1200::/48 to AS64498.
真实申请需要使用真实上游、真实资源和符合 RPSL 要求的策略。示例中的 ASN 和 Prefix 仅供文档说明。
如果上游尚未最终开通,应如实说明当前状态和可验证的接入计划,而不是把意向写成已完成事实。
需要准备哪些资源
一套基本 BGP Multihoming 通常需要:
- 公共 ASN;
- 可由该 ASN 从多个上游发布的 IP 前缀;
- 两个或更多真实外部网络关系;
- 支持 BGP 的路由设备或软件;
- IRR 路由对象;
- 正确的 ROA;
- 上游认可的 LOA 或授权材料;
- Import 和 Export Policy;
- 外部路由和数据面监控;
- 故障切换与回滚方案。
ASN 和 IP 前缀解决身份与地址,上游解决连接,BGP 解决路由交换,IRR 与 RPKI 解决公开登记和 Origin 授权。缺少其中任何一层,都可能影响上线。
怎么测试故障切换
不要等真实事故发生才第一次验证。
可以在维护窗口按以下步骤测试:
- 记录当前两边 Session、路由数量和外部路径;
- 确认备用上游已发布相同聚合前缀;
- 从多个外部网络持续探测;
- 有计划地撤下主上游 Session 或公告;
- 记录路由变化和业务中断时间;
- 检查入站与出站是否都切换;
- 恢复主路径;
- 检查是否发生路由振荡;
- 更新监控阈值和操作文档。
不要在没有带外管理、回滚和上游联系人时进行高风险测试。
中国团队常见的额外问题
跨境 Multihoming 往往还涉及:
- 国内机房是否允许客户 BGP;
- 海外机房、Tunnel 和云平台是否有真实独立路径;
- 备案、内容合规和地址使用要求;
- 跨境链路的延迟、抖动和可用性;
- 不同上游对 IPv6、IRR、RPKI 的支持差异;
- 值班人员能否与海外 NOC 沟通;
- 故障发生时能否访问带外管理。
不要把“海外有两个 VPS”直接等同于生产级 Multihoming。先画出底层网络和故障域,再判断方案能否承担业务。
常见误区
两个上游一定满足 ASN 申请
仍需证明真实 Multihoming 和独立路由策略,并通过 RIPE NCC 个案审核。
有两个 ASN 比一个更冗余
同一个网络通常使用一个 ASN 对外呈现一致策略。额外 ASN 不会自动增加物理路径或可用性。
两边都 Established 就完成冗余
还要检查同一前缀是否从两边传播、外部是否可见、数据面是否可达,以及故障切换是否通过测试。
只要使用 BGP 就不需要 NAT
BGP 和 NAT 解决不同问题。是否使用 NAT 取决于地址和架构,不由 BGP 自动决定。
备用线路平时没有流量,所以不能用
主备策略下,备用线路平时流量很少是正常的。但必须持续监控 Session,并定期验证实际可达和容量。
决策清单
申请 ASN 前,至少确认:
- 确实需要独立外部路由策略
- 至少两个真实外部网络关系
- 对端 ASN 和接入方式明确
- 有可从多个上游发布的前缀
- 地址属性和维护关系清楚
- 上游支持客户 BGP
- IRR 与 ROA 由谁维护已经确定
- 设备能承载计划接收的路由数量
- 物理线路、设备和电源故障域已检查
- 入站、出站和故障切换策略已写明
- 有外部监控和回滚方案
- 团队能够持续运维,而不是只完成首次配置
常见问题
Multihoming 一定需要两家 Transit 吗
不一定,外部关系可以有不同组合。但如果目标是完整的 Transit 冗余,一家 Transit 加一个只交换有限路由的 Peer,通常不能等同于两家全网 Transit。
可以只用两个 PA 前缀做 Multihoming 吗
可以构建某些多出口方案,但每个 PA 前缀依附于对应提供方,入站地址稳定性和故障切换方式与使用同一独立前缀从多上游发布不同。
一台小型 VPS 能运行 BGP 吗
软件层面可以,但生产适用性还取决于底层网络、上游政策、路由数量、CPU、内存、带宽、MTU、DDoS 风险和可维护性。
接收全表才能做 Multihoming 吗
不需要。主备场景可以只接收默认路由。全表提供更细粒度的出站选择,但需要更多设备资源和运维能力。
Multihoming 能让网站永不掉线吗
不能。网络只是应用可用性的一层。DNS、服务器、数据库、存储、供电和部署系统也需要冗余。
小结
判断一个方案是否具备 Multihoming,不看线路数量,而看:
同一个网络通过多个真实外部关系维持可达,并用一套清晰的路由策略控制发布、接收和故障切换。
申请 ASN 前,应先把上游、Prefix、IRR、ROA、设备和故障域确认清楚。ASN 是多上游网络的身份,不是替代这些准备工作的捷径。
参考资料
- RIPE NCC:Autonomous System Number Assignment Policies(RIPE-679)
- RFC 1930:Guidelines for Creation, Selection, and Registration of an AS
- RFC 4271:A Border Gateway Protocol 4
- RFC 8212:EBGP 默认拒绝路由
- RFC 7454:BGP Operations and Security