Transit Gateway ConnectとCisco Catalyst8000VでBGP over GREを動かす

# はじめに
Transit Gateway Connectのリリースにより、Transit Gatewayと仮想ルータ間で直接GREトンネルを形成することが可能になりました。GREトンネル内でBGPを動作させることで、経路が冗長化されたダイナミックルーティングプロトコルドメインをオンプレミスからTransit Gatewayまで拡張することができ、ネットワークエンジニアにとってシンプルなネットワーク設計が実現できます。

[Simplify SD-WAN connectivity with AWS Transit Gateway Connect](https://aws.amazon.com/jp/blogs/networking-and-content-delivery/simplify-sd-wan-connectivity-with-aws-transit-gateway-connect/)
# Transit Gateway Connectを形成する要素
Transit Gateway Connectは、従来のTransit Gatewayにはない新しい要素を含むコンポーネントで形成されています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/cf71b775-6fa2-4231-e289-01432b0bc1ec.png)

#### Connect attachment
VPC上の仮想ルータがTransit Gatewayに接続するためのアタッチメントです。

#### トランスポートアタッチメント
作成済みのTransit Gatewayのアタッチメントを指します。（VPCまたはAWS Direct Connectアタッチメント）Connectアタッチメントを作成する際に、通信したいVPCのアタッチメントをトランスポートアタッチメントとして指定します。

#### Transit Gateway Connectピア
Transit Gateway Connectと接続するVPC上の仮想ルータ（GREトンネルおよびBGPピア）を指します。
# Transit Gateway Connectの注意ポイントまとめ
・Connect attachmentは既存のTransit Gateway上に作成することが可能です。
・Connectピアがオンプレミスにある場合はAWS Direct Connect 経由での接続が必要です。
・Connect attachment は静的ルートをサポートしません。
・BGPは、Transit Gateway Connectの最小要件です。
・Transit Gateway Connectは、GREトンネルごとに最大5 Gbpsの帯域幅をサポートします。5Gbpsを超える帯域幅は、同じConnectアタッチメントに対して複数のConnectピアで同じプレフィックスをBGPでアドバタイズすることで実現されます。
・各Connectアタッチメントに対して最大4つのConnectピアがサポートされます。
・eBGPのマルチホップを使用する必要があります。
・Transit GatewayのGRE用IPアドレスはICMPに応答しません。
・AWSは1つのTGW Connectにつき、2つのGREトンネル（＝BGPピア）を張ることを推奨しています。
・Transit Gateway Connect経由で仮想ルータから学習したBGP経路情報は、AS-PATH、MED、LOCAL_PREFERENCE、ORIGINのアトリビュートが同じ値になっている場合、ECMPとなる。
それ以外の場合は最も優先される経路情報が選択されるが、BGPベストパス選択基準に関するドキュメントは2022/12時点で公開されていない。
（参考：AWSサポートの回答）Transit Gateway Connectアタッチメントのベストパス選択基準につきましては公開情報はございませんでしたが、BGPでは同じプレフィックスのルートを受信した場合、BGP IDといった情報で経路選択を行いますため、BGPの経路選択に従ってベストパスを選択しているものと考えております。
・Transit Gateway Connectピア作成時に設定が必要なBGP内部CIDR（GREトンネルのネットワークアドレス）はAWSの制約で169.254.0.0/16の範囲内で、/29のブロックしか使用できません。さらにその中で169.254.6.0/29なら169.254.6.1～169.254.6.6までしか使用できないので注意しましょう。
[Connectピア](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-connect.html#tgw-connect-peer)
[Transit Gateway ConnectアタッチメントとTransit Gateway Connectピア](https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-connect.html)
# Transit Gateway Connectのクォータ
Transit Gateway Connectに関するクォータについても確認し、実現したいクラウドネットワークに対し制約が無いか予めチェックしておきましょう。
[Transit Gatewayのクォータ](https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/transit-gateway-quotas.html)
# 検証環境
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/ac344dfe-3a0c-4b8d-dcca-9a9867b65623.png)
・実際にTransit Gateway Connectを試すために、AWS上で仮想ルータ（Cisco Catalyst8000V）をHA構成でデプロイしてみました。Transit Gateway Connectのメリットの一つとして、オンプレミスのダイナミックルーティングドメインをTransit Gatewayまで拡張しネットワークエンジニアによる設計ができる点があると考えています。そのため疑似オンプレミスとしてのVPCを用意し、そこでも仮想ルータをデプロイし、EIGRP～BGP間での再配送を行う設計を想定した環境を用意しました。

# シナリオ
VPC１とVPC２の仮想ルータ間をIPsec VPNで接続する
　↓
VPC１とVPC２の仮想ルータ間でEIGRPを動作させ、各仮想ルータがVPC１とVPC２の経路を学習していることを確認する
　↓
VPC２とVPC３間のTransit Gatewayルートテーブルを設定する
　↓
VPC２とVPC３間のTransit GatewayでTransit Gateway Connectを作成する
　↓
VPC２の仮想ルータとTransit Gateway Connect間でBGP over GREを動作させ、EIGRPと相互に再配布する
　↓
VPC１の仮想ルータがVPC３の経路を学習していることを確認する
　↓
VPC１～VPC３間でPingやTracerouteが可能となっていることを確認する
　↓
VPC２の仮想ルータ１側の経路上で障害が発生した場合、仮想ルータ２側に切り替わり通信が復旧することを確認する

# 各仮想ルータのConfiguration
#### VPC１仮想ルータ
```
crypto isakmp policy 1
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key ipseckey address 10.1XX.1.100
crypto isakmp key ipseckey address 10.1XX.2.100

crypto ipsec transform-set tset-cmn esp-aes 256 esp-sha256-hmac
 mode tunnel

crypto ipsec profile prof
 set transform-set tset-cmn

interface Tunnel11
 ip address 10.200.1.1 255.255.255.0
 tunnel source GigabitEthernet2
 tunnel mode ipsec ipv4
 tunnel destination 10.1XX.1.100
 tunnel protection ipsec profile prof

interface Tunnel12
 ip address 10.200.2.1 255.255.255.0
 tunnel source GigabitEthernet2
 tunnel mode ipsec ipv4
 tunnel destination 10.1XX.2.100
 tunnel protection ipsec profile prof

ip prefix-list plist seq 5 permit 10.XX.1.0/24

router eigrp 1
 distribute-list prefix plist out Tunnel11
 distribute-list prefix plist out Tunnel12
 network 10.XX.1.0 0.0.0.255
 network 10.200.1.0 0.0.0.255
 network 10.200.2.0 0.0.0.255
```

#### VPC2仮想ルータ１
```
crypto isakmp policy 1
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key ipseckey address 10.XX.2.100

crypto ipsec transform-set tset-cmn esp-aes 256 esp-sha256-hmac
 mode tunnel

crypto ipsec profile prof
 set transform-set tset-cmn

interface Tunnel11
 ip address 10.200.1.2 255.255.255.0
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 10.XX.2.100
 tunnel protection ipsec profile prof

interface Tunnel13
 ip address 10.200.10.1 255.255.255.0
 tunnel source GigabitEthernet1
 tunnel destination 10.1XX.2.100

ip route 10.1XX.2.0 255.255.255.0 10.1XX.1.1

router eigrp 1
 network 10.200.1.0 0.0.0.255
 network 10.200.10.0 0.0.0.255

interface Tunnel1
 ip address 169.254.1XX.1 255.255.255.248
 tunnel source GigabitEthernet2
 tunnel destination 192.168.1.XX

ip route 192.168.1.0 255.255.255.0 10.1XX.3.1

ip prefix-list plist1 permit 10.XX.1.0/24
ip prefix-list plist2 permit 10.2XX.0.0/16

route-map eigtobgp
 match ip address prefix-list plist1

route-map bgpin
 match ip address prefix-list plist2

router bgp 65001
 timer bgp 10 30
 neighbor 10.1XX.2.100 remote-as 65001
 neighbor 169.254.1XX.2 remote-as 64512
 neighbor 169.254.1XX.2 ebgp-multihop
 neighbor 169.254.1XX.2 route-map bgpin in
 redistribute eigrp 1 metric 10000 route-map eigtobgp

router eigrp 1
 redistribute bgp 65001 metric 10000 1 255 1 1500
```
#### VPC2仮想ルータ2 （10.1XX.2.100）
```
crypto isakmp policy 1
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
crypto isakmp key ipseckey address 10.XX.2.100

crypto ipsec transform-set tset-cmn esp-aes 256 esp-sha256-hmac
 mode tunnel

crypto ipsec profile prof
 set transform-set tset-cmn

interface Tunnel11
 ip address 10.200.2.2 255.255.255.0
 tunnel source GigabitEthernet1
 tunnel mode ipsec ipv4
 tunnel destination 10.XX.2.100
 tunnel protection ipsec profile prof

interface Tunnel13
 ip address 10.200.10.2 255.255.255.0
 tunnel source GigabitEthernet1
 tunnel destination 10.1XX.1.100

ip route 10.1XX.1.0 255.255.255.0 10.1XX.2.1

router eigrp 1
 network 10.200.2.0 0.0.0.255
 network 10.200.10.0 0.0.0.255

interface Tunnel1
 ip address 169.254.2XX.1 255.255.255.248
 tunnel source GigabitEthernet2
 tunnel destination 192.168.1.1XX

ip route 192.168.1.0 255.255.255.0 10.1XX.4.1

ip prefix-list plist1 permit 10.XX.1.0/24
ip prefix-list plist2 permit 10.2XX.0.0/16

route-map eigtobgp
 match ip address prefix-list plist1

route-map bgpin
 match ip address prefix-list plist2

route-map bgpout
 match ip address prefix-list plist1
 set as-path prepend 65001

router bgp 65001
 timer bgp 10 30
 neighbor 10.1XX.1.100 remote-as 65001
 neighbor 169.254.2XX.2 remote-as 64512
 neighbor 169.254.2XX.2 ebgp-multihop
 neighbor 169.254.2XX.2 route-map bgpin in
 neighbor 169.254.2XX.2 route-map bgpout out
 redistribute eigrp 1 metric 10000 route-map eigtobgp

router eigrp 1
 redistribute bgp 65001 metric 10000 1 255 1 1500
 offset-list 1 out 1000000 Tunnel11
```
# Transit Gateway Connectの構築
Transit Gateway Connectアタッチメントを作成します。
「Transit Gatewayアタッチメント」⇒「Transit Gatewayアタッチメントを作成」をクリックし、以下の通り設定します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/940e86ad-ee97-2ade-092e-bcd7dae821ba.png)
先ほど作成したTransit Gateway Connectアタッチメントを選択し、「Connectピア」タブを選択し、「Connectピアを作成」をクリックします。
「Connectピアを作成」画面で以下の通り設定します。（同じ手順で２つ作成する）
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/b48c7c56-80a9-d7bc-5a3c-288478482a5b.png)
先ほど作成したTransit Gateway Connectアタッチメントを選択し、「Connectピア」を選択し、2つのConnectピアの状態が「Pending」から「Available」になっていることを確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/f637d476-2447-fe43-edc9-176497cb19d7.png)
予め作成しておいたVPC2とVPC3用のTransit Gatewayルートテーブルを選択し、「関連付け」タブを選択し、「関連付けを作成」をクリックします。
「関連付けを作成」画面で先ほど作成したTransit Gateway Connectアタッチメントを選択し、「関連付けを作成」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/328b8e89-7e85-be2f-d52d-243b37aac709.png)
Transit Gatewayルートテーブルに先ほど作成したTransit Gateway Connectアタッチメントからのルートが伝搬されるように設定します。
Transit Gatewayルートテーブルを選択し、「伝搬」タブを選択し、「伝播を作成」をクリックします。
「伝達を作成」画面で先ほど作成したTransit Gateway Connectアタッチメントを選択し、「伝達を作成」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/43f50529-e431-15ce-9770-a7f9b9140514.png)

# Transit Gateway Connectと仮想ルータ間のBGP over GRE
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/444eee72-0738-b172-e798-9a7ca5cab4c3.png)
Transit Gateway Connectと仮想ルータ間のBGP over GREについて論理構成のイメージを起こしてみました。各VPC上のルートテーブルやTransit GatewayルートテーブルにおいてはOverlayを構築するための土台となる適切なルートエントリを設定する必要があります。

仮想ルータとTransit Gateway Connectで適切なBGP over GREが設定できたらお互いのルートがBGPで学習できていることを確認します。
#### Transit Gateway Connectが学習したルート情報
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/5a835ffc-6333-b7fe-4470-bb5fd158afcb.png)
先ほど作成したTransit Gateway Connectアタッチメントを選択し、「Connectピア」を選択し、2つのConnectピアの状態が「Pending」から「Available」になっていることを確認します。


#### 仮想ルータ上のルーティングテーブル
VPC２仮想ルータ１ ではTransit Gateway ConnectからBGPでVPC3のCIDRが学習できています。
```
show ip route

  10.0.0.0/8 is variably subnetted, 13 subnets, 3 masks
S        10.XX.0.0/16 [1/0] via 10.1XX.1.1
D        10.XX.1.0/24 [90/26880256] via 10.200.1.1, 00:07:06, Tunnel11
C        10.1XX.1.0/24 is directly connected, GigabitEthernet1
L        10.1XX.1.100/32 is directly connected, GigabitEthernet1
S        10.1XX.2.0/24 [1/0] via 10.1XX.1.1
-snip-
D        10.200.2.0/24 [90/28160000] via 10.200.10.2, 03:57:45, Tunnel13
C        10.200.10.0/24 is directly connected, Tunnel13
L        10.200.10.1/32 is directly connected, Tunnel13
B        10.2XX.0.0/16 [20/100] via 169.254.1XX.2, 00:05:50
      169.254.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        169.254.1XX.0/29 is directly connected, Tunnel1
L        169.254.1XX.1/32 is directly connected, Tunnel1
S     192.168.1.0/24 [1/0] via 10.1XX.3.1
```
VPC２仮想ルータ２でもTransit Gateway ConnectからBGPでVPC3のCIDRが学習できています。
```
show ip route

  10.0.0.0/8 is variably subnetted, 13 subnets, 3 masks
S        10.XX.0.0/16 [1/0] via 10.1XX.2.1
D        10.XX.1.0/24 [90/26880256] via 10.200.2.1, 00:05:59, Tunnel11
S        10.1XX.1.0/24 [1/0] via 10.1XX.2.1
-snip-
D        10.200.1.0/24 [90/28160000] via 10.200.10.1, 00:06:02, Tunnel13
C        10.200.2.0/24 is directly connected, Tunnel11
L        10.200.2.2/32 is directly connected, Tunnel11
C        10.200.10.0/24 is directly connected, Tunnel13
L        10.200.10.2/32 is directly connected, Tunnel13
B        10.2XX.0.0/16 [20/100] via 169.254.2XX.2, 00:25:06
      169.254.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        169.254.2XX.0/29 is directly connected, Tunnel1
L        169.254.2XX.1/32 is directly connected, Tunnel1
S     192.168.1.0/24 [1/0] via 10.1XX.4.1
```
VPC１仮想ルータではEIGRPに再配送されたVPC3のCIDRが学習できています。
```
show ip route

 10.0.0.0/8 is variably subnetted, 12 subnets, 3 masks
C        10.XX.1.0/24 is directly connected, GigabitEthernet1
L        10.XX.1.100/32 is directly connected, GigabitEthernet1
C        10.XX.2.0/24 is directly connected, GigabitEthernet2
L        10.XX.2.100/32 is directly connected, GigabitEthernet2
S        10.1XX.0.0/16 [1/0] via 10.XX.2.1
C        10.200.1.0/24 is directly connected, Tunnel11
L        10.200.1.1/32 is directly connected, Tunnel11
C        10.200.2.0/24 is directly connected, Tunnel12
L        10.200.2.1/32 is directly connected, Tunnel12
D        10.200.10.0/24 [90/28160000] via 10.200.1.2, 00:05:08, Tunnel11
D EX     10.2XX.0.0/16 [170/26880256] via 10.200.1.2, 00:03:52, Tunnel11
```

# 疎通確認
VPC1のEC2インスタンスから、VPC3のEC2インスタンスへPingとTracerouteによる疎通確認を行います。
```
sh-5.2$ ping 10.2XX.1.200
PING 10.2XX.1.200 (10.2XX.1.200) 56(84) bytes of data.
64 bytes from 10.2XX.1.200: icmp_seq=2 ttl=124 time=5.02 ms
64 bytes from 10.2XX.1.200: icmp_seq=3 ttl=124 time=2.96 ms
^C
--- 10.2XX.1.200 ping statistics ---
3 packets transmitted, 2 received, 33.3333% packet loss, time 2058ms
rtt min/avg/max/mdev = 2.963/3.993/5.024/1.030 ms
sh-5.2$
sh-5.2$ traceroute 10.2XX.1.200
traceroute to 10.2XX.1.200 (10.2XX.1.200), 30 hops max, 60 byte packets
 1  ip-10-XX-1-100.ap-northeast-1.compute.internal (10.XX.1.100)  18.435 ms  18.391 ms  18.368 ms
 2  ip-10-200-1-2.ap-northeast-1.compute.internal (10.200.1.2)  29.574 ms  29.548 ms  29.535 ms
 3  * * *
 4  ip-10-2XX-1-200.ap-northeast-1.compute.internal (10.2XX.1.200)  29.353 ms  29.455 ms  29.442 ms
```
想定通りVPC2の仮想ルータ1を経由して疎通が可能となっています。
# 障害試験
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/282cef1c-0bba-5168-cd0e-f8cae18d9fad.png)
仮想ルータがTransit Gateway ConnectとのBGP over GREによるHA構成で動作していることを確認します。VPC2の仮想ルータ1として稼働しているEC2インスタンスを停止し、VPC1のEC2インスタンスから、VPC3のEC2インスタンスへPingとTracerouteによる疎通確認を行います。
```
sh-5.2$ ping 10.2XX.1.200
PING 10.2XX.1.200 (10.2XX.1.200) 56(84) bytes of data.
64 bytes from 10.2XX.1.200: icmp_seq=43 ttl=124 time=5.12 ms
64 bytes from 10.2XX.1.200: icmp_seq=44 ttl=124 time=4.55 ms
64 bytes from 10.2XX.1.200: icmp_seq=45 ttl=124 time=4.51 ms
^C
--- 10.2XX.1.200 ping statistics ---
45 packets transmitted, 3 received, 93.3333% packet loss, time 45694ms
rtt min/avg/max/mdev = 4.511/4.724/5.116/0.277 ms
sh-5.2$ traceroute 10.2XX.1.200
traceroute to 10.2XX.1.200 (10.2XX.1.200), 30 hops max, 60 byte packets
 1  ip-10-XX-1-100.ap-northeast-1.compute.internal (10.XX.1.100)  0.335 ms  0.313 ms  0.326 ms
 2  ip-10-200-2-2.ap-northeast-1.compute.internal (10.200.2.2)  14.217 ms  14.213 ms  14.206 ms
 3  * * *
 4  ip-10-2XX-1-200.ap-northeast-1.compute.internal (10.2XX.1.200)  14.120 ms  14.118 ms  14.216 ms
```
想定通りVPC2の仮想ルータ2の経路に切り替わり疎通が可能となっています。
Transit Gateway Connect上のBGPピア1がDownし、ルートも仮想ルータ2に向いていることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3731465/e050a415-08de-c5b9-1a6d-e4c3cda1531e.png)

# まとめ
Transit Gateway ConnectとCisco Catalyst8000VでBGP over GREを動作させ、想定通りの挙動となることを確認しました。今回の仮想ルータのコンフィグレーションはあくまで検証用の簡易的なものであるため、より実践的なルーティング設計は丁寧に行う必要があることに注意してください。