RIP (Routing Informartion Protocol) 은 AS 내에서 라우팅을 수행하는 IGP 중 하나이다.
RIP 는 목적지로 도착하기 까지 홉 수 정보를 저장하고 인접 라우터와 정보를 공유하는 방법이다.
즉, 라우팅 관련 정보를 자동으로 주기적으로 공유하는 방법이다.
RIP 는 벨만이 제안한 거리 벡터 알고리즘에 기초하여 "Bellman-Ford Protocol" 이라고도 불린다.
(** 홉수 : 목적지로 도착하기 까지 거쳐야 하는 링크 혹인 라우터의 수)
홉수를 포함한 라우팅 정보를 일반적으로 30초마다 갱신한다.
120초 동안 정보를 받지 못하면 경로 단절로 판단한다.
그리고 단절된 경우 홉 수를 무한으로 표시한다.
또 다른 표현으로는 무한을 16으로 표현하기도 한다.
RIP 는 UDP 520번 포트를 사용한다.
RIP 라우팅의 알고리즘을 살펴보자
위와 같이 192.168.10.0 ~ 192.168.40.0 까지 네트워크 대역이 있다고 해보자.
각 네트워크의 이름은 Network A 부터 Network D 까지 설정되어 있다.
그리고 각 네트워크 사이에 라우터 1 부터 라우터 3까지가 연결되어 있다.
라우터 1의 초기설정을 보면 라우터 1과 연결된 네트워크는 Network A 와 Network B 이다.
라우팅 테이블의 초기에는 인접한 네트워크를 등록하며, 라우터1과 인접한 네트워크는 192.168.10.0 과 192.168.20.0 이다.
홉수가 0 으로 표시되어 있는데 이는 직접 접속되어 있는 네트워크의 홉수는 카운팅 하지 않으므로 0으로 표시한다.
라우터 2 , 3 도 이와 같은 방법으로 정보를 테이블에 등록한다.
위에서 라우팅 정보를 일반적으로 30초 마다 갱신한다고 하였다.
30초 후 라우팅 테이블의 정보는 아래와 정보가 갱신된 모습을 볼 수 있다.
라우팅1 의 라우팅 테이블에 추가된 정보는 같은 네트워크 대역에 접속해 있는
인접한 라우터2의 라우팅 테이블로부터 정보를 받아 갱신되어 있다.
(그림에는 빨간줄으로 특정 정보만 보내는 것처럼 보이지만 사실은 모든 정보를 보내는 것이다.)
기존 라우팅1의 라우팅 테이블은 Network A 와 Network B 의 정보만 저장되어 있었지만,
인접한 라우팅2의 테이블은 Network C 의 정보도 저장되어 있다.
이에 따라 라우팅2로부터 Network C 의 정보를 받아 해당 네트워크 ip addr 과 홉수가 1 로 추가된다.
마찬가지로 라우터 2 에서도 각각 인접한 라우터 1,3 으로부터 Network A 와 Network D 의 정보도 추가해준다.
여기서도 마찬가지로 최초 라우터를 제외하고 1개를 거쳤으므로 홉수는 +1 이 된다.
라우터 3 도 마찬가지로 인접한 라우터 2 에서 Netowrk B 의 정보를 가져와 라우팅 테이블에 등록하게 된다.
또 30초가 지났을때 즉 초가 지났을 경우에 라우팅 테이블은 아래와 같이 업데이트가 된다.
라우터 1의 라우팅 테이블은 라우터 2의 라우팅 테이블로 부터 Netowrk D 의 정보를 받아서 표시한다.
라우터 1 이 Network D 까지 가기 위해서는 S0 을 거쳐서 두번의 홉이 필요하므로 해당 정보를 기록한다.
라우터3도 라우터2의 라우팅 테이블에서 Network A 의 정보를 부여받았다.
라우터3 이 Network A 까지 가기 위해서는 S0 를 거쳐서 두번의 홉이 필요하므로 마찬가지로 홉 정보를 2로 표시해준다.
하지만 RIP 방식은 라우터 간 무한 루프가 발생한다는 문제점이 존재한다.
이는 느린 수렴(Slow Convergence) 현상으로 발생하는데, 라우팅 테이블의 정보가 30초 마다 변경되고,
링크에 문제가 생겼을 경우에 정보가 제대로 전달되지 않아 발행하는 현상이다.
만약에 Network A 의 경로가 단절되었을 경우에 홉수가 무한대로 변경되게 된다.
그러나 변경된 내용이 다른 라우터 까지 적용되는데 많은 시간이 소요되는 문제가 발생한다.
(30초 마다 정보를 전송하므로 오래걸릴 수 있음)
즉 경로가 단절된 상황이 느리게 전달되어서 모든 라우터가 변경 사항을 적용하는데 오랜 시간이 걸리는 문제가 발생한다.
이러한 느림 수렴 현상을 해결하기 위한 해결책으로 아래와 같이 4가지의 해결책이 존재한다.
1. 무한대 홉 수로 16을 사용
- 홉수가 15를 초과할 경우 무한대로 설정한다는 의미
- 경로가 단절되었을 경우에 변경되는 내용이 적용되는 시간을 단축할 수 있다.
2. Split-Horizon
- 전달하는 정보를 '구분'하여 전송하는 방식
- 상대방에게서 받은 라우팅 정보를 다시 상대방에게 보내지 않는다.
예를들어서 Network A 로 가는 경로가 단절되었을 경우에 라우터1 는 단절된 정보로 홉수를 무한으로 설정한다.
그리고 이 정보가 라우터2의 라우팅 테이블에도 전달되어 갱신되게 된다.
라우터2는 라우터1 에게 정보를 전달할 때 Network A 의 정보를 전달하지 않고 Network C 의 정보만 전달한다.
이로써 라우터2 는 오른쪽 인터페이스로 통하는 Network C 의 정보만 구분하여 전달함으로써
Network A 의 경로가 단절되었다는 정보를 보존한다.
3. Poison-Reverse
- 반대쪽 네트워크 메트릭 값을 무한으로 늘리는 방식
4. Triggered Update
- 변경 상황의 정보를 바로 전달하는 방식
- 일반적으로 라우팅 테이블의 정보를 30초마다 갱신하게 되는데, 이로 인한 방식은 느린수렴 문제를 발생시킬 수
있으므로 30초라는 시간 간격과 관계없이 바로 상황 정보를 전달하기 때문에 느린수렴 문제를 해결할 수 있다.
'네트워크' 카테고리의 다른 글
[네트워크] NAT (0) | 2022.09.29 |
---|---|
[네트워크] OSPF (0) | 2022.09.28 |
[네트워크] 라우팅 프로토콜 (0) | 2022.09.25 |
[네트워크] 라우터 (0) | 2022.09.23 |
[네트워크] IP 패킷, IP 헤더 (0) | 2022.09.22 |