当流量进入 Cloudflare 的网络时,它需要到达您基础设施中的正确目的地——特定的数据中心、办公室或云环境。流量引导(Traffic steering)控制 Cloudflare 如何做出这些路由决策。
Magic Transit 虚拟网络 是一个虚拟 network overlay,对您的账户(account)私有,横跨全球所有 Cloudflare 数据中心。该 overlay 网络提供:
- 针对 拒绝服务 (DoS) 和 Cloudflare Network Firewall 过滤的互联网流量的 Magic Transit 交付,从流量进入的入口数据中心到您的公共地址边缘/边界网络。
- 在 IPsec/GRE 隧道、互连、Cloudflare Load Balancer 以及 Zero Trust 连接(例如 Cloudflare One Client、Remote Browser Isolation、Access 和 Gateway)之间的 Magic Transit 数据包传输。
Magic Transit 虚拟网络 支持使用 GRE 和 IPsec 或 带 Dataplane v2 的 CNI 通过任播(anycast)隧道路由 Magic Transit 流量。您可以通过静态路由配置或通过 BGP 对等(BGP peering)(Beta)学到的路由,将条目添加到 Magic Transit 虚拟网络路由表 中。
在 Magic Transit 虚拟网络路由表 中允许使用以下 IPv4 地址范围:
如果流量不匹配您在虚拟网络中配置的任何路由,Cloudflare 将根据目的地地址类型应用默认行为:
- 公共(可在互联网路由的)地址:流量出口到互联网。
- 私有地址(RFC 1918 ↗ 或 CGNAT/RFC 6598 ↗):流量被丢弃(空路由),因为私有地址在公共互联网上是不可路由的,且在没有匹配路由的情况下 Cloudflare 无法交付它们。
Magic Transit 根据路由条目优先级引导沿隧道路由的流量。
- 数值越小,优先级越高。
- 当前缀条目的优先级数值相同时,Cloudflare 使用 等价多路径 (ECMP) 数据包转发来路由流量。您可以为静态路由应用可选的权重值,以 修改 ECMP 隧道分布。
Cloudflare 路由采用最长前缀匹配(longest-prefix match)。无论隧道优先级如何,更具体的静态路由(例如
/30)总是优先于较不具体的静态路由(例如/29)—— 除非您删除更具体的路由。- 当 BGP 和静态路由具有相同的前缀和优先级时,Cloudflare 通过使静态路由优于 BGP 路由来强制执行优先级。这确保了手动配置的静态路由优先,除非您明确降低它们的优先级。
静态路由的优先级值直接在 Cloudflare 仪表板(dashboard)或通过 API 配置,作为路由对象的一部分。例如:
| 前缀 | 下一跳 | 优先级 |
|---|---|---|
10.10.10.100/24 |
TUNNEL_1_IAD |
200 |
10.10.10.100/24 |
TUNNEL_2_IAD |
200 |
10.10.10.100/24 |
TUNNEL_3_ATL |
100 |
10.10.10.100/24 |
TUNNEL_4_ATL |
100 |
在此示例中,优先级为 100 的隧道优于优先级为 200 的隧道,因为数值越小优先级越高。
或者,您可以分配权重以在多个隧道之间更有效地分配流量。权重值决定了流量比例,权重越高接收的流量越多。最大权重值为 256。
在以下示例中,TUNNEL_2_IAD 可能会接收到两倍于 TUNNEL_1_IAD 的流量。
| 前缀 | 下一跳 | 优先级 | 权重 |
|---|---|---|---|
10.10.10.100/24 |
TUNNEL_1_IAD |
100 |
64 |
10.10.10.100/24 |
TUNNEL_2_IAD |
100 |
128 |
10.10.10.100/24 |
TUNNEL_3_ATL |
100 |
192 |
10.10.10.100/24 |
TUNNEL_4_ATL |
100 |
255 |
除了优先级之外,将静态路由的范围限定在特定的地理区域也会影响流量的引导方式。有关更多详细信息,请参阅 将路由范围限定在特定区域。
当 BGP 宣告路由时,Cloudflare 会自动将其添加到 Magic Transit 虚拟网络路由表,默认优先级为 100,适用于 所有区域。但是,如果存在具有相同前缀和优先级的静态路由,则静态路由始终优先于 BGP 路由。根据您想要优先考虑的路由,为静态路由设置不同的优先级(大于或小于 100)。数值越小,优先级越高。
此外,当存在多个具有相同前缀长度和优先级的 BGP 路由时,ECMP 使用 等价多路径 (ECMP) 路由 在它们之间分配流量。
Cloudflare 支持通过 BGP 团体属性(BGP communities)和 AS 预挂(AS prepending)进行流量工程。您可以使用这些流量路由技术来设置路由优先级并在多个互连之间执行流量工程。
默认的 BGP 路由优先级为 100。可以使用团体属性(communities)调整此基本优先级。例如,当路由被标记为团体属性 13335:60010 时,其优先级被设置为 10。这使其优先级高于默认值 100,因为数值越小优先级越优先。
支持用于设置基本路由优先级的团体属性值包括:
13335:60010:将基本路由优先级设置为1013335:60050:将基本路由优先级设置为50UNSET:将基本路由优先级设置为10013335:60150:将基本路由优先级设置为15013335:60200:将基本路由优先级设置为20013335:60901:将基本路由优先级设置为50100013335:60902:将基本路由优先级设置为1001000
在同一前缀更新消息中设置多个基本优先级团体属性属于配置错误。在这种情况下,Cloudflare 会优先选择最高优先级(最小整数值)。
在接收到的 AS 路径中,每多出现一次您的 ASN,Cloudflare 就会在路由的基本优先级上加 10。通过增加优先级数值,该路由将变得不那么优先。
例如,如果您的 ASN 是 65000,那么发送给 Cloudflare 的 BGP UPDATE 将为:
# 基本优先级无变化。
AS_PATH: 65000 65200
# 为 1 次 65000 预挂在基本优先级上加 10
AS_PATH: 65000 65000 65200
# 为 2 次 65000 预挂在基本优先级上加 20
AS_PATH: 65000 65000 65000 65200当结合团体属性使用 AS 预挂时,Cloudflare 会调整路由优先级。例如,如果路由被标记为 13335:60150,则基本优先级设置为 150。如果您预挂了两次 ASN,Cloudflare 将为每次预挂加 10,从而将路由优先级提高到 180。
Unified Routing 模式是较新的 Cloudflare One 数据平面,它对所有支持的连接类型使用单一的路由架构。Unified Routing 模式在单个系统中跨 Cloudflare One Client、Cloudflare Tunnel、IPsec、GRE 和 Cloudflare Network Interconnect (CNI) 路由流量,使您可以更轻松地设置 Cloudflare One 连接。
在 Magic Transit 仪表板(dashboard)中,路由模式显示在您管理路由的位置:
- Routing mode: Unified — 您的账户(account)处于统一数据平面上,并支持新的路由功能。
- Routing mode: Legacy — 您的账户(account)使用旧版(Legacy)数据平面,不支持所有统一路由功能。
Unified Routing 是驱动 Magic Transit 和 Cloudflare One 网络连接的专用虚拟网络覆盖的未来。
对于 Magic Transit 客户,考虑使用 Unified Routing 的主要原因是评估 用于 IPsec/GRE 隧道的 BGP,该功能依赖于 Unified Routing。
以下限制适用于使用 Unified Routing 模式的账户。随着 Cloudflare 添加对其他功能的支持,此列表将会变短。
| 当前 Beta 限制 | 细节 |
|---|---|
| 性能 | 每个上路连接(onramp)通常在 150 Mbps 左右 |
| 基本数据包捕获 | 捕获排除自动返回路由(Automatic Return Routing)或 BGP-over-tunnels 流量 |
| 完整数据包捕获 | 尚未支持 |
| Cloudflare 高级网络防火墙功能:IP 列表、ASN 列表、威胁情报列表、IDS、速率限制、SIP、托管规则集 | 尚未支持 |
| Gateway 过滤规则 | 在入站和出站连接都是 IPsec/GRE/CNI 的流量上不受支持 |
| Load Balancer | 支持公共到私有的使用场景到达 IPsec/GRE/CNI 目的地。私有到私有的使用场景尚未支持 Cloudflare 源 IP |
| IPv6 支持 | IPsec 和 GRE 支持 IPv6。IPv6 的基本网络防火墙支持仅限于源/目的 IP 过滤 |
Unified Routing 目前处于封闭 Beta 测试阶段。要注册:
- 现有的 Cloudflare WAN 或 Magic Transit 客户:Cloudflare 建议您在非生产账户中评估该新功能及您的使用场景。联系您的账户团队以启用 Unified Routing。
- 新客户:Contact 您的账户团队,在针对您的使用场景的概念验证中启用 Unified Routing。
如果您有通往某一网络段的多条连接路径,并且想根据流量到达 Cloudflare 网络的位置来应用不同的路由优先级,您可以将路由范围限定在特定的 Cloudflare 数据中心区域。如果您运行自己的任播(anycast)网络,并且希望最终用户流量到达最靠近该用户的网络位置,这将非常有用。
当您将路由范围限定在某个 Cloudflare 数据中心区域时,它仅在该区域的 Magic Transit 虚拟网络路由表 中显示,另外还有所有不带任何区域范围的全局路由。路由优先级和 ECMP 逻辑在区域范围路由和全局路由中均适用。
使用具有区域范围的路由时,请确保所有前缀的路由都覆盖所有区域。否则,流量可能会到达没有被任何路由覆盖的 Cloudflare 区域,在这种情况下 Cloudflare 会丢弃该流量。
下表举例说明了如何对路由使用地理范围限定:
| 前缀 | 下一跳 | 优先级 | 区域代码 |
|---|---|---|---|
10.10.10.100/24 |
TUNNEL_1_IAD |
100 |
AFR |
10.10.10.100/24 |
TUNNEL_2_IAD |
100 |
EEUR |
10.10.10.100/24 |
TUNNEL_3_ATL |
100 |
ENAM |
10.10.10.100/24 |
TUNNEL_4_ATL |
100 |
ME |
10.10.10.100/24 |
TUNNEL_5_ATL |
100 |
WNAM |
10.10.10.100/24 |
TUNNEL_4_ATL |
100 |
ENAM |
当有多个通往相同前缀且优先级相同的路由,并且这些路由被分配给不同的地理区域(如 WNAM 和 ENAM)时,进入特定区域(例如 WNAM)内网络的流量将通过与该相同区域关联的路由出站。
Cloudflare 有九个地理区域:
| 区域代码 | 区域 |
|---|---|
AFR |
非洲 |
APAC |
亚太地区 |
EEUR |
东欧 |
ENAM |
北美东部 |
ME |
中东 |
OC |
大洋洲 |
SAM |
南美洲 |
WEUR |
西欧 |
WNAM |
北美西部 |
在添加或编辑静态路由时,在 Region code(区域代码) 部分中配置您流量的范围。有关更多信息,请参阅 创建静态路由 和 编辑静态路由。
您必须提供您的前缀以及应映射到的隧道,以便 Cloudflare 通过任播隧道将流量从我们的全球网络路由到您的数据中心。请使用下表作为参考。
| 前缀 | 下一跳 |
|---|---|
103.21.244.0/29 |
TUNNEL_1_IAD |
103.21.244.8/29 |
TUNNEL_2_ATL |
最小的宣告前缀为 `/24`,但因为 Cloudflare 使用任播隧道作为流量的外层包装,所以 Cloudflare 可以将该 `/24` 内的前缀路由到不同的隧道端点。例如,您可以将 `x.x.x.0/29` 发送至数据中心 1,将 `x.x.x.8/29` 发送至数据中心 2。这在 IP 资源受限的环境中运行非常有用。
如果您有多个已接入的 /24 子网,它们属于一个更大的连续地址块,您可以为相应的超网(如 /23 或 /22)配置一条汇总静态路由,而不是分别添加每个 /24。这消除了配置每个 /24 路由的需要,因为所有流量都将通过相同的 GRE 隧道进行路由。
例如,如果您有两个隧道:
192.0.2.0/24192.0.3.0/24
您可以将这些汇总为单个 192.0.2.0/23。
请参阅 添加隧道 以了解有关配置 GRE 隧道的更多信息。
等价多路径路由使用从 数据包 ↗ 数据计算得到的哈希来决定选择哪条路由。哈希始终使用源 IP 地址和目的 IP 地址。对于 TCP 和 UDP 数据包,哈希还包含源端口和目的端口。ECMP 算法将每个数据包的哈希值除以等价下一跳的数量。模数(余数)决定了数据包选择的路由。
使用 ECMP 会带来许多后果:
- 路由到等价路径是概率性的。
- 具有相同源和目的地的相同会话中的数据包具有相同的哈希值。这些数据包也使用相同的下一跳。
- 路由中等价下一跳数量的更改可能会导致流量使用不同的隧道。例如,由健康检查事件触发的动态优先级重新调整可能会导致流量使用不同的隧道。
因此,ECMP 在具有相同前缀和优先级的隧道之间提供了负载均衡。
此图表说明了 ECMP 如何在具有相同前缀和优先级的两条路径上同等地分配流量。
flowchart LR
accTitle: 隧道图
accDescr: 此示例包含三个隧道路由,流量同等地分配在两个路径上。
subgraph Cloudflare
direction LR
B[Cloudflare <br> 数据中心]
C[Cloudflare <br> 数据中心]
D[Cloudflare <br> 数据中心]
end
Z("针对某些优先级隧道的负载均衡 <br> 使用 ECMP(基于源 IP、目的 IP、<br> 源端口、目的端口进行哈希)") --- Cloudflare
A((用户)) --> Cloudflare --- E[任播 IP]
E[任播 IP] --> F[/"GRE 隧道 1 / <br> 优先级 1 / <br> 约 50% 流"/] --> I{{客户 <br> 数据中心/ <br> 网络 1}}
E[任播 IP] --> G[/"GRE 隧道 2 / <br> 优先级 1 / <br> 约 50% 流"/] --> J{{客户 <br> 数据中心/ <br> 网络 2}}
E[任播 IP] --> H[/GRE 隧道 3 / <br> 优先级 2 / <br> 0% 流/] --o K{{客户 <br> 数据中心/ <br> 网络 3}}
客户路由器故障
当 Magic Transit 健康检查确定隧道 2 不健康时,Magic Transit 会动态地降低该路由的优先级,使隧道 1 成为唯一的最高优先级路由。因此,Magic Transit 将流量从隧道 2 引导开,所有流量都流向隧道 1。
flowchart LR
accTitle: 隧道图
accDescr: 此示例中隧道 2 不健康,且所有流量均优先路由到隧道 1。
subgraph Cloudflare
direction LR
B[Cloudflare <br> 数据中心]
C[Cloudflare <br> 数据中心]
D[Cloudflare <br> 数据中心]
end
Z(隧道健康状态 <br> 由运行自所有 Cloudflare <br> 数据中心的健康检查确定) --- Cloudflare
A((用户)) --> Cloudflare --- E[任播 IP]
E[任播 IP] --> F[/"隧道 1 / <br> 优先级 1 / <br> 约 100% 流"/]:::green --> I{{客户 <br> 数据中心/ <br> 网络 1}}
E[任播 IP] --> G[/隧道 2 / <br> 优先级 3 / <br> 不健康 / 0% 流/]:::red --x J{{客户 <br> 数据中心/ <br> 网络 2}}
E[任播 IP] --> H[/隧道 3 / <br> 优先级 2 / <br> 0% 流/] --o K{{客户 <br> 数据中心/ <br> 网络 3}}
classDef red fill:#EE4B2B,color: black
classDef green fill:#00FF00,color: black
中间互联网服务提供商(ISP)故障
当 Magic Transit 确定隧道 1 也不健康时,该路由也会被降低优先级,使隧道 3 成为最高优先级路由。在这种情况下,所有流量都流向隧道 3。
flowchart LR
accTitle: 隧道图
accDescr: 此示例中隧道 1 和 2 均不健康,且所有流量均优先路由到隧道 3。
subgraph Cloudflare
direction LR
B[Cloudflare <br> 数据中心]
C[Cloudflare <br> 数据中心]
D[Cloudflare <br> 数据中心]
end
Z(当高优先级隧道 <br> 不健康时,将使用 <br> 较低优先级的隧道) --- Cloudflare
A((用户)) --> Cloudflare --- E[任播 IP]
E[任播 IP] -- 中间网络问题 --> F[/隧道 1 / <br> 优先级 3 / <br> 不健康 / 0% 流/]:::red --x I{{客户 <br> 数据中心/ <br> 网络 1}}
E[任播 IP] -- 中间网络问题 --> G[/隧道 2 / <br> 优先级 3 / <br> 不健康 / 0% 流/]:::red --x J{{客户 <br> 数据中心/ <br> 网络 2}}
E[任播 IP] --> H[/隧道 3 / <br> 优先级 2 / <br> 100% 流/]:::green --> K{{客户 <br> 数据中心/ <br> 网络 3}}
classDef red fill:#EE4B2B,color: black
classDef green fill:#00FF00,color: black
当 Magic Transit 确定隧道 1 和 2 再次恢复健康时,它会重新调整这些路由的优先级,流量流动恢复正常。
因为 ECMP 是概率性的,所以该算法在每条隧道中路由大约相同数量的流。然而,在决定将下一个数据包路由到哪里时,它并不考虑已经通过隧道发送的流量大小。
例如,考虑一个具有许多极低带宽的 TCP 连接和一个极高带宽的 TCP 连接的场景。高带宽连接的数据包具有相同的哈希值,因此使用相同的隧道。结果,该隧道比其他隧道消耗更多的带宽。
将 BGP 对等(BGP peering)与您的 Cloudflare One 或 Magic Transit 虚拟网络路由表配合使用可以让您:
- 自动执行添加或删除网络及子网的过程。
- 利用故障检测和会话恢复功能。
通过此功能,您可以:
- 在通过 CNI、GRE 或 IPsec 隧道连接时,在您的设备与 Magic Transit 服务之间建立 eBGP 会话。
- 通过 MD5 身份验证确保会话安全,防止配置错误。
- 在您的设备与您的 Magic Transit 虚拟网络路由表 之间动态交换路由。
下表概述了跨不同连接方法的 BGP 当前可用性和推荐使用场景。
| 功能 | 发布阶段 | 推荐使用 | 前提条件 |
|---|---|---|---|
| BGP over CNI | Closed Beta | 不适用于新客户 — 请联系您的账户团队 | Cloudflare Network Interconnect (CNI) v2 |
| BGP over Anycast IPsec/GRE | Open Beta | 非生产工作负载 | Unified Routing (Beta) - 联系您的账户团队注册 |
Magic Transit 虚拟网络 在首次处理数据包的 Cloudflare 数据中心(入口节点)处做出单次、逐包路由决策。这确保了即使数据包横跨 Cloudflare 骨干网中的多个节点,其路径也会在进入点确定,以获得最大效率。
您在 IPsec、GRE 或 CNI 之上的 BGP 会话是在最靠近您的 BGP 对等设备的 Cloudflare 数据中心建立的。此处学到的路由必须传播到 Cloudflare 的全球边缘,以控制整个网络的流量路由方式。
- 收敛时间:全局路由收敛通常在 20 秒内完成。
- 可见性:您可以通过 Cloudflare 仪表板或 API 监视学到的路由及其传播状态。
Magic Transit 虚拟网络 使用集中式控制平面进行路由传播,功能类似于 BGP 路由反射器(Route Reflector)。此架构将物理 BGP 会话与全局路由分发解耦:
- 会话终止:BGP 对等会话在最靠近路由器的 Cloudflare 边缘位置终止。
- SDN 转换:入站 BGP 更新被转换为软件定义网络(SDN)状态并传输到集中式中继功能。
- 全球传播:该中继将这些指令传播到全球每个 Cloudflare 数据中心,更新每个站点的本地转发信息库(FIB)。
Cloudflare 的数据平面专为高可用性设计。如果边缘位置与集中式中继失去通信,系统将进入边缘韧性模式(Edge Resiliency Mode),模拟非中断转发(NSF)行为:
- 转发连续性:边缘位置继续使用已知的最后一个良好转发表(FIB)路由流量。数据平面流量保持不受中断。
- 陈旧路径保留:因为在此模式下 FIB 被冻结,所以即使您的路由器底层 BGP 会话发生抖动或重置,转发决策仍保持活动状态。
- 持续健康监测:尽管 BGP 更新已冻结,但隧道健康检查仍保持活跃。这些检查发送自所有 Cloudflare 数据中心,使得任何入口节点处的边缘能够检测到与路由器的物理连接是否已发生故障。如果健康检查失败,边缘的入口节点将降低该特定路径的优先级,从而在即使路由状态冻结的情况下,也能防止流量被发送到黑洞中。
- 更新冻结:在此状态下,全局控制平面将被冻结。从您的路由器接收到的新 BGP 更新将保留在本地的边缘,并且在恢复与集中式中继的连接之前不会向全球传播。
- Magic Transit 边缘宣告:在此冻结状态下,您的 BYOIP 前缀将继续在 Cloudflare 的全球边缘进行宣告。您可以通过 API 或仪表板手动更改此宣告状态。
一旦 Cloudflare 边缘与集中式中继之间的连接恢复,系统会自动退出边缘韧性模式并执行有状态的重新同步:
- RIB 到中继同步:边缘将所有当前保留的 BGP 更新(当前 RIB 状态)推送到中继。
- 全球更新:中继核对这些更新并传播任何更改到 Cloudflare 全球网络的其余部分。
- FIB 解冻:边缘处的本地转发表被解冻,并使用最新验证的路由指令进行更新。
Magic Transit BGP 对等是与 Magic Transit 虚拟网络路由表 进行的(而不是与 Cloudflare 互联网全球网络建立对等)。按照本指南配置的 BGP 对等体将接收 Magic Transit 虚拟网络路由表 中所有前缀的宣告,以及在上路连接(on-ramp) 已宣告前缀列表 中配置的任何其他前缀。
相反,如果您寻求在 Cloudflare 数据中心之一与 Cloudflare ASN 13335 进行公共对等,请参阅 PNI 和对等设置。目前无法在同一个物理互连端口上共享 Magic Transit 虚拟网络 BGP 对等和 PNI。
Cloudflare 将从您的设备接收的路由重新分发到 Magic Transit 虚拟网络路由表。
Magic Transit 虚拟网络路由表 中的所有路由都会宣告给 BGP 对等体。每个 BGP 对等体都会收到每个前缀路由以及完整的 AS_PATH,其中预挂了选定的 Cloudflare 侧 ASN ↗。这是为了让对等体能够准确地执行 环路防御 (loop prevention) ↗。
BGP 对等会话可以宣告可达的前缀到对等体,并撤销先前宣告的前缀。此传播大约需要几分钟。
Cloudflare 使用以下定时器,这些定时器是不可配置的:
| 设置 | 描述 |
|---|---|
| Hold timer(保持定时器) | CNI 为 240 秒,GRE 和 IPsec 隧道为 90 秒 (为了建立会话,Cloudflare 会比较其保持定时器和对等体的保持定时器,并使用两者中较小的一个来建立 BGP 会话。) |
| Keepalive 定时器 | 保持定时器的三分之一。 |
| Graceful restart(平滑重启) | 120 秒(目前仅在 CNI 上支持) |
- Hold timer(保持定时器):指定 BGP 对等体在宣布 BGP 会话中断之前等待接收 keepalive、更新或通知消息的最大时间。Cloudflare 使用此默认保持定时器与在 Open 消息中从对等体收到的保持定时器两者中的较小值。
- Keepalive 定时器:BGP 系统交换 keepalive 消息以确定对等路由器是否可达。如果在保持定时器时间内未收到 keepalive 消息,则假定会话已断开,表示该对等体在 BGP 协议级别上不再可达。
- Graceful restart timer(平滑重启定时器):跟踪路由器在对等体发起平滑重启后,等待对等体重新建立 BGP 会话的时间。如果对等体在此时间内未重新连接,路由器将宣告会话中断并删除陈旧路由。
支持 BGP 多路径(BGP multipath)。如果 BGP 在两个不同的互连上学到相同的前缀,Cloudflare 会根据常规 ECMP 行为在每个互连之间分配发送到该前缀的流量。
支持被动(辅助/感知)模式下的 BGP 平滑重启。Cloudflare 为重启的邻居维护转发状态。
BGP 支持目前存在以下限制:
- Cloudflare 账户(account)的 ASN 和您的设备 ASN 必须不同。仅支持 eBGP。
- Cloudflare 始终注入优先级为
100的路由。 - 不支持双向转发检测(BFD)。
- 如果您对 IPsec/CNI 使用 BGP(Beta),您必须将 Cloudflare 侧的 ASN 设置为
13335。尚不支持私有 ASN。
对于 Magic Transit 客户,与 Magic Transit 虚拟网络路由表 的 BGP 对等与 Cloudflare 边缘的任播(anycast)前缀宣告是分开的。必须通过 宣告前缀(Advertise prefixes) 中记载的现有方法来控制任播撤销。
您需要与 BGP 一起启用 旧版健康检查。这对于确定您的设备是否可以访问特定的 Cloudflare 数据中心至关重要。隧道健康检查 会修改动态学到的 BGP 路由的路由优先级。