네트워크 시뮬레이션 공방

OPNET Modeler 16.1 버전은 2011년에 나왔으며, 주요 모델의 업데이트 내용은 당시에 살펴본 바 있습니다("OPNET Modeler 16.1 PL1 발표" 참조). 그런데, OPNET Modeler 16.1 버전에서는 이외에도 사용 환경상의 중요한 변화가 몇 가지 더 있었기에, 시간이 많이 지났지만 이 부분을 다시 한번 정리하고자 합니다.

1) 설치 디렉토리 변경 : 16.0 버전까지는 OPNET Modeler의 기본 설치 디렉토리가 "C:\Program Files\"이었는데(예: "C:\Program Files\OPNET\16.0.A"), 16.1 버전부터는 윈도우 Vista 이후의 윈도우 OS에 설치시 "C:\"로 변경되었습니다(예: "C:\OPNET\16.1.A"). 이는 사용자 권한 문제 때문인  것으로 생각됩니다. 윈도우 Vista나 윈도우 7에서는 UAC 기능때문에 "C:\Program Files\" 하나부의 파일에 접근시 관리자 권한이 필요하며, 이 때문에 OPNET 실행시 여러가지 문제를 일으켰기 때문입니다. 윈도우 XP에서는 계속 "C:\Program Files\"가 기본 설치 디렉토리로 사용됩니다.

2) OPNET 환경변수 설정파일 명칭 변경 : 16.0 버전까지는 OPNET 환경변수 파일명으로 "env_db버전명"이 사용되었는데(예: "env_db16.0"), 16.1 버전부터는 "opnet-버전명.prefs"로 변경되었습니다(예: "opnet-16-1.prefs"). 환경 변수 파일의 위치는 "사용자 계정\op_admin"으로 동일합니다.

3) MSVC 6.0 부분적 지원중단 : "OPNET Modeler 17.1 버전 Visual C/C++ 6.0 지원중단"에서 살펴본 것처럼, 16.1 버전의 LTE 모델에서는 MSVC 6.0을 지원하지 않습니다. MSVC 6.0을 사용하여 16.1 버전의 LTE 모델에 대한 컴파일을 시도하면 다음과 같은 에러들이 발생합니다.

=============================================================================================
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(3414) : warning C4761: integral size mismatch in argument; conversion supplied
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(7562) : warning C4761: integral size mismatch in argument; conversion supplied
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(8357) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(8359) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(9153) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
C:/Program Files/OPNET/16.1.A/models/std/lte/lte_ue_as.pr.c(9222) : error C2520: conversion from unsigned __int64 to double not implemented, use signed __int64
=============================================================================================
17.1 버전부터는 MSVC 6.0을 전혀 사용할 수 없게 됩니다.

Riverbed Modeler(OPNET) 시뮬레이션에서 IP 패킷들이 어떤 경로를 거쳐 전달되었는가를 다음의 방법들로 확인할 수 있다.
1) 라우터의 라우팅 테이블 확인(DES)
2) Demand Traffic Flow에 대한 라우팅 경로 표시(DES)
3) Demand Traffic Flow에 대한 라우팅 가능 경로 표시(Flow Analysis)
4) 두 노드간의 라우팅 가능 경로 표시(Flow Analysis)

라우터의 라우팅 테이블 확인은 DES 시뮬레이션 수행 후, 각 라우터의 IP Forwarding Table 정보를 보고 IP 패킷의 전달경로를 추론하는 방법이다. 가장 근본적인 방법으로 시뮬레이션에 사용한 트래픽의 종류에 상관없이 사용할 수 있다는 장점이 있다. 하지만, 개별 라우터에 기록된 Destination과 Next Hop Address 정보를 보고 사용자가 일일히 추적해야 하므로, 사용하기 어렵다는 단점이 있다. (특히, Auto Assign으로 IP 주소를 설정했을 경우 분석하기가 까다롭다.)

Demand Traffic Flow에 대한 라우팅 경로 표시는 DES 시뮬레이션 수행 후, ip_traffic_flow와 같은 Demand Traffic Flow에 선정된 라우팅 경로를 네트워크 토폴로지 상에 표시해주는 방법이다. 다음 그림처럼 라우팅 경로가 네트워크 토폴로지 상에 표시된다.

Demand Traffic Flow에 대한 라우팅 가능 경로 표시는 Flow Analysis 시뮬레이션 수행 후, ip_traffic_flow와 같은 Demand Traffic FLow에 선정 가능한 라우팅 경로들을 네트워크 토폴로지 상에 표시해주는 방법이다. 시뮬레이션에서 선택된 하나의 경로가 표시되는 것이 아니라, 선택 가능한 경로들이 표시되는 것이라는 점에 유의할 필요가 있다.

두 노드간의 라우팅 가능 경로 표시는 Flow Analysis 시뮬레이션 수행 후, 지정된 두 노드간에 선정 가능한 라우팅 경로들을 네트워크 토폴로지 상에 표시해주는 방법이다. 역시 시뮬레이션에서 선택된 하나의 경로가 표시되는 것이 아니라, 선택 가능한 경로들이 표시되는 것이라는 점에 유의할 필요가 있다.

OPNET Debugger를 사용하여 무선망에서 패킷 전송 애니메이션을 보는 방법에 대해서는 "무선망에서 패킷 전송 애니메이션 보기"에서 살펴보았다. 이 방법을 사용하면 이동중인 무선 노드와의 패킷 전송 애니메이션을 보는 것도 가능하다. (만약, 노드 이동에 대한 애니메이션만을 보고 싶다면 "패킷 전송 애니메이션 보기"에서 설명한 2-D Animation Viewer를 사용하여도 된다.)
다음 그림은 WiFi 단말간의 패킷 전송 애니메이션을 보기위한 예제망 구조를 나타낸 것이다.

무선 단말이 이동하여 거리가 멀어짐에 따라 패킷 전달이 이루어지지 못하는 과정을 관찰하기 위해서, Source 노드에서 Dest 노드로 전달하는 단방향 UDP 트래픽을 Custom Traffic으로 설정하였다.
OPNET Debugger의 Show Animation 기능을 이용하여 이 시나리오에 대한 패킷 전달 애니메이션을 살펴보면 다음 영상과 같다.

Source 노드와 거리가 가까울때에는 Dest 노드로 패킷이 전달되지만, Dest 노드가 이동하여 거리가 멀어지면 패킷이 전달되지 않는 것을 다음 그림처럼 쉽게 확인할 수 있다. Dest 노드가 더 이동하여 다시 Source 노드와의 거리가 가까워지면, 패킷 전달도 다시 이루어진다.

Riverbed Modeler(OPNET)에서 제공하는 모델을 사용하다 보면, 모델명에 'adv'라는 접미사가 붙어있는 모델과 붙어있지 않은 모델이 있다. (예: 'wlan_wkstn_adv' 노드 모델과 'wlan_wkstn' 노드 모델) 이 모델들간의 차이 점은 무엇인지 한번 살펴보자.

- 'adv' 접미사가 붙는 모델: 기본이 되는 모델로서, 모델 파일의 확장자가 '.m'으로 끝난다. (예: 'wlan_wkstn_adv.nd.m') 'adv'는 'Advanced'를 의미한다. 모델에 포함된 모든 파라미터를 사용할수 있다.

- 'int' 접미사가 붙는 모델: 기본 모델로부터 파생된(derived) 모델로서, 모델 파일의 확장자가 '.d'로 끝난다. (예: 'ethernet_wkstn_int.nd.d') 'int'는 Intermediate'를 위미한다. 모델의 일부 파라미터들이 사용자가 변경할 수 없도록 숨겨져 있다.

- 접미사가 붙지 않는 모델: 기본 모델(Advanced 모델) 또는 중간 파생 모델(Intermediate 모델)로부터 파생된 모델로서, 모델 파일의 확장자가 '.d'로 끝난다. (예: 'wlan_wkstn.nd.d') 모델의 일부 파라미터들이 사용자가 변경할 수 없도록 숨겨져 있다. Final 모델이라고도 한다.

Advanced, Intermediate, Final 모델간의 관계를 그림으로 표현하면 다음과 같다. 접미사 사용은 Riverbed Modeler(OPNET)에서 제공하는 모델들이 따라는 규칙일 뿐이며, 사용자가 신규 모델 개발시에 반드시 따라야만 하는 것은 아니다. (즉, 노드 모델을 새롭게 작성하였을 때에도, 'adv' 접미사를 붙이지 않아도 사용하는데 아무런 문제가 없다.)

즉, 'adv' 접미사가 붙는 모델(Advanced 모델)이 '진짜' 모델이며, 접미사가 없거나 'int' 접미사를 가진 모델은 Advanced 모델의 일부 파라미터 값들을 사전에 설정한 후 사용자가 변경할 수 없도록 막아놓은 파생 모델이다. 이렇게 하는 이유는 너무 많은 파라미터가 제공되면 사용자가 설정에 어려움을 느낄 수 있으므로, 전형적인 값으로 설정되는 파라미터들에 대해서는 사용자가 설정할 필요가 없도록 해주기 위함이다.
단, 이렇게 일부 파라미터가 숨겨짐으로 인해서, 특정 목적의 시뮬레이션시에는 해당 모델은 사용할 수 없는 경우가 있으므로 주의하여야 한다. 예를 들어 'wlan_wkstn' 노드 모델은 Custom 어플리케이션의 목적지 노드로 지정되지 않으므로, Custom 어플리케이션을 사용하고자 하는 경우 'wlan_wkstn' 노드 모델(Final 모델) 대신 'wlan_wkstn_adv' 노드 모델(Advanced 모델)을 사용하여야 한다.

"Riverbed Modeler 18.0 발표"에서 살펴본 것처럼, OPNET Modeler가 18.0 버전부터 Riverbed Modeler로 제품명이 변경되었다. 또한, 이름 변경과 더불어 로고와 심볼도 Riverbed 것으로 변경되었다.
다음 그림은 17.5 버전("OPNET Modeler 17.5 PL6 발표" 참조)의 메인 화면이며, 기존의 익숙하던 OPNET 로고와 심볼을 볼 수 있다.

다음 그림은 18.0 버전("Riverbed Modeler 18.0 발표" 참조)의 메인 화면이다. 로고는 모두 riverbed로 교체되었고, 기존의 OPNET 심볼도 더 이상 사용되지 않는다. OPNET이라는 이름이 역사속으로 사라졌음을 피부로 느낄 수 있는 증거인 셈이다.

UDP는 분할(segmentaiton) 및 재조립(reassembly) 기능을 제공하지 않으므로, UDP 패킷 크기를 초과하는 크기의 데이터는 전달할 수 없다. OPNET에도 이러한 UDP의 특성이 모델링되어 있어서, 일정 크기 이상의 데이터 패킷이 UDP로 전달되면, 패킷을 전송하지 않고 폐기한다. 따라서, 이 특성을 정확하게 이해하지 못하면, 사용자가 설정한 트래픽이 실제로는 시뮬레이션에 영향을 미치지 않을 수도 있으므로 주의하여야 한다.
다음 그림은 표준[1]에 정의된 UDP 패킷 구조를 나타낸 것이며, 2Bytes의 Length 필드로 표현할 수 있는 UDP 패킷의 최대 크기는 65,535Bytes이다. 따라서, UDP 패킷 헤더 8Bytes를 제외하면, UDP 페이로드의 최대 크기는 65,527Bytes가 된다.

Custom Application을 이용하면 다음 그림과 같이 Transport Protocol을 UDP로 손쉽게 변경할 수 있다(Custom Application을 이용하여 트래픽을 설정하는 방법은 "OPNET 기초다지기" 3.2.2절 예제 참조).

다음 그림은 Custom Application을 이용하여 65,527Bytes와 65,528Bytes 크기의 데이터 패킷을 0.1sec 간격으로 발생시켜 UDP를 통해 전송하려고 하였을 때 UDP 계층을 거쳐 전달되는 트래픽을 측정한 것이다. 65,527Bytes 크기의 데이터 패킷을 발생시켰을 때에는 트래픽이 잘 전달되는 반면, 65,528Bytes 크기의 데이터 패킷을 발생시켰을 때에는 트래픽이 전혀 전달되지 않는 것을 확인할 수 있다.

이렇게 사용자가 설정해준 트래픽이 실제로는 네트워크로 전혀 전달되지 않고 UDP 계층에서 폐기되지만, 이는 UDP의 정상적인 동작이므로 시뮬레이션 수행시 에러 메시지는 발생하지 않는다. 다만, 패킷 폐기시 WARNING 메시지를 남겨주므로, Log Viewer를 통해 확인할 수 있다.

[1] RFC 768, "User Datagram Protocol," IETF, 1980.

"OPNET 시뮬레이션 공방"에서 다루는 OPNET은 정확히는 OPNET Modeler를 의미합니다. OPNET사의 제품군에는 Modeler외에도 IT Guru, SP Guru나 APM이 있었습니다만, 회사 설립 초기에 Modeler를 주력으로 성장했기때문에 OPNET Modeler는 OPNET으로 통칭되었습니다. 이 블로그 이름을 "OPNET Modeler 시뮬레이션 공방"이 아니라 "OPNET 시뮬레이션 공방"으로 지은 이유도 이 때문이었습니다.
OPNET사는 2년전에 Riverbed사에 매각되었습니다만("OPNET, 리버베드에 인수됨" 참조), 그 이후로도 OPNET이라는 이름에는 변동이 없었고, OPNET Modeler에 대한 업데이트는 계속 이루어져왔습니다("OPNET Modeler/Release notes" 참조),
그런데, 최근 OPNET 이라는 명칭이 변경될 것 같다는 느낌이 듭니다. 다음은 Riverbed사 홈페이지의 제품 소개 화면을 오늘 캡춰한 것인데, Riverbed Modeler로만 소개되어 있을뿐 OPNET이라는 단어는 어디에도 없습니다.

OPNET이라는 단어가 사라진 Modeler 소개, 굉장히 낯서네요. 다음번 버전이 나와봐야 확실해질 것 같습니다만, 어쩌면 블로그 이름도 변경해야 할지도 모르겠네요. (하지만, "Riverbed Modeler"는 임팩트가 너무 약하군요)

OPNET 2-D Animation Viewer 기능을 이용하여 패킷 전송 애니메이션을 관찰하는 방법에 대해서는 "패킷 전송 애니메이션 보기"에서 살펴보았다. 그런데, 이 방법은 유선망에서만 사용할 수 있으며, 무선망에서는 아무런 결과도 관찰되지 않는다.
그러면, WiFi와 같은 무선망에서는 패킷 전송 애니메이션을 볼 수 없는 것일까? 이러한 요구는 OPNET Debugger의 Show Animation 기능을 이용하여 어느 정도 만족시킬 수 있다.
다음 그림은 WiFi 단말간의 패킷 전송 애니메이션을 보기위한 예제망 구조를 나타낸 것이다.

가장 간단한 패킷 전달 애니메이션을 보기 위해서, "패킷 전송 애니메이션 보기"에서와 마찬가지로 트래픽은 Source 노드에서 Dest 노드로 전달하는 단방향 UDP 트래픽을 Custom Traffic으로 설정하였다.
OPNET Debugger의 Show Animation 기능을 이용하여 이 시나리오에 대한 패킷 전달 애니메이션을 살펴보면 다음 영상과 같다.

Source 노드에서 가까이에 위치한 Dest 노드로는 패킷(애니메이션에서 표시되는 패킷은 WLAN 프레임이다)이 전달되지만, 먼 거리에 위치한 Dest_2 노드로는 패킷이 전달되지 않는 것을 다음 그림처럼 쉽게 확인할 수 있다.

Debugger 모드에서 관찰한 애니메이션 결과는 2D Animation Viewer 때와는 달리 별도의 파일로 저장되지 않으므로 애니메이션을 보기위해서는 항상 시뮬레이션을 새로 수행시켜야만 한다.

시뮬레이션을 수행하다보면, 언제 어디서 어디로 패킷이 전송되는지를 애니메이션으로 확인해보고 싶을 때가 있다. (애니메이션이 꼭 데모 관점에서만 필요한 것은 아니다. 디버깅 관점에서도 애니메이션 결과를 보는 것이 편리할 때가 있다.) 이럴 때 선택할 수 있는 가장 간단한 방법은 OPNET에서 제공하는 2D Animation 기능을 이용하는 것이다.
다음 그림은 Ethernet 단말간의 패킷 전송 애니메이션을 보기위한 예제망 구조를 나타낸 것이다.

가장 간단한 패킷 전달 애니메이션을 보기 위해서, 트래픽은 Source 노드에서 Dest 노드로 전달하는 단방향 UDP 트래픽(즉, Dest 노드에서 Source 노드로는 어떠한 패킷도 전달되지 않는다)을 Custom Traffic으로 설정하였다.
OPNET의 2-D Animation Viewer 기능을 이용하여 이 시나리오에 대한 패킷 전달 애니메이션을 살펴보면 다음 영상과 같다.

Source 노드에서 Dest 노드로 패킷(애니메이션에서 표시되는 패킷은 Ethernet 프레임이다)이 순차적으로 전달되고 있는 것을 다음 그림처럼 쉽게 확인할 수 있다.

OPNET에서 op_stat_write () 함수를 사용하여 시뮬레이션 결과값을 기록할 때, 바로 뒤에 '0' 값을 기록해주는 경우가 종종 있다. 이렇게 하는 것은 결과값을 해석하는데 상당히 큰 영향을 미칠 때가 있기 때문인데, 다수의 OPNET 사용자들이 그 차이를 잘 이해하지 못하고 있는 부분이기도 하다(덕분에 본인도 모르는 사이에 왜곡된 시뮬레이션 결과를 발표한 분들도 제법 있을 것으로 생각된다).
다음은 "OPNET 기초다지기"의 ARQ 예제에서 작성한 arq_sender 프로세스 모델의 Rcv_HL_Packet 스테이트의 일부분인데, 역시 send_pkt_sthandle Statistic handle에 결과값을 기록한 뒤에 즉시 '0'값을 기록해주는 것을 볼 수 있다.

왜 이렇게 '0'값을 같이 기록해주는 것일까? 대부분의 경우에 있어 그 이유는 bucket 방식의 캡춰 모드에서 시간당 결과값을 보다 정확하게 파악하기 위해서이다. 물론, 캡춰 모드와는 상관없이 '0'값을 같이 기록해줄 수도 있지만, 그렇게 사용하는 경우는 극히 드물다(결과 수집을 위한 캡춰 모드에 대해서는 이후에 별도의 글에서 다루도록 하겠다). 즉,  '0'값을 같이 기록해주는 것은 일반적으로 해당 결과(statistic)의 캡춰 모드가 bucket이고, bucket 모드는 sum/time인 경우이다.
다음 그림은 arq_sender 프로세서 모델의 send_pkt_sthandle Statistic handle에 '0'값을 같이 기록하지 않도록 수정한뒤, '0'값을 같이 기록되는 Traffic Generator 모듈의 Tranffic Sent (packet/sec) 결과값과 비교한 것이다. '0'값을 같이 기록하지 않는 arq_sender의 경우 순간순간의 정확한 값(빨간 선)을 보여주지 못하고 좀 더 평균화된 값(파란 선)을 보여주는 것을 알 수 있다.

이러한 차이는 하나의 statistic value가 표현하는 시간 간격을 축소시키면 더 확연하게 나타난다. 다음 그림은 위와 동일한 트래픽이 발생하는 경우에 대해서 하나의 statistic value가 1초의 시간 간격을 나타내도록 설정했을 때의 결과이다. '0'값을 같이 기록하지 않는 arq_sender의 경우(파란선) 순간순간의 정확한 값(빨간 선)을 전혀 나타내지 못하는 것을 알 수 있다.

지금까지 살펴본 것처럼  bucket 방식의 캡춰 모드에서 시간당 결과값을 보다 정확하게 파악하기 위해서는 '0' 값을 같이 기록해주는 것이 필요하다. 하지만, 일부 상황에서는 '0'값을 같이 기록한 결과값이 해석하기에 더 혼란스러운 경우도 있으므로 사용시 주의하여야 한다.