RIP

From IT Wiki

Routing Information Protocol

거리벡터 알고리즘에 기초하여 개발된 라우팅 프로토콜

역사[edit | edit source]

  • 1970년대 : 제록스社 팔로알토연구소(PARC)의 XNS(Xerox Network System) 프로토콜 군의 일부로써 GWINFO(게이트웨이 정보 프로토콜)를 개발
  • 1980년대 : Berkeley UNIX BDS 4.2에서 Routed Daemon 으로 개발됨
    • 1982년 버클리 UNIX 배포판인 BSD 4.2에 routed 데몬 프로그램 포함 배포됨
    • 1988년   : RIPv1 (RFC 1058)
  • 1994년   : RIPv2 (RFC 1723)
  • 1997년   : RIPng (RFC 2080)

특징[edit | edit source]

  • 거리벡터 라우팅 프로토콜 임 / 벨만-포드 알고리즘(Bellman-Ford)
  • 라우팅 메트릭 으로 Hop Count (홉 수) 만 사용
  • 경로비용을 단지 홉 수로 만 판단
    • 속도나 거리 지연 등을 고려하지 않아 최적의 경로 산정에 비효율적
  • 최대 홉 수의 제한
    • 최대 15 홉 수(16은 무한대)로 제한
    • 홉(hop)수는 라우터를 통과할 때 마다 1 씩 증가하게 됨
  • UDP 세그먼트에 캡슐화되어 사용
    • RIP 메세지 송수신용 UDP 포트
      • RIPv1,RIPv2 : UDP 포트번호 520
      • RIPng: UDP 포트번호 521

UDP 세그먼트에 캡슐화된 RIP 메시지.jpg

  • Classful Routing 수행
    • Subnetwork 정보가 아닌 Class 형태의 라우팅 정보 만을 전달함으로써 라우팅 정보 전달량이 많음
    • 단, RIPv2 는 라우팅 업데이트 정보에 서브넷 마스크 정보를 포함하여 VLSM 지원
  • 주기적인 라우팅 업데이트
    • 매 30초 마다 RIP 응답메세지(RIP 패킷)를 브로드캐스팅 함
      • 이때, 목적지 IP 주소를 255.255.255.255 (브로드캐스트 주소)로써 사용
    • 상대에게서 수신된 네트워크 정보를 제외한 모든 네트워크 정보를 상대에게 알려줌
    • 수신 라우터는 자신의 라우팅 테이블을 재작성하도록 함
      • 단, 네트워크 경로 항목에서 더 짧은 홉 수를 수신 받았을 때 만 해당 라우팅 경로 항목을 교체함

RIP 타이머[edit | edit source]

  • Update 타이머: 30초
    • 라우팅 테이블 전체를 브로드캐스트 또는 멀티캐스트 방식으로 송출
  • Timeout 타이머: 180초
    • 라우팅 테이블에 있는 매 경로 마다 만료(Timeout) 타이머를 둠
    • 업데이트 정보(RIP 응답메세지)에 해당 경로가 있으면 만료 타이머를 초기화하고, 만료 타이머 종료시까지 해당 경로가 없으면 도착 불가능(16,무한)으로 표시
  • Garbage Collection 타이머: 120초  (Garbage Collection Timer)
    • 도착불가능 16(무한)으로 표시하고 주변에 알리며, 즉각 삭제 유예하는 시간
  • Flush 타이머: 240초
    • 업데이트 없는 경로에 대해서는 라우팅 테이블에서 해당 경로를 제거
  • Triggered Update (트리거 갱신)
    • 토폴로지 변화시 업데이트 타이머 종료전이라도 즉각 라우팅 업데이트 정보 송출

RIP의 문제점과 해결 방안[edit | edit source]

문제점[edit | edit source]

  • Slow Convergence (늦은 수렴성)
    • 라우터들끼리 주기적으로(30초 간격) 경로 업데이트를 하며 경로 재계산함에 따라 몇 개 라우터 만 지나도 수분 이상 걸림
  • 라우팅 트래픽 부하
    • 전체 경로를 담은 라우팅 테이블을 주기적으로 보로드캐스트함에 따라 network에 이에따른 traffic 부하를 줌
  • 라우팅 루프
    • 전 라우터들 사이에 동기화를 시켜주지 않으면 패킷의 경로가 부적절하게될 수 있음
    • 매 30초 마다 업데이트되는 까닭에 다운(Down) 등의 나쁜 소식이 늦게 전달되어 잘못된 경로로 무한 루프(Infinite Loop)를 도는 사태 발생
  • Count-to-Infinity Problem  
    • 느린 수렴 시간 때문에, 나쁜 경로를 다른 라우터에게 전하면 그 라우터는 더 느리게 더 나쁜 정보로써 다른 라우터에게 전하게되면서 결국 무한(16) 홉 수로 가는 현상

해결 방안[edit | edit source]

  • 최대 홉 수의 제한
  • Triggered Update
  • Holddown Timer
  • Split Horizon
  • Poison/Poison Reverse 등

참고 문헌[edit | edit source]

  • 정보통신기술용어해설