네트워크 시뮬레이션 공방

EIGRP는 bandwidth, load, delay, reliability 정보를 종합적으로 사용하여 Metric을 계산("EIGRP 메트릭" 참조)할 수 있도록 개발되었지만, 실제로는 대부분의 경우에 있어 load나 reliablity 항목은 사용되지 못하고 bandwidth와 delay 항목만이 사용된다[1].

형식상으로는 delay 항목이 추가로 사용되는 것만으로도 링크의 대역폭(bandwidth) 정보만을 사용하여 cost를 계산하는 OSPF("OSPF에서의 링크 비용" 참조)와는 차별화되어 보이기도 한다. 하지만, 여기에서의 delay는 인터페이스 전송 속도에 의해 지정[2]되는 것이므로, 실제로는 거의 동일하다.
"RIP 라우팅 예제"에서 사용한 예제망의 라우팅 프로토콜을 EIGRP로 변경하여 EIGRP의 동작을 확인해보기로 하자. 첫번째 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조).

R2 - R4, R3 - R4, R4 - Server 네트워크에 대한 라우팅 정보가 EIGRP에 의해 생성되었으며, R2 - R4, R3 - R4 네트워크에 대한 Metric은 89,344, R4 - Server 네트워크에 대한 Metric은 91,904임을 확인할 수 있다. (R4 - Server 네트워크에 대해서 2개의 경로 정보가 구성된 것은 ECMP("다중경로 라우팅(1) - ECMP" 참조) 때문이다.)
"EIGRP 메트릭"에서 설명하였듯이 EIGRP는 bandwidth, load, delay, reliability, mtu 정보로부터 계산된 값을 Metric으로 사용하며, 기본값 사용시 DS3(44.746Mbps) 링크 2개로 구성된 경로의 Metric은 89,344, DS3(44.746Mbps) 링크 2개와 Fast Ethernet(100Mbps) 링크 1개로 구성된 경로의 Metric은 91,904로 계산된다. 따라서, R1 -> R2 -> (R4) 경로와 R1 -> R3 -> (R4) 경로의 Metric은 89,344가 되며, R1-> R2-> R4 ->(Server) 경로의 Metric은 91,904가 된다.

Client 노드로부터 Server 노드로의 트래픽 전달 경로는 다음과 같이 2홉 경로(R1 -> R2 -> R4 경로)으로 확인되며, 이는 라우팅 테이블과 일치한다. (이후의 1홉 예제의 결과와 비교할 것이므로 R1 -> R2 -> R4 경로, 또는 R1 -> R3 -> R4 경로 어느 쪽이던 별 상관은 없다)

이제 R1 노드와 R4 노드사이에 1홉 링크를 추가하여 EIGRP의 특성을 보다 자세히 살펴보자. 다음 그림은 첫번째 예제를 변형한 두번째 예제의 구조이다. R1 노드와 R4 노드 사이에 다른 링크(DS3)보다 작은 대역폭의 링크(DS1)를 추가하였다.

시뮬레이션을 수행한 후, 두 번째 시나리오에서 R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

R1 노드와 R4 노드를 연결하는 링크가 추가되었음에도 불구하고 R4 - Server 네트워크에 대한 경로는 변경이 없으며, Metric도 동일하게 91,904임을 확인할 수 있다.
이제 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 살펴보면 라우팅 테이블의 구성과 같이 2홉 경로(R1 -> R2 -> R4)인 것을 알 수 있다.

즉, 기본적으로 EIGRP는 경로의 bandwidth와 delay 항목 정보로부터 계산된 Metric을 기반으로 라우팅 경로를 선정하며, Metric이 더 작은 경로가 존재하면 홉 수에 상관없이 해당 경로를 라우팅 경로로 선정한다. 따라서, EIGRP에 의해 선정된 경로는 OSPF에 의해 선정된 경로와 동일("OSPF 라우팅 예제" 참조)한 경우가 많다.

[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

Riverbed(OPNET) Modeler TCP 모델은 시뮬레이션에서 사용된 TCP 연결들을 사용자가 확인할 수 있도록 화면상에 정보를 출력하는 기능을 제공한다. 이러한 기능은 실제 TCP 구현물에서는 제공되지 않는 것으로, 시뮬레이터이기에 가능한 부분이다. (굳이 비교 대상을 찾자면 Windows나 Linux에서 제공하는 netstat 명령어와 유사한 면이 있다.) 다음 그림은 사용자가 TCP 연결 정보 출력 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

"TCP Windows Scaling(1) - LFN에서의 동작"에서 사용한 시나리오를 사용하여 시뮬레이션을 수행한 후, 화면에 출력되는 TCP 연결 정보를 살펴보면 다음과 같다.

FTP 연결(포트 20번 사용)이 100.0초에 설정되어 시뮬레이션이 끝날때까지 사용된 것을 쉽게 확인할 수 있다.

어제(6월29일) Riverbed Modeler 18.6.1 버전이 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.6.0 발표" 참조). Release note에는 6월 26일로 표기되어 있습니다만, 공식적인 업데이트 발표는 어제 있었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 주요 내용은 기존 모델들에 대한 기능 업데이트입니다.

- SDN Model Enhancements
- OSPF Model Enhancements
- WLAN Model Enhancements

SDN(Software-Defined Networking) 모델은 직전의 Riverbed Modeler 18.6.0 버전("Riverbed Modeler 18.6.0 발표" 참조)에서 추가된 모델인데, 이번에도 새로운 기능들이 다수 반영되었습니다. Port status monotoring and reporting, Recovery of TCP conneciton, Seding "Echo Request" message, Version negotiation 등의 기능입니다.
OSPF 모델의 개선 사항은 LSA의 주기적 재생성과 유효시간이 경과한 LSA 정보의 삭제입니다. 이 기능은 주로 SITL 모듈을 통한 실장비와의 연동시 필요한 것이며, 이 기능이 활성화되기 위해서는 OSPF simulation efficiecny 옵션이 꺼져 있어야 합니다.
WLAN 모델의 개선 사항은 Block-ACK 메커니즘을 위한 "next expected sequence number" 기능이 반영되었다는 것입니다. 이 기능은 IEEE 802.11 표준의 2012년 버전에서 소개된 것인데, 이제 Riverbed Modeler에도 구현되었다고 합니다.

이외에 버그 수정도 4건 포함되었습니다만, 현재 관심이 가는 내용이 아니라서 생략합니다.

UDP는 사용하는 RIP나 TCP를 사용하는 BGP와는 달리, OSPF는 TCP/UDP 계층을 거치지 않고 IP 계층을 직접 사용하여 메시지를 전달한다[1]. 이러한 차이는 다음 그림처럼 Riverbed(OPNET) Modeler에서 제공하는 노드 모델의 구조에서도 쉽게 확인할 수 있다. 즉, RIP는 UDP 계층위에 위치하지만, OSPF는 IP 계층 바로 위에 위치한다.

OSPF 메시지가 TCP/UDP를 사용하지 않고, IP 계층으로 바로 전달됨은 OSPF 메시지에 대한 Enacapsulation 구조를 통해서도 알 수 있다. 다음 그림은 "OSPF 메시지(2) - Hello 패킷 정보 확인"에서 살펴본 OSPF Hello 메시지를 담고 있는 패킷 정보를 확인한 것이다. TCP 패킷이나 UDP 패킷을 통한 Enacapsulation 과정없이, OSPF 패킷이 IP 패킷에 바로 Enacapculation 되어 있는 것을 확인할 수 있다.

OSPF 메시지를 싣고 있는 IP 패킷의 목적지 주소로는 OSPF 메시지의 종류와 단계에 따라 2가지가 사용된다. 이 IP 패킷은 OSPF Hello 메시지를 싣고 있으므로 멀티캐스트 주소인 224.0.0.5가 목적지 IP 주소로 사용되었다[1].
다음 그림은 OSPF DBD(DataBase Description) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, 수신측 인터페이스의 IP 주소인 192.0.1.2이 목적지 주소로 사용되었다.

다음 그림은 OSPF LSU(Link-State Update) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데,멀티캐스트 주소인 224.0.0.5가 목적지 IP 주소로 사용되었다

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

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

목적지 노드가 동일한 경우에 Destination-Based 방식과 Packet-Based 방식의 로드 밸런싱이 어떤 차이를 보이는지에 대해서는 "다중경로 라우팅(4) - 동일 목적지 예제"에서 살펴보았다. 이번에는 목적지 노드가 다수인 경우(즉, 서비스 플로우들의 목적지가 다른 경우)에 대해서 살펴보겠다.
다음은 10개의 트래픽 플로우가 라우팅 경로가 중첩되는 다수의 목적지 노드로 향하는 경우의 예제망 구조
이다("다중경로 라우팅(1) - ECMP"의 예제망에서 확장). Client 노드에서 Server_1 ~ 10 노드로 향하는 트래픽 플로우는 "다중경로 라우팅(4) - 동일 목적지 예제"와 유사하게 100초마다 하나씩 트래픽을 발생시키도록 설정하였다(이는 트래픽 증가에 따른 로드 밸런싱 효과를 관찰하기 위해서이다).

로드 밸런싱이 Destination-Based 방식인 경우와 Packet-Based 방식인 경우에 Client 노드로부터 Server_1 ~ 10 노드로의 트래픽 전달 경로를 비교해보면 다음 그림과 같다. Destination-Based 방식인 경우 개별 트래픽 플로우는 하나의 라우팅 경로를 통해서만 전달되지만, 전체 트래픽 플로우 관점에서는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)된다. Packet-Based 방식인 경우 각 트래픽 플로우는 다중 경로를 통해 분산되어 전달(R1 -> R3 -> R4와 R1 -> R2 -> R4)된다.

R1 -> R2 링크와 R1 -> R3 링크의 트래픽유통량을 살펴보면 다음 그림과 같다.

두 방식 모두 다중 경로(R1 -> R2, R1 -> R3 링크)로 트래픽이 분산되었다. 하지만, Destination-Based 방식인 경우 다중 경로로 분산된 트래픽의 양이 불균등한 반면, Packet-Based 방식인 경우 다중 경로로 균등하게 분산되었음을 확인할 수 있다. 즉, 라우팅 경로가 중첩되는 다수 목적지에 대해서는 Packet-Based 방식보다 공평성이 떨어지기는 하지만, Destination-Based 방식도  로드 밸런싱 효과가 있다("다중경로 라우팅(3) - 로드 밸런싱" 참조).

"WiFi 모델에서의 통신 가능 거리(3)"에서 살펴본 것처럼 WiFi 노드간의 최대 거리는 300미터로 가정되지만, 이보다 먼 거리의 노드들간에도 시뮬레이션은 별 문제없이 수행된다. 그러면, 송신 파워만 충분히 높다면 WiFi 인터페이스를 사용하는 장비들간의 통신 가능 거리에 제약은 없는 것일까? 그렇지는 않은데, 그 이유는 ACK Timeout 때문이다.
IEEE 802.11에서는 DATA 프레임을 송신하면 ACK 프레임을 수신해야만 하며, 지정된 시간안에 ACK가 수신되지 않으면 송신에 실패한 것으로 간주한다. 이 때 ACK가 수신되기를 기다리는 최대 시간이 ACK Timeout 이다. 따라서, 노드간의 거리가 너무 멀어서 ACK Timeout 시간안에 ACK를 수신할 수 없을만큼 propagation delay가 큰 경우에는 통신이 이루어지지 않는다.
표준[1]에 따르면, ACK Timeout은 SIFS, Slot time, PHY-RX-START-Delay의 합으로 구성(ACKTimeout = SIFS + Slot Time + PHY-RX-START-Delay)되며, propagation delay는 Slot time 내에 포함된 것으로 간주된다. 다음은 PHY 종류별 Slot time을 정리한 것이다[1]. Slot time을 구성하는 다른 요소들을 모두 무시한다 할지라도 Slot time이 그리 크지 않으므로, 장거리 전송을 수용할 수 있는 여지는 크지 않다. (802.11에서 propagation delay는 원래 1us 이하로 가정되었다는 점을 잊지말기 바란다.) Slot time과 ACK Timeout을 변경시켜 전송 거리를 증대시킬 수는 있으나[2], 이는 802.11 표준[1] 범위를 벋어난 것이다.

Riverbed(OPNET) Modeler에서 ACK Timeout 값은 상대방이 최저 속도로 ACK 프레임을 전송(transmission)할 때를 가정하고 계산되며, 이 시간안에 응답 프레임에 대한 수신이 시작되면 timeout은 발생하지 않는다(이 부분은 표준[1]과 조금 차이가 있다). 따라서, propagation delay가 최저 속도로 ACK 프레임을 전송하는 transmission delay 미만이면 정상적으로 동작하므로, 전송 거리에 상당한 여분이 있는 편이다.

"30Km 거리에 대한 WiFi 통신 시뮬레이션 실험"에서, 11g로는 통신이 잘 되는데 11a로는 통신이 되지않는 것도 이러한 이유때문인 것으로 생각된다.

[1] IEEE Std 802.11, "Wireless LAN MAC and PHY Specifications", IEEE, 2007.
[2] http://www.air-stream.org/Change_ACK

TCP 영속(persistence) 타이머는 probe 세그먼트[1, 2]을 보내는 시간 간격을 조정하기 위하여 사용되며, Riverbed(OPNET) Modeler TCP 모델은 persistence 타이머 값을 지정할 수 있는 기능을 제공한다. 다음 그림은 사용자가 persistence 타이머 값을 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에는 실수값을 입력할 수 있으며 기본값은 1.0, 즉 1초이다.

[1] RFC 793, "TRANSMISSION CONTROL PROTOCOL", IETF, Sep. 1981.
[2] RFC 1122, "Requirements for Internet Hots -- Communication Layers", IETF, Oct. 1989.

SITL 모듈을 사용하는 시뮬레이션을 실행하다보면 다음 그림처럼 real-time ratio가 잘못 설정되었다는 오류 메시지가 보이는 경우가 있다.

오류 메시지의 내용을 자세히 살펴보면 다음과 같다. 즉,  SITL 모듈을 사용하기 위해서는 real-time ratio가 1로 설정되어야 하는데, 현재 1로 설정되어 있지 않다는 것이다.
----
<<< Warning >>>
Use of the SITL module typically requires a real-time ratio of 1.0.
The real-time ratio is currently set to 0.000.
Use the "sitl_realtime_ratio_check" preference to eliminate this warning.
----
이 오류를 해결하기 위해서는 시뮬레이션 설정창에서 Real-time execution ratio 속성을 1로 설정해주면 된다. Real-time execution ratio는 시뮬레이터 시간과 실세계 시간과의 비율이며, SITL 모듈을 사용하는 경우는 대부분 실세계 시스템과 연동이 필요하므로 시뮬레이터 시간이 실세계 시간과 동일한 속도로 진행되도록 조절할 필요가 있다. Real-time execution ratio 값 1은 시뮬레이터 시간이 실세계 시간과 동일한 속도로 흐르도록 한다는 의미이다.

GRP(Geographic Routing Protocol)는 MANET 라우팅 프로토콜 중 하나로써, 위치기반 라우팅 알고리즘을 사용한다. Riverbed(OPNET) Modeler에서 모델을 제공하는 다른 프로토콜들과는 달리, GRP는 OPNET사에서 자체적으로 개발[1]한 매우 독특한 프로토콜이다.
GRP는 표준 문서가 따로 없으며 Riverbed(OPNET) Modeler에서 제공하는 모델이 바로 표준이라고 볼 수 있다. 때문에 GRP에 대한 참고 문헌은 매우 부족한 편이다. Riverbed(OPNET) Modeler에서 제공하는 문서에는 GRP의 동작방식에 대해서는 거의 설명되어 있지 않으며, 몇 편의 논문들[2, 3, 4]에서 언급하고 있기는 하나 세부적인 사항에 대해서는 설명이 제한적이다. 따라서, GRP의 세부적인 동작에 대한 확인은 GRP 모델의 코드에 의존해야 하는 실정이다.

[1] OPNET Technologies, "Understanding MANET Model Internals and Interfaces", OPNETWORK2007, 2007.
[2] Li Zhiyuan, "Geographic Routing Protocol and Simulation", WCSE 2009, 2009.
[3] Rob Hussey, Earl Huff, Zabih Shinwari, and Vasil Hnatyshin, "A Comparative Study of Proactive and Reactive Geographical Routing Protocols for MANET", ICWN 13, 2013.
[4] Shuai Yang, Rngxi He, Sen Li, Bin Lin, Ying Wang, "An Improved Geographical Routing Protocol and its OPNET-based Simulation in VANETs", BMEI 2014, 2014.

윈도우에서 Visual Studio 2013을 컴파일러 사용하기 위한 환경 변수 설정. (Riverbed Modeler 18.0.3("Riverbed Modeler 18.0.3 발표" 참조)까지도 Visual Studio 2013 Express는 지원 컴파일러 목록에 포함되어 있지 않다. 하지만, 설치 및 동작에 큰 문제는 없는 것으로 보여진다.
Riverved(OPNET) Modeler를 위한 환경 변수 설정 방법은, Visual Studio 2010 버전 이후로는 동일하("Visual Sutdio 2010을 위한 환경 변수 설정" 참조)

1) VS2013 콘솔에서 "set INCLUDE"를 실행한다.
2) "INCLUDE=" 뒤부터 출력문을 복사한다.
3) 환경변수 입력창에서 시스템 변수에 "INCLUDE" 항목을 추가하고, 복사해둔 내용을 변수 값에 입력한다. (동일 항목이 기존에 존재하면, 값만 추가)
4) VS2013 콘솔에서 "set LIB"를 실행한다.
5) "LIB=" 뒤부터 "LIBPATH=" 전까지의 출력문을 복사한다.
6) 환경변수 입력창에서 시스템 변수에 "LIB" 항목을 추가하고, 복사해둔 내용을 변수 값에 입력한다. (동일 항목이 기존에 존재하면, 값만 추가)
7) VS2013 콘솔에서 "set Path"를 실행한다.
8) "Path=" 뒤부터 "C:\Windows\system32;"까지의 출력문을 복사한다.
9) 환경변수 입력창의 시스템 변수에서 "Path" 항목을 찾고, 본사해둔 내용을 변수 값에 추가한다.