構成、Cloud Router、認証、ルート処理のトラブルシューティング

Cloud Router の一般的な問題を解決する場合は、次のガイドをご覧ください。

詳しくは、以下のドキュメントをご覧ください。

構成に関する問題

BGP セッションの確立に失敗した

オンプレミス BGP ルーターの設定と Cloud Router の設定が正しいことを確認します。詳細については、Cloud Router のログをご覧ください。

Cloud VPN トンネルを作成する際は、トンネルのステータスが ESTABLISHED であることを確認してください。このステータスになっていない場合は、Cloud VPN のトラブルシューティングを参照して、問題のトラブルシューティングを行ってください。

BGP セッションの IPv4 アドレスと IPv6 アドレス

BGP ピアリング IPv6 アドレスのサポートはプレビュー版です。

BGP セッションに使用できる IPv4 アドレスと IPv6 アドレスは、使用するプロダクトによって異なります。詳細については、BGP ピアリング アドレスをご覧ください。

項目 resource.bgp.asn の値が無効です

次のエラーが発生する場合があります。

「resource.bgp.asn フィールドの値が無効: ######。ローカル ASN は、同じリージョンとネットワーク内のルーターによって指定されたピア ASN と競合しています。」

Cloud Router は、同じ ASN のオンプレミス デバイスと BGP セッションを確立しようとします。この問題を解決するには、デバイスか Cloud Router の ASN を変更してください。

単一リージョンの Cloud Router 間で iBGP が機能しない

同じ ASN の 2 つの Cloud Router は作成できますが、iBGP はサポートされません。

IPv6 BGP セッションを確立できない

IPv6 BGP ピアとの接続を確立できない場合は、次のようにします。

  1. 対応する VLAN アタッチメントまたは HA VPN トンネルが接続されていることを確認します。
  2. VLAN アタッチメントまたは HA VPN ゲートウェイのスタックタイプが IPV4_IPV6 であることを確認します。VLAN アタッチメントのスタックタイプが正しくない場合は、VLAN アタッチメントを変更します。HA VPN ゲートウェイの場合は、HA VPN ゲートウェイとそのトンネルを再作成します。

  3. Cloud Router が正しく構成され、オンプレミス ルーターが一致する IPv6 BGP アドレスで構成されていることを確認します。

    次のコマンドを実行します。

    gcloud compute routers describe ROUTER-NAME

    コマンド出力で、次の値を確認します。

    • bgpPeers.peerIpAddress は、オンプレミス ルーターの外部インターフェースに割り当てられた IPv6 アドレスです。この IPv6 アドレスは、HA VPN トンネルまたは Dedicated Interconnect VLAN アタッチメントの Cloud Router との BGP ピアリング アドレスとして使用されます。
    • bgpPeers.ipAddress は、Cloud Router のインターフェースに割り当てられた IPv6 アドレスで、オンプレミス ルーターでピア BGP IP アドレスとして構成された値と一致します。
    • bgpPeers.peerAsn は、オンプレミス ルーターの ASN と一致します。
    • bgp.asn は、オンプレミス ルーターで構成されているピア ASN と一致します。

IPv6 BGP セッションは確立されるが、IPv4 ルートが交換されない

  1. VLAN アタッチメントまたは HA VPN ゲートウェイのスタックタイプが IPV4_IPV6 であることを確認します。VLAN アタッチメントのスタックタイプが正しくない場合は、VLAN アタッチメントを変更します。HA VPN ゲートウェイの場合は、HA VPN ゲートウェイとそのトンネルを再作成します。

  2. Cloud Router が正しく構成されていることを確認します。次のコマンドを実行します。

    gcloud compute routers describe ROUTER-NAME

    出力で、次の値を確認します。

    • bgpPeers.enableIpv4 は true
    • bgpPeers.ipv4NexthopAddress と bgpPeers.peerIpv4NexthopAddress が存在する

Cloud Router の問題

Google Cloud からの BGP リセットがルーターに表示される

Cloud Router タスクは、通常はマシン間で移行される Google Cloud のコントロール プレーンのソフトウェア プロセスです。この間、Cloud Router が最大で 60 秒程度停止することがあります。通常の移行では、トラフィックは破棄されません。

Cloud Router はデータパスに配置されていません。レイヤ 3 スイッチとして機能しませんが、ルート プログラミングの管理者として機能します。実際には、VLAN アタッチメントか Cloud VPN トンネルによってルーティングが処理されます。

Cloud Router のログに NOTIFICATION_RECEIVED というメッセージが表示される

Cloud Router が BGP ピアから NOTIFICATION メッセージを受信すると、Cloud Router ログに NOTIFICATION_RECEIVED メッセージが表示されます。NOTIFICATION メッセージは、BGP セッションを停止する必要があることを Cloud Router に通知します。

Cloud Router が BGP ピアから NOTIFICATION メッセージを受信すると、Cloud Router はそのピアとの BGP 接続を終了し、学習したルートをすべて削除します。

BGP ピアが NOTIFICATION メッセージを送信する理由はさまざまです。たとえば、ピアから「Hold Timer Expired」というメッセージが送信されることがあります。

Cloud Router のログに CONFIG_DISABLED というメッセージが表示される

CONFIG_DISABLED メッセージは、Cloud Router が BGP セッションを意図的に停止したことを示します。BGP セッションを停止することで、Cloud Router はピアにエラー状態をすぐに通知しようとします。

このメッセージは、次のいずれかの理由で表示されます。

  • ユーザーが Cloud Router API、Google Cloud コンソール、または Google Cloud CLI を使用して BGP セッションを無効にした。BGP セッションの無効化または削除をご覧ください。
  • Cloud VPN 用に設定された BGP セッションの場合に、BGP セッションに関連付けられた VPN トンネルで、IKE と子セキュリティ アソシエーション（SA）が確立されていない。VPN 接続のトラブルシューティングについては、Cloud VPN のトラブルシューティングをご覧ください。
  • Cloud Interconnect 用に BGP セッションが設定されている場合に、VLAN アタッチメントが構成されていないか、admin-down 状態になっている。問題のトラブルシューティングをさらに行うには、Cloud Interconnect ドキュメントのトラブルシューティングをご覧ください。
  • BFD 対応の BGP セッションで、Cloud Router の BFD 制御検出タイマーが時間切れになった。この場合、BGP セッションは停止されます。BFD セッションの状態の詳細については、BFD 診断メッセージとセッションの状態をご覧ください。

Google ピアリング エッジルーターと Cloud Interconnect の VLAN アタッチメント間のリンクがダウンすると、Cloud Router のログに LINK_DOWN メッセージが表示されます。ピアリング エッジルーターは、Cloud Interconnect 接続をプロビジョニングしたコロケーション施設内で Google が管理するネットワーク機器です。

LINK_DOWN メッセージは、対応する BGP ピアのステータスがダウンしていることを示すシグナルです。このメッセージは、Cloud Interconnect ベースの BGP セッションにのみ適用されます。

オンプレミス ルーターで BGP フラップが発生する

BGP フラップは、Cloud Router のソフトウェア メンテナンスと自動タスクの再起動など、さまざまな問題により発生する可能性があります。

完了したメンテナンス イベントの詳細については、ルーターのメンテナンス イベントの識別をご覧ください。他の Cloud Router イベントの詳細を確認するには、Cloud Router のログと指標の表示をご覧ください。

オンプレミス ルーターが次のように構成されている場合、Cloud Router のメンテナンス イベントは問題を示すものではありません。

  • オンプレミス ルーターが、グレースフル リスタート イベントを処理できる。
  • オンプレミス ルーターのホールド タイマーが 60 秒以上に設定されている。

タイマー設定の概要については、BGP タイマーの管理をご覧ください。

接続のモニタリングについては、オンプレミス ルーターと Cloud Router 間の接続の検証をご覧ください。

認証の問題

以降のセクションでは、MD5 認証で発生する可能性のある問題について説明します。

BGP ピアのステータスが MD5_AUTH_INTERNAL_PROBLEM

BGP ピアのステータスに次の値が含まれることがあります。

  • md5AuthEnabled: true
  • statusReason: MD5_AUTH_INTERNAL_PROBLEM

最初の値は、MD5 認証が正常に構成されていることを示します。2 番目の値（statusReason の値 MD5_AUTH_INTERNAL_PROBLEM）は、内部エラーによって Cloud Router が MD5 認証を構成できなかったことを示します。そのため、BGP セッションのステータスは DOWN になります。この場合、何もする必要はありません。Cloud Router はセッションを復元して元に戻そうと試みます。セッションのバックアップに 1 時間以上かかる場合は、Google Cloud サポートにお問い合わせください。

ピアのステータスを確認する方法については、認証ステータスを確認するをご覧ください。

Cloud Router とピアが異なる MD5 キーを使用する

MD5 認証を設定する場合、Cloud Router とそのピアルーターは同じシークレット認証キーを使用する必要があります。不一致が発生した場合、2 つのルーターは通信できません。不一致が発生していると思われる場合は、Cloud Router で使用されている鍵を更新します。この変更方法については、認証鍵を更新するをご覧ください。

鍵の不一致があるかどうか不明な場合は、ピアルーターのドキュメントに記載されているトラブルシューティングで解決策を探してください。多くのルーターには、鍵の不一致の有無を記録するログがあります。

自動生成された MD5 鍵がオンプレミスのデバイスでサポートされる長さを超えている

UI コンソールで [生成してコピー] をクリックすると、MD5 鍵を自動生成できます。詳細については、既存のセッションに認証を追加するをご覧ください。自動生成される MD5 鍵がオンプレミスでサポートできる長さを超えている場合は、UI、gcloud、API を使用して MD5 鍵を手動で構成できます。

ルート処理に関する問題

MED 値のないオンプレミス ルートが優先される

Cloud Router が MED 値のないオンプレミス ルートを受信すると、Cloud Router は RFC 4271 に記述されているように動作します。Cloud Router は、可能な限り低い MED 値（0）を想定し、優先度の最も高いルートを処理します。

レイヤ 3 Partner Interconnect 接続を介して MED 値を送信して学習できない

レイヤ 3 サービス プロバイダが BGP を処理する Partner Interconnect 接続を使用している場合、Cloud Router がオンプレミス ルーターから MED 値を学習することや、そのルーターに MED 値を送信することはできません。これは、MED 値が自律システムを通過できないためです。このタイプの接続では、Cloud Router からアドバタイズされたルートのルート優先度をオンプレミス ルーターに設定することはできません。また、オンプレミス ルーターによってアドバタイズされるルートの優先順位を VPC ネットワークに設定することはできません。

一部のオンプレミスの IPv4 または IPv6 プレフィックスは使用できない

一部のオンプレミスの IPv4 または IPv6 プレフィックスが使用できない場合は、割り当てと上限、またはサブネット範囲の重複を確認します。

カスタム学習ルートが機能していない

カスタム学習ルートを構成していて、トラフィックの損失、ping エラーなど、ルートに関連する問題が発生した場合は、次の操作を行います。

  • BGP セッションでルートが正しく構成されていることを確認します。

  • BGP セッションが稼働していることを確認します。

詳細については、カスタム学習ルートのステータスを確認するをご覧ください。

割り当てと上限を確認する

Cloud Router で学習したルートの上限を超過していないことを確認します。Cloud Router の学習したルートの数を確認するには、そのステータスを確認します。

上限、関連するログメッセージ、指標、問題の解決方法については、次の表をご覧ください。

上限 ガイダンス
上限について

学習したルートには 2 つの上限があります。これらの上限によって、学習したルートの最大数が直接定義されることはありません。代わりに、一意の宛先プレフィックスの最大数が定義されます。

  • 特定リージョン内のすべての Cloud Router によって同じリージョン内のサブネットに適用できる、学習したルートの一意の宛先の最大数
  • 異なるリージョン内の Cloud Router によって特定のリージョンのサブネットに適用できる、学習したルートの一意の宛先の最大数

最初の上限は、VPC ネットワークで使用される動的ルーティング モードに関係なく該当します。2 つ目の上限は、VPC ネットワークがグローバル動的ルーティング モードを使用している場合にのみ有効です。Cloud Router の上限の詳細については、上限をご覧ください。

 学習したルート 特定リージョン内のすべての Cloud Router によって同じリージョン内のサブネットに適用される、学習したルートの一意の宛先の最大数
ログ これらの制限のいずれかが発生すると、Cloud Logging に limit-exceeded メッセージが表示されます。このメッセージを表示する高度なクエリを作成する方法については、Cloud Router の Logging のドキュメント内の関連するクエリをご覧ください。
指標

次の指標を使用して、現在の上限と使用量を確認することもできます。指標の先頭には router.googleapis.com/dynamic_routes/learned_routes/ が付加されます。

  • used_unique_destinations

    この VPC ネットワークで使用されている一意の宛先の数。グローバル動的ルーティングが有効になっている場合、この指標にはグローバルとリージョンの両方の使用状況が表示されます。

  • unique_destinations_limit

    この VPC ネットワークでアドバタイズすることが許可されている一意の宛先の数。グローバル動的ルーティングが有効になっている場合、この指標にはグローバルとリージョンの両方の上限が表示されます。

  • any_dropped_unique_destinations

    この VPC ネットワークに、ルート割り当ての上限の一つまたは両方を超過したことによってドロップされた宛先があるかどうかを示します。

これらの指標は、gce_network_region モニタリング対象リソースを通じて取得できます。Cloud Router の指標とそれらの指標を表示する方法の詳細については、ログと指標の表示の指標セクションをご覧ください。
問題を解決する

ルートの上限の問題を解決するには、次の操作を行います。ルートの数が上限を大幅に超えている場合には、両方を行うことで効果があります。

  • オンプレミス ルーターを構成して、エクスポートするルートを集約し、それらのルートがより少ない宛先（CIDR）をアドバタイズするようにする。
  • サポートにお問い合わせください。サポートはお客様と協力し、必要に応じて Cloud Router のリセットや、上限の引き上げを行うことができます。

重複するサブネットの範囲を確認する

VPC サブネットの IPv4 および IPv6 アドレス範囲が、オンプレミス ネットワークからアドバタイズされたルートと完全に重複していないことを確認します。IPv4 と IPv6 の範囲が重複すると、ルートが破棄される可能性があります。これは、Cloud Router が学習した動的ルートに重複するカスタム静的ルートにも適用されます。次の場合、Cloud Router が受信するプレフィックスは無視されます（カスタム動的ルートは作成されません）。

  • 学習したプレフィックスが、VPC ネットワーク内のサブネットのプライマリまたはセカンダリ IPv4 / IPv6 アドレス範囲と完全に一致する場合。
  • 学習したプレフィックスが、VPC ネットワーク内のカスタム静的ルートの宛先と完全に一致する場合。
  • 学習したプレフィックスが、VPC ネットワーク内のサブネットのプライマリまたはセカンダリ IPv4 / IPv6 アドレス範囲よりも明確である（より長いサブネット マスクがある）場合。
  • 学習したプレフィックスが、VPC ネットワーク内のカスタム静的ルートの宛先よりも明確である（より長いサブネット マスクがある）場合。

詳細については、VPC ルートの概要のルートの適用範囲と順序をご覧ください。

オンプレミス ネットワークから学習されたルートが他の VPC ネットワークに伝達されない

単一の Cloud Router では、ある BGP ピアから他の BGP ピア（他の VPC ネットワーク内の Cloud Router を含む）に学習したルートを再アドバタイズできません。

たとえば、次のハブとスポークのトポロジでは、Cloud Router が複数の VPC ネットワーク間のルート アドバタイズをサポートできません。

Cloud Router のハブとスポーク。
Cloud Router のハブとスポーク（クリックして拡大）

Google Cloud のネットワーク トポロジに関する推奨事項については、VPC 設計のためのベスト プラクティスとリファレンス アーキテクチャをご覧ください。

さらに、Google Cloud でハブ アンド スポーク トポロジを構築して管理するには、Network Connectivity Center を使用できます。

プレフィックスが BGP セッションにインポートされない（AS パスプリペンド）

AS パスの先頭付加は、コントロール プレーンと VPC ネットワークとは無関係です。AS パスの長さは、以下のシナリオで説明するように、各 Cloud Router ソフトウェア タスク内でのみ考慮されます。

1 つの Cloud Router のソフトウェア タスクが 2 つ以上の BGP セッションから同じ宛先を学習した場合は、次のようになります。

  • ソフトウェア タスクは、AS パスの長さが最も短いネクストホップの BGP セッションを選択します。
  • ソフトウェア タスクは、宛先、ネクストホップ、MED の情報を Cloud Router のコントロール プレーンに送信します。
  • コントロール プレーンは、この情報を使用して 1 つ以上の候補ルートを作成します。各候補の基本優先度は、受信した MED に設定されています。

2 つ以上の Cloud Router のソフトウェア タスクが 2 つ以上の BGP セッションから同じ宛先を学習した場合は、次のようになります。

  • 各ソフトウェア タスクは、AS パスの長さが最も短いネクストホップの BGP セッションを選択します。
  • 各ソフトウェア タスクは、宛先、ネクストホップ、MED の情報を Cloud Router のコントロール プレーンに送信します。
  • コントロール プレーンは、この情報を使用して 2 つ以上の候補ルートを作成します。各候補の基本優先度は、受信した MED に設定されています。

Cloud Router のコントロール プレーンは、VPC ネットワークの動的ルーティング モードに従って、1 つ以上の動的ルートを VPC ネットワークにインストールします。グローバル動的ルーティング モードでは、各リージョンの動的ルートの優先度は、Cloud Router のリージョンとは異なるリージョンに合わせて調整されます。Google Cloud がルートを選択する方法について詳しくは、VPC ドキュメントのルーティング順序をご覧ください。

multi-NIC VM で NIC ごとに異なるルートが取得される

これは想定内の動作です。固有の VPC ネットワーク内の multi-NIC VM 用に、それぞれのネットワーク インターフェース（NIC）を構成する必要があります。各 Cloud Router は 1 つの VPC ネットワークにカスタム動的ルートを作成します。したがって、1 つの Cloud Router が学習したルートは、multi-NIC VM の 1 つのネットワーク インターフェースにのみ適用されます。VM のネットワーク インターフェースから送信されたパケットは、そのインターフェースの VPC ネットワークに適用されるルートのみを使用します。

トラフィックが非対称にルーティングされる

上り（内向き）のトラフィックと下り（外向き）のトラフィックが異なるパスを使用する場合、トラフィックは非対称にルーティングされます。たとえば、2 つの Cloud VPN トンネルがあるとします。VPC ネットワークからの下り（外向き）トラフィックが最初のトンネルを使用し、VPC ネットワークへの上り（内向き）トラフィックは 2 番目のトンネルを使用します。

非対称ルーティングは、オンプレミス ルーターと Cloud Router によってアドバタイズされた優先パスが一致しない場合に発生します。VPC ネットワークへの上り（内向き）トラフィックの場合は、Cloud Router を使用してアドバタイズ ルートの優先度を構成します。詳細については、学習したルートをご覧ください。

他の属性（ルーター ID や発信元 ASN など）が影響を及ぼす可能性があるため、BGP の最適なパス選択の仕組みについてデバイスのドキュメントをご覧ください。たとえば、次のリソースをご覧ください。

VPC ネットワークからの下り（外向き）トラフィックの場合は、オンプレミス ルーターの MED 値を確認してください。

デフォルト ルート（0.0.0.0/0 または ::/0）がインターネット ゲートウェイにトラフィックを送信している

VPC ネットワークを作成すると、Google Cloud は、ネクストホップがデフォルトのインターネット ゲートウェイである、優先度が 1000 のデフォルト ルートを自動的に作成します。

デフォルトのインターネット ゲートウェイのネクストホップを持つルートは、インターネット アクセス要件を満たす VM でのみ使用できます。

Google API とサービスにアクセスするには、限定公開の Google アクセスの使用時などに、デフォルトのインターネット ゲートウェイのネクストホップでルートを使用することも必要です。

次の例は、インターネットまたは Google API とサービスへのトラフィックがブロックされる原因となる可能性がある状況について説明します。

  • 自動的に作成されたデフォルト ルート（デフォルト インターネット ゲートウェイのネクストホップのあるルート）を削除した場合。
  • 自動的に作成されたデフォルト ルートを置き換え、置き換えルートのネクストホップがデフォルト インターネット ゲートウェイと異なる場合。
  • Cloud Router が、自動的に作成されたデフォルト ルートよりも優先度が高い宛先 0.0.0.0/0 または ::/0 のルートを学習した場合。

ネクストホップが明確でない

Google Cloud のルート選択アルゴリズムの仕組みについては、VPC ルート ドキュメントの適用範囲と順序をご覧ください。

IPv6 トラフィックがルーティングされない

IPv6 ホストに接続する際に問題が発生した場合は、次のようにします。

  1. IPv4 ルートが正しくアドバタイズされていることを確認します。最初に IPv4 トラフィックを確認することで、一般的なネットワークの問題を除外できます。IPv4 ルートがアドバタイズされない場合は、このドキュメントに記載されている一般的なトラブルシューティング手順を実施してください。
  2. ファイアウォール ルールを調べて、VPC ネットワークとオンプレミス ネットワーク間で IPv6 トラフィックが許可されていることを確認します。
  3. VPC ネットワークとオンプレミス ネットワークで IPv6 サブネット範囲が重複していないことを確認します。重複するサブネットの範囲を確認するをご覧ください。
  4. 学習したルートの割り当てと上限を超過したかどうかを判断します。学習したルートの割り当てを超過すると、IPv4 接頭辞の前に IPv6 接頭辞がドロップされます。割り当てと上限を確認するをご覧ください。
  5. IPv6 構成を必要とするすべてのコンポーネントが正しく構成されていることを確認します。
    • VPC サブネットが、IPV4_IPV6 スタックタイプを使用するように構成されている。
    • VPC サブネットの --ipv6-access-type が INTERNAL に設定されている。
    • サブネット上の Compute Engine VM が IPv6 アドレスで構成されている。
    • HA VPN ゲートウェイまたは Dedicated Interconnect の VLAN アタッチメントが、IPV4_IPV6 スタックタイプを使用するように構成されている。
    • BGP ピアで IPv6 の使用が有効になっており、BGP セッションに正しい IPv6 ネクストホップ アドレスが構成されている。

次のステップ