1. 検証内容
以下のように、address prefixが被っているVPC間をTransit Gatewayで接続した場合、接続元VSI（10.0.0.4)から対象のVSIに疎通できるかどうかを確認してみた。
参考情報（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より長い (Transit GatewayとしてはVPC2への経路を優先) |
有 |
| Case2 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2の方がVPC1より長い (Transit GatewayとしてはVPC2への経路を優先） |
有 |
| Case3 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2の方がVPC1より長い (Transit GatewayとしてはVPC2への経路を優先) |
無（VPC1にsubnetは構成していない） |
| Case4 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2とVPC1は同じ (Transit GatewayとしてはVPC1/VPC2の優先度は同じ) |
無（VPC1にsubnetは構成していない） |
| Case5 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2の方がVPC1より短い (Transit GatewayとしてはVPC1への経路を優先) |
無（VPC1にsubnetは構成していない） |
また、以下のようにVPC1(vpc-tok-syasuda1)からのTransit GatewayへのBGP広告をPrefix Filtering機能を利用してフィルタリングしたケースでも、接続可否を確認してみた。
2. address prefixの重複がある場合の検証結果
まとめると以下のようになった。
| テストケース | 接続元VPCと接続先のVPCが同じ | VPC間で重複するaddress prefix長 | VPC間で重複するsubnetの有無 | 接続可否 |
|---|---|---|---|---|
| Case1 | Yes | VPC2の方がVPC1より長い (Transit GatewayとしてはVPC2への経路を優先するハズ) |
有 | 可能 |
| Case2 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2の方がVPC1より長い (Transit GatewayとしてはVPC2への経路を優先） |
有 | 不可 |
| Case3 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2の方がVPC1より長い (Transit GatewayとしてはVPC2への経路を優先) |
無（VPC1にsubnetは構成していない） | 可能 |
| Case4 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2とVPC1は同じ (Transit GatewayとしてはVPC1/VPC2の優先度は同じ) |
無（VPC1にsubnetは構成していない） | 不可。ただし、Prefix Filteringを構成してVPC1からの経路広告を止めると、接続可能 |
| Case5 | No(接続するにはTransit Gatewayを通る必要あり） | VPC2の方がVPC1より短い (Transit GatewayとしてはVPC1への経路を優先) |
無（VPC1にsubnetは構成していない） | 不可。ただし、Prefix Filteringを構成してVPC1からの経路広告を止めると、接続可能 |
この挙動を利用することで、Transit VPCが構成できる。詳細はIBM Cloud: Transit VPCの構成例にて紹介する。
case1:
接続元VPCの内部に存在するsubnetへの経路が優先される。Prefix filteringあり・なしに関わらず接続可能。
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あり・なしに関わらず接続不可。
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を構成しているかどうかに関わらず接続可能。
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に残ることで）接続可能。
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に残ることで）接続可能。
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
vpc-tok-syasuda2のaddress prefixとsubnet
