IP SLA

IP SLA?

라우터는 자신과 직접적으로 붙어 있는 노드의 통신 단절은 감지할 수 있지만 그 이상의 노드의 사고는 감지하지 못 합니다. 따라서 이에 대응하기 위해 등장한게 IP SLA 입니다. 간단하게 말해서 직접적으로 연결되어 있는 노드 이외 이상의 노드 간의 상태 이상을 감지하기 위해 존재하는 방법으로 일정 주기마다 노드에 서비스를 요청하고 응답을 확인하면서 링크가 정상 동작하는지 확인함으로써 네트워크 상에 있을 수 있는 통신 오류에 대해 빠르게 대응할 수 있도록 합니다.

따라서 IP SLA를 이용하게 되면 종단간 통신에서 발생하는 사고를 알아차리고 라우팅 경로를 변경하는 식의 고가용성 설정에 이용할 수 있고 네트워크 관리가 가능해집니다.

작업(operation)

작업이란?

IP sla를 이용하여 수행하는 네트워크 상태 측정을 작업(operation)이라고 함

작업에 사용할 수 있는 값들

ping , RTP, tcp , udp, dns, dhcp, http, ftp

사용 범위

1. 단대단 네트워크 도달 가능성 및 성능 모니터링
2. Voip,video 와 VPN 모니터링
3. MPLS 네트워크 모니터링
4. 네트워크 동작 트러블슈팅

측정값

1. 네트워크 지연시간(latency)과 응답시간(response time)
2. 패킷 로스
3. 네트워크 지터(jitter) 와 voice quality scoring
4. 단대단 네트워크 연결성

설정법

💡 ip sla를 통해 모니터링 할때 연결하려는 서버, ISP를 지정하는 것이 일반적임, 실습에선 next hop을 선택할 수 있으나 의미 없는 행동

이번 포스팅에서는 IP SLA를 이용한 정적 라우팅에 대한 고가용성 설정을 해보도록 하겠습니다. 

IOSv1에 2개의 일반적인 디폴트 라우팅을 구성해보았습니다, 다른 AD 값을 주어서 210.110.10.1로 라우팅 되도록 구성 했습니다. 위와 같이 구성하면 210.110.10.1로 라우팅 하다가 사고 발생시 210.110.20.1 로 라우팅 되게 됩니다. 

라우팅 테이블을 확인하면 210.110.10.1로 라우팅 되는 것을 알 수 있습니다.

210.110.10.1의 인더페이스를 차단합니다.

IOSv1의 라우팅 테이블은 변경되지 않습니다. 이는 라우터가 결과적으로 자신의 인터페이스가 죽는게 아닌 이상 라우팅 테이블을 교체하지 않기 때문입니다. 

놀랍게도 라우터의 인터페이스가 죽어야지만 라우팅 경로가 변경됩니다. 실제로 이러한 구성은 라우터 장비에 문제가 있을땐 간단하고 효과적으로 작동하겠지만, 라우터의 문제가 아닌 다른 경로 상의 문제가 발생했을때 라우팅 테이블을 갱신하지 않는 다는 것을 알 수 있습니다.

가장 기초적인 구성 예시

ip sla [num] 
icmp-echo [target IP] 
// target-ip로 icmp-echo를 보내라

frequency 5 
 // 5초 간격으로 실행하라 default는 60초
 
ip sla schedule [num] life forever start-time now 
// sla 1을 시작해라 지금부터 당장 영원히  

track [num] ip sla [num] reachability
// sla 1을 track 1로 지정하고 도달할 수 있는지 상태를 감지한다

show ip sla monitor statistics 
// 명령어 통해 frequency 상태 확인

show ip sla configuration [num] 
// sla 설정 확인

ip route 0.0.0.0 0.0.0.0 [destination address] track 1​

 

마지막으로 생성한 track을 라우팅 테이블에 연결해줍니다. 

라우팅했던 종단 장치의 인터페이스를 차단해봅니다.

ip sla의 로그가 보이고 라우팅 테이블이 변경됩니다. 다시 해당 라우터의 인터페이스를 연결하면 원래의 라우팅 테이블로 교체되는 것을 볼 수 있습니다.

아래 시스코의 공식 문서를 참조하면서 보셔도 좋을 것 같습니다. 

IP SLA 추적을 사용하는 기본 경로를 사용하는 ISP 장애 조치