ルーティングと BGP のトラブルシューティング

このガイドでは、Magic Transit でよくあるルーティングと BGP の問題を診断し、解決します。こうした問題は、トラフィック配信に影響したり、想定外のレイテンシを引き起こしたり、接続損失につながることがあります。

ルーティングや BGP の問題が起きている場合は、まず次を確認してください。

1. BGP セッションの状態: セッションが Established であること。Connect や Active で止まっていないことを確認します。
2. ファイアウォールルール: ルーターと Cloudflare の間で TCP ポート 179 が双方向に許可されていることを確認します。
3. プレフィックス広告の状態: ダッシュボードでプレフィックスが Advertised と表示され、Withdrawn や Approved ではないことを確認します。
4. ルート伝播の所要時間: 変更がグローバルに伝播するまで 2〜5 分ほど待ちます。Cloudflare 側は数分以内に伝播しますが、外部 ISP が BGP テーブルを更新する速さは制御できません。
5. トンネルまたは CNI の健全性: 下層の接続が正常であることを確認します。劣化したトンネルはルート優先度に影響します。
6. 静的ルートとの競合: 同じ優先度では、静的ルートが BGP ルートより優先されます。

BYOIP プレフィックスを広告または取り下げると、変更は数分以内に Cloudflare ネットワーク全体へ伝播します。

ルートが取り下げられると、インターネット上のネットワークは BGP パスハンティングを行います。新しいルーティング状態に収束する前に、代替パスを探します。この動作は次の要因で強まります。

• Cloudflare のグローバルなエニーキャストネットワークと、広範なピアリング関係
• Minimum Route Advertisement Interval（MRAI）。通常は反復あたり 30 秒
• 複数の Tier-1 ネットワークが、それぞれ独立して収束する必要があること

パスハンティング中は、トラフィックが最適でない経路を通ったり、完全に破棄されたりすることがあります。

推奨手順は BYOIP プレフィックスを安全に取り下げる を参照してください。

このセクションは、CNI またはトンネル経由で、自ネットワークと Cloudflare の間に張る BGP ピアリングセッション（ベータ）が対象です。Cloudflare がインターネットへプレフィックスを広告する仕組みは別で、ルート伝播の所要時間 で扱います。

• BGP セッションが Established に到達しない
• ルートが広告も受信もされない
• ルーターログに接続試行が繰り返される

1. ルーターと Cloudflare のピアリングアドレスの間で、TCP ポート 179 が双方向に許可されていることを確認します。
2. ネイバー IP が、Cloudflare から提供されたピアリングアドレスと完全に一致することを確認します。
3. ASN の設定がダッシュボードの設定と一致することを確認します。サポートしているのは eBGP のみのため、自 ASN は Cloudflare アカウントの ASN と異なる必要があります。
4. MD5 認証を使う場合は、双方のパスワードが一致することを確認します。

• ダッシュボードではプレフィックスが Advertised と表示される
• 外部ホストがプレフィックス内の IP に到達できない
• トラフィックが破棄される

• ルート伝播がまだ完了していない
• 自ネットワークに戻り経路のルーティングがない
• 上流 ISP での ROA / RPKI 検証の問題

1. 伝播を待つ: グローバル全体への伝播まで、最大 5 分ほど待ちます。Cloudflare 内への伝播は速いですが、外部ネットワークの更新速度はまちまちです。
2. 戻り経路のルーティングを確認する: エグレス構成では、戻りトラフィックを Cloudflare 経由で送り返すルートが自ネットワークにあることを確認します。イングレスのみ、または Direct Server Return の構成では、戻りトラフィックをトンネル経由でルーティングします。
3. 外部からの可視性を確認する: bgp.he.net ↗ や RIPE RIS ↗ などの BGP Looking Glass ツールを使い、外部ネットワークからプレフィックスが見えることを確認します。
4. RPKI の設定を確認する: Resource Public Key Infrastructure（RPKI）を使う場合は、Route Origin Authorization（ROA）レコードがプレフィックスと、Cloudflare 上の ASN 設定に一致することを確認します。

• API またはダッシュボードでプレフィックスを取り下げた
• 外部トラフィックは Cloudflare に届き続けるが、破棄される
• 取り下げ後も数分間、接続損失が続く

これは BGP パスハンティングの動作です。Cloudflare がプレフィックスを取り下げると、インターネット上のネットワークは代替パスを探します。収束には通常 2〜5 分かかりますが、11 分を超えることもあります。この期間、トラフィックは次のようになることがあります。

• ISP にキャッシュされたパス経由で Cloudflare へ向かう
• まだ収束していない Tier-1 プロバイダー間でループする
• 自ネットワークに届く前に破棄される

安全なプレフィックス取り下げ手順に従います。

1. 取り下げ前: 代替プロバイダーから同じプレフィックス（同一のプレフィックス長）を広告します。これで BGP に即座の代替パスを与えます。
2. 任意 - Cloudflare の優先度を下げる: Cloudflare のルートに AS prepend を追加して優先度を下げ、トラフィックが段階的に移るようにします。
3. Cloudflare から取り下げる: API またはダッシュボードでプレフィックスの取り下げを要求します。
4. 収束を待つ: 移行完了とみなす前に、少なくとも 15 分待ちます。

Cloudflare と ISP の両方から同一のプレフィックス長を広告すると、パスハンティングを防げます。ネットワークはすぐに代替ルートを使えます。

詳細な手順は BYOIP プレフィックスを安全に取り下げる を参照してください。

• 特定リージョンからのトラフィックが、離れたデータセンター経由になる
• 地域ユーザーのレイテンシが想定より高い
• 最も近いトンネルまたは CNI が使われない

• トンネル健全性の劣化により、ルートの優先度が下がっている
• リージョンスコープのルート設定ミス
• BGP ルートの優先度が想定どおりでない
• 静的ルートが BGP ルートを上書きしている

1. トンネルの健全性を確認する: 劣化したトンネルにはルート優先度に 500,000 が加算されます。ダウンしたトンネルには 1,000,000 が加算されます。トラフィックはより健全なパスへ移るため、別リージョンになることがあります。診断手順は トンネルヘルスのトラブルシューティング を参照してください。

2. ルート優先度を確認する: 優先度の値が小さいほど、優先度は高くなります。ルートが想定どおりの優先度になっていることを確認します。

   • BGP ルートのデフォルト優先度: 100
   • 優先度 100 の静的ルートは、優先度 100 の BGP ルートより優先されます

3. リージョンスコープを確認する: リージョンスコープのルートを使う場合は、すべてのリージョンにルートがあることを確認します。一致するルートがないリージョンに届いたトラフィックは破棄されます。

4. Network Analytics を使う: トラフィックがどこに着地し、どのパスを通るかを把握するため、トラフィックパターンを確認します。使い方は Network Analytics を参照してください。

• ダッシュボードで CNI がダウンと表示される
• CNI 上の BGP セッションが切れる
• トラフィックがトンネルや別の CNI へフェイルオーバーする

CNI の問題は、複数のレイヤーで起きることがあります。

物理リンクが正常でも BGP に問題があることがあります。BGP セッションが正常でも、特定のプレフィックスが取り下げられていることがあります。

物理層を確認する（自側）:

1. 自ルーターでインターフェースが管理上アップになっていることを確認します。
2. 光レベル（Tx / Rx dBm）を確認します。異常な値は、ファイバーまたはトランシーバーの問題を示します。
3. 受信側の光レベルが低い、またはない場合は、データセンターに連絡してクロスコネクトの状態を確認します。

BGP セッションを確認する:

1. 自ルーターの BGP ネイバー状態が Established であることを確認します。
2. 認証を設定している場合は、MD5 認証の不一致がないか確認します。
3. セッション切断の理由を示すエラーメッセージがないか、BGP ログを確認します。

メンテナンスを確認する:

1. CNI の設置場所に影響する予定メンテナンスがないか、Cloudflare Status ↗ を確認します。
2. 非破壊と表示されていても、一部のメンテナンスは CNI 接続に一時的な影響を与えることがあります。

CNI の設定とセットアップについては Network Interconnect を参照してください。

• 学習済みにもかかわらず BGP ルートが使われない
• トラフィックが想定した BGP パスを通らない
• ルート変更が想定どおりに反映されない

同じプレフィックスと優先度を静的ルートと BGP ルートが共有する場合、Cloudflare は静的ルートを優先します。明示的に優先度を下げない限り、手動設定したルートが優先されます。

希望に応じてルート優先度を調整します。

• BGP ルートを優先する場合: 静的ルートの優先度を大きい数字（例: 150 または 200）にします。数字が大きいほど優先度は低くなります。
• 静的ルートを優先する場合: 静的ルートの優先度を 100 以下にします。BGP ルートのデフォルト優先度は 100 です。

この例で BGP ルートを優先するには、静的ルートの優先度を 150 以上にするか、静的ルートを削除します。

優先度の仕組みの詳細は ルートの優先度 を参照してください。

これらのコンポーネントの関係を理解すると、ルーティング問題の切り分けに役立ちます。

CNI が正常でも、ヘルスチェックプローブがブロックされていたり設定を誤っていたりすると、トンネルが異常になることがあります。下層の物理リンクが稼働していても、BGP ルートは取り下げられることがあります。

このガイドを一通り確認してもルーティング問題が続く場合は、Cloudflare サポートへ連絡する前に、次の情報を集めてください。

1. アカウント ID と、影響を受けているプレフィックス、トンネル名、または CNI 識別子
2. 問題が発生した タイムスタンプ（UTC）
3. BGP 設定の詳細:
   • 自 ASN と Cloudflare のピアリング ASN
   • ネイバー IP アドレス
   • サニタイズしたルーター設定（パスワードとキーは削除）
4. 現在の状態情報:
   • 自ルーターから見た BGP セッション状態
   • プレフィックス、ルート、またはトンネルの状態を示すダッシュボードのスクリーンショット

• 外部からの BGP 可視性: Looking Glass ツールでプレフィックスを確認した結果
• ルーターログ: インシデント期間をカバーする BGP ネイバーログ
• traceroute の結果: 影響を受けた送信元ネットワークから自プレフィックスへ
• CNI の問題の場合: 自装置の光レベル測定値

次のコマンドの出力を収集します（構文はベンダーによって異なります）。

# Show BGP neighbor status
show bgp neighbors

# Show BGP summary
show bgp ipv4 unicast summary

# Show specific prefix in BGP table
show bgp ipv4 unicast <YOUR_PREFIX>

# Show interface status (for CNI)
show interface <YOUR_INTERFACE_NAME>

# Show received and advertised routes
show bgp ipv4 unicast neighbors <YOUR_NEIGHBOR_IP> routes
show bgp ipv4 unicast neighbors <YOUR_NEIGHBOR_IP> advertised-routes

• トラフィックステアリング: ルートの優先度、BGP コミュニティ、ECMP の動作
• プレフィックスの広告: BGP 制御方法と安全な取り下げ手順
• ルートの設定: 静的ルートの設定
• Network Interconnect: CNI のセットアップと BGP ピアリング
• トンネルヘルスのトラブルシューティング: トンネル固有の診断手順
• Network Analytics: トラフィック分析と監視
• Cloudflare Status ↗: メンテナンスとインシデントの通知