네트워크 시뮬레이션 공방

Riverbed(OPNET) Modeler TCP 모델에서는 사용자 편의를 위하여 TCP 버전 및 OS별로 속성값들이 조정된 TCP 프로파일("OS별 TCP 프로파일 (16.1 버전)" 참조)을 제공한다. 새로운 OS가 등장함에 따라 OS별 기본 프로파일의 추가가 이루어져왔으며("OPNET Modeler 17.1 PL1 발표" 참조), 17.5 버전("OPNET Modeler 17.5 PL6 발표" 참조)에서 제공되는 TCP 프로파일은 Windows 7, Andriod, FreeBSD 8.2, HP-UX 10.x/11.x, iPad, iPhone, Linux 2.6, Mac OS X, NT (3.5/4.0), Solaris 2.6, Solaris 2.7, Solaris 2.8, Solaris 2.9, Windows 98, Windows 2000, Windows Server 2003, Windows Server 2008, Windows Vista, Windows XP, Tahoe, Reno, New Reno, SACK, Full-Featured, Default 이다.
16.1 버전후에 새롭게 추가된 프로파일 중 자주 사용되는 프로파일의 세부 속성항목들의 값을 살펴보면 다음 표와 같다.

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 노드에서는 응답을 하지않아 중간 경로 확인은 불가능함을 알 수 있다.