RIP 편집하기

'''Routing Information Protocol'''

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

* [[내부 라우팅 프로토콜|내부 라우팅 프로토콜 중 하나(IGP, Interior Gateway Protocol)]]
* 소규모 또는 교육용 등 비교적 간단한 네트워크에 주로 사용됨

== 역사 ==

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

== 특징 ==

* 거리벡터 라우팅 프로토콜 임
* 라우팅 메트릭 으로 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 타이머 ==

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

== RIP의 문제점과 해결 방안 ==

=== 문제점 ===

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

=== 해결 방안 ===

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

== 참고 문헌 ==

* 정보통신기술용어해설