EEM 및 IP SLA를 사용하여 VPN 터널을 통해 IGP 플랩, 패킷 손실 또는 터널 바운스 문제 해결

소개

이 문서에서는 DMVPN/GRE/sVTI/FlexVPN 터널을 통해 EIGRP/OSPF/BGP 플랩을 경험할 때 수행할 단계를 설명합니다.

배경 정보

이 문제를 해결하려면 먼저 답변해야 할 질문은 "VPN, 라우팅 프로토콜 또는 ISP 문제입니까?"입니다. 질문에 답하려면 플랩/중단 시 언더레이(보통 인터넷 또는 사설 WAN) 및 오버레이(일반적으로 VPN 터널)에서 연결 테스트를 수행해야 합니다. 안타깝게도 이러한 플랩 이벤트는 일시적이며 간헐적일 수 있으며, 따라서 문제 발생 시 이러한 테스트를 수행하기가 어려울 수 있습니다. 이 문서에서는 문제 발생 시 이 정보를 자동으로 수집하기 위해 IP SLA(Service Level Agreement), 추적 객체 및 EEM(Embedded Event Manager)의 사용에 대한 지침을 제공합니다.

기능 정보

IP SLA는 백그라운드에서 라우터에서 실행되는 프로세스로서 여러 네트워크 조건을 테스트합니다. 이 문서에서 일반 IP 연결은 "icmp-echo" 테스트.

그런 다음 트랙 개체는 IP SLA의 상태를 추적할 수 있습니다. 그런 다음 EEM 애플릿을 사용하면 추적 객체가 변경될 때 syslog 버퍼에 네트워크 상태를 기록할 수 있습니다.

시스템 로그 기록에 기록된 네트워크 상태를 활용하여 플랩/중단 중 네트워크의 상태를 파악하고 암호화, 전송 또는 IGP(Interior Gateway Protocol) 문제가 있는지 확인합니다.

방법론

1단계. 언더레이(인터넷 연결)를 추적할 SLA를 정의합니다.

• 옵션 A
  공용 IP 주소에 대한 공용 IP 주소(172.18.3.52 > 172.20.5.43). 일반적으로 원격 피어가 ICMP에 응답하므로 이 SLA는 하나의 디바이스에서만 정의되어야 합니다.
  

  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(Internet Control Message Protocol) 패킷이 언더레이/전송 네트워크에서 차단됩니다. 이러한 환경에서는 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초마다 단일 패킷을 전송합니다. 피어가 응답하면 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 메시지를 찾습니다.

다음과 같은 세 가지 잠재적 시나리오가 있습니다.

1. 두 SLA 모두 실패합니다. 이는 다음을 의미합니다.
   1. 두 피어 간의 언더레이(인터넷/MPLS) 간 레이어 3 연결이 중단되었습니다. 추가 조사가 필요합니다.
   2. 터널에 문제가 없습니다. 그것은 언더레이 중단의 피해자이기 때문에 실패했다.
2. 물리적 SLA는 실패하지 않지만 터널 SLA는 실패합니다. 이는 다음을 의미합니다.
   1. 두 피어 간에 인터넷을 통해 레이어 3 연결이 올바르게 작동합니다.
   2. 터널에 문제가 있습니다. 그 터널에 대한 추가 조사가 필요하다.
3. 두 SLA는 모두 실패하지 않습니다. 이는 다음을 의미합니다.
   1. 두 피어 간에 인터넷을 통해 레이어 3 연결이 올바르게 작동합니다.
   2. 두 피어 간의 터널을 통해 레이어 3 유니캐스트 연결이 올바르게 작동합니다.
   3. 터널 전반의 레이어 3 멀티캐스트 연결을 알 수 없습니다. 이를 테스트하려면 IGP에서 사용하는 멀티캐스트 주소를 ping합니다.
   4. 테스트가 작동하는 경우 애플리케이션 문제(EIGRP/OSFP/BGP)를 나타냅니다. 추가 프로토콜 조사가 필요합니다.