네트워크 시뮬레이션 공방

다음 그림은 Riverbed(OPNET) Modeler에서 AODV 프로토콜이 동작하는 WLAN 노드 모델의 구조를 보인 것이다. 그런데, 해당 라우팅 프로토콜에 대한 프로세서 모듈이 바로 식별되는 RIP나 OSPF와는 달리, AODV는 프로세서 모듈이 직접 보이지 않는다.

그럼 AODV 프로세스는 어디에 위치하는 것일까? 일반적으로는 UDP를 사용하는 AODV의 특성[1]을 고려하면 UDP 계층위의 manet_rte_mgr 프로세서 모듈에 위치할 것 같지만, 실제로는 다음 그림처럼 ip 프로세서 모듈 내부에 차일드 프로세스 형태로 존재한다.

이러한 프로토콜 계층 구성은 사용자들에게 혼란을 주는 AODV 모델의 문제점이다. 사실 Riverbed(OPNET) Modeler에서는 계층 개념을 정확히 준수하지 않고도 충분히 표준에 맞는 프로토콜을 구현할 수 있다. 하지만, 대부분의 프로토콜은 계층 구조를 준수하여 구현되어 있으며, 계층 구조에 맞지 않은 위치에 구현되어 있는 경우는 AODV 모델외에는 아직 보지 못했다.

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

OSPF Hello 메시지("OSPF 메시지(1) - Hello 패킷 포맷" 참조)에 실제로 어떤 정보가 실려서 전달되는지, "OSPF 라우팅 예제"에서 사용한 예제를 활용하여 시뮬레이션을 통해 확인해보기로 하자. 다음은 "OSPF 라우팅 예제"에서 사용한 시험망 구조와, 시뮬레이션 수행시 실제로 할당된 IP주소 내역을 보인 것이다.

이 때, R1 노드에서 R2 노드로 전달되는 Hello 메시지 정보를 ODB를 통해 살펴보면 다음과 같다.

각 필드에 실린 정보의 의미는 다음과 같다.

- type : OSPF 패킷의 종류. 1은 Hello Packet임을 의미.
- version : OSPF 버전. 2는 OSPFv2를 의미.
- Hello Interval : Hello 메시지 전송 간격. 단위는 초(sec).
- Router Dead Interval : 상대 라우터의 비활성화 여부 판단 시간. 단위는 초(sec).
- priority : DR 선출시에 사용되는 라우터 우선 순위. 1은 기본값.
- options : OSPF 옵션. 2는 ExternalRoutingCapability 비트가 설정되었음을 의미.
- Router ID : Hello 메시지를 보내는 라우터의 ID. 192.0.2.1은 이 예제망에서 R1 노드의 Router ID이다.
- Area ID : Hello 메시지가 속한 Area의 ID. 이 예제망에서는 Area가 설정되지 않았으므로, 0.0.0.0으로 지정된다.
- Network Mask : Hello 메시지를 보내는 인터페이스에 사용되는 Metwork Mask.
- DR : DR의 IP 주소. Point-to-point 네트워크에서는 DR이 사용되지 않으므로, 0.0.0.0으로 지정된다.
- Backup DR : BDR의 IP 주소. Point-to-point 네트워크에서는 BDR이 사용되지 않으므로, 0.0.0.0으로 지정된다.

"EIGRP 메트릭"에서 설명하였듯이, EIGRP에서 Metric 계산시 Delay는 인터페이스 전송 속도에 의해 지정[2]된다. 다음은 Riverbed(OPNET) Modeler EIGRP 모델에서 사용하는 Delay 값 변환 표이다.

[1] http://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/16406-eigrp-toc.html#eigrpmetrics
[2] http://www.ietf.org/staging/draft-savage-eigrp-00.txt

특정 소스와 목적지간에 백그라운드 트래픽을 ip_traffic_flow 디맨드 모델을 이용하여 간단히 모의하는 방법을 "Background Traffic의 영향(4) - Demand Model"에서 살펴보았으며, 이 때 "Traffic Mix" 속성을 All Background로 설정하면 시뮬레이션 수행시간을 크게 줄일 수 있음은 "Background Traffic의 영향(5) - Traffic Mix"에서 살펴보았다.
그런데, 네트워크 토폴로지 상에 허브가 포함되는 경우에는 드맨드 모델에 의한 트래픽 부하가 정상적으로 관찰되지 않으므로 주의하여야만 한다. 다음은 드맨드 모델에 의한 백그라운드 트래픽이 허브 모델을 지나갈때 관찰되는 트래픽을 확인하기 위하여 구성한 시험망을 나타낸 것이다. "RIP 라우팅 예제"에서 사용한 시험망을 변경한 것으로 R1 노드와 R4 노드 사이에 이더넷 허브 노드를 배치하고 이더넷 링크로 연결해 주었다.

시뮬레이션을 수행한 후 Traffic Mix 모드가 All Background 인 경우와 All Explcit인 경우에 대해서 Client 노드로부터 R1, Hub, R4, Server 노드로 전달되는 트래픽량을 비교해보면 다음 그림과 같다.

Traffic Mix 모드가 All Background인 경우에는 R1 노드에서 Hub 노드, Hub 노드에서 R4 노드 구간에서는 디맨드 플로우에 의한 트래픽이 전혀 관찰되지 않는다. 하지만, Client 노드로부터 R1 노드로 전달된 것과 동등한 양의 트래픽이 R4 노드에서 Server 노드로 전달되는 것이 확인되므로, 실제로는 트래픽이 R1 노드에서 사라진 것이 아니라 R1 -> Hub, Hub -> R4 링크에서 관찰되지만 않은 것임을 알 수 있다. (링크뿐만 아니라 Hub 노드에서도 관찰되지 않는다)
반면, Traffic Mix 모드가 All Explicit인 경우에는 모든 구간에서 디맨드 플로우에 의한 트래픽이 정상적으로 관찰된다.
따라서, 허브 노드가 포함된 시험망에서 디맨드 트래픽 모델을 사용할 때에는 트래픽 유통량 분석 과정에서 Traffix Mix 모드가 어떻게 설정되어 있는지에 대한 세심한 주의가 필요하다.

IETF 표준문서는 다음의 사이트를 사용하면 좀 더 편하게 볼 수 있다.

http://tools.ietf.org/html/

지난 10월31일자로 Riverbed Modeler 18.6.0 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.5.1 발표" 참조). Release note에는 10월 19일로 표기되어 있습니다만, 실제로 배포된 것은 10월 31일입니다. Release notes를 통해 변경 사항을 살펴보았습니다. 내용은 많지 않지만, 상당히 중요한 사항들로 생각됩니다.
변경 사항은 다음과 같습니다.

- SDN Model 추가
- SITL Enhancement

새로운 모델인 SDN(Software-Defined Networking) 모델이 추가되었습니다. 신규 모델의 추가는 2014년의 Cyber Effects 모델("OPNET Modeler 17.5 PL6 발표" 참조) 이후로 2년만입니다만, 신규 프로토콜 모델이라는 관점에서는 2011년의 802.11n 모델("OPNET Modeler 16.1 PL1 발표" 참조) 이후로 5년만인 것 같습니다. 실로 오래간만의 프로토콜 모델 추가인지라 무척 반갑네요. 이번에 추가된 SDN 모델은 OpenFlow Switch 규격 v1.3.0을 따른다고 합니다.
SITL 모듈은 802.1Q(VLAN) 태그도 처리할 수 있도록 기능이 개선되었다고 합니다.

Riverbed(OPNET) Modeler TCP 모델은 재전송 수행시의 횟수를 제한하는 기준을 설정할 수 있는 기능을 제공한다. 다음 그림은 사용자가 TCP 재전송 횟수를 제한하는 방식과 기준값을 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

Retransmission Thresholds 속성 항목은 하위 속성 항목들의 조합이며, 선택 가능한 값은 Attempts Based, Time Based, Windows 2000, HP-UX 10.x/11.x이다. 이외에도 하위 속성 항목들을 직접 설정하는 것도 가능하다. 기본값은 17.1 버전까지는 "Attempts Based"이고, 17.5 버전부터는 직접 설정된 값(Attempts Based가 일부 수정됨)이다.
각 하위 속성항목의 용도는 다음과 같다.

- Mode : 재전송 횟수를 제한하는 기준 방법을 정의. 선택 가능한 값은 Attempts Based와 Time Based이다. Attempts Based는 재전송이 수행되는 횟수를 제한하는 방법이며, Time Based는 재전송이 수행되는 시간을 제한하는 방법이다. Windows NT는 Attempts Based 방법을 사용하고, Solaris는 Time Based 방법을 사용한다.
- Maximum Connect Attempts (attempts) : 연결 요청(SYN) 메시지 최대 전송 횟수.
- Maximum Data Attempts (attempts) : 데이터 세그먼트 최대 전송 횟수.
- Maximum Connect Interval (seconds) : 연결 요청(SYN) 메시지 전송 절차 최대 진행 시간.
- Maximum Data Interval (seconds) : 데이터 세그먼트 전송 절차 최대 진행 시간.

"TCP 재전송(5) - 연속된 Timeout"에서 살펴본 것처럼, 최대 재전송 횟수를 넘어서면 TCP 재전송은 더이상 수행되지 않는다.

[1] http://www.microsoft.com/korea/technet/network/tcpip2k.mspx
[2] http://www.speedguide.net/articles/windows-7-vista-2008-tweaks-2574

OSPF에서 Hello 메시지는 이웃(Neighbor)을 찾아내는(discorver) 용도와 이웃과의 관계를 유지(maintain)하는 용도로 사용된다. 다음 그림은 Riverbed(OPNET) Modeler OSPF 모델에서 사용하는 Hello 패킷 포맷과 표준[1]에서 설명하는 Hello 패킷 포맷 비교하여 나타낸 것이다.

얼핏 보기에는 Riverbed(OPNET) Modeler의 Hello 패킷 포맷은 표준과 완전히 다른 것처럼 보인다. 하지만, fields 필드에는 Router ID, Area ID, Version, Network Mask, HelloInterval, Options, Router Priority, RouterDeadInterval, Designated Router, Backup Designated Router 등의 정보가 실리므로, 실제로는 표준[1]과 동일하다(Authenticaiton 및 Checksum 제외).

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

"EIGRP 메트릭"에서 살펴본 것처럼 EIGRP에서는 메트릭 계산시에 링크 부하도 사용된다. 링크 부하는 EIGRP에서 따로 측정하지 않으며, IP 모델에서 기록해준 정보("IP 트래픽 부하 정보" 참조)를 사용하되 EIGRP 메트릭에 맞추어 재조정하여 적용한다. 즉, IP 모델에서는 링크 부하에 대한 기록을 bps 단위로 남기지만, EIGRP에서는 이 bps 값을 다음 수식처럼 링크 사용률로 변환(단, 최대값은 255)하여 부하(load)로 사용한다.

한가지 주의할 사항은 IP 모델에서 링크 부하에 대해서 기록해주는 코드가 EIGRP 사용시에는 동작하지 않으므로(버그로 생각된다), EIGRP에서 load를 메트릭에 반영하고자 하는 경우에는 해당 소스 코드를 일부 수정해주어야 한다는 것이다.

"서브넷 경계를 넘어서는 WLAN 노드간의 통신(1) - BSS ID"에서 설명한 방법을 이동하는 WLAN 단말에 적용하면 다음 그림처럼 서로 다른 서브넷에 속한 AP들간을 로밍하는 시나리오도 만들 수 있다. Subnet1에 속한 AP 노드와 STA 노드의 BSS ID는 1, Subnet2에 속한 AP 노드의 BSS ID는 2로 설정하였으며, STA 노드의 Roaming Capability를 Enabled로 변경하였다. 트래픽은 "서브넷 경계를 넘어서는 WLAN 노드간의 통신(1) - BSS ID"에서와 동일하게 STA 노드에서 Server 노드를 향해 전달하도록 설정하였다(1,024bytes 패킷을 0.1sec 간격으로 UDP를 통해 전송).

STA 노드는 Subnet1 내의 AP 노드를 통해 Server 노드로 트래픽을 전달하다가 이동하여 Subnet2 내의 AP 노드로 로밍하여 트래픽을 계속 전달한다. 이를 확인하기 위해서 Subnet1에서 Router로 Subnet2에서 Router로, Router에서 Server로 전달되는 트래픽을 살펴보면 다음 그림과 같다.