네트워크 시뮬레이션 공방

ospf_interface_v2 프로세스 모델에서 DR 선출이 필요없는 경우와 DR 선출이 필요한 경우에 대한 스테이트 천이 과정은 "OSPF 인터페이스 프로세스(2) - 천이 순서"에서 살펴보았다. 이번에는 시뮬레이션 수행시에 실제로 이 분석 결과대로 천이가 일어나는지 ODB(OPNET Debugger)의 Show Animation 기능("무선망에서의 패킷 전송 애니메이션 보기" 참조)을 통해 확인해보도록 하자.
다음 그림은 DR 선출이 필요없는 경우의 스테이트 천이 애니메이션을 보기 위해 "OSPF 라우팅 예제"에서 사용한 시나리오를 활용한 예제망 구조를 나타낸 것이다.

R1 노드에서 R2 노드와 연결된 인터페이스를 담당하는 ospf_interface_v2 프로세스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Point-to-Point 스테이트 순서로 천이하는 것을 확인할 수 있다.

동일한 링크를 사용하는 R2 노드에서 R1 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. R1 노드에서와 마찬가리로 Down -> Point-to-Point 스테이트 순서로 천이하는 것을 확인할 수 있다.

다음 그림은 DR 선출이 필요한 경우의 스테이트 천이 애니메이션을 보기 위해 "OSPF DR(1) - 라우터 상태"에서 사용한 시나리오를 활용한 예제망 구조를 나타낸 것이다.

R1 노드에서 Hub 노드와 연결된 인터페이스를 담당하는 ospf_interface_v2 프로세스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Wating -> Calc DR -> DR Other 스테이트 순서로 천이하는 것을 확인할 수 있다.

R2 노드에서 Hub 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Wating -> Calc DR -> DR Other 스테이트 순서로 천이하는 것을 확인할 수 있다.

R3 노드에서 Hub 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Waiting -> Clac DR -> DR Other -> Calc DR -> Backup 스테이트 순서로 천이하는 것을 확인할 수 있다.

R4 노드에서 Hub 노드와 연결된 인터페이스의 스테이트 천이 애니메이션을 살펴보면 다음 영상과 같다. Down -> Waiting -> Calc DR -> DR 스테이트 순서로 천이하는 것을 확인할 수 있다.

이러한 천이 과정은 모두 "OSPF 인터페이스 프로세스(2) - 천이 순서"에서 살펴본 내용과 일치하는 것이다.

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

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

32비트 OS 시스템에서는 Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)까지만 사용할 수 있으며, 18.5.0 버전("Riverbed Modeler 18.5.0 발표" 참조)부터는 사용할 수 없다.
32비트 윈도우즈 시스템에서 18.5.0 이후의 버전을 설치하려고 하면, 다음 그림처럼 "Java VM 로드 중 Windows 오류 216 발생" 에러 메시지를 발생시키고 설치가 중지된다.

에러 메시지만 보고는 32비트 OS에 의한 제약점인지 파악하기가 쉽지 않다. 더군다나, 이런 중요한 사항이 release note에 제대로 기술되어 있지 않은 것은 사용자들에게 큰 혼란을 줄수 있다고 보여진다.

"GRP 쿼드런트 예제"에서 사용한 예제망에서 데이터 패킷이 전달되는 과정을 통해 GRP의 동작 결과를 좀 더 확인해보기로 하자. 시뮬레이션을 수행한 후, STA_1 노드에서 STA_8 노드로의 패킷 전달 경로를 살펴보면 다음 그림과 같다.

데이터 패킷은 STA_1 -> STA_2 -> STA_5 -> STA_8 경로로 전달되었음을 보여주고 있다. 이 경로가 사용된 이유를 좀더 세부적으로 살펴보면 다음과 같다.

- STA_1 -> STA_2 : STA_1 노드의 이웃 노드인 STA_2, STA_3, STA_4 노드중 (STA_8 노드가 속한) Ab3 쿼드런트와 가장 인접한 노드가 STA_2 노드이므로, STA_2 노드가 다음 홉으로 사용되었다("GRP 다음 홉 선정" 및 "GRP 쿼드런트와의 거리 계산" 참조).
- STA_2 -> STA_5 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 (STA_8 노드가 속한) Ab3 쿼드런트에 속한 노드가 STA_5 노드이므로, STA_5 노드가 다음 홉으로 사용되었다("GRP 다음 홉 선정" 참조).
- STA_5 -> STA_8 : STA_5 노드의 이웃 노드인 STA_2, STA_6, STA_7, STA_8 노드중 STA_8 노드가 동일한 Ab3 쿼드런트에 속해있으며 목적지이므로, STA_8 노드가 다음 홉으로 사용되었다.

TDMA 네트워크에는 각 멤버 노드들에 대한 자원 할당을 제어하는 네트워크 제어기(Network Controller)가 필요하다. Riverbed(OPNET) Modeler TDMA 모델에서는 별도의 제어기 노드 모델을 사용하지 않으며, 모든 TDMA 노드는 네트워크 제어기로 사용될 수 있다.
어느 노드가 네트워크 제어기로 동작할지의 여부는 사용자 설정에 따른다. 다음 그림은 사용자가 TDMA 네트워크 제어기 동작 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다. 하나의 TDMA 네트워크에는 한개의 네트워크 제어기만 동작하여야 하며, 복수 개의 네트워크 제어기가 동작하도록 설정해서는 안된다.

네트워크 제어기는 멤버 노드들에 대한 자원 할당을 제어하는 것외에 중계 역활도 수행한다. 네트워크 제어기 노드는 목적지가 자신이 아닌 데이터 패킷이 수신되면 다른 멤버 노드들이 받아볼 수 있도록 이를 다시 TDMA 네트워크로 재전송한다.

Riverbed(OPNET) Modeler에서 OSPF 인터페이스 관리를 담당하는 ospf_interface_v2 프로세스 모델의 구조는 "OSPF 인터페이스 프로세스(1) - State Diagram"에서 살펴보았다. 이번에는 OSPF 인터페이스 상태 변화에 따른 ospf_interface_v2 프로세스 모델 state diagram에서의 천이 과정을 살펴보기로 하자.
시뮬레이션이 시작된후 OSPF 라우팅 테이블이 완성되기까지(즉, 인터페이스가 처음 활성화 된후 장애가 발생하지 않은 경우)의 상태 천이 과정을 추적해보면 다음 그림과 같다.

큰 범주에서는 DR 선출이 필요없는 경우와 DR 선출이 필요한 경우의 2가지 구분되며, 이는 인터페이스 종류("OSPF 인터페이스 종류" 참조)에 따라 결정된다.

1) DR 선출이 필요없는 경우("OSPF 라우팅 예제" 참조) : Point-to-point 인터페이스일 때만 해당하며, Down -> Point-to-Point 스테이트의 순서로 천이한다. DR 선출이 필요없으므로 상태천이 과정이 매우 단순한다.

2) DR 선출이 필요한 경우("OSPF DR(1) - 라우터 상태" 참조) : Broadcast, NBMA 등의 인터페이스일 때에 해당하며, 해당 노드가 DR 또는 BDR 노드로 선출되는가에 따라 천이 과정이 달라진다.
2-1) DR 노드로 선출되는 경우: Down -> Waiting -> Calc DR -> DR 스테이트의 순서로 천이한다.
2-2) BDR 노드로 선출되는 경우: Down -> Waiting -> Clac DR -> DR Other -> Calc DR -> Backup 스테이트의 순서로 천이한다.
2-3) DR/BDR 노드로 선출되지 않는 경우 : Down -> Wating -> Calc DR -> DR Other 스테이트의 순서로 천이힌다.

EIGRP에서 제공하는 UCMP에서는 Traffic Share 속성을 추가로 사용하여 로드 밸런싱(부하 분산)을 더 세밀하게 조정할 수 있음을 "다중경로 라우팅(9) - UCMP에서의 로드 밸런싱"에서 살펴보았다. 이번에는 Traffic Share 방법으로 Balanced 방식을 선택했을 때와 Minium 방식을 선택했을 때 동작이 어떻게 차이나는지 예제를 통해 확인해보도록 하자.
다음 그림은 Traffic Share 방법간의 차이를 비교하기 위하여, "다중경로 라우팅(7) - UCMP"에서 사용한 시나리오를 수정하여 작성한 시험망의 구조를 나타낸 것이다. R1 노드와 R4 노드 사이에 R5 노드를 배치하고 R1 <-> R2, R2 <-> R4 링크와 동일한 대역폭을 가지는 링크로 연결하였다.

Traffic Share 방법이 Minimum 방식일 경우와 Balanced 방식일 경우의 라우팅 경로를 비교해보면 다음 그림과 같다. Minimum 방식일 때에는 최소 metric 값을 가지는 2개의 경로만 사용되었지만, Balanced 방식일 때에는 최소 metric 비용을 가지는 경로를 포함하여 3개의 경로가 사용되었음을 확인할 수 있다.

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

Minimum 방식일 때에는 대역폭이 큰(즉, 최소 metric 값을 가지는) R1 -> R2 링크와 R1 -> R5 링크로만 트래픽이 분산되었지만, Balanced 방식일 때에는 대역폭이 작은(즉, 비용이 큰) R1 -> R3 링크로도 일부 트래픽이 분산되었음을 확인할 수 있다.

RREQ_RETRIES는 RREQ 메시지의 최대 재전송 횟수를 지정하기 위하여 사용되며, Riverbed(OPNET) Modeler AODV 모델은 RREQ_RETRIES 값을 지정할 수 있는 기능을 제공한다. 다음 그림은 사용자가 RREQ_RETRIES 값을 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

0 이상의 정수값을 입력할 수 있으며, 기본값은 5 이다.

어플리케이션 모델을 사용할 때 트래픽 발생 패턴은에 큰 영향을 미치는 프로파일 타이밍과 어플리케이션 타이밍 설정에 대해서는 "어플리케이션 사용 패턴(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.