Cloudflare Network Interconnect（CNI）部署模式实战指南：从高可用架构到多云混合互联

Cloudflare Network Interconnect（CNI）部署模式实战指南：从高可用架构到多云混合互联

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills

本篇指南基于仓库 network-interconnect 参考目录下的patterns.md文档，系统梳理 Cloudflare Network Interconnect（CNI）的六大核心部署模式：高可用设计、Magic Transit + CNI v2、多云混合（AWS/GCP）、多地点高可用、Partner 互联以及故障切换与安全加固。读完本文，你将掌握如何为企业级网络设计具备设备级冗余、可故障切换的 CNI 拓扑，并能够直接用 TypeScript/Python SDK 或 REST API 完成互联创建、BGP 配置与状态轮询，同时避开常见的误配置陷阱。

背景提示：CNI 是 Cloudflare 提供的私有高性能接入服务（企业版专属），用于在客户网络与 Cloudflare 全球网络（AS13335）之间建立直连、合作伙伴或云厂商（AWS/GCP）三种类型的私有互联通道，详细的产品背景与规格可先阅读 network-interconnect/README.md。

高可用设计：从第一天就为韧性而设计

patterns.md开篇即以Critical级别强调：设计阶段必须从第一天就考虑韧性（resilience），而不是等上线后再补救。

硬性要求（Requirements）

• 设备级多样性（Device-level diversity）：两条链路必须落在独立硬件上，避免单台设备故障拖垮全部流量；
• 备份 Internet 连接（Backup Internet）：CNI 是免费服务，没有任何 SLA，必须保留备用的公网出口作为兜底路径；
• 优先选择网络韧性好的机房位置（Network-resilient locations）：机房本身的电力、制冷、上游多路径能力会直接影响互联稳定性；
• 定期做故障切换演练（Regular failover testing）：HA 架构只有在真实切换演练中才能被验证，演练应纳入常态化运维计划。

参考架构

Your Network A ──10G CNI v2──> CF CCR Device 1 │ Your Network B ──10G CNI v2──> CF CCR Device 2 │ CF Global Network (AS13335)

两条 10G CNI v2 链路分别接入 Cloudflare 的两台 CCR（Cloudflare Core Router）设备，客户侧同样要求双网络出口。这样无论客户侧设备、物理链路还是 CF 侧设备故障，流量都能通过另一条路径继续到达 CF 全球网络。

容量规划（Capacity Planning）

• 跨所有链路统一规划容量：不要按"单链路满载"规划，而是按"最坏情况下剩余链路可承载全部流量"的 N+1 思路规划；
• 为故障切换场景预留容量：某条链路宕机后，其余链路必须能吸收被转移的流量；
• 这是客户自己的责任：CNI 没有 SLA，容量规划的责任完全在客户侧，这一点在架构设计中必须明确。

模式一：Magic Transit + CNI v2

适用场景：需要 DDoS 防护 + 私有连接，且希望避免 GRE 隧道开销。

为什么选 v2

根据 network-interconnect/README.md 的说明，v2（Beta）数据平面不需要 GRE 隧道，双向都是 1500 MTU（对称），且使用 ECMP（等价多路径）而非 VLAN/BFD/LACP，路由配置显著简化。而 v1（Classic）是 GRE 隧道 + 非对称 MTU（下行 1500 / 上行 1476），配置复杂、有封装开销。

落地步骤（TypeScript SDK）

// 1. 创建互联 const ic = await client.networkInterconnects.interconnects.create({ account_id: id, type: 'direct', facility: 'EWR1', speed: '10G', name: 'magic-transit-primary', }); // 2. 轮询直到状态变为 active const status = await pollUntilActive(id, ic.id); // 3. 通过 Dashboard 或 API 配置 Magic Transit 隧道

创建成功后需要轮询互联状态直至active。可用的状态取值来自 api.md：active|healthy|unhealthy|pending|down。需要注意，gotchas.md 明确反对高频轮询（见"反模式"表：每秒轮询会触发限流），建议轮询间隔控制在 30–60 秒。

收益

• 双向 1500 MTU：避免 v1 非对称 MTU 带来的分片与吞吐问题；
• 简化路由：Magic Transit/WAN 可直接在 CNI v2 上运行 BGP，无需 GRE 隧道（自 2024 年 12 月起，Magic WAN/Transit 支持直接通过 CNI v2 建立 BGP 对等，详见 configuration.md）。

模式二：多云混合（Multi-Cloud Hybrid）

适用场景：AWS/GCP 工作负载与 Cloudflare 互联，形成"CF 边缘 + 多云后端"的混合架构。Cloud 类型互联仅支持 Magic WAN（见 README 连接类型说明）。

AWS Direct Connect

// 1. 在 AWS Console 订购 Direct Connect // 2. 从 AWS 获取 LOA + VLAN // 3. 发送给 CF account team（无 API 通道） // 4. 在 Magic WAN 中配置静态路由 await configureStaticRoutes(id, { prefix: '10.0.0.0/8', nexthop: 'aws-direct-connect', });

需要强调的是，AWS 侧的对接链路属于"需账户团队介入"的范畴（见 README.md 的自动化边界一节）：LOA 与 VLAN 信息必须发给 CF 账户团队手工处理，没有 API 通道。配置细节可参考 configuration.md：要求 Magic WAN + AWS 专用 Direct Connect 1/10 Gbps，从订购到就绪通常约 4 周；就绪后需在 Magic WAN 添加静态路由，并启用双向健康检查。

GCP Cloud Interconnect

1. 从 GCP Console 获取 VLAN attachment pairing key（配对密钥） 2. 通过 Dashboard 创建：Interconnects → Create → Cloud Interconnect → Google - 输入配对密钥、名称、MTU、速率（Partner 互联可选 50M–50G 的细粒度速率） 3. 在 Magic WAN 中配置静态路由（GCP 的 BGP 路由会被忽略） 4. 在 GCP Cloud Router 中配置自定义学习路由（custom learned routes）

关键注意点（重要）：

• Dashboard-only：GCP Cloud Interconnect 的创建与状态查询目前没有 API/SDK 支持，只能通过 CF Dashboard 与 GCP Console 操作；
• 路由方向是单向的：GCP Cloud Router 发出的 BGP 路由会被 CF 侧按设计忽略，从 CF 到 GCP 必须用 Magic WAN 静态路由；反向（GCP 学习 CF 前缀）则需在 Cloud Router 配置自定义学习路由，前缀列表向 CF 账户团队申请；
• MTU 必须匹配：Dashboard 中填写的 MTU 要与 GCP VLAN attachment 的 MTU 一致。

模式三：多地点 HA（Multi-Location HA）

适用场景：追求 99.99%+ 可用性，需要跨地域 + 跨设备的冗余拓扑。这是四种落地模式中最完整的一套参考实现。

// Primary（纽约） const primary = await client.networkInterconnects.interconnects.create({ account_id: id, type: 'direct', facility: 'EWR1', speed: '10G', name: 'primary-ewr1', }); // Secondary（纽约，不同硬件） const secondary = await client.networkInterconnects.interconnects.create({ account_id: id, type: 'direct', facility: 'EWR2', speed: '10G', name: 'secondary-ewr2', }); // Tertiary（洛杉矶，不同地理区域） const tertiary = await client.networkInterconnects.interconnects.create({ account_id: id, type: 'partner', facility: 'LAX1', speed: '10G', name: 'tertiary-lax1', }); // BGP local preferences（本地优先级）： // Primary: 200 // Secondary: 150 // Tertiary: 100 // Internet: Last resort（兜底出口）

设计要点解析

• 同城异构（EWR1 / EWR2）：纽约两个不同的机房位置，满足"设备级多样性"要求——即使 EWR1 整机房故障，EWR2 仍可承载流量；
• 跨地域（LAX1）：洛杉矶提供地理级冗余，抵御区域性事件（极端天气、电网故障等）；
• 三级 BGP 本地优先级（local-preference）：200 → 150 → 100 的递减策略让流量永远优先走 Primary，其次 Secondary，再次 Tertiary，最后才落回公网 Internet 兜底——这是实现"有损降级"的经典 BGP 流量工程手段；
• 混合类型：Tertiary 使用partner类型（无需自有机房托管），与 README 中 Partner 互联"快速部署、无需 colocation"的定位一致。

配合该模式，建议在每台互联设备上配置 configuration.md 中推荐的 BFD（仅 v1 支持）以实现快速故障检测，并用/31点对点子网承载 BGP 对等。

模式四：Partner 互联（以 Equinix 为例）

适用场景：快速部署、没有自有机房托管（无 colocation）需求。

部署步骤（Setup）

1. 在 Equinix Fabric Portal 订购虚拟电路（virtual circuit）；
2. 选择 Cloudflare 作为目的地；
3. 选择机房位置；
4. 将详细信息发送给 CF 账户团队；
5. CF 在 Portal 中接受（accept）连接请求；
6. 配置 BGP。

重要限制

没有 API 自动化——Partner 互联的虚拟电路订购与接受动作都发生在合作伙伴的 SDN Portal 中，与 CF 账户团队协作是必经环节。在 gotchas.md 中也有印证：Console Connect/Megaport 的"API 创建失败"属于预期行为，因为 Partner 互联要求"合作伙伴 Portal 订购 + CF 账户团队审批"两步，无法完全自动化；Equinix 虚拟电路不出现时，通常是因为 CF 尚未接受请求，需要联系账户团队并预留 2–3 个工作日。

故障切换与安全（Failover & Security）

故障切换最佳实践

• 用 BGP local-preference 控制优先级：多链路场景下通过本地优先级（如 200/150/100）明确流量主备顺序；
• 配置 BFD 实现快速检测：BFD 可将故障探测时间从秒级压缩到毫秒级，但仅 v1 支持（v2 目前无 BFD）；
• 定期用流量切换做演练：真实压测主备切换流程，验证路由收敛与容量冗余；
• 编写并维护 runbook：把切换步骤、联系人、回滚方案固化为可执行文档。

安全清单

• BGP 密码认证：为每个 BGP 会话配置 MD5/共享密钥认证，防止会话劫持；
• BGP 路由过滤：入方向/出方向均做前缀过滤，只允许约定的前缀；
• 监控异常路由：对收到的路由做基线监控，发现未预期前缀及时告警；
• 启用 Magic Firewall：在 Magic Transit/WAN 上叠加 DDoS 防护与威胁拦截；
• API Token 最小权限：用于 CNI 管理的 Token 仅授予所需账户与操作范围；
• 定期轮换凭据：BGP 密码、API Token 均应按安全基线周期性轮换。

关于 API Token 权限，本仓库 SKILL.md 也强调部署前必须用npx wrangler whoami验证认证状态，CI/CD 场景应通过CLOUDFLARE_API_TOKEN环境变量注入，避免在脚本中硬编码凭据。

决策矩阵：按需求选型

patterns.md给出了从需求到推荐互联类型的快速对照表：

结合 README.md 补充说明：

• Direct：与 CF 共享数据中心的物理裸光纤，10/100 Gbps，需要客户自行订购 cross-connect；
• Partner：经由 Console Connect、Equinix、Megaport 等合作伙伴的虚拟化接入，由合作伙伴 SDN 管理；
• Cloud：AWS Direct Connect 或 GCP Cloud Interconnect，仅限 Magic WAN；
• v1（Classic）：支持 GRE 隧道、VLAN/BFD/LACP、非对称 MTU（1500↓/1476↑）、支持 peering；
• v2（Beta）：无 GRE、双向 1500 MTU、暂无 VLAN/BFD/LACP、改用 ECMP。

一句话总结选型逻辑：追求简单与对称 MTU 选 v2，需要 VLAN/BFD/LACP/公网对等这类高级特性则留在 v1，按托管关系决定 Direct 还是 Partner，多云工作负载一律走 Cloud。

落地实施前必读：与本文模式配套的自动化边界与踩坑清单

本文所有模式中的 TypeScript 代码均依赖client.networkInterconnects.*命名空间（这是官方推荐的主命名空间，旧的client.magicTransit.cfInterconnects.*已标记为废弃）。完整的 REST 端点（POST /accounts/{account_id}/cni/interconnects等）、Python SDK 与 cURL 示例请参见 api.md。

在设计模式落地前，务必对照以下两类清单自查：

自动化边界（来自 README.md）：互联的增删查、slot 查询、LOA 下载、CNI 对象（BGP 配置）创建均可 API 自动化；但初始请求审批、AWS Direct Connect 的 LOA+VLAN 对接、GCP 最终激活、Partner 接受、v1 的 VLAN 分配与配置文档生成、升级与排障支持都需要账户团队；物理 cross-connect 安装、Partner Portal 操作、云厂商 Portal 操作与维护窗口协调则完全无法自动化。

高频踩坑点（来自 gotchas.md）：

• Status: Pending常因 cross-connect 未装好、RX/TX 纤芯接反、光模块类型错误或光功率过低（目标 > -20 dBm）；
• Status: Unhealthy多为物理问题：低光（< -20 dBm）、光模块不匹配（10GBASE-LR / 100GBASE-LR4）或连接器脏污；
• BGP Session Down排查顺序：IP 是否与 CNI 对象一致 → ASN 是否正确 → BGP 密码 → 防火墙是否放行 TCP/179 → BGP 日志与计时器；
• 低吞吐：先查 MTU（v1 为 1500↓/1476↑，v2 双向 1500），再考虑增加 GRE 隧道（v1）或升级 v2；
• API 创建报slot_id already occupied：用occupied=false过滤列出可用 slot 后再创建；
• API 限流：1200 请求/5 分钟/Token，务必实现指数退避，并对 slot 列表做缓存。

资源导航

• network-interconnect/README.md：产品概述、连接类型、数据平面版本、规格与自动化边界；
• network-interconnect/configuration.md：2–4 周开通工作流、BGP 配置、AWS/GCP 接入细则与监控告警；
• network-interconnect/api.md：REST 端点、TypeScript/Python SDK 与 cURL 完整示例；
• network-interconnect/gotchas.md：错误排查、云厂商专项问题、反模式与硬性限制；
• SKILL.md：Cloudflare 部署技能总入口，含产品选型决策树与认证前置检查。

若你的场景更偏向轻量级私有连接（无需 CNI 的企业级物理/虚拟互联），可在 tunnel 对应的 tunnel/README.md 中了解替代方案；TCP/UDP 四层代理场景可参考 spectrum/README.md。

【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills