ルート

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 ネットワーク内のルートを分類する方法をまとめたものです。

タイプと宛先 ネクストホップ メモ
システム生成ルート
システム生成のデフォルト ルート
IPv4 の場合は 0.0.0.0/0
IPv6 の場合は ::/0		 default-internet-gateway VPC ネットワーク全体に適用されます。

削除または置換できます。
サブネット ルート
サブネット IP アドレス範囲ごとに自動的に作成されます。		 VPC ネットワーク
パケットを VM と内部ロードバランサに転送します。

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

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

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

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

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

インポートされたピアリング サブネット ルートは、VPC ネットワーク全体に適用されます。
ピアリングの静的ルートと動的ルート
VPC ネットワーク ピアリングを使用して接続される別の VPC ネットワーク内の静的ルートまたは動的ルート		 ピア VPC ネットワークのネクストホップ

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

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

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

インポートされたピアリング動的ルートは、ルートをエクスポートする VPC ネットワークの動的ルーティング モードに従って、VPC ネットワークの一部のリージョンまたはすべてのリージョンに適用されます。
Network Connectivity Center のルート
Network Connectivity Center のサブネット ルート
VPC スポーク（Network Connectivity Center ハブに接続されている別の VPC ネットワーク）内のサブネット IP アドレス範囲を表します。 		Network Connectivity Center ハブ

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

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

インポートされた Network Connectivity Center のサブネット ルートは、VPC ネットワーク全体に適用されます。
ポリシーベースのルート
ポリシーベースのルート
ポリシーベースのルートは、ソース IP アドレス、宛先 IP アドレス、プロトコル、またはそれらの組み合わせに基づいてパケットに適用できます。

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

ポリシーベースのルートは、VPC ネットワーク ピアリングを通じて交換されることはありません。

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

デフォルト ルートは宛先の範囲が最も広いルートであり、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 静的ルートを作成して使用できます。

サブネット ルート

サブネット ルートは、VPC ネットワーク内のリソース（VM、内部ロードバランサなど）のパスを定義します。

各サブネットには 1 つ以上のサブネット ルートがあり、その宛先はサブネットのプライマリ IPv4 範囲と一致します。サブネットにセカンダリ IP 範囲がある場合は、セカンダリ IP アドレス範囲ごとに対応するサブネット ルートがあります。サブネットに IPv6 範囲がある場合は、IPv6 アドレス範囲に対応するサブネット ルートがあります。サブネット IP 範囲の詳細については、サブネットをご覧ください。

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

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

静的ルートとの相互作用

対応するサブネットがハイブリッド サブネットとして構成されている場合を除いて、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 では、次のルールが適用されます。

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

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

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

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

    • VPC ネットワークに宛先が 10.70.1.128/25 のローカルまたはピアリングの動的ルートがある場合、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 のローカルまたはピアリングの動的ルートが存在する場合、2001:db8:a0b:c0d::/64 の新しいローカル、ピアリング、Network Connectivity Center のサブネット ルートが作成されると、動的ルートが削除されます。

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

サブネットに含まれるすべての 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 ネットワークの動的ルーティング モードに基づいてリージョンに動的ルートをインストールします。

  • VPC ネットワークがリージョン動的ルーティング モードを使用する場合、各リージョンの Cloud Router は、Cloud Router と同じリージョンにのみ動的ルートを作成します。

  • VPC ネットワークがグローバル動的ルーティング モードを使用する場合、各リージョンの Cloud Router は VPC ネットワークのすべてのリージョンに動的ルートを作成します。

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

動的ルートのネクストホップがアクセス不能になった場合、BGP セッションを管理する Cloud Router は、次のいずれかの条件が満たされた後に動的ルートを削除するよう VPC ネットワークに指示します。

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

ピアリング サブネット ルート

ピアリング サブネット ルートは、VPC ネットワーク ピアリングで接続されている別の VPC ネットワーク内に存在するサブネット内のリソースへのパスを定義します。詳細については、サブネットのルート交換オプションをご覧ください。

ローカル サブネットとピアリング サブネット ルートを重複させることはできません。詳細については、サブネットとピアリング サブネット ルートの相互作用をご覧ください。

ピアリング グループあたりのサブネット ルートの数は、ピアリング グループの割り当てごとのネットワークあたりのサブネットワーク範囲で制御されます。

ピアリングの静的ルートと動的ルート

VPC ネットワーク ピアリングを使用して 2 つの VPC ネットワークを接続すると、一方のネットワークから静的ルートと動的ルートをエクスポートし、もう一方のネットワークにインポートできます。詳しくは以下をご覧ください。

ピアリング グループあたりの静的ルート数と、ピアリング グループごとのリージョンあたりの動的ルート数は、ネットワークごとの静的ルートと動的ルートの割り当てによって制限されます。

適用範囲と順序

適用可能なルート

各インスタンス、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. 単一 VPC ネットワーク内のネクストホップ: このステップは、ルーティング動作をモデル化する VPC ネットワークが、VPC ネットワーク ピアリングを使用して 1 つ以上の VPC ネットワークに接続している場合にのみ適用されます。VPC ネットワーク ピアリングでは、同じ宛先を持つカスタムルートがピアリング グループ内の複数のネットワークに存在する可能性があります。このステップでモデル化する場合、Google Cloud によって選択されるすべてのネクストホップが、同じ 1 つの VPC ネットワーク内に存在している必要があります。

    • ルートモデル内の 1 つ以上のルートで、モデル化対象の VPC ネットワーク内にネクストホップがある場合、ピア ネットワークにネクストホップがあるルートはすべて無視されます。この場合、Google Cloud は、1 つ以上のピア VPC ネットワークに同じ宛先に向かうネクストホップが存在する場合でも、ローカル VPC ネットワークのネクストホップのみを使用します。

    • モデル化対象の VPC ネットワークにネクストホップがあるルートがルートモデルになく、すべてのネクストホップが複数のピア ネットワークに存在する場合、Google Cloud は内部アルゴリズムを使用して、最も限定的な宛先に向かうネクストホップがあるピア ネットワークを 1 つ選択します。ルートの優先度は、この時点では考慮されません。また、VPC ネットワークが新しい VPC ネットワークとピアリングする場合や、既存のピア VPC ネットワークから切断された場合、ネクストホップ用に選択された VPC ネットワークは変わる可能性があります。

    このステップが終わると、ルート選択モデルには、最も限定的な宛先を持つルートのみが含まれ、これらのルートのネクストホップはすべて同じ 1 つの VPC ネットワーク内にあります。

  6. 使用できないネクストホップを含む静的ルートおよび動的ルートを無視する: このステップでは、ダウンしているまたは無効なネクストホップを 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 がパケットを処理しているかどうかを検証しません。詳細については、インスタンスと内部パススルー ネットワーク ロードバランサのネクストホップに共通する考慮事項をご覧ください。

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

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

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

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

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

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

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

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

  9. パケットを送信または破棄する: 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（ネットワーク到達不能）メッセージでパケットを破棄します。

次のステップ