【AWS】Direct Connect フェイルオーバーテスト機能使ってみた

# はじめに
だいぶ時間経ってしまっているのですが、、
1年位前[アップデート(2020/6/3)](https://aws.amazon.com/jp/about-aws/whats-new/2020/06/aws-direct-connect-enables-failover-testing/))があった、AWS DirectConnectでフェイルオーバーテスト機能についてのメモです。

アップデート直後に、たまたま[AWS 専用線アクセス体験ラボトレーニング](https://aws.amazon.com/jp/dx_labo/)に参加し、AWS DirectConnect環境構築しており、その際にフェイルオーバーテスト機能も試していました。
せっかくなので実際にやってみた記録（とやり方）をまとめておこうと思い、アップデートからだいぶ時間経ってますが一応残しておきます。

なお、実際にやってみたのは2020年06月頃になるので、マネジメントコンソールの画面キャプチャなどはその当時(2020年06月頃)のものになりますので、その点ご承知おきください。

# 嬉しいこと
>これまで、物理的に回復性がある接続を介して BGP セッションを確立できましたが、AWS では設定の回復性をテストするために障害を誘発するツールが提供されていませんでした。
お客様は今後、フェイルオーバーテスト機能を使用することで、自身で指定した時間 BGP セッションをシャットダウンできます。
また、テスト中、テスト前の設定に戻すために、いつでもフェイルオーバーテストをキャンセルすることもできます。

https://aws.amazon.com/jp/about-aws/whats-new/2020/06/aws-direct-connect-enables-failover-testing/

今までは、AWS Direct Connect環境の回線冗長化を確認したい場合、
CGW(BGPルータ)側で障害を発生させることでしか確認ができませんでしたが
フェイルオーバーテスト機能によって、AWS側の障害起因での切り替え試験を再現できるようになりました。
これによって、本当に耐障害性のあるネットワークとして構成できているかを、
実環境でテストにて確認することが可能になりました。



# やってみた
## 全体環境イメージ
今回の検証環境イメージは以下の通りです。（後述しますが、冗長構成も試しています。）
この状態でフェイルオーバーテストを実施してみました。
仮想オンプレ環境はハンズオン用ラボ環境としてAWSから貸し出されたものを使用してます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/bffb83cf-20b5-b22e-7585-fce387756b1e.png)

## 実施方法
1. [Services]-[Networking & Content Delivery]-[Direct Connect]をクリックします。
[仮想 Interfaces]を開き、対象の仮想 Interfacesを選択します。
今回は「selfdxlab-csr-4」を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/6d0ef290-975e-d327-76b1-b5aa5f89e7c4.png)

2. [アクション]　-[フェイルオーバーテスト]を選択します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/810d30ed-40b5-1998-59dd-467648da177a.png)

3. 障害テストの開始画面にて、必要項目を入力してテストを開始します。(設定可能な時間は1~180分)
  今回は[テストの最大時間]を1分に設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/a7b76c62-3f18-a74b-3690-057587754b80.png)

4. 正常にテストが開始されると、「BGP 障害テストが正常に開始されました」と表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/3bdcc4dd-416d-b25a-c0ef-8fc330459de8.png)

5. テスト開始後疎通可能になるまで、以下のように遷移します。
**[testing]→[down]→[avalilable]**
BGP停止時に設定した[テストの最大時間]（今回は1分）が経過すると、BGPセッションが回復します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/b64125c4-f18c-4139-c593-a0e6845df271.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/36ca30f3-c39f-4fe2-1139-c09d168b8e90.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/78c122e8-3ad4-b492-4e01-bd6d74eca147.png)

6. テストを実行した仮想インターフェイスの画面からテスト履歴を確認できます。
履歴画面では[テスト開始時刻]、[テスト終了時刻]、[テストステータス]が確認できます。
※先程テストを実行した履歴のステータスはcompleteになっていることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/6d4a220b-a70c-ebba-8e12-9f4ff4a182a0.png)


## 実検証結果
実際にフェイルオーバーテストをやって、どの程度通信断となるのか（設定したテスト時間通りか?）シングル構成で確認してみました。
また冗長構成でもテストを実施してみて、通信断にならないかどうか確認してみました。


### 全体構成（シングル構成）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/c3d37963-a913-956c-53df-e0d97733a7a8.png)

###
- [テスト最大時間：1分] シングル構成
- pingダウン時間：**約100秒**　※設定時間(1分)よりちょっと長い。。

```shell:ubuntu→Trainingサーバping結果
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
```

```Cisco:BGPセッション停止～回復【CSR出力ログ】
$ 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
```

```Cisco:BGPセッション停止～回復【CSRルーティング情報】
★正常時
$ 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です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/fef5f500-0635-d9c0-60e9-bca2cc92e040.png)

- [テスト最大時間：1分] 冗長構成
- pingダウン時間：**断なし**

```shell:ubuntu→Trainingサーバ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
```

```JunOS:BGPセッション停止～状態遷移【VSR出力ログ】
*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![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/955507/2647a1c3-1be4-e2f5-ffde-9b88ed83b456.png)
```

```JunOS:BGPセッション停止～状態遷移【VSRルーティング情報】
★正常時
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ルータ)側の挙動含めて確認できたのはよかったです。


# 参考にさせていただいた記事：
* [AWS Direct Connect のフェイルオーバーテストをやってみた(DevelopersIO)](https://dev.classmethod.jp/articles/aws-direct-connect-enables-failover-testing-do/)