はじめに
だいぶ時間経ってしまっているのですが、、
1年位前アップデート(2020/6/3))があった、AWS DirectConnectでフェイルオーバーテスト機能についてのメモです。
アップデート直後に、たまたまAWS 専用線アクセス体験ラボトレーニングに参加し、AWS DirectConnect環境構築しており、その際にフェイルオーバーテスト機能も試していました。
せっかくなので実際にやってみた記録（とやり方）をまとめておこうと思い、アップデートからだいぶ時間経ってますが一応残しておきます。
なお、実際にやってみたのは2020年06月頃になるので、マネジメントコンソールの画面キャプチャなどはその当時(2020年06月頃)のものになりますので、その点ご承知おきください。
嬉しいこと
これまで、物理的に回復性がある接続を介して BGP セッションを確立できましたが、AWS では設定の回復性をテストするために障害を誘発するツールが提供されていませんでした。
お客様は今後、フェイルオーバーテスト機能を使用することで、自身で指定した時間 BGP セッションをシャットダウンできます。
また、テスト中、テスト前の設定に戻すために、いつでもフェイルオーバーテストをキャンセルすることもできます。
今までは、AWS Direct Connect環境の回線冗長化を確認したい場合、
CGW(BGPルータ)側で障害を発生させることでしか確認ができませんでしたが
フェイルオーバーテスト機能によって、AWS側の障害起因での切り替え試験を再現できるようになりました。
これによって、本当に耐障害性のあるネットワークとして構成できているかを、
実環境でテストにて確認することが可能になりました。
やってみた
全体環境イメージ
今回の検証環境イメージは以下の通りです。（後述しますが、冗長構成も試しています。）
この状態でフェイルオーバーテストを実施してみました。
仮想オンプレ環境はハンズオン用ラボ環境としてAWSから貸し出されたものを使用してます。
実施方法
-
[Services]-[Networking & Content Delivery]-[Direct Connect]をクリックします。
[仮想 Interfaces]を開き、対象の仮想 Interfacesを選択します。
今回は「selfdxlab-csr-4」を選択します。
-
[アクション] -[フェイルオーバーテスト]を選択します。
-
障害テストの開始画面にて、必要項目を入力してテストを開始します。(設定可能な時間は1~180分)
今回は[テストの最大時間]を1分に設定します。
-
正常にテストが開始されると、「BGP 障害テストが正常に開始されました」と表示されます。
-
テスト開始後疎通可能になるまで、以下のように遷移します。
[testing]→[down]→[avalilable]
BGP停止時に設定した[テストの最大時間]（今回は1分）が経過すると、BGPセッションが回復します。
-
テストを実行した仮想インターフェイスの画面からテスト履歴を確認できます。
履歴画面では[テスト開始時刻]、[テスト終了時刻]、[テストステータス]が確認できます。
※先程テストを実行した履歴のステータスはcompleteになっていることが確認できます。
実検証結果
実際にフェイルオーバーテストをやって、どの程度通信断となるのか（設定したテスト時間通りか?）シングル構成で確認してみました。
また冗長構成でもテストを実施してみて、通信断にならないかどうか確認してみました。
全体構成（シングル構成）
- [テスト最大時間：1分] シングル構成
- pingダウン時間：約100秒 ※設定時間(1分)よりちょっと長い。。
aws@ubuntu:~$ ping 172.16.0.100
PING 172.16.0.100 (172.16.0.100) 56(84) bytes of data.
64 bytes from 172.16.0.100: icmp_seq=1 ttl=243 time=5.08 ms
～省略～
64 bytes from 172.16.0.100: icmp_seq=9 ttl=243 time=3.63 ms
From 172.16.0.100 icmp_seq=10 Destination Host Unreachable
～省略～
From 172.16.0.100 icmp_seq=106 Destination Host Unreachable
64 bytes from 172.16.0.100: icmp_seq=107 ttl=243 time=3.67 ms
64 bytes from 172.16.0.100: icmp_seq=108 ttl=243 time=3.49 ms
$ show log
*Jun 17 15:33:54.294: %BGP-5-ADJCHANGE: neighbor 169.254.100.5 Down BGP Notification received
～省略～
*Jun 17 15:35:31.088: %BGP-5-ADJCHANGE: neighbor 169.254.100.5 Up
★正常時
$ show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 172.16.0.0 169.254.100.5 100 0 64512 i
★フェイルオーバーテスト実施時
$ show ip bgp
Network Next Hop Metric LocPrf Weight Path
（何も出力されない）
全体構成（冗長構成）
- Juniper（VSR)と、Cisco（CSR)で冗長化しています。
- 経路冗長の仕組みは、WAN側：eBGPのLocalPreferenceとAS PATHで行き戻りの経路制御、LAN側：iBGPです。
- [テスト最大時間：1分] 冗長構成
- pingダウン時間：断なし
aws@ubuntu:~$ ping 18 72.16.0.100
PING 172.16.0.100 (172.16.0.100) 56(84) bytes of data.
64 bytes from 172.16.0.100: icmp_seq=1 ttl=243 time=5.91 ms
64 bytes from 172.16.0.100: icmp_seq=2 ttl=243 time=9.59 ms
～省略～
64 bytes from 172.16.0.100: icmp_seq=91 ttl=243 time=7.98 ms
64 bytes from 172.16.0.100: icmp_seq=92 ttl=243 time=7.41 ms
From 172.16.0.100: icmp_seq=93 Redirect Host(New nexthop: 172.16.0.100)
64 bytes from 172.16.0.100: icmp_seq=93 ttl=243 time=9.05 ms
64 bytes from 172.16.0.100: icmp_seq=94 ttl=243 time=4.86 ms
*Jun 17 15:33:54.294: %BGP-5-ADJCHANGE: neighbor 169.254.100.5 Down BGP Notification received
～省略～
*Jun 17 15:35:31.088: %BGP-5-ADJCHANGE: neighbor 169.254.100.5 Up
★正常時
aws@vsrx> show route 172.16.0.0
inet.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/16 *[BGP/170] 00:00:01, localpref 200
AS path: 64512 I
> to 169.254.100.1 via ge-0/0/0.0
★フェイルオーバーテスト実施時（NextHopがCSRに向く）
aws@vsrx> show route 172.16.0.0
inet.0: 11 destinations, 12 routes (11 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.0/16 *[BGP/170] 08:16:00, MED 0, localpref 100, from 10.0.0.254
AS path: 64512 I
> to 192.168.10.30 via ge-0/0/1.0
最後に
NW環境としての冗長性をよりきちんと確認出来るので、
オンプレとクラウドのハイブリッド環境を構築する上では、とても有益な機能だと思いました。
断時間が想定より長かった理由は分かりませんでしたが。。
実際にやってみてどう動くかまで、CGW(BGPルータ)側の挙動含めて確認できたのはよかったです。