Cloudflare Network InterconnectCNI部署模式实战指南从高可用架构到多云混合互联【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills本篇指南基于仓库 network-interconnect 参考目录下的patterns.md文档系统梳理 Cloudflare Network InterconnectCNI的六大核心部署模式高可用设计、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 InternetCNI 是免费服务没有任何 SLA必须保留备用的公网出口作为兜底路径优先选择网络韧性好的机房位置Network-resilient locations机房本身的电力、制冷、上游多路径能力会直接影响互联稳定性定期做故障切换演练Regular failover testingHA 架构只有在真实切换演练中才能被验证演练应纳入常态化运维计划。参考架构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 的两台 CCRCloudflare Core Router设备客户侧同样要求双网络出口。这样无论客户侧设备、物理链路还是 CF 侧设备故障流量都能通过另一条路径继续到达 CF 全球网络。容量规划Capacity Planning跨所有链路统一规划容量不要按单链路满载规划而是按最坏情况下剩余链路可承载全部流量的 N1 思路规划为故障切换场景预留容量某条链路宕机后其余链路必须能吸收被转移的流量这是客户自己的责任CNI 没有 SLA容量规划的责任完全在客户侧这一点在架构设计中必须明确。模式一Magic Transit CNI v2适用场景需要 DDoS 防护 私有连接且希望避免 GRE 隧道开销。为什么选 v2根据 network-interconnect/README.md 的说明v2Beta数据平面不需要 GRE 隧道双向都是 1500 MTU对称且使用 ECMP等价多路径而非 VLAN/BFD/LACP路由配置显著简化。而 v1Classic是 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.mdactive|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 Interconnect1. 从 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-onlyGCP 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 一致。模式三多地点 HAMulti-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-preference200 → 150 → 100 的递减策略让流量永远优先走 Primary其次 Secondary再次 Tertiary最后才落回公网 Internet 兜底——这是实现有损降级的经典 BGP 流量工程手段混合类型Tertiary 使用partner类型无需自有机房托管与 README 中 Partner 互联快速部署、无需 colocation的定位一致。配合该模式建议在每台互联设备上配置 configuration.md 中推荐的 BFD仅 v1 支持以实现快速故障检测并用/31点对点子网承载 BGP 对等。模式四Partner 互联以 Equinix 为例适用场景快速部署、没有自有机房托管无 colocation需求。部署步骤Setup在 Equinix Fabric Portal 订购虚拟电路virtual circuit选择 Cloudflare 作为目的地选择机房位置将详细信息发送给 CF 账户团队CF 在 Portal 中接受accept连接请求配置 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给出了从需求到推荐互联类型的快速对照表需求Requirement推荐Recommended与 CF 同机房托管Collocated with CFDirect未与 CF 同机房Not collocatedPartnerAWS/GCP 工作负载Cloud双向 1500 MTUv2VLAN 标签VLAN taggingv1公网对等Public peeringv1配置最简单Simplest configv2BFD 快速故障切换v1LACP 链路捆绑v1结合 README.md 补充说明Direct与 CF 共享数据中心的物理裸光纤10/100 Gbps需要客户自行订购 cross-connectPartner经由 Console Connect、Equinix、Megaport 等合作伙伴的虚拟化接入由合作伙伴 SDN 管理CloudAWS Direct Connect 或 GCP Cloud Interconnect仅限 Magic WANv1Classic支持 GRE 隧道、VLAN/BFD/LACP、非对称 MTU1500↓/1476↑、支持 peeringv2Beta无 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 的 LOAVLAN 对接、GCP 最终激活、Partner 接受、v1 的 VLAN 分配与配置文档生成、升级与排障支持都需要账户团队物理 cross-connect 安装、Partner Portal 操作、云厂商 Portal 操作与维护窗口协调则完全无法自动化。高频踩坑点来自 gotchas.mdStatus: Pending常因 cross-connect 未装好、RX/TX 纤芯接反、光模块类型错误或光功率过低目标 -20 dBmStatus: Unhealthy多为物理问题低光 -20 dBm、光模块不匹配10GBASE-LR / 100GBASE-LR4或连接器脏污BGP Session Down排查顺序IP 是否与 CNI 对象一致 → ASN 是否正确 → BGP 密码 → 防火墙是否放行 TCP/179 → BGP 日志与计时器低吞吐先查 MTUv1 为 1500↓/1476↑v2 双向 1500再考虑增加 GRE 隧道v1或升级 v2API 创建报slot_id already occupied用occupiedfalse过滤列出可用 slot 后再创建API 限流1200 请求/5 分钟/Token务必实现指数退避并对 slot 列表做缓存。资源导航network-interconnect/README.md产品概述、连接类型、数据平面版本、规格与自动化边界network-interconnect/configuration.md2–4 周开通工作流、BGP 配置、AWS/GCP 接入细则与监控告警network-interconnect/api.mdREST 端点、TypeScript/Python SDK 与 cURL 完整示例network-interconnect/gotchas.md错误排查、云厂商专项问题、反模式与硬性限制SKILL.mdCloudflare 部署技能总入口含产品选型决策树与认证前置检查。若你的场景更偏向轻量级私有连接无需 CNI 的企业级物理/虚拟互联可在 tunnel 对应的 tunnel/README.md 中了解替代方案TCP/UDP 四层代理场景可参考 spectrum/README.md。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考