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

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

Cloudflare 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 接続のあいだの Cloudflare WAN パケット転送。

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

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

• RFC 1918 ↗ アドレス空間。具体的には 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。

Cloudflare WAN と Cloudflare Tunnel を併用する場合は、Cloudflare WAN の静的ルートを選ぶときに Cloudflare Tunnel の静的ルートで使う IP レンジを考慮してください。詳細は Cloudflare Tunnel を参照してください。

RFC 1918 外のプレフィックスについては、Cloudflare のカスタマーサービスマネージャーに連絡してください。

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

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

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

• 値が小さいほど優先度が高いです。
• プレフィックスエントリの優先度が一致すると、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 はそれを Cloudflare 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 になります。

Automatic Return Routing（ARR）は、Cloudflare WAN（旧 Magic WAN）接続拠点からのネットワークフローを追跡し、静的または動的ルートなしで、受信した接続へ戻りトラフィックを戻します。この機能には Unified Routing モード が必要です。

戻り経路に静的または動的ルートを頼らず、Cloudflare WAN はフローを学習し、あるフローが到着した接続を記憶します。一致する戻りトラフィックに対して、Cloudflare WAN はこの学習済み状態でネクストホップを選びます。設定が簡単になり、管理するルート数が減り、ステートフルトラフィックの対称性を保つのに役立ちます。

ARR の利点は次のとおりです。

• 戻りルートが不要: 新しい TCP 接続（TCP SYN）、UDP、ICMP echo などの対応トラフィック種別では、Cloudflare WAN は発信元トンネルまたはインターコネクトへ戻すためのルーティングテーブルエントリを必要としません。
• フローの対称ルーティングを維持: 特定フロー（TCP セッションなど）への応答は、最初のリクエストを運んだ同じ Cloudflare WAN 接続経由で戻ります。ステートフルファイアウォールとミドルボックスにとって重要です。
• 重複する IP 空間をサポート: 戻り経路はルーティングテーブルの宛先プレフィックスではなく学習した接続状態に紐づくため、異なるサイトが重複するプライベートアドレス空間を使うシナリオにも対応できます。
• 接続単位で動作: この挙動を使う IPsec / GRE トンネルまたはネットワークインターコネクトを、接続ごとに有効にして決めます。

Automatic Return Routing（ARR）の対象トラフィックが ARR 有効の接続に到着すると、Cloudflare WAN は次を記録するフローエントリを作ります。

• 送信元と宛先の IP アドレス
• プロトコルに応じた関連ポートまたは識別子
• トラフィックが到着した接続（トンネルまたはインターコネクト）

このフローに一致し、ネクストホップが必要な後続パケットに対して、Cloudflare WAN は次を行います。

1. 一致する Automatic Return Routing フローがあるかを確認します。
2. 一致があれば、Cloudflare Virtual Network ルーティングテーブルを参照せず、フローを学習した同じ接続へパケットを戻します。

ネットワークからインターネットへの最初のリクエストは、設定済みの静的または BGP ルートを使います。ARR が影響するのは、フロー学習後の対応トラフィックの戻り経路だけです。

Automatic Return Routing が適用されるのは次の場合です。

• 機能が有効なトンネルまたはネットワークインターコネクトでトラフィックを受信した。
• 受信トラフィックが次のいずれかである。
  • 新しい TCP 接続（TCP SYN）
  • UDP
  • ICMP echo（ping）リクエスト
• トラフィックの宛先が次のいずれかである。
  • Cloudflare 経由のインターネットエグレス
  • Cloudflare One Client
  • Cloudflare Tunnel で Cloudflare に接続されたプライベートネットワーク
  • Cloudflare Mesh で Cloudflare に接続されたプライベートネットワーク

ARR は Cloudflare WAN 接続間のトラフィック（たとえばある IPsec/GRE トンネルまたはインターコネクトから別へのトラフィック）のルーティングは変えません。そのトラフィックは、設定済みの Cloudflare WAN ルートに従い続けます。

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

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

• 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. アカウントチームに変更を依頼し、受け入れ可能な時間帯の範囲を伝えます。

アカウントが Zero Trust ルート（Cloudflare Tunnel、Cloudflare Mesh）と WAN ルート（IPsec、GRE、CNI）の両方を使う場合、ルート選択の挙動は ルーティングモード に依存します。

Unified Routing はすべての接続種別に単一のルーティングファブリックを使います。ルート選択は、すべてのトラフィック種別と接続方法に対して最長プレフィックス一致を一貫して適用します。

プレフィックス長が同じときは、Zero Trust ルートが WAN ルートより優先されます。

サイト間で IP 空間が重複するシナリオでは、Automatic Return Routing を有効にし、戻りトラフィックが正しいオリジンへ届くようにします。

Legacy Routing を使うアカウントでは、ルート選択はトラフィックの送信元に依存します。

Zero Trust のみのアカウントでは、Cloudflare One Client トラフィックは Zero Trust IP ルーティングテーブルのみを使い、最長プレフィックス一致に従います。

アカウントで Cloudflare WAN が有効な場合、Cloudflare One Client からのトラフィックは Gateway 付きのサイト間トラフィック と同じルート選択挙動に従います。WAN が有効でないかのように Cloudflare One Client を動かし続けたい場合は、アカウントチームに連絡してください。

Gateway フィルタを必要としない WAN 接続間のトラフィック（IPsec 間、GRE 間、CNI 間）では、WAN ルーティングテーブル内で最長プレフィックス一致が適用されます。このトラフィックは Zero Trust ルーティングと相互作用しません。

Gateway ネットワークポリシー をサイト間 WAN トラフィックに適用すると、ルート選択は次の規則に従います。

Legacy Routing は 2 つのルーティングコンポーネントを使います。

• Zero Trust ルーティング（Cloudflare One Client、Cloudflare Tunnel、Cloudflare Mesh を扱う）
• WAN ルーティング（IPsec、GRE、CNI を扱う）

システム横断トラフィックは Gateway 付きのサイト間トラフィック と同じ規則に従います。より具体的な Zero Trust ルートは正しく動作します。より具体的な WAN ルートが選ばれることは保証されません。

推奨: 重複が必要な場合は、Unified Routing へのアップグレード方法 に従ってください。

アカウントのルーティングモードを確認する手順は次のとおりです。

1. Routes に進みます。

2. ページ上部のバナーを確認します。
   • Your account is using Unified Routing mode. — アカウントは Unified Routing です。
   • Unified routing is available. — アカウントは Legacy Routing です。

アカウントが Legacy Routing の場合は、Unified Routing へのアップグレード方法 に従ってください。

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

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

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

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

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

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

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

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}}

お客様ルーターの障害

Cloudflare WAN ヘルスチェックが Tunnel 2 を不健全と判定すると、Cloudflare WAN はそのルートの優先度を動的に下げ、Tunnel 1 だけが最優先ルートになります。その結果、Cloudflare WAN は 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）の障害

Cloudflare WAN が 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

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

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

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

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

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

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

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

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

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

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

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

Cloudflare 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 更新はエッジでローカルに保持され、集中リレーへの接続が復旧するまでグローバルには伝播しません。

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

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

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

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

Cloudflare は機器から受信したルートを、Cloudflare WAN と Magic Transit の両方が使う Cloudflare Virtual Network ルーティングテーブルへ再配布します。

Cloudflare 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 はまだ非対応です。

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

デフォルトでは、Cloudflare はネットワーク層の特性（IP、ポートなど）に基づいてトラフィックを分散し誘導します。Cloudflare WAN Connector を使う場合は、よく知られたアプリケーションに基づいてトラフィックを誘導することもできます。アプリケーション認識ポリシーは、管理を簡単にし、トラフィックフローをより細かく制御します。

詳細は アプリケーションとアプリタイプ を参照してください。