네트워크 시뮬레이션 공방

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 스테이트의 순서로 천이힌다.

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.

Riverbed(OPNET) Modeler에서 OSPF 프로토콜 기능은 여러 개의 프로세스 모델로 분할되어 수행된다. 다음 그림은 관련 프로세스 모델간의 생성 관계를 나타낸 것이다. 이해하기 쉽도록 가상 인터페이스(Virtual Interface) 프로세스 모델은 생략하였다.

각 프로세스 모델의 주요 기능은 다음과 같다.

- ospf_v2 : OSPF 변수들을 생성/초기화하고, 필요한 child 프로세스를 생성한다.

- ospf_process : 라우팅 테이블을 관리하고, 제어 메시지를 처리한다.

- ospf_interface_v2 : OSPF 인터페이스의 상태(state)를 관리한다.

- ospf_neighbor_v2 : OSPF 이웃(neighbor) 노드의 상태(state)를 관리한다.

OSPF Broadcast 모드는 Broadcast(BMA) 네트워크에서 사용되는 방식이고, OSPF NBMA 모드는 NBMA 네트워크에서는 사용되는 방식이다. 두 방식은 모두 DR을 사용("OSPF DR(1) - 라우터 상태" 참조)한다는 점에서는 동일하다. 그러면, Broadcast 모드와 NBMA 모드의 차이점은 무엇일까? 그것은 두 방식에서 사용하는 목적지 IP 주소이다.
Broadcast 모드에서는 유니캐스트 주소뿐만 아니라 멀티캐스트 주소가 함께 사용되지만("OSPF DR(5) - 메시지 Encapsulation" 참조), NBMA 모드에서는 유니캐스트 주소만 사용되며 멀티캐스트 주소는 사용되지 않는다("OSPF NBMA 모드" 참조). 다음의 표는 이를 비교한 것이다.

바꾸어 말하자면, Broadcast 모드로 동작하기 위해서는 MAC 계층에서 멀티캐스팅을 지원해야만 한다.

NBMA(Non-Broadcast Multi-Access) 네트워크에서는 OSPF가 NBMA 모드로 동작할 수 있음을 "OSPF NBMA 모드"에서 살펴보았다. OSPF가 NBMA 모드로 동작하기 위해서는 이웃 라우터들에 대한 정보가 필요하며[1], 실 장비에서는 neighbor 명령어를 통해 설정된다[2, 3].
NBMA 네트워크에서 브로드캐스팅을 통해 이웃 라우터를 발견할 수 없는 것은 모든 라우터에 해당하므로, 이웃 정보 설정은 원칙적으로 모든 라우터에서 해주어야 한다. 하지만, 어느 라우터가 DR로 선출될지 미리 알고 있다면("OSPF DR(2) - Router Priority" 참조), DR로 선출될 라우터에만 이웃 정보 설정을 해주어도 NBMA 모드로 동작하는 것이 가능하다.
다음은 이를 확인하기 위하여 "OSPF NBMA 모드"에서 사용한 시나리오를 수정하여 작성한 시험망 구조이다. R2 노드의 Neighbor List만 남겨두고, R1, R3, R4 노드의 Neighor List 정보는 모두 삭제하였으며, Priority를 조절하여 R2 노드가 DR로 선출되도록 하였다.

Client 노드에서 Server 노드로 향하는 트래픽의 송/수신량을 살펴보면 다음과 같다. Client 노드에서 Server 노드로 트래픽이 잘 전달되고 있음을 확인할 수 있다.

Neighbor List를 R2 노드에만 설정해주었다고해서, 이 트래픽이 R2 노드를 거쳐서 전달되는 것이 아니라는 것은 다음 그림처럼 R1 노드에서 ATM_SW 노드로 전달되는 트래픽과, AMT_SW 노드에서 R2, R4 노드로 전달되는 트래픽을 비교해보면 명확하게 알 수 있다.

[1] RFC 2328, "OSPF Version 2", IETF, Apr. 1998.
[2] http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/13690-18.html
[3] http://egloos.zum.com/light99/v/5159722

NBMA 모드는 NBMA(Non-Broadcast Multi-Access) 네트워크에서 OSPF가 동작하는 방식 중 한가지[1]이며,  Riverbed(OPNET) Modeler OSPF 모델도 이를 지원한다. OSPF를 NBMA 모드로 동작시키려면, OSPF의 해당 인터페이스 Type 속성을 Non-Broadcast로 설정해주면 된다("OSPF 인터페이스 종류" 참조).
다음은 OSPF가 NBMA 모드로 동작하고 있음을 확인하기 위한 시험망 구조이다. "OSPF DR(1) - 라우터 상태"에서 사용한 시나리오를 수정한 것으로, R1, R2, R3, R4 노드간을 Non-Broadcast Multi-Access 방식인 ATM으로 연결하였다.

OSPF NBMA 모드 시뮬레이션을 위해 할당한 IP주소 내역은 다음과 같다.

이 때, R1, R2, R3, R4 노드에 구성된 OSPF 인터페이스 정보를 ODB를 통해 살펴보면 다음과 같다.

192.0.3.x 네트워크에 대하여 R4 노드가 DR로, R3 노드가 BDR(Backup DR)로 동작하고 있음을 확인할 수 있다. DR(Designated Router)은 Broadcast 모드와 NBMA 모드에서만 사용되므로[1], OSPF가 현재 Point to Point 모드나 Point to Multipoint 모드로 동작중이 아니라는 것은 이 결과로부터 알 수 있다.
또한, R4 노드(DR)에서 내보내는 Hello 메시지를 살펴보면 다음과 같이 unicast로 전달되고 있다.

Hello 메시지는 NBMA 모드와 Point to Multipoint 모드에서만 unicast로 전달되므로, OSPF가 현재 Point to Point 모드나 Broadcast 모드로 동작중이 아니라는 것은 이 결과로부터 알 수 있다.
이상의 두가지 결과로부터 이 시험망의 OSPF는 NBMA 모드로 동작하고 있음이 분명하다.

[1] RFC 2328, "OSPF Version 2", IETF, Apr. 1998.

OSPF는 인터페이스 종류에 따라 몇 가지 동작 모드를 가지며[1], Riverbed(OPNET) Modeler OSPF 모델도 이를 지원한다. 다음 그림은 사용자가 OSPF 인터페이스 종류를 선택할 수 있도록 Riverbed(OPNET) Modeler에서 제공하는 속성 설정창을 보인 것이다.

이 속성에서 선택 가능한 값은 Point To Point, Broadcast, Non-Broadcast, Point To Multipoint, MANET이다. Point To Point는 Point-to-point 네트워크를 위한 것이며, Broadcast는 이더넷과 같이 Broadcast 기능을 사용하는 다중 접속 네트워크를 위한 것이다. Non-Broadcast와 Point To Multipoint는 프레임 릴레이와 같이 Broadcast 기능을 사용하지 않는 다중 접속(Non-Broadcast Multi-Access: NBMA) 네트워크를 위한 것이다. MANET은 무선망을 위한 것이다.

[1] RFC 2328, "OSPF Version 2", IETF, Apr. 1998.

OSPF는 OSPF 메시지가 TCP/UDP를 사용하지 않고, IP 계층으로 바로 전달됨은 "OSPF 메시지(3) - Encapsulation"에서 살펴본 바 있다. 이 때, Point-to-Point 네트워크에서 OSPF 패킷을 싣고 있는 IP 패킷의 목적지 주소로 2가지가(멀티캐스트 주소중 224.0.0.5와 유니캐스트 주소)가 사용되었는데, Broadcast 네트워크(BMA 모드)에서는 3가지(멀티캐스트 주소중 224.0.0.5, 224.0.0.6과 유니캐스트 주소)가 사용된다.
다음은 "OSPF DR(4) - Hello 패킷"의 예제를 사용하여 OSPF 메시지를 담고 있는 패킷 정보를 확인한 것이다. 먼저 DR(R4 노드)에서 전송하는 Hello 패킷을 살펴보면 다음 그림과 같다.

다음은 DR other(R1 노드)에서 전송하는 Hello 패킷을 살펴본 것이다.

DR/DR other 노드 모두 OSPF Hello 메시지를 싣고 있는 IP 패킷의 목적지 주소로는 224.0.0.5가 사용된다[1].
다음 그림은 DR other(R1 노드)에서 전송하는 OSPF DBD(DataBase Description) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, 수신측 인터페이스의 IP 주소인 192.0.1.4가 목적지 주소로 사용되었다.

다음 그림은 DR other(R1 노드)에서 전송하는 OSPF LSU(Link-State Update) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, Point-to-point 네트워크("OSPF 메시지(3) - Encapsulation" 참조)와는 달리 멀티캐스트 주소
224.0.0.6이 목적지 IP 주소로 사용되었다.

포트 번호로는 [1]에 정의된 대로 항상 89가 사용된다.

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

OSPF에서 사용되는 Hello 메시지의 내용과 형식에 대해서는 "OSPF 메시지(2) - Hello 패킷 정보 확인"과 "OSPF 메시지(3) - Encapsulation"에서 살펴보았다. 이번에는, DR이 사용되는 경우(Broadcast 네트워크나 NBMA 네트워크)에 Hello 메시지의 내용에 어떠한 차이가 있는지 살펴보겠다.
"OSPF DR(1) - 라우터 상태"에서 사용한 시험망을 재사용할 것이며, 다음은 "OSPF DR(1) - 라우터 상태"에서 사용한 시험망 구조와, 시뮬레이션 수행시 실제로 할당된 IP주소 내역을 보인 것이다.

이 때, R2 노드(DR other)에서 R4 노드(DR)로 전달되는 Hello 메시지는 다음과 같이 관찰된다.

R4 노드(DR)에서 R2 노드(DR other)로 전달되는 Hello 메시지는 다음과 같이 관찰된다.

그리고, R2 노드(DR other)에서 R1 노드(DR other)로 전달되는 Hello 메시지도 다음과 같이 관찰된다.

R1 노드(DR other)에서 R2 노드(DR other)로 전달되는 Hello 메시지도 다음과 같이 관찰된다.

즉, Hello 메시지는 Adjacenct 노드간뿐만아니라 Neighbor 노드간("OSPF DR(3) - 이웃 상태" 참조)에도 교환된다.

"OSPF 메시지(3) - Encapsulation"에서 살펴본 것처럼, OSPF Hello 메시지는 멀티캐스트 주소를 사용하여 전달된다. 하지만, 이 멀티캐스트 패킷들은 단일 홉내에서만 사용되며, 다음 홉으로는 전달되지 않는다.
시뮬레이션을 통해 이를 확인해보기로 하자. 다음 그림은 "OSPF 라우팅 예제"에서 사용한 시나리오를 수정한 시험망 구조인데, R1 노드에서 R2 노드로 보내는 Hello Interval을 1초로 수정한 것이다.

다음 그림은 수정된 시험망 시나리오에서의 R1 --> R2 링크 트래픽 유통량을 기존의 시험망 시나리오와 비교한 것이다. 약 10배 정도로 트래픽이 증가하였으며, 이는 Hello 메시지 발생량이 10배로 증가(Hello Interval이 10초에서 1초로 축소됨)한 것을 고려하면 타당한 결과인다.

이제 R2 --> R4 링크의 트래픽 유통량을 두 시나리오간에 비교해보면 다음 그림과 같다. 전반적인 트래픽 유통량은 두  시나리오간에 동일함을 알 수 있으며, 이는 R1 노드에서 R2 노드 로의 Hello 메시지 발생량 증가가 R2 노드에서 R4 노드로의 Hello 메시지 발생량에 영향을 미치지 않았음을 의미한다.

즉, Hello 메시지는 다중 홉 너머로 Flooding되지 않는다.