ExpressRoute 折り返しで multi hub-spoke の構成を試す
今回は ExpressRoute circuit を利用して 2 つの hub を接続します。
言い方としては完全閉域での接続となります。
メリットとしては Azure Route Server を利用せずとてもシンプルな構成です。
デメリットとしては帯域が ExpressRoute circuit および ExpressRoute Gateway の SKU に依存します。
その他の実装方法はこちらにまとめています。
構成のポイント
hub と spoke との VNet Peering において "Use the remote virtual network's gateway or Route Server" オプションを有効化することで spoke のアドレス空間が ExpressRoute の BGP に乗ります。
そのため、お互いの ExpressRoute 接続において hub と 2 つの spoke の合計 3 つの経路が広報され動的ルーティングにより学習するため、この構成でも spoke-to-spoke の接続が実現します。
前回同様、spoke10 と spoke20 の間は通信ができませんが、UDR などで容易に到達性を持たせられるため省略しています。
動作確認
動作確認のスクリーンショットはこちらです。
裏に隠れているのが vm-spoke10 自体の Server Manager、左下が vm-hub00、右下が vm-hub100、その上に vm-spoke110 と vm-spoke120 という感じです。
vm-spoke10 の effective routes はどのようになっているか
結局ここが重要なので、確認しておきます。
vm-spoke10 の NIC である nic-spoke10 において、effective routes から表示させます。
10.10.0.0/16 が vm-spoke10 のある VNet の IP アドレス空間となっています。
10.0.0.0/16 は直接つながっている hub となっているので Next Hop Type が VNet peering となっています。
そのほか 2 番目の hub である 10.100.0.0/16 やその先にある spoke たちである 10.110.0.0/16 と 10.120.0.0/16 は Virtual network gateway となっています。
これは ExpressRoute 経由で折り返し接続なのでまぁ妥当かと思います。
この場合の Next Hop IP Address は Azure 内部のどこかの IP アドレスがそのまま表示されてしまっているのであまり気にする必要はありません。(10.2.146.76 と 10.2.146.77)
| Source | State | Address Prefixes | Next Hop Type | Next Hop IP Address | User Defined Route Name |
|---|---|---|---|---|---|
| Default | Active | 10.10.0.0/16 | Virtual network | - | - |
| Default | Active | 10.0.0.0/16 | VNet peering | - | - |
| Virtual network gateway | Active | 10.100.0.0/16 | Virtual network gateway | 10.2.146.76 | - |
| Virtual network gateway | Active | 10.100.0.0/16 | Virtual network gateway | 10.2.146.77 | - |
| Virtual network gateway | Active | 10.120.0.0/16 | Virtual network gateway | 10.2.146.76 | - |
| Virtual network gateway | Active | 10.120.0.0/16 | Virtual network gateway | 10.2.146.77 | - |
| Virtual network gateway | Active | 10.110.0.0/16 | Virtual network gateway | 10.2.146.76 | - |
| Virtual network gateway | Active | 10.110.0.0/16 | Virtual network gateway | 10.2.146.77 | - |
tracert の結果はどうなるか
事前に、tracert に反応させるため、それぞれの Windows Server では Windows Firewall with Advanced Security を無効化しておきます。
まず、となりの hub にある vm-hub00 までは 1 hop で見えてきます。
> tracert -d 10.0.0.5
Tracing route to 10.0.0.5 over a maximum of 30 hops
1 2 ms 1 ms <1 ms 10.0.0.5
Trace complete.
別の hub およびその spoke たちに対しては、2 hop で見えてきます。
RTT がやたら長いですが、これは検証環境の VM たちは East Asia、ExpressRoute circuit が Japan East にあるためで、今回はあまり気にしなくてよいです。
途中に反応しないコンポーネントがあるようですが、おそらく ExpressRoute を構成する何かだと思います。
こちらもあまり気にするポイントではありません。
いずれにせよ無駄な経路を通らず、意図とおりに通信できているように見えます。
> tracert -d 10.100.0.5
Tracing route to 10.100.0.5 over a maximum of 30 hops
1 * * * Request timed out.
2 105 ms 106 ms 105 ms 10.100.0.5
Trace complete.
> tracert -d 10.110.0.5
Tracing route to 10.110.0.5 over a maximum of 30 hops
1 * * * Request timed out.
2 113 ms 110 ms 110 ms 10.110.0.5
Trace complete.
> tracert -d 10.120.0.5
Tracing route to 10.120.0.5 over a maximum of 30 hops
1 * * * Request timed out.
2 106 ms 105 ms 106 ms 10.120.0.5
Trace complete.
参考実装はこちらです。
書き直したタイミングで Ubuntu Server 20.04 にしてしまいました、ごめんなさい。
Discussion