네트워크 시뮬레이션 공방

Riverbed(OPNET) Modeler WLAN 모델은 같은 서브넷 내에 있는 노드간에만 통신이 가능하다고 안내되어 있다. 하지만, 이는 정확하지 않은 것이며, 실제로는 WLAN 노드들간에 서브넷 경계를 넘어서(Ex: 서브넷 안에 위치한 AP 노드와 서브넷 밖에 위치한 STA 노드간) 통신이 가능하다. 단, 동일한 서브넷 내에 배치되어 있지 않은 WLAN 노드들간에는 BSS ID에 대한 Auto Assign 기능을 이용할 수 없으므로 사용자가 직접 BSS ID를 설정해 주어야만 한다(약간의 편법을 사용하면 이 경우에도 Auto Assign 기능을 적용할 수 있기는 하나 권장할만한 수준은 아니다).

다음은 통신을 원하는 WLAN 노드들이 서브넷 경계를 넘어서 배치되는 2가지 경우에 대한 예이다.

1) AP 노드는 서브넷 내부에, STA 노드는 서브넷 외부에 배치

AP 노드는 Subnet1 서브넷 내부에 배치되어 있으며, STA 노드에서 발생시킨 트래픽의 목적지가 되는 Server
노드와 AP 노드는 Ethernet 링크로 연결되어 있다. STA 노드는 서브넷 외부에 배치되어 있으며 Server 노드를 향해 트래픽(1024bytes 패킷을 0.1sec 간격으로 UDP를 통해 전송)을 발생시킨다. 시뮬레이션 결과를 살펴보면 다음 그림처럼 STA 노드에서 발생된 트래픽이 Subnet1의 AP 노드로 잘 전달되고 있음을 확인할 수 있다.

2) AP 노드와 STA 노드가 각각 서로 다른 서브넷에 위치

AP 노드는 Subnet1 서브넷에 배치되어 있으며, STA 노드에서 발생시킨 트래픽의 목적지가 되는 Server 노드와 AP 노드는 Ethernet 링크로 연결되어 있다. STA 노드는 Subnet2 서브넷에 배치되어 있으며 Server 노드를 향해 트래픽을 발생시킨다. 시뮬레이션 결과를 살펴보면 다음 그림처럼 Subnet2의 STA 노드에서 발생된 트래픽이 Subnet1의 AP 노드로 잘 전달되어 있음을 확인할 수 있다.

Riverbed(OPNET) Modeler TCP 모델에서는 Timestamps Option[1] 기능을 제공한다. 다음 그림은 Riverbed
(OPNET) Modeler의 Timestamp 속성 설정창을 보인 것이다.

각 속성항목의 용도는 다음과 같다.

- Status : 타임스탬프 기능 사용 여부를 설정. 선택 가능한 값은 Enabled, Disabled, Passive이다. Passive로 설정되면 상대방(client)에서 타임스탬프 사용을 먼저 요청하는 경우에만 타임스탬프를 사용한다. 즉 Passive는 Server 노드에서만 의미가 있으며, Client 노드가 Passive로 설정되면 Disabled로 설정된 것과 동일하다. 기본값은 17.1 버전까지는 "Disabled", 17.5 버전에서는 "Passive"이다.

- Clock Tick (millisec) : 타임스탬프 값의 증가 단위. 기본값은 500ms.

[1] RFC 1323, "TCP Extensions for High Performance," IETF, 1992.

지난 주(2016년 4월 28일)에 Riverbed Modeler 18.5.1 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.5.0 발표" 참조). Release note에는 4월 18일로 표기되어 있습니다만, 실제로 배포된 것은 4월 28일입니다.
Release note에 따르면 기능상에 주요 변화는 없으며, 문제점 수정 3건이 전부입니다. (Riverbed Modeler로 바뀌더니, 업데이트가 부실해진 건 사실인 것 같습니다.) 다만, 이 수정 사항 중 한건은 사용자 편의에 매우 큰 영향을 주는 부분인데, Attributes 편집창이 열릴 때 기본적으로는 "Advanced" 모드로 열리지 않도록 변경되었다고 합니다. 이 "Avdanced" 모드로 열리는 부분 때문에 그동안 상당히 불편했었는데, 이제서야 수정을 해주는군요. (사실은 원복입니다.)

Broadcast 네트워크나 NBMA 네트워크에서 OSPF는 DR(Designated Router)를 사용한다[1]. 다음은 Riverbed(OPNET) Modeler OSPF Model에서 DR이 사용되고 있음을 확인하기 위한 시험망의 구조이다. "OSPF 라우팅 예제"에서 사용한 시나리오를 수정한 것으로, R1, R2, R3, R4 노드간을 Broadcast 방식인 Ethernet으로 연결하였다.

시뮬레이션 수행시 실제로 할당된 IP주소 내역은 다음과 같다.

이 때, R1, R2, R3, R4 노드에 구성된 OSPF 인터페이스 정보를 ODB를 통해 살펴보면 다음과 같다.

192.0.1.x 네트워크에 대하여 R4 노드가 DR로, R3 노드가 BDR(Backup DR)로 동작하고 있음을 확인할 수 있다. 이 정보는 [2]에서 제시한 양식을 따른 것이다.

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

MS 윈도우에서 Visaul Studio 2010 버전을 컴파일러로 사용하기 위한 환경 변수 설정 방법(32비트/64비트 동일). Visual Studio 2010 버전 이후로는 동일한 방법이 적용되며, Visual Studio Express 버전에도 적용된다.

1) 설치된 Visual Studio의 "개발자 명령 프롬프트" 창을 연다.
2) "개발자 명령 프롬프트" 창에서 "set INCLUDE" 명령어를 입력하고, 출력된 문자열을 복사한다.
3) 환경 변수 설정창에서 사용자 변수에 "INCLUDE" 항목을 추가하고, 복사해둔 문자열을 입력한다.
4) "개발자 명령 프롬프트" 창에서 "set LIB" 명령어를 입력하고, 출력된 문자열중 "LIBPATH="전까지만 복사한다.
5) 환경 변수 설정창에서 사용자 변수에 "LIB" 항목을 추가하고, 복사해둔 문자열을 입력한다.
6) "개발자 명령 프롬프트" 창에서 "set Path" 명령어를 입력하고, 출력된 문자열중 "C:\Windows\system32"까지만 복사한다.
7) 환경 변수 설정창에서 사용자 변수에 "Path" 항목을 추가하고, 복사해둔 문자열을 입력한다.
8) 환경 변수 설정창에서 "확인" 버튼을 클릭한다.

ECMP(Equal-Cost Multi-Path)는 동일한 비용(Cost)을 가지는 여러 개의 경로들을 동시에 라우팅에 사용하는 것[1, 2]이며, Riverbed Modeler(OPNET)에도 구현되어 있다. 다중경로를 사용하는 주된 이유중 하나는 트래픽 부하 분산(로드 밸런싱)때문이다. 다음 그림은 ECMP 라우팅 동작을 확인하기 위하여, "라우터 배치 순서와 라우팅 경로 선정"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다.

ECMP가 사용되지 않은 경우와 사용된 경우의 라우팅 경로를 비교해보면 다음 그림과 같다. ECMP가 사용되지 않은 경우에는 하나의 경로만 사용되었지만, ECMP가 사용되는 경우에는 2개의 경로가 모두 사용되었음을 쉽게 관찰할 수 있다.

트래픽이 실제로 균등하게 분산되었음을 확인하기 위하여 R1 -> R2 링크와, R1 -> R3 링크의 트래픽 유통량을 살펴보면 다음 그림과 같다.

ECMP가 사용되지 않은 경우에는 R1 -> R2 링크로 모든 트래픽이 전달되었지만, ECMP가 사용되는 경우에는 R1 -> R2, R1 -> R3 링크로 트래픽이 분산되었음을 확인할 수 있다.

[1] RFC 2991, "Multipath Issues in Unicast and Multicast Next-Hop Selection", IETF, Nov. 2000.
[2] RFC 2992, "Analysis of an Equal-Cost Multi-Path Algorithm", IETF, Nov. 2000.

"OPNET 버전간의 호환성 문제(2) - OPNET 16.1 VoIP의 예"에서 언급하였듯이 Riverbed(OPNET) Modeler VoIP 모델에서는 지터 버퍼(Jitter Buffer) 기능을 제공한다. 지터 버퍼란 VoIP에서 지터에 따른 음성 품질 저하를 완화시키기 위하여 수신단에서 음성 재생전에 음성 데이터 프레임을 저장해두는 버퍼이다. 지터 버퍼는 디지터 버퍼(De-jitter Buffer) 또는 Playout Buffer라고도 불리우며, Riverbed(OPNET) Modeler에서는 "Playout Delay"로 표현된다.
다음 그림은 Riverbed(OPNET) Modeler에서 제공하는 지터 버퍼 속성 설정창을 보인 것이다.

각 속성 항목의 용도는 다음과 같다.

- Mode : 지터 버터가 Fixed 모드인지, Adaptive 모드인지를 결정한다. 기본값은 Fixed이다.
- Nominal Value : Fixed 모드일 경우, 지터 버퍼의 크기(ms). 기본값은 200(16.0 버전 이하) 또는 40(16.1 버전 이상)이다. ("OPNET 버전간의 호환성 문제(2) - OPNET 16.1 VoIP의 예" 참조)
- Minimum Value : Adaptive 모드일 경우, 지터 버터의 최소 크기(ms). 기본값은 10(Low)이다.
- Maximum Value : Adaptive 모드일 경우, 지터 버터의 최대 크기(ms). 기본값은 250(16.0 버전 이하) 또는 60(16.1 버전 이상)이다.
- Sliding Mean Coefficient : Adaptive 모드일 경우, 지터 버퍼 크기 계산을 위한 계수. 기본값은 0.5이다.

- Buffer Sizing Interval : Adaptive 모드일 경우, 지터 버터 크기를 계산하는 주기(ms). 기본값은 "Between Talkspurts"이며, 각 유음 구간의 시작 시점마다 지터 버퍼의 크기를 계산한다.

Nagle 알고리즘으로 인한 효과는 "TCP Nagle 알고리즘(2) - 예제"에서 살펴보았다. 그런데, "TCP Nagle 알고리즘(1) - 파라미터 설정"에서 설명하였듯이, OPNET TCP 모델에서 제공하는 "Nagle Algorithm" 속성값은 "Disabled"나 "Enabled" 외에 "Per-Send"로도 선택 가능하다. Per-Send 방식은 Optimized 버전이라고도 하며, Per-Segment 방식인 표준 Nagle 알고리즘을 개선한 것이다.
5,120bytes 크기의 데이터를 전송하는 경우, Per-Segment 방식과 Per-Send 방식의 동작을 예측해보면 다음과 같다.

이제 시뮬레이션을 통해 이 예측이 맞음을 확인해보도록 하자.
Per-Send 방식의 Nagle 알고리즘을 사용하였을 경우의 효과를 확인하기 위하여, "TCP Nagle 알고리즘(2) - 예제"에서 사용한 시나리오를 이용하여 5,120바이트 크기의 패킷을 1개 생성하도록 Task를 수정하고, 이 Task가 15초 간격으로 수행되도록 Profiles를 수정한다.
시뮬레이션을 수행한 후, Per-Segment 방식을 사용한 경우와 Per-Send 방식을 사용한 경우의 결과를 비교해보면, Server 노드에서 전송한 IP 패킷의 수는 동일한 것을 확인할 수 있다.

또한, 전송된 데이터의 양에는 차이가 없다. 다음 그림은 전송된 데이터 양이 동일함을 확인하기 위하여, Server 노드와 Discarder_2 노드간 링크에서 측정된 트래픽 양을 비교한 것이다.

전송한 패킷 수도 같고 데이터의 양도 같은데, Per-Send 방식에서는 무엇이 개선된 것일까? 그것은 TCP 레벨에서의 전달 지연(Delay)이다. Per-Send 방식에서는 전달해야할 하나의 데이터가 여러 세그먼트로 분할된 후 마지막 세그먼트가 MSS보다 작은 경우, Per-Segment 방식과는 달리 이전 세그먼트의 응답을 기다리지 않고 바로 전송하므로 전달 지연이 평균적으로 작다.
다음 그림은 이를 확인하기 위해서 Glaobal Statistics에서 측정한 TCP 데이터의 지연을 나타낸 것이다. Per-Send 방식(Optimized 버전)을 사용한 경우가 Per-Segment 방식(RFC 버전)을 사용한 경우보다 훨씬 낮은 평균 지연을 가지는 것을 확인할 수 있다.

"RIP 라우팅 예제"나 "OSPF 라우팅 예제"에서 사용한 예제망과 유사한 토폴로지의 네트워크를 사용하여 AODV의 동작을 확인해보기로 하자. 예제망의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

STA_3 노드의 최초 위치는 STA_2, STA_5 노드와 모두 통신이 가능한 거리이며, STA_4 노드의 최초 위치는 STA_2 노드와만 통신이 가능하고 STA_5 노드와는 통신할 수 없는 거리이다. 시간이 지남에 따라 STA_3 노드와 STA_4 노드는 이동하여 STA_3 노드는 STA_2 노드와는 통신할 수 없는 거리에, STA_4 노드는 STA_2, STA_5 노드와 모두 통신이 가능한 거리에 도달한다. 
시뮬레이션을 수행한 후, STA_2 노드에서 초기에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

STA_1, STA_3, STA_6 노드에 대한 라우팅 정보가 생성되었으며, STA_6 노드로의 전달을 위한 다음 홉은 STA_3 노드로 지정되어 있음을 확인할 수 있다. 또한, STA_1, STA_3 노드에 대한 홉 카운트는 1, STA_6 노드에 대한 홉 카운트는 3임을 알 수 있다. ("AODV 홉 카운트"에서 설명하였듯이, AODV는 홉 카운트를 라우팅 기준으로  사용한다.)
STA_1 노드로부터 STA_6 노드로의 디맨드 트래픽 전달 경로는 다음과 같이 STA_3 노드를 거쳐가는 경로로 확인되며, 이는 라우팅 테이블 정보와 일치한다.

STA_3 노드와 STA_4 노드의 이동에 따라 변경된 STA_2 라우팅 테이블을 살펴보면 다음 그림과 같다.

STA_3 노드에 대한 라우팅 정보가 없어지고 STA_4 노드에 대한 라우팅 정보가 생성되었으며, STA_6 노드로의 전달을 위한 다음 홉은 STA_4 노드로 변경되었음음 확인할 수 있다.
STA_1 노드로부터 STA_6 노드로의 디맨드 트래픽 전달 경로는 다음과 같이 STA_4 노드를 거쳐가는 경로로 확인되며, 이 역시 라우팅 테이블 정보와 일치한다.

Riverbed(OPNET) Modeler IP 모델은 링크 트래픽 부하에 대한 기록을 내부적으로 가지고 있으며, 이렇게 기록된 정보는 IGRP나 EIGRP에서 메트릭을 계산하는데 사용된다.
링크 트래픽 부하에 대한 정보는 두 가지 형태로 기록되는데, 하나는 bit 단위고 다른 하나는 bps 단위이다. 주의해야 할 점은, 이 부하의 측정 주기는 시뮬레이션 시작시점부터 해당 시점까지의 전기간이라는 것이다. 즉, 해당 순간의 링크 부하 또는 링크 사용률에 기반하여 어떠한 동작을 수행하는 목적에 사용하기에는 적합한 정보가 아니며, 별도의 정보를 따로 기록하여 사용하는 편이 낫다.