Cross ConnectでAWSをCatoへ繋いでみよう

前回記事は、パブリッククラウド環境をCatoクラウドへ接続する方法として、vSocketとCross Connectを比較してみました。

vSocket × Cloud Interconnect 徹底比較

パブリッククラウドをCatoクラウドへ接続する方法「vSocket」と「Cross Connect」を性能面・コスト面等から比較します。

続いて、本記事では実際にAWSをCross ConnectでCatoクラウドに接続する際の流れをご紹介します。

各パブリッククラウドの接続手順は、以下のCato Knowledge Baseもご参照ください。

Cato Knowledge Base | Cato Cross Connect Sites

まずは構成を決める
Cross Connect用Siteを作成する
必要情報をCatoパートナーへ連絡する
AWS側の設定を行う
CatoのSite側の設定を行う
接続テストを行う
AWS側のルートテーブルを設定・確認する
その他補足情報
まとめ

まずは構成を決める

接続ロケーションを決める

AWSのDirect Connectロケーションと、CatoのCross Connectロケーションを照らし合わせ、利用するロケーションを2つ選択します。

AWS Direct Connect Locations

Cato Knowledge Base | Cato Cross Connect Availability

2023年11月現在、日本国内のCross Connectロケーションは以下2つのみですので、AWSの東京または大阪リージョンを利用する場合には、この2つを選択します。

Equinix TY2, Tokyo, Japan
Equinix OS1, Osaka, Japan

ネットワーク構成を決める

続いて、ネットワーク構成を検討します。構成イメージとしては、Transit Gatewayを使うパターンと使わないパターンが考えられます。選択のポイントは、接続したいVPCが(将来の拡張も含めて)いくつあるかです。

構成例A : Transit Gatewayを利用しないパターン

Direct Connect Gatewayに接続できるVPCの上限が20です。
VPC同士のDirect Connect Gatewayでの折返し通信は、基本的には対応していません。※詳細はAWS側の仕様をご確認ください

構成例B : Transit Gatewayを利用するパターン

Transit Gatewayに接続できるアタッチメントの上限が5,000です。
Direct Connect Gatewayに接続できるTransit Gateway の上限が6です。
- 上記2点より、たくさんのVPCを接続する構成が可能です。
Transit GatewayでVPC同士の折返し通信ができます。※通信させない構成も可能です
構成例Aと比較し、Transit Gatewayおよびアタッチメントの利用料金が発生します。

なお、構成例Aで構築した後にBに変更することも可能ですが、その際は、AWS側の設計変更や構成変更時の通信断が発生します。

ASNを割り振る

各仮想プライベートゲートウェイ(VGW)、Direct Connectゲートウェイ(DXGW)、トランジットゲートウェイ(TGW)と、Cato側の設備はBGPで経路交換を行うため、重複しないAS番号(ASN)を割り当てる必要があります。

なお、Cato側のASNは2byte(64512～65535)のみ対応しておりますが、4byte ASNとのピアリングに対応しているため、AWS側のASNは2byte、4byte(4200000000～4294967294)のどちらでも可能です。

Direct Connect接続部分のIPアドレスを決める

Direct Connect の両端に、接続セグメントを作成します。

具体的には、社内ネットワークで利用されていないIPアドレスレンジから、/30のIPアドレスレンジを2つ割当し、Cato側・AWS側のIPアドレスを決めます。

例として、検証用に構成を作成し、ASNとIPアドレスを割り当てた図が以下です。

以上で、構成が確定です。

Cross Connect用Siteを作成する

続いて、Cato Management Consoleから、Cross Connectで接続するSiteを作成します。

作成方法は通常のSiteと同じですが、Connection Type は「Cross Connect」を選択します。

この時点ではSiteを作成するのみでOKです。他の設定はDirect Connectの開通後に行います。

必要情報をCatoパートナーへ連絡する

ここまで準備ができたら、実際にDirect ConnectをCato側から接続してもらうよう、以下の必要情報をCatoサービスの提供元へ連絡します。

	項目	説明	記載例
1	対象のCato Site名	手順2で作成したSite名	CrossConnectAWS
2	接続するパブリッククラウド	AWS/Azure/GCP/ Oracle Cloud	AWS
3	パブリッククラウドのアカウントID	上記のアカウント	AWSアカウント(数字12桁)
4	パブリッククラウドの利用リージョン	メインで利用されるリージョン	ap-northeast-1(Tokyo)
5	Primary Linkのロケーション	手順1で選択したもの	Equinix TY2, Tokyo
6	Secondary Linkのロケーション	手順1で選択したもの	Equinix OS1, Osaka
7	接続帯域	回線帯域	1Gbps

申請後、接続が準備されるまでに必要時間は、ロケーションによって異なります。1.のCross Connectロケーション一覧に納期の目安が書いてありますので、ご参照ください。2023年11月現在は日本ですと2週間程度となっています。

接続が準備され次第、パートナーから完了の連絡があります。

AWS側の設定を行う

パートナーから準備完了の連絡を受けたら、AWS側・Cato側それぞれに設定を行っていきます。

なお、以後の手順はすべて、前述の「構成例A Transit Gatewayを利用しない」パターンでの例となります。

Direct Connect接続をAcceptする

AWSコンソールの「Direct Connect」を確認すると、以下のように接続が準備されています。

状態がorderingとなっており、承諾待ちの状態です。IDをクリックすると「承諾する」ボタンがありますので、これをクリックして接続を承諾します。 2回線それぞれ承諾します。

しばらくすると状態が「available」になります。

Direct Connect Gatewayを作成する

設定項目は名称とASNのみです。ASNは手順1で決めたものを指定します。

この手順は、新規の環境を想定した例となっています。すでに各VPCで仮想プライベートゲートウェイ(VGW)を利用し通信を行っている場合、これ以降の作業により既存の通信が切断される可能性がありますので、十分にご注意ください。

Direct Connect Gatewayと仮想プライベートゲートウェイを紐付けする

作成したDirect Connect Gateway(以下DXGW)をクリックし、「ゲートウェイを関連付ける」に進みます。

紐付ける仮想プライベートゲートウェイ(以下VGW)をすべて選択します。

また、「許可されたプレフィックス」は、Cato側にBGPで広報するルートとなります。空欄にした場合には、各VPCのアドレスレンジが自動で広報されますので、特に要件がなければ空欄で問題ありません。

仮想インターフェイスを作成する

Primary、Secondaryそれぞれの接続に対し、仮想インターフェイス(以下VIF)を作成します。

以後、AWS側・Cato側でそれぞれ設定を行っていきますが、お互いがお互いを「Peer(ピア)」と呼ぶので、IPアドレスやASNの設定項目がCato側を指しているのかAWS側を指しているのかを間違いやすいです。作成した構成図を見ながら作業されることをおすすめします。

以下に設定項目の例を掲載します。

タイプ	VIFをDXGWへ接続する場合は「プライベート」を選択
仮想インターフェイス名	任意の名前を入力
接続	VIFを作成するDirect Connect接続をプルダウンで選択
仮想インターフェイスの所有者	通常は「自分のAWSアカウント」

ゲートウェイタイプ	DXGWへ接続する場合は「Direct Connect ゲートウェイ」を選択
Direct Connect ゲートウェイ	先ほど作成したものをプルダウンで選択
Virtual Local Area Network	元となるDirect Connect接続のVLANと同じ番号を指定
BGP ASN	手順1で決めたCato側のASNを指定

上記まで入力したら「▶追加設定」をクリックして下に進みます。ここを忘れがちです。

アドレスファミリー	IPv4を選択
ルーターのピアIP	Cato側のIPアドレス
AmazonルーターのピアIP	AWS側のIPアドレス
BGP認証キー	任意の文字列 ※設定必須
ジャンボMTU	チェックを入れない (Catoは非対応)
SiteLinkの有効化	チェックを入れない (Catoは非対応)

すべて設定したら作成ボタンを押します。Primary/SecondaryそれぞれのVIFを作成したら、AWS側の設定は完了です。

CatoのSite側の設定を行う

続いて、Cato側の設定を行います。

Cross Connectを設定する

Network > 対象Site > Cross Connect の設定項目にて、Primary/Secondary の接続情報を設定します。手順1での設計どおりIPアドレスを設定します。また契約帯域に合わせたBandwidthを指定します。

設定後、Saveします。CatoとAWS間の疎通にしばらく時間がかかるため、次へ進みます。

BGPを設定する

続いて、Cato側のBGP設定を行います。左メニューの「BGP」から「New」をクリックして設定を作成します。PrimaryとSecondaryの2つの設定が必要です。

Name	任意の名前を指定
ASN Settings Peer	手順1で割り当てたAWS側のASN (この構成だとDXGWのASN)
ASN Settings Cato	手順1で割り当てたCato側のASN
Peer	AWS側のIPアドレス

続いてBGP Policyの設定です。こちらはCatoおよびAWS内のルーティングに応じて設定する必要があります。

Advertise	AWS側に対してどのようにルートをアドバタイズするかの設定です。 Default routeにすると、0.0.0.0をアドバタイズします。もしAWS側で0.0.0.0を他に向ける必要がある場合には、All routesまたはSummary routesのアドバタイズをご検討ください。(※)
Accept	AWS側からのRouteを受け入れるかどうかです。通常はチェックを入れます。チェックを入れ忘れると、AWS側のルートをCatoで受け取らなくなってしまうので注意してください。
NAT	CatoからPeer宛の通信において、送信元IPアドレスをNATするかどうかです。チェックを入れた場合には、送信元IPがCato側のPeer IPアドレスに変換されます。

※AWSの場合受け取れるルート数の上限があります。All routesをアドバタイズすると上限を超えがちなため、ご注意ください。(2023年11月現在は上限100ルート)

MD5 Auth	AWS側で設定したのと同じBGP認証キーの文字列を入力。入力必須です。
Metric	低い値の経路が優先されますので、値をPrimary<Secondaryとするのが一般的ですが、Cato側で自動でPrimary側が優先されるため、Metricを同じ値にしても正常に動作します。(優先度の詳細は後述します)
Hold time	デフォルト値で問題ありません。もし接続先のクラウド側で指定があればそれに従ってください。
Keepalive interval	デフォルト値で問題ありません。もし接続先のクラウド側で指定があればそれに従ってください。
Email Notification	BGPピアがDown/Upした際にEメールで通知する機能です。接続監視のため設定されることをおすすめします。

PrimaryとSecondary両方のBGP設定を作成したら、Saveします。

以上で設定は完了です。

接続テストを行う

続いて接続が正常にできるかのテストを行います。

Connectivityのテスト

先ほど設定したCross Connect のページで「Test Connectivity」ボタンをクリックします。Cato側からAWSに対し、ICMPでの疎通テストが実行されます。

以下のように「Success!」と表示されたら接続成功です。もし「Failed!」やその他エラーとなる場合は、アドレス設定がAWS側の設定と相違ないかを確認します。

BGPのステータス確認

BGPの設定画面で、「Show BGP Status」をクリックすると、BGPの状態が確認できます。

BGP Status	BGP の接続状態です。「Established via ～」となっていれば正常に接続できています。「Not Established」やその他表示の場合、BGP Peerが張れていません。IPアドレスやASNが正しく設定されているか、BGP認証キーがAWS側と一致しているかを確認します。
Routes from neighbor	AWS側から受け取っているルートです。ここが空欄の場合、BGP設定でAcceptのチェックが外れている可能性があります。
Routes to neighbor	AWS側へ渡しているルートです。BGP設定のAdvertiseで設定したルートが渡されます。