ルート

Google Cloud のルートは、ネットワーク トラフィックが仮想マシン（VM）インスタンスから他の宛先に到達する経路を定義します。これらの宛先は、Google Cloud Virtual Private Cloud（VPC）ネットワークの内部（別の VM など）の場合もあれば、VPC ネットワークの外部の場合もあります。

VPC ネットワークの場合、ルートは 1 つの宛先（CIDR 形式）と 1 つのネクストホップで構成されます。VPC ネットワークのインスタンスがパケットを送信したときに、パケットの宛先アドレスがルートの宛先範囲内にある場合、Google Cloud はパケットをルートのネクストホップに送信します。

このページでは、Google Cloud でのルートの機能について説明します。

Google Cloud でのルーティング

VPC ネットワークは、スケーラブルな分散仮想ルーティング メカニズムを使用します。ネットワークに割り当てられている物理デバイスはありません。ルートを個別に適用することもできますが、VPC ネットワークのルーティング テーブルが VPC ネットワーク レベルで定義されています。

VM インスタンスには、ネットワークのルーティング テーブルから適用可能なルートを通知するコントローラがあります。VM から送信されるパケットは、ルーティング順序に基づいて、適用可能なルートで適切なネクストホップに配信されます。ルートを追加または削除すると、最終的に一貫性のある設計によって、一連の変更が VM コントローラに伝播されます。

ルートのタイプ

次の表は、Google Cloud が VPC ネットワーク内のルートを分類する方法をまとめたものです。

タイプと宛先 ネクストホップ メモ
ポリシーベースのルート: ポリシーベースのルートは、他のタイプのルートより先に評価されます。
ポリシーベースのルート
ポリシーベースのルートは、ソース IP アドレス、宛先 IP アドレス、プロトコル、またはそれらの組み合わせに基づいてパケットに適用できます。

ポリシーベースのルートは、ネットワーク内のすべての VM、ネットワーク タグで選択された特定の VM、または Cloud Interconnect の VLAN アタッチメントを介して VPC ネットワークに入るトラフィックに適用できます（1 つのリージョンのみ、またはすべてのリージョン）。

ポリシーベースのルートは、VPC ネットワーク ピアリングを通じて交換されることはありません。
サブネット ルート: すべてのサブネット ルートタイプは、ポリシーベースのルートの後で、カスタム ルートの前に評価されます。
ローカル サブネット ルート
サブネット IP アドレス範囲ごとに自動的に作成されます。		 VPC ネットワーク

サブネットのライフサイクルのイベント中に Google Cloud によって自動的に作成、更新、削除されます。

ローカル サブネット ルートは VPC ネットワーク全体に適用されます。
ピアリング サブネット ルート
VPC ネットワーク ピアリングを使用して接続される別の VPC ネットワーク内のサブネット IP アドレス範囲を表します。		 ピア VPC ネットワークのネクストホップ

VPC ネットワーク ピアリングには、サブネット ルートを交換するためのオプションが用意されています。

サブネットのライフサイクルのイベント中に Google Cloud によって自動的に作成、更新、削除されます。

インポートされたピアリング サブネット ルートは、VPC ネットワーク全体に適用されます。
Network Connectivity Center のサブネット ルート
VPC スポーク（Network Connectivity Center ハブに接続されている別の VPC ネットワーク）内のサブネット IP アドレス範囲を表します。		 Network Connectivity Center ハブ

Network Connectivity Center のスポークの管理者は、サブネット ルートのエクスポートを除外できます。

サブネットのライフサイクルのイベント中に Google Cloud によって自動的に作成、更新、削除されます。

インポートされた Network Connectivity Center のサブネット ルートは、VPC ネットワーク全体に適用されます。
カスタムルート: カスタムルートは、ポリシーベースのルート、サブネット ルートの後に評価されます。
ローカル静的ルート
さまざまな 宛先をサポートします。		 パケットを静的ルートのネクストホップに転送します。 各静的ルートのネクストホップの詳細については、次の考慮事項をご覧ください。
ローカル動的ルート
サブネット ルートまたは静的ルートと競合しない宛先		 Cloud Router での BGP セッションのピア ルートは、VPC ネットワーク内の Cloud Router から学習したルートに基づいて自動的に追加、削除されます。

ルートは、VPC ネットワークの動的ルーティング モードに応じて VM に適用されます。
ピアリング静的ルート、ピアリング動的ルート
VPC ネットワーク ピアリングを使用して接続される別の VPC ネットワーク内の静的ルートまたは動的ルート		 ピア VPC ネットワークのネクストホップ

VPC ネットワーク ピアリングには、静的ルートを交換するためのオプションが用意されています。

インポートされたピアリング静的ルートは、VPC ネットワーク全体に適用されます。

VPC ネットワーク ピアリングには、動的ルートを交換するためのオプションが用意されています。

ピアリング動的ルートは、ルートをエクスポートする VPC ネットワークの 動的ルーティング モードに従って、VPC ネットワークの一部のリージョンまたはすべてのリージョンに適用されます。
Network Connectivity Center 動的ルート
異なる VPC ネットワークにある Network Connectivity Center ハイブリッド スポークからインポートされた動的ルート		 Network Connectivity Center ハブ

Network Connectivity Center ハブには、 VPC スポークとハイブリッド スポークの両方を含めることができます。

Network Connectivity Center 動的ルートは、ハイブリッド スポークを含む VPC ネットワークの動的ルーティング モードに応じて、VPC ネットワークの一部のリージョンまたはすべてのリージョンに適用されます。
システム生成ルート
システム生成のデフォルト ルート
IPv4 の場合は 0.0.0.0/0
IPv6 の場合は ::/0		 default-internet-gateway VPC ネットワーク全体に適用されます。

削除または置換できます。

サブネット ルート

各サブネットには、サブネットに関連付けられている IP アドレス範囲ごとに 1 つ以上のサブネット ルートがあります。サブネット IP 範囲の詳細については、サブネットをご覧ください。

サブネット ルートの種類

VPC ネットワークには、次の種類のサブネット ルートを含めることができます。

  • 同じ VPC ネットワーク内のサブネットのサブネット ルート（ローカル サブネット ルート）。
  • Network Connectivity Center ハブの VPC スポークからインポートされた Network Connectivity Center サブネット ルート。
  • VPC ネットワーク ピアリングを使用して接続されたネットワークからインポートされたピアリング サブネット ルート。

すべてのタイプのサブネット ルートの宛先範囲は一意である必要があります。詳細については、次の情報をご覧ください。

サブネット ルートのライフサイクル

サブネットに含まれるすべての IP アドレス範囲（プライマリ IPv4 アドレス範囲、セカンダリ IPv4 アドレス範囲、IPv6 アドレス範囲）には、対応するサブネット ルートが存在します。Google Cloud では、次のシナリオでサブネット ルートが作成および削除されます。

  • サブネット構成を変更します。次に例を示します。

    • サブネットを追加または削除する
    • プライマリ IPv4 範囲を拡張する
    • セカンダリ IPv4 範囲を追加または削除する
    • IPv6 範囲を追加または削除する

  • Google Cloud によって新しいリージョンが追加されると、自動 VPC モード ネットワークに新しいサブネットが自動的に追加されます。リージョンごとの各サブネットの IPv4 アドレス範囲については、自動モードの IPv4 範囲をご覧ください。

動的ルート

Cloud Router は、受信した Border Gateway Protocol（BGP）メッセージ、適用可能な BGP ルートポリシー（プレビュー）、Cloud Router のカスタム学習ルートに基づいて、動的ルートの作成、更新、削除を VPC ネットワークに指示します。

動的ルートは、Cloud Router を含む VPC ネットワークの動的ルーティング モードと最適パス選択モードに基づいて、1 つのリージョンまたはすべてのリージョンに作成されます。詳しくは以下をご覧ください。

動的ルートのネクストホップは、次のいずれかに設定できます。

動的ルートのネクストホップがアクセス不能になった場合、BGP セッションを管理する Cloud Router は、動的ルートを削除するよう VPC ネットワークに指示します。詳細については、BGP 状態の変更をご覧ください。

動的ルートの種類

VPC ネットワークには、次の種類の動的ルートを含めることができます。

Google Cloud は、動的ルートとの相互作用で説明されているように、動的ルートとサブネット ルートの競合を解決します。

システム生成のデフォルト ルート

デフォルト ルートは宛先の範囲が最も広いルートであり、IPv4 の場合は 0.0.0.0/0、IPv6 の場合は ::/0 です。Google Cloud は、パケットがルーティング順序のより限定的なルートに一致しない場合にのみ、デフォルト ルートを使用してパケットを配信します。

デフォルト ルートがない場合でも、ネットワークがインターネットから分離されるわけではありません。これは、外部パススルー ネットワーク ロードバランサと外部プロトコル転送の特別なルーティング パスがデフォルト ルートに依存しないためです。

VPC ネットワークを作成すると、Google Cloud は、システム生成の IPv4 デフォルト ルートを VPC ネットワークに追加します。システム生成の IPv4 デフォルト ルートは、0.0.0.0/0 の宛先とデフォルトのインターネット ゲートウェイのネクストホップを持つローカル静的ルートです。0.0.0.0/0 の宛先とデフォルトのインターネット ゲートウェイのネクストホップを持つローカル静的ルートは、インターネット上の IPv4 アドレスを含む外部 IPv4 アドレスへのパスを提供します。次のリソース例では、このパスが使用されます。

  • ネットワーク インターフェースに割り当てられた外部 IPv4 アドレスがある VM（送信するパケットの送信元がネットワーク インターフェースのプライマリ内部 IPv4 アドレスと一致する場合）。
  • VM ネットワーク インターフェースで使用されるサブネットに NAT サービスを提供するように構成されたパブリック Cloud NAT ゲートウェイ。Cloud NAT ゲートウェイがサービスを提供するように構成されているサブネット IPv4 アドレス範囲に応じて、パケットの送信元は次のいずれかに一致する場合があります。
    • VM のネットワーク インターフェースのエイリアス IP アドレス範囲の内部 IPv4 アドレス（ネットワーク インターフェースに外部 IPv4 アドレスがあるかどうかに関係なく）。
    • ネットワーク インターフェースに外部 IPv4 アドレスが割り当てられていない場合、VM のネットワーク インターフェースのプライマリ内部 IPv4 アドレス。

外部 IPv6 アドレス範囲を持つサブネットを作成すると、システム生成の IPv6 デフォルト ルートが VPC ネットワークに追加されます（まだ存在しない場合）。システム生成の IPv6 デフォルト ルートは、::/0 の宛先とデフォルトのインターネット ゲートウェイのネクストホップを持つローカル静的ルートです。::/0 の宛先とデフォルトのインターネット ゲートウェイのネクストホップを持つローカル静的ルートは、インターネット上の IPv6 アドレスを含む外部 IPv6 アドレスへのパスを提供します。次の場合にこのパスを使用できます。

  • ネットワーク インターフェースに割り当てられた /96 外部 IPv6 アドレス範囲がある VM（送信するパケットの送信元がその /96 アドレス範囲である場合）。

グローバル Google API へのアクセスは、デフォルトのインターネット ゲートウェイのネクストホップを持つローカル IPv4 または IPv6 デフォルト ルートに依存することがあります。

  • グローバル Google API 用の Private Service Connect エンドポイントにパケットを送信してグローバル Google API とサービスにアクセスする場合、VPC ネットワークにデフォルトのインターネット ゲートウェイのネクストホップを持つデフォルト ルートは必要ありません。Google Cloud は、エンドポイントに特別なルーティング パスを追加します。

  • デフォルト ドメインの IPv4 または IPv6 アドレス、private.googleapis.com の IPv4 または IPv6 アドレス、restricted.googleapis.com の IPv4 または IPv6 アドレスにパケットを送信してグローバル Google API とサービスにアクセスする場合は、デフォルトのインターネット ゲートウェイ ネクストホップを持つデフォルトの IPv4 ルートと IPv6 ルートを使用するか、より限定的な宛先とデフォルトのインターネット ゲートウェイ ネクストホップを持つ IPv4 静的ルートと IPv6 静的ルートを作成して使用できます。

ルートの操作

以降のセクションでは、サブネット ルートと他のルートタイプの相互作用について説明します。

サブネット ルートと静的ルートの相互作用

対応するサブネットがハイブリッド サブネットとして構成されている場合を除いて、Google Cloud では、ローカル、ピアリング、Network Connectivity Center のサブネット ルートに次のルールが適用されます。

  • 新しい静的ルートの宛先が、既存のローカル、ピアリング、Network Connectivity Center のサブネット ルートの宛先と完全に一致するか、その宛先に含まれる場合、Google Cloud では新しい静的ルートを作成できません。次に例を示します。

    • 10.70.1.0/24 宛先のローカル、ピアリング、Network Connectivity Center のサブネット ルートが存在する場合、10.70.1.0/24、10.70.1.0/25、10.70.1.128/25、または 10.70.1.0/24 に含まれる他の宛先に新しい静的ルートを作成することはできません。

    • 2001:0db8:0a0b:0c0d::/64 宛先のローカルまたはピアリングの各サブネット ルートが存在する場合、2001:0db8:0a0b:0c0d::/64、2001:0db8:0a0b:0c0d::/96、または 2001:0db8:0a0b:0c0d::/64 に含まれる他の宛先に新しい静的ルートを作成することはできません。

  • Google Cloud では、サブネット IP アドレス範囲が既存のローカル静的ルートまたはピアリング静的ルートの宛先と完全に一致するか、その宛先を含む範囲になるようなサブネットの変更は行うことができません。次に例を示します。

    • VPC ネットワークに宛先が 10.70.1.128/25 の静的ルートがある場合、プライマリまたはセカンダリの IPv4 アドレス範囲が 10.70.1.128/25、10.70.1.0/24、または 10.70.1.128/25 のすべての IPv4 アドレスを含む他の IP アドレス範囲を持つ新しいサブネットを作成することはできません。

    • VPC ネットワークに宛先が 2001:db8:a0b:c0d:e0f:f0e::/96 の静的ルートがある場合、Google Cloud では、2001:db8:a0b:c0d::/64 の IPv6 アドレス範囲、または 2001:db8:a0b:c0d:e0f:f0e::/96 内のすべての IPv6 アドレスを含む他の範囲を持つ新しいローカルまたはピアリングのサブネット ルートの作成が禁止されています。

サブネット ルートと動的ルートの相互作用

サブネットがハイブリッド サブネットとして構成されている場合を除いて、Google Cloud では、次のルールが適用されます。

  • Cloud Router が、既存のローカル、ピアリング、Network Connectivity Center のサブネット ルートの宛先と完全に一致するか、その宛先に含まれるプレフィックスを送信した場合、Google Cloud では動的ルートは作成されません。次に例を示します。

    • 宛先が 10.70.1.0/24 のローカル、ピアリング、または Network Connectivity Center のサブネット ルートが存在し、VPC ネットワーク、ピアリングされた VPC ネットワーク、または Network Connectivity Center ハイブリッドスポークを含むネットワーク内の Cloud Router が 10.70.1.128/25、10.70.1.0/24、または 10.70.1.0/24 に収まる他のプレフィックスを受信した場合、Google Cloud は、受信した競合するプレフィックスのローカル、ピアリング、または Network Connectivity Center の動的ルートは作成しません。

    • 宛先が 2001:0db8:0a0b:0c0d::/64 のローカル、ピアリング、または Network Connectivity Center のサブネット ルートが存在し、VPC ネットワーク、ピアリングされた VPC ネットワーク、または Network Connectivity Center ハイブリッド スポークを含むネットワーク内の Cloud Router が 2001:0db8:0a0b:0c0d::/96、2001:0db8:0a0b:0c0d::/64、または 2001:0db8:0a0b:0c0d::/64 に収まる他のプレフィックスを受信した場合、Google Cloud は、受信した競合するプレフィックスのローカル、ピアリング、または Network Connectivity Center の動的ルートは作成しません。

  • サブネットの変更により、宛先が既存のローカル、ピアリング、Network Connectivity Center の動的ルートの宛先と完全に一致するか、その宛先を含む新しいローカル、ピアリング、Network Connectivity Center のサブネット ルートが作成された場合、Google Cloud では、既存の動的ルートが削除されます。次に例を示します。

    • VPC ネットワークに宛先が 10.70.1.128/25 のローカル、ピアリング、Network Connectivity Center の各動的ルートがある場合、10.70.1.128/25、10.70.1.0/24、10.70.1.128/25 内のすべての IPv4 アドレスを含む他の IP アドレス範囲の新しいローカル、ピアリング、Network Connectivity Center の各サブネット ルートが作成されると、動的ルートが削除されます。

    • VPC ネットワークに宛先が 2001:db8:a0b:c0d::/96 のローカル、ピアリング、Network Connectivity Center の動的ルートが存在する場合、2001:db8:a0b:c0d::/64 の新しいローカル、ピアリング、Network Connectivity Center のサブネット ルートが作成されると、動的ルートが削除されます。

適用範囲と順序

適用可能なルート

各インスタンス、Cloud VPN トンネル、VLAN アタッチメントには、一連の適用可能なルート（特定のリソースに適用されるルート）があります。適用可能なルートは、VPC ネットワーク内のすべてのルートのサブセットです。

次のルートタイプは、すべての VM インスタンス、VLAN アタッチメント、Cloud VPN トンネルに常に適用されます。

次のルートタイプは、特定の VM インスタンス、VLAN アタッチメント、または Cloud VPN トンネルにのみ適用するように構成できます。

  • ポリシーベースのルートは、次に対して適用できます。

    • すべての VM インスタンス、VLAN アタッチメント、Cloud VPN トンネル
    • ネットワーク タグで識別される VM インスタンスのみ
    • 特定のリージョンの VLAN アタッチメントのみ

  • 静的ルートは、次に対して適用できます。

    • すべての VM インスタンス、VLAN アタッチメント、Cloud VPN トンネル
    • ネットワーク タグで識別される VM インスタンスのみ

  • 動的ルートは、VPC ネットワークの動的ルーティング モードに基づいて、動的ルートのネクストホップを含むリージョンまたはすべてのリージョンの VM インスタンス、VLAN アタッチメント、Cloud VPN トンネルに適用できます。

特別なルーティング パス

VPC ネットワークには特定のサービス用の特別なルートがあります。こうした特別なルーティング パスは、VPC ネットワーク ルートテーブルには表示されません。特別なルーティング パスを削除することはできません。ただし、VPC ファイアウォール ルールまたはファイアウォール ポリシーを使用することで、パケットを許可または拒否できます。

外部パススルー ネットワーク ロードバランサと外部プロトコル転送のためのパス

外部パススルー ネットワーク ロードバランサと外部プロトコル転送では、Maglev システムを使用して、インターネット上のクライアントから VPC ネットワーク内のバックエンド VM とターゲット インスタンスにパケットを転送します。これらの Maglev システムは、外部転送ルールの宛先と一致する宛先のパケットを転送します。

外部パススルー ネットワーク ロードバランサまたは外部プロトコル転送の各転送ルールは、バックエンド VM やターゲット インスタンスが VPC ネットワークの外部の宛先にパケットを送信するためのルーティング パスも提供します。

  • バックエンド VM またはターゲット インスタンスから送信されるパケットは、アウトバウンド レスポンス パケット（クライアントに送り返される）または新しい接続を開始するアウトバウンド パケットのいずれかです。
  • パケットの送信元は、転送ルールの IP アドレスと一致しなければなりません。パケットのプロトコルと送信元ポートが、転送ルールのプロトコルとポートの仕様に一致する必要はありません。
  • 転送ルールのルーティング パスは、デフォルト ルートやデフォルト インターネット ゲートウェイのネクストホップの使用に依存しません。
  • バックエンド VM とターゲット インスタンスで IP 転送を有効にする必要はありません。

Google Front End とバックエンド間のパス

外部アプリケーション ロードバランサと外部プロキシ ネットワーク ロードバランサは、Google Front End（GFE）を使用します。2 番目のレイヤの GFE は、バックエンド VM への TCP 接続を開き、以下の送信元からパケットを送信します。

  • 35.191.0.0/16
  • 130.211.0.0/22

Google Cloud は、Google のネットワーク内のルートを使用して、これらの送信元の範囲から VPC ネットワーク内のバックエンド VM にパケットを配信します。各 VPC ネットワークには、VM が 35.191.0.0/16 と 130.211.0.0/22 にレスポンス パケットを送信できるようにするルーティング パスが含まれています。

ヘルスチェックのパス

すべてのロードバランサに対するヘルスチェックとマネージド インスタンス グループの自動修復用のヘルスチェックでは、ヘルスチェック プローブの IP アドレス範囲からバックエンド VM にパケットが送信されます。

Google Cloud は、Google のネットワーク内のルートを使用して、ヘルスチェック プローブ システムから VPC ネットワーク内の VM にパケットを配信します。各 VPC ネットワークには、VM がヘルスチェック プローブ システムにレスポンス パケットを送信できるルーティング パスが含まれています。

Identity-Aware Proxy（IAP）のパス

IAP を使用した TCP 転送では、35.235.240.0/20 を内部専用範囲として使用し、ネクストホップはすべて Google のネットワーク内にあります。Google は、インターネット上に 35.235.240.0/20 へのルートを公開していません。

IAP TCP 転送を使用する場合、Google のネットワーク内のルートによって、35.235.240.0/20 から VPC ネットワーク内の VM にパケットが配信されます。各 VPC ネットワークには、VM が 35.235.240.0/20 にレスポンス パケットを送信できるルーティング パスが含まれています。

Cloud DNS と Service Directory のパス

以下の Cloud DNS と Service Directory の機能では、35.199.192.0/19 を内部専用の範囲として使用し、ネクストホップは Google のネットワーク内にあります。Google は、インターネット上に 35.199.192.0/19 へのルートを公開していません。

これらの Cloud DNS や Service Directory の機能を使用する場合、Google のネットワーク内のルートによって 35.199.192.0/19 から VPC ネットワーク内の VM にパケットが配信されます。各 VPC ネットワークには、VM が 35.199.192.0/19 にレスポンス パケットを送信できるルーティング パスが含まれています。

サーバーレス VPC アクセスのパス

サーバーレス VPC アクセスでは、35.199.224.0/19 を内部専用の範囲として使用し、ネクストホップはすべて Google のネットワーク内にあります。Google は、インターネット上に 35.199.224.0/19 へのルートを公開していません。

Google ネットワーク内のルートによって、35.199.224.0/19 からサーバーレス VPC アクセス コネクタ インスタンスにパケットが配信されます。各 VPC ネットワークには、コネクタ インスタンスが 35.199.224.0/19 にレスポンス パケットを送信できるルーティング パスが含まれています。

グローバル Google API の Private Service Connect エンドポイントのパス

グローバル Google API 用の Private Service Connect エンドポイントを作成すると、Google Cloud によって、エンドポイントのルートが VPC ネットワークに追加されます。ルートの宛先は、エンドポイントのグローバル内部 IP アドレスです。

ルーティング順序

特定のパケットに適用可能なルートが複数ある場合があります。次の手順では、ルートの選択に使用されるプロセスをモデル化します。

  1. 特別なルーティング パス: Google Cloud の特別なルーティング パスには、VPC ネットワークのルートテーブルに表示されないものがあります。詳細については、特別なルーティング パスをご覧ください。

    特別なルーティング パスが適用される場合、ルート選択モデルには特別なパスのみが含まれます。他のルートはすべて無視され、評価はこのステップで停止します。

  2. ポリシーベースのルート: ポリシーベースのルートは、特別なルーティング パスの後で、他のタイプのルートより前に評価されます。VPC ネットワークにポリシーベースのルートが存在しない場合、Google Cloud はこのステップをスキップし、サブネット ルートのステップに進みます。

    Google Cloud は、ポリシーベースのルートを優先度だけで評価します。Google Cloud は、各ポリシーベースのルートについて、優先度の最も高いポリシーベースのルートから順にパケットの送信元と宛先を評価します。パケットの特性がポリシーベースのルートと一致しない場合、Google Cloud はポリシーベースのルートを無視し、ソートされたリストにある次のポリシーベースのルートを評価します。次に評価するポリシーベースのルートは、無視されたポリシーベースのルートと同じ優先度の場合も、それよりも低い優先度の場合もあります。

    • ルート選択モデル内のすべてのポリシーベースのルートを評価した後、パケットの特性がどのポリシーベースのルートにも一致しない場合、Google Cloud はすべてのポリシーベースのルートを無視し、サブネット ルートのステップに進みます。

    • パケットの特性が優先度の最も高いポリシーベースのルートと一致する場合、Google Cloud はまず、優先度の低いポリシーベースのルートをすべて無視します。リストにポリシーベースのルートが 2 つ以上残っている場合、Google Cloud は、優先度が等しい残りのポリシーベースのルートをそれぞれ評価します。パケットの特性が一致しない残りのポリシーベースのルートはすべて無視します。このステップの後、ルート選択モデルには、ポリシーベースのルートが 1 つ以上含まれる場合があります。

    • ルート選択モデルに、最も優先度の高いポリシーベースのルートが 2 つ以上含まれている場合、Google Cloud は内部アルゴリズムを使用して 1 つのポリシーベースのルートを選択します。選択されたポリシーベースのルートは、パケットの送信元または宛先に対して最も詳細に一致しない可能性があります。このあいまいさを避けるため、一意の優先度を持つポリシーベースのルートを作成することをおすすめします。

    • ルート選択モデルに、他のポリシーベースのルートをスキップするように構成された、最も優先度の高いポリシーベースのルートが 1 つだけ含まれている場合、Google Cloud は、すべてのポリシーベースのルートを無視し、サブネット ルートのステップに進みます。

    • ルート選択モデルに、他のポリシーベースのルートをスキップするように構成されていない、最も優先度の高いポリシーベースのルートが 1 つだけ含まれている場合、Google Cloud はパケットをネクストホップの内部パススルー ネットワーク ロードバランサに配信し、ポリシーベースではないルートをすべて無視します。

  3. サブネット ルート: Google Cloud は、パケットの宛先が VPC ネットワーク内のローカル、ピアリング、Network Connectivity Center のサブネット ルートの宛先範囲に含まれるかどうかを判断します。

    • パケットの宛先がローカル、ピアリング、Network Connectivity Center のサブネット ルートの宛先範囲と一致しない場合、Google Cloud は、すべてのサブネット ルートを無視し、最も限定的な宛先のステップに進みます。

    • パケットの宛先が VPC ネットワーク内のローカル、ピアリング、Network Connectivity Center のサブネット ルートの宛先範囲と一致する場合、動作は、サブネットがハイブリッド サブネットとして構成されているかどうかによって異なります。

      • ほとんどのサブネットでは、Google Cloud はサブネット ルートを排他的に使用し、サブネット内のリソース（VM ネットワーク インターフェースや内部転送ルールなど）にパケットを送信しようとします。他のルートはすべて無視され、評価はこのステップで停止します。パケットの宛先を使用するリソースが存在しない場合、またはリソースが停止した VM インスタンスである場合、パケットは破棄されます。

      • ただし、一致したサブネット ルートがハイブリッド サブネットからのものである場合、Google Cloud はサブネット内で一致する宛先リソース（VM ネットワーク インターフェースや内部転送ルールなど）を探します。

        • サブネットにリソースが存在する場合、Google Cloud はサブネット ルートを排他的に使用し、リソースにパケットを送信しようとします。他のルートはすべて無視され、評価はこのステップで停止します。パケットの宛先にリソースが存在しない場合、パケットは破棄されます。実行されていない VM がリソースである場合も、パケットが破棄されます。

        • サブネットにリソースが存在しない場合、Google Cloud は一致したサブネット ルートを含むすべてのサブネット ルートを無視し、最も限定的な宛先のステップに進みます。

  4. 最も限定的な宛先: このステップの開始時点で、ルート選択モデルには特別なルーティング パス、ポリシーベースのルート、およびローカル、ピアリング、Network Connectivity Center のサブネット ルートは含まれません。

    Google Cloud は、残りの適用可能なルートの中から、パケットの宛先 IP アドレスを含む最も限定的な宛先のルートを特定します。Google Cloud は、宛先が限定的でない他のルートをすべて無視します。たとえば、10.240.1.0/24 は 10.240.0.0/16 よりも限定された宛先です。

    このステップが終わると、ルート選択モデルには、宛先が同じカスタムルートのみが含まれます。

  5. 最も望ましいカスタムルート タイプのみを選択する: このステップでは、最も望ましいカスタムルート タイプを除くすべてのカスタムルートが削除されます。ローカル カスタムルートは Network Connectivity Center 動的ルートよりも優先され、Network Connectivity Center 動的ルートはピアリング カスタムルートよりも優先されます。

    次の表に、このステップで Google Cloud が使用するロジックの概要を示します。

    カスタムルート カテゴリ 影響
    ローカル動的ルートとローカル静的ルート

    ルートモデルに宛先のローカル動的ルートまたはローカル静的ルートが 1 つ以上含まれている場合、Google Cloud は、ルートモデルに存在する場合、次のカスタム ルートタイプを削除します。

    • 異なる VPC ネットワーク内のハイブリッド スポークからの Network Connectivity Center 動的ルート
    • ピアリング動的ルート（VPC ネットワーク ピアリングを使用して接続された他の VPC ネットワークからインポート）
    Network Connectivity Center の動的ルート 次の条件をすべて満たしている場合、Google Cloud はルートモデルからすべてのピアリング動的ルートおよびピアリング静的ルートを削除します。
    • ルートモデルに宛先のローカル カスタムルートが含まれていない
    • ルートモードに、宛先の Network Connectivity Center 動的ルートが 1 つ以上含まれている
    • Network Connectivity Center 動的ルートが、別の VPC ネットワーク内のハイブリッド スポークから送信される
    ピアリングの動的ルートおよびピアリングの静的ルート 最も望ましくないカスタムルートタイプには、ピアリング カスタムルートが含まれています。宛先のピアリング カスタムルートは、ルートモデルに宛先のローカル カスタムルートまたは Network Connectivity Center 動的ルートが含まれていない場合にのみ使用されます。

  6. 単一の VPC ネットワークからピアリング カスタムルートのネクストホップを選択する: 同じ宛先のネクストホップは、同じ VPC ネットワークに配置する必要があります。このステップは、VPC ネットワーク ピアリングを使用して接続された 2 つ以上の異なる VPC ネットワークからインポートされたピアリング動的ルートまたはピアリング静的ルートがルートモデルに含まれている場合にのみ適用されます。

    Google Cloud は、内部アルゴリズムを使用して、単一の VPC ネットワークからピアリング カスタムルートをインポートします。VPC ネットワークが新しい VPC ネットワークとピアリングする場合や、既存のピア VPC ネットワークから切断された場合、Google Cloud で選択されるピア ネットワークが変更されることがあります。

  7. 使用できないネクストホップを含む静的ルートおよび動的ルートを無視する: このステップでは、ダウンしているまたは無効なネクストホップを Google Cloud が無視する状況をモデル化します。

    • ネクストホップの VM の IP アドレスの指定が無効: 静的ルートの next-hop-address は、ルートの VPC ネットワーク内の VM に割り当てられた IP アドレスと一致する必要があります。IP アドレスは、次のいずれかとして VM のネットワーク インターフェースに割り当てられている必要があります。

      • プライマリ内部 IPv4 アドレス
      • 内部 IPv6 アドレス
      • 外部 IPv6 アドレス

      next-hop-address で指定された IP アドレスが別のタイプのリソース（エイリアス IP 範囲など）と一致する場合、またはどのリソースとも一致しない場合、Google Cloud はルートを無視します。

    • ネクストホップの VM が停止または削除されている: Google Cloud は、ネクストホップの VM インスタンスが停止または削除された各静的ルートを無視します。この動作は、ネクストホップが next-hop-instance または next-hop-address を使用して指定されているルートに適用されます。詳細については、インスタンスが停止または削除されたときの動作をご覧ください。

    • ネクストホップ ロードバランサの IP アドレスの指定が無効: IP アドレスでネクストホップ ロードバランサが指定されている静的ルートの場合、IP アドレスは、ルートの VPC ネットワークまたはピアリングされた VPC ネットワークにある内部パススルー ネットワーク ロードバランサの転送ルールと一致する必要があります。ネクストホップの IP アドレスが異なるタイプのロードバランサの転送ルールと一致する場合、または転送ルールと一致しない場合、Google Cloud はルートを無視します。

    • ネクストホップの Classic VPN トンネルが確立されていない: Google Cloud は、アクティブなフェーズ 1（IKE）セキュリティ アソシエーション（SA）がないネクストホップの Classic VPN トンネルを含む静的ルートを無視します。詳細については、Classic VPN ドキュメントのルートの順序をご覧ください。

    • ネクストホップが機能していない動的ルート: 動的ルートのプログラミングを担当する BGP セッションが停止する前でも、ネクストホップの Cloud VPN トンネル、VLAN アタッチメント、またはルーター アプライアンスの VM が機能していない場合、Google Cloud は動的ルートを無視します。通常、この状況は数秒間しか存在せず、対応する Cloud Router BGP セッションが停止すると動的ルートが削除されます。

    Google Cloud は、ネクストホップの VM のゲスト OS またはネクストホップ ロードバランサのバックエンド VM がパケットを処理しているかどうかを検証しません。詳細については、インスタンスと内部パススルー ネットワーク ロードバランサのネクストホップに共通する考慮事項をご覧ください。

  8. 優先度の低いルートを無視する: このステップでは、Google Cloud が、最も高い優先度のルート以外をすべて破棄する仕組みをモデル化します。

    このステップを終えると、ルートモデルは空か、1 つ以上のルートを含みます。モデルが空でない場合、モデル内のすべてのルートは次の特性を持ちます。

    • 同じ優先度
    • 無視されなかったネクストホップ
    • 同一の宛先
    • ポリシーベースのルートまたはサブネット ルート以外のルートタイプ

  9. 単一の VPC ネットワークから Network Connectivity Center 動的ルートのネクストホップを選択する: 同じ宛先のネクストホップは同じ VPC ネットワークに配置する必要があります。このステップは、異なる VPC ネットワークにある 2 つ以上のハイブリッド スポークからインポートされた Network Connectivity Center 動的ルートがルートモデルに含まれている場合にのみ適用されます。

    Google Cloud は、内部アルゴリズムを使用して、単一の VPC ネットワークにあるハイブリッド スポークから Network Connectivity Center の動的ルートをインポートします。Network Connectivity Center ハブにハイブリッド スポークを追加または削除すると、選択したハイブリッド スポークが変更される場合があります。このあいまいさを回避するには、次のような場合に、Network Connectivity Center 動的ルートに一意の優先度があることを確認します。

    • ルートが同じ宛先を持つ。
    • ルートは、異なる VPC ネットワーク内の 2 つ以上のハイブリッド スポークからインポートされます。

  10. 最も望ましい選好カテゴリのみを選択する: Google Cloud は、この手順で定義されているように、異なる選好カテゴリに属するルート間で等コスト マルチパス（ECMP）を実行しません。

    選好カテゴリ ルートタイプとネクストホップのタイプ
    第 1 選好（最も望ましい） ネクストホップ インスタンス（next-hop-instance または next-hop-address）またはネクストホップの Classic VPN トンネルを含む 1 つ以上の静的ルート。
    第 2 選好 1 つのタイプの 1 つ以上の動的ルート。
    第 3 候補 ネクストホップが内部パススルー ネットワーク ロードバランサの単一の静的ルート。
    第 4 選好（最も望ましくない） ネクストホップ default-internet-gateway を含む 1 つ以上の静的ルート。

    このステップでは、ネクストホップ ロードバランサを含む静的ルートが 2 つ以上存在する場合、Google Cloud は内部アルゴリズムを使用して 1 つの静的ルートを選択します。Google Cloud は複数のロードバランサ間で ECMP を実行しません。詳細については、内部パススルー ネットワーク ロードバランサのネクストホップに関する考慮事項をご覧ください。

    このステップを終えると、ルートモデルは空か、1 つ以上のルートを含みます。モデルが空でない場合、モデル内のすべてのルートは次の特性を持ちます。

    • 同じ選好カテゴリ
    • 同じ優先度
    • 無視されなかったネクストホップ
    • 1 つの VPC ネットワーク内のネクストホップ
    • 同一の宛先
    • ポリシーベースのルートまたはサブネット ルート以外のルートタイプ

  11. パケットを送信または破棄する: Google Cloud は、ルートモデルに残っているルートの数に応じて、パケットを送信または破棄します。

    • ルートモデルに単一のルートが含まれている場合、Google Cloud はパケットをネクストホップに送信します。ただし、次の例外があります。

      グローバル アクセスが有効になっていないネクストホップの内部パススルー ネットワーク ロードバランサには、ロードバランサのリージョン外のリージョンからはアクセスできません。したがって、ネクストホップ ロードバランサでグローバル アクセスが有効でない場合、Google Cloud は、ロードバランサのリージョンとは異なるリージョンの VM インスタンス、VLAN アタッチメント、Cloud VPN トンネルから送信されたすべてのパケットを破棄します。この動作を変更するには、グローバル アクセスを有効にする必要があります。

    • ルートモデルに 2 つ以上のルートが含まれている場合、Google Cloud は ECMP を実行して、ネクストホップ間でパケットを分散します。ネクストホップの選択は、ハッシュ計算とネクストホップの数によって異なります。パケットにポート情報が含まれている場合、Google Cloud は 5 タプルハッシュを使用します。それ以外の場合は、3 タプルハッシュを使用します。ハッシュ パケットが同じでも、後続のパケットの送信でルートモデルが変更されると、Google Cloud はそれらのパケットを別のネクストホップに転送する場合があります。

    • ルートモデルが空の場合、Google Cloud は ICMP タイプ 3、コード 0（ネットワーク到達不能）メッセージでパケットを破棄します。

次のステップ