Google Cloud の VPC とオンプレミスの間のルーティングの仕組み
一日遅れてしまいましたが、この記事は Google Cloud Japan Advent Calendar 2021 の23日目の記事です。
TL;DR
Google Cloud の VPC とオンプレミスの間のトラフィックは、BGP（Border Gateway Protocol）というルーティングプロトコルによっておこなわれる経路交換の結果にもとづいて、どの経路を通るかが決定されます。
基本的には普通のルーティングの考え方と同じですが、少しだけクラウド特有の要素が入ってくるので気をつけてください。
目次
- マルチリージョン構成
- マルチリージョン構成時の疑問
- デフォルト時のルーティング
- 動的ルーティングモードと経路受信
- 動的ルーティングモードと経路広告
- グローバル ルーティングモード時の経路選択
- オンプレミスから VPC へのトラフィック
- VPC からオンプレミスへのトラフィック
- リージョン間で優先度を加算する理由
- まとめ
マルチリージョン構成
Google Cloud の VPC （Virtual Private Cloud — クラウド内のプライベートなネットワーク）はグローバルに展開できるので、マルチリージョンな構成も簡単に作れます、みたいなのは聞いたことがある方もいると思います。
実際、下の図のような構成は非常に簡単に作ることができます。
このような構成を作る手順は次の通りです。
- VPC を作る（名前をつけるだけ）
- 東京リージョンと大阪リージョンにサブネットを作る（ネットワークアドレスを設定）
- 東京リージョンと大阪リージョンに Cloud VPN のゲートウェイを作りオンプレミスと IPsec VPN で接続する
- 東京リージョンと大阪リージョンに Cloud Router を作り、オンプレミスと BGP セッションを張る
- 東京リージョンと大阪リージョンに Compute Engine の VM を作成する
以上で、東京リージョンと大阪リージョンで冗長化がされた Compute Engine の VM を動かすことができました。（あとは Compute Engine の VM をインスタンスグループにして可用性を上げる、とかもできます）
注：なお上記例では、話を簡単にするためにオンプレミスのネットワークは東京と大阪で一つのネットワーク（172.22.33.0/24）にしてます。普通は分かれてることが多いとは思いますが。
マルチリージョン構成時の疑問
さて、このようなマルチリージョン構成を作った時によく聞かれるのが、ルーティングはどうなるんですか？というご質問です。具体的には、
- オプレミスから VPC へのトラフィック
- VPC からオンプレミスへのトラフィック
は、それぞれ東京の VPN トンネルを通るのか、大阪の VPN トンネルを通るのか、各 VPN トンネルが落ちた場合にはどうなるのか、というのが質問のポイントになります。
簡単な答えは、オンプレミスルーターでいかようにもコントロールできます、になります。
すると、何をどうコントロールするとどうなるのか？というのが次の質問になります。
というわけで、本記事ではそこをもう少し掘り下げてみたいと思います。
デフォルト時のルーティング
まず初めにデフォルトの状態で上図の構成を作った場合にどうなるかを見てみます。
その前に、上図のままだとオンプレミス側も東京と大阪があって、その間のルーティングをどうするかというオンプレミス側の設計もしなければならず、問題が複雑になってしまうので、とりあえず今回はオンプレミス側は一箇所だけにしました。
注：今回はオンプレミスを模擬するために、別の VPC を使ってます。ゲートウェイ用に VM で strongSwan（IPsec VPN 用）と Quagga（BGP 用）を動かしてます。
ではこの状態でまずは、VPC のルート（経路表）を見てみます。
一行目は、0.0.0.0/0（デフォルトルート）が「デフォルト インターネット ゲートウェイ」へ向いてる経路です。一般的な、インターネットへ接続するための経路で、VPC を作ると自動的に生成されます。（削除することもできます。）
二行目と三行目がそれぞれ、VPC 内のサブネットの経路になります。（サブネットを作成すると自動的に生成されます。）
そして四行目と五行目がオンプレミスから BGP で広告されている経路になります。ただ、ここまでの経路と違い、「送信先 IP 範囲」は同じ（172.22.33.0/24）で「優先度」も同じ 0、「ネクストホップ」だけが違う経路が二つ表示されています。
- 一つ目の経路は東京の Cloud Router “lab-cr1” が受信した経路（「名前」が “lab-cr1-dynamic-route-1” になっています）で、ネクストホップがオンプレミスのゲートウェイの、東京との VPN トンネルのアドレス（169.254.33.2）になっています。
- 二つ目の経路は大阪の Cloud Router “lab-cr2” が受信した経路（「名前」が “lab-cr2-dynamic-route-1” になっています）で、ネクストホップがオンプレミスのゲートウェイの、大阪との VPN トンネルのアドレス（169.254.44.2）になっています。
補足：ところで、Google Cloud における VPC 内のルート（経路）は VPC 単位の、グローバルなリソースとなります。そのため、サブネットごとにルーティングを変える、みたいなことはできません。その代わり静的ルートではネットワークタグというものを使って、そのルートを適用する VM インスタンスを指定できます。
さて、この状態で東京の lab-vm1 や、大阪の lab-vm2 からオンプレミスのサーバーへの経路はどうなるでしょうか。
簡単にチェックする方法として、Google Cloud の Connectivity Test（接続テスト）というサービスがあります。（テスト 20 回までは無料で、それ以降は 20 回ごとに $0.15 の費用が発生します。）
Cloud Console のメニューの「ネットワーク インテリジェンス」カテゴリから「接続テスト」を選びます。
そして、こんな感じにテストの内容を入力します。まずは東京からオンプレミスサーバーへの通信がどうなるかを見るため、送信元として東京の lab-vm1 を選び、送信先として 172.22.33.4 を設定します。
すると以下のような結果が得られて、東京の VPN トンネル（lab-vpn1）を経由してオンプレミスへ向かっていることが分かります。
同様に、送信元として大阪の lab-vm2 を選んで試してみます。すると、以下の通り、今度は大阪の VPN トンネル（lab-vpn2）を経由してオンプレミスへ向かってるが分かりました。
つまり、こんな感じに通信がおこなわれた、ということです。
先に、オンプレミスへの経路 172.22.33.0/24 は二つ（東京経由、大阪経由）あることを見ましたが、なぜ東京の VM からは東京経由、大阪の VM からは大阪経由になるのでしょうか。逆に言うと、たとえばなぜ東京・大阪の VM 両方とも東京経由での通信にならないのでしょうか？（いずれも送信元の VM に近い VPN トンネルを経由してるという意味では、理にかなってるとは言えますが。）
答えは実は簡単です。デフォルトの状態で VPC を作成した場合、各リージョンで受け取った経路はそのリージョンでしか使えないから、です。つまり、東京リージョンの VM は東京のトンネル経由の経路しか知らないし、大阪リージョンの VM も大阪のトンネル経由の経路しか知らないのです。
それを検証するために、試しに東京リージョンの VPN トンネルを落としてみます…と言いたいところなんですが、Cloud VPN にも、オンプレミスで使ってる strongSwan にも、一時的にトンネルを落とす機能を見つけられなかったので、かわりに BGP セッションを落とすことにします。（経路が無ければ、トンネル自体が上がっていても使えないので、東京の VPN トンネルを使えなくするという目的は達せます。）
東京リージョンの Cloud Router lab-cr1 の詳細から、オンプレミスとの BGP ピアを選択。
設定の編集で、BGP ピアを 無効 にします。
Cloud Router のリストで東京の Cloud Router lab-cr1 のBGP セッションが停止してることを確認します。
さて、この状態で再度、東京の lab-vm1 からの接続テストをしたらどうなるでしょう。
おっと、到達不可能になりました。先ほどの接続テストでは3つ目のチェックが「動的ルート」（ネクストホップ： VPNトンネル）でしたが、このテストではデフォルトインターネットゲートウェイへの「静的ルート」に変わってしまっています。
オンプレミスへはインターネット経由では到達できないので、結果、到達不可能というのはうなづけます。
ではなぜ初めにあった動的ルートが使えなくなってしまったのでしょうか。
この時の VPC のルートはこんな状態です。大阪の Cloud Router lab-cr2 が受信したオンプレミスへの経路（172.22.33.0/24）はありますが、東京の Cloud Router が受信した経路は無くなっています。それ自体は東京での BGP セッションをダウンさせたので期待通りですが、そもそも大阪で受信した経路は使えないのでしょうか？
動的ルーティングモードと経路受信
実はこれは VPC の「動的ルーティングモード」という設定に関係があります。
VPC 作成時、デフォルトでは「リージョン」ルーティングモードが選ばれてますが、その状態だと、あるリージョンで受け取られた経路はそのリージョンでしか使われません。そのため、上で試したように、東京の BGP セッションをダウンさせてしまうと東京リージョン内にオンプレミスへの経路は無くなり、大阪リージョンで受け取った経路も使えないので、結果として東京リージョンからオンプレミスへは到達が不可能になります。
補足：というわけで、 VPC の動的ルーティングモードが「リージョン」だと、東京と大阪で接続し冗長化してるつもりでも、あるリージョンでの接続が落ちると接続性は無くなってしまい、冗長接続が活かせないのです。
では次に、VPC の動的ルーティングモードを「グローバル」へ変更してみます。
再度、東京の BGP セッションは落としたまま、東京の VM からオンプレミスへの接続テストをおこなうと、今度は無事、大阪の VPN トンネル（lab-vpn2 ）経由でアクセスできるようになりました。
これは、VPC の動的ルーティングモードを「グローバル」に変更したことで、大阪リージョンで受け取っている経路（172.22.33.0/24）を東京リージョンでも使えるためとなります。
動的ルーティングモードと経路広告
ここまで VPC の動的ルーティングモードの影響として、Cloud Router がオンプレミスから受け取った経路の話しかしませんでしたが、実は Cloud Router がオンプレミスへ広告する経路にも影響があります。
「グローバル」ルーティングモードではオンプレミスから受け取った経路を（その経路を受け取ったリージョンだけでなく）グローバルに使えると説明しましたが、経路をオンプレミスへ広告する場合もグローバルの（サブネット）経路をすべて広告するようになります。
注：Cloud Router はデフォルトで対象となるすべてのサブネットの経路を広告します。
東京の BGP セッションを再度有効にして、「グローバル」ルーティングモードのまま、オンプレミスルーターが受信してる経路を確認します。
東京の BGP セッションbgpd# show ip bgp neighbors 169.254.33.1 received-routes
BGP table version is 0, local router ID is 169.254.33.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 192.168.111.0 169.254.33.1 100 0 65010 ?
*> 192.168.222.0 169.254.33.1 308 0 65010 ?Total number of prefixes 2大阪の BGP セッションbgpd# show ip bgp neighbors 169.254.44.1 received-routes
BGP table version is 0, local router ID is 169.254.33.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 192.168.111.0 169.254.44.1 308 0 65010 ?
*> 192.168.222.0 169.254.44.1 100 0 65010 ?Total number of prefixes 2
細かいところはおいておいて、東京・大阪のいずれの BGP セッションでも、二つの経路（東京の 192.168.111.0 と大阪の 192.168.222.0）を受け取っていることが分かります。そのため、東京・大阪のいずれかの BGP セッションが落ちたとしても、残ったほうの VPN トンネルを経由して両ネットワークへ到達することができます。
では、VPC の動的ルーティングモードを再度「リージョン」へ戻した上で、同じようにオンプレミスルーターが受信してる経路を確認します。
東京の BGP セッションbgpd# show ip bgp neighbors 169.254.33.1 received-routes
BGP table version is 0, local router ID is 169.254.33.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 192.168.111.0 169.254.33.1 100 0 65010 ?Total number of prefixes 1大阪の BGP セッションbgpd# show ip bgp neighbors 169.254.44.1 received-routes
BGP table version is 0, local router ID is 169.254.33.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 192.168.222.0 169.254.44.1 100 0 65010 ?Total number of prefixes 1
ご覧の通り、東京の BGP セッションでは東京のサブネット経路だけ、大阪の BGP セッションでは大阪のサブネット経路だけを受信していることが分かります。この状態でいずれかの BGP セッションが落ちると、経路が無いため、別のリージョンへの到達は不可となります。
このように、VPC の「動的ルーティングモード」の設定は、Cloud Router がオンプレミスへ広告する経路の選択と、オンプレミスから受信した経路の取り扱いの両方に影響があります。
グローバル ルーティングモード時の経路選択
これでとりあえず基本的なところは把握できました。一方、ここまではデフォルトの挙動（とちょっとした変更による影響）しか見ていません。
上の方で「オンプレミスルーターでいかようにもコントロールできます」と書きましたが、たとえば「オンプレミスと VPC の間の通信は普段は東京の VPN トンネル経由。東京のトンネルが落ちたら大阪の VPN トンネル経由にフォールバック。」みたいな設定はどうしたらいいのでしょう。
オンプレミスから VPC へのトラフィック
オンプレミスから VPC へのトラフィックを東京の VPN トンネルを経由するようにするには、大阪との BGP セッションで受け取った経路より、東京との BGP セッションで受け取った経路の方が優先度が高くなるように設定すればよいです。
注：ちなみにこのタイミングで VPC の動的ルーティングモードを「グローバル」に変更しておきます。
具体的な設定方法はオンプレミスのルーターによって違いますが、たとえばテストで使ってる Quagga ではこんな設定（抜粋）になります。
router bgp 65030
neighbor 169.254.33.1 route-map peer1-in in # 東京のBGPセッション
neighbor 169.254.44.1 route-map peer2-in in # 大阪のBGPセッション
!
route-map peer1-in permit 10
set local-preference 200
!
route-map peer2-in permit 10
set local-preference 100
!これは、東京の BGP セッションで受け取った経路の Local Preference を 200 に、大阪の BGP セッションで受け取った経路の Local Preference を 100 にする、という設定になります。
Local Preference とは経路の優先度のことで、値が大きい方が優先されます。つまり、東京で受け取った経路を、大阪で受け取った経路より優先させる、という意味になります。
この設定をする前と後で、オンプレミスルーターの経路表がどう変化するか見てみましょう。
上記設定を入れる前bgpd# show ip bgp
BGP table version is 0, local router ID is 169.254.33.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 172.22.33.0/24 0.0.0.0 0 32768 i
* 192.168.111.0 169.254.44.1 308 0 65010 ?
*> 192.168.111.0 169.254.33.1 100 0 65010 ?
* 192.168.222.0 169.254.33.1 308 0 65010 ?
*> 192.168.222.0 169.254.44.1 100 0 65010 ?上記設定を入れた後bgpd# show ip bgp
BGP table version is 0, local router ID is 169.254.33.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 172.22.33.0/24 0.0.0.0 0 32768 i
* 192.168.111.0 169.254.44.1 308 100 0 65010 ?
*> 192.168.111.0 169.254.33.1 100 200 0 65010 ?
*> 192.168.222.0 169.254.33.1 308 200 0 65010 ?
* 192.168.222.0 169.254.44.1 100 100 0 65010 ?Displayed 3 out of 5 total prefixes
慣れないと上記出力がそもそも分かりにくいと思いますが、抜粋するとこうなります。
上記設定を入れる前Network Next Hop
192.168.111.0 169.254.33.1 (東京 192.168.111.0 は東京 169.254.33.1 へ)
192.168.222.0 169.254.44.1 (大阪 192.168.222.0 は大阪 169.254.44.1 へ)上記設定を入れた後Network Next Hop LocPrf
192.168.111.0 169.254.33.1 200
192.168.222.0 169.254.33.1 200東京・大阪のネットワークのいずれへ行く場合も、東京 169.254.33.1 へ (LocPrf は Local Preference の略です)
上記の通り、デフォルトでは東京宛ては東京の VPN トンネル経由、大阪宛は大阪の VPN トンネル経由だったのが、東京からの経路の優先度（Local Preference）が高く（200）なったことで、どちら宛ても東京経由に変化したことが分かります。
VPC からオンプレミスへのトラフィック
オンプレミスから VPC へのトラフィックが両リージョン宛てとも東京の VPN トンネルを通るように設定できたので、今度は逆向き、VPC からオンプレミスへのトラフィックがどちらも東京を通るように設定します。
考え方は同じで、大阪の Cloud Router で受け取った経路よりも、東京の Cloud Router で受け取った経路の VPC 内での優先度が高くなるようにします。
Cloud Router が受け取った経路の VPC 内での優先度には、基本的にはオンプレミスルーターから受け取った経路の属性である MED (Multi Exit Discriminator — メトリック)の値が使われます。
つまり前のセクションでやったのと同じ考え方にのっとり、オンプレミスのルーターで、
- 東京の BGP セッションで広告する経路の優先度を高く
- 大阪の BGP セッションで広告する経路の優先度を低く
すればよさそうな気がします。受け取った経路の優先度は Local Preference で設定しましたが、広告する経路の優先度は上述の通り MED で設定します。Quagga の設定だとこんな感じになります。Local Preference の値とは逆に、MED は値が小さい方が優先度が高いので、東京の BGP セッションの方に小さい MED を設定してます。
router bgp 65030
neighbor 169.254.33.1 route-map peer1-out out# 東京のBGPセッション
neighbor 169.254.44.1 route-map peer2-out out# 大阪のBGPセッション
!
route-map peer1-out permit 10
set local-preference 100
!
route-map peer2-out permit 10
set local-preference 200
!設定後、VPC のルートの様子を見るとこんな風になり、MED に設定した値が優先度のところに反映されてることが分かるかと思います。（東京の Cloud Router lab-cr1 で受けた経路の優先度が 100、大阪の Cloud Router lab-cr2 で受けた経路の優先度が 200 になっています。MED と同じく、値が小さい方が優先度が高いです。）
ではこの状態で大阪の VM lab-vm2 からオンプレミスサーバーへのアクセスが東京経由になることを確認します。
ご覧の通り、無事、東京の VPN トンネル経由になり…ません。lab-vpn2 を経由しているので、これは大阪の VPN トンネル経由になっています。
VPC ルートの優先度は正しく反映されているのになぜでしょうか？
VPC の動的ルーティングモードが「グローバル」になっている場合は、あるリージョンで受け取った経路は他のリージョンでも利用できるようになると上の方で説明しましたが、他のリージョンに経路が伝播する際に優先度が加算されるのです。たとえば、東京リージョンと大阪リージョンの間では優先度に 208 が加算されます。
つまり、起こってるのはこういうことです。
- 東京リージョンでオンプレミスから MED 100 の 172.22.33.0/24 という経路を受け取り、優先度 100 のルートとして保持されます。
- 東京で受け取った優先度 100 のルート 172.22.33.0/24 を大阪へ伝播させます。その際、優先度に 208 が足され、優先度が 308 になります。
- 一方、大阪ではオンプレミスから MED 200 の 172.22.33.0/24 という経路を受け取っており、優先度 200 のルートとして保持されています。
- 最後に大阪では、東京から来た優先度 308 のルート 172.22.33.0/24 と、オンプレミスから直接受け取った優先度 200 のルート 172.22.33.0/24 が比較され、優先度の高い（値の小さい）優先度 200 のルートが選択されます。（＝ 東京経由のルートは破棄され、大阪経由のルートが選択されます）
補足：VPC ルートのリストでは、オンプレミスから受け取った経路しか表示されておらず、他リージョンから伝播してきた経路（上の図の「比較」の右側の経路）が表示されておらず、そもそも上の図のような比較がおこなわれてること自体が見えず、分かりにくいですね…。
ということは、オンプレミスから広告する経路の MED を308 より大きくすれば東京から伝播してきた経路が選択されそうです。早速オンプレミスルーターの設定を変更してみましょう。
route-map peer1-out permit 10
set local-preference 100
!
route-map peer2-out permit 10
set local-preference 309
!
この状態で再度、接続テストをおこなってみます。今度は無事、東京の VPN トンネル（lab-vpn1）が選択されました。
ところで「じゃあ、オンプレミスからの MED を 308 にしたらどうなるの？」と思われた方は鋭いです。つまり、オンプレミスから受け取ったルートの優先度と、東京から伝播してきたルートの優先度が同じ場合です。
この場合は Equal Cost Multi Path (ECMP) という状態になり、両方の経路が利用されます。ドキュメントでは次のように説明されています。
Google Cloud は、アフィニティ用に 5 タプルハッシュを使用してルート候補のネクストホップ間にパケットを分散させ、ECMP（equal-cost multi-path）を実装します。ハッシュ計算は、この段階のルート候補の数に基づき、パケットの送信時にパケットごとに行われます。ルートの候補数が変わると、同じ 5 タプルハッシュを持つパケットを別のネクストホップに転送する場合があります。つまり、パケットのポート番号だったりによって、東京経由か大阪経由かのいずれかが選ばれるということです。
補足：接続テストは残念ながらまだ ECMP の表示に対応していません。
ところで、リージョン間で足される優先度の値（「コスト」と呼んだりします）は、それぞれのリージョン間ですべて内部的に決まっているのですが、残念ながら公開されているリストはありません。（また、ドキュメントにもあるように、定期的に変化することがあります。）
上の例では、東京リージョン、大阪リージョン間で 208 が足されるという ことを知っていたので、オンプレミスから経路を広告する際の MED の値の差が 208 より大きくなるように（つまり、東京からの広告は 100、大阪からの広告は 308 に設定）できましたが、知らなかったり、そもそも変化するんだと、どうやって MED（優先度）を設定したらよいのでしょうか。
ドキュメントを確認すると、以下のようにリージョン間のコストは 201〜9999 の範囲であることが分かります。したがって、MED の値の差が 10000 以上になるように設定すれば、リージョン間コストが加算されることの影響を受けなくできます。
リージョン間のコストは 201 以上、9999 以下の範囲です。値は、2 つのリージョン間の距離やレイテンシなどの要因によって異なります。Google がリージョン間のコストの値を生成します。変更することはできません。リージョン間で優先度を加算する理由
そもそもどうしてリージョン間でルートを伝播させる時、優先度を加算するんでしょう。
実は、オンプレミスから VPC へのトラフィックの章に出てきた、オンプレミスルーターの経路表にヒントがあります。
bgpd# show ip bgp
BGP table version is 0, local router ID is 169.254.33.2
Status codes: s suppressed, d damped, h history, * valid, > best, = multipath,
i internal, r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incompleteNetwork Next Hop Metric LocPrf Weight Path
*> 172.22.33.0/24 0.0.0.0 0 32768 i
* 192.168.111.0 169.254.44.1 308 0 65010 ?
*> 192.168.111.0 169.254.33.1 100 0 65010 ?
* 192.168.222.0 169.254.33.1 308 0 65010 ?
*> 192.168.222.0 169.254.44.1 100 0 65010 ?
これは Local Preference の設定を入れる前のオンプレミスルーターでの経路表ですが、東京のサブネット（192.168.111.0/24）宛ての経路が二つ（東京のトンネル 169.254.33.1 経由と、大阪のトンネル 169.254.44.1 経由の二つ）と、大阪のサブネット（192.168.222.0/24）宛ての経路が二つ、とそれぞれあることが分かります。
そして、東京のサブネット 192.168.111.0/24 の経路に注目すると、ネクストホップが違うことともう一つ、Metric という列（MED の値に相当します）の値が違う（100 と 308）ことに気づかれると思います。
東京の Cloud Router 169.254.33.1 から広告された経路の MED は 100、大阪の Cloud Router 169.254.44.1 から広告された経路の MED は 308 となっており、これは東京のサブネット経路が東京から大阪に伝播する際、優先度に 208 が加算された結果となります。
補足：Cloud Router がオンプレミスへ経路を広告する際、デフォルトでは MED の値は 100 となります。ですので、東京から広告された東京の経路の MED は 100、大阪から広告された東京の経路の MED は 100 + 208 = 308 となります。
MED の値が違う（優先度が加算される）ことによって、
- 東京のサブネット 192.168.111.0/24 へは MED の値が小さい（100）、東京の Cloud Router 169.254.33.1 からの経路
- 大阪のサブネット 192.168.222.0/24 へは同じく MED の値が小さい（100）、大阪の Cloud Router 169.254.44.1 からの経路
がそれぞれ選択されてます。（行頭の *> となってるところの > の部分が、その経路が選択されたことを示しています。）つまり、特に何もしなくても宛先サブネットに近い方の VPN トンネルを通るように経路選択できています。
では、優先度の加算がなかったとしたらどうなるでしょう。
もし VPC 内で優先度が加算されてなかった場合、東京・大阪の両 Cloud Router からの経路広告はいずれも MED 100 となってしまい、オンプレミスルーターはどちらの経路を優先すればいいのか判断がつかなくなってしまいます。その結果、たとえば東京のサブネットに到達するのに、大阪の VPN トンネル使ってしまい、遠回りになってしまっていたかもしれません。
このように、VPC 内部で経路伝播時に優先度に加算をすることで、オンプレミスルーター側にどの経路広告が接続先ネットワークに一番近いかを伝えることができているのです。
補足：インターネットサービスプロバイダ内でよく使われる BGP の設定に、BGP の MED として IGP のコストを設定するというものがありますが、この「優先度の加算」という仕組みはそれと同じようなものだと考えることができると思います。
まとめ
というわけで、無事にトラフィックが図のような流れになるよう、ルーティングの設定をすることができました。
設定のポイントは以下の通りです。
- オンプレミスから VPC へのトラフィックは、オンプレミスルーターの受信経路の優先度（Local Preference）の設定で操作 （値が大きい方が優先）
- VPC からオンプレミスへのトラフィックは、オンプレミスルーターからの広告経路のメトリック（MED）で操作 （値が小さい方が優先）
- オンプレミスから広告された経路が VPC 内で伝播する際、リージョン間コストが加算されるため、MED で優先度を操作する場合、値の差を 10000 以上にしておく
また、上記設定の前提知識として、VPC の動的ルーティングモードの設定が、ルーティングに与える影響を見ました。
本記事が Google Cloud とオンプレミスを接続し、ルーティングの設計をする際の一助となれば嬉しいです。
