JANOG50 の NETCON に作問者として参加しました!
こちらのブログでは、level 3-4 の問題について解説していきます。
【目次】
level 3-4 問題の概要
level 3-4 は拠点間で BGP over IPsec が正常に構成できていない問題で、 IPsec 及び BGP 観点のトラブルシューティングが必要です。
ポイントは対向拠点の機器にログインできないことで、あえて debug コマンドを使わざるを得ない状況にしています。
トポロジ
![](https://hutene.com/wp-content/uploads/topology.png)
問題文
拠点間で 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 が確立できていないことが分かります
![](https://hutene.com/wp-content/uploads/show_crypto_ikev2_sa.png)
show crypto ipsec sa
→ Phase 2 SA も確立できていないことが分かります
![](https://hutene.com/wp-content/uploads/show_crypto_ipsec_sa.png)
次に、 debug コマンドで Phase 1 SA が確立できていない原因を探ります。
debug crypto ikev2
![](https://hutene.com/wp-content/uploads/debug_crypto_ikev2.png)
上記より、対向機器 (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 の作成が完了した旨のメッセージが表示されます。
![](https://hutene.com/wp-content/uploads/image2022-6-28_8-39-50.png)
問題①はこれにて完了です!!
※ 今回は不要ですが、Phase 2 SA についても調査が必要な場合は “debug crypto ipsec” も有効です。
問題②の解説
Syslog message を確認すると、recursive routing によって Tunnel 1 Interface が flap している様です。
![](https://hutene.com/wp-content/uploads/image2022-6-28_8-45-39.png)
流れを追うと、以下のようになっています。
- 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
![](https://hutene.com/wp-content/uploads/image2022-6-28_8-52-54.png)
上記より、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) の両方から学習していそうとアタリがつけられると思います。
![](https://hutene.com/wp-content/uploads/image2022-6-29_8-23-46.png)
仮説を検証します。
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 前
![](https://hutene.com/wp-content/uploads/iproute1.png)
// neighbor 192.168.0.2 up 直後
![](https://hutene.com/wp-content/uploads/iproute2.png)
上記のように、 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 の結果は以下のようになります。
![](https://hutene.com/wp-content/uploads/iproute3.png)
最後に、両端の VPC から ping を実行して完了です!
![](https://hutene.com/wp-content/uploads/ping.png)