네트워크 시뮬레이션 공방

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

어플리케이션 타이밍("어플리케이션 사용 패턴(1) - 파라미터 설정" 참조)을 조절하여 하나의 어플리케이션이 프로파일내에서 일정 시간 간격으로 반복 실행되도록 만들수 있음은 "어플리케이션 사용 패턴(3) - 어플리케이션 반복 예제"에서 살펴보았다. 트래픽을 원하는 시간 간격마다 반복해서 발생시키는 또 다른 방법은 어플리케이션이 포함되어 있는 프로파일의 타이밍을 조절하여 어플리케이션이 반복적으로 실행되도록 하는 것이다.

"어플리케이션 사용 패턴(1) - 파라미터 설정"에서 살펴보았듯이, 프로파일의 실행시간은 Duration에 의해 지정되며, 실행간의 간격은 Inter-repetition Time에 의해 지정된다. 따라서, 이 두 값을 조정하면 시뮬레이션 실행시간동안 프로파일이 일정 시간 간격으로 반복 실행되도록 만들수 있다.
프로파일 타이밍의 Duration은 200초, Inter-repetition Time은 300초로 설정하였을 때, Client로 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.

200초 길이의 트래픽 발생 구간이 300초 간격을 두고 계속 반복되는 것을 확인할 수 있다.

Duration은 100초, Inter-repetition Time은 400초로 설정하였을 때, Client로 노드로 전송되는 트래픽을 살펴보면 다음 그림과 같다.

100초 길이의 트래픽 발생 구간이 400초 간격을 두고 계속 반복되는 것을 확인할 수 있다.

Destination only flag 정보는 RREQ 메시지("AODV 메시지(2) - RREQ 구조체" 참조)에서 사용되며, RREQ에 대한 응답을 중간 노드에서 대신 처리할지의 여부를 알린다[1]. 다음 그림은 사용자가 Destination only flag사용 여부를 설정할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

설정 가능한 값은 Enabled와 Disabled이다.

- Enabled : 목적지 노드만 RREQ에 대한 응답 RREP를 생성함.
- Disabed : 목적지 노드뿐만 아니라 경로상 목적지 노드 이전에 위치한 중간 노드도 RREQ에 대한 응답 RREP를 생성할 수 있음.

[1] RFC 3561, "Ad hoc On-Demand Distance Vector (AODV) Routing", IETF, July 2003.

"라우팅 테이블과 포워딩 테이블"에서 살펴본 것처럼, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포위딩 테이블은 완전히 분리되어 별도로 저장된다. 하지만, "라우팅/포워딩 테이블 예제(1) - RIP"와 "라우팅/포워딩 테이블 예제(2) - OSPF"에서 살펴본 예제에서는 두 테이블에 저장되어 있는 정보의 내용은 동일하였다.
그러면, 두 테이블에는 항상 동일한 정보가 저장되는 것일까? 그렇지는 않다. 이제 또 다른 예제를 통해 라우팅 테이블과 포워딩 테이블에 서로 다른 정보가 저장될 수도 있음을 확인해보기로 하자. 다음은 "RIP 라우팅 예제"에서 사용한 시나리오를 수정하여 작성한 시험망 토폴로지이다.

Client <-> R1, R1 <-> R2, R2 <-> R4, R4 <-> Server 구간에는 RIP를 적용하였고, R1 <-> R3, R3 <-> R4 구간에는 OSPF를 적용하였다. 이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 RIP 라우팅 테이블, OSPF 라우팅 테이블, IP 포워딩 테이블을 비교하여 살펴보면 다음 그림과 같다.

R1 노드에는 RIP와 OSPF가 모두 실행되므로 RIP 라우팅 테이블과 OSPF 라우팅 테이블이 각각 만들어지며, IP 포워딩 테이블에는 RIP 라이팅 테이블 정보와 OSPF 라우팅 테이블 정보가 모두 취합되어 있는 것을 확인할 수 있다. (실제 망에서 라우팅 프로토콜을 이렇게 구성하는 경우는 거의 없을 것이라는 점에서 좋은 예제는 아니다. 하지만, Riverbed(OPNET) Modeler에서 라우팅 테이블과 포워딩 테이블의 관계를 이해하는데는 도움이 될 것이다.)

다음 그림은 Riverbed(OPNET) Modeler ICMP 모델에서 사용하는 패킷 포맷과 fields 필드에 실리는 정보를 나타낸 것이다.

ip_icmp 패킷은 ICMP 메시지를 위한 컨테이너 패킷이며, 실제 ICMP 메시지는 echo_packet 필드에 실린다. 어떤 ICMP 메시지가 실려있는지는 fields 필드에 실려있는 IpT_Icmp_Packet_Fields 구조체의 message_type 정보를 통해 구분할 수 있다. 이러한 구조는 다양한 ICMP 메시지들을 공통으로 사용하는 단일 ICMP 패킷을 통해 처리하기 위한 의도인 것으로 생각된다.
하지만, "ip_icmp 프로세스 모델"에서 살펴보았듯이 Riverbed(OPNET) Modeler 18.0.3 버전("Riverbed Modeler 18.0.3 발표" 참조)에서는 ICMP 메시지들[1, 2]중 Echo/Echo Reply 메시지만 사용되므로, 실제적으로는 이 구조가 특별한 의미를 가지지 못하고 사용자들에게 혼란을 주는 면이 있다.

[1] RFC 792, "Internet Control Message Protocol", IETF, 1981. 
[2] https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

GRP에서 backtrack 기능("GRP Backtrack" 참조)이 어떻게 동작하는지 예제를 통해 살펴보도록 하자. 다음은 backtrack 동작을 살펴보기 위한 예제망 구조이다. 쿼드런트("GRP 쿼드런트" 참조) 크기는 2Km로 설정하였으며, 트래픽은 STA_1 노드에서 STA_16 노드로 향하도록 하였다.

시뮬레이션을 수행한 후 데이터 패킷이 전달된 경로를 확인("GRP 라우팅 경로 확인하기" 참조)해보면 다음 그림과 같이 STA_1 -> STA_2 -> STA_5 -> STA_7 -> STA_13 -> STA_16 경로가 사용되었다.

그런데, ODB를 사용하여 데이터 패킷이 각 노드를 거쳐 전달되는 과정을 자세하게 추적해보면, 실제로는 다음 그림과 같이 STA_1 -> STA_4 -> STA_1 -> STA_2 -> STA_4 -> STA_2 -> STA_5 -> STA_7 -> STA_13 -> STA_16 경로를 거쳤음을 보여준다.

여기에서 STA_4 노드에서 STA_1 노드로, STA_4 노드에서 STA_2 노드로 되돌려진 과정이 바로 backtrack이다. 그러면, 왜 이렇게 backtrack이 발생한 것일까? 그 이유는 목적지 쿼드런트와의 거리계산 방식("GRP 쿼드런트와의 거리 계산" 참조)때문이다. 다음 그림은 이를 확인하기 위하여 STA_1 노드에 구성된 목적지 테이블을 분석한 결과를 토폴로지상에 표시한 것이다.

이제 이 쿼드런트 정보를 사용하여 각 단계별로 다음 홉이 선정된 이유를 살펴기로 하자.

(1) STA_1 -> STA_4 : 목적지 노드인 STA_16은 쿼드런트 B에 속해있으며, STA_1 노드의 이웃 노드인 STA_2, STA_3, STA_4 노드중 쿼드런트 B와의 거리가 가장 가까운 노드는 STA_4 노드이므로("GRP 쿼드런트와의 거리
계산" 참조), 데이터 패킷은 STA_4 노드로 전달된다.

(2) STA_4 -> STA_1 : STA_4 노드에서는 자신보다 쿼드런트 B에 더 가까운 이웃 노드를 찾을 수 없으므로, 이전 노드인 STA_1 노드로 패킷을 되돌림(backtrack)한다("GRP Backtrack" 참조).

(3) STA_1 -> STA_2 : STA_1 노드에서는 backtrack된 경로를 제외하고 쿼드런트 B에 가장 가까운 노드인 STA_2 노드로 데이터 패킷을 전달한다.

(4) STA_2 -> STA_4 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 쿼드런트 B와의 거리가 가장 가까운 노드는 STA_4 노드이므로, 데이터 패킷을 STA_4 노드로 전달한다.

(5) STA_4 -> STA_2 : STA_4 노드에서는 자신보다 쿼드런트 B에 더 가까운 이웃 노드를 찾을 수 없으므로, 이전 노드인 STA_2 노드로 패킷을 되돌림(backtrack)한다.

(6) STA_2 -> STA_5 : STA_2 노드의 이웃 노드인 STA_1, STA_4, STA_5 노드중 쿼드런트 B와의 거리가 자신보다 가까운 STA_5 노드로 데이터 패킷을 전달한다.

(7) STA_5 -> STA_7 : STA_5 노드의 이웃 노드인 STA_2, STA_6, STA_7, STA_8 노드중 쿼드런트 B와의 거리가 가장 가까운 노드인 STA_7 노드로 데이터 패킷을 전달한다.

(8) STA_7 -> STA_13 : STA_7 노드의 이웃 노드인 STA_5, STA_8, STA_13 노드중 STA_13 노드가 목적지 쿼드런트에 위치하므로, STA_13 노드로 데이터 패킷을 전송한다.

(9) STA_13 -> STA 16 : STA_13 노드의 이웃 노드중에 목적지 노드인 STA_16 노드가 있으므로, STA_16 노드로 데이터 패킷을 전송한다.

Riverbed Modeler의 Urban Propagation Model에 대한 제공 중단이 지난 10월15일자로 아래와 같이 공지되었습니다.

Urban Propagation Model은 Riverbed Modeler 18.0 버전("Riverbed Modeler 18.0 발표" 참조)에서 발표되었던 Urban Propagation Module을 가리키는 것으로 보입니다.
기존에는 Release note에나 포함되었을 법한 내용인데, 이렇게 별도의 공지 메일을 통해 알려주네요. (Modeler 신규 버전 발표는 메일 공지를 잘 안해주면서, 이런 사소한(?) 변경은 또 이렇게 메일 공지를 해주니 당황스럽네요.)

RIP를 사용할 때의 라우팅 테이블과 포워딩 테이블의 비교는 "라우팅/포워딩 테이블 예제(1) - RIP"에서 살펴본 바 있다. 이번에는 OSPF를 사용할 때의 라우팅 테이블과 포워딩 테이블을 비교해 보기로 하자.
예제망은 "OSPF 라우팅 예제"에서 사용한 것을 사용하였다.

이 예제망에 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블과 포워딩 테이블을 비교하여 살펴보면 다음 그림과 같다. ("OSPF 라우팅 예제"에서는 아래의 포워딩 테이블을 라우팅 테이블 정보를 살펴보기위해서 사용하였지만, 정확하게 말하자면 포워딩 테이블이다).

정보의 항목에서는 조금 차이가 있지만, 저장되어 있는 정보의 내용은 동일한 것을 알 수 있다. 다만, Metric 항목은 RIP의 경우("라우팅/포워딩 테이블 예제(1) - RIP" 참조)와는 달리 라우팅 테이블과 포워딩 테이블에 저장된 값이 조금 차이가 있다. 그리고, OSPF 라우팅 테이블의 일부 정보 항목은 IP 라우팅 테이블에 저장되지 않는 것도 RIP와의 차이점이다.

TDMA 네트워크에서 데이터 전송을 위해서는 슬롯을 할당받아야만 하며 다음 그림은 그 절차를 보인 것이다. (논리적인 이해를 돕기위해 전파지연 시간은 무시하였다.)

동적 할당을 받아야하는 멤버 노드는 전송할 데이터가 있을 경우 제어 슬롯(control slot)을 이용하여 네트워크 제어기("TDMA 네트워크 제어기" 참조) 노드로 자원(슬롯) 할당 요청 메시지를 보낸다. 네트워크 제어기는 다음 프레임의 시작 시점에 고정 할당과 동적 할당("TDMA 자원할당 방식" 참조)에 대한 슬롯 할당을 수행하고, 슬롯 할당 정보를 멤버 노드들에게 알려준다. 멤버 노드는 자신이 할당받은 데이터 슬롯(data slot)을 사용하여 데이터를 전송한다.

Riverbed(OPNET) Modeler OSPF 모델에서 라우팅 테이블의 수렴(convergence) 여부는 특정 convergence activity 이후 "일정 간격" 동안 convergence activity가 없는지(즉, 일정 시간 간격 동안 라우팅 테이블 갱신이 없는지)의 여부를 통해 판단한다("OSPF 수렴 시간 (1) - Convergence Duration" 참조).
이 "일정 간격"은 기본적으로 시뮬레이션 실행시의 "Routing Activity Idle Timer (seconds)" 속성값에 의해 정해진다.

다만, OSPF에서는 라우팅 테이블 갱신 작업이 SPF Hold Time에 의해 연기될 수 있으므로 SPF Hold Time 범위내의 시간 값도 같이 고려된다.