トラフィックステアリング

トラフィックが Cloudflare のネットワークに入ると、インフラ内の正しい宛先（特定のデータセンター、オフィス、クラウド環境）へ到達する必要があります。トラフィックステアリングは、Cloudflare がこのルーティング判断を行う方法を制御します。

Magic Transit Virtual Network は、アカウント専用の仮想ネットワークオーバーレイで、世界中のすべての Cloudflare データセンターにまたがります。このオーバーレイネットワークは次を提供します。

• トラフィックが着信したエントリデータセンターから、公開アドレス付きのエッジ/ボーダーネットワークへ、Denial of Service (DoS) と Cloudflare Network Firewall でフィルタしたインターネットトラフィックの Magic Transit 配信。
• IPsec/GRE トンネル、インターコネクト、Cloudflare Load Balancer、Cloudflare One Client、Remote Browser Isolation、Access、Gateway などの Zero Trust 接続のあいだの Magic Transit パケット転送。

Magic Transit Virtual Network は、GRE と Internet Protocol Security (IPsec) または Dataplane v2 の CNI を使う anycast トンネル経由で Magic Transit トラフィックをルーティングできます。静的ルート設定、または BGP ピアリング（ベータ）で学習したルートにより、Magic Transit Virtual Network ルーティングテーブルへエントリを追加できます。

Magic Transit Virtual Network ルーティングテーブルで許可される IPv4 アドレスレンジは次のとおりです。

• Cloudflare Magic Transit にオンボードした BYOIP 公開アドレス空間。
• アカウントに割り当てられた Cloudflare リース IP。

仮想ネットワークで設定したどのルートにも一致しないトラフィックには、宛先アドレスの種別に基づくデフォルト挙動を適用します。

• パブリック（インターネットルーティング可能な）アドレス: トラフィックはインターネットへ出ます。
• プライベートアドレス（RFC 1918 ↗ または CGNAT/RFC 6598 ↗）: トラフィックはドロップ（ヌルルート）されます。プライベートアドレスはパブリックインターネットでルーティングできず、一致するルートがなければ Cloudflare は配信経路を持たないためです。

Magic Transit は、ルートエントリの優先度に基づいてトンネルルート沿いにトラフィックを誘導します。

• 値が小さいほど優先度が高いです。
• プレフィックスエントリの優先度が一致すると、Cloudflare は equal-cost multi-path (ECMP) パケット転送でルーティングします。静的ルートに任意の weight 値を付け、ECMP トンネル分散を変更 できます。
• Cloudflare のルーティングは最長プレフィックス一致を適用します。より具体的な静的ルート（/30 など）は、トンネル優先度に関係なく、より粗いルート（/29 など）より常に優先されます。より具体的なルートを削除しない限りです。
• BGP と静的ルートが同じプレフィックスと優先度のとき、Cloudflare は静的ルートを BGP ルートより優先して優先度を適用します。明示的に優先度を下げない限り、手動設定した静的ルートが優先されます。

静的ルートの優先度値は、Cloudflare の ダッシュボードまたは API でルートオブジェクトの一部として直接設定します。例:

この例では、優先度 100 のトンネルが優先度 200 のトンネルより優先されます。数字が小さいほど優先度が高いためです。

任意で weight を割り当て、複数トンネル間のトラフィック分散を効果的にできます。weight 値はトラフィック割合を決め、高いほど多くのトラフィックを受けます。最大 weight 値は 256 です。

次の例では、TUNNEL_2_IAD は TUNNEL_1_IAD の約 2 倍のトラフィックを受ける可能性が高いです。

優先度以外に、静的ルートを特定の地理的リージョンにスコープすることも、トラフィックの誘導に影響します。詳細は 特定リージョンへのルートのスコープ を参照してください。

BGP がルートを広告すると、Cloudflare はそれを Magic Transit Virtual Network ルーティングテーブルへ、デフォルト優先度 100 で自動追加し、すべてのリージョン に適用します。ただし同じプレフィックスと優先度の静的ルートがある場合、静的ルートは常に BGP ルートより優先されます。どちらを優先するかに応じて、静的ルートに別の優先度（100 より大きいか小さいか）を設定してください。値が小さいほど優先度が高いです。

加えて、同じプレフィックス長と優先度の BGP ルートが複数ある場合、ECMP は equal-cost multi-path (ECMP) ルーティング でトラフィックを分散します。

Cloudflare は BGP communities と AS prepending によるトラフィックエンジニアリングに対応します。これらの手法でルート優先度を設定し、複数インターコネクトをまたいだトラフィックエンジニアリングができます。

デフォルトの BGP ルート優先度は 100 です。この基準優先度は communities で調整できます。たとえば、ルートに community 13335:60010 が付くと優先度は 10 になります。数値が小さいほど優先されるため、デフォルトの 100 より高い優先度です。

基準ルート優先度の設定に使える community 値は次のとおりです。

• 13335:60010: 基準ルート優先度を 10 に設定
• 13335:60050: 基準ルート優先度を 50 に設定
• UNSET: 基準ルート優先度を 100 に設定
• 13335:60150: 基準ルート優先度を 150 に設定
• 13335:60200: 基準ルート優先度を 200 に設定
• 13335:60901: 基準ルート優先度を 501000 に設定
• 13335:60902: 基準ルート優先度を 1001000 に設定

同じプレフィックス更新メッセージで複数の基準優先度 community を設定するのは誤設定です。この場合、Cloudflare は最も高い優先度（最も小さい整数値）を優先します。

受信 AS パスに自分の ASN が追加で現れるたびに、Cloudflare はルートの基準優先度に 10 を加算します。優先度の数字が大きくなると、ルートの優先は下がります。

たとえば ASN が 65000 の場合、Cloudflare への BGP UPDATE は次のようになります。

# No change to base priority.
AS_PATH: 65000 65200

# Add 10 to base priority for 1 prepend of 65000
AS_PATH: 65000 65000 65200

# Add 20 to base priority for 2 prepend of 65000
AS_PATH: 65000 65000 65000 65200

Cloudflare は AS prepending を communities と使うときにルート優先度を調整します。たとえばルートに 13335:60150 が付くと基準優先度は 150 です。ASN を 2 回 prepend すると、Cloudflare は prepend ごとに 10 を加算し、ルート優先度は 180 になります。

Unified Routing モードは、対応するすべての接続種別で単一のルーティングファブリックを使う Cloudflare One データプレーンです。Cloudflare One Client、Cloudflare Tunnel、IPsec、GRE、Cloudflare Network Interconnect（CNI）をまたいでトラフィックを 1 つのシステムでルーティングします。

Magic Transit ダッシュボードでは、ルートを管理する場所にルーティングモードが表示されます。

• Routing mode: Unified — アカウントは統合データプレーン上にあり、新しいルーティング機能をサポートします。
• Routing mode: Legacy — アカウントは以前のデータプレーンを使い、統合ルーティング機能のすべてをサポートしません。

Unified Routing は一般提供であり、新しいアカウントすべてに推奨するルーティングモードです。

次の機能には Unified Routing が必要です。

Cloudflare Network Firewall 以外の機能の可用性は次のとおりです。

Cloudflare Network Firewall 機能の可用性は次のとおりです。

同じトラフィックプロファイルでも、Unified Routing の性能は Legacy Routing と異なることがあります。スループットはトラフィック分布、パケットサイズ、トンネル設定、暗号化、お客様機器に依存します。

アップグレード前に Legacy Routing のベースラインを取り、代表的なトラフィックで制御した Unified Routing のパイロットを実行してください。想定およびピークのスループット、パケットロス、レイテンシ、トンネルフェイルオーバー、既存の IPsec 設定を試験します。

アカウントが Legacy Routing の場合は、次の手順でアップグレードします。

1. 現在のニーズに対して Unified Routing の機能と性能を評価します。ルーティングモードの比較、機能の可用性、性能の案内 を確認してください。
2. アップグレードに適した時間帯を特定します。アップグレード中、Cloudflare One Client ユーザーは最大 3 分のリモートアクセス停止が発生することがあります。
3. アカウントチームに変更を依頼し、受け入れ可能な時間帯の範囲を伝えます。

ネットワークセグメントへの接続パスが複数あり、Cloudflare ネットワークへの着信地点に応じて異なるルート優先度を適用したい場合は、ルートを特定の Cloudflare データセンターリージョンにスコープできます。独自の anycast ネットワークを運用し、エンドユーザートラフィックをユーザーに最も近い自ネットワーク拠点へ到着させたいときに役立ちます。

ルートを Cloudflare データセンターリージョンにスコープすると、そのリージョンの Magic Transit Virtual Network ルーティングテーブルにだけ現れます。リージョンスコープのないグローバルルートとあわせて表示されます。ルート優先度と ECMP ロジックは、リージョンスコープのルートとグローバルルートの両方に適用されます。

リージョンスコープのルートを使うときは、すべてのプレフィックスがすべてのリージョンを覆うルートを持つようにしてください。そうしないと、どのルートにも覆われない Cloudflare リージョンにトラフィックが到着し、Cloudflare はそのトラフィックをドロップします。

次の表は、ルートの地理的スコープの使い方の例です。

同じプレフィックスへの複数ルートが同じ優先度で、WNAM と ENAM など異なる地理的リージョンに割り当てられている場合、特定リージョン（例: WNAM）でネットワークに入ったトラフィックは、同じリージョンに紐づくルート経由でエグレスします。

Cloudflare には 9 つの地理的リージョンがあります。

静的ルートの追加または編集時に、Region code セクションでトラフィックのスコープを設定します。詳細は 静的ルートを作成する と 静的ルートを編集する を参照してください。

Cloudflare がグローバルネットワークから anycast トンネル経由でデータセンターへトラフィックをルーティングするには、プレフィックスとマッピング先トンネルを提供する必要があります。次の表を参照してください。

広告する最小プレフィックスは /24 です。ただし Cloudflare はトラフィックの外側ラッパーとして anycast トンネルを使うため、その /24 内のプレフィックスを異なるトンネルエンドポイントへルーティングできます。たとえば x.x.x.0/29 を Data Center 1 へ、x.x.x.8/29 を Data Center 2 へ送れます。IP 資源が限られた環境で運用するときに役立ちます。

より大きな連続ブロックに属する複数のオンボード済み /24 サブネットがある場合、各 /24 を個別に追加する代わりに、対応するスーパーネット（/23 や /22 など）の要約静的ルートを設定できます。すべてのトラフィックが同じ GRE トンネル経由でルーティングされるため、各 /24 ルートの設定が不要になります。

たとえば 2 つのトンネルがあるとします。

• 192.0.2.0/24
• 192.0.3.0/24

これらを単一の 192.0.2.0/23 に要約できます。

GRE トンネルの設定は トンネルを追加する を参照してください。

Equal-cost multi-path ルーティングは、パケット ↗ データから計算したハッシュで選ぶルートを決めます。ハッシュは常に送信元と宛先の IP アドレスを使います。TCP と UDP パケットでは、送信元と宛先のポートも含みます。ECMP アルゴリズムは各パケットのハッシュを等コストのネクストホップ数で割ります。剰余がパケットの通るルートを決めます。

ECMP を使うと次の結果があります。

• 等コストパスへのルーティングは確率的です。
• 同じセッションで同じ送信元と宛先のパケットは同じハッシュを持ちます。パケットは同じネクストホップも使います。
• 等コストのネクストホップ数が変わると、トラフィックが別のトンネルを使うことがあります。たとえばヘルスチェックイベントによる動的な優先度変更で、トラフィックが別のトンネルを使うことがあります。

その結果、ECMP は同じプレフィックスと優先度のトンネル間で負荷分散を提供します。

この図は、同じプレフィックスと優先度の 2 つのパスに ECMP がトラフィックを均等に分散する様子です。

flowchart LR
accTitle: トンネルの図
accDescr: この例は 3 つのトンネルルートがあり、2 つのパスにトラフィックが均等に分散されます。

subgraph Cloudflare
direction LR
B[Cloudflare <br> データセンター]
C[Cloudflare <br> データセンター]
D[Cloudflare <br> データセンター]
end

Z("一部の優先度トンネルの <br> 負荷分散は ECMP を使う <br> （src IP、dst IP、<br> src ポート、dst ポートでハッシュ）") --- Cloudflare
A((ユーザー)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"GRE Tunnel 1 / <br> 優先度 1 / <br> フローの約 50%"/] --> I{{お客様 <br> データセンター/ <br> ネットワーク 1}}
E[Anycast IP] --> G[/"GRE Tunnel 2 / <br> 優先度 1 / <br> フローの約 50%"/] --> J{{お客様 <br> データセンター/ <br> ネットワーク 2}}
E[Anycast IP] --> H[/GRE Tunnel 3 / <br> 優先度 2 / <br> フローの 0%/] --o K{{お客様 <br> データセンター/ <br> ネットワーク 3}}

お客様ルーターの障害

Magic Transit ヘルスチェックが Tunnel 2 を不健全と判定すると、Magic Transit はそのルートの優先度を動的に下げ、Tunnel 1 だけが最優先ルートになります。その結果、Magic Transit は Tunnel 2 からトラフィックを外し、すべてのトラフィックが Tunnel 1 へ流れます。

flowchart LR
accTitle: トンネルの図
accDescr: この例では Tunnel 2 が不健全で、すべてのトラフィックが Tunnel 1 に優先されます。

subgraph Cloudflare
direction LR
B[Cloudflare <br> データセンター]
C[Cloudflare <br> データセンター]
D[Cloudflare <br> データセンター]
end

Z(トンネル健全性は <br> すべての Cloudflare <br> データセンターから実行される <br> ヘルスチェックで判定) --- Cloudflare
A((ユーザー)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"Tunnel 1 / <br> 優先度 1 / <br> フローの約 100%"/]:::green --> I{{お客様 <br> データセンター/ <br> ネットワーク 1}}
E[Anycast IP] --> G[/Tunnel 2 / <br> 優先度 3 / <br> 不健全 / フローの 0%/]:::red --x J{{お客様 <br> データセンター/ <br> ネットワーク 2}}
E[Anycast IP] --> H[/Tunnel 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 が Tunnel 1 も不健全と判定すると、そのルートも優先度が下がり、Tunnel 3 が最優先ルートになります。その場合、すべてのトラフィックは Tunnel 3 へ流れます。

flowchart LR
accTitle: トンネルの図
accDescr: この例では Tunnel 1 と 2 が不健全で、すべてのトラフィックが Tunnel 3 に優先されます。

subgraph Cloudflare
direction LR
B[Cloudflare <br> データセンター]
C[Cloudflare <br> データセンター]
D[Cloudflare <br> データセンター]
end

Z(優先度の低いトンネルは <br> 優先度の高いトンネルが <br> 不健全なときに使われる) --- Cloudflare
A((ユーザー)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP]  -- 中間 <br> ネットワークの問題 -->  F[/Tunnel 1 / <br> 優先度 3 / <br> 不健全 / フローの 0%/]:::red --x I{{お客様 <br> データセンター/ <br> ネットワーク 1}}
E[Anycast IP]  -- 中間 <br> ネットワークの問題 -->  G[/Tunnel 2 / <br> 優先度 3 / <br> 不健全 / フローの 0%/]:::red --x J{{お客様 <br> データセンター/ <br> ネットワーク 2}}
E[Anycast IP] -->  H[/Tunnel 3 / <br> 優先度 2 / <br> フローの 100%/]:::green --> K{{お客様 <br> データセンター/ <br> ネットワーク 3}}
classDef red fill:#EE4B2B,color: black
classDef green fill:#00FF00,color: black

Magic Transit が Tunnel 1 と 2 が再び健全と判定すると、それらのルートの優先度を戻し、トラフィックフローは通常に戻ります。

ECMP は確率的なため、アルゴリズムはおおよそ同数のフローを各トンネルへルーティングします。ただし次のパケットの送り先を決めるとき、トンネルへすでに送ったトラフィック量は考慮しません。

たとえば、非常に低帯域の TCP 接続が多数あり、非常に高帯域の TCP 接続が 1 本あるシナリオを考えます。高帯域接続のパケットは同じハッシュを持ち、同じトンネルを使います。その結果、そのトンネルはほかより多くの帯域を使います。

Cloudflare One または Magic Transit のネットワークルーティングテーブルとの BGP ピアリングを使うと、次ができます。

• ネットワークとサブネットの追加・削除を自動化する。
• 障害検出とセッション復旧機能を活用する。

この機能で次ができます。

• CNI、GRE、IPsec トンネル経由で接続しているとき、機器と Magic Transit サービスのあいだに eBGP セッションを確立する。
• 誤設定を防ぐため、MD5 認証でセッションを保護する。
• 機器と Magic Transit ネットワークルーティングテーブルのあいだでルートを動的に交換する。

次の表は、接続方法ごとの BGP の現在の可用性と推奨用途です。

Magic Transit Virtual Network は、パケットを最初に処理する Cloudflare データセンター（イングレスノード）で、1 パスのパケット単位ルーティング判断を行います。パケットが Cloudflare バックボーン内の複数ノードを横断しても、経路は入口で決まるため効率が最大になります。

IPsec、GRE、CNI 上の BGP セッションは、BGP ピア機器に最も近い Cloudflare データセンターと確立されます。ここで学習したルートは、ネットワーク全体のルーティングを制御するため Cloudflare のグローバルエッジへ伝播する必要があります。

• 収束時間: グローバルルート収束は通常 20 秒以内に完了します。
• 可視性: Cloudflare ダッシュボードまたは API で、学習したルートとその伝播状況を監視できます。

Magic Transit Virtual Network はルート伝播に集中コントロールプレーンを使い、BGP Route Reflector と同様に機能します。このアーキテクチャは、物理 BGP セッションとグローバルルート配布を切り離します。

• セッション終端: BGP ピアリングセッションは、ルーターに最も近い Cloudflare エッジ拠点で終端されます。
• SDN 変換: イングレス BGP 更新は Software-Defined Networking（SDN）状態に変換され、集中リレー機能へ送られます。
• グローバル配布: リレーはこれらの指示を世界中のすべての Cloudflare データセンターへ伝播し、各サイトのローカル Forwarding Information Base（FIB）を更新します。

Cloudflare のデータプレーンは高可用性向けに設計されています。エッジ拠点が集中リレーとの通信を失うと、システムは Edge Resiliency Mode に入り、Non-Stop Forwarding（NSF）に似た挙動をします。

• 転送の継続: エッジ拠点は最後に正常だった転送テーブル（FIB）を使ってトラフィックをルーティングし続けます。データプレーントラフィックは中断しません。
• 古いパスの保持: このモード中 FIB は凍結されるため、ルーターとの下層 BGP セッションがフラップまたはリセットしても転送判断は有効なままです。
• 継続的なヘルス監視: BGP 更新が凍結されても、トンネルヘルスチェックは稼働し続けます。これらはすべての Cloudflare データセンターから送られ、どのイングレスノードのエッジでも、ルーターへの物理接続の障害を検出できます。ヘルスチェックが失敗すると、エッジのイングレスノードはそのパスの優先度を下げ、ルーティング状態が凍結されていてもブラックホールへ送ることを防ぎます。
• 更新の凍結: この状態ではグローバルコントロールプレーンは凍結されます。ルーターから受信した新しい BGP 更新はエッジでローカルに保持され、集中リレーへの接続が復旧するまでグローバルには伝播しません。
• Magic Transit エッジ広告: この凍結状態でも、BYOIP プレフィックスは Cloudflare のグローバルエッジで広告され続けます。API またはダッシュボードでこの広告状態を手動変更できます。

Cloudflare エッジと集中リレーの接続が復旧すると、システムは自動で Edge Resiliency Mode を抜け、ステートフルな再同期を行います。

1. RIB からリレーへの同期: エッジは現在保持しているすべての BGP 更新（現在の RIB 状態）をリレーへプッシュします。
2. グローバル更新: リレーはこれらの更新を調停し、変更を Cloudflare グローバルネットワークの残りへ伝播します。
3. FIB の凍結解除: エッジのローカル転送テーブルの凍結を解除し、最新の検証済みルーティング指示で更新します。

Magic Transit の BGP ピアリングは Magic Transit ネットワークルーティングテーブルとのピアリングです（Cloudflare インターネットグローバルネットワークとのピアリングではありません）。このガイドに従って設定した BGP ピアは、Magic Transit ネットワークルーティングテーブル内のすべてのプレフィックスに加え、オンランプの Advertised prefix list で設定した追加プレフィックスの広告を受け取ります。

代わりに Cloudflare データセンターの 1 つで Cloudflare ASN 13335 とのパブリックピアリングを行う場合は PNI とピアリングのセットアップ を参照してください。同じ物理インターコネクトポートで Magic Transit Virtual Network BGP ピアリングと PNI を共有することは、現時点ではできません。

Cloudflare は機器から受信したルートを Magic Transit Virtual Network ルーティングテーブルへ再配布します。

Magic Transit Virtual Network ルーティングテーブル内のすべてのルートは BGP ピアへ広告されます。各 BGP ピアは、選択した Cloudflare 側 ASN ↗ が prepend された完全な AS_PATH とともに各プレフィックスルートを受け取ります。ピアが正確に ループ防止 ↗ を行えるようにするためです。

BGP ピアリングセッションは、到達可能なプレフィックスをピアへ広告し、以前広告したプレフィックスを撤回できます。この伝播は数分以内です。

Cloudflare は次のタイマーを使い、設定変更はできません。

• Hold timer: BGP ピアが keepalive、update、notification メッセージを待ってから BGP セッションをダウンと宣言するまでの最大時間です。Cloudflare はこのデフォルト hold timer と、open メッセージでピアから受け取った値の小さい方を使います。
• Keepalive timer: BGP システムは keepalive メッセージを交換し、ピアルーターが到達可能かを判定します。hold timer 内に keepalive メッセージが届かないと、セッションはダウンとみなされ、BGP プロトコルレベルでピアが到達不能であることを示します。
• Graceful restart timer: ピアが graceful restart を開始したあと、ルーターがピアの BGP セッション再確立を待つ時間です。この時間内にピアが再接続しないと、ルーターはセッションをダウンと宣言し、古いルートを削除します。

BGP multipath に対応します。BGP が 2 つの異なるインターコネクトで同じプレフィックスを学習すると、Cloudflare はそのプレフィックス宛てのトラフィックを通常の ECMP 挙動に従って各インターコネクトへ分散します。

BGP Graceful Restart はパッシブ（helper/aware）モードで対応します。Cloudflare は再起動中のネイバーの転送状態を維持します。

BGP サポートには現在次の制限があります。

• Cloudflare アカウントの ASN と機器の ASN は異なる必要があります。eBGP のみ対応です。
• Cloudflare は常に優先度 100 でルートを注入します。
• Bidirectional Forwarding Detection（BFD）は非対応です。
• IPsec/CNI（ベータ）で BGP を使う場合、Cloudflare 側の ASN を 13335 にする必要があります。プライベート ASN はまだ非対応です。

Magic Transit のお客様では、Magic Transit Virtual Network ルーティングテーブルとの BGP は、Cloudflare エッジでの anycast プレフィックス広告から分離されています。Anycast の撤回は プレフィックスを広告する に記載の既存方法で制御する必要があります。

BGP とあわせて レガシーヘルスチェック を有効にする必要があります。特定の Cloudflare データセンターが機器から到達可能かを判定するために不可欠です。トンネルヘルスチェック は、動的に学習した BGP ルートのルート優先度を変更します。