Telehouse OS2を含む冗長構成を検討するために、Direct Connectのルーティングポリシーを図に起こして理解する
前置き (飛ばしてOK)
大阪2番目のDirect Connectロケーションやったー!
元々要望を出していたこともあり、11~12月のラッシュの中でも特に嬉しい発表の一つでした。
さて、この新しいロケーションですが、下記URLのロケーション一覧を見ると、国内で唯一大阪リージョンに関連付けられていることが分かります。(Equinix OS1以外の国内ロケーションも全て東京リージョン)
大阪のロケーションを抜粋:AWS Direct Connect Location | Also accessible from: | Associated AWS Region | 1G | 10G | 100G |
---|---|---|---|---|---|
Telehouse OS2, Osaka, Japan | Asia Pacific (Osaka) | ✔ | ✔M | ✔M | |
Equinix OS1, Osaka, Japan** | Asia Pacific (Tokyo) | ✔ | ✔M | ✔M |
「確かに違うけど、それがどうしたん?」… そう思っていた時期が私にもありました。
Direct Connectのルーティングポリシー
上のURLに記載の通り、Direct Connectを経由するAWS→オンプレミス方向の通信経路は、下記の順番で評価されたうえで決定します。(すべて同じなら両方使われる(ECMP))
- プレフィックス長
- ローカルプリファレンス
- AS_PATH 長
- MED (非推奨)
このうち2のローカルプリファレンスがちょっと曲者なのですが、とりあえず当該部分を引用してみましょう。
この値は、7224:7200—Medium ローカルプレファレンスコミュニティ値が設定された、同じ AWS リージョン に関連付けられた AWS Direct Connect ロケーション を優先的に選択するように設定されます。ローカルリージョンが Direct Connect ロケーションに関連付けられていない場合、より低い値に設定されます。これは、ローカルプリファレンスコミュニティタグが使用されていない場合にのみ適用されます。
うーん、言いたいことは分からんでもないけど、別々のリージョンに関連付けられた複数ロケーション冗長構成の例が欲しい…
と探したところ、ちょうどいいナレッジ記事がre:Postにありました。
でも図がないので、せっかくだし図に起こしてみるか!というのが本記事の主題です。
re:Postのナレッジを図に起こしてみた
下記ナレッジ記事のシナリオ1を図に起こしてみます。
ベースとなる構成は下記の通り。
- us-east-1リージョンに1つのDirect Connect接続(DX1)があり、eu-west-1リージョンに2つ目の接続(DX2)があります。
- DX1とDX2には、オンプレミス機器からアドバタイズされた同じプレフィックスを持つプライベート仮想インターフェイス(VIF)が作成されます。
- DX1とDX2のVIFは、us-east-1、eu-west-1、ap-southeast-1リージョンの3つのVGWに関連するDXGWにアタッチされます。
構成図はこちら。顧客環境側はいろいろ省略しています。
1. 明示的なBGP属性の設定を何もしなかった場合
まずはありのまま。
- us-east-1リージョンのAmazon VPCから送信されたトラフィックは、同じリージョンにあるため、DX1に優先されます。
- eu-west-1リージョンのAmazon VPCから送信されたトラフィックは、同じリージョンにあるため、DX2に優先されます。
- ap-southeast-1リージョンはリモートリージョンであるため、Amazon VPCからのトラフィックはDX1とDX2で負荷分散されます。
-
us-east-1
発:
-
eu-west-1
発:
-
ap-southeast-1
発:
…見事にバラけますね。
7224:7300
を広報した場合
2. DX1のVIF上でBGPタグBGPタグ7224:7300
は対向AWS側BGPピアのローカルプレファレンスを操作するためのもので、高中低の3段階のうち「高」の指定になります。
DX1のVIF上でBGPタグ7224:7300をアドバタイズすると、
- us-east-1リージョンのAmazon Virtual Private Cloud(Amazon VPC)からのトラフィックは変わりません。
- eu-west-1リージョンとap-southeast-1リージョンからのトラフィックは、同じリージョンのプリファレンスがBGPコミュニティによって上書きされるため、DX1を優先します。
-
us-east-1
およびap-southeast-1
発:
-
eu-west-1
発:
結果的は同じなんですが、DX2のBGPタグが変わるため一応分けておきました。
3. DX1、DX2両方のVIF上でBGPタグを広報した場合
DX1とDX2のVIF上でBGPタグ7224:7300をアドバタイズすると、異なるリージョンにあるすべてのAmazon VPCからのトラフィックがDX1とDX2でロードバランスされます。
これは、同じリージョンのプリファレンスがBGPコミュニティによって上書きされるためです。
4. DX1、DX2両方でBGPタグ広報 + DX1でAS_PATHをプリペンドした場合
個人的に一番使いそうなパターン。
BGPタグ7224:7300をDX1のASプリペンドで両方のVIFにアドバタイズすると、すべてのリージョンのすべてのAmazon VPCからのトラフィックはDX2を優先します。これは、リージョンのプリファレンスが等しいものとして上書きされるためです。
次に、AWS は AS パス長の検証を行い、DX2 のパスプレフィックスが DX1 より短いことを発見します。
5. DX1のVIF上でAS_PATHをプリペンドした場合
シングルロケーションからの移行時にやらかしそうなパターン。
BGPコミュニティタグなしでDX1のVIF上で1つのASプリペンドのみをアドバタイズする場合、
- us-east-1リージョンとeu-west-1リージョンのAmazon VPCからのトラフィックは変わりません。
- ap-southeast-1リージョンからのトラフィックは DX2 を優先します。
これは、ASパス長よりもリージョンプリファレンスの方が優先順位が高いためです。
-
us-east-1
発:
-
eu-west-1
発:
-
ap-southeast-1
発:
Direct Connectのルーティングポリシー、完全に理解した
Telehouse OS2を冗長構成に組み込む際に参考になりそうなナレッジ記事のシナリオを図に起こしてみました。
意図した経路を通すために、顧客側ルーターからBGPタグを明示的に広報しておくのがよさそうだ…と解釈しています。
実環境に触れる機会があれば試してみたいですね。
Discussion