IBM Cloud: VPC Custom Routesを利用したAZまたぎのHA環境の構成例(VPC外部からのアクセス）: ingress routeのadvertise

1. はじめに

3年以上前にIBM Cloud: VPC Custom Routesを利用したAZまたぎのHA環境の構成例(VPC外部からのアクセス）という記事を書いたことがあるが、最近これを改善するIngress routeの新機能が出てきたので、再度検証したのがこの記事である。

2. 前回の構成

前回の記事では、

1. Direct LinkやTransit GatewayのようなVPC外部からの経路については、Ingress Route tableを使う必要がある。(前回利用していたのはEgress Route tableで、VPC内のsubnetをsourceとする経路制御）
2. 192.168.10.10というVPC内で定義されていないアドレスに対して、そのままではVPC外部からは到達できない（勝手に指定したアドレスが対向側に経路広告されることはない）。そのため、例えば192.168.10.0/28というダミーのAddress Prefixを定義しておく必要があった。IBM CloudのVPCはPrefix単位で経路広告されるため、必ずしもsubnetを作っておく必要はない。

という制約があったため、以下のようにTokyo1での障害発生時にはTokyo1からAddress Prefixを削除し、Tokyo2にAddress Prefixを作成するという構成をとっていた。

• Server-A正常時(192.168.10.10宛のアクセスは10.0.0.7に転送）。192.168.10.10を含むAddress PrefixはTokyo1側にある。
  

• Server-A障害時(192.168.10.10宛のアクセスは10.1.0.7に転送）。Tokyo2側にAddress Prefixを再作成。
  

しかし、上記2の制約が非常に取り扱いに面倒であった。そもそもこういう風にダミーのAddress prefix（海外ではMagic Address Prefixと呼ばれていることもある）には以下のような問題点がある。

• ダミーのAddress prefixは、構成上の意図が伝わりにくい（VSIに割り当てても良いsubnet帯であると誤解されないようにしておく必要がある）
• Address prefixの制限が大きい
  • 192.168.10.10を経路広告するだけで良いのに、Address Prefixは(/28が最小）なので、192.168.10.0/28でAddress prefixを定義する必要がある。
  • Address prefixの作成可能な数には上限がある。VPCあたり25まで。
  • 0.0.0.0/0を作成して経路広告することはできない。(Address prefixで最大の長さは/9だし、そもそも既存のAddress prefixと重複が発生してしまう）
  • AZ間でaddress prefixの重複はできないから、全てのAZから同じsubnet rangeで経路広告しておくことはできない。

3. Ingress routeの新機能での構成

Ingress routeの新機能では、ingress routeに対して経路広告を可能とするroute advertisementが実装されており、ingress routeで定義したDestination宛への経路をDirect LinkやTransit Gatewayを通して対向環境にBGPで経路広告する機能が提供された。ingress custom routeを作成するだけで対向環境に経路広告できるので、ダミーのaddress prefixを作成する必要もなく、取り扱いがシンプルになる。しかも前項の問題を解決してくれる。

[パターン1: 優先度(Priority)で制御する方法]

[パターン2: 経路広告をする・しないで制御する方法]

4. 設定方法（事前準備）

4-1. Server-A/Server-Bに192.168.10.10を付与

前回実施している場合は不要。

4-2. IP spoofingの有効化

前回実施している場合は不要。

4-3. Security Group/Network ACLでDirect Link/Transit Gatewayの対向側からの通信を許可する。

（省略）

4-4. Direct Link/Transit Gatewayの対向側で192.168.10.10/32宛のstatic routeを設定する

前回は192.168.10.0/28で設定していたが、今回は192.168.10.10/32で良い。
具体的な手順は省略。

5. パターン1: 優先度(Priority)で制御する方法

5-1. Ingress Custom Route(Ingress)の作成

• 経路広告を有効にするには、「Direct LinkやTransit Gatewayに経路広告を行うかどうか」というGlobal設定と、「各経路ごとの設定」の、２箇所での構成が必要になる。
• tokyo1/tokyo2への経路を作成しておき、普段はtokyo1/tokyo2の両方から経路広告しておく。ただしtokyo1の優先度の方が高くなるようにtokyo2の優先度を3に下げておく。切替時には、tokyo2からの経路広告の優先度を3から2に変更する。
• 切替のための設定が１箇所で済み、CLIでもibmcloud is vpc-routing-table-routeで優先度を確認できるので、パターン2より使いやすいと思われる。（各経路が経路広告されているかどうかは、ibmcloud is vpc-routing-table-routeではわからず、ibmcloud is vpc-routing-table-routeも併用しないと分からないため、CLIでの実装上でもパターン2は若干使い勝手が悪い）。
  

5-2. Server-Aへの接続テスト

• 今回はDirect Link Connect 2.0経由でAIX端末からテストを行った。
• Direct Linkの経路広告情報を見ると、以下のように192.168.10.10/32だけが経路広告されている（どちらのAZからの経路広告なのかは読み取れない。また、二つ経路が現れてどちらかの優先度が高い・・・みたいな表示になる訳でもない）。
  

AIX(Client）

bash-4.3# ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10): 56 data bytes
64 bytes from 192.168.10.10: icmp_seq=0 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=1 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=4 ttl=54 time=1 ms

Server-A

[root@server-a ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
22:03:27.385619 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 280, seq 0, length 64
22:03:27.385667 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 280, seq 0, length 64
22:03:28.385549 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 280, seq 1, length 64
22:03:28.385575 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 280, seq 1, length 64
22:03:29.385451 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 280, seq 2, length 64
22:03:29.385499 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 280, seq 2, length 64
22:03:30.385614 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 280, seq 3, length 64
22:03:30.385661 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 280, seq 3, length 64
22:03:31.385563 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 280, seq 4, length 64
22:03:31.385586 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 280, seq 4, length 64

Server-B

[root@server-b ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
（出力なし）

5-3. Server-A障害時のアクセス（Server-Bへの切り替えテスト）

• Custom Routeにて、tokyo2からの経路広告の優先度を3から1に変更する(UIで変更しても良いし、以下のようにCLIで変更しても良い）。

$ ibmcloud is vpc-routing-table-route-update vpc-tok-syasuda1 ingress-route dbserver2-tokyo2 --priority 1
Update route dbserver2-tokyo2 for routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID            r022-aeb1c366-f112-4f7a-a072-5ed9af1f2465
Name          dbserver2-tokyo2
Action        deliver
Status        stable
Destination   192.168.10.10/32
Priority      1
Origin        user
Next hop      10.1.0.7
Advertise     true
Zone          jp-tok-2
Created       2023-12-22T12:14:42+09:00

$ ibmcloud is vpc-routing-table vpc-tok-syasuda1 ingress-route
Getting routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID                                         r022-3f05feb1-8897-445d-a0d2-8272aab20756
Name                                       ingress-route
Status                                     stable
Accept routes from resource type filters   -
Route Direct Link Ingress                  true
Route Internet Ingress                     true
Route Transit Gateway Ingress              true
Route VPC Zones Ingress                    true
Routes                                     ID                                          Name                                            Action    Status   Destination        Next hop   Zone       Priority   Origin
                                           r022-5c5378c2-2817-4a02-9b40-77d96a62b474   dbserver1-tokyo1                                deliver   stable   192.168.10.10/32   10.0.0.7   jp-tok-1   2          user
                                           r022-aeb1c366-f112-4f7a-a072-5ed9af1f2465   dbserver2-tokyo2                                deliver   stable   192.168.10.10/32   10.1.0.7   jp-tok-2   1          user

Advertise routes to                        direct_link,transit_gateway
Subnets                                    ID                          Name
                                           No subnets were attached.

Created                                    2021-01-21T14:11:14+09:00

bash-4.3# ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10): 56 data bytes
64 bytes from 192.168.10.10: icmp_seq=0 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=1 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=4 ttl=58 time=0 ms

Server-A

[root@server-a ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
（出力なし）

Server-B

[root@server-b ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
22:07:54.585069 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 322, seq 0, length 64
22:07:54.585092 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 322, seq 0, length 64
22:07:55.585055 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 322, seq 1, length 64
22:07:55.585076 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 322, seq 1, length 64
22:07:56.585087 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 322, seq 2, length 64
22:07:56.585134 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 322, seq 2, length 64
22:07:57.585104 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 322, seq 3, length 64
22:07:57.585151 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 322, seq 3, length 64
22:07:58.585102 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 322, seq 4, length 64
22:07:58.585147 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 322, seq 4, length 64

5-4. Server-Aへの切り戻し

再度Server-Bへの経路広告の優先度を1から3に戻す。
UIで戻しても良いが、以下にCLIでの実行例を示す。

$ ibmcloud is vpc-routing-table-route-update vpc-tok-syasuda1 ingress-route dbserver2-tokyo2 --priority 3
Update route dbserver2-tokyo2 for routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID            r022-aeb1c366-f112-4f7a-a072-5ed9af1f2465
Name          dbserver2-tokyo2
Action        deliver
Status        stable
Destination   192.168.10.10/32
Priority      3
Origin        user
Next hop      10.1.0.7
Advertise     true
Zone          jp-tok-2
Created       2023-12-22T12:14:42+09:00

$ ibmcloud is vpc-routing-table vpc-tok-syasuda1 ingress-route
Getting routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID                                         r022-3f05feb1-8897-445d-a0d2-8272aab20756
Name                                       ingress-route
Status                                     stable
Accept routes from resource type filters   -
Route Direct Link Ingress                  true
Route Internet Ingress                     true
Route Transit Gateway Ingress              true
Route VPC Zones Ingress                    true
Routes                                     ID                                          Name                                            Action    Status   Destination        Next hop   Zone       Priority   Origin
                                           r022-5c5378c2-2817-4a02-9b40-77d96a62b474   dbserver1-tokyo1                                deliver   stable   192.168.10.10/32   10.0.0.7   jp-tok-1   2          user
                                           r022-aeb1c366-f112-4f7a-a072-5ed9af1f2465   dbserver2-tokyo2                                deliver   stable   192.168.10.10/32   10.1.0.7   jp-tok-2   3          user

Advertise routes to                        direct_link,transit_gateway
Subnets                                    ID                          Name
                                           No subnets were attached.

Created                                    2021-01-21T14:11:14+09:00

6. パターン2: 経路広告をする・しないで制御する方法

6-1. Ingress Custom Route(Ingress)の作成

• 経路広告を有効にするには、「Direct LinkやTransit Gatewayに経路広告を行うかどうか」というGlobal設定と、「各経路ごとの設定」の、２箇所での構成が必要になる。
• tokyo1/tokyo2への経路を作成しておき、普段はtokyo1からのみ経路広告しておく（tokyo2からは経路広告しない）。切替時には、tokyo1からの経路広告を停止し、tokyo2からの経路広告を有効にする。
  

6-2. Server-Aへの接続テスト

• 今回はDirect Link Connect 2.0経由でAIX端末からテストを行った。
• Direct Linkの経路広告情報を見ると、以下のように192.168.10.10/32だけが経路広告されている（どちらのAZからの経路広告なのかは読み取れない）。
  

AIX(Client）

bash-4.3# ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10): 56 data bytes
64 bytes from 192.168.10.10: icmp_seq=0 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=1 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=54 time=1 ms
64 bytes from 192.168.10.10: icmp_seq=4 ttl=54 time=1 ms

Server-A

[root@server-a ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
21:56:05.275552 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 362, seq 0, length 64
21:56:05.275598 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 362, seq 0, length 64
21:56:06.275533 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 362, seq 1, length 64
21:56:06.275578 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 362, seq 1, length 64
21:56:07.275580 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 362, seq 2, length 64
21:56:07.275625 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 362, seq 2, length 64
21:56:08.275548 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 362, seq 3, length 64
21:56:08.275594 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 362, seq 3, length 64
21:56:09.275503 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 362, seq 4, length 64
21:56:09.275524 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 362, seq 4, length 64

Server-B

[root@server-b ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
（出力なし）

6-3. Server-A障害時のアクセス（Server-Bへの切り替えテスト）

• Custom Routeにて、tokyo-1からの経路広告を停止し、tokyo-2からの経路広告を有効にする(UIで変更しても良いし、以下のようにCLIで変更しても良い）。

$ ibmcloud is vpc-routing-table-route-update vpc-tok-syasuda1 ingress-route dbserver1-tokyo1 --advertise false
Update route dbserver1-tokyo1 for routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID            r022-5c5378c2-2817-4a02-9b40-77d96a62b474
Name          dbserver1-tokyo1
Action        deliver
Status        stable
Destination   192.168.10.10/32
Priority      2
Origin        user
Next hop      10.0.0.7
Advertise     false
Zone          jp-tok-1
Created       2023-12-22T11:30:31+09:00

$ ibmcloud is vpc-routing-table-route-update vpc-tok-syasuda1 ingress-route dbserver2-tokyo2 --advertise true
Update route dbserver2-tokyo2 for routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID            r022-aeb1c366-f112-4f7a-a072-5ed9af1f2465
Name          dbserver2-tokyo2
Action        deliver
Status        stable
Destination   192.168.10.10/32
Priority      2
Origin        user
Next hop      10.1.0.7
Advertise     true
Zone          jp-tok-2
Created       2023-12-22T12:14:42+09:00

AIX(Client）

bash-4.3# ping 192.168.10.10
PING 192.168.10.10 (192.168.10.10): 56 data bytes
64 bytes from 192.168.10.10: icmp_seq=0 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=1 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=2 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=3 ttl=58 time=0 ms
64 bytes from 192.168.10.10: icmp_seq=4 ttl=58 time=0 ms

Server-A

[root@server-a ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

Server-B

[root@server-b ~]# tcpdump -i any icmp -nn
tcpdump: data link type LINUX_SLL2
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
21:59:23.312625 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 500, seq 0, length 64
21:59:23.312649 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 500, seq 0, length 64
21:59:24.312411 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 500, seq 1, length 64
21:59:24.312457 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 500, seq 1, length 64
21:59:25.312424 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 500, seq 2, length 64
21:59:25.312487 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 500, seq 2, length 64
21:59:26.312375 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 500, seq 3, length 64
21:59:26.312423 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 500, seq 3, length 64
21:59:27.312463 eth0  In  IP 192.168.50.223 > 192.168.10.10: ICMP echo request, id 500, seq 4, length 64
21:59:27.312508 eth0  Out IP 192.168.10.10 > 192.168.50.223: ICMP echo reply, id 500, seq 4, length 64

6-4. Server-Aへの切り戻し

再度tokyo1からの経路広告を有効にし、tokyo2からの経路広告を無効にする。
UIで戻しても良いが、以下にCLIでの実行例を示す。

$ ibmcloud is vpc-routing-table-route-update vpc-tok-syasuda1 ingress-route dbserver1-tokyo1 --advertise true
Update route dbserver1-tokyo1 for routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID            r022-5c5378c2-2817-4a02-9b40-77d96a62b474
Name          dbserver1-tokyo1
Action        deliver
Status        stable
Destination   192.168.10.10/32
Priority      2
Origin        user
Next hop      10.0.0.7
Advertise     true
Zone          jp-tok-1
Created       2023-12-22T11:30:31+09:00

$ ibmcloud is vpc-routing-table-route-update vpc-tok-syasuda1 ingress-route dbserver2-tokyo2 --advertise false
Update route dbserver2-tokyo2 for routing table ingress-route of vpc vpc-tok-syasuda1 under account xxx as user [e-mail]...

ID            r022-aeb1c366-f112-4f7a-a072-5ed9af1f2465
Name          dbserver2-tokyo2
Action        deliver
Status        stable
Destination   192.168.10.10/32
Priority      2
Origin        user
Next hop      10.1.0.7
Advertise     false
Zone          jp-tok-2
Created       2023-12-22T12:14:42+09:00