네트워크 시뮬레이션 공방

Destination only flag 정보는 RREQ 메시지("AODV 메시지(2) - RREQ 구조체" 참조)에서 사용되며, RREQ에 대한 응답을 중간 노드에서 대신 처리할지의 여부를 알린다[1]. 다음 그림은 사용자가 Destination only flag사용 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

설정 가능한 값은 Enabled와 Disabled이다.

- Enabled : 목적지 노드만 RREQ에 대한 응답 RREP를 생성함.
- Disabed : 목적지 노드뿐만 아니라 경로상 목적지 노드 이전에 위치한 중간 노드도 RREQ에 대한 응답 RREP를 생성할 수 있음.

[1] RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", IETF, July 2003.

"라우팅 테이블과 포워딩 테이블"에서 살펴본 것처럼, 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