Cloudflare のアカウントチームが CNI の適格性とポートの空き状況を判断します。特に次のとおりです。
- CNI ポートは現在、Enterprise 顧客に無償で提供しています。
- 非 Enterprise 顧客(および第三者)は、オープンピアリングポリシー ↗ に従って Internet Exchange 経由で Cloudflare とピアできます。
- CNI は一部の Cloudflare データセンターで利用できます。
- そのロケーションで提供される Dataplane の種類が、MTU などサポートされる接続の仕様を決めます。
- ロケーションで提供される多様性は異なります。
- CNI v1 を運用するには、BGP セッションが確立されている必要があります。
Cloudflare とピアするには、IPv4 では /24 以下、IPv6 では /48 以下のプレフィックス長でプレフィックスをアドバタイズします。
CNI は、Cloudflare とのプライベートなポイントツーポイント IP 接続を提供します。技術仕様の異なる 2 つの Dataplane があります。
| Dataplane v1 | Dataplane v2 | |
|---|---|---|
| Magic Transit Direct Server Return (DSR) インターネットから公開ネットワークへのすべての受信(ingress)トラフィックに対する分散型サービス拒否(DDoS)保護。送信(egress)トラフィックは ISP 経由で送ります。 |
相互接続回線上に GRE トンネルを確立した場合でも、しなくてもサポートされます。 | サポートされます。 |
| Magic Transit with Egress インターネットから公開ネットワークへのすべての受信トラフィックに対する DDoS 保護。送信トラフィックは Cloudflare 経由で送ります。 |
相互接続回線上に GRE トンネルを確立した場合にサポートされます。 | サポートされます。 |
| Cloudflare WAN and Zero Trust Zero Trust のユーザーとアプリケーションを、すべてのサイト、データセンター、クラウドとつなぐ、安全なプライベートネットワークバックボーンを構築します。 |
相互接続回線上に GRE トンネルを確立した場合にサポートされます。 | サポートされます。 |
| Peering 1 つの Cloudflare PoP(Point of Presence)と公開ルートを交換します。 |
サポートされます。 エッジデータセンターに接続するすべてのお客様は、その PoP で AS13335 と公開ルートを交換します。接続は各 PoP ごとに確立されます。Cloudflare ネットワーク内の他のエッジ拠点のルートは利用できない場合があります。お客様がアドバタイズしたプレフィックスのルートは、接続した PoP でのみ利用できます。 |
サポートされません。 |
| Application Security and Performance Web アプリケーションのパフォーマンスとセキュリティを向上させます |
ピアリング経由でサポート: レイテンシが最も低いと判断された場合、お客様は Argo Smart Routing を使って、エッジピアリング接続経由でオリジン向けトラフィックを送れます。一部のトラフィックと障害時には必ず使う、直接のインターネット接続を維持する必要があります。 Magic Transit 経由でサポート: Magic Transit で保護されているオリジンサーバーの IP アドレスを使う製品を設定できます。Magic Transit はこのトラフィックをオーバーレイ経由で送り、お客様は Magic Transit Virtual Network のルーティングテーブルで相互接続のネクストホップを制御できます。 |
オリジン IP が CNI v2 上の Magic Transit の背後にある場合、公開オリジンで動作するすべての Cloudflare サービス(Load Balancer、WAF、Cache など)は CNI 上で動作します。 |
詳細は 前提条件のセクション を参照してください。
- サポートするポート種類:
- Dataplane v1: 10GBASE-LR(シングルモードファイバー)と 100GBASE-LR(シングルモードファイバー)。
- Dataplane v2: 10GBASE-LR(シングルモードファイバー)と 100GBASE-LR4(シングルモードファイバー)の光学モジュールをサポートします。
- 距離の制限: Cloudflare は 10 km を超える光リンクをサポートしません。より長い距離では、接続を延ばすために中間ハードウェアまたは第三者プロバイダーが必要です。
- IP アドレッシング: すべての CNI 接続と Partner CNI 接続は、ルーターと Cloudflare のあいだのポイントツーポイント IP 接続に
/31サブネットを使います。 - VLAN サポート:
- Dataplane v1: CNI ポートには単一の 802.1Q VLAN タグを割り当てられます。
- Dataplane v2: VLAN タグ付け(802.1Q)と QinQ はまだサポートされていません。
- MTU の考慮:
- Dataplane v1: Cloudflare からお客様へのトラフィック(イングレス)ではネイティブ 1,500 バイト MTU をサポートしますが、お客様から Cloudflare へのトラフィック(エグレス)では 1,476 バイト MTU が必要です。
- Dataplane v2: GRE 要件なしで、双方向の最大 MTU 1,500 バイトをサポートします。
- Bidirectional Forwarding Detection (BFD):
- Dataplane v1: BFD は BGP セッションの高速障害検出を提供し、直接接続でサポートされます。BFD を有効にするには、アカウントチームに連絡してください。CNI 上の BFD は、別のヘルスチェックに依存する IPsec / GRE トンネルのフェイルオーバー時間には影響しません。
- Dataplane v2: まだサポートされていません。
- Link Aggregation Control Protocol (LACP):
- Dataplane v1: 帯域を増やしリンクの耐障害性を提供するため、Cloudflare は複数の物理 CNI ポートを Link Aggregation Control Protocol (LACP) で 1 つの論理チャネルにまとめることをサポートします。複数接続をバンドルして総スループットを増やし、Cloudflare とのプライベート接続に冗長性を追加できます。
- Dataplane v2: まだサポートされていません。代わりに ECMP を使います。
次は、CNI 接続がサポートする最大スループットです。実際のパフォーマンスは、具体的なユースケースと設定に依存します。
| 方向(ユースケース) | 10G 回線 | 100G 回線 |
|---|---|---|
| Cloudflare からお客様へ(すべてのユースケース) | 最大 10 Gbps | 最大 100 Gbps |
| お客様から Cloudflare へ(ピアリングのユースケース) | 最大 10 Gbps | 最大 100 Gbps |
| お客様から Cloudflare へ(Magic Transit / WAN) | v1: CNI 上の GRE トンネルあたり最大 1 Gbps v2: CNI 接続あたり最大 1 Gbps |
v1: CNI 上の GRE トンネルあたり最大 1 Gbps v2: CNI 接続あたり最大 1 Gbps |
展開を計画するときは、次のサービスレベルを考慮します。
- 正式な SLA なし:
- CNI は現在無償で提供され、正式な Service Level Agreement (SLA) ↗ はありません。
- Cloudflare 側の問題で CNI サービスが止まった場合、Cloudflare は復旧に取り組みます。一部の Cloudflare データセンターでは復旧に数日かかることがあります。そのため、別デバイスへのバックアップ接続、またはインターネットトンネル経由のバックアップを常に推奨します。
- オブザーバビリティ: Cloudflare dashboard 内にインターコネクトの設定 / 状態の可視化はありません。
- 可用性: デバイスレベルの多様性をサポートするロケーションでは、接続が別々のデバイスで終端する場合、メンテナンス中も接続を維持できます。単一デバイスの展開では、メンテナンス中にサービスが完全に中断します。
- バックアップ接続: すべての CNI 実装で、代替のインターネット接続をバックアップとして維持する必要があります。
- 容量計画: Cloudflare への利用可能なリンク全体の容量計画は、それらのリンクのトポロジーとサイズに基づいてお客様が担当します。
直接接続は、お客様も所在する任意の Cloudflare データセンターで利用できます。関心のあるロケーションに、ユースケースに合う dataplane バージョンと多様性の要件があるかを確認してください。詳細は 利用できるロケーション を参照してください。
Cloudflare は次を含む主要なグローバルプロバイダーと提携しています: Console Connect、CoreSite、Digital Realty、Equinix Fabric、Megaport、PacketFabric、Zayo。
CNI のプロビジョニングは通常 2〜4 週間かかります。実装の複雑さと第三者プロバイダーのスケジュールによります。最もよくある遅延は、Cloudflare が直接制御できない物理接続フェーズで起きます。
- リクエストを提出する: アカウントチームと協力して CNI リクエストチケットを作成し、希望する CNI の種類、ロケーション、ユースケース、技術詳細を提供します。実装マネージャーがプロセスを案内します。
- 設定を確認する: v1 Dataplane では、実装マネージャーが IP アドレッシング、VLAN、その他の技術仕様をカバーする詳細な設定ドキュメントを提供します。このドキュメントを確認して承認する必要があります。v2 Dataplane では、この手順は不要です。
- 接続を注文する:
- Direct Interconnect の場合、データセンター施設事業者から物理クロスコネクトを注文するための Letter of Authorization (LOA) を Cloudflare から受け取ります。
- Partner Interconnect の場合、提供された詳細を使ってパートナーのポータルから仮想回線を注文します。
- ネットワークを設定する: Cloudflare とお客様のネットワークチームの両方が、承認済みドキュメントに従ってそれぞれのネットワークデバイスを設定します。
- テストして確認する: 接続が物理的に確立されたら、チームは基本的な接続テスト(例: ping)を行い、該当する場合は BGP セッションを確立できることを確認します。
- Magic Transit および / または Cloudflare WAN のトンネルヘルスチェックを有効にします。
- サービスを有効にする: 新しい CNI 経由でトラフィックをルーティングするよう、Cloudflare 製品(例: Magic Transit)を設定します。実装マネージャーは、展開完了とマークする前にエンドツーエンドのトラフィックフローを確認します。
- メンテナンス通知を追加する。
- プロジェクトキックオフ: 最初のキックオフコールで、Cloudflare とスコープとスケジュールを確認します。次の情報を用意してください。
- 希望するコロケーション施設
- 必要なポート速度(10G または 100G)
- Peering / Magic Transit 用の BGP ASN
- BGP パスワード(任意)
- クロスコネクトを注文する: Cloudflare が Letter of Authorization (LOA) を発行します。この文書は、データセンター内の Cloudflare ハードウェア上の特定ポートとお客様の機器のあいだで物理クロスコネクトを注文する許可を与えます。クロスコネクト注文のエンドツーエンドプロセスは、施設プロバイダーによって 1〜2 週間以上かかることがあります。Cloudflare の分界点は、LOA で指定されたポートです。この接続の展開、プロビジョニング、継続的なサポートと運用、および施設プロバイダーと第三者接続プロバイダーとの商取引関係は、お客様の責任です。
Cloudflare は世界の主要な接続プロバイダーと提携しています。Partner Interconnect をプロビジョニングするには、選んだプロバイダーの管理ポータルから接続リクエストを開始します。Cloudflare がリクエストを確認して受け入れ、仮想回線を有効にします。
Cloudflare WAN を使う Enterprise 顧客は、アカウントチームに連絡して Cloud Interconnect を始められます。
Cloudflare WAN 顧客の場合、Cloud Interconnect を使って AWS Direct Connect ↗ に接続できます。Cloud Interconnect は、AWS で物理ポート全体の割り当てを提供する AWS Dedicated Direct Connect をサポートします。AWS Hosted Direct Connect はまだサポートされていません。
AWS Dedicated Direct Connect では、接続速度として 10 Gbps または 1 Gbps を選べます。
AWS Direct Connect に接続する手順は次のとおりです。
- アカウントチームに連絡し、Cloud Interconnect のプロビジョニングを開始します。チームは最適なロケーションを選べるよう、利用できるインターコネクトロケーションと、このプロセスに関わるすべての詳細を伝えます。
- AWS ポータルにログインし、Direct Connect を注文します。
- AWS が Letter of Authorization (LOA) と VLAN ID を提供します。これらをアカウントチームに送ります。
- アカウントチームは、提供した AWS ドキュメントを使って Cloud Interconnect のプロビジョニングを続けます。全体として、このプロセスは約 4 週間で完了します。
-
Cloudflare dashboard で Interconnects を開きます。
Interconnects を開く ↗ -
Create an interconnect を選びます。
-
Cloud Interconnect で Create new を選びます。
-
Google Integration で Select integration を選びます。
-
インターコネクトに名前を付け、任意で説明を付けます。MTU 値が GCP VLAN attachment ↗ で設定した MTU と一致することを確認します。
-
Continue を選びます。
-
Interface speed ドロップダウンメニューからインターフェース速度を選びます。GCP は選んだインターコネクトの速度に基づいて課金します。
-
VLAN attachment pairing key ↗ を入力します。
-
Continue を選びます。
-
提供した詳細を確認し、Confirm order を選びます。
Google Cloud Platform (GCP) インターコネクトが利用可能になるまで数分かかります。BGP セッションは確立されますが、ルートは交換されません。
View interconnects を選ぶと、アカウント上のすべてのインターコネクトの一覧が表示されます。インターコネクト名を選ぶと、インターコネクトの詳細が表示されます。インターコネクトには一意の Interconnect ID があります。
Google Cloud Interconnect を設定したあと、インターコネクトを使うためにルートを追加する必要があります。
- GCP へトラフィックを向けるために、Cloudflare Virtual Network のルーティングテーブルにルートを作成するには:
- 障害を検出して代替パスへトラフィックを誘導する レガシー双方向トンネルヘルスチェック 付きの 静的ルート を Cloudflare WAN ルーティングテーブルに追加します。
- GCP Cloud Router が BGP でアドバタイズするルートは無視されることに注意してください。
- Cloudflare へトラフィックを向けるために、GCP ルーティングテーブルにルートを作成するには、GCP Cloud Router を使う必要があります。
- Cloud Router にカスタム学習ルートを追加 ↗ します。
- BGP セッションを使います。アカウントチームに連絡し、アドバタイズする 1 つ以上のプレフィックスの一覧を依頼し、アドバタイズしたいインターコネクト ID を指定します。