Distance-Vector 라우팅 알고리즘의 문제점
- 디스턴스 벡터(Distance-Vector)에서 한 번 배운 라우팅 테이블을 계속 전달하기 때문에 컨버전스 타임(Convergence Time)이 오래 걸리고 루핑이 발생할 수 있다.
*Convergence Time : 네트워크에서 발생한 업데이트가 모든 네트워크에 전달되는 시간.
Distance-Vector 개념
① 라우터 A는 왼쪽 링크로부터 변화된 라우팅 테이블 즉, 업데이트를 받는다.
라우터 A는 그 변화(새로운 링크 발생, 링크 끊어짐 등)를 라우팅 테이블에 업데이트 할 것이다.
② 라우터 A가 업데이트한 라우팅 테이블을 디스턴스 벡터의 업데이트 시간(RIP은 30초)에 의해 라우터 B로 전달한다. 또, B에서 C로 30초 후에 전달할 것이다.
라우터 루핑(Router Looping)
① 라우터 A에 연결되어 있던 5.1.0.0 네트워크가 DOWN되었다. 즉시 자신의 라우팅 테이블을 업데이트 한다.
하지만, 아직 업데이트 주기(Distance-Vector, RIP은 30초)가 되지 않아 B와 C는 모른다.
이 때, 라우터 B가 라우팅 테이블을 업데이트 한다. (업데이트 주기가 더 빠르다고 가정)
② 라우터 A는 전달받은 네트워크 정보에서 5.1.0.0 네트워크를 라우터 B를 통해 갈 수 있는지 알고 Hop Count를 2로 변경한다.
③ 라우터 B가 라우터 A로부터 온 네트워크 5.1.0.0에 대한 정보를 보고 홉 카운트가 2로 바뀐 것을 안다.
라우터 B는 5.1.0.0 네트워크로 가려면 A를 거쳐서 가야된다는 것을 알기 때문에 Hop Count를 3으로 변경한다.
결국 라우터 C는 라우터 B로부터 전달 받은 라우팅 테이블을 보고 Hop Count를 4로 변경한다.
④ 라우팅 테이블은 루핑에 걸리고 죽어 있는 네트워크(5.1.0.0)로 향하는 데이터는 계속 돌기만 한다.
네트워크에 엄청난 트래픽을 발생시키고, 라우팅 테이블이 꼬여서 제대로된 라우팅을 수행할 수 없다.
결론
- 한 라우터가 라우팅 정보를 모두 알고 있지 못하고, 이웃 라우터로부터 업데이트가 느리게 이루어지기 때문에 루핑이 발생한다.
Distance-Vector 라우팅 알고리즘에서의 문제점 해결책
① Maximum Hop Count
ex) RIP에서는 최대 홉 카운트를 15로 규정한다.
- 홉 카운트가 15를 넘어가면 Unreachable로 간주하고 FlushTime이 넘어가면 라우팅 테이블에서 삭제시킨다.
- 장점 : 루핑이 발생하더라도 최대 홉 카운트를 넘어가면 멈출 수 있다.
- 단점 : 15홉을 넘어갈 때, 경로 도달이 불가능하기 때문에 규모가 크면 치명적이다.
② Hold Down Timer
- Hold Down Timer가 동작하고 있는 동안에는 외부에서 해당 네트워크에 대한 라우팅 경로 정보를 받았을 때, 원래 가지고 있던 Metric 값보다 큰 값이 들어오면 무조건 무시한다.
- 즉, Hold Down Timer가 종료되거나 목적지에 대한 새로운 경로가 가지고 있던 Metric 값과 같거나 좋은 경로일 때만 이웃 라우터로부터 업데이트를 받아들인다.
*Metric 값 : 목적지까지의 거리에 대한 값으로, RIP의 경우 Hop Count이다.
1. 라우터 E에 붙어 있는 네트워크 A가 Down된다. 라우터 E는 네트워크 .A가 Down되었다는 것을 라우터 A에 알린다.
이 때, 라우터 A는 네트워크 A에 대한 Hold Down Timer를 시작한다.
2. 만약 라우터 B가 라우팅 테이블을 업데이트하면서 라우터 A에
"네트워크 A는 나를 통해서 갈 수 있고, Hop Count는 4야"
라고 하면 무시한다.
- A가 가지고 있는 Metric 값보다 B가 준 Metric 값(4 Hop)이 작으면 무시한다. 게다가 Hold Down Timer도 동작 중이다.
3. 라우터 A가 B와 D쪽으로 업데이트를 하면, 이들도 Hold Down Timer를 작동시킨다.
4. C가 B나 D에 네트워크 A를 Hop count 3으로 갈 수 있다 하더라도, 그들이 가지고 있는 Network A에 대한 같거나 좋은 메트릭 값이 아니기 때문에 이 업데이트를 무시한다.
- 이로써 Hold Down Timger 동안 네트워크의 모든 라우터들이 네트워크 A가 다운되었다는 것을 인식한다.
5. 이러다가 Network A가 살아나면 라우터 A는 B와 D에 홉 카운트 1로 갈 수 있다고 업데이트하여 B와 D는 Hold Down Timer를 풀고 업데이트를 받아들인다.
③ Split Horizon
* 'show ip interface' 명령어로 Split Horizon이 Enable되었는지 확인할 수 있다.
1. 라우터 E는 라우터 A쪽으로 Network A에 대한 라우팅 정보를 매 주기마다 업데이트 한다.
2. 라우터 A는 라우터 E가 Network A에 대한 라우팅 정보를 보내주는 것에 대해 분명, 그 네트워크와 더 가까이 있을 것이라고 생각하고 Network A 라우팅 정보를 제외한 나머지 라우팅 정보만 업데이트 해준다.
- 라우팅 정보가 들어온 곳으로는 같은 정보를 보낼 수 없게 한다. 단, 같은 정보가 아닌 다른 정보는 업데이트 한다.
- 두 라우터 간 루핑만을 막기 위해 만들어진 기술이라서 전체 네트워크의 루핑을 막기는 힘들다.
④ Router Poisoning
1. 라우터 E는 네트워크 A가 다운되자마자 네트워크 A에 대한 Metric 값을 16으로 변경한다.
(즉, 사용할 수 없는 값 : 최대 홉이 15인데 16으로 초과 해버리기 때문에 Unreachable)
또, 라우팅 테이블에서 지워지지 않는다.
2. 라우터 A에서 네트워크 A에 대한 정보를 E로 업데이트 해줘도 라우터 E는 이를 무시하고 라우터 A에게 네트워크 A에 대한 Metric 값을 16으로 하여 보내주기 때문에 라우터 A도 네트워크 A에 대한 Metric 값이 16으로 바뀐다.
- 다운된 네트워크를 먼저 무한대치(∞)로 바꾸어 버리는 방식 (라우팅 테이블 극약처방)
- 즉, 라우팅 테이블에서 지워버렸다가 잘못된 라우팅 정보를 받는 일을 미리 막을 수 있다.
⑤ Poison Reverse
Split Horizon with poison reverse update
- 포이즌 리버스 업데이트를 사용한 스플릿 호라이즌
* 홉 개수 무한대 = 경로 사용 못함 = 해당 경로에 대한 업데이트 무시
1. 라우터 A는 라우터 E로부터 네트워크 A가 다운되었다는 업데이트를 받는다.
2. 라우터 A는 네트워크 A에 대한 Metric 값을 16홉(무한대, ∞ )으로 설정하여 라우터 E로 되돌려 보내준다.
(이 때, 라우팅 테이블에서 경로를 삭제하지는 않는다.)
- 경로의 정보를 없애는 것보다 무한대 홉 값을 포함해서 라우팅 업데이트를 실시하면 다른 모든 라우터들은 실수로 잘못된 경로 정보를 사용하는 경우를 줄일 수 있다.
- Split Horizon은 라우팅 정보를 보내준 쪽으로 알려주지 않는데, Poison Reverse는 라우팅 정보를 되돌려 보내기는 하되 이 값을 무한대로 쓰는 방식이다.
결론
※ Split Horizon은 Poison Reverse 기능이 첨가되든지 또는 안되든지 라우팅 루프를 인접 라우터에서만 방지할 수 있다.
- 여러 가지 방식의 루핑 방지법을 적절히 잘 활용하는 것이 중요하다.
