네트워크 시뮬레이션 공방

"라우팅 테이블과 포워딩 테이블"에서 살펴본 것처럼, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포위딩 테이블은 완전히 분리되어 별도로 저장된다. 하지만, "라우팅/포워딩 테이블 예제(1) - RIP"와 "라우팅/포워딩 테이블 예제(2) - OSPF"에서 살펴본 예제에서는 두 테이블에 저장되어 있는 정보의 내용은 동일하였다.
그러면, 두 테이블에는 항상 동일한 정보가 저장되는 것일까? 그렇지는 않다. 이제 또 다른 예제를 통해 라우팅 테이블과 포워딩 테이블에 서로 다른 정보가 저장될 수도 있음을 확인해보기로 하자. 다음은 "RIP 라우팅 예제"에서 사용한 시나리오를 수정하여 작성한 시험망 토폴로지이다.

Client <-> R1, R1 <-> R2, R2 <-> R4, R4 <-> Server 구간에는 RIP를 적용하였고, R1 <-> R3, R3 <-> R4 구간에는 OSPF를 적용하였다. 이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 RIP 라우팅 테이블, OSPF 라우팅 테이블, IP 포워딩 테이블을 비교하여 살펴보면 다음 그림과 같다.

R1 노드에는 RIP와 OSPF가 모두 실행되므로 RIP 라우팅 테이블과 OSPF 라우팅 테이블이 각각 만들어지며, IP 포워딩 테이블에는 RIP 라이팅 테이블 정보와 OSPF 라우팅 테이블 정보가 모두 취합되어 있는 것을 확인할 수 있다. (실제 망에서 라우팅 프로토콜을 이렇게 구성하는 경우는 거의 없을 것이라는 점에서 좋은 예제는 아니다. 하지만, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블의 관계를 이해하는데는 도움이 될 것이다.)

다음 그림은 Riverbed(OPNET) Modeler ICMP 모델에서 사용하는 패킷 포맷과 fields 필드에 실리는 정보를 나타낸 것이다.

ip_icmp 패킷은 ICMP 메시지를 위한 컨테이너 패킷이며, 실제 ICMP 메시지는 echo_packet 필드에 실린다. 어떤 ICMP 메시지가 실려있는지는 fields 필드에 실려있는 IpT_Icmp_Packet_Fields 구조체의 message_type 정보를 통해 구분할 수 있다. 이러한 구조는 다양한 ICMP 메시지들을 공통으로 사용하는 단일 ICMP 패킷을 통해 처리하기 위한 의도인 것으로 생각된다.
하지만, "ip_icmp 프로세스 모델"에서 살펴보았듯이 Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)에서는 ICMP 메시지들[1, 2]중 Echo/Echo Reply 메시지만 사용되므로, 실제적으로는 이 구조가 특별한 의미를 가지지 못하고 사용자들에게 혼란을 주는 면이 있다.

[1] RFC 792, "Internet Control Message Protocol", IETF, 1981. 
[2] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

GRP에서 backtrack 기능("GRP Backtrack" 참조)이 어떻게 동작하는지 예제를 통해 살펴보도록 하자. 다음은 backtrack 동작을 살펴보기 위한 예제망 구조이다. 쿼드런트("GRP 쿼드런트" 참조) 크기는 2Km로 설정하였으며, 트래픽은 STA_1 노드에서 STA_16 노드로 향하도록 하였다.

시뮬레이션을 수행한 후 데이터 패킷이 전달된 경로를 확인("GRP 라우팅 경로 확인하기" 참조)해보면 다음 그림과 같이 STA_1 -> STA_2 -> STA_5 -> STA_7 -> STA_13 -> STA_16 경로가 사용되었다.

그런데, ODB를 사용하여 데이터 패킷이 각 노드를 거쳐 전달되는 과정을 자세하게 추적해보면, 실제로는 다음 그림과 같이 STA_1 -> STA_4 -> STA_1 -> STA_2 -> STA_4 -> STA_2 -> STA_5 -> STA_7 -> STA_13 -> STA_16 경로를 거쳤음을 보여준다.

여기에서 STA_4 노드에서 STA_1 노드로, STA_4 노드에서 STA_2 노드로 되돌려진 과정이 바로 backtrack이다. 그러면, 왜 이렇게 backtrack이 발생한 것일까? 그 이유는 목적지 쿼드런트와의 거리계산 방식("GRP 쿼드런트와의 거리 계산" 참조)때문이다. 다음 그림은 이를 확인하기 위하여 STA_1 노드에 구성된 목적지 테이블을 분석한 결과를 토폴로지상에 표시한 것이다.

이제 이 쿼드런트 정보를 사용하여 각 단계별로 다음 홉이 선정된 이유를 살펴기로 하자.

(1) STA_1 -> STA_4 : 목적지 노드인 STA_16은 쿼드런트 B에 속해있으며, STA_1 노드의 이웃 노드인 STA_2, STA_3, STA_4 노드중 쿼드런트 B와의 거리가 가장 가까운 노드는 STA_4 노드이므로("GRP 쿼드런트와의 거리
계산" 참조), 데이터 패킷은 STA_4 노드로 전달된다.

(2) STA_4 -> STA_1 : STA_4 노드에서는 자신보다 쿼드런트 B에 더 가까운 이웃 노드를 찾을 수 없으므로, 이전 노드인 STA_1 노드로 패킷을 되돌림(backtrack)한다("GRP Backtrack" 참조).

(3) STA_1 -> STA_2 : STA_1 노드에서는 backtrack된 경로를 제외하고 쿼드런트 B에 가장 가까운 노드인 STA_2 노드로 데이터 패킷을 전달한다.

(4) STA_2 -> STA_4 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 쿼드런트 B와의 거리가 가장 가까운 노드는 STA_4 노드이므로, 데이터 패킷을 STA_4 노드로 전달한다.

(5) STA_4 -> STA_2 : STA_4 노드에서는 자신보다 쿼드런트 B에 더 가까운 이웃 노드를 찾을 수 없으므로, 이전 노드인 STA_2 노드로 패킷을 되돌림(backtrack)한다.

(6) STA_2 -> STA_5 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 쿼드런트 B와의 거리가 자신보다 가까운 STA_5 노드로 데이터 패킷을 전달한다.

(7) STA_5 -> STA_7 : STA_5 노드의 이웃 노드인 STA_2, STA_6, STA_7, STA_8 노드중 쿼드런트 B와의 거리가 가장 가까운 노드인 STA_7 노드로 데이터 패킷을 전달한다.

(8) STA_7 -> STA_13 : STA_7 노드의 이웃 노드인 STA_5, STA_8, STA_13 노드중 STA_13 노드가 목적지 쿼드런트에 위치하므로, STA_13 노드로 데이터 패킷을 전송한다.

(9) STA_13 -> STA 16 : STA_13 노드의 이웃 노드중에 목적지 노드인 STA_16 노드가 있으므로, STA_16 노드로 데이터 패킷을 전송한다.