네트워크 시뮬레이션 공방

Riverbed Modeler 18.13.0 발표

신상헌 — Mon, 20 Jul 2026 21:00:07 +0900

Riverbed Modeler 18.13.0 버전이 2026년7월15일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.12.1 발표" 참조). 이번에도 특이하게(?) 메일 공지가 있었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 주요 변경 사항으로 3가지가 적혀있기는 한데, 대부분 유지 보수에 대한 것들입니다. 모델 업데이트는 없다고 봐도 될 것 같습니다.

- New Supported Linux Platform
- Removal of ZigBee Model Suite
- Upgrade of Java to Version 17.0.19

New Supported Linux Platform은 Red Head Enterprise Linux 10 (v. 6.12 Linux kernel)을 지원하게 되었다는 것입니다. 이전 버전("Riverbed Modeler 18.12.1 발표" 참조)에서는 Red Head Enterprise Linux 9 (v. 5.14.0 Linux kernel)까지만 지원했었습니다.

Removal of ZigBee Model Suite은 ZigBee 모델 제품군이 표준 모델 라이브러리에서 제외되었다는 것입니다. 다만, IEEE 802.15.4 표준에 따른 LR-WPAN 모델은 계속 사용할 수 있으며, LR-WPAN MAC 및 PHY 계층 모델로 구성된 새로운 노드 모델인 wpan_station_partial 모델이 추가되었다고 합니다. (노드 모델만 새로 추가된 것이고, 프로토콜 관점에서의 기능 추가는 없는 것으로 짐작됩니다.)

Upgrade of Java to Version 17.0.19은 모델에서 사용하는 Java 버전이 Java 17.0.19_10으로 변경되었다는 것입니다. 이전 버전("Riverbed Modeler 18.12.1 발표" 참조)에서는 Java 17.0.18_8을 사용했었습니다.

그 외에 버그 수정사항 5건도 있습니다만, 특별히 관심이 가는 내용이 아니라서 생략합니다.

OSPF 이웃 프로세스(2) - 천이 순서

신상헌 — Mon, 20 Apr 2026 21:00:45 +0900

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

큰 범주에서 Adjacency 관계인 경우와 Adjacency 관계가 아닌 경우의 2가지로 구분되며, 이는 인터페이스 종류("OSPF 인터페이스 종류" 참조)와 DR/BDR 연부("OSPF DR(1) - 라우터 상태" 참조)에 따라 결정된다.

1) Adjacency 관계인 경우 : Point-to-point 네트워크이거나("OSPF 이웃 상태정보 확인" 참조), Broadcast/NBMA 네트워크에서 이웃이 DR/BDR인 경우("OSPF DR(3) - 이웃 상태" 참조)에 해당한다.
대부분의 경우 Point-to-point 네트워크에서는 Down -> Init -> DetAdj -> ExStart -> Exchng -> Loading-> Full 스테이트의 순서로, Broadcast/NBMA 네트워크에서는 Down -> Init -> DetAdj -> 2-Way -> DetAdj-> ExStart -> Exchng -> Loading -> Full 스테이트의 순서로 천이한다.

2) Adjacency 관계가 아닌 경우 : Broadcast/NBMA 네트워크에서 이웃이 DR/BDR이 아닌 경우("OSPF DR(3) - 이웃 상태" 참조)에 해당한다. Down -> Init -> DetAdj -> 2-Way 스테이트의 순서로 천이한다.

OSPF 이웃 프로세스(1) - State Diagram

신상헌 — Mon, 13 Apr 2026 21:00:16 +0900

OSPF에서 이웃(Neighbor)은 Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, Full 상태중 하나의 상태를 가지며[1, 2], "OSPF 이웃 상태정보 확인"에서 살펴본 것처럼 Riverbed(OPNET) Modeler OSPF 모델에서도 이웃 상태 변화/관리 기능을 제공한다.
다음 그림은 표준[1]에 기술된 이웃 상태 변화도를 보인 것이다. Hello 메시지("OSPF 메시지(2) - Hello 패킷 정보 확인" 참조) 교환에 의한 스테이트와 Database 메시지 교환에 의한 스테이트로 구성되어 있다.

다음 그림은 Riverbed(OPNET) Modeler OSPF 모델에 구현된 해당 프로세스 모델(ospf_neighbor_v2, "OSPF 프로세스 모델 구조" 참조)의 state diagram을 나타낸 것이다. 그림 형태가 조금 다를 뿐, 스테이트 및 천이관계는 표준[1]과 동일한 것을 알 수 있다.

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

Riverbed Modeler 18.12.1 발표

신상헌 — Thu, 2 Apr 2026 20:00:09 +0900

Riverbed Modeler 18.12.1 버전이 2026년2월19일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.12.0 발표" 참조). 홈페이지에는 2월18일로 표시되어 있는데, Release notes에 2월19일로 표시되어 있고 메일 공지도 2월19일에 이루어졌습니다. 이번에는 특이하게(?) 메일 공지가 있었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트가 1가지 있다고 적혀있기는 한데, 내용이 이전 버전(18.12.0 버전)내용과 동일합니다.

- Wireless LAN Model Enhancement – IEEE 802.11ax Support Phase-II

이 내용은 이전 버전(18.12.0 버전)과 완전히 동일합니다. 즉 새로운 모델 기능 추가는 없습니다.
18.11.1 버전("Riverbed Modeler 18.11.1 발표" 참조)처럼 모델 업데이트가 없다고 명시했으면 나았을텐데, 마치 이전 버전의 모델 업데이트 내용이 이번 버전에서 적용된 것처럼 적혀 있어서 많이 혼란스러웠습니다.

그나마, 모델러에서 사용하는 Java의 버전이 Java 17.0.18_8로 변경되어서, Release notes 전체적으로는 미세하게라도 이전 버전과 내용이 다르기는 하네요.

Riverbed Modeler 18.12.0 발표

신상헌 — Wed, 31 Dec 2025 19:21:36 +0900

Riverbed Modeler 18.12.0 버전이 2025년10월22일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.11.1 발표" 참조).  Release notes에는 10월17일자로 되어 있는데, 홈페이지에는 10월22일로 표시되어 있습니다. 아쉽게도, 이번에도 메일 공지가 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 1가지입니다.

- Wireless LAN Model Enhancement – IEEE 802.11ax Support Phase-II

WLAN 모델 개선 사항은 802.11ax High Efficient(또는 Wi-Fi 6 및 Wi-Fi 6E) 기술에 대한 것이며, 지원되는 특성은 다음과 같습니다.
  * DL OFDMA 사용시 DL 멀티 유저 지원
  * Triggered Response Scheduling (TRS)

또한, Red Hat Enterprise Linux 9 플랫폼을 지원하게 되었고, 모델러에서 사용하는 Java의 버전이 Java 17.0.16_8로 변경되었다고 합니다. 그 외에 버그 수정사항 1건도 있습니다만, 특별히 관심이 가는 내용이 아니라서 생략합니다.

WiFi 모델에서의 통신 가능 거리(9) - IP 트래픽(1)

신상헌 — Sun, 15 Jun 2025 21:14:49 +0900

802.11b 11Mbps 환경에서 237Bytes 크기의 MAC 사용자 패킷을 전송하는 경우에 거리에 따른 MAC 사용자 패킷 전달률(Throughput) 변화는 "WiFi 모델에서의 통신 가능 거리(5) - MAC Throughput(1)"에서 살펴본 바 있다.
이번에는 동일한 환경에서 IP 패킷을 전송하는 경우, 패킷 전달률이 어떻게 변화하는지 살펴보기로 하자. (얼핏 생각하면 패킷 전달률이 동일할 것처럼 생각할 수 있지만, 시뮬레이션 결과는 그렇지 않다는 것을 보여준다.)
2대의 WLAN 워크스테이션 노드를 배치하고, Physical Characteristics은 "Direct Sequence"로, Data Rate(bps)는 "11Mbps"로 설정한다. 트래픽은 Demand 타입의 Traffic Flow를 이용하여 237Bytes 크기의 패킷을 두 노드 사이에 전달하였다.

먼저, 1,024M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 100%)와는 약간 차이가 있지만 유사한 결과(전달률 약 99.32%)를 보여준다.

다음으로, 1,084M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 94.94%)와는 매우 큰 차이가 나는 결과(전달률 약 68.58%)를 보여준다.

다음으로, 1,116M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 71.25%)와는 매우 큰 차이가 나는 결과(전달률 약 15.93%)를 보여준다.

다음으로, 1,217M 거리에 두 노드를 배치하였을 때의 결과는 다음 그림과 같다. 앞의 시뮬레이션 결과(전달률 0.25%)와는 약간 차이가 있지만 유사한 결과(전달률 0.0%)를 보여준다.

즉, IP 트래픽 패킷을 사용하여도 BER이 낮을 때(거리가 가까울 때)는 MAC 사용자 패킷을 전송하는 경우와 비슷한 결과를 보여주지만, BER이 높을 때(거리가 멀 때)는 MAC 사용자 패킷을 전송하는 경우보다 훨씬 낮은 전달률을 보여준다. 왜 이런 차이가 발생하는 것일까? 그 이유는 IP 라우팅 때문이다.
IP 트래픽 패킷을 전송하기 위해서는 소스 노드의 IP 라우팅 테이블에 목적지에 대한 경로가 존재해야 한다. 만약 IP 라우팅 테이블에 경로가 존재하지 않으면, 패킷은 소스 노드의 IP 계층 하위로도 전송되지 않는다. 그런데, 라우팅 프로토콜 메시지도 IP 패킷이므로, BER이 높아지면 라우팅 프로토콜 메시지도 역시 잘 전달되지 못하고 라우팅 테이블 경로 구성에 실패하는 경우가 발생한다. 이 시점에 발생한 IP 트래픽 패킷은 모두 폐기되므로, BER이 높아지면 IP 트래픽 패킷의 전달률은 실제 MAC 계층의 전송 용량보다 크게 낮아지는 것이다.
다음은 이를 확인하기 위하여 소스 노드의 라우팅 테이블 정보를 중요 시간별로 관찰한 것이다. BER이 낮은 때(1,024M 거리)에는 라우팅 테이블상에 경로가 항상 구성되어 있음을 알 수 있다.

BER이 높을 때(1,084M 거리)에는 라우팅 테이블상에 경로 구성이 되지 않은 경우가 발생함을 알 수 있다.

OSPF 라우팅 테이블 구조

신상헌 — Fri, 2 May 2025 21:00:53 +0900

"라우팅/포워딩 테이블 예제(2) - OSPF"에서 살펴본 OSPF 라우팅 테이블 정보는 Riverbed(OPNET) Modeler 내부에서 다음 그림과 같은 구조로 저장된다.

Riverbed Modeler 18.11.1 발표

신상헌 — Mon, 3 Mar 2025 20:00:22 +0900

Riverbed Modeler 18.11.1 버전이 2024년12월10일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.11.0 발표" 참조). Release notes에는 12월16일자로 되어 있는데, 홈페이지에는 오히려 12월10일로 표시되어있습니다. 아쉽게도, 이번에도 메일 공지가 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 없으며, 다음과 같은 보안 업데이트만 적용되었습니다.

- Java Runtime Environment(JRE) 버전을 17.0.13으로 업그레이드
- Elastic Search libraries 제거

그동안 20년 넘게 OPNET(Riverbed Modeler)를 사용해왔지만, 이렇게 보안 패치만으로 버전업이 이루어지는 경우는 처음 보는 것 같습니다. 특이하네요.

Riverbed Modeler 18.11.0 발표

신상헌 — Fri, 28 Feb 2025 21:00:36 +0900

Riverbed Modeler 18.11.0 버전이 2024년8월30일자로 발표되었습니다(이전 버전에 관한 내용은 "Riverbed Modeler 18.10.0 발표" 참조).  Release notes에는 8월29일자로 되어 있는데, 홈페이지에는 8월30일자로 되어있습니다. 아쉽게도, 이번에도 메일 공지가 없었습니다.
Release notes를 통해 변경 사항을 살펴보았습니다. 모델 업데이트는 1가지입니다.

- Wireless LAN Model Enhancement – IEEE 802.11ax Support Phase-I

WLAN 모델 개선 사항은 802.11ax High Efficient(또는 Wi-Fi 6 및 Wi-Fi 6E) 기술을 지원하기 사작했다는
것입니다. 금번에 지원되는 특성은 다음과 같습니다.
  * 2.4 GHz, 5 GHz, 6 GHz 밴드에서 동작
  * 56-QAM 5/6, 1024-QAM 3/4, 1024-QAM 5/6 변조를 사용하는 고속 데이터 전송률
  * 3가지 GI 옵션 (GI-LTF와의 조합 포함)
  * HE PPDU 포맷(HE SU PPDU, HE TB SU PPDU, Nominal Packet Padding, LDPC coding)
  * maximum A-MPDU size 증가
  * basic NAV and intra-BSS NAV
  * 수신된 PPDU에 대한 Intra/inter-BSS 구분
  * BSS Color
  * TXOP duration-based RTS/CTS
  * Multi-TID A-MPDUs
  * non-AP HE STA의 버퍼 상태 보고
  * Contention free uplink access
  * Dynamic fragmentation – Level 1

그리고, WLAN 모델에서 Delayed Block ACK가 제거되었습니다.

또한, Red Hat Enterprise Linux 8 플랫폼을 지원하게 되었고, 모델러에서 사용하는 Java의 버전이 Java 17로 변경되었다고 합니다. 그 외에 버그 수정사항 4건도 있습니다만, 특별히 관심이 가는 내용이 아니라서 생략합니다.

TCP Duplicate SACK(1) - 파라미터 설정

신상헌 — Mon, 29 Jul 2024 21:00:19 +0900

OPNET Modeler는 17.1 버전부터 TCP Duplicate SACK[1]을 지원한다("OPNET Modeler 17.1 PL1 발표" 참조). 다음 그림은 사용자가 Duplicate SACK(D-SACK) 적용 여부를 설정할 수 있도록 OPNET TCP 모델에서 제공하는 속성을 보인 것이다.

이 속성에서 선택 가능한 값은 Disabled와 Enabled이며, Enabled를 선택하기 위해서는 SACK 속성 항목("TCP SACK(1) - 파라미터 설정" 참조)의 값이 Enabled 또는 Passive로 설정되어야만 한다. 기본값은 Enabled.

[1] RFC 2883, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", IETF, Jul. 2000.
[2] RFC 2018, "TCP Selective Acknowledgment Options", IETF, Oct. 1996.
[3] RFC 3708, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions, IETF, Feb. 2004.