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

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

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

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

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

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 のカスタマーサービスマネージャーに連絡してください。

仮想ネットワークで設定したどのルートにもトラフィックが一致しない場合、Cloudflare は宛先アドレスの種類に応じてデフォルトの動作を適用します。

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

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

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

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

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

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

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

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

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

さらに、同じプレフィックス長と優先度の BGP ルートが複数ある場合、ECMP は equal-cost multi-path (ECMP) routing を使ってトラフィックを分散します。

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 path で自分の 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 は communities と AS prepending を併用する場合にルート優先度を調整します。たとえば、ルートに 13335:60150 が付くとベース優先度は 150 になります。ASN を 2 回 prepend すると、Cloudflare は prepend ごとに 10 を加算し、ルート優先度は 180 になります。

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

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

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

• 戻りルートが不要になる: 新しい TCP 接続（TCP SYN）、UDP、ICMP echo トラフィックなど、対応するトラフィック種類では、発信元のトンネルまたはインターコネクトへトラフィックを戻すためのルーティングテーブルエントリが不要になります。
• フローの対称ルーティングを維持する: あるフロー（例: TCP セッション）への応答は、最初のリクエストを運んだ同じ Cloudflare WAN 接続を通って戻ります。ステートフルファイアウォールやミドルボックスにとって重要です。
• 重複する IP 空間をサポートする: 戻り経路はルーティングテーブルの宛先プレフィックスではなく、学習した接続状態に結びつくため、異なるサイトが重複するプライベートアドレス空間を使うシナリオを Automatic Return Routing はサポートできます。
• 接続単位で動作する: この動作を使う 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 dashboard では、ルートを管理する場所にルーティングモードが表示されます。

• 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 から IPsec、GRE から GRE、CNI から CNI）では、WAN ルーティングテーブル内で最長プレフィックス一致が適用されます。このトラフィックは Zero Trust ルーティングと相互作用しません。

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

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 routing は、パケット ↗ データから計算したハッシュでルートを決めます。ハッシュは常に送信元と宛先の IP アドレスを使います。TCP と UDP パケットでは、送信元ポートと宛先ポートもハッシュに含まれます。ECMP アルゴリズムは、各パケットのハッシュを等コストのネクストホップ数で割ります。剰余（remainder）がパケットの通るルートを決めます。

ECMP を使うと、次の結果になります。

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

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

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

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has three tunnel routes, with traffic equally distributed across two paths.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z("Load balancing for some <br> priority tunnels uses ECMP <br> (hashing on src IP, dst IP, <br> scr port, dst port)") --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"GRE Tunnel 1 / <br> priority 1 / <br> ~50% of flows"/] --> I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP] --> G[/"GRE Tunnel 2 / <br> priority 1 / <br> ~50% of flows"/] --> J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] --> H[/GRE Tunnel 3 / <br> priority 2 / <br> 0% of flows/] --o K{{Customer <br> data center/ <br> network 3}}

お客様ルーターの障害

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

flowchart LR
accTitle: Tunnels diagram
accDescr: This example has Tunnel 2 unhealthy, and all traffic prioritized to Tunnel 1.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z(Tunnel health is <br> determined by <br> health checks that <br> run from all Cloudflare <br> data centers) --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP] --> F[/"Tunnel 1 / <br> priority 1 / <br> ~100% of flows"/]:::green --> I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP] --> G[/Tunnel 2 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] --> H[/Tunnel 3 / <br> priority 2 / <br> 0% of flows/] --o K{{Customer <br> data center/ <br> network 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: Tunnels diagram
accDescr: This example has Tunnel 1 and 2 unhealthy, and all traffic prioritized to Tunnel 3.

subgraph Cloudflare
direction LR
B[Cloudflare <br> data center]
C[Cloudflare <br> data center]
D[Cloudflare <br> data center]
end

Z(Lower-priority tunnels <br> are used when <br> higher-priority tunnels <br> are unhealthy) --- Cloudflare
A((User)) --> Cloudflare --- E[Anycast IP]
E[Anycast IP]  -- Intermediary <br> network issue -->  F[/Tunnel 1 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x I{{Customer <br> data center/ <br> network 1}}
E[Anycast IP]  -- Intermediary <br> network issue -->  G[/Tunnel 2 / <br> priority 3 / <br> unhealthy / 0% of flows/]:::red --x J{{Customer <br> data center/ <br> network 2}}
E[Anycast IP] -->  H[/Tunnel 3 / <br> priority 2 / <br> 100% of flows/]:::green --> K{{Customer <br> data center/ <br> network 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 dashboard または 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 データセンターで Cloudflare ASN 13335 とパブリックピアリングしたい場合は、PNI とピアリングのセットアップ を参照してください。同じ物理インターコネクトポートで Cloudflare Virtual Network の BGP ピアリングと PNI を共有することは、現在できません。

Cloudflare は、デバイスから受信したルートを Cloudflare Virtual Network のルーティングテーブルへ再配信します。Cloudflare WAN と Magic Transit の両方がこのテーブルを使います。

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

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

Cloudflare は次のタイマーを使います。これらは設定できません。

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

BGP multipath はサポートされます。2 つの異なるインターコネクトで BGP が同じプレフィックスを学習した場合、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 を使っている場合は、よく知られたアプリケーションに基づいてトラフィックを誘導することもできます。アプリケーション認識ポリシーは、管理が簡単になり、トラフィックフローをより細かく制御できます。

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