EEMおよびIP SLAを使用したVPNトンネルでのIGPフラップ、パケット損失、またはトンネルバウンスのトラブルシューティング

概要

このドキュメントでは、DMVPN/GRE/sVTI/FlexVPNトンネルでEIGRP/OSPF/BGPのフラップが発生した場合に実行する手順について説明します。

背景説明

この問題をトラブルシューティングするには、最初に回答する必要がある質問は、「これはVPN、ルーティングプロトコル、またはISPの問題か」です。 この質問に答えるには、フラップまたは停止時に、アンダーレイ（通常はインターネットまたはプライベートWAN）とオーバーレイ（通常はVPNトンネル）の接続テストを実行する必要があります。残念ながら、これらのフラップイベントは一時的で断続的である可能性があり、その結果、問題の発生時にこれらのテストを実行することが困難になる可能性があります。このドキュメントでは、問題発生時にIP Service Level Agreement（SLA；サービスレベル契約）、トラックオブジェクト、およびEmbedded Event Manager(EEM)を自動的に収集するための使用方法について説明します。

機能情報

IP SLAは、バックグラウンドでルータ上で実行されるプロセスであり、多数のネットワーク状態をテストします。このドキュメントでは、一般的なIP接続が "icmp-echo" テスト.

トラックオブジェクトは、IP SLAの状態を追跡できます。次に、EEMアプレットを使用して、トラックオブジェクトが変化したときにネットワークの状態をsyslogバッファに記録できます。

syslog履歴に記録されたネットワーク状態を利用して、フラップまたは停止時のネットワークの状態を把握し、暗号化、トランスポート、またはInterior Gateway Protocol(IGP)の問題があるかどうかを判断します。

方法

手順1.アンダーレイ（インターネット接続）を追跡するSLAを定義する

• オプション A
  パブリックIPアドレスからパブリックIPアドレス(172.18.3.52 > 172.20.5.43)。 通常、リモートピアはICMPに応答するため、このSLAは1つのデバイス上でのみ定義する必要があります。
  

  ip sla 100
      icmp-echo 172.20.5.43 source-interface FastEthernet4
      frequency 5
  ip sla schedule 100 life forever start-time now
  

• オプション B

  注：環境によっては、アンダーレイ/トランスポートネットワークでインターネット制御メッセージプロトコル(ICMP)パケットがブロックされます。このような環境では – udp-echo パケットは icmp-echo IP SLA

  
  IP SLAイニシエータ（左側のルータ）
  

  ip sla 100
   udp-echo 172.20.5.43 1501 source-ip 172.18.3.52 source-port 1501 control disable
   frequency 5
  ip sla schedule 100 life forever start-time now

  IP SLA応答側（正しいルータ）
  

  ip sla responder
  ip sla responder udp-echo ipaddress 172.20.5.43 port 1501

ステップ2：オーバーレイ（トンネル接続）を追跡するSLAを定義します

• トンネルIPアドレスからトンネルIPアドレス(10.1.12.100 > 10.1.12.1)

  ip sla 200
      icmp-echo 10.1.12.1 source-interface Tunnel100
      frequency 5
  ip sla schedule 200 life forever start-time now

これらのSLAは、定義されたピアに5秒ごとに1つのパケットを送信します。ピアが応答すると、SLAは「OK。 応答しない場合は、「Timeout。 トラックオブジェクトは、SLAの状態を監視します。

ステップ3：トラックオブジェクトを定義してSLAの状態を監視する

• アンダーレイ接続トラックオブジェクト
  

  track 100 ip sla 100
     delay down 15 up 15

• オーバーレイ接続トラックオブジェクト
  

  track 200 ip sla 200
     delay down 15 up 15

トラック オブジェクトが変化すると、メッセージを Syslog に挿入できます。

ステップ4：トラックオブジェクトの変更時に記録するEEMアプレットを定義します

• アンダーレイの転送が失敗した場合のEEMアプレットを、回復した場合のEEMアプレットを作成します
  

  event manager applet ipsla100down 
      event track 100 state down
      action 1.0 syslog msg "Underlay SLA probe failed!"
  event manager applet ipsla100up 
     event track 100 state up
     action 1.0 syslog msg "Underlay SLA probe came up!"

• オーバーレイトランスポートが失敗した場合のEEMアプレットを作成し、回復した場合のEEMアプレットを作成します
  

  event manager applet ipsla200down 
      event track 200 state down
      action 1.0 syslog msg "Overlay SLA probe failed!"
  event manager applet ipsla200up 
     event track 200 state up
     action 1.0 syslog msg "Overlay SLA probe came up!"

データ分析

停止が発生した場合は、 show log コマンドを実行します。前のセクションに示すSLAメッセージを探します。

次の3つのシナリオが考えられます。

1. 両方の SLA が失敗します。この場合、次を意味します。
   1. 2つのピア間のアンダーレイ（インターネット/MPLS）間のレイヤ3接続が中断されました。これはさらなる調査が必要です。
   2. トンネルには問題は発生していません。アンダーレイの中断の犠牲者であるため、失敗しました。
2. 物理SLAは失敗しませんが、トンネルSLAは失敗します。この場合、次を意味します。
   1. 2つのピア間のインターネット経由のレイヤ3接続は正常に動作します。
   2. トンネルに問題が発生しています。トンネルのさらなる調査が必要です。
3. いずれの SLA も失敗します。この場合、次を意味します。
   1. 2つのピア間のインターネット経由のレイヤ3接続は正常に動作します。
   2. 2つのピア間のトンネルを介したレイヤ3ユニキャスト接続は正常に動作します。
   3. トンネル経由でのレイヤ 3 マルチキャスト接続は不明です。これをテストするには、IGPが使用するマルチキャストアドレスにpingを実行します。
   4. テストが正常に動作している場合は、アプリケーションの問題(EIGRP/OSFP/BGP)を示しています。 プロトコルのさらなる調査が必要です。