네트워크 시뮬레이션 공방

Riverbed(OPNET) Modeler SITL 모듈 사용시 시나리오상에 배치한 라우터나 단말 노드가 tracert[1]에는 정상적으로 응답하지 않는 문제(?)가 있음은 "SITL tracert 예제(1)"에서 확인하였다.
그 원인은 tracert에서는 ping 요청(ICMP Echo Request)에 대한 응답으로 ICMP Echo Reply 메시지외에 ICMP Time Exceeded 메시지[2]도 사용되는데[3], Riverbed(OPNET) Modeler에는 이에 대한 처리 기능이 구현되어 있지 않기 때문("ip_icmp 프로세스 모델" 참조)이다. 즉, tracert가 정상적으로 동작하기 위해서는 중간 노드에서 TTL 값이 만료된 ICMP 패킷에 대해 Time Exceeded 메시지로 응답해 주어야만 한다. 하지만, Riverbed(OPNET) Modeler에서는 TTL 값이 만료된 IP 패킷은 모두 폐기 처리하므로("IP 패킷 TTL 처리"와 "ICMP 패킷 처리 절차" 참조), tracert가 정상적으로 동작하지 못하는 것이다.

[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

tracert 명령어를 Riverbed(OPNET) Modeler SITL 모듈과 연동시켜 사용할 경우 정상적으로 동작하지 않음은 "SITL tracert 예제(1)"에서 살펴보았다. 이를 명확히 하기 위해서 좀 더 복잡한 망 구조에서 다시 확인해보도록 하겠다.
다음은 "SITL Ping 예제(2)"의 시험망에서 Access_2 노드를 상대로 tracert 명령어를 사용했을 때의 결과를 보인 것이다.

Access_2 노드는 SITL 게이트웨이로부터 4홉 거리에 있으며, ping 요청에 대해서 정상적으로 응답하였다. 하지만, 중간에 위치한 Access1, R2, R1 노드에서는 응답을 하지않아 중간 경로 확인은 불가능함을 알 수 있다.

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

Riverbed(OPNET) Modeler 시나리오상에 배치한 라우터나 단말 노드로 ping 요청을 보내고 응답을 받는 것이 가능함은 "SITL Ping 예제(1)"에서 살펴보았다. 이번에는 좀 더 복잡한 망 구조에서도 이러한 시험이 가능함을 확인해보도록 하겠다.
다음은 좀 더 복잡한 망 구조에서 ping 응답 시험을 위한 포토로지 구성과 IP 주소 설정을 보인 것이다.

SITL GW를 통해 연동된 실장비에서 시나리오상의 Access_2 노드(라우터)로 ping 요청을 보냈을 경우의 결과는 다음과 같다. 라우터 여러 대를 거쳐서도 ping 응답이 정상적으로 수신되는 것을 확인할 수 있다.

"SITL에서 지원하는 프로토콜의 종류"에서 설명하였듯이 Riverbed(OPNET) Modeler SITL 모듈은 ICMP에 대한 패킷 변환을 지원하며, Riverbed(OPNET) Modeler 시나리오상에 배치한 라우터나 단말 노드에 대해서 ping 요청을 보내고 응답을 받는 것이 가능하다. (일종의 Real-Sim 형태의 시뮬레이션이다.)
다음은 이러한 ping 응답 시험을 위한 토폴로지 구성("SITL을 통해 전달된 실제 PDU를 시뮬레이터에서 처리하기" 참조)과 IP 주소 설정을 보인 것이다.

SITL GW를 통해 연동된 실장비에서 시나리오상의 R1 노드(라우터)로 ping 요청을 보냈을 경우의 결과는 다음과 같다. 응답이 정상적으로 수신되는 것을 확인할 수 있다.

또한 시나리오상의 Server_1 노드(단말)로 ping 요청을 보냈을 경우의 결과는 다음과 같다. 라우터와 동일하게 ping 응답이 정상적으로 수신되는 것을 확인할 수 있다.

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

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

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은 시뮬레이터 시간이 실세계 시간과 동일한 속도로 흐르도록 한다는 의미이다.

시스템 성능에 비하여 과도한 트래픽이 사용된 것이 아님에도 불구하고, 시스템 NIC에 수신된 패킷이 Riverbed(OPNET) SITL 게이트웨이로 넘겨지는 과정에서 일부가 누락되는 경우가 있다. VLC 프로그램을 사용하여 비디오 스트리밍 트래픽을 발생시키는 경우에 이러한 현상이 확인되었으며, 그 원인은 패킷 간격때문인 것으로 생각된다.

1) 다음 그림은 Gigabit 이더넷 인터페이스를 통해 Iperf로 30Mbps 트래픽을 발생시켰을 때 수신된 패킷 간격을 측정한 것이다. 패킷 간격이 수백us인 것을 확인할 수 있으며, Riverbed(OPNET) SITL GW에서 패킷 누락없이 처리된다.

2) 다음 그림은 VLC를 사용하여 평균이 수Mbps인 트래픽을 발생시켰을 때 수신된 패킷 간격을 측정한 것이다. 패킷들이 집중된 구간에서는 때때로 수us 간격으로 패킷이 수신되는 것을 확인할 수 있으며, Riverbed(OPNET) SITL GW
에서 패킷 누락이 발생한다.

시뮬레이션상의 노드와 실세계 장비간에 직접 통신이 일어나는 Real-Sim 형태의 SITL 시뮬레이션을 수행할 경우 실장비에서 생성한 패킷을 Riverbed(OPNET) Modeler에서 해석할 수 있어야 하다, 반대로 Riverbed(OPNET) Modeler에서 생성한 패킷도 실장비에서 사용할 수 있어야 한다.

하지만, "SITL에서 지원하는 프로토콜의 종류"에서 살펴본 것처럼 SITL에서는 UDP/TCP 계층보다 상위 계층 프로토콜에 대해서는 변환을 지원하지 않는다. 따라서, Real-Sim 형태의 SITL 시뮬레이션시에는 사용되는 트래픽의 UDP/TCP 상위계층 프로토콜에 대해서 PDU를 직접 생성하고 해석하는 기능을 사용자가 구현해 주어야만 한다.

Riverbed Modeler(OPNET) SITL에서 시뮬레이션 패킷과 실세계 패킷 간의 패킷 변환을 지원하는 프로토콜 종류에 대해서는 "SITL에서 지원하는 프로토콜의 종류"에서 살펴보았다. 그러면, 여기에 해당하지 않는 프로토콜 패킷은 어떻게 처리되는지 좀더 살펴보기로 하자.
현재 대부분의 네트워크 장비는 IP 프로토콜을 사용하므로, 네트워크 계층 프로토콜을 SITL을 통해 연동시키는 것에서는 문제가 거의 발생하지 않는다. 문제는 NetBIOS나 RTP처럼 종단 단말간에 전달되는 상위계층 프로토콜에서 발생한다("SITL 사용시 NetBIOS 트래픽 처리" 참조). 이렇게 패킷 변환이 지원되지 않는 프로토콜의 패킷이 SITL 게이트웨이에 도착하였을 때의 처리 결과를 시뮬레이션 시나리오 및 파라미터 설정상태에 따라 구분하여 정리해보면 다음과 같다.

1) Riverbed Modeler(OPNET)을 통과(Passthrough)하는 패킷을 때 : 해당 페이로도를 unformatted 패킷에 담아 전달한다. 최종적으로 Riverbed Modeler(OPNET) 외부에서 해석될 것이므로 문제가 되지 않는다.

2) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 패킷일 때 : SITL 게이트웨이의 "Drop Real Packet If Translation Fails" 속성 설정값에 따른다. "Drop Real Packet If Translation Fails" 속성이 Enabled이면(기본값이 Enabled이다), 전달하지 않고 폐기한다. 해당 속성이 Disabled이면, 페이로드를 unformatted 패킷에 담아 전달한다.

3) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 브로드캐스트 패킷일 때 : SITL 게이트웨이의 "Drop Real Packet If Translation Fails" 속성 설정값과는 상관없이 페이로드를 unformatted 패킷에 담아 전달한다. "SITL 사용시 NetBIOS 트래픽 처리" 예에서 문제가 발생한 이유도 NetBIOS 패킷들이 브로드캐스트 주소를 사용하기 때문이다.

여기에서 한 가지 유의해야할 사항은 "2) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 패킷일 때"의 경우와 "3) Riverbed Modeler(OPNET) 시나리오 상의 노드를 목적지로 하는 브로드캐스트 패킷일 때"의 경우에 있어 unformatted 패킷으로 변환되는 페이로드 레벨이 다를 수 있다는 점이다. 즉, unformatted 패킷으로 변환하는 페이로드 레벨은 2)의 경우 SITL 게이트웨이 노드의 "Maximum Packet Translation Level" 속성값에 의해 결정된다. 하지만, 3)의 경우에는 "Maximum Packet Translation Level for Passthrough" 속성값에 의해 결정된다(단, SITL GW와 맵핑된 NIC에서 발생시킨 패킷은 항상 "Maximum Packet Translation Level for Passthrough" 속성값이 2일 때와 동일하게 처리된다. 즉, UDP 헤더부터 unformatted 패킷에 담겨서 처리된다).