차노 블로그

RIP은 Bellman-Ford algorithm을 사용하는 알고리즘 입니다. 네이버간의  routing update 를 통해서 라우팅 정보를 서로 교환합니다. 이러한 업데이트 정보는 distance와 vector를 포함하고 있어  RIP 을 디스턴스벡터 프로토콜 이라고 부르기도 합니다. 또한 RIP은 IGP(Inter Gatawa Protocol)이기도 합니다. 왜냐면 AS 안에서 돌아가기 때문이죠. 1970년대 Xerox사의 PARC에서 사용할려고 개발되었고 최초의 디스턴스벡터 프로토콜입니다. RIP에 대해 좀 더 자세히 알아봅시다~

 RIP의 기능

 아주 가벼운 라우팅 프로토콜 입니다.   기본적인 머신? 부터 아주 복잡한 인터넷 라우터에서도 사용됩니다.
 - 네이버에게 메시지를 보내기위해 UDP 520번 포트를 사용합니다. UDP프로토롤을 사용하기 때문에 네이버가 메시지를 잘
   받았는지 신경안씁니다
 - 네이버들과 주고받는 패킷안에는 네트워크 주소와 그와 관련된 metric , hop count 등을 포함합니다.
 - metric(hop count) 은 소스 업데이트로부터의 거리를 의미하고, 각각의 hop에는 값이 할당이 됩니다. 이 값은 기본적으로
   1이 할당이 되고 이 값은 변경 할 수 있습니다.
 - RIPv1 에서는 브로드케스트로 메시지를 보냈습니다. 그래서 동일 네트워크에 있는 모든 라우터 뿐만 아니라 호스트 이외
    message 가 필요없는 장비들에게 까지 메시지가 전달됩니다.
 - 네트워크 토폴로지가 변경되었을 경우를 대비해서 30초 마다 계속 routing update message를 전송합니다.
 - metric 값에 제한을 두어서 routing loop 를 방지합니다.

infinity metric
routing loops 를 방지하기위해서 metric값의 제한을 두기 때문에 큰 네트워크에서는 사용이 불가능 합니다. 예를 들어 최대 메트릭 값이 15 라면 16이상의 경로는 도달할 수 없는 경로(infinity metric)로 인식하게 됩니다.

RIP의 동작

RIP 의 기본적인 내용을 알아보았으니 이제부터 동작방식에 대해 알아봅시다.

Input  Processing
  RIP은 네이버들로부터 두가지 유형의 메지시( request message, response message)를 받습니다.

 request message
  - RIP라우터들은 request message를 자신들의 네이버로부터 받습니다. request message의 목적은 네이버들의 라우팅
    테이블에서 전체 혹은 일부분의 라우팅 정보를 받기위함 입니다. 
  - request message는 장비가 부팅될때나 라우팅 프로토콜이 restart될 때 입니다. 이러한 상황에서 RIP라우터는 자신이
    가지고 있는 라우팅 정보를 전파하기 위해서 request message 를 보냅니다.
- RIP 라우터들은 request message 를 entry 단위로 처리합니다. request message 가 single entry 이고 metric 값이 16,
   address family identifier 필드가 모두 0으로 되어 있다면 라우팅 테이블 전체를 보내달라는 의미 입니다.
 - 하나의 request message에는 하나 이상의 라우팅 정보가 포함되어 있습니다. 이런 경우에 로컬라우터는 각각의 목적지
   별로 라우팅 테이블을 찾아봅니다. 목적지가 라우팅 테이블에 있으면 찾아낸 라우팅 정보를 유니케스트로 요청한 라우터에
   게 response message 에 담아서 보냅니다. 목적지가 라우팅 테이블에 없다면 metric field를 16으로 설정한 후 요청한 
   라우터에게 response message  를 보내면 이를 받은 라우터는 이 경로를 도달 불가능으로 인식합니다.

 response message
  RIP 라우터들은 보통 3가지 이유로 response message 를 받습니다.
   - 로컬라우터로부터 받은 request message 에 대한 응답
   - 네이버로부터 받은  regular response message
   - 네이버로부터 받은 triggered update response message 
     
   response message를 받은 로컬라우터가 첫번째로 수행하는 것은 특정 field 를 검사하는 것 입니다. 예를들어,
   수신받은 message 가 유효한 RIP라우터에게서 받은 메시지인가? , 수신받은 update message 의 source address가
   다이렉트로 연결된 네트워크인가? 등등...  이러한 질문들의 대답이  yes라면  message는  ACCEPT 된다.
   몇몇의 유효성 체크는 update를 reject하게 된다. 예를들어, 로컬라우터인터페이스로 부터 받은 패킷인가? 하는 쓸대없는
   질문에는 response message 를 만들 필요가 없기 때문이다.
   route entries는 하나씩 처리됩니다.  뭔말인가 하면은 각각의 entry는 유효성 검사를 받는다는 말씀. 예들들어 update
   message를 보낼 목적지 주소가 유효한가?,  메트릭값이 1 ~ 16 사이의 값인가?  과 같은 유효성 검사를 받는다.
   유효성검사를 받은 entry는 message를 받은 인터페이스의 cost값 만큼  metric 값을 더합니다.  보통의 경우 인터페이스의
   cost값은 1로 설정되어 있습니다. metric값이 범위를 벗어나면 자동으로 16으로 설정되고 이는 도달불가를 의미합니다.
   이때 로컬라우터는 목적지로가는 명시적으로 선언된 경로가 있는지 찾아보게 되고 만약 없다면 유효성검사를 마친 경로를
   라우팅 테이블에 추가하게 됩니다. (infinity metric제외)  명시적으로 선언된 경로가 존재한다면 next-hop address를 체크
   합니다.
   next-hop이 자신의 라우팅테이블에 있는 것과 동일하면 로컬라우터는 timeout timer를 초기화 하고 두 경로
   (라우팅테이블에 있는 경로와 response message로 받은 경로)의 metric값을 비교합니다.
   만약 두 값이 같거나 새로 받은 경로의 metric값이 더 큰 경우 라우팅테이블에 있던 경로는 남게되고 새로 들어온 경로
   값의 처리는 중단합니다.
   새로 받은 경로의 metric값이 작은 경우 기존 테이블에 있던 경로는 지워지고 새로 받은 경로가 라우팅 테이블에 복사
   (metric값도 같이 복사) 되고 네이버들에게  triggered update를 보냅니다. 
   새로 받은 경로의  metric 값이 infinity metric 이라면 로컬라우터는 라우팅테이블에 있던 경로를 삭제합니다.

Output processing
 RIP라우터들은 다음의 경우에 response message를 네이버들에게 보냅니다.
  - request message의 처리
  - update timer ( 30초 ) 가 만기된 경우.
  - 네트워크 토폴로지가 변경된 경우

 response message를 처리하기 전에 라우팅 테이블에 있는 경로들을 검사합니다. local administrative controls 때문에      
 response message에 라우팅 테이블에 있는 경로들이 포함되어야 한다면, 포함되어야 할 경로의 metric값과 목적지주소가
 resoponse message에 추가됩니다. 왜냐하면 RIP 패킷은 크기제한이 있기때문에 한번에 25개 이상의 entry 나 경로가 
 포함 될 수 없기 때문입니다. 만약 message 가 25개 이상의 경로가 포함된다면 여러개의 패킷으로 나눠 보냅니다.

Stability Features

 RIP protocol은 안정성 향상을 위해  몇가지 기능들을 사용합니다. 이러한 기능들은 모두 network convergence time 을
 최소화 하기 위해서 사용됩니다. 
  
  Split Horizon
    - 만약 A라우터가 B라우터로  자신이 가지고 있는 모든 경로가 들어있는 update를 보냈다면 B라우터는 A라우터에게 
      똑같은 내용을 update 할 필요가 있을까? 당연히 없을 뿐더러 이것은 네트워크 대역폭을 차지한다. Split Horizon은
      이러한 문제점을 해결한다. 라우터 update timer가 만기되고 response message가 생성될 때,   Split Horizon은 로컬
      라우터가 라우팅 정보를 보냈던 인터페이스로부터 똑같은 경로가  response message에 포함되는 것을 막는다.
      split horizon 은 routing loop을 막는 간단한 방법중에 하나이다.

Split Horizon with Poisoned Reverse
   - split horizon은 poisoned reverse와 함께 사용되면 네이버로부터 배운 경로를 광고 안하는 것 대신에 infinity metric으로
      광고를 합니다. 이렇게 되면 앞에 언급한 대로 네이버로부터 배운 경로를 광고 안하는 절차와 이에 필요한 정보들이 필요
       하지 않기 때문이다.

Triggered Updates
   - RIP라우터는 토폴로지가 변경 되었을때 regular update interval 이 발생할 때 까지 기다려하 한다. 이 방법은 비 효율적.
     triggered update를 사용하면 토폴로지가 변경되었을 때 regular update interval 이 발생 할 때 가지 기다리지 않고 바로
     자신의 네이버들에게 알린다. 각각의 downstream RIP 라우터들의 대부분은 바로 triggered update를 통해 다른 라우터
    들에게 전파한다.  모든라우터라고 하지 않고 거의 대부분의 라우터라고 말한 것은 각각의 라우터들은 triggered update를
    short timer 와 함께 수행 하고 이것은 triggered update가 즉시 수행되는 것을 막아준다. 라우터가  triggered update를 
    요청받았을 때 라우터는 short time동안 기다린다 (1초~5초) 그리고 기다리는 동안 들어온  updates 들 묶어서 모든
    네이버들에게 전송한다. 이렇게 되면 response message 처리시간이 줄어들게 되고  RIP 네트워크의 convergence 속도
    를 향상시킨다.

Hold-Downs
   - RIP에서 언급하는  hold-down이란 용어는 RFC에 명시되어 있지는 않지만 라우팅 동작에서 많이 사용합니다. hold-down
      을 사용하므로서 얻는 이점은 라우터가 불필요하거나 쓸모없는  라우팅 정보를 전파하지 않게 되는 것 입니다.
      로컬 라우터가 자신의 네이버로부터 받은 경로가 자신의 라우팅 테이블에 있는 정보보다 metric 값이 높거나 infinity
      metric 인 경우 또한 active 된 경로의 next-hop이 앞서 언급한 네이버 라면 hold-down timer 가 시작되고 새로운 정보
      (더 높은 metric 혹은 infinity metric) 가 나머지 네이버들로 바로 전송되어지지 않고 timer가 만료될 때 까지 기다린다. 
      hold-down은 triggered update 와 정반대의 효과를 낸다고 생각 할 수 있다. 왜나면 convergence 속도가 늦어지기
      때문이다. 그러나 이로인해서 필요한 라우팅 정보만 전파하게 되는 이점이 있다.


Timer
  RIP에서 사용하는 timer는 여러가지가 있다. update timer, hold-down timer, timeout timer, garbage collection timer

  Update timer
    - 완전한 라우팅 테이블을 광고하기 위해 사용한다. JUNOS 에서는 default 30초 
  Hold-down timer
   - 불필요한 라우팅 정보 전파를 방지하기 위해 사용한다. JUNOS에서는 default 180초 이고 변경이 불가능 하다.
  Timeout timer
   - 로컬 라우터로 부터 받은 라우팅 정보가 유효한지 사용가능한지 확인하기 위해서 사용한다.  경로가 처음 라우팅 테이블에
     등록되면 타이머는 120초(최대값)으로 초기화 된다. 타이머 값은  response message 를 받아서 처리할 때, 라우팅
     테이블에 있는 경로가 관리될때 업데이트 된다. 이때 timer는 120초로 reset된다.  update timer가 30초 이고 update
     message 를 4번 연속 못 받았을 경우에 해당 경로는 사용하지 못하는 경로가 된다. 이런 경우 해당 경로의 metric값은
     16이 되고 모든 네이버로 이 정보를 전달한다.
Garbage collector timer
   - 라우팅 테이블에서 특정 경로가 빠지면 테이블에서 완전히 삭제되어지는 것은 아니고 garbage collector timer값이 설정된
     시간만큼 남아있게 된다(이 때 timer 의 값이 0으로 초기화) timer 값이 180  가 되면 라우팅 테이블에서 해당 경로가 
     완전히 삭제된다.
   - garbage collector timer 와 timeout timer는 모든  down stream네이버가 해당 경로가 다운인지 도달불가능인지를 알 수
     있는 충분한 시간을 갖게 해준다.

Limitations
 지금까지 RIP 프로토콜에 대해 알아보았다. RIP은 몇가지 안정성을 위한 기능들을 포함하고 있고 표준 프로토콜 임에도 불구
  하고 많은 관리자들은 큰 네트워크에서  RIP 프로토롤을 사용하지 않는다. 왜냐하면  RIP은 제약사향이 많기 때문이다. 이런 
  제약사항을 알아보자.

    - Scalability
       RIP은 hop-count 제한 때문에 큰 네트워크에서 사용하지 못한다. 또한 RIP v1 에서  response update  message에
       사용하는 브로드케스팅 주소 255.255.255.255 때문이다. 이 주소는 다른 IP대역에 문제를 유발시킬 가능성이 있다.
    - Small hop count limit 
      16홉 이상은 infinity metric으로 정의되어 있기 때문에 도달할수 없거나 사용할 수 없는 서브넷으로 인식한다.
    - Slow convergence
       triggered update가 RIP의 광고시간을 줄여준다고는 하지만 RIP에서 사용되는 여러가지 timer는 네트워크 안의 가장
      멀리 떨어져 있는 라우터간의 라우팅 정보 교환하는데 몇분 이상의 시간을 필요하게 만든다.
    - Suboptional routing
       RIP은 라우팅 경로 계산을 위해 오로지 hop-count만을 사용하기 때문에  홉카운트가 더 적지만 빠른 경로가 있어도
       우회하지 못하고 느린 경로만을 사용한다.
    - Nonhierarchical design 
       네트워크 규모가 커질 수록 작은 관리도메인으로 나누는게 더 효율적이지만 큰 도메인을 작은 도메인으로 나눌 방법이
       RIP에는 존재하지 않는다. 
    - Classful routing protocol 
       RIP v1 은 클레스단위 라우팅 프로토콜이기때문에 두가지 형태의 서브넷 마스크중 하나만 사용이 가능하다. 하나는
       인터페이스에서 사용되는 서브넷 마스크이고, 나머지 하나는 classful network  서브넷 마스크( A,B, or C class )