VPC CIDRの拡張によるVPN接続の動的経路(BGP)への影響を検証してみた
こんにちは、菊池です。
先月の機能アップデートにより、VPCのCIDRが追加拡張可能になりました。
これまで、最初にVPCを作成した時点のCIDRから一切変更できなかったことを考えると、素晴らしいアップデートです。しかし、簡単にCIDRを追加できる一方で、VPNで動的ルーティング(BGP)を設定している環境では注意が必要になります。
BGPによる経路情報の交換
動的ルーティングを有効にしているVPN接続では、BGPによりお互いの経路情報を交換し、ルートテーブルに反映します。これにより、お互いのCIDRを認識して、手動で設定することなく相互に通信することが可能です。
AWS上のVPCへのVPN接続では、VGWはVPC全体のCIDRをアドバタイズしますので、上図の場合には10.16.0.0/20がカスタマーゲートウェイに通知されます。カスタマーゲートウェイがアドバタイズする経路は、ルーターのBGP設定次第になります。
VPC CIDRの追加機能により、VPCにセカンダリCIDRを追加すると、VGWからは追加されたCIDRが即座にアドバタイズされます。
CIDR追加でも自動で経路を学習し、オンプレミスからの通信が可能になることはありがたいですが、環境によっては障害になるケースがあります。
CIDR追加の経路で問題になるケース
CIDR追加によってBGPで接続されたネットワーク全体でCIDRの重複が発生すると、意図しない経路を学習し、正常に通信できなくなるケースがあります。
例えば、以下のように2つのVPC、A/Bとオンプレミス環境がVPNで接続している環境です。
この状態では、アドバタイズされる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の一部サブネットには到達不能になってしまいます。
このときの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に追加してみます。
ルータの状態です。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以外についてネットワーク管理者が関与せず、自由に操作可能な環境も多いかと思います。簡単に拡張できる一方で、重大な障害を引き起こす可能性もある箇所ですので、注意しましょう。