公開 / 更新
JANOG50 NETCON 問題解説 (level 3-4)：BGP over IPsec
BGP over IPsec が確立しない原因を debug コマンドで調べ、IKEv2 のポリシー不一致と再帰ルーティングによるトンネルの flap を解消します。
JANOG50 の NETCON に作問者として参加しました。 こちらのブログでは、level 3-4 の問題について解説していきます。
level 3-4 問題の概要
level 3-4 は拠点間で BGP over IPsec が正常に構成できていない問題で、 IPsec 及び BGP 観点のトラブルシューティングが必要です。
ポイントは対向拠点の機器にログインできないことで、あえて debug コマンドを使わざるを得ない状況にしています。
トポロジ
問題文
拠点間で IPsec トンネルの確立を試み、あなたは函館拠点 (CSR1)、上司は東京拠点 (CSR3) で作業をしています。 上司は設定作業を終えると、「妻との結婚記念日なんだ！」とさっさと帰ってしまいました。
その後、あなたも設定を完了させました。 しかし IPsec トンネルが確立できません！
切り分けの結果、IPsec パケット自体は届いているため、IP アドレスや通信経路の問題ではないようです。 上司に連絡はつかないものの、どうにか今日中に IPsec トンネルを確立する必要があります。
なお、東京拠点の機器 (CSR3) にログインすることはできないため、函館拠点の機器 (CSR1) の設定を修正して IPsec トンネルを確立する必要があります。
問題① 函館拠点側の機器 (CSR1) の設定を 修正 して、 IPsec トンネルを確立してください。
問題② 問題1でIPsecトンネルを確立できました。 ただ、Interface flap が発生しており、 VPC間で通信が行えないようです。 函館拠点側の機器 (CSR1) に設定を 追加 し、VPC1 (192.168.100.1) から VPC2 (192.168.200.1) への ping が成功する事を確認してください。
CSR1の初期Config
interface gigabitethernet 1
ip address 10.0.0.1 255.255.255.252
no shutdown
interface gigabitethernet 4
ip address 192.168.100.254 255.255.255.0
no shutdown
interface tunnel 1
ip address 192.168.0.1 255.255.255.252
ip mtu 1400
tunnel mode ipsec ipv4
tunnel source gigabitethernet 1
tunnel destination 10.0.0.6
tunnel protection ipsec profile profile-for-csr3
no shutdown
ip prefix-list local-networks seq 10 permit 192.168.100.0/24
ip prefix-list provider-networks seq 10 permit 10.0.0.0/30
router bgp 65510
neighbor 10.0.0.2 remote-as 65500
neighbor 10.0.0.2 update-source GigabitEthernet1
neighbor 192.168.0.2 remote-as 65520
neighbor 192.168.0.2 update-source Tunnel1
address-family ipv4 unicast
neighbor 10.0.0.2 activate
neighbor 10.0.0.2 prefix-list provider-networks out
neighbor 192.168.0.2 activate
neighbor 192.168.0.2 prefix-list local-networks out
network 10.0.0.0 mask 255.255.255.252
network 192.168.100.0 mask 255.255.255.0
crypto ikev2 proposal proposal-for-csr3
encryption aes-cbc-256 aes-cbc-128
group 14
integrity sha256 sha1
crypto ikev2 policy policy-for-csr3
proposal proposal-for-csr3
crypto ikev2 keyring keyring-for-csr3
peer csr3
address 10.0.0.6 255.255.255.252
pre-shared-key local cisco
pre-shared-key remote cisco
crypto ikev2 profile profile-for-csr3
match identity remote address 10.0.0.6 255.255.255.252
identity local address 10.0.0.1
authentication local pre-share
authentication remote pre-share
keyring local keyring-for-csr3
lifetime 28800
crypto ipsec transform-set transformset-for-csr3 esp-aes esp-sha256-hmac
mode tunnel
crypto ipsec profile profile-for-csr3
set transform-set transformset-for-csr3
set ikev2-profile profile-for-csr3
set security-association lifetime seconds 28800
set security-association lifetime kilobytes 102400000
responder-only解答
問題① 以下のように CSR1 の Config を修正します。
// 設定修正前
crypto ikev2 proposal proposal-for-csr3
encryption aes-cbc-256 aes-cbc-128
group 14
integrity sha256 sha1// 設定修正後
crypto ikev2 proposal proposal-for-csr3
encryption aes-cbc-192
group 24
integrity sha512問題② 以下のように CSR1 の config を追加します。
// 設定追加
ip prefix-list block-routes seq 10 deny 10.0.0.4/30
ip prefix-list block-routes seq 20 permit 0.0.0.0/0 le 32
router bgp 65510
address-family ipv4 unicast
neighbor 192.168.0.2 prefix-list block-routes in問題解説
問題①の解説
「IPsec が繋がらない」以外の情報がないため、show コマンドでもう少し情報収集をします。
show crypto ikev2 sa → Phase 1 SA が確立できていないことが分かります
show crypto ipsec sa → Phase 2 SA も確立できていないことが分かります
次に、 debug コマンドで Phase 1 SA が確立できていない原因を探ります。
debug crypto ikev2
上記より、対向機器 (Received) とローカル機器 (Expected) で明らかに Phase1 SA の Policy が異なることが分かります。
Received Policies = AES-CBC-192 SHA512 SHA512 DH_GROUP_2048_256_MODP/Group 24
Expected Policies = AES-CBC-256 AES-CBC-128 SHA256 SHA1 SHA256 SHA96 DH_GROUP_2048_256_MODP/Group 14
そのため、対向機器に合わせて、ローカル機器の設定を以下のように修正します。
修正後の設定は次のとおりです。
crypto ikev2 proposal proposal-for-csr3
encryption aes-cbc-192
group 24
integrity sha512設定修正後、IKE SA と IPsec SA の作成が完了した旨のメッセージが表示されます。
問題①はこれにて完了です。
※ 今回は不要ですが、Phase 2 SA についても調査が必要な場合は “debug crypto ipsec” も有効です。
問題②の解説
Syslog message を確認すると、recursive routing によって Tunnel 1 Interface が flap している様です。
流れを追うと、以下のようになっています。
- Tunnel 1 が up
- Tunnel 上で bgp neighbor が up
- recursive routing を検知し、Tunnel 1 が down
- それに合わせて bgp neighbor も down
上記より、 BGP で何かしらの経路を学習した際に、 意図しない recursive routing が発生し、 Interface が flap しているとアタリを付けられると思います。
BGP で学習した経路を確認するには、以下の debug コマンドが有用です。
debug ip bgp updates
上記より、neighbor 192.168.0.2 から以下の経路を学習していることが分かります。
- 10.0.0.0/30 (ローカル経路を優先するため、RIB には登録されない)
- 10.0.0.4/30
- 192.168.200.0/24
ここで今回の環境のトポロジ図を確認します。
すると、 10.0.0.4/30 について、Underlay と Overlay (IPsec Tunnel) の両方から学習していそうとアタリがつけられると思います。
仮説を検証します。
neighbor (192.168.0.2) up 前 及び up 直後の show ip route を確認すると、neighbor 10.0.0.2 と 192.168.0.2 から 10.0.0.4/30 を学習しています。 これが意図しない recursive routing 及び Interface flap が発生する原因です。
// neighbor 192.168.0.2 up 前
// neighbor 192.168.0.2 up 直後
上記のように、 IPsec Tunnel 経由で 10.0.0.4/30 を neighbor (192.168.0.2) から学習すると、AS Path の違いにより、元々学習していた経路情報 1 は上書きされてしまいます。
宛先 = 10.0.0.4/30, nexthop = 10.0.0.2- 宛先 = 10.0.0.4/30, nexthop = 192.168.0.2
10.0.0.4/30 は、IPsec Tunnel の宛先が存在するネットワークです。 しかし、それが IPsec Tunnel 経由の経路情報に上書きされてしまったことで Tunnel の宛先に到達不能となり、それを検知したルーターがエラーを出力します。
この状況を解消するには、伝播経路 又は 学習経路のフィルタリングが有効です。 ただし、今回は対向機器を操作できないため、学習経路のフィルタリングを適用します。
具体的には、ローカル機器に以下のような設定を追加します。
ip prefix-list block-routes seq 10 deny 10.0.0.4/30
ip prefix-list block-routes seq 20 permit 0.0.0.0/0 le 32
router bgp 65510
address-family ipv4 unicast
neighbor 192.168.0.2 prefix-list block-routes in設定修正後、BGP flap は解消され、 show ip route の結果は以下のようになります。
最後に、両端の VPC から ping を実行して完了です。
