このご時世、SD-WANだSASE導入だとかトリガはいろいろあるでしょうが
DirectConnectからCATOに移行じゃ、というお達しを受けている方も
自分以外にいらっしゃると思います。が、
とにかく情報の少ないCATOというかvSocket
新規接続はともかくDirectConnectからの切り替えの手順がないと
停止時間の見積もりすらできず(*)本人も利用部門の方もいろいろ困るので
記事にしました。同じ境遇の方の参考になれば。
(*)慣れれば＆事前設定を済ませておけば切り替え当日の作業時間は15分弱、通信停止時間も数分程度です
前提条件
・CATOの契約もしくはPoC環境がありAWS側にvSocketが導入済みである事
(vSocketの導入も地味に面倒なので要望あれば設定手順とか図とか記事にします)
全体の流れ
手順をざっくり図にするとこんな感じ。④の設定が不要な事は後で気づきました。
①～② 事前準備可能
③～⑦ 切り替え当日作業順序
TransitGatewayAttachmentって?
こんなところに来てる時点でそんな人もいないと思いますが
TGA(TransitGatewayAttachment)に馴染みの無い方に補足しますと
ざっくり以下のイメージをしていただけると以下の設定内容が掴みやすいと思います。
TGAはGW間を繋ぐためのケーブル＋ポートのようなものでこれ自体にルート情報はありません。
あるのはあくまでどのGWに繋がっているかという情報のみ。
経路情報は繋いだGW間でよろしくやってます。
接続先のAWSアカウントがまたがる場合先方の許可が必要で↑の図で線が
TGW(TransitGW)に繋がってない状態なのはそれ（許可待ち）を意図してます。
本題
以下作業手順になりますが、AWSのどっちの作業をしているのか分かるように
[親] CATO(vSocket)側AWSアカウントの設定
[子] 移行対象DC利用AWSアカウント設定
を示しています
① AWS管理画面 : TGA作成
[親] RAMからTGWに追加接続するアカウントの共有を設定します
[子] RAMにて同リソースの共有確定
Pending ステータスになっているので許諾
[子] TGWが利用できるようになるので、TGA作成>TGWへの接続設定まで進める
② AWS管理画面 : TransitGateway ルートテーブル
[親] ①で作成された子TGAのTGW接続許可
[親] TGA接続によりTGW上のルートもこの辺りに自動的に追加されている事を確認
TGW のルートテーブルに 0.0.0.0/0 のルート記載があると 別AZからのTGA接続がある場合
通信エラーが発生するので設定しないでください
[親] vSocket LAN のルートテーブルにもTGWへの静的ルート追加
ここまでが前日までの事前作業になります。
切り替え当日朝の作業はいよいよここからです。
③ AWS管理画面 : DirectConnect BGP停止
[子] AWS Direct Connect > 仮想インターフェイス でBGP停止
時間設定ができるので、初回は作業途中で再開してしまわないよう長めに時間設定しておいた方がいいです。
④vSocketルーティング追加
⑤ CC2管理画面 : Site ルート追加
CC2(CATO管理画面) の対象vSocket site の Routing>Networksで今回移行する
ネットワークのルートを追加します
⑥ AWS管理画面 : 対象サブネットのルーティング切り替え
[子] ルートテーブル / 切り替え対象VPC側 にTGW方向のルートを追加
⑦ 端末からAWS上のサーバへの通信確認
切り替え1分も待たずに経路変更され疎通できるようになります。
数分立っても繋がらないようであれば
対象EC2の "ネットワーキング" > "Reachability Analyzer" で
LAN側への経路確認をお薦めします。
⑧ AWS管理画面 : 後片付け
[子] DCのBGP , DCGW , VGW の削除を行います
BGPはほっておくと再度有効化してしまうので削除忘れずに！
補足というか注意 : CATO オフクラウド接続について
CATOは拠点からCATO網への接続に帯域ライセンス購入が必須なのですがこれが結構高い。
なお、CATOにはSD-WAN機能の１つとしてCATO網を経由せず拠点間を直接接続できる
オフクラウド接続という機能があります。
これだけ聞くと「お、ライセンス消費無しで1Gbpsで繋げんじゃん」と思ってしまうのですが
実際にはオフクラウド接続も上記帯域ライセンスの制限がかかります。
この点リセラーの営業も分かってないケースが多々あるので導入検討の際はミスリードされないようご注意を。