Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

プレフィックスを広報する

最終更新 Markdown で表示Agent セットアップ

プレフィックスをオンボードする

Magic Transit で使うために、独自の公開 IP アドレスを Cloudflare へ持ち込めます。これは bring your own IP（BYOIP）とも呼ばれます。このプロセスには、次の 2 種類のプレフィックスがあります。

  1. IP プレフィックス: Cloudflare へ持ち込む各 IP アドレスブロックには、IP プレフィックスエントリが必要です。IP プレフィックスには、Cloudflare がそのネットワークまたはサブネットを広報することを許可する権限（Letter of Agency（LOA））が含まれます。広報する AS パスに含める省略可能な Autonomous System Number（ASN） ↗ も定義できます。
  2. BGP プレフィックス: Cloudflare がグローバルネットワークから広報するプレフィックスを制御します。デフォルトでは、各 IP プレフィックスに一致する BGP プレフィックスが 1 つあります。追加の、より具体的な BGP プレフィックス（IP プレフィックスのサブネット）を、最大プレフィックス長 /24 まで設定できます。

IP プレフィックス

Cloudflare は、定義した BGP プレフィックスの数に基づいて Magic Transit のプレフィックス数を計測します。重なっていても、各プレフィックスは個別に課金されます。たとえば /16 と、その中の任意の /24 はそれぞれ個別に数えられます。より大きな集約プレフィックスをオンボードしても、より小さなサブネットが広報または課金の対象に自動では含まれません。

受け入れるプレフィックスサイズに課金上限はありません。ただし、オンボードで受け付けるのは /24 までのプレフィックスです。より長いプレフィックス（/25、/26 など）はグローバルにルーティングできないためです。

オンボード予定のすべての IP プレフィックスと、それらを広報する ASN を提供します。プレフィックスを指定するときは、次のガイドラインに従います。

  • プレフィックスには少なくとも 256 個の IP アドレス（CIDR（Classless Inter-Domain Routing ↗）表記で /24）が必要です。/24 のプレフィックス長要件を満たさない場合は、Cloudflare IP を使う を参照してください。
  • Internet Routing Registry のエントリと LOA は、Cloudflare に提出するプレフィックスおよび起点プレフィックスと一致する必要があります。
  • 連続するプレフィックスを使う場合は、可能な限り集約プレフィックスを指定します。
  • resource public key infrastructure（RPKI） ↗ のルートに署名するために Route Origin Authorizations（ROAs）を使う場合、プレフィックスと起点 ASN はオンボード提出と一致する必要があります。
  • ASN を所有していない場合は、Cloudflare Customer ASN（AS13335）を使えます。

Cloudflare ASN と独自 ASN

IP プレフィックスのオンボードプロセスの一環として、Cloudflare がプレフィックスを広報するときに使う ASN を決める必要があります。独自 ASN を提供する場合、Cloudflare は BGP AS_PATH にメインの Cloudflare ASN（AS13335）を前置します。たとえば ASN が AS64496 の場合、Cloudflare と直接ピアしている相手はパスを 13335 64496 として見ます。

ASN がない場合、または ASN を Cloudflare へ持ち込みたくない場合は、Cloudflare Customer ASN（AS13335）を使えます。

BGP プレフィックス

BGP プレフィックスは、Cloudflare がグローバルネットワークから anycast 経由で広報するプレフィックスを表します。デフォルトでは、オンボードした IP プレフィックスと同一の BGP プレフィックスが少なくとも 1 つあります。

たとえば /20 の IP プレフィックスを Magic Transit にオンボードした場合、デフォルトの /20 BGP プレフィックスしかないため、/20 としてしか広報できません。その /20 内のより小さなサブプレフィックス（/24 など）は、別の BGP プレフィックスとして設定しない限り、個別には広報できません。

BGP プレフィックス広報の制御方法

Cloudflare は、オンデマンドプレフィックスの広報と撤回を制御する複数の仕組みを提供します。各方法は異なるデプロイシナリオに対応します。

  • Addressing API: API 呼び出しでプレフィックス広報を手動制御します。BGP プレフィックスを広報または撤回する を参照してください。
  • ルートリフレクターとの BGP peering: インターネット経由、または Dataplane v1 の CNI 接続経由で、Cloudflare のグローバルに分散したルートリフレクターへの BGP セッションで広報を制御します。このオプションが必要な場合は、Cloudflare アカウントチームに連絡してください。Cloudflare Route Reflectors による BGP 制御 を参照してください。
  • Network Flow: ネットワークで観測した、ユーザー定義のトラフィックしきい値に基づいてプレフィックスを自動広報します。Network Flow（旧 Magic Network Monitoring）を参照してください。
  • Magic Transit ネットワークルーティングテーブルとの BGP peering: Dataplane v2 の CNI（クローズドベータ）、または GRE および IPsec トンネル（ベータ）経由で学習した BGP ルートに基づいて、プレフィックス広報を自動制御します。この方法には Unified Routing が必要です。Magic Transit Virtual Network ルーティングテーブルへの BGP 制御 を参照してください。

BGP プレフィックスを管理する

BGP プレフィックスを追加する

BGP プレフィックスを追加するには POST リクエスト を作成します。例:

Create BGP Prefixbash
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"cidr": "192.0.2.0/24"
	}'

BGP プレフィックスを広報または撤回する

  1. Routes ページを開きます。
Routes を開く ↗
  1. IP prefixes タブで、変更したいプレフィックスを選択し、Edit を選択します。
  2. Status ドロップダウンメニューから Advertised または Withdrawn を選択します。
  3. （省略可）プレフィックスの説明を編集します。
  4. Edit IP Prefix を選択して変更を保存します。

設定済みの任意の BGP プレフィックスは、PATCH リクエスト を使う API で制御できます。例:

Required API token permissions

At least one of the following token permissions is required:
  • Magic Transit Write
  • IP Prefixes: Write
  • IP Prefixes: BGP On Demand Write
Update BGP Prefixbash
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"on_demand": {
				"advertised": true
		}
	}'

IP プレフィックスを削除する

削除できるのは Unapproved ステータスのプレフィックスだけです。別のステータスのプレフィックスを削除するには、管理者またはアカウントマネージャーに連絡してください。

  1. Routes ページを開きます。
Routes を開く ↗
  1. IP Prefixes タブで、変更したいプレフィックスを探し、Delete を選択します。
  2. モーダルで Delete を選択して確定します。

API で BGP プレフィックスの AS prepend を設定する

Addressing API を使い、Cloudflare がプレフィックスに Autonomous System Number（ASN）を前置する回数を制御します。プレフィックス向け BGP 更新の AS_PATH で、AS13335 を最大 3 回前置できます。

BGP プレフィックスに AS13335 を 3 回前置する例は次です。

Required API token permissions

At least one of the following token permissions is required:
  • Magic Transit Write
  • IP Prefixes: Write
  • IP Prefixes: BGP On Demand Write
Update BGP Prefixbash
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"asn_prepend_count": 3
	}'

AS prepend は、ネットワークプロバイダー間でトラフィックを円滑に移行するのに役立ちます。Cloudflare の広報に prepend を追加すると、一部のインターネットネットワークプロバイダーにとって Cloudflare 経由のルートが優先されにくくなります。同じプレフィックスを、より短く望ましい AS_PATH で代替プロバイダーから同時に広報できます。両方のプロバイダーから同時に広報すると、トラフィック移行がスムーズになり、プロバイダー変更中のパケットロスを最小化します。

"asn_prepend_count" パラメーターは 0 から 3 の値を受け付けます。値が大きいほどルートは優先されにくくなります。このパラメーターは BGP でも変更できます。コミュニティを使って anycast プレフィックスの AS prepend を設定する を参照してください。

AS prepend を使って Magic Transit からトラフィックを移行するときの、典型的な一連の流れは次です。

  • 初期状態: Cloudflare はデフォルトの優先度（"asn_prepend_count": 0）でプレフィックスを広報します。Cloudflare はすべてのトラフィックを、Cloudflare グローバルネットワーク経由でネットワークへルーティングします。
  • Cloudflare の優先度を下げる: API 経由でプレフィックスを更新し、AS prepend 回数を設定します（たとえば "asn_prepend_count": 3）。Cloudflare はより長い AS_PATH でプレフィックスを広報します。外部ネットワークは BGP テーブルを更新し、Cloudflare パスが新しい、より長い AS_PATH を持つことを認識します。
  • 新しいプロバイダーを導入する: 標準の（より短い）AS_PATH で、代替プロバイダーから同じプレフィックスの広報を始めます。
  • 最終状態: 外部ネットワークは 2 つの広報を受け取ります。Cloudflare 経由の prepend 済みルートと、新しいプロバイダー経由の prepend なしルートです。外部ネットワークは BGP ポリシールールに基づいてパスを選びます。

BYOIP プレフィックスを安全に撤回する

スタックした BGP ルートの緩和

Bring Your Own IP（BYOIP） プレフィックスのトラフィックを Cloudflare エッジから外す準備をするとき、BGP を直接撤回すると、スタックした BGP ルートのリスクがあります。この状態は、ルートがインターネットの Default-Free Zone（DFZ） ↗ に残ってしまうときに起きます。撤回アナウンスを受け取れなかったコアルーターは、すでに無効なネクストホップへトラフィックを転送し続けます（いわゆるブラックホールです）。詳細はブログ記事 BGP zombies and excessive path hunting ↗ を参照してください。

このリスクは、グローバルルーティングテーブルが、より具体的なプレフィックスからより広いプレフィックスへのフォールバックに依存している場合に特に現れます。このフォールバックはルートの不安定化を招きやすいため、Cloudflare は複数ステップのドレイン手順を推奨します。

BYOIP の複数ステップ撤回手順

トラフィックをドレインするときは、Cloudflare と ISP（インターネットサービスプロバイダー）で同じプレフィックス長を使ってください。プレフィックス長を揃えると、いちばん確実で予測しやすい動きになります。

クリーンなトラフィック切り替えを行い、ブラックホールを防ぐための、推奨する複数ステップのドレイン手順は次のとおりです。

  1. オリジンネットワークからアドバタイズを開始する: 同じ長さのプレフィックス（例: 192.0.2.0/24）を、自社インフラから上流のインターネットサービスプロバイダー（ISP）へアナウンスし始めます。これにより、同じ長さの競合ルートがグローバルルーティングテーブルに入ります。BGP のベストパス選択は、ほかの指標（例: より短い AS パス長やローカルプリファレンス）に基づいて自社のネイティブルートを優先するため、トラフィックは Cloudflare エッジから離れ始めます。ISP がルートをどう優先するかによって、一部のトラフィックは想定どおりにルーティングされないことがあります（例: Cloudflare のルートを完全に撤回しないと、優先度の低いパスとして扱われる場合があります）。

  2. グローバル BGP の収束を待つ: 新しいネイティブアドバタイズがグローバルルーティングテーブル全体に伝わり、ルートが収束するまで時間を置きます（通常は 5〜10 分）。この待機で、次のステップの前に大半のトラフィックが自社ネットワークへ移ったことを確認します。

  3. Cloudflare エッジから BGP 撤回を通知する: トラフィックが正常にドレインされたことを確認したら、BGP 制御方法のいずれかを使って、Cloudflare エッジからのプレフィックスアドバタイズを停止します。

  4. ドレイン手順は完了です。

Magic Transit Virtual Network ルーティングテーブルへの BGP 制御

anycast ベースの Magic BGP ルートを自動広報および撤回する

Dataplane v2 の CNI、GRE、または IPsec トンネルを使う場合、次ができます。

  • Magic Transit Virtual Network ルーティングテーブルから一致するすべての学習済み BGP プレフィックスを撤回したときに、Cloudflare のグローバルエッジインフラストラクチャからプレフィックスを自動撤回する。
  • Magic Transit Virtual Network ルーティングテーブルに一致する学習済み BGP プレフィックスが少なくとも 1 つあるときに、Cloudflare のグローバルエッジインフラストラクチャ経由でプレフィックスを自動広報する。

自動のグローバル広報と撤回を有効にするには、Addressing API を使って BGP プレフィックスでこの機能を有効にします。例:

Required API token permissions

At least one of the following token permissions is required:
  • Magic Transit Write
  • IP Prefixes: Write
  • IP Prefixes: BGP On Demand Write
Update BGP Prefixbash
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/addressing/prefixes/$PREFIX_ID/bgp/prefixes/$BGP_PREFIX_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"auto_advertise_withdraw": true
	}'

BGP プレフィックスにこれを設定すると、Cloudflare は次のロジックを適用します。

  • Magic Transit Virtual Network ルーティングテーブルに、BGP プレフィックスと完全一致する BGP ルートがない場合、Cloudflare は BGP プレフィックスを撤回します。
  • Magic Transit Virtual Network ルーティングテーブルに、BGP プレフィックスと完全一致する BGP ルートが少なくとも 1 つある場合、Cloudflare は BGP プレフィックスを広報します。

Addressing API の BGP プレフィックスと、Magic Transit Virtual Network ルーティングテーブルの BGP ルートは完全一致（同じ IP プレフィックスと CIDR プレフィックス長）する必要があります。サブネットまたはスーパーネットへの有効なルートがあっても、完全一致する Magic Transit Virtual Network BGP ルートがない場合、Cloudflare は BGP プレフィックスを撤回します。

コミュニティを使って anycast プレフィックスの AS prepend を設定する

API で anycast プレフィックスの AS prepend を設定する 代わりに、BGP コミュニティを使い、エッジからプレフィックスを広報するときの AS prepend 回数を制御できます。コミュニティ値は次です。

  • 13335:50101: 13335 ASN を 1 回前置します
  • 13335:50102: 13335 ASN を 2 回前置します
  • 13335:50103: 13335 ASN を 3 回前置します

代替サービスプロバイダーへ切り替える必要がある場合、Cloudflare の ASN を複数回前置できます。通常の目的は、ルートの優先度を下げ、新しいプロバイダーへの円滑な移行を可能にすることです。prepend 回数が多いほど、他の優先順位ルールがない場合に Cloudflare の接続は優先されにくくなります。

この機能に関するピアの動作についての重要な情報は、AS prepend に関する注意 を参照してください。

Cloudflare Route Reflectors による BGP 制御

省略可で、BGP を使い、オンデマンドデプロイシナリオ向けに、Cloudflare のグローバルネットワークからのプレフィックスの広報ステータス（広報または撤回）を制御できます。BGP 制御は、Cloudflare のグローバルに分散した Route Reflectors への BGP セッションを確立することで動作し、それらが Cloudflare のグローバルネットワーク全体へプレフィックス広報を伝播します。インターネットまたは CNI 経由で Cloudflare の Route Reflectors とピアできます。CNI peering はアカウントチーム経由で利用できます。

Cloudflare のネットワークからのプレフィックス広報は、BGP 制御などの対応するオンデマンド方法、または UI、API、Network Flow による動的方法で行えます。オンデマンドプレフィックスのオンボード時に、BGP 制御の広報か、動的広報（ダッシュボード/API/Network Flow）かを指定します。

ネットワークアーキテクチャは、複数の冗長な Route Reflectors を使います。単一のリフレクターの障害は、全体のネットワーク耐障害性やトラフィック転送に影響しません。最大の耐障害性のため、Cloudflare の 3 つの冗長 Route Reflectors すべてとピアすることを推奨します。

BGP 制御の利用を始めるには、次の情報を添えてアカウントチームに連絡してください。

  • BGP エンドポイントの IP アドレス
  • BGP 制御で使いたいプレフィックス
  • BGP セッション用の ASN

情報を受け取ったあと、Cloudflare はファイアウォールフィルターを更新して BGP セッションを確立し、プレフィックスを制御するための BGP エンドポイントを提供します。

ルーター設定の例

次の例は、BGP 制御を使うオンデマンドデプロイ向けの Cisco IOS ↗ と Juniper Junos OS ↗ の peering 設定です。使っている IP アドレスは Cloudflare のルートリフレクターのものなので、そのままにしてください。

Cisco IOS

ip route {{ <YOUR-MAGIC-TRANSIT-PREFIX> }} Null0
ip prefix-list magic-transit-prefix seq 5 permit {{ <YOUR-MAGIC-TRANSIT-PREFIX> }}

route-map cloudflare-magic-transit-out permit 1
match ip address prefix-list magic-transit-prefix
!
route-map cloudflare-magic-transit-out deny 99

route-map reject-all deny 99

router bgp {{ <YOUR-ASN> }}
neighbor 141.101.67.22 remote-as 13335
neighbor 141.101.67.22 ebgp-multihop 64
neighbor 141.101.67.22 timers 60 900
neighbor 162.158.160.22 remote-as 13335
neighbor 162.158.160.22 ebgp-multihop 64
neighbor 162.158.160.22 timers 60 900
neighbor 173.245.63.66  remote-as 13335
neighbor 173.245.63.66  ebgp-multihop 64
neighbor 173.245.63.66  timers 60 900
!
address-family ipv4 unicast
redistribute static
neighbor 141.101.67.22 route-map cloudflare-magic-transit-out out
neighbor 141.101.67.22 route-map reject-all in
neighbor 162.158.160.22 route-map cloudflare-magic-transit-out out
neighbor 162.158.160.22 route-map reject-all in
neighbor 173.245.63.66  route-map cloudflare-magic-transit-out out
neighbor 173.245.63.66  route-map reject-all in
exit-address-family

Juniper MX（Junos OS set コマンド）

set protocols bgp group CF_ROUTE_REFLECTORS neighbor 162.158.160.22 description "CF RR#1 SIN"
set protocols bgp group CF_ROUTE_REFLECTORS neighbor 173.245.63.66 description "CF RR#2 IAD"
set protocols bgp group CF_ROUTE_REFLECTORS neighbor 141.101.67.22 description "CF RR#3 CDG"
set protocols bgp group CF_ROUTE_REFLECTORS peer-as 13335
set protocols bgp group CF_ROUTE_REFLECTORS import REJECT-ALL
set protocols bgp group CF_ROUTE_REFLECTORS export BGP-CONTROL-OUT

set policy-options policy-statement REJECT-ALL then reject
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-filter 104.245.62.0/24 exact
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from protocol static
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> from route-type internal
set policy-options policy-statement BGP-CONTROL-OUT term <TERM-NAME> then accept
set policy-options policy-statement BGP-CONTROL-OUT then reject

Juniper MX（Junos OS XML 形式）

@rtr01> show configuration routing-instances STAGE protocols bgp group CF_ROUTE_REFLECTORS
type external;
multihop {
    ttl 64;
}
local-address {{customer router IP}}
import NONE;
export NONE;
peer-as 13335;
local-as {{customer AS}} loops 2;
neighbor 162.158.160.22 {
    description "CF RR#1 SIN";
}
neighbor 173.245.63.66 {
    description "CF RR#2 IAD";
}
neighbor 141.101.67.22 {
    description "CF RR#3 CDG";
}

BGP peering

Dataplane v2 の CNI、GRE、または IPsec トンネルを使ってネットワークトラフィックを Magic Transit へオンランプする場合、Cloudflare とネットワーク間のトラフィックルーティングに BGP を使う方法は BGP information を参照してください。これは、プレフィックスの広報ステータスを制御する手段としての BGP とは別のオプションです。

リージョン設定

Magic Transit は、Cloudflare のネットワークから設定済みオフランプ（GRE トンネル、IPsec トンネル、または CNI）へトラフィックを誘導するために、静的ルーティングと BGP の両方に対応しています。Cloudflare は現在、トラフィックエンジニアリング目的のルート広報には対応していません。ラストホップの待ち時間を減らすベストプラクティスとして、ルートをリージョン単位でスコープすることを検討してください。

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

リージョンコード リージョン
AFR アフリカ
APAC アジア太平洋
EEUR 東ヨーロッパ
ENAM 北アメリカ東部
ME 中東
OC オセアニア
SAM 南アメリカ
WEUR 西ヨーロッパ
WNAM 北アメリカ西部

静的ルートのリージョンのデフォルト設定は All Regions です。静的ルートの 追加 または 編集 時に、Region code セクションでトラフィックのスコープを設定します。

詳細は 特定リージョンへのルートのスコープ を参照してください。

役に立ちましたか？