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 している様です。

流れを追うと、以下のようになっています。

  1. Tunnel 1 が up
  2. Tunnel 上で bgp neighbor が up
  3. recursive routing を検知し、Tunnel 1 が down
  4. それに合わせて 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 は上書きされてしまいます。

  1. 宛先 = 10.0.0.4/30, nexthop = 10.0.0.2
  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 を実行して完了です!