네트워크 시뮬레이션 공방

OSPF는 인터페이스 종류에 따라 몇 가지 동작 모드를 가지며[1], Riverbed(OPNET) Modeler OSPF 모델도 이를 지원한다. 다음 그림은 사용자가 OSPF 인터페이스 종류를 선택할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에서 선택 가능한 값은 Point To Point, Broadcast, Non-Broadcast, Point To Multipoint, MANET이다. Point To Point는 Point-to-point 네트워크를 위한 것이며, Broadcast는 이더넷과 같이 Broadcast 기능을 사용하는 다중 접속 네트워크를 위한 것이다. Non-Broadcast와 Point To Multipoint는 프레임 릴레이와 같이 Broadcast 기능을 사용하지 않는 다중 접속(Non-Broadcast Multi-Access: NBMA) 네트워크를 위한 것이다. MANET은 무선망을 위한 것이다.

[1] RFC 2328, "OSPF Version 2", IETF, Apr. 1998.

이 블로그의 많은 글에서 라우팅 테이블과 포워딩 테이블을 구분없이 사용하고 있다. 하지만, 엄밀하게 말하자면 Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블은 구분된다. (Riverbed(OPNET) Modeler의 라우팅/포워딩 테이블 구분은 얼핏보면 일반적인 라우팅/포워딩 테이블 개념[1, 2, 3]과 조금 달라보이기도 한다. 하지만, 근본적으로는 동일한 개념이라고 생각된다.) Riverbed(OPNET) Modeler에서 라우팅 테이블은 각 라우팅 프로토콜이 생성/관리하는 정보이며, 포워딩 테이블은 각 라우팅 프로토콜로부터 정보를 넘겨받아 IP 계층에서 생성/관리하는 정보이다. 이 관계를 그림으로 표현하면 다음과 같다.

그림에서 알 수 있듯이 라우팅 테이블과 포워딩 테이블은 완전히 분리되어 별도로 저장된다. 하지만, 대부분의 경우 포워딩 테이블에는 라우팅 테이블에 저장된 내용과 동일한 정보가 저장된다. 이 블로그에서 라우팅 테이블과 포워딩 테이블을 구분하지 않고 혼용하는 이유는 이 때문이다. (사실, Riverbed(OPNET) Modeler 내부에서 조차도 라우팅 테이블과 포워딩 테이블 용어를 정확히 구분하지 않고 혼용하는 경우가 있다.)

[1] https://en.wikipedia.org/wiki/Routing_table
[2] https://en.wikipedia.org/wiki/Routing_table#Forwarding_table
[3] http://nenunena.tistory.com/52

GRP 사용시 목적지 노드로의 패킷 전달을 위한 다음 홉(Next Hop) 선정은 목적지 노드 위치 정보가 직접 좌표인지 쿼드런트("GRP 쿼드런트" 참조) 좌표인지에 따라 구분되어 이루어진다.

1) 목적지 노드 위치 정보가 직접 좌표인 경우: 현재 노드의 이웃 노드들중 목적지 노드와 가장 가까운 거리에 위치한 이웃 노드를 다음 홉으로 선정.
2) 목적지 노드 위치 정보가 쿼드런트 좌표인 경우
  2-1) 현재 노드의 이웃 노드들중 목적지 노드와 같은 쿼드런트에 속한 노드가 있는 경우: 이웃 노드들중 목적지 노드와 같은 쿼드런트에 속한 (임의의) 노드를 다음 홉으로 선정.
  2-2) 현재 노드의 이웃 노드들중 목적지 노드와 같은 쿼드런트에 속한 노드가 없는 경우: 이웃 노드들중 목적지 노드가 속한 쿼드런트와 가장 가까운 거리에 위치한 노드를 다음 홉으로 선정.

이 과정은 패킷이 목적지 노드에 도착할 때까지 반복된다.

CUBIC 알고리즘이 적용되었을 때의 TCP 동작을 살펴보기 위하여 "TCP Window Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 수정한 시험망 토폴로지를 나타낸 것이다. Discarder_2 노드에서 200초와 300초에 패킷 1개씩을 폐기하도록 설정하고, Server 노드와 STA 노드 사이의 RTT는 100ms가 되도록 설정한다.

CUBIC 알고리즘을 사용하지 않은 경우와 사용한 경우의 비교를 위하여, New Reno를 적용한 시나리오와 CUBIC을 적용한 시나리오를 작성한다.

다음 그림은 시뮬레이션을 수행한 후, CUBIC 알고리즘을 적용한 시나리오의 Server 노드에서 측정된 CWND 값을 관찰한 것이다. [1, 2, 3]에 설명된 것처럼 cubic 함수에 의한 전형적인 CWND 변화 패턴을 확인할 수 있다.

다음 그림은 기존 방식과의 차이를 확인하기 위하여, New Reno를 적용한 시나리오와 CUBIC을 적용한 시나리오의 결과를 비교한 것이다.

New Reno에서는 재전송이 발생하면 Slow-Start 과정과 Congestion Avoidance 과정을 거치므로, CWND가 최소값으로 줄어들었다가 다시 급격하게 증가한다. 반면, CUBIC에서는 재전송을 수행한 후 Steady State Behavior 과정과 Probing 과정을 거치므로, CWND의 변화가 훨씬 완만하게 이루어진다.
다음 그림은 Server 노드에서 Discarder_2 노드로 전달되는 트래픽 양을 비교한 것이다. 재전송이 발생하였을 때에도 CUBIC을 사용한 경우에는 전송률의 저하가 심하지 않으며, 파일 전송 완료까지의 시간도(미미한 차이이기는 하지만) 더 짧다.

[1] http://research.csc.ncsu.edu/netsrv/?q=content/bic-and-cubic
[2] http://tools.ietf.org/html/draft-rhee-tcpm-cubic-02
[3] Sangtae Ha, Injong Rhee and Lisong Xu, "CUBIC: A New TCP-Friendly High-Speed TCP Variant", ACM SIGOPS Operating System Review, Volume 42, Issue 5, July 2008, Page(s):64-74, 2008.
[4] http://kernelnewbies.org/Linux_2_6_19

Riverbed(OPNET) Modeler는 18.7.1 버전("Riverbed Modeler 18.7.1 발표" 참조)까지도 MS Visual Studio 2013 이하 버전만을 지원하며, MS Visual Studio 2015는 지원하지 않는다.
다음은 Riverbed(OPNET) Modeler 18.0 버전("Riverbed Modeler 18.0.3 발표" 참조)에서 MSVC 2015를 컴파일러로 사용하려고 시도했을 때 발생하는 에러를 보인 것이다.

======================================================================================================
Beginning simulation of Analysis-RIP_Routing at 11:08:40 Sun Nov 29 2015
----
Kernel: development (not optimized), sequential, 32-bit address space
----
<<< Recoverable Error >>>
Object repository construction failed
due to errors encountered by the binder program (bind_so_msvc)

----
Errors reported by the binder program follow
(these messages have been saved in (C:\Users\User\op_admin\tmp\bind_err_4876):
   D:\OPNET_17_5\Analysis.project\Analysis-RIP_Routing.dev32.i0.nt.lib 라이브러리 및 D:\OPNET_17_5\Analysis.project\Analysis-RIP_Routing.dev32.i0.nt.exp 개체를 생성하고 있습니다.

apprun.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 __snprintf 기호를 _Aps_AppRun_Python_Exec 함수로 가져왔습니다.

apprun_sup.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 __snprintf 기호를 _appy_aps_application_base_odb_message 함수로 가져왔습니다.

gdc_server_support.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 __snprintf 기호를 _gdc_process_svr_to_svr_query. 함수로 가져왔습니다.

haipe_support.dev32.i0.ex.obj : warning LNK4049: 지역으로 정의된 기호 __snprintf을(를) 가져왔습니다.

apprun.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 _printf 기호를 _Aps_AppRun_Parameters_Print. 함수로 가져왔습니다.

apprun_sup.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 _printf 기호를 _appy_aps_module_init. 함수로 가져왔습니다.

gdc_server_support.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 _printf 기호를 _gdc_send_server_relation_candidate_req. 함수로 가져왔습니다.

apprun_sup.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 _fprintf 기호를 _appy_aps_apprun_print 함수로 가져왔습니다.

gdc_server_support.dev32.i0.ex.obj : warning LNK4217: 지역으로 정의된 _sprintf 기호를 _gdc_server_protocol_msg_create. 함수로 가져왔습니다.

op_win_stdio_patch.obj : error LNK2019: __imp____iob_func 외부 기호(참조 위치: _op_win_stdio_patch 함수)에서 확인하지 못했습니다.

D:\OPNET_17_5\Analysis.project\Analysis-RIP_Routing.dev32.i0.nt.dll : fatal error LNK1120: 1개의 확인할 수 없는 외부 참조입니다.

Microsoft (R) Manifest Tool version 6.3.9600.17336

Copyright (c) Microsoft Corporation 2012.

All rights reserved.

mt : general error c101008d: Failed to write the updated manifest to the resource of file "D:\OPNET_17_5\Analysis.project\Analysis-RIP_Routing.dev32.i0.nt.dll". ??? ??? ?? ? ????.

----
<<< Program Abort >>>
Error encountered rebuilding repository -- unable to proceed
T (0), EV (-), MOD (NONE), PROC (sim_load_repos_load)

----
======================================================================================================

따라서, Riverbed(OPNET) Modeler 18.0 ~ 18.7.1 버전에서는 컴파일러로 MSVC 2013("Visual Studio 2013 Express를 위한 환경 변수 설정" 참조) 이하 버전을 사용하여야 한다.

EIGRP는 기본적으로 bandwidth와 delay 항목 정보로부터 계산된 Metric을 기반으로 라우팅 경로를 선정하므로, EIGRP에 의해 선정된 경로는 OSPF에 의해 선정된 경로와 동일한 경우가 많다("EIGRP 라우팅 예제(1) - 2홉 vs 1홉" 참조). 하지만, 기본 파라미터를 그대로 사용한다고 할지라도 EIGRP의 Metric 계산 공식("EIGRP 메트릭" 참조)과 OSPF의 Cost 계산 공식("OSPF에서의 링크 비용" 참조)이 정확히 일치하지는 않으므로, 일부 경우에 따라서는 EIGRP에 의해 선정된 경로와 OSPF의해 선정된 경로가 다를 수도 있다.
다음 그림은 "EIGRP 라우팅 예제(1) - 2홉 vs 1홉"의 첫번째 예제를 조금 변경(R2->R4 링크, R1->R3 링크와 R3->R4 링크의 bandwidth를 기존보다 낮게 설정)한 토폴로지에 EIGRP와 OSPF가 사용되었을 때 두 단말 사이의 라우팅 경로를 비교하여 나타낸 것이다. 그런데, 라우팅 프로토콜을 제외한 모든 조건이 동일하였지만, 두 시나리오에서 선정된 라우팅 경로가 서로 다른 것을 알 수 있다.

여기에서는 라우터 배치 순서도 동일하게 해 주었으므로 동작 순서의 차이에 의해 발생한 현상("라우터 배치 순서와 라우팅 경로 선정" 참조)이 아니며, EIGRP와 OSPF에서 계산한 경로 Metric이 서로 달라서 발생된 것이다. 이를 확인하기 위해서 각 라우팅 프로토콜이 사용된 경우에 R1 노드에서 구성된 라우팅 테이블을 비교해보면 다음 그림과 같다. R4 - Server 네트워크에 대한 Next Hop이 EIGRP에서는 R3 노드로 지정되는 반면, OSPF에서는 R2 노드로 한 개씩만 지정되어 있는 것을 확인할 수 있다. 이는 R2 노드를 경유하는 경로와 R3 노드를 경유하는 경로의 Metric이 서로 달랐으며 EIGRP에서는 R3 노드를 경유하는 경로가, OSPF에서는 R2 노드를 경류하는 경로의 Metric이 상대적으로 더 작은 것으로 계산되었음을 의미한다.

Riverbed(OPNET) Modeler에서는 OPNET Modeler 14.5 PL8 버전부터 TDMA 모델을 제공한다. TDMA 모델은 Riverbed(OPNET) Modeler에서 제공하는 다른 프로토콜 모델들과는 달리, 모델링 대상 표준(또는 규격)이 특정되어 있지 않다.
대상 표준 문서가 따로 없다는 점에서는 GRP 모델("GRP 개요" 참조)의 경우와 유사하다. 하지만, GRP 모델은 (비록 OPNET사에서 자체 개발한 것이기는 하지만) GRP라는 특정 프로토콜을 모델링 한 것인데 비해, TDMA 모델은 GSM이나 Link 16 등과 같이 TDMA 방식을 사용하는 프로토콜들을 모의하는데 공통적으로 사용될 수 있도록 범용적인 TDMA 개념[1]을 모델링했다는 점에서 큰 차이가 있다. 때문에, Riverbed(OPNET) Modeler TDMA 모델의 세부적인 구현 방식에 대한 참고 문헌은 매우 부족한 편이며, 구체적인 내용 확인은 TDMA 모델 User Guide와 코드 분석에 의존해야 하는 실정이다.

[1] https://en.wikipedia.org/wiki/Time_division_multiple_access

Route Reply(RREP) 메시지는 Route Request(RREQ) 메시지에 대한 응답으로 사용되며, Riverbed(OPNET) Modeler AODV 모델에서는 "AODV 메시지(1) - 패킷 포맷"에서 살펴본 것처럼 공통 AODV 패킷 포맷의 Options 필드에 RREP 메시지에 대한 구조체를 싣는 방식으로 구현된다. 다음 그림은 AODV 모델에서 사용 하는 패킷 포맷과 RREP 메시지일 경우 Options 필드에 실리는 정보를 표준[1]과 비교하여 나타낸 것이다.

AODV 모델에 구현된 RREP 메시지 구조체와 표준이 잘 일치함을 확인할 수 있다.

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

OSPF는 OSPF 메시지가 TCP/UDP를 사용하지 않고, IP 계층으로 바로 전달됨은 "OSPF 메시지(3) - Encapsulation"에서 살펴본 바 있다. 이 때, Point-to-Point 네트워크에서 OSPF 패킷을 싣고 있는 IP 패킷의 목적지 주소로 2가지가(멀티캐스트 주소중 224.0.0.5와 유니캐스트 주소)가 사용되었는데, Broadcast 네트워크(BMA 모드)에서는 3가지(멀티캐스트 주소중 224.0.0.5, 224.0.0.6과 유니캐스트 주소)가 사용된다.
다음은 "OSPF DR(4) - Hello 패킷"의 예제를 사용하여 OSPF 메시지를 담고 있는 패킷 정보를 확인한 것이다. 먼저 DR(R4 노드)에서 전송하는 Hello 패킷을 살펴보면 다음 그림과 같다.

다음은 DR other(R1 노드)에서 전송하는 Hello 패킷을 살펴본 것이다.

DR/DR other 노드 모두 OSPF Hello 메시지를 싣고 있는 IP 패킷의 목적지 주소로는 224.0.0.5가 사용된다[1].
다음 그림은 DR other(R1 노드)에서 전송하는 OSPF DBD(DataBase Description) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, 수신측 인터페이스의 IP 주소인 192.0.1.4가 목적지 주소로 사용되었다.

다음 그림은 DR other(R1 노드)에서 전송하는 OSPF LSU(Link-State Update) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, Point-to-point 네트워크("OSPF 메시지(3) - Encapsulation" 참조)와는 달리 멀티캐스트 주소
224.0.0.6이 목적지 IP 주소로 사용되었다.

포트 번호로는 [1]에 정의된 대로 항상 89가 사용된다.

[1] RFC 2328, "OSPF Version 2", IETF, April 1998.

SITL 모듈을 사용하는 시뮬레이션을 MS Windows 환경에서 실행할 때에는 관리자(Administrator) 권한이 필요하다. 관리자 권한이 아닌 상태에서 SITL 모듈을 사용하는 시뮬레이션을 실행하면 다음 그림처럼 에러 메시지는 없지만 시뮬레이션이 정상적으로 진행되지 않고 종료되어 버린다.

시뮬레이션된 시간도 0초이고 처리된 이벤트 수도 0개이므로 실제로는 시뮬레이션이 전혀 진행되지 않은 것이다. 또한, 시뮬레이션이 종료되어 버렸으므로, 시뮬레이션과 외부 장비를 연동시키는 것도 불가능하다. 따라서, SITL 모듈을 사용하는 시뮬레이션 시에는 관리자 권한에 대한 주의가 필요하다.