IBM Cloud: Transit Gatewayに接続するVPC間で、prefixが重複している際の挙動


# 1. 検証内容
以下のように、address prefixが被っているVPC間をTransit Gatewayで接続した場合、接続元VSI（10.0.0.4)から対象のVSIに疎通できるかどうかを確認してみた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/e6338816-e3b3-b3e6-3a4b-3b992c2b3e38.png)


参考情報（IBM Cloud docsより)
Transit Gatewayには各VPCのaddress prefixがBGPで広告されるが、もし重複があった場合にはaddress prefix長が長い方への経路が優先される。
https://cloud.ibm.com/docs/transit-gateway?topic=transit-gateway-route-reports&interface=ui
>When diagnosing conflicting routes, keep in the mind the following traffic flow considerations:
> - If the advertised prefixes match exactly, or have the same prefix length and AS Path length, the route preferred by the BGP protocol on the IBM Cloud router is non-deterministic and might change over time. Therefore, you might expect to see routes working as expected, and then suddenly not. In a redundant GRE or Direct Link situation, this can be fine, but if you have stateful firewalls, this can be an issue in that the return path to a customer site (or virtual router) can shift if the preferred route changes.
> - **If the prefix lengths of two routes are different (for example, 192.168.0.0/16 and 192.168.0.0/24), the more precise prefix is preferred. In this example, the connection advertising the /24 prefix would be used for all matching IPs.**
> - If routes have the same prefix length, but different AS Paths, then the shorter AS Path is the preferred route. The prefix length takes precedence over the AS Path.


このテストケースは以下のようにまとめられる。

|テストケース  |接続元VPCと接続先のVPCが同じ  |VPC間で重複するaddress prefix長|VPC間で重複するsubnetの有無|
|:---|:---|:---|:---|
|Case1  |Yes   |VPC2の方がVPC1より長い<br>(Transit GatewayとしてはVPC2への経路を優先)|有|
|Case2  |No(接続するにはTransit Gatewayを通る必要あり）  |VPC2の方がVPC1より長い<br>(Transit GatewayとしてはVPC2への経路を優先）|有|
|Case3  |No(接続するにはTransit Gatewayを通る必要あり）  |VPC2の方がVPC1より長い<br>(Transit GatewayとしてはVPC2への経路を優先)|無（VPC1にsubnetは構成していない）|
|Case4  |No(接続するにはTransit Gatewayを通る必要あり） |VPC2とVPC1は同じ<br>(Transit GatewayとしてはVPC1/VPC2の優先度は同じ)|無（VPC1にsubnetは構成していない）|
|Case5  |No(接続するにはTransit Gatewayを通る必要あり）  |VPC2の方がVPC1より短い<br>(Transit GatewayとしてはVPC1への経路を優先)|無（VPC1にsubnetは構成していない）|

また、以下のようにVPC1(vpc-tok-syasuda1)からのTransit GatewayへのBGP広告をPrefix Filtering機能を利用してフィルタリングしたケースでも、接続可否を確認してみた。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/af4110a8-d76a-00d7-2a2e-615c824832df.png)



# 2. address prefixの重複がある場合の検証結果

まとめると以下のようになった。

|テストケース  |接続元VPCと接続先のVPCが同じ  |VPC間で重複するaddress prefix長|VPC間で重複するsubnetの有無|接続可否|
|:---|:---|:---|:---|:---|
|Case1  |Yes   |VPC2の方がVPC1より長い<br>(Transit GatewayとしてはVPC2への経路を優先するハズ)|有|可能|
|Case2  |No(接続するにはTransit Gatewayを通る必要あり）  |VPC2の方がVPC1より長い<br>(Transit GatewayとしてはVPC2への経路を優先）|有|不可|
|Case3  |No(接続するにはTransit Gatewayを通る必要あり）  |VPC2の方がVPC1より長い<br>(Transit GatewayとしてはVPC2への経路を優先)|無（VPC1にsubnetは構成していない）|可能|
|Case4  |No(接続するにはTransit Gatewayを通る必要あり） |VPC2とVPC1は同じ<br>(Transit GatewayとしてはVPC1/VPC2の優先度は同じ)|無（VPC1にsubnetは構成していない）|不可。ただし、Prefix Filteringを構成してVPC1からの経路広告を止めると、接続可能|
|Case5  |No(接続するにはTransit Gatewayを通る必要あり）  |VPC2の方がVPC1より短い<br>(Transit GatewayとしてはVPC1への経路を優先)|無（VPC1にsubnetは構成していない）|不可。ただし、Prefix Filteringを構成してVPC1からの経路広告を止めると、接続可能|


この挙動を利用することで、[Transit VPC](https://cloud.ibm.com/docs/vpc-journey?topic=vpc-journey-vpc-advanced-elements)が構成できる。詳細は[IBM Cloud: Transit VPCの構成例](https://qiita.com/testnin2/items/e343e07cc26bda3939aa)にて紹介する。

## case1: 
接続元VPCの内部に存在するsubnetへの経路が優先される。Prefix filteringあり・なしに関わらず接続可能。

```txt:Case1
[root@new-syasuda-tok1-vpc1 ~]# ping 172.16.0.10
PING 172.16.0.10 (172.16.0.10) 56(84) bytes of data.
64 bytes from 172.16.0.10: icmp_seq=1 ttl=64 time=0.460 ms
64 bytes from 172.16.0.10: icmp_seq=2 ttl=64 time=0.393 ms
64 bytes from 172.16.0.10: icmp_seq=3 ttl=64 time=0.350 ms
64 bytes from 172.16.0.10: icmp_seq=4 ttl=64 time=0.299 ms
```
## case2: 
接続元VPCの内部に存在するsubnetへの経路が優先される。たとえ、VPC2のaddress prefix長の方が長くても、おそらくTransit Gatewayに転送されることなく、接続元VPC内でルーティングされるのだろう。Prefix filteringあり・なしに関わらず接続不可。

```txt:Case2
[root@new-syasuda-tok1-vpc1 ~]# ping 172.16.0.5
PING 172.16.0.5 (172.16.0.5) 56(84) bytes of data.
（無応答）
```

## case3:
- 例えaddress prefixは定義されていても、接続元VPCには接続先対象のsubnetは存在しないので、Transit Gatewayが利用される。
- VPC2の方がAddress prefix長が長いため、Transit GatewayはVPC2への経路を優先する。 VPC1からのBGP広告をフィルタリングするように、Prefix Filteringを構成しているかどうかに関わらず接続可能。

```txt:Case3
[root@new-syasuda-tok1-vpc1 ~]# ping 172.17.0.5
PING 172.17.0.5 (172.17.0.5) 56(84) bytes of data.
64 bytes from 172.17.0.5: icmp_seq=1 ttl=59 time=14.0 ms
64 bytes from 172.17.0.5: icmp_seq=2 ttl=59 time=0.775 ms
64 bytes from 172.17.0.5: icmp_seq=3 ttl=59 time=0.618 ms
64 bytes from 172.17.0.5: icmp_seq=4 ttl=59 time=0.790 ms
64 bytes from 172.17.0.5: icmp_seq=5 ttl=59 time=0.679 ms
```

## case4:

- 例えaddress prefixは定義されていても、接続元VPCには接続先対象のsubnetは存在しないので、Transit Gatewayが利用される。
- VPC1/VPC2のAddress prefix長は同じ。Transit Gatewayは原理的にはVPC1/VPC2の優先度は同じだが、そのままだと接続不可だった。VPC1からのBGP広告をフィルタリングするように、Prefix Filteringを構成すると、（おそらくVPC2への経路のみがTransit Gatewayに残ることで）接続可能。

```txt:Case4:
$ ping 172.18.0.5
（Prefix filteringなしの時。応答なし）

$ ping 172.18.0.5
PING 172.18.0.5 (172.18.0.5) 56(84) bytes of data.
64 bytes from 172.18.0.5: icmp_seq=1 ttl=59 time=0.682 ms
64 bytes from 172.18.0.5: icmp_seq=2 ttl=59 time=0.738 ms
64 bytes from 172.18.0.5: icmp_seq=3 ttl=59 time=0.702 ms
64 bytes from 172.18.0.5: icmp_seq=4 ttl=59 time=0.815 ms
64 bytes from 172.18.0.5: icmp_seq=5 ttl=59 time=0.690 ms
```

## case5:

- 例えaddress prefixは定義されていても、接続元VPCには接続先対象のsubnetは存在しないので、Transit Gatewayが利用される。
- VPC1の方がAddress prefix長が長いため、Transit GatewayはVPC1への経路を優先する。 デフォルトだと接続不可。VPC1からのBGP広告をフィルタリングするように、Prefix Filteringを構成すると、（おそらくVPC2への経路のみがTransit Gatewayに残ることで）接続可能。

```txt:Case5:
$ ping 172.19.0.5
（Prefix filteringなしの時。応答なし）

$ ping 172.19.0.5
PING 172.19.0.5 (172.19.0.5) 56(84) bytes of data.
64 bytes from 172.19.0.5: icmp_seq=1 ttl=59 time=0.633 ms
64 bytes from 172.19.0.5: icmp_seq=2 ttl=59 time=0.640 ms
64 bytes from 172.19.0.5: icmp_seq=3 ttl=59 time=0.790 ms
64 bytes from 172.19.0.5: icmp_seq=4 ttl=59 time=0.685 ms
64 bytes from 172.19.0.5: icmp_seq=5 ttl=59 time=0.745 ms
```


# 参考: 今回テストしたprefixとsubnet情報の画面キャプチャー

## vpc-tok-syasuda1のaddress prefixとsubnet 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/0d4f70a7-f40f-a3f4-556f-caff023c5f27.png)
## vpc-tok-syasuda2のaddress prefixとsubnet 
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/8ad66963-7c73-3357-ad59-9a1c38fe2d44.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/e4c48148-d7b2-4a9a-7fd4-af7606f6d5c0.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/26c58122-27a0-b979-34d0-ff7fe607203a.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/62127/01653482-8e68-9cd0-f583-e0ab3b07b32c.png)