Cloud Router の概要

Cloud Router は、完全に分散され管理された Google Cloud サービスであり、カスタム動的ルートをプログラムし、ネットワーク トラフィックに合わせてスケーリングします。Cloud Router は、従来のネットワークと Virtual Private Cloud(VPC)ネットワークのどちらでも機能します。

Cloud Router は接続オプションではありませんが、Cloud VPN または Cloud Interconnect 接続で機能し、VPC ネットワークに BGP ルーティング プロトコルを使用して動的ルーティングを提供するサービスです。Cloud Router は、ダイレクト ピアリングまたはキャリア ピアリング接続ではサポートされていません。

Cloud Router は、ボトルネックの原因となる物理的なデバイスではありません。単独では使用できません。ただし、次の場合は必須または推奨されます。

  • Cloud NAT に必要な場合。
  • Cloud Interconnect と HA VPN に必要な場合。
  • 従来の VPN の推奨設定オプション

オンプレミス ネットワークを Google Cloud に拡張する場合は、Cloud Router を使用して Google Cloud ネットワークとオンプレミス ネットワークの間のルートを動的に交換します。Cloud Router は、オンプレミスの VPN ゲートウェイまたはルーターとピアリングします。ルーターは、Border Gateway Protocol(BGP)を介してトポロジ情報を交換します。

トポロジの変更は、Virtual Private Cloud(VPC)ネットワークとオンプレミス ネットワークの間で自動的に伝播されます。Cloud Router を使用する場合、静的ルートを構成する必要はありません。

静的ルーティングと動的ルーティング

静的ルートでは、ルーティング テーブルを作成または保守する必要があります。いずれかのネットワークでトポロジを変更するには、静的ルートを手動で更新する必要があります。また、リンクに障害が発生した場合でも、静的ルートではトラフィックのルートが自動的に変更されることはありません。

静的ルーティングは、安定したトポロジを持つ小規模ネットワークに適しています。また、ルーティング テーブルを厳密に制御できます。ルーターがネットワーク間でアドバタイズを送信することはありません。

Cloud Router では、BGP を使用してネットワーク間でルーティング情報を交換できます。静的ルートを手動で設定する代わりに、ネットワークによって BGP を介して自動的かつ迅速にトポロジの変更が検出されます。変更は、トラフィックを中断することなくシームレスに実装されます。BGP を介してルートを交換するこの方法は、動的ルーティングです。

動的ルーティングは、すべての規模のネットワークに適しています。静的ルートの保守から解放されます。また、リンクに障害が発生した場合、(可能であれば)動的ルーティングによってトラフィックのルートが自動的に変更されます。動的ルーティングを有効にするには、Cloud Router を作成し、 Cloud Router とオンプレミスのゲートウェイまたはルーターとの間の BGP セッションを構成します。

Cloud VPN トンネルの静的ルーティング

Cloud Router がない場合、Cloud VPN の設定には静的ルートのみが使用できます。静的ルートを使用する場合のデメリットは次のとおりです。

  • Cloud VPN トンネルの一方の側でネットワーク構成が変更されたとき、その変更に合わせて手動で新しい静的ルートを作成し、既存の静的ルートを削除する必要があります。また、静的ルートの変更のコンバージェンスには時間がかかります。
  • Cloud VPN トンネルを作成して静的ルートを使用する場合、トンネルを作成する前に、トンネルの両側に IP 接頭辞のリストを指定する必要があります。つまり、ルートの変更が必要になるたびに、Cloud VPN トンネルを削除して再作成し、新しいルートを構成する必要があります。これにより、既存のトラフィックが中断されます。
  • 静的ルートを構成する標準的な方法はありません。使用するコマンドはベンダーごとに異なります。

次の例では、結合されたネットワークは、Google Cloud ネットワークと、クラウド VPN トンネルの反対側のオンプレミス ネットワーク上の 29 のサブネット(ラックごとに 1 つ)で構成されています。この例では、ビジネスが成長途上で、マシンの新しいサブネットを毎週追加する必要があると仮定しています。今週は、次の図に示すようにサブネット 10.0.30.0/24 を追加します。

VPC ネットワークを使用した Cloud VPN の Cloud Router(クリックすると拡大します)
Cloud Router を使用しない Cloud VPN(クリックすると拡大します)

このシナリオでは、Cloud VPN が静的ルートに基づいている場合、次のように変更する必要があります。

  1. 新しいオンプレミス サブネットに到達するには、Google Cloud への静的ルートを追加する必要があります。
  2. 新しいオンプレミス サブネットを含めるには、Cloud VPN トンネルを破棄して再作成する必要があります。

Cloud Router をデプロイすることで、静的ルートと Cloud VPN トンネルの構成を変更する必要をなくすことができます。Cloud Router は BGP を使用して Cloud VPN ゲートウェイとピアリングし、トポロジ情報を交換します。実際には、Google Cloud ネットワークでのネットワーク トポロジの変更は、BGP により自動的に自身のネットワークに反映されます(逆も同様)。そのため、Cloud VPN トンネルの静的ルートを構成する必要はありません。

Cloud Interconnect と Cloud VPN の動的ルーティング要件

次の操作を行うには、既存の Cloud Router が必要です。

Cloud Router を作成するときに、Google 側の ASN を選択できます。ASN を指定しない場合、Google Cloud によって ASN が選択されます。ただし、Cloud Router の構成設定でオンプレミス(ピア)ルーターの ASN を手動で指定する必要があります。

BGP アドレスは次の方法で指定できます。

VPC ネットワークにおける Cloud VPN トンネルの動的ルーティング

VPC ネットワークを使用して、リージョンごとにネットワーク IP スペースを接頭辞(サブネット)にセグメント化し、仮想マシン(VM)インスタンスの内部 IP アドレスがどの接頭辞から割り当てられるかを制御します。Cloud VPN の関連する静的ルートの追加と削除の負担を含むこれらのサブネットの静的な管理を避けるには、Cloud Router を使用して Cloud VPN トンネルの動的ルーティングを有効にします。

Cloud Router は特定の VPC ネットワークとリージョンに属します。Cloud Router は BGP を使用して、VPC ネットワークからサブネットをオンプレミス ゲートウェイにアドバタイズします。VPC ネットワークの動的ルーティング モードに基づいて、ローカル リージョンのサブネット、またはネットワーク内のすべてのサブネットをアドバタイズします。また、Cloud Router は BGP を使用してオンプレミス ルートを学習し、ネットワーク インフラストラクチャを有効にして、対応する接頭辞に到達する最適なルートを選択します。

次の例は、カスタムモード VPC ネットワークを使用した Cloud Router を示しています。自動モードの VPC ネットワークを使用する場合、Cloud Router によってリージョンの /20 接頭辞が自動的に通知されます。自動モードとカスタムモードの詳細については、VPC ネットワークの概要をご覧ください。

次の図は、VPC ネットワークの 2 つの異なるリージョン サブネットと、オンプレミス ネットワークの 30 のサブネットを示しています。2 つのネットワークは、Cloud VPN トンネルで接続されています。このシナリオでは、次の新しいサブネットが両方のネットワークに追加されます。

  1. Google Cloud ネットワークのリージョン us-east1 にある新しい 192.168.1.0/24 サブネット。
  2. データセンターで増大するトラフィックを処理する、新しいオンプレミス 10.0.30.0/24 サブネット。
VPC ネットワークを使用した Cloud VPN の Cloud Router(クリックすると拡大します)
VPC ネットワークを使用した Cloud VPN の Cloud Router(クリックすると拡大します)

ネットワーク構成の変更を自動的に反映させるために、Cloud VPN トンネルは、Cloud Router を使用して、BGP をサポートする必要があるオンプレミス VPN ゲートウェイ間の BGP セッションを確立します。新しいサブネットはネットワーク間でシームレスにアドバタイズされます。新しいサブネット内のインスタンスは、すぐにトラフィックの送受信を開始できます。

BGP を設定するには、Cloud VPN トンネルの各端に追加の IP アドレスを割り当てる必要があります。どちらの IP アドレスも、IP アドレス範囲 169.254.0.0/16 に属するリンクローカル IP アドレスでなければなりません。これらのアドレスは、いずれのネットワークの IP アドレス空間にも含まれていないものにします。これら 2 つのアドレスは、BGP セッションの確立にのみ使用されます。これらのアドレスはルーティングできないため、一般的なネットワーク テストツールでは適切に機能しません。たとえば、Traceroute は機能しません。ping テストが機能するのは、リクエストがリンクローカル アドレスからピアのリンクローカル アドレス宛てに送信される場合のみです。

レガシー ネットワークにおける Cloud VPN トンネルの動的ルーティング

レガシー ネットワークでは、前の例と同様に、ネットワーク構成の変更が自動的に反映されます。静的ルートを再構成して Cloud VPN トンネルを再起動する必要はありません。

BGP セッションにより、各ルーターにローカルの変更が通知されます。BGP を設定するには、Cloud VPN トンネルの各端に追加の IP アドレスを割り当てる必要があります。どちらの IP アドレスも、IP アドレス範囲 169.254.0.0/16 に属するリンクローカル IP アドレスでなければなりません。これらのアドレスはトンネルのどちらの側の IP アドレス空間にも含まれず、BGP セッションを確立するための BGP ピアの設定にのみ使用されます。

トンネルの両側で、2 つのリンクローカル IP アドレス(どちらも同じサブネットからのもの)とネットマスクを設定する必要があります。トンネルの両側でこれらの変更内容を設定すると、BGP セッションが確立されます。

繰り返しになりますが、ネットワーク上の Cloud VPN トンネルが複数のリージョンにある場合、動的ルーティングを使用するリージョンごとに Cloud Router を作成する必要があります。複数の Cloud VPN ゲートウェイ、およびルーターが属するネットワークのリージョン内の複数のトンネルに対しては、単一の Cloud Router で対応できます。

動的ルーティング モード

VPC ネットワークの動的ルーティング モードにより、Cloud Router に表示されるサブネットが決まります。動的ルーティング モードはグローバルまたはリージョンに設定できます。

  • グローバル動的ルーティングでは、Cloud Router によって VPC ネットワーク内のすべてのサブネットがオンプレミス ルーターにアドバタイズされます。Cloud Router によって、学習したルートがオンプレミス ルーターからすべてのリージョンに伝播されます。
  • リージョン動的ルーティングでは、Cloud Router によってそのローカル リージョンのルートがアドバタイズされて伝播されます。

動的ルーティング モードは、VPC ネットワーク上で構成されます。VPC ネットワークを作成または編集するときに、動的ルーティング モードをグローバルまたはリージョンに設定できます。VPC ネットワーク内のすべての Cloud Router のインスタンスが、ネットワークの動的ルーティング モードを使用します。このモードのデフォルトはリージョンです。

VPC ネットワークの動的ルーティング モードを変更する場合は、既存の接続の中断や意図しないルートの有効化などの影響を考慮してください。たとえば、リージョン動的ルーティングに変更した場合、別のリージョンの Cloud VPN トンネルと Cloud Interconnect 接続に接続できる VM が接続を失うことがあります。グローバル動的ルーティングに変更すると、Cloud Router によって、意図せずリージョンから VM がアドバタイズされる可能性があります。動的ルーティング モードを表示または設定するには、リージョン動的ルーティングまたはグローバル動的ルーティングの設定をご覧ください。

動的ルーティング モードとロード バランサー

Cloud VPN トンネルと Cloud 相互接続のアタッチメント(VLAN)経由で内部 TCP/UDP ロードバランサにアクセスする方法を理解するには、内部 TCP/UDP 負荷分散と接続されたネットワークをよくご確認ください。 たとえば、グローバル アクセスを無効にした内部 TCP/UDP ロードバランサには、クライアント VM、Cloud VPN トンネル、そしてロードバランサと同じリージョンに配置されている Cloud 相互接続のアタッチメント(VLAN)のみがアクセスできます。

リージョン動的ルーティングの例

リージョン動的ルーティングでは、Cloud VPN トンネルと VM を 1 つの Google Cloud リージョンに存在させることができます。トンネルによって、オンプレミス ネットワークが VPC ネットワークに拡張されます。他のリージョンの VM がオンプレミス ネットワークに接続する必要がある場合も考えられますが、トンネルには接続できません。この制約を回避するには、静的ルートを作成します。ただし、静的ルートの保守にはエラーが伴いやすく、トラフィックが中断される可能性があります。

次の例で Cloud Router が表示できるのは、us-west1 リージョン内のリソースのみです。us-central1 など、他のリージョンにある VM はこの Cloud VPN トンネルにアクセスできません。

Cloud Router のリージョン動的ルーティング(クリックすると拡大します)
Cloud Router のリージョン動的ルーティング(クリックすると拡大します)

グローバル動的ルーティングの例

グローバル動的ルーティングでは、Cloud Router ですべてのリージョンのリソースを表示できます。たとえば、あるリージョンにある VM は、静的ルートを維持せずに別のリージョンの Cloud VPN トンネルに自動的に接続できます。

次の例は、グローバル動的ルーティングを使用する VPC ネットワークを示しています。Cloud Router の us-west1 サブネットを us-west1us-central1 の 2 つの異なるリージョンにアドバタイズします。両方のリージョンの VM は、オンプレミス ホストを動的に学習します。

Cloud Router のグローバル動的ルーティング(クリックすると拡大します)
Cloud Router のグローバル動的ルーティング(クリックすると拡大します)

冗長トポロジの場合、動的ルーティング(BGP)によって、パスに障害が発生したときにトラフィックのルートが変更されるように、VPC とオンプレミスのネットワークに十分な情報が提供されます。あるリージョンの接続で問題がある場合には、トラフィックを別のリージョンにフェイルオーバーできます。

次の例は、2 つの異なるリージョンにある 2 つの Cloud VPN トンネルを示しています。VM(10.128.0.0/20)は us-west1 リージョンの tunnel-us-west1 を使用して、オンプレミス ネットワークの両方のサブネットに接続します。同様に、us-central1 の VM(10.138.0.0/20)は tunnel-us-central1 を使用します。

Cloud Router のグローバル動的ルーティング(クリックすると拡大します)
Cloud Router のグローバル動的ルーティング(クリックすると拡大します)

ルートは、VM がローカル トンネル(そのリージョンのトンネル)を優先するように構成されています。Cloud Router によって、同じ宛先のローカルルートとリモートルートに対して異なる重みが設定されます。1 つのトンネルに障害が発生した場合、Cloud Router によってトラフィックのルートを適切に変更できます。

次の例の tunnel-us-west1 は失敗します。VM(10.128.0.0/20)への、あるいは VM からのトラフィックは、ドロップされるのではなく、tunnel-us-central1 経由でルート変更されます。

Cloud Router のグローバル動的ルーティング(クリックすると拡大します)
Cloud Router のグローバル動的ルーティング(クリックすると拡大します)

ルート アドバタイズ

Cloud Router は、オンプレミス ネットワークのクライアントが IP アドレスに接続できるように、BGP 経由で IP アドレスをアドバタイズします。オンプレミス ネットワークは、アドバタイズされた IP 範囲に一致する送信先 IP アドレスの VPC ネットワークにパケットを送信します。Google Cloud に到達すると、VPC ネットワークのファイアウォール ルールとルートによって、Google Cloud がパケットをどのように処理するかが決まります。

Cloud Router のデフォルト アドバタイズを使用することも、アドバタイズする CIDR 範囲を明示的に指定することもできます。アドバタイズを指定しないと、Cloud Router はデフォルトの値を使用します。

デフォルト

リージョン動的ルーティングの場合、Cloud Router はデフォルトでリージョンのサブネットをアドバタイズします。グローバル動的ルーティングの場合は、VPC ネットワークのすべてのサブネットをアドバタイズします。Cloud Router は新しいサブネットを自動的にアドバタイズします。また、サブネットにセカンダリ IP 範囲があり、エイリアス IP アドレスが設定されている場合、Cloud Router はプライマリとセカンダリの両方の IP アドレスをアドバタイズします。

Cloud Router の BGP セッションにもデフォルトのアドバタイズが設定されています。デフォルトでは、Cloud Router はルート アドバタイズをすべての BGP セッションに伝播します。Cloud Router にカスタムルート アドバタイズを設定すると、BGP セッションはこれらのカスタム アドバタイズを継承します。

以下の場合に、カスタムルート アドバタイズを指定する必要があります。

  • サブネットのプライマリ IP 範囲外や、いずれかのセカンダリ IP 範囲外にある IP アドレスをアドバタイズする場合。たとえば、外部 IP アドレスのアドバタイズなどがこれに該当します。
  • VPC ネットワーク ピアリングを使用して、VPC ネットワークに接続された別の VPC ネットワークからルート アドバタイズする場合。この場合、ピア ネットワーク内のサブネット ルートとインポートされたカスタムルートは、VPC ネットワーク内の Cloud Router によって自動的にアドバタイズされません。それらをアドバタイズするには、VPC ネットワークの Cloud Router でカスタムルート アドバタイズを作成し、VPC Network Peering 接続がカスタムルートを交換するように設定する必要があります。

カスタム アドバタイズで、サブネット、あるいはサブネットの一部を選択してアドバタイズできます。これにより、特定のサブネットのアドバタイズを回避できます。この機能が必要ない場合は、デフォルトのアドバタイズを使用してください。

カスタム

カスタムルート アドバタイズを設定する場合、Cloud Router がアドバタイズするルートを明示的に指定します。カスタム アドバタイズは、デフォルトのサブネット アドバタイズをカスタム IP アドレスで補完できる便利な機能です。カスタム IP アドレスはサブネットの IP 範囲外にあるアドレスで、予約済みの外部 IP アドレスなどが該当します。カスタムルート アドバタイズを使用しない場合、カスタム IP アドレスの静的ルートを作成し、維持する必要があります。

カスタムルート アドバタイズを設定するときに、アドバタイズの対象としてすべてのサブネットを選択できます(デフォルトの動作)。すべてのサブネットではなく、特定のサブネットやサブネット内の特定の CIDR ブロックに限定することもできます。たとえば、Cloud Router が特定のサブネットをアドバタイズしないように設定できます。これにより、公開したいものだけをアドバタイズできます。ただし、アドバタイズするサブネットを選択した場合、新しいサブネットはカスタムルート アドバタイズに手動で追加する必要があります。Cloud Router は新しいサブネットを自動的にアドバタイズしません。

カスタムルート アドバタイズは Cloud Router または BGP セッションに指定できます。Cloud Router のカスタムルート アドバタイズは、すべての BGP セッションに適用されます。ただし、BGP セッションにカスタムルート アドバタイズを指定すると、Cloud Router のルート アドバタイズは無視され、セッションのアドバタイズでオーバーライドされます。

1 つの Cloud Router に最大 200 までの CIDR 範囲を指定できます。 また、BGP セッションの上限は 200 です。

以下では、Cloud Router のデフォルトの動作と、カスタムルート アドバタイズが便利なシナリオについて説明します。この例では、VPC とオンプレミス ネットワーク間に接続(IPsec VPN トンネル、専用の相互接続など)が確立していることを前提としています。

デフォルトのルート アドバタイズ

リージョン動的ルーティングの場合、Cloud Router はリージョンのサブネットをアドバタイズします。次の例では、Cloud Router がサブネットを us-central1 リージョンでアドバタイズします。また、alias-subnet のセカンダリ IP 範囲をアドバタイズします。新しいサブネットを us-central1 に作成した場合は、Cloud Router が自動的にアドバタイズします。Cloud Router は、サブネットの IP 範囲に含まれていない IP アドレス(外部 IP アドレスなど)をアドバタイズしません。

Cloud Router のデフォルト ルート アドバタイズ(クリックすると拡大します)
Cloud Router のデフォルト ルート アドバタイズ(クリックすると拡大します)

オンプレミス ネットワーク内のクライアントにサービスを提供する Google Cloud アプリケーションには、外部静的 IP アドレスを使用できます。アプリケーションのメンテナンス時に、静的 IP アドレスを別の VM にマッピングすることで、ダウンタイムを最小限に抑えることができます。Cloud Router のデフォルトのアドバタイズでは、静的ルートの設定と維持が必要になります。カスタム アドバタイズを使用すると、BGP 経由で外部 IP アドレスをアドバタイズできます。

次の例では、Cloud Router がプロキシ サーバーの外部 IP アドレス 1.2.3.4 をアドバタイズします。外部 IP アドレスはサーバーの内部 IP アドレス 10.20.0.2 にマッピングされます。Cloud Router は、プロキシ サーバーまたは my-subnet サブネット内の VM の内部 IP アドレスをアドバタイズしません。オンプレミスのクライアントは、プロキシ サーバーの外部 IP アドレスのみを認識します。

外部 IP アドレスのアドバタイズ(クリックすると拡大します)
外部 IP アドレスのアドバタイズ(クリックすると拡大します)

詳細については、カスタム IP 範囲のアドバタイズをご覧ください。

サブネットのアドバタイズを制限する

インスタンスのアドバタイズを防ぎ、インスタンスを隠すことができます。次の例では、Cloud Router が subnet-1subnet-2 をアドバタイズします。 オンプレミス ネットワーク内のクライアントは、これらのサブネット内の VM に接続できますが、unadvertised-subnet サブネット内の VM には接続できません。

Cloud Router での特定のサブネットのアドバタイズ(クリックすると拡大します)
Cloud Router での特定のサブネットのアドバタイズ(クリックすると拡大します)

詳細については、特定の VPC サブネットのアドバタイズをご覧ください。

BGP セッションごとにルートをアドバタイズする

VPC とオンプレミス ネットワークに本番環境とテスト環境のリソースがあり、これらのリソースを別のサブネットに編成しているとします。また、異なる IP アドレス範囲をアドバタイズする 2 つの BGP セッションを設定しています。2 つの異なる BGP セッションを使用しているので、1 つのサブネットにバインドされたトラフィックが誤って別のサブネットに転送されることはありません。次の例は、2 つの BGP セッションを示しています。prod-subnet のみをアドバタイズする prod-bgp と、test-subnet のみをアドバタイズする test- bgp です。

BGP セッションでの特定のサブネットのアドバタイズ(クリックすると拡大します)
BGP セッションでの特定のサブネットのアドバタイズ(クリックすると拡大します)

詳細については、カスタム IP 範囲のアドバタイズまたは特定の VPC サブネットのアドバタイズをご覧ください。

学習したカスタム動的ルート

Cloud Router が同じ宛先接頭辞の複数のネクストホップを受信すると、Google Cloud はルート指標と、場合によっては AS パスの長さを使用して VPC ネットワークにカスタム動的ルートを作成します。 このセクションでは、そのプロセスについて説明します。

動的ルーティング モードの影響

VPC ネットワークの動的ルーティング モードは、Cloud Router から学習したカスタム動的ルートがどのように適用されるかを決定します。

  • リージョン動的ルーティング モードでは、Cloud Router は、Cloud Router と同じリージョンに宛先とネクストホップのカスタム動的ルートを作成します。Cloud Router は、そのカスタム動的ルートの優先度を基本優先度に設定します。これは、Cloud Router が、オンプレミス ルーターによってアドバタイズされた MED から派生したものです。

  • グローバル動的ルーティング モードでは、Cloud Router が各 Google Cloud リージョンの宛先とネクストホップのカスタム動的ルートを作成します。そのルートを学習した Cloud Router が含まれるリージョンで、Cloud Router によって、カスタム動的ルートの優先度が基本優先度に設定されます。他のすべてのリージョンでは、Cloud Router によって基本優先度に優先度が設定され、さらに適切なリージョンのコストが設定されます。

オンプレミス ルーターにエクスポートされた Google Cloud ルートのルート優先度を定義できます。ただし、このルート優先度は、構成によっては、オンプレミス ルーターによってオーバーライドされる場合があります。たとえば、オンプレミス ルーターがルートの優先度を変更した場合などです。

Cloud Router によって学習されたオンプレミスへのルートの場合、Cloud Router は AS パス長と MED 値を取得し、次の 2 つのセクションで説明するように基本優先度を計算します。

AS パスの長さを考慮する場合

単一の Cloud Router によって、複数のネクストホップを持つ宛先の接頭辞が学習される場合、Cloud Router は短い AS パスの長さを持つネクストホップを使用します。この場合、Cloud Router は VPC ネットワーク内に、AS パスが最も短い宛先とネクストホップのカスタム動的ルートを作成します。Cloud Router で、MED によるネクストホップが選択されることはありません。Cloud Router は MED を使用して、MED 値から派生したカスタム動的ルートの基本優先度を設定します。詳細については、動的ルーティング モードの影響をご覧ください。

同じリージョンまたは異なるリージョンの 2 つ以上の Cloud Router によって宛先接頭辞が学習された場合、AS パスは考慮されません。複数の Cloud Router が存在する場合、これらのルーターはネクストホップを選択するのに AS パスの長さではなく、カスタム動的ルートの優先度を使用します。

AS パスの先頭付加

AS パスの先頭付加は、一部のネットワークで BGP アドバタイズを優先するために使用する 1 つの方法です。Google Cloud では、VPC ネットワークがグローバルに設計されているため、AS パスの先頭付加の利点は少なくなります。

VPC ネットワークに複数の Cloud Router(1 つまたは複数のリージョン内)が含まれている場合、次のアルゴリズムを使用して学習する宛先(プレフィックス)のネクストホップを選択します。

  • 宛先(接頭辞)が 1 つの BGP セッションによって受信された場合、AS パスの先頭付加には影響はありません。VPC ネットワーク内で作成された各カスタム動的ルートのネクストホップは、1 つの BGP セッションに関連付けられたネクストホップです。
  • 宛先(プレフィックス)が複数の BGP セッションで受信された場合、同じ Cloud Router でも異なる Cloud Router でも、Google Cloud は関連付けられた AS パスの先頭付加を持つネクストホップを無視します。VPC ネットワークで作成された各カスタム動的ルートのネクストホップは、BGP セッションに AS パスの先頭付加を使用しないネクストホップです。複数の Cloud Router が関係している場合、Cloud Router が同じリージョンにあるかどうかは関係ありません。

すべての状況で、1 つ以上のカスタム動的ルートが作成されるかどうかは、VPC ネットワークの動的ルーティング モードに依存します。

最も一貫性のある結果を得るには、AS パスの先頭付加を使用しないでください。代わりに、MED 値を構成してください。

基本優先度と MED

Cloud Router は、ピアルーターによってアドバタイズされた MED 値を使用して、基本優先度を計算します。

  • 宛先の接頭辞の MED 値が 0 から 231 -1 まで(包括的)の場合、Cloud Router は基本優先度を MED 値に設定します。
  • 宛先の接頭辞の MED 値が 231 から 232 -1 まで(包括的)の場合、Cloud Router は基本優先度を 231 -1 に設定します。

Cloud Router が VPC ネットワークでカスタム動的ルートを作成するときに設定する最終的な優先度の値は、ネットワークの動的ルーティング モードによって異なります。詳細については、動的ルーティング モードの影響をご覧ください。

静的ルート

VPC ルーティング ドキュメントのルーティング順序のセクションをご覧ください。

VPC サブネットとオンプレミスのルート アドバタイズでの IP 範囲の重複

IP 範囲が重複している VPC サブネットとオンプレミス ルート アドバタイズがある場合、Google Cloud は IP 範囲に応じて下りのトラフィックを送信します。

詳細については、VPC ドキュメントの適用可能なルートをご覧ください。

BGP セッションで学習したルートを別の BGP セッションにアドバタイズする

現在 Cloud Router では、静的ルート アドバタイズを通じて、ある BGP セッションから別の BGP セッションに学習したオンプレミス ルートのアドバタイズをサポートしていませんこれを行うと、ルートが削除されることがあります。

複数の VPC ネットワークと動的ルートを適切に交換する方法の詳細については、Cloud Router のトラブルシューティングのページのIP プレフィックスが伝播しない、または使用できないをご覧ください。

ルート指標

ネットワーク接続は、ルートをアドバタイズまたは伝播するときに、ルート指標を使用してルートの優先度を指定します。VPC ネットワークとオンプレミス ネットワークの間に複数のパスがある場合、優先されるパスはルート指標によって決定されます。この値は、MED 値と等価です。ルート指標(MED)が低いほど優先度が高くなります。

ルート指標は、基本のアドバタイズされたルートの優先度とリージョンのコストで構成されます。基本優先度はユーザー指定の値ですが、リージョンのコストは変更できない Google 生成値です。リージョンのコストは、VPC ネットワーク内の 2 つのリージョン間の通信のコストを表します。ネットワーク接続は、これら 2 つの値を加算してルート指標を生成します。

リージョン動的ルーティングの場合、ネットワーク接続ではそのリージョンのルートのみが処理されるため、ルート指標にリージョンのコストは加算されません。ネットワーク接続では、基本のアドバタイズされたルートの優先度のみを使用します。

グローバル動的ルーティングの場合、すべてのネットワーク接続で同じルートがアドバタイズされて伝播されます。ただし、各ネットワーク接続で、リージョンのコストのために異なるルート指標が使用される場合があります。

基本のアドバタイズされたルートの優先度

ネットワーク接続でルート指標を計算するときは、基本のアドバタイズされたルートの優先度値で開始し、次にリージョンのコストが加算されます。この基本値は、アドバタイズされたルートの最小ルート指標です。ネットワーク接続上で BGP セッションを設定するときは、そのセッションのすべてのルートに適用される基本のアドバタイズされたルートの優先度を指定できます。デフォルトでは、アドバタイズされる基本の優先度の値は 100 であり、値として正の整数を取ります。Cloud Router は、数値が 1 である基本のアドバタイズされた優先度を最も優先度の高いルートと見なします。この値は、2 以上の値を持つ低い優先度よりも優先されます。

基本のアドバタイズされたルートの優先度を使用すると、ルートの優先度を設定できます。たとえば、VPC とオンプレミス ネットワークを接続する Cloud VPN トンネルと Dedicated Interconnect 接続があるとします。トラフィックが Dedicated Interconnect を優先するように、基本のアドバタイズされたルートの優先度を設定できます。Cloud Interconnect 接続が使用できない場合、トラフィックはトンネルを通過します。詳細については、トポロジの例をご覧ください。

リージョンのコスト

ネットワーク接続によってそのリージョン以外のリージョンからのルート(リモート Google Cloud リージョンからのルート)がアドバタイズされるか、ルートがリモート リージョンに伝播されると、リージョンのコストが追加されます。

リージョンのコストは、201~9999 の範囲で設定できます。値は、2 つのリージョン間の距離やレイテンシなどの要因によって異なります。Google がリージョンのコスト値を生成します。これを変更することはできません。リージョンのコストの詳細については、トポロジの例をご覧ください。

リージョンのコストは、リージョンの近接性に基づいてパスの優先順位を決定するのに役立ちます。たとえば、VPC とオンプレミス ネットワークの間に、独自のネットワーク接続を備えた 2 つの Cloud VPN トンネルといったような接続が 2 つあるとします。1 つの接続は us-central1 にあり、もう 1 つは europe-west1 にあります。ルート指標にリージョンのコストを追加することにより、us-central1 内のネットワーク間のトラフィックで、us-central1 トンネルが優先されます。同様に、europe-west1 内のネットワーク間のトラフィックで、europe-west1 トンネルが優先されます。リージョンのコストがなければ、トラフィックは両方の接続を介して均等に送信され、ネットワークのパフォーマンスに一貫性がなくなります。

学習したルートの場合、ネットワーク接続によって、学習したルートがリモート Google Cloud リージョンに伝播されると、リージョンのコストが追加されます。これは、VPC とオンプレミスのネットワークの間の上りトラフィックと下りトラフィックの対称性の維持に役立ちます。ネットワーク接続によって、オンプレミス ルーターによってアドバタイズされる MED 値に、リージョンのコストが追加されます。

推奨の基本優先度値

単一のリージョン内のルート間の優先度を調整するには、201 より小さい値を使用します。これにより、リージョンのコストがグローバル ルート優先度に影響を与えないことが保証されます。別のリージョン(リモート リージョン)からのルートに、201 より低い優先度を設定することはできません。大きい値を使用すると、リージョンのコストがルートの優先度に影響を与える可能性があります。たとえば、プライマリ接続とバックアップ接続があるとします。バックアップ接続の基本優先度を高く設定しすぎると、バックアップ接続でなく、他のリージョンからのルートが意図せず優先される可能性があります。

VPC ネットワーク内のルートの優先度をグローバルに下げるには、10,200 より高い値を使用します。これにより、リージョンのコストに関係なく、201 より低い他のすべてのルートが優先されます。

リージョン内のすべてのルートの優先度が等しい場合は、デフォルト値の 100 を使用できます。

トポロジの例

次の例では、グローバル動的ルーティングを使用するときに、リージョンのコストがルート指標にどのように影響するかを説明します。

VPC ネットワークに、独自のネットワーク接続を備えた 2 つの Cloud VPN トンネルの接続があるとします。1 つのトンネルは us-central1 にあり、もう 1 つは us-west1 にあります。デフォルトで、これらのリージョンへの上りトラフィックでは、それぞれのリージョン内の対応するトンネルが使用されます。それでは、europe-west1 にある VM など、これらのリージョンにない VM にアクセスする場合はどうなるのでしょうか。次の図は、リージョンのコストがルート指標にどのように影響するかを示しています。

アドバタイズされたルートのネットワーク接続ルート指標(クリックして拡大)
アドバタイズされたルートのネットワーク接続ルート指標(クリックして拡大)

両方のネットワーク接続で europe-west1 へのルートがアドバタイズされますが、それぞれ使用するルート指標が異なっています。us-central1 のネットワーク接続では、距離やレイテンシなどの要因により、us-west1 より低いルート指標の europe-west1 にルートがアドバタイズされます。この例で、europe-west1 のリージョンのコストは、us-central1 を介する場合は 300 で、us-west1 を介する場合は 350 であると仮定しています。上りトラフィックでは、より低いルート指標を持つ us-central1 トンネルが使用されます。このルート指標が 350 であるのに対して、us-west1 トンネルのルート指標は 400 です。

同様に、ネットワーク接続によって、学習したルートの MED 値(オンプレミス ルーターで指定)にリージョンのコストが追加されます。デフォルトでは、europe-west1 リージョンからの下りトラフィックでも、ルート指標が低いため、us-central1 トンネルが使用されます。このようにして、上りトラフィックと下りトラフィックで対称性が維持されます。

学習したルートのネットワーク接続ルート指標(クリックして拡大)
学習したルートの接続ネットワーク接続指標(クリックして拡大)

リージョン内のルートの優先度

us-west1 で冗長性を確保するために、バックアップ トンネルを作成するとします。次の例に示すように、us-west1 への上りトラフィックでプライマリ トンネルが優先されるように、バックアップ トンネルに高い基本優先度を指定します。

リージョン内のルートの基本優先度(クリックすると拡大します)
リージョン内のルートの基本優先度(クリックすると拡大します)

プライマリ トンネルに障害が発生した場合は、us-west1 への上りトラフィックでは、ルート指標が us-central1 である 51 トンネルよりも、ルート指標が 400 であるバックアップ トンネルが優先されます。

リージョン内のルートの基本優先度(クリックすると拡大します)
リージョン内のルートの基本優先度(クリックすると拡大します)

同様に、VPC ネットワークからオンプレミス ネットワークへの下りトラフィックであるパスを別のパスより優先するには、MED 値を 201 よりも小さくします。そうしないと、VPC ネットワークからオンプレミス ネットワークへの下りトラフィックが上りトラフィックと対称にならない可能性があります。

リージョン内のすべてのトンネルまたは Cloud Interconnect 接続の優先度が同じ場合は、100 のデフォルトの基本ルート優先度を使用できます。

グローバルに優先されるルート

Dedicated Interconnect と Cloud VPN トンネルが異なるリージョンにあるとします。Dedicated Interconnect は、Cloud VPN トンネルよりもコスト効率が高いため、優先度を上げる必要があります。Cloud VPN トンネルルートの基本優先度を 10,051 に指定して、優先度を下げます。その結果、すべての上りトラフィックで、リージョンのコストとは無関係に、Dedicated Interconnect が使用されます。Dedicated Interconnect のルート指標が 10,051 を超えることはありません。接続に障害が発生した場合にのみ、トラフィックで VPN トンネルが使用されます。

グローバル ルートの基本優先度(クリックすると拡大します)
グローバル ルートの基本優先度(クリックすると拡大します)

また、VPC ネットワークからオンプレミス ネットワークへの下りトラフィックが常に Dedicated Interconnect を使用するように、オンプレミス ルーターにも同じ調整を行う必要があります。

基本優先度の設定の詳細については、BGP セッションの確立またはアドバタイズされたルートの基本優先度の更新をご覧ください。

デフォルト ルート

特定の IP 宛先に対してルートが指定されていない場合、トラフィックはデフォルト ルートに送信されます。これは、他に選択肢がない場合の最終手段です。たとえば、Google Cloud VPC ネットワークでは、トラフィックをインターネット ゲートウェイに送信するデフォルト ルート(0.0.0.0/0)が自動的に追加されます。

デフォルトでトラフィックをオンプレミスのネットワークに送る必要がある場合もあります。オンプレミスのルーターからネットワーク接続にデフォルト ルートをアドバタイズして、これを行うことができます。ネットワーク接続を使用すると、静的ルートを作成および管理する必要はありません。オンプレミスのネットワークからデフォルト ルート アドバタイズする場合、他の自動的に作成されたデフォルト ルートより優先されている(MED 値が低い)ことを確認します。ルートページに移動して、送信先 IP 範囲0.0.0.0/0 のルートと、ネクストホップDefault internet gateway優先度を確認します。

グレースフル リスタート

Cloud Router は、オンプレミス ルーターから送信されたグレースフル リスタートのメッセージを受け取ります。グレースフル・リスタートを使用してオンプレミス ルーターを構成した場合、ルーターがソフトウェアの更新をインストールするか定期的なメンテナンスを行う必要がある場合は Cloud Router に通知します。Cloud Router は、オンプレミス ルーターから学習したカスタムの動的ルートを、オンプレミス ルーターのグレースフル リスタートのタイマーで定義された期間保持します。

グレースフル リスタートのタイマーの詳細については、BGP タイマー設定を参照してください。

グレースフル リスタートを使用した Cloud VPN トンネル

次の例では、ネットワーク接続がメンテナンス更新を必要とする場合、グレースフル リスタート時間内にオンラインに戻れば、トラフィックを中断することなく更新できます。

グレースフル リスタートとネットワーク接続(クリックして拡大)
グレースフル リスタートとネットワーク接続(クリックして拡大)

BGP タイマーの設定

Cloud Router とオンプレミス ルーターは、次のタイマー設定を使用して通信を維持します。

keep-alive タイマー
これは、Cloud Router とそれに対応するオンプレミス ピアルーター間で交換される定期的な BGP ハートビートの間隔です。キープアライブ タイマーは、ホールド タイマーと一緒に使用し、各ルーターの可用性を相手ルーターに知らせます。オンプレミス ルーターでキープアライブ タイマーを 20 秒に設定します。
ホールド タイマー
このタイマーで、前回の正常な keep-alive ハートビートが検出された後の最低限必要な時間がトラックされます。ホールド タイマーは、Cloud Router またはオンプレミス ルーターが相手ルーターから通知されたルートを削除するまでの待機時間を示します。オンプレミス ルーターでホールド タイマーを 60 秒に設定します。
グレースフル リスタート タイマー

これは、オンプレミス ルーターが、新しい keep-alive ハートビートを受信する前に、対応する Cloud Router からグレースフル リスタート通知メッセージを受信した後、定期的な keep-alive ハートビートなしで待機する時間です。新しい keep-alive ハートビートが受信されない場合、オンプレミス ルーターは Cloud Router から学習したルートを削除します。

Cloud Router と同じ方法でルーターを動作させる場合は、オンプレミス ルーターでグレースフル リスタート タイマーを 1 秒に設定することをおすすめします。

Cloud Router は、ネクストホップ Cloud VPN トンネルがダウンしているか、Cloud Interconnect 接続がダウンしていると判断した場合に、オンプレミス デバイスから学習したカスタムの動的ルートを取り消します。オンプレミス ルーターのグレースフル リスタート時間を 1 秒より大きい値に設定すると、構成されたアクティブなセカンダリ ネクストホップに切り替わらず、オンプレミス ルーターがアクティブでなくなったネクストホップにリターン トラフィックを送信することがあります。

Stalepath タイマー

この設定は、いずれかのルーターが相手ルーターから end-of-record(EOR)メッセージを受信した後、そのルーターから学習したルートを削除するまでの待機時間を指定します。このタイマーは、グレースフル リスタート後に BGP セッションが再初期化されても、対象の接頭辞が UPDATE メッセージによって更新されていない場合に開始されます。Cloud Router の設定に合わせて、オンプレミス ルーターで Stalepath タイマーを 300 秒に設定することをおすすめします。

冗長 Cloud VPN トンネル

オンプレミス ゲートウェイがグレースフル リスタートをサポートしていない場合、BGP セッションのいずれかの側で障害が発生するとセッションが失敗し、トラフィックが中断されます。BGP タイムアウト(ネットワーク接続の場合は 60 秒)を超過すると、ルートは両方の側から削除されます。動的にルーティングされた Cloud VPN トラフィックはトンネルに入らなくなります。トンネル用の静的ルートは引き続き機能します。

グレースフル リスタートをサポートしていない場合、2 台のオンプレミス ゲートウェイをデプロイしてそれぞれにトンネルを 1 つずつ設定することで、冗長化とフェイルオーバーを実現できます。このような構成にすると、トラフィックを中断することなく、ソフトウェア アップグレードやメンテナンスのために一方のトンネルとデバイスをオフラインにできます。また、一方のトンネルで障害が発生した場合に、他方のトンネルでアクティブなルートとトラフィック フローを維持できます。

次の例では、ネットワーク接続として 1 つのボックスを示していますが、IP アドレスは 2 つあります。これらの 2 つのアドレスは、同じネットワーク接続タスク内の異なるイーサネット インターフェースを示します。各インターフェースは、異なるオンプレミス ゲートウェイとの別々の BGP セッションに使用されます。この使用例では、Cloud VPN トンネルが冗長性確保の目的で作成されているため、両方の BGP セッションが正確に同じルート接頭辞のセットを交換しますが、ネクストホップは別々の VPN トンネルを指します。

グレースフル リスタートを使用しない場合の冗長化(クリックすると拡大します)
グレースフル リスタートを使用しない場合の冗長化(クリックすると拡大します)

アップグレード サイクル

ネットワーク接続は定期的にアップグレードされ、60 秒以内に完了します。アップグレード中はネットワーク接続を利用できません。ピア BGP ルーターが使用できないときに学習済みルートが保持される時間は、BGP ホールド タイマーによって決まります。BGP ホールド タイマーは、両側のネゴシエーションによって 2 つの値の低い方に設定されます。ネットワーク接続の BGP ホールド タイマーは 60 秒です。お客様側ではピア BGP ホールド タイマーを 60 秒以上に設定することをおすすめします(デフォルト値は 3 分)。これにより、アップグレード中に両方のルーターでそれぞれのルートが保持されるため、トラフィックのフローが維持されます。

単一の Cloud VPN ゲートウェイを使用した、Cloud VPN ゲートウェイのメンテナンス サイクル中にネットワーク接続が使用されると、BGP セッションがリセットされ、ルートを再学習する必要があるため、トンネル復旧時間が約 20 秒長くなります。Cloud VPN ゲートウェイの復旧時間は通常 1 分程度です。冗長 Cloud VPN ゲートウェイがある場合、トラフィックは影響を受けません。これは、一度に 1 つの Cloud VPN ゲートウェイのみが停止されるためです。

次のステップ

ネットワーク接続に関する一般的な問題のトラブルシューティングについては、トラブルシューティングのドキュメントをご覧ください。

サポートされているサービスでの静的ルーティングと動的ルーティングの使用について詳しくは、次のドキュメントをご覧ください。

プロダクト ルーティング ドキュメント
Dedicated Interconnect 静的 サポート対象外
Dedicated Interconnect 動的 VLAN アタッチメントの作成
Classic VPN ポリシーベース、静的 静的ルーティングを使用する Classic VPN の作成
Classic VPN または HA VPN 動的 ダイナミック ルーティングを使用した Classic VPN の作成
ピア VPN ゲートウェイへの HA VPN ゲートウェイの作成
Google Cloud HA VPN ゲートウェイへの Google Cloud の作成