VPC CIDRの拡張によるVPN接続の動的経路（BGP）への影響を検証してみた

VPC CIDRの拡張によるVPN接続の動的経路（BGP）への影響を検証してみた

#Amazon VPC
#AWS
菊池修治

菊池修治

facebook logohatena logotwitter logo
Clock Icon2017.09.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、菊池です。

先月の機能アップデートにより、VPCのCIDRが追加拡張可能になりました。

[新機能] VPCのCIDRが拡張可能になりました！IPアドレス範囲を追加可能です！

これまで、最初にVPCを作成した時点のCIDRから一切変更できなかったことを考えると、素晴らしいアップデートです。しかし、簡単にCIDRを追加できる一方で、VPNで動的ルーティング（BGP）を設定している環境では注意が必要になります。

BGPによる経路情報の交換

動的ルーティングを有効にしているVPN接続では、BGPによりお互いの経路情報を交換し、ルートテーブルに反映します。これにより、お互いのCIDRを認識して、手動で設定することなく相互に通信することが可能です。

add-cidr-vpn-008

AWS上のVPCへのVPN接続では、VGWはVPC全体のCIDRをアドバタイズしますので、上図の場合には10.16.0.0/20がカスタマーゲートウェイに通知されます。カスタマーゲートウェイがアドバタイズする経路は、ルーターのBGP設定次第になります。

VPC CIDRの追加機能により、VPCにセカンダリCIDRを追加すると、VGWからは追加されたCIDRが即座にアドバタイズされます。

add-cidr-vpn-007

CIDR追加でも自動で経路を学習し、オンプレミスからの通信が可能になることはありがたいですが、環境によっては障害になるケースがあります。

CIDR追加の経路で問題になるケース

CIDR追加によってBGPで接続されたネットワーク全体でCIDRの重複が発生すると、意図しない経路を学習し、正常に通信できなくなるケースがあります。

例えば、以下のように2つのVPC、A/Bとオンプレミス環境がVPNで接続している環境です。

add-cidr-vpn-011

この状態では、アドバタイズされるCIDRに重複はありませんので、VPCとオンプレミス環境は問題なくルーティングが可能です。上記の構成で、カスタマーゲートウェイのBGPテーブルとなります。（Cisco IOSルータの場合）なお、各VPCにつきVPNセッションは2つ存在するため、2つの経路を受け取っています。

router#show ip bgp
BGP table version is 4, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.10.10.0/24    0.0.0.0                  0         32768 i
 *   10.16.0.0/20     169.254.24.229         200             0 10124 i
 *>                   169.254.26.57          100             0 10124 i
 *   10.16.16.0/20    169.254.27.213         200             0 10124 i
 *>                   169.254.27.253         100             0 10124 i

ルートテーブルには、各VPCの宛先が追加されています。

router#sho ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.1.1
      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C        10.10.10.0/24 is directly connected, Vlan1
L        10.10.10.254/32 is directly connected, Vlan1
B        10.16.0.0/20 [20/100] via 169.254.26.57, 00:26:28
B        10.16.16.0/20 [20/100] via 169.254.27.253, 00:09:54
      169.254.0.0/16 is variably subnetted, 8 subnets, 2 masks
C        169.254.24.228/30 is directly connected, Tunnel1
L        169.254.24.230/32 is directly connected, Tunnel1
C        169.254.26.56/30 is directly connected, Tunnel2
L        169.254.26.58/32 is directly connected, Tunnel2
C        169.254.27.212/30 is directly connected, Tunnel4
L        169.254.27.214/32 is directly connected, Tunnel4
C        169.254.27.252/30 is directly connected, Tunnel3
L        169.254.27.254/32 is directly connected, Tunnel3
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, GigabitEthernet0/5
L        192.168.1.253/32 is directly connected, GigabitEthernet0/5

ここで、VPC Aに、セカンダリCIDRとしてVPC Bと重複する10.16.16.0/22を追加します。すると、VPC Aからは即座に追加した経路情報がアドバタイズされます。その結果、カスタマーゲートウェイは10.16.16.0/22をVPC A側にルーティングしてしまうため、VPC Bの一部サブネットには到達不能になってしまいます。

add-cidr-vpn-010

このときのBGPテーブルは以下のようになっています。

router#show ip bgp
BGP table version is 5, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.10.10.0/24    0.0.0.0                  0         32768 i
 *   10.16.0.0/20     169.254.24.229         200             0 10124 i
 *>                   169.254.26.57          100             0 10124 i
 *   10.16.16.0/22    169.254.24.229         200             0 10124 i
 *>                   169.254.26.57          100             0 10124 i
 *   10.16.16.0/20    169.254.27.213         200             0 10124 i
 *>                   169.254.27.253         100             0 10124 i

ルートテーブルにも、10.16.16.0/22が学習されてしまっています。

router#sho ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.1.1
      10.0.0.0/8 is variably subnetted, 5 subnets, 4 masks
C        10.10.10.0/24 is directly connected, Vlan1
L        10.10.10.254/32 is directly connected, Vlan1
B        10.16.0.0/20 [20/100] via 169.254.26.57, 00:27:12
B        10.16.16.0/20 [20/100] via 169.254.27.253, 00:10:38
B        10.16.16.0/22 [20/100] via 169.254.26.57, 00:00:18
      169.254.0.0/16 is variably subnetted, 8 subnets, 2 masks
C        169.254.24.228/30 is directly connected, Tunnel1
L        169.254.24.230/32 is directly connected, Tunnel1
C        169.254.26.56/30 is directly connected, Tunnel2
L        169.254.26.58/32 is directly connected, Tunnel2
C        169.254.27.212/30 is directly connected, Tunnel4
L        169.254.27.214/32 is directly connected, Tunnel4
C        169.254.27.252/30 is directly connected, Tunnel3
L        169.254.27.254/32 is directly connected, Tunnel3
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, GigabitEthernet0/5
L        192.168.1.253/32 is directly connected, GigabitEthernet0/5

重複するCIDRがルートテーブルにある場合、ネットマスクのプレフィックスが長く一致する経路を優先して利用します（ロンゲストマッチ）。そのため、このケースでは10.16.16.1〜10.16.19.255までの宛先についてはVPC Aにルーティングする動作になります。

では、重複する範囲が同じ大きさのCIDRを追加した場合にはどのような動作となるでしょうか。下図のように、今度はVPC BのCIDRと同じ10.16.16.0/20をVPC Aに追加してみます。

add-cidr-vpn-009

ルータの状態です。BGPテーブルには、同じ宛先ネットワークとして4経路存在していますが、ベストパスは169.254.27.253で変化がありません。ちなみに、VPC Aからの経路は連続サブネットですが、VGWで10.16.0.0/19のように経路集約はしないみたいです。

outer#show ip bgp
BGP table version is 7, local router ID is 192.168.1.253
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found

     Network          Next Hop            Metric LocPrf Weight Path
 *>  10.10.10.0/24    0.0.0.0                  0         32768 i
 *   10.16.0.0/20     169.254.24.229         200             0 10124 i
 *>                   169.254.26.57          100             0 10124 i
 *   10.16.16.0/20    169.254.24.229         200             0 10124 i
 *                    169.254.26.57          100             0 10124 i
 *                    169.254.27.213         200             0 10124 i
 *>                   169.254.27.253         100             0 10124 i

ルートテーブル上も、問題はないですね。

router#sho ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
       a - application route
       + - replicated route, % - next hop override, p - overrides from PfR

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.1.1
      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
C        10.10.10.0/24 is directly connected, Vlan1
L        10.10.10.254/32 is directly connected, Vlan1
B        10.16.0.0/20 [20/100] via 169.254.26.57, 00:32:52
B        10.16.16.0/20 [20/100] via 169.254.27.253, 00:16:18
      169.254.0.0/16 is variably subnetted, 8 subnets, 2 masks
C        169.254.24.228/30 is directly connected, Tunnel1
L        169.254.24.230/32 is directly connected, Tunnel1
C        169.254.26.56/30 is directly connected, Tunnel2
L        169.254.26.58/32 is directly connected, Tunnel2
C        169.254.27.212/30 is directly connected, Tunnel4
L        169.254.27.214/32 is directly connected, Tunnel4
C        169.254.27.252/30 is directly connected, Tunnel3
L        169.254.27.254/32 is directly connected, Tunnel3
      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.1.0/24 is directly connected, GigabitEthernet0/5
L        192.168.1.253/32 is directly connected, GigabitEthernet0/5

CIDRの大きさが同じ場合には、ルートが変わってしまうことはありませんでした。これは、BGPのパラメータが同じ経路の場合には、先に受信した経路を利用するというCiscoルータの仕様によるものです。

このケースではたまたま問題はありませんでしたが、セッション断などが発生した場合には経路が切り替わるリスクがありますので回避すべきでしょう。

回避方法

このような事態を回避するためには、ネットワーク全体で重複するCIDRを設定しないことが第一です。

しかし、AWS環境とネットワークの管理者が別であったりすることもあるかと思います。オンプレミスにあるカスタマーゲートウェイを操作する人は限られていても、AWS側はVPCの設定が可能であれば簡単にCIDRの追加ができてしまいます。意図せず、ネットワーク全体の設計を破壊することがないように、カスタマーゲートウェイ側で防御しておく方法もあります。

ルートフィルタの設定

カスタマーゲートウェイで、学習する経路を制限しておきましょう。Cisco IOSルータの場合は、以下のようにアクセスリストを作成し、BGPネイバーに対し設定します。（169.254.xxx.xxxの部分は利用環境のBGPネイバーに合わせて設定します）

router(config)#access-list 10 permit 10.16.0.0 0.0.15.255
router(config)#access-list 11 permit 10.16.16.0 0.0.15.255
router(config)#router bgp 65000
router(config-router)#neighbor 169.254.24.229 distribute-list 10 in
router(config-router)#neighbor 169.254.26.57 distribute-list 10 in
router(config-router)#neighbor 169.254.27.213 distribute-list 11 in
router(config-router)#neighbor 169.254.27.253 distribute-list 11 in

こうすることで、許可された経路以外をルートテーブルに学習しないよう制御可能です。自動で経路を学習することとのトレードオフにはなりますので、障害のリスクを考慮して適用を検討しましょう。

まとめ

VPCのCIDR追加に伴う、VPNのBGP経路について動作をみてみました。

AWS側の操作については、VPNやDirectConnect以外についてネットワーク管理者が関与せず、自由に操作可能な環境も多いかと思います。簡単に拡張できる一方で、重大な障害を引き起こす可能性もある箇所ですので、注意しましょう。

 

Share this article

facebook logohatena logotwitter logo

関連記事

[レポート] VPC Lattice と PrivateLink を利用したクロス VPC リソースアクセス「Simplify cross-VPC resource access with PrivateLink and VPC Lattice」 #NET218

[レポート] VPC Lattice と PrivateLink を利用したクロス VPC リソースアクセス「Simplify cross-VPC resource access with PrivateLink and VPC Lattice」 #NET218

User avatar
大村 保貴
2024.12.22
Service Network型VPCエンドポイントの作成が失敗しても使える時の裏側を確認してみた

Service Network型VPCエンドポイントの作成が失敗しても使える時の裏側を確認してみた

User avatar
のんピ
2024.12.20
Resource型VPCエンドポイント経由でMulti-AZのAmazon FSx for NetApp ONTAPファイルシステムに接続してみた

Resource型VPCエンドポイント経由でMulti-AZのAmazon FSx for NetApp ONTAPファイルシステムに接続してみた

User avatar
のんピ
2024.12.18
VPC Lattice経由でSSH接続してみた

VPC Lattice経由でSSH接続してみた

User avatar
のんピ
2024.12.17
Classmethod's white logo
Facebook's logo
X's logo
YouTube's logo

© Classmethod, Inc. All rights reserved.