BGPの経路・トンネルの疎通・アプリの成功を分けて調べる

緑の表示が三つあっても、答えている問いは違う

拠点のアプリがタイムアウトした。担当者はBGPセッションがEstablishedなので、ネットワークは正常だと考える。別の担当者はトンネルのプローブが成功しているため、アプリも正常だと考える。どちらの観測にも、まだ調べていない範囲がある。

診断する主張を三つに分けよう。経路が広告されて選ばれたこと、狙ったトンネルでプローブが往復したこと、狙ったアプリへのリクエストが成功したこと。経路が正しいサブネットを向いていても、ファイアウォールがサービスのポートを拒否することはある。境界ルーターまでプローブが届いても、その先のバックエンドは停止し得る。これは診断を考えるための独自の例で、Cloudflare上で測定した障害ではない。

10月5日のGA発表で変わったのは提供範囲だ。Unified Routingを使うCloudflare WANとMagic Transitのアカウントでは、IPsec/GRE上のBGPが一般提供となり、個別の有効化手続きが不要になった。CNI上のBGPはclosed betaのまま。GAの発表だけでは、特定の顧客の転送経路が動くことまで確かめられない。

経路を知らせる流れと、パケットを送る流れ

2006年1月のRFC 4271は、BGPが宛先への到達情報と経路属性を交換する仕組みを定める。受信した経路、選んだ経路、広告する経路をそれぞれ区別する。これはプロトコルの基礎であり、後続のRFCによる更新もある。

1. 1CPEの広告方針
2. 2BGPの経路広告
3. 3Cloudflareの経路選択
4. 4転送テーブル

1. 1アプリのパケット
2. 2選択された宛先経路
3. 3トンネル
4. 4アプリの応答

1. 1トンネルのプローブ
2. 2対象からの応答
3. 3トンネルの状態観測

独自の概念図。転送を決めるための情報と、その後に送られるパケットを分けて示している。パケットの採取結果や、Cloudflareの構成全体を示す図ではない。

Cloudflareのtraffic steeringの仕様では、このピアリングは顧客の仮想ネットワーク内にあり、インターネット側のASN 13335とのピアリングとは別に扱われる。学習した経路は分散した転送テーブルへ伝わる。BGPを使ってもトンネルのヘルスチェックは必要だ。仕様にあるEdge Resiliency Modeでは、新しい制御情報が通常どおり伝わらなくても、最後の有効なテーブルで転送が続く場合がある。

したがって、BGPが切れたという情報だけで通信停止を断定せず、経路の古さ、選ばれたnext hop、トンネルの観測、実際のリクエスト結果を揃える。古い経路でも転送が続く可能性があり、セッションが成立していても不適切なプレフィックスが広告され得る。今回の実測結果ではなく、確かめるべき仮説として扱う。

2024年の接続構成から、beta、GAまで

2024年2月7日のSASE発表は、利用者や拠点を異なる入口から接続する構成を説明していた。接続設計の歴史として読めるが、BGPの提供開始日は示していない。2026年1月30日にIPsec/GRE上のBGPがbetaとなり、10月5日にUnified Routingアカウント向けのGAへ進んだ。

今回の調査窓は、Asia/Tokyoの2026年9月6日17:16:05から10月6日17:16:05まで。この章に関係する期間内の、日付を確認できた一次資料の更新は10月のGA発表だ。現在の設定資料は10月6日に確認したが、確認日をリリース日へ置き換えてはいない。

設定値で実験の条件を決める

設定の仕様では、CPE側がトンネルのCloudflare側IPv4インターフェースアドレスへ接続を開始する。eBGPでは両側のASNを異なる値にする。Cloudflareが提示するHold Timeは240秒で、交渉後の値は双方の小さい方となる。サポートする最小値は30秒、推奨は90秒以上。任意のMD5キーはセキュリティ機構ではないと明記され、設定の取り違えを避けるためのものとして説明されている。

下限と推奨を区別しよう。タイマーの実験には、双方の設定値とセッションのイベント記録が必要だ。選んだタイマーの値やセッションの正常表示から、アプリの可用性は測れない。

ヘルスチェックの仕様は、カプセル化したICMPプローブを使う。また、経路の選択に使うトンネルチェックと、選択に使わないエンドポイントチェックを区別する。対象と方向によって、成功が示す範囲は変わる。ICMPの応答を、アプリの正常動作と呼び換えない。

集める証拠	答えられる問い	まだ残る問い
セッション状態と受信プレフィックス	この相手と、この経路を交換したか	経路が選ばれて転送側まで伝わったか
選択経路とnext hop	この宛先にどの経路を使う予定か	いま、その経路でパケットが通るか
プローブの対象・方向・結果	そのプローブが応答を得たか	認証を含むアプリのリクエストが成功したか
アプリのステータス・応答・時刻	このリクエストが合格条件を満たしたか	別の拠点や障害条件でも同じか

独自の調査計画を表にした。すべての機器や管理画面で全項目が取れるという主張ではない。対象環境で現在サポートされる確認手段を選び、証拠には時刻を残す。

合成データで、広告する経路の集合を厳密に点検する

ルーターを変更する前に、その拠点が担当する宛先を明記する。この演習では、承認済みの集合に架空の 10.42.8.0/24 を一つだけ入れる。より具体的な子プレフィックスでも通信は成立し得るが、この演習では承認していない。デフォルト経路の広告は、意図したアプリのネットワークよりも大幅に範囲を広げる。

以下は未実行のオフラインPython演習。入力を厳密に解釈し、集合の完全一致を調べる。ネットワークへのリクエストもルーターの設定も行わない。広告方針の小さな点検用コードであり、BGPのエミュレーターやCloudflare設定の検証器ではない。

from ipaddress import ip_network

allowed = {ip_network("10.42.8.0/24")}
cases = {
    "approved": ["10.42.8.0/24"],
    "unapproved-child": ["10.42.8.0/25"],
    "default-route": ["0.0.0.0/0"],
    "host-bits": ["10.42.8.7/24"],
}

for label, values in cases.items():
    try:
        advertised = {ip_network(value, strict=True) for value in values}
        if advertised != allowed:
            raise ValueError("advertisements differ from the approved set")
        print(label, "PASS")
    except ValueError as error:
        print(label, "FAIL", str(error))

コードを読んだ上での期待結果は、approved だけがPASS。子プレフィックスとデフォルト経路は集合が一致せずFAIL。ホスト部のビットが立った入力は、ネットワークの厳密な解釈でFAILとなる。失敗を表示し、許可範囲を勝手に広げたり、不正な入力を別の値へ置換したりしない。

この点検は意図的に小さく、AS path、next hopへの到達性、経路の撤回、重複、IPv6、機器固有の構文を扱わない。承認済みの広告集合に一致しても、これらの性質は確かめられていない。実際のアカウントのアドレスや認証情報を、公開用のワークシートへ載せない。

設定変更の前に、観測計画を作る

別途許可を得た検証ネットワークで、まずUnified Routingの状態、トンネル種別、両側のASN、ピアのアドレス、承認済みプレフィックス、現在の経路の証拠を記録する。所有者が認めた、設定に必要な最小権限のIDを使う。この教材では権限を追加せず、トークンも用意しない。

次に、一つの宛先を表の四層で観測する。経路とプローブが同じトンネル・拠点を指しているか揃える。その後、その検証環境だけで経路の撤回やサービス停止を制御して試す。最初に変わった観測、緑のまま残った観測、アプリが再び成功した時刻を記録する。サービスだけを止める実験は、アプリが停止してもBGPセッションが成立し続ける理由を考えるのに役立つ。

このネットワーク演習は未実行。収束時間、損失、スループット、復旧時間は報告していない。観測間隔を足して仮想的に見積もることはできるが、その値を実測の停止時間やSLAとは呼ばない。

セッションが成立しなければ、接続を開始する側、ピアのアドレス、ASNの一致条件、機器のログを調べる。成立しても狙ったプレフィックスが届かなければ、広告方針と受信経路の証拠を見る。経路があるのにリクエストが失敗するなら、選択経路、プローブの範囲、ファイアウォール、サービスの待受、応答を調べる。失敗を記録し、別経路に切り替えた結果を最初の試験の成功にしない。

拠点の到達先が頻繁に変わり、プレフィックスの手作業による管理が実際の運用問題になったとき、BGPには用途がある。小さく固定された検証環境なら、GAになったからという理由だけで動的経路を導入せず、明示的な静的経路の設計を選べる。動的経路には、診断対象となるセッション状態と経路方針が加わる。製品の利用料や接続費用は顧客の契約によって異なり、この章では価格も請求も確認していない。オフラインの点検に有料サービスは不要だ。