[Cisco]IP SLA & EEM

'Network 기록하기'는 글쓴이가 실무 경험을 통해 알게 된 지식을 기록하는 공간으로 다른 카테고리의 글에 비해 다소 설명이 불친절하거나 잘못된 정보가 있을 수 있습니다. 양해 부탁드립니다.

IP SLA & EEM

Static Routing(이하 스태틱 라우팅)의 단점은 직접 연결된 링크의 단절은 감지할 수 있지만 직접 연결되지 않은 링크의 단절은 감지할 수 없다는 것입니다. 이는 각 통신사(KT, SKT, LG)의 전용회선을 사용할 때 흔히 일어나는 장애죠. 예를 들어 어떤 회사의 본사와 지사가 모두 라우터를 보유하고 있고 이 중간을 통신사의 전용선을 통해 연결한다고 가정해보겠습니다.(통신사 내부는 한 지역을 담당하는 국사와 다른 지역을 담당하는 국사 간의 연결로 이루어져 있습니다.)

본사 라우터와 국사(통신사 소유 데이터 센터)의 라우터 사이의 연결 단절은 감지할 수 있지만, 국사와 국사간 연결 단절 발생 시 본사 / 지사 라우터가 감지할 수 없습니다. 그래서 라우터는 패킷을 장애가 발생한 국사의 라우터로 라우팅합니다. 그렇다면 통신 문제가 발생할 수밖에 없지요. 그래서 보통 전용회선을 연결할 땐 국사와 국사 간의 LLCF(Link Loss Carry Forward) 활성화를 요청합니다. LLCF 활성화시 국사와 국사 간 단절이 발생하면 Endpoint(이하 엔드포인트)인 본사와 지사 라우터와 연결된 인터페이스까지 모두 다운시켜 엔드포인트에 링크 단절을 전달할 수 있는 것이죠.

이러한 현상은 일반 회사의 네트워크에서도 흔히 발생합니다. 아래 그림의 경우, Office_Router는 Office_VPN으로 가는 경로가 끊어진 것을 알 수 없습니다. 'Connected', 즉 직접 연결된 네트워크가 아니니까요.

<VPN과 스위치의 링크 단절>

IP SLA(Service-Level Agreement)는 이러한 이유로 탄생했습니다. 여기서 말하는 SLA(Service-Level Agreement)는 직역하면 '서비스 수준 협약'이지만 Cisco의 IP SLA는 IP를 이용해 네트워크 성능을 모니터링하는 기능이라고 보는 것이 맞는 듯합니다. 말 그대로 좁게 보면 IP, 넓게 보면 HTTP, FTP, DNS 등을 사용하여 Static Routing이 갖는 한계를 벗어나 다른 네트워크의 성능/상태를 확인하는 것입니다. 이 문서에서는 ICMP Check를 사용한 다른 네트워크의 성능을 확인하는 방법에 대해 적습니다.

<Cisco IP SLA>

EEM(Embedded Evenet Manager)는 장비 내에서 발생하는 이벤트를 추적, 감지하고 그에 대한 동작을 수행하는 OS 내 구성요소입니다. 이벤트가 감지되면 이를 트리거로 작업자가 원하는 작업을 즉시 수행합니다. 이 문서에서는 ICMP Check Down시 그에 대한 대응을 수행하며 CLI로 수행하기 때문에 'Applet'(CLI 명령어)을 적용할 것입니다.

<EEM>

 

활용 배경

본사와 지사로 이루어진 사내 네트워크 구성 중, 이중화와 충분한 대역폭 확보를 위해 아래와 같이 네트워크를 구성하였습니다. 본사는 'HeadQuarter Router/VPN', 지사는 'Office Router/VPN'으로 이루어져 있고 중요 서비스는 라우터(전용회선)로 EIGRP를 활용하여 통신하고, 기타 서비스와 외부 인터넷 접속은 VPN을 통해 이루어집니다.

<라우터와 VPN를 이용한 이중화>

그중 전용회선(라우터)의 대역폭을 뛰어넘는 트래픽을 발생시키는 목적지 IP 대역에 대해서는 VPN으로 우회하여 통신하고자 하였습니다. 해당 목적지 IP는 '5.5.5.x/24'으로 이는 라우터가 아닌 VPN을 통해 통신해야 하며 라우터에서 스태틱 라우팅을 추가하여 강제로 VPN으로 전달하였습니다. 다만 여기서 VPN과 WorkGroup_Switch(이하 워크그룹 스위치) 간 연결이 끊어질 경우, 라우터가 이를 알지 못하고 끊임없이 VPN으로 패킷을 전달하는 문제가 발생할 수 있죠. 연결이 끊어지면 VPN으로의 라우팅을 멈추고 EIGRP를 통해 본사 라우터로 패킷을 전달해야 합니다.

<5.5.5.x/2에 대한 Next Hop은 VPN>

이를 해결하기 위해 IP SLA & EEM을 활용했습니다.

 

구체적인 활용

먼저 라우터에 IP SLA를 적용하였습니다. VPN의 IP(1.1.1.2)를 대상으로 ICMP Check를 실시합니다. 아래 설정에 대한 해석은 다음과 같습니다. 'IP SLA 7'은 5초마다 실시하며 'IP SLA 7'는 설정한 순간부터 즉시 작동합니다.

ip sla 7
 icmp-echo 1.1.1.2
 frequency 5
ip sla schedule 7 life forever start-time now

그리고 'IP SLA 7'이 ICMP Check에 실패하여 VPN과 워크그룹 스위치 간의 연결이 다운되었음을 확인하고 트리거가 발생하면 '5.5.5.x/24'에 대한 스태틱 라우팅(AD 1)을 삭제하여 EIGRP(AD 90)을 통해 라우팅이 이루어지도록 합니다.

event manager applet LINK_DOWN
 event track 10 state down
 action 1 syslog msg "Internal Link Fail"
 action 2 cli command "enable"
 action 3 cli command "conf t"
 action 4 cli command "no ip route 5.5.5.0 255.255.255.0 1.1.1.2"
!
event manager applet LINK_UP
 event track 10 state up
 action 1 syslog msg "Internal Link Success"
 action 2 cli command "enable"
 action 3 cli command "conf t"
 action 4 cli command "ip route 5.5.5.0 255.255.255.0 1.1.1.2"

위 설정에 대한 해석은 다음과 같습니다. 한 개의 'Event Track 10'(이하 이벤트 트랙)으로 이루어진 2개의 이벤트 매니저를 확인할 수 있습니다. 이벤트 트랙의 State(이하 상태)는 any, up, down으로 이루어지며 상태에 따라 맞는 applet을 실행할 수 있습니다. 하나는 'LINK DOWN(링크 다운)'시 실시할 명령어의 집합(Applet)이고 하나는 'LINK UP(링크 업)'시 실시할 명령어의 집합(Applet)입니다. IP SLA에서 ICMP Check를 실패할 경우 트리거가 발생하며 위 이벤트를 실행하게 됩니다. 실행을 위해 'IP SLA 7'과 'Event Track 10'을 이어줍니다.

track 10 rtr 7 reachability

완성된 모습은 다음과 같습니다.

track 10 rtr 7 reachability
!
ip sla 7
 icmp-echo 1.1.1.2
 frequency 5
ip sla schedule 7 life forever start-time now
!
event manager applet LINK_DOWN
 event track 10
 state down
 action 1 syslog msg "Internal Link Fail"
 action 2 cli command "enable"
 action 3 cli command "conf t"
 action 4 cli command "no ip route 5.5.5.0 255.255.255.0 1.1.1.2"
!
event manager applet LINK_UP
 event track 10
 state up
 action 1 syslog msg "Internal Link Success"
 action 2 cli command "enable"
 action 3 cli command "conf t"
 action 4 cli command "ip route 5.5.5.0 255.255.255.0 1.1.1.2"

VPN과 워크그룹 스위치 간의 링크가 단절되지 않았을 때 라우터의 라우팅을 확인하면 '5.5.5.2/24'에 대한 Next Hop은 아래와 같이 VPN이 됩니다.

<5.5.5.x/2에 대한 Next Hop은 VPN>

VPN과 워크그룹 스위치 간의 링크가 단절되었을 때, 로그를 발생시키며 '5.5.5.2/24'에 대한 스태틱 라우팅을 삭제하고 '5.5.5.2/24'에 대한 라우팅은 EIGRP에 의해 광고되어 Next Hop이 본사의 'HeadQuarter_Router(2.2.2.1/30)'로 변경되며 문제없이 통신이 가능해집니다.

<EIGRP에 의해 광고되는 라우팅>

 

참고한 링크

지기님의 zigispace.net/473 : 이 곳을 가장 많이 참고했으며 설정 방식 또한 동일합니다. 설명이 잘 되어있습니다.

Cisco 러닝네트워크 : learningnetwork.cisco.com/s/blogs/a0D3i000002SKN0EAO/ip-sla-fundamentals

Cisco IP SLA 기술 문서 : www.cisco.com/c/ko_kr/support/docs/ip/ip-routing/200785-ISP-Failover-with-default-routes-using-I.html

Cisco EEM 기술 문서 : www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/ios-embedded-event-manager-eem/datasheet_c78-692254.html