네트워크 시뮬레이션 공방

Feasibility Condition은 DUAL 알고리즘의 일부로써, 루프를 방지하기 위한 것이다. 그런데, 사용자가 주의를 기울이지 않으면 이 기능으로 인한 결과는 혼란스러운 면이 있으므로, 결과 해석시 주의가 필요하다.

"다중경로 라우팅(8) - UCMP 라우팅 테이블"에서 EIGRP는 동일한 비용을 가지는 경로가 없을 때에도 다음 그림처럼 다중경로로 라우팅 테이블을 구성해줄 수 있음을 확인한 바 있다.

그런데, "다중경로 라우팅(8) - UCMP 라우팅 테이블"의 예제망에서 R1 <-> R3 링크의 대역폭과 R3 <-> R4 링크의 대역폭을 서로 바꾸고 시뮬레이션을 수행하면, 다음 그림처럼 라우팅 테이블에 다중경로가 구성되지 않는 것을 볼 수 있다.

얼핏 생각하면, R1 노드에서 Server 노드로 향하는 경로의 전체 Metric 값에는 변화가 없으므로(R1 <-> R3 링크와 R3 <-> R4 링크의 대역폭을 서로 바꾸기만 하였으므로) 이전의 예제와 동일한 라우팅 테이블이 구성되어야 할 것처럼 생각된다. 하지만, 시뮬레이션 결과는 예상(?)과는 다르며, 이러한 차이가 발생한 원인은 Feasibility Condition 때문이다.
즉, EIGRP에서는 전체 경로의 Metric이 동일하더라도 Next-Hop 라우터에서 목적지까지의 경로 Metric 값이 어떻게 변화하는가에 따라 다중경로가 라우팅 테이블에 사용될 수도 있고 안될 수도 있다.

OSPF 망에서 DR("OSPF DR(1) - 라우터 상태" 참조) 변경이 발생할 경우, 이웃 노드들은 Hello 패킷("OSPF 메시지(2) - Hello 패킷 정보 확인" 참조)을 통해 이를 알수 있다. DR 변경후 Hello 메시지 수신은 다음 2가지 경우가 존재한다.

1) 새로운 DR로 선출된 노드로부터의 Hello 패킷 수신: 이전에는 DR 노드가 아니었던 이웃이 자신을 DR로 선언함.2) 이전 DR 노드로부터의 Hello 패킷 수신: 이전에는 DR 노드였던 이웃이 자신이 DR이 아님을 선언함.

이러한 경우, NeighborChange 이벤트가 발생하고 이웃 노드들과의 관계("OSPF DR(3) - 이웃 상태" 참조) 변경 여부에 대한 점검이 숫행된다. 또한, NeighborChange 이벤트는 BDR 노드 변경시에도 동일하게 발생한다.

GRP에서 사용되는 쿼드런트의 기본 개념에 대해서는 "GRP 쿼드런트"에서 살펴본 바 있다. 이 쿼드런트는 또한 계층개념을 가지는데, 상위 계층 쿼드런트는 하위 계층 쿼드런트 4개로 구성된다. 따라서, 상위 계층 쿼드런트 한 변의 길이는 하위 계층 쿼드런트의 2배이다. 다음 그림은 이러한 쿼드런트의 계층 관계를 나타낸 것이다.

소스 노드(S)는 1번 노드의 위치를 Aa2 쿼드런트로 간주한다. 2번 노드의 위치는 한단계 상위인 Ab 쿼드런트로 간주하며, 3번 노드의 위치는 두단계 상위인 B 쿼드런트로 간주한다. 동일한 원리로 4번 노드의 위치는 D 쿼트런트로, 5번 노드와 6번 노드의 위치는 C 쿼드런트로 간주한다. 즉, 소스 노드에서 멀리 떨어진 노드일수록 더 상위 계층의 쿼드런트를 적용하며, 이 과정은 대상 노드의 쿼드런트가 결정될때까지 반복된다.
쿼드런트는 좌표계를 기준으로 결정되므로 시나리오상의 노드 배치를 보고 어느 노드가 어느 쿼드런트에 속할 것인지를 직관적으로 파악하기는 쉽지 않다("GRP 쿼드런트 예제" 참조). 더구나, 소스 노드에서 멀어질수록 더 큰 크기의 상위 계층 쿼드런트가 적용되므로, 어떤 노드들이 같은 쿼드런트에 속할 것인지를 직관적으로 파악하기는 더 어려워진다. 그 예로, 위 그림에서 4번 노드와 5번 노드는 서로 다른 쿼드런트로 간주되는 반면, 상대적으로 더 큰 거리를 가지는 5번 노드와 6번 노드는 같은 쿼드런트로 간주된다.