네트워크 시뮬레이션 공방

어플리케이션 모델을 사용할 때 트래픽 발생 패턴은에 큰 영향을 미치는 프로파일 타이밍과 어플리케이션 타이밍 설정에 대해서는 "어플리케이션 사용 패턴(1) - 파라미터 설정"에서 살펴보았다. 이 설정값에 의해 트래픽 발생 패턴이 실제로 어떻게 영향을 받는지 예제를 통해 살펴보기로 하자.
다음은 어플리케이션 사용 패턴을 실험하기 위한 예제망을 보인 것이다. 어플리케이션은 FTP를 이용하여 Server 노드에서 Client 노드로 50KBytes 크기의 파일이 50초마다 전송되도록 설정하였다.

트래픽의 시작 시간을 결정하는 Start Time(프로파일 타이밍)과 Start Time Offset(어플리케이션 타이밍)의 영향을 살펴기로 하자. Start Time을 100초로 설정하고, Start Time Offset을 No Offset으로 설정하였을 때, Client 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.

트래픽이 100초부터 발생한 것을 확인할 수 있다.

또한, Start Time을 150초로 설정하고, Start Time Offset을 No Offset으로 설정하였을 때는 다음 그림처럼 트래픽이 150초부터 발생한 것을 확인할 수 있으며,

Start Time을 100초로 설정하고, Start Time Offset을 50초로 설정하였을 때도 다음 그림처럼 트래픽이 150초부터 발생한 것을 확인할 수 있다.

즉, 트래픽이 처음 발생하는 시간은 Start Time + Start Time Offset에 해당하는 값이다.

그러면, Start Time과 Start Time Offset은 동일한 것일까? 그렇지는 않다. Start Time은 프로파일이 처음 실행되는 경우에만 적용되고, Start Time Offset은 프로파일이 반복될 때에도 적용되기 때문이다. 즉, 앞의 예제와 같이 프로파일이 반복없이 한번만 실행되는 경우에는 동일한 결과를 보여주만, 프로파일이 반복되는 경우에는 매우 다른 결과를 보여준다.
200초의 길이를 가지고 300초 간격마다 반복실행되는 프로파일에 대해서(프로파일의 반복에 대해서는 나중에 다시 살펴볼 것이다), Start Time을 150초로 설정하고 Start Time Offset을 No Offset으로 설정하였을 때 Client 노드에서 전송되는 트래픽을 살펴보면 다음 그림과 같다.

200초의 트래픽 발생구간이 300초의 간격으로 반복되는 것을 확인할 수 있다.

200초의 길이를 가지고 300초 간격마다 반복실행되는 프로파일에 대해서, Start Time을 100초로 설정하고 Start Time Offset을 50초로 설정하였을 때의 결과를 살펴보면 다음과 같다.

트래픽이 최초로 발생하는 시점은 150초로 동일하지만, 트래픽 발생구간이 150초, 반복 간격은 350초로 변경된 것을 확인할 수 있다. 이를 프로파일이 시작될때마다 Offset 50초동안 기다렸다가 트래픽 발생이 시작되기 때문에 나타나는 현상이다.

OSPF에서 인터페이스는 Down, Loopback, Waiting, Point-to-point, DR Other, Backup, DR 상태중 하나의 상태를 가지며[1, 2], "OSPF DR(1) - 라우터 상태"에서 살펴본 것처럼 Riverbed(OPNET) Modeler OSPF 모델에서도 인터페이스 상태 변화/관리 기능을 제공한다.
다음 그림은 표준[2]에 기술된 인터페이스 상태 변화도와 Riverbed(OPNET) Modeler OSPF 모델에 구현된 해당 프로세스 모델(ospf_interface_v2, "OSPF 프로세스 모델 구조" 참조)의 state diagram을 비교하여 나타낸 것이다.

비교해보면 Backup 스테이트와 DR Other 스테이트의 위치가 변경된 것과, Riverbed(OPNET) Modeler에는 Loopback 스테이트가 없다는 점을 제외하면 두 그림은 동일하다. 따라서, 표준 문서[1, 2]의 내용만 잘 이해하면 Riverbed(OPNET) Modeler 프로세스 모델의 동작은 쉽게 짐작할 수 있다.
다만, 여기에서는 이해를 돕기 위하여 예전 표준[2]에 포함된 그림을 비교에 사용하였다. 다음 그림은 최신 표준[1]에 포함된 그림을 보인 것인데, 형태만 다를뿐 실제 내용은 동일하다.

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

"OPNET Modeler 17.5 PL3 발표"와 "멀티코어 시스템에서의 시뮬레이션 (16.1 버전)"에서 언급하였듯이, 멀티코어
활용을 위한 설정 기능은 OPNET 17.5 PL3 버전에서 일부 변경되었다.
17.5 PL3 버전부터는 Multiple run이 필요한 시나리오를 멀티코어 사용이 비활성화된 상태에서 실행할 경우, 멀티코어 사용여부를 확인하는 설정창이 다음 그림처럼 친절하게 나타난다.

이 창을 통해 코어의 갯수만 설정해주면 멀티코어를 사용한 동시 시뮬레이션을 다음 그림처럼 쉽게 수행할 수 있다(사용 코어수는 3개로 설정).

17.5 PL6 버전("OPNET Modeler 17.5 PL6 발표" 참조)에서 프로세싱 게인은 MCS 레벨별 프로세싱 게인과 OFDM에 의한 프로세싱 게인의 합으로 계산된다. MCS 레벨별 프로세싱 게인은 MCS 레벨("WiFi MCS 레벨 (17.5 PL6 버전)" 참조)에 따라 지정된 수식을 사용하여 계산된다. OFDM에 의한 프로세싱 게인은 대역폭과 Guard Internal 값으로부터 계산된다.

Riverbed(OPNET) Modeler 시나리오상에 배치한 라우터나 단말 노드로 기본적인 ping 요청을 보내고 응답을 받는 것에는 아무런 문제가 없음을 "SITL Ping 예제(1)"과 "SITL Ping 예제(2)"에서 살펴보았다.
그러면, tracert(traceroute의 MS Windows 버전)의 경우에는 어떨까? tracert도 실제로는 ping 요청(ICMP Echo Request)을 사용하므로[1, 2], 얼핏 생각하면 잘 동작할 것으로 예상할 수도 있다. 하지만, 애석하게도 tracert 명령어를 SITL 모듈과 연동시켜 사용해보면 정상적으로 동작하지 않는다.
다음은 "SITL Ping 예제(1)"의 시험망에서 Server_1 노드를 상대로 tracert 명령어를 사용했을 때의 결과를 보인 것이다.

Server_1 노드는 SITL 게이트웨이로부터 2홉 거리에 있으며, ping 요청에 대해서 정상적으로 응답하였다. 하지만, 중간에 위치한 R1 노드에서는 응답을 하지않아 중간 경로 확인은 불가능함을 알 수 있다. 정상적으로 동작하지 않는 원인은 tracert 에서는 ping 요청(ICMP Echo Request)에 대한 응답으로 ICMP Echo Reply 메시지외에 ICMP Time Exceeded 메시지[2]도 사용되는데[3], Riverbed(OPNET) Modeler에는 이에 대한 처리 기능이 구현되어 있지 않기 때문이다.

[1] https://en.wikipedia.org/wiki/Traceroute
[2] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
[3] https://technet.microsoft.com/en-us/library/cc940128.aspx

AODV의 Hello 메시지는 링크의 연결성을 확인하기 위해 사용되며, RREP 메시지의 일종이다[1]. Riverbed(OPNET) Modeler AODV 모델에서 RREP 메시지는 AODV 패킷 포맷의 Options 필드에 RREP 메시지에 대한 구조체를 싣는 방식으로 구현되므로("AODV 메시지(3) - RREP 구조체" 참조), Hello 메시지 역시 동일한 방식으로 구현된다.

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

다중 경로 라우팅을 통한 로드 밸런싱(부하 분산)은 Load Balancing Options 속성값을 통해 조정할 수 있음을 "다중경로 라우팅(3) - 로드 밸런싱"에서 살펴보았다. EIGRP를 통한 UCMP("다중경로 라우팅(7) - UCMP" 참조)에서는 여기에 한가지 속성을 추가로 사용할 수 있는데, 그것은 Traffic Share이다. Traffic Share 속성의 선택 가능한 값은 다음과 같다.

- Balanced : Traffic Share 속성의 기본값이며, metric 값에 비례하여 다중 경로별로 트래픽을 분배하는 방법이다.

- Minimum : 최소 metric 값을 가지는 경로들에 대해서만 트래픽을 균등하게 분배하는 방법이다. 즉 Minimum은 metric 값이 동일한 경로가 존재하는 경우에만 로드 밸런싱 효과가 있으며, 다중 경로의 metric 값이 다른 경우에는 로드 밸런싱 효과는 없다.

Traffic Share 방법이 Balanced 방식인지 Minimum 방식인지는, Load Balancing Options이 Destination-Based
방식인지 Packet-Based 방식인지에 종속되지 않는다.

Riverbed(OPNET) Modeler TCP 모델에서는 매우 많은 수의 속성들을 제공하고 있으며, 이러한 속성들을 모두 사용자가 정확히 이해하고 값을 정확히 설정하기에는 상당한 시간이 걸릴뿐만 아니라 매우 번거롭다. 이러한 어려움을 해결하기 위하여, Riverbed(OPNET) Modeler에서는 TCP 버전 및 OS별로 속성값들이 조정된 TCP 프로파일을 제공한다. TCP 프로파일은 다음 그림처럼 TCP Parameters 속성에서 선택할 수 있다.

16.1 버전에서 제공되는 TCP 프로파일은 Default, Tahoe, Reno, New Reno, SACK, NT (3.5/4.0), Windows 98, Windows 2000, Windows XP, Solaris 2.6, Solaris 2.7, Solaris 2.8, Solaris 2.9, HP-UX 10.x/11.x, Full-Featured 이며, 자주 사용되는 프로파일의 세부 속성항목들의 값은 다음 표와 같다.

Riverbed(OPNET) Modeler에서 IP 패킷이 전달되는 경로를 확인하는 방법은 "라우팅 경로 확인하기"에서 살펴보았다. 그런데, 라우팅 프로토콜로 GRP가 사용된 경우에는 "라우팅 경로 확인하기"에서 사용한 방법으로 IP 패킷 전달 경로가 확인되지 않으며, 다른 방법을 사용해야만 한다.
GRP가 사용된 경우에 IP 패킷 전달 경로는 다음의 방법들로 확인할 수 있다.

1) 패킷별 경로 테이블 확인
2) 패킷별 경로 그래프 표시

패킷별 경로 테이블 확인은 시뮬레이션 수행 후, 각 패킷이 소스 노드에서 목적지 노드까지 어떤 노드를 거쳐갔는지를 표로 확인하는 방법이다. 패킷을 기준으로 그 패킷이 거쳐간 경로를 테이블로 기록한 결과라는 점에서 라우터의 라우팅 테이블 확인("라우팅 경로 확인하기" 및 "라우팅 테이블과 포워딩 테이블" 참조)과는 다르다.

패킷별 경로 그래프 표시는 시뮬레이션 수행 후, 패킷별로 사용한 경로를 네트워크 토폴로지 상에 표시해주는 방법이다. Demand Traffic Flow에 대한 라우팅 경로 표시("라우팅 경로 확인하기" 참조)와 유사하며, 다음 그림처럼 GRP에서의 라우팅 경로가 네트워크 토폴로지 상에 표시된다.

Riverbed(OPNET) Modeler에서 OSPF 프로토콜 기능은 여러 개의 프로세스 모델로 분할되어 수행된다. 다음 그림은 관련 프로세스 모델간의 생성 관계를 나타낸 것이다. 이해하기 쉽도록 가상 인터페이스(Virtual Interface) 프로세스 모델은 생략하였다.

각 프로세스 모델의 주요 기능은 다음과 같다.

- ospf_v2 : OSPF 변수들을 생성/초기화하고, 필요한 child 프로세스를 생성한다.

- ospf_process : 라우팅 테이블을 관리하고, 제어 메시지를 처리한다.

- ospf_interface_v2 : OSPF 인터페이스의 상태(state)를 관리한다.

- ospf_neighbor_v2 : OSPF 이웃(neighbor) 노드의 상태(state)를 관리한다.