Cloud Router の概要

Cloud Router は、完全に分散されたフルマネージドの Google Cloud サービスです。ネットワーク トラフィックに応じてスケールされます。ボトルネックの原因となる物理的な端末ではありません。

オンプレミス ネットワークを Google Cloud に拡張する場合は、Cloud Router を使用して Google Cloud ネットワークとオンプレミス ネットワークの間のルートを動的に交換します。Cloud Router は、オンプレミスの VPN ゲートウェイまたはルーターとピアリングします。ルーターは、Border Gateway Protocol(BGP)を介してトポロジ情報を交換します。トポロジの変更は、VPC ネットワークとオンプレミス ネットワークの間で自動的に伝播されます。静的ルートを設定する必要はありません。

Cloud Router は、レガシー ネットワークと Virtual Private Cloud(VPC)ネットワークのどちらでも機能します。

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

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

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

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

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

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

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

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

次の例では、Google Cloud ネットワークとお客様側のオンプレミス ネットワークが VPN トンネルで接続されており、オンプレミス ネットワークには 29 のサブネット(ラックごとに 1 つ)があります。この例では、事業の成長が著しく、新しいサブネットを毎週追加することが必要になっているとします。今週は、次の図に示すようにサブネット 10.0.30.0/24 を追加します。

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

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

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

Cloud Router をデプロイすることで、静的ルートと VPN トンネルの構成を変更する必要をなくすことができます。Cloud Router は、BGP を使用してお客様の VPN ゲートウェイとピアリングし、トポロジ情報を交換します。実質的に、ネットワーク トポロジの変更は、Google Cloud Platform ネットワークとお客様のネットワークの間で BGP を介して自動的に伝播されるため、VPN トンネル用に静的ルートを設定する必要はありません。

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

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

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

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

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

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

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

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

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

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

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

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

ネットワークの VPN トンネルが複数のリージョンに存在する場合は、動的ルーティングを使用する各リージョンで、再度 Cloud Router を作成する必要があります。複数の VPN ゲートウェイに対して単一の Cloud Router を使用でき、ルーターが属するネットワークのリージョンのトンネルであれば複数のトンネルに対して同じ Cloud Router を使用できます。

動的ルーティング モード

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

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

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

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

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

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

次の例では、Cloud Router で us-west1 リージョンのリソースのみを表示できます。us-central1 などの他のリージョンの VM インスタンスは、Cloud VPN トンネルに到達できません。

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

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

グローバル動的ルーティングでは、Cloud Router ですべてのリージョンのリソースを表示できます。たとえば、あるリージョンに VM インスタンスがある場合、静的ルートを保守することなく、別のリージョンの Cloud VPN トンネルに自動的に到達することができます。

次の例は、グローバル動的ルーティングを使用する VPC ネットワークを示しています。us-west1 の Cloud Router によって、2 つの異なるリージョン(us-west1us-central1)のサブネットがアドバタイズされます。両方のリージョンの 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)とのトラフィックは、ドロップされるのではなく tunnel-us-central1 経由でルートが変更されます。

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

ルート アドバタイズ

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

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

カスタム

カスタムルート アドバタイズを設定する場合、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 のデフォルト ルート アドバタイズ(クリックすると拡大します)

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

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

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

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

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

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

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

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

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

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

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

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

GCP からオンプレミス ネットワークへの下りトラフィックの最適なパス

Cloud Router が同じ宛先の複数のルートを受信した場合、GCP によってルート指標と、場合によっては AS パスの長さが使用されて、最適なパスが決定します。次のリストは、1 つの VPC ネットワークの動的ルートを管理する 1 つまたは複数の Cloud Router での下りトラフィックに使用されるアルゴリズムを示しています。

  1. 1 つの Cloud Router に複数の BGP セッションがある場合、最初に満たされた条件によって下りが決まります。
    1. すべての下りトラフィックは、AS パスの長さが最も短いルートに送信されます。
    2. ルートの AS パスの長さが同じ場合、すべての下りトラフィックは、最小の Multi-Exit Discriminator(MED)値(最小のルート指標)を持つルートに送信されます。
    3. ルートの AS パスの長さと MED 値が同じ(ルート指標が同じ)場合、下りトラフィックは、等価コスト マルチパス(ECMP)を使用してすべてのルートでバランスが保たれます。
  2. 同じリージョンで複数の Cloud Router を使用している場合、GCP でルート指標のみが使用されて最適なパスが決定されます。AS パスの長さは使用されません。最初に満たされた条件によって下りが決まります。
    1. すべての下りトラフィックは、最小の Multi-Exit Discriminator(MED)値(最小のルート指標)を持つルートに送信されます。
    2. ルートの MED 値が同じ(ルート指標が同じ)場合、下りトラフィックは、ECMP を使用してすべてのルートでバランスが保たれます。
  3. 競合が発生した場合、静的ルートが Cloud Router の動的ルートよりも優先されます。動的ルートと同じ接頭辞とルート指標を持つ静的ルートは常に優先されるため、競合する動的ルートは無視されます。

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

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

サブネットの IP 範囲がオンプレミスのルート アドバタイズと同じか、より広範囲の場合、GCP はオンプレミスのアドバタイズを無視します。サブネットの IP 範囲に対する GCP 下りトラフィックはすべて VPC サブネットにルーティングされます。たとえば、サブネットの IP 範囲が 10.2.0.0/16 で、オンプレミス ルーターが 10.2.1.0/24 をアドバタイズしている場合、GCP はオンプレミスのアドバタイズを無視し、10.2.0.0/16 トラフィックを VPC サブネットにルーティングします。

サブネットの IP 範囲がオンプレミスのルート アドバタイズよりも狭い場合、宛先の IP がサブネットの IP 範囲内にあれば、GCP 下りトラフィックは VPC サブネットにルーティングされます。オンプレミスのアドバタイズに一致する他の下りトラフィックは、すべてオンプレミス ネットワークにルーティングされます。たとえば、サブネットの IP 範囲が 10.2.0.0/16 で、オンプレミス ルーターが 10.0.0.0/8 をアドバタイズしている場合、宛先が 10.2.0.0/16 に一致していない限り、GCP は 10.0.0.0/8 宛てのトラフィックをオンプレミス ネットワークにルーティングします。一致した場合、GCP はサブネットにルーティングします。

ルート指標

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

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

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

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

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

Cloud Router でルート指標を計算するときは、基本のアドバタイズされたルートの優先度値で開始し、次にリージョンのコストが加算されます。この基本値は、アドバタイズされたルートの最小ルート指標です。Cloud Router 上で BGP セッションを設定するときは、そのセッションのすべてのルートに適用される基本のアドバタイズされたルートの優先度を指定できます。デフォルトでは、基本のアドバタイズされた優先度値は 100 です。

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

リージョンのコスト

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

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

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

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

推奨の基本優先度値

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

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

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

トポロジの例

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

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

アドバタイズされたルートについての Cloud Router のルート指標(クリックすると拡大します)
アドバタイズされたルートについての Cloud Router のルート指標(クリックすると拡大します)

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

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

学習したルートについての Cloud Router のルート指標(クリックすると拡大します)
学習したルートについての Cloud Router のルート指標(クリックすると拡大します)

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

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

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

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

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

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

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

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

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

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

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

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

デフォルトのルート

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

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

グレースフル リスタート

Cloud Router ではグレースフル リスタートが有効になっています。グレースフル リスタートを使用すると、グレースフル リスタート時間内は、トラフィック フローを中断することなく、オンプレミス BGP 端末がオフラインになり、復帰できます。そのため、BGP エージェントのソフトウェア アップグレードやメンテナンスが必要な場合、または一時的な障害が発生した場合にもネットワークが停止することはありません。

BGP 端末がこの機能をサポートしている場合は、グレースフル リスタートを有効にします。

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

次の例では、Cloud Router でメンテナンス アップデートが必要な場合に、グレースフル リスタート時間内にオンラインに戻る限り、トラフィックを中断させることなく更新できます。

グレースフル リスタートと Cloud Router(クリックすると拡大します)
グレースフル リスタートと Cloud Router(クリックすると拡大します)

BGP タイマーの設定

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

キープアライブ タイマー: これは、Cloud Router と対応するオンプレミス ピアルーターとの間で交換される定期的な BGP ハートビートの間隔です。キープアライブ タイマーは、ホールド タイマーと一緒に使用し、各ルーターの可用性を相手ルーターに知らせます。このタイマーは、オンプレミス ルーターでは 20 秒に設定することをおすすめします。

ホールド タイマー: このタイマーでは、前回の正常なキープアライブ ハートビートが検出された後の最低限必要な時間が監視されます。ホールド タイマーは、Cloud Router またはオンプレミス ルーターが相手ルーターから通知されたルートを削除するまでの待機時間を示します。このタイマーは、オンプレミス ルーターでは 60 秒に設定することをおすすめします。

グレースフル リスタート タイマー: これは、オンプレミス ルーターが、対応する Cloud Router からグレースフル リスタート通知メッセージを受信した後、定期的なキープアライブ ハートビートを受信しないまま、新しいキープアライブ ハートビートの受信を求めるようになるまでの待機時間を示します。新しいキープアライブ ハートビートを受信しないと、オンプレミス ルーターは Cloud Router から通知されたルートを削除します。このタイマーは 60 秒に設定することをおすすめします。

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

冗長 Cloud VPN トンネル

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

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

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

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

アップグレード サイクル

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

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

次のステップ

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

サービス ルーティング ドキュメント
専用の相互接続 静的 サポート対象外
専用の相互接続 動的 VLAN アタッチメントの作成
Cloud VPN ポリシーベース ポリシーベース ルールを使用する VPN トンネルの作成
Cloud VPN 静的 静的ルートを使用する VPN トンネルの作成
Cloud VPN 動的 動的ルートを使用する VPN トンネルの作成
このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...