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-256 aes-cbc-128 group 14 integrity sha256 sha1 // 設定修正後 crypto ikev2 proposal proposal-for-csr3 encryption aes-cbc-192 group 24 integrity sha51 |
設定修正後、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.1) 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 を実行して完了です！
