#1. はじめに
IBM Cloudには、Classic InfrastructureやVPCと呼ばれるx86系のIaaSと、Power Systems Virtual Server（以下PowerVS)と呼ばれるPower系のサーバー（AIXやIBMiなどを提供）があります。これらは直接は繋がっておらず、Direct Linkを別途注文することで接続可能となります。
なお、上記リンクにも記載されているとおり、IBM Cloud(x86)とPowerVS間は、Direct Link Classicを使ってもDirect Link 2.0を使っても、以下の条件内であれば無料です。
The Power Systems Virtual Server offering now includes a highly available 5 Gbps connection to IBM Cloud services at no cost for each customer per data center. If desired, you can select the global routing option for these links at no cost.
ということで、新規に注文するのであれば、複数のVPCやClassic Infrastructureへの同時接続が可能であるDirect Link 2.0を使った方がお得なので、実際に注文してみました。今回は、PowerVSとIBM Cloud(x86)のVPCの手順を実際に追ってみたいと思います。
#2. Direct Link Connect 2.0の注文(IBM Cloudポータル）
- メニューから
Interconnectivityを選択。
-
Direct Linkを選択。
-
Order Direct Linkを選択。
-
Direct Link nameを入力し、Resource groupを選択。Billingは、とりあえずUnmeteredでも料金は変わらないみたいなので、そちらを選択。
- 今回は東京リージョンのPowerVSとIBM Cloud(x86)を接続したいので、
Tokyo 4を選択。またGlobal Routingも無償なのでこちらも選択しておく。これにより、PowerVSから他のRegionに接続することも可能になる。また、ProviderとしてIBM POWER VSを選択する。
-
BGP and connectionsにて、ポートを１つ選択する。
なお、ポートの構成は以下のようになっている。
BGP ASNは接続ガイドにもあるとおり、64999を選択する。
[追記]BGP peering subnetは今回は、Auto-select IPを選択して、169.254.0.0/16から自動選択するようにしたが、Manual-select IPを選択して明示的にRFC1918のprivate networkのsubnetから選択した方が、そのsubnetにもpingが打てるようになって問題判別が容易になるため望ましいかもしれない。今回は、自動選択される169.254.0.0/16はリンクローカルアドレスであり、そのsubnetにはPowerVSやIBM Cloud(x86)のサーバーからは通信はできない。 - Connection設定（IBM Cloud(x86)のどのVPCやClassic Infrastructureと接続するかを指定）は、後からでも構成できるので、いったんこのままにする。
- 数分程度待つと、プロビジョニングが完了し、IBM Cloud(x86)側の接続が完了する。
#3. Power Systems VSへのCaseの起票。
PowerVSに対してCaseを起票し、先述のDirect Link Connect 2.0へのポートとの接続依頼を行います。以下はCaseの起票例です。
（たまたま担当者がすぐに対応してくれて運が良かっただけなのかもしれませんが）今回は、その２時間後にはPowerVS側のサポートチームから回答があり、接続が完了しました！IBM Cloud Portal側でも、BGP StatusがEstablishedに変更されたことがわかります。
#4. Direct Link 2.0のVPCへの接続
現時点では、IBM Cloud(x86)側のDirect Link Connect 2.0はどのIaaS環境とも接続していないため、接続先を選択する必要があります。今回は、すでに作成済みのVPCに接続したいと思います。
- Add Connectionを選択
- 既存のVPCを選択
3.しばらく待つと、Readyになる。
#5. PowerVSにおけるStatic routingの構成
今回、PowerVSでは、サーバーに以下のように192.168.50.0/24というprivate NWが構成されています。
- VPC側は、Implicit Routerがdefault gatewayになっているので、特にPower VSのネットワーク(今回の場合は、192.168.50.0/24)宛の通信への追加対応不要です。ただし、Network ACLやSecurity Groupで通信が許可されていることは確認しておいてください。
- Power VS側は、このままではVPC宛のパケットまでDefault Gatewayの方に転送されてしまうため、Private NWが接続されている192.168.50.1(Gateway Address)に対してVPC宛のstatic routeを構成する必要があります。
# netstat -nr -f inet
Routing tables
Destination Gateway Flags Refs Use If Exp Groups
Route tree for Protocol Family 2 (Internet):
default 192.168.186.57 UG 1 12825 en0 - -
127/8 127.0.0.1 U 4 8237 lo0 - -
192.168.50.0 192.168.50.223 UHSb 0 0 en1 - - =>
192.168.50/24 192.168.50.223 U 0 2 en1 - -
192.168.50.223 127.0.0.1 UGHS 0 0 lo0 - -
192.168.50.255 192.168.50.223 UHSb 0 4 en1 - -
192.168.186.56 192.168.186.60 UHSb 0 0 en0 - - =>
192.168.186.56/29 192.168.186.60 U 1 2 en0 - -
192.168.186.60 127.0.0.1 UGHS 0 0 lo0 - -
192.168.186.63 192.168.186.60 UHSb 0 4 en0 - -
# smitty route
今回は、VPCが10.x.x.xだったので、シンプルに10.0.0.0/8宛を全部192.168.50.1に転送するようにしました。
# netstat -nr -f inet
Routing tables
Destination Gateway Flags Refs Use If Exp Groups
Route tree for Protocol Family 2 (Internet):
default 192.168.186.57 UG 2 1914070 en0 - -
10/8 192.168.50.1 UGS 0 589168 en1 - -
127/8 127.0.0.1 U 4 682772 lo0 - -
172.16/24 192.168.50.1 UGS 1 67699 en1 - -
192.168.50.0 192.168.50.223 UHSb 0 0 en1 - - =>
192.168.50/24 192.168.50.223 U 2 13 en1 - -
192.168.50.223 127.0.0.1 UGHS 0 0 lo0 - -
192.168.50.255 192.168.50.223 UHSb 0 4 en1 - -
192.168.186.56 192.168.186.60 UHSb 0 0 en0 - - =>
192.168.186.56/29 192.168.186.60 U 1 2 en0 - -
192.168.186.60 127.0.0.1 UGHS 6 38437 lo0 - -
192.168.186.63 192.168.186.60 UHSb 0 4 en0 - -
これで疎通は可能になるはずです。
# ping -c 3 10.4.0.4
PING 10.4.0.4 (10.4.0.4): 56 data bytes
64 bytes from 10.4.0.4: icmp_seq=0 ttl=54 time=1 ms
64 bytes from 10.4.0.4: icmp_seq=1 ttl=54 time=1 ms
64 bytes from 10.4.0.4: icmp_seq=2 ttl=54 time=1 ms
--- 10.4.0.4 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1/1/1 ms
# ping -c 3 192.168.50.223
PING 192.168.50.223 (192.168.50.223) 56(84) bytes of data.
64 bytes from 192.168.50.223: icmp_seq=1 ttl=245 time=1.55 ms
64 bytes from 192.168.50.223: icmp_seq=2 ttl=245 time=1.64 ms
64 bytes from 192.168.50.223: icmp_seq=3 ttl=245 time=1.56 ms
--- 192.168.50.223 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 1.553/1.586/1.644/0.041 ms
#参考: Trouble Shooting
うまくいかない時は以下を確認しましょう。
- IBM Cloud(x86):
- PowerVSへのStatic Routingの構成はされているか？（VPCであれば不要だが、Classic Infrastructureであれば必要）
- Network ACLやSecurity Groupで通信がブロックされていないか？
- PowerVS:
- IBM Cloud(x86)へのStatic Routingの構成はされているか？
また、それでもうまくいかない場合は、Caseを起票する必要がありますが、以下の問題判別を実施すると良いでしょう。
- PowerVS:
- Private NW側のGatewayアドレスにpingができるかどうか？
- VLAN-IDは実機とCustomer Portal上で合致しているか？確認例はこちら
- BGP peering subnetへpingができるかどうか？（Auto-select IPを選択していない場合に限る）
- PowerVS -> IBM Cloud(x86)へのpingにおいて、IBM Cloud(x86)側でtcpdumpを取得し、パケットの到達状況などを確認。Linux上での実行例:
tcpdump -i eth0 icmp -nn - CaseでBGP経路情報を問い合わせし、IBM Cloud(x86)からの経路広告を受け取っていることを確認。
- IBM Cloud(x86):
- BGP peering subnetへpingができるかどうか？（Auto-select IPを選択していない場合に限る）
- IBM Cloud(x86) -> PowerVSへのpingにおいて、PowerVS側でtcpdumpを取得し、パケットの到達状況などを確認。AIX上での実行例:
tcpdump -i en1 icmp -nn - CaseでBGP経路情報を問い合わせし、PowerVSからの経路広告を受け取っていることを確認。