モチベ
- Hub-Spoke構成のネットワークにおいて、Spoke間通信を実現するための手段の一つとして、ExpressRouteで折り返すパターンがMicrosoftのドキュメント上にあげられている
- 手段の一つとして挙げている一方で、"非推奨"であることが悉く強調されているのですが…(笑)
ExpressRoute. In certain configurations, an ExpressRoute gateway can advertise routes that attract spoke-to-spoke communication, sending traffic to the Microsoft edge router, where it's routed to the destination spoke. Microsoft strongly discourages this scenario because it introduces latency by sending traffic to the Microsoft backbone edge and back. On top of that, Microsoft does not recommend this approach, due to the single point of failure and the large blast radius. This scenario also presents multiple problems caused by putting extra pressure on the ExpressRoute infrastructure (the gateway and physical routers). This additional pressure can cause packet drops.
- ここまで書かれてこのパターンが採用されることはあるのかという疑問はさておき、ExpressRouteの性質の検証の一つとしてここで試しておく
用意する環境
以下のような、ExpressRouteを共有するマルチHub-Spoke環境を準備
Effective Routeの確認
- Hub002上のVMのEffective Routeを確認
- Hub002(10.50.0.0/16)上のVMからHub001(10.0.0.0/16)および、Hub001-Spoke(10.10.0.0/16)へのルートが見えている
疎通確認
-
pingでHub002上のWindows VM(10.50.0.4)からHub001-SpokeのUbuntu VM(10.10.0.4)への疎通確認
-
念のため、Hub002-Spoke上のUbuntu VM(10.60.0.4)からHub001-Spoke上のUbuntu VM(10.10.0.4)への疎通確認も行う
AzureAdmin@vm-clab-hub002-spoke:~$ ping 10.10.0.4
PING 10.10.0.4 (10.10.0.4) 56(84) bytes of data.
64 bytes from 10.10.0.4: icmp_seq=1 ttl=63 time=6.70 ms
64 bytes from 10.10.0.4: icmp_seq=2 ttl=63 time=5.33 ms
64 bytes from 10.10.0.4: icmp_seq=3 ttl=63 time=6.70 ms
64 bytes from 10.10.0.4: icmp_seq=4 ttl=63 time=5.80 ms
64 bytes from 10.10.0.4: icmp_seq=5 ttl=63 time=6.32 ms
64 bytes from 10.10.0.4: icmp_seq=6 ttl=63 time=5.29 ms
64 bytes from 10.10.0.4: icmp_seq=7 ttl=63 time=5.60 ms
^C
--- 10.10.0.4 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6010ms
rtt min/avg/max/mdev = 5.293/5.963/6.701/0.562 ms
つまり、ExpressRoute Circuit折り返しでHub002Spoke-ERGW-MSEE-ERGW-Hub001Spokeが成立することが確認できた。ということは、同じER Circuitを共有していると経路的には繋がっているHub-Spoke環境が見えてしまうため、ネットワークを完全に分離するにはER Circuitごと分ける必要があるといえる。。。
おまけ:Global Reach
- ついでに、ExpressRouteのGlobal Reach経由でリージョン間のVNET間通信ができるのでは？と思い、検証してみた
- 環境としては以下のようなイメージ(オンプレ側で西日本のExpressRoute用のスイッチの構成が手間だったため、単にAzure側だけ構成している)
Effective Routeの確認
- Japan West側のHubに置いたVMのEffective Routeを確認
- Japan East側のHub,Spokeのアドレス空間への経路がすべて流れ込んできている
- つまり、Global Reach経由でリージョン間ピアリング的なことができていることになる
- つまり、Global Reach経由でリージョン間ピアリング的なことができていることになる
念のため、Pingも確認
- Japan EastのHubのWindows VMからJapan WestのHubのUbuntu VMへPing
想定通り、疎通できた。
おわり
- 非推奨ながらもERCircuit折り返しで疎通ができることは確認できた
- 具体的にこのパターンが必要とされるケースは思いついていないが、性質として知っておくのはいいかもしれない、、！
Discussion