네트워크 시뮬레이션 공방

UDP는 사용하는 RIP나 TCP를 사용하는 BGP와는 달리, OSPF는 TCP/UDP 계층을 거치지 않고 IP 계층을 직접 사용하여 메시지를 전달한다[1]. 이러한 차이는 다음 그림처럼 Riverbed(OPNET) Modeler에서 제공하는 노드 모델의 구조에서도 쉽게 확인할 수 있다. 즉, RIP는 UDP 계층위에 위치하지만, OSPF는 IP 계층 바로 위에 위치한다.

OSPF 메시지가 TCP/UDP를 사용하지 않고, IP 계층으로 바로 전달됨은 OSPF 메시지에 대한 Enacapsulation 구조를 통해서도 알 수 있다. 다음 그림은 "OSPF 메시지(2) - Hello 패킷 정보 확인"에서 살펴본 OSPF Hello 메시지를 담고 있는 패킷 정보를 확인한 것이다. TCP 패킷이나 UDP 패킷을 통한 Enacapsulation 과정없이, OSPF 패킷이 IP 패킷에 바로 Enacapculation 되어 있는 것을 확인할 수 있다.

OSPF 메시지를 싣고 있는 IP 패킷의 목적지 주소로는 OSPF 메시지의 종류와 단계에 따라 2가지가 사용된다. 이 IP 패킷은 OSPF Hello 메시지를 싣고 있으므로 멀티캐스트 주소인 224.0.0.5가 목적지 IP 주소로 사용되었다[1].
다음 그림은 OSPF DBD(DataBase Description) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데, 수신측 인터페이스의 IP 주소인 192.0.1.2이 목적지 주소로 사용되었다.

다음 그림은 OSPF LSU(Link-State Update) 메시지를 싣고 있는 IP 패킷을 살펴본 것인데,멀티캐스트 주소인 224.0.0.5가 목적지 IP 주소로 사용되었다

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

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

OSPF Hello 메시지("OSPF 메시지(1) - Hello 패킷 포맷" 참조)에 실제로 어떤 정보가 실려서 전달되는지, "OSPF 라우팅 예제"에서 사용한 예제를 활용하여 시뮬레이션을 통해 확인해보기로 하자. 다음은 "OSPF 라우팅 예제"에서 사용한 시험망 구조와, 시뮬레이션 수행시 실제로 할당된 IP주소 내역을 보인 것이다.

이 때, R1 노드에서 R2 노드로 전달되는 Hello 메시지 정보를 ODB를 통해 살펴보면 다음과 같다.

각 필드에 실린 정보의 의미는 다음과 같다.

- type : OSPF 패킷의 종류. 1은 Hello Packet임을 의미.
- version : OSPF 버전. 2는 OSPFv2를 의미.
- Hello Interval : Hello 메시지 전송 간격. 단위는 초(sec).
- Router Dead Interval : 상대 라우터의 비활성화 여부 판단 시간. 단위는 초(sec).
- priority : DR 선출시에 사용되는 라우터 우선 순위. 1은 기본값.
- options : OSPF 옵션. 2는 ExternalRoutingCapability 비트가 설정되었음을 의미.
- Router ID : Hello 메시지를 보내는 라우터의 ID. 192.0.2.1은 이 예제망에서 R1 노드의 Router ID이다.
- Area ID : Hello 메시지가 속한 Area의 ID. 이 예제망에서는 Area가 설정되지 않았으므로, 0.0.0.0으로 지정된다.
- Network Mask : Hello 메시지를 보내는 인터페이스에 사용되는 Metwork Mask.
- DR : DR의 IP 주소. Point-to-point 네트워크에서는 DR이 사용되지 않으므로, 0.0.0.0으로 지정된다.
- Backup DR : BDR의 IP 주소. Point-to-point 네트워크에서는 BDR이 사용되지 않으므로, 0.0.0.0으로 지정된다.

OSPF에서 Hello 메시지는 이웃(Neighbor)을 찾아내는(discorver) 용도와 이웃과의 관계를 유지(maintain)하는 용도로 사용된다. 다음 그림은 Riverbed(OPNET) Modeler OSPF 모델에서 사용하는 Hello 패킷 포맷과 표준[1]에서 설명하는 Hello 패킷 포맷 비교하여 나타낸 것이다.

얼핏 보기에는 Riverbed(OPNET) Modeler의 Hello 패킷 포맷은 표준과 완전히 다른 것처럼 보인다. 하지만, fields 필드에는 Router ID, Area ID, Version, Network Mask, HelloInterval, Options, Router Priority, RouterDeadInterval, Designated Router, Backup Designated Router 등의 정보가 실리므로, 실제로는 표준[1]과 동일하다(Authenticaiton 및 Checksum 제외).

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

"OSPF 이웃 상태정보 확인"에서 살펴본 것처럼, OSPF는 이웃(Neighbor) 노드와 Adjacency 관계를 맺는다. 하지만, Broadcast 네트워크일 경우에는 이웃끼리도 모두 Adjacent가 되지는 않으며, DR 및 BDR과만 Adjacent가 된다. (즉, DR/BDR <--> DR other 및 DR <--> BDR 간에만 Adjacent가 관계(Full 상태)가 된다.)
"OSPF DR(1) - 라우터 상태"에서 사용한 예제를 통해 Riverbed(OPNET) Modeler OSPF Model에서도 동일한 관계가 형성됨을 확인해보도록 하자. 다음은 "OSPF DR(1) - 라우터 상태"에서 사용한 예제망의 구조이며, R1, R2, R3, R4 노드간은 Broadcast 방식인 Ethernet으로 연결되어 있다.

시뮬레이션 수행시 실제로 할당된 IP주소 내역은 다음과 같다.

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

DR인 R4 노드 및 BDR인 R3 노드("OSPF DR(1) - 라우터 상태" 참조)와만 Adjacent 관계이며(Full 상태), DR other인 R2 노드와는 단지 이웃(Neighor) 관계에만 있음을 확인할 수 있다.
R1, R2, R3, R4 노드간의 관계 상태를 종합하면 다음 그림과 같다.

Riverbed(OPNET) Modeler OSPF 모델은 다음 그림처럼 인터페이스별로 Router Priority를 설정할 수 있는 기능을 제공한다.

이 Router Priority 값은 DR/BDR 선출시 사용되며, 가장 큰 Router Priority 값을 가지는 노드가 DR로 선출된다[1]. "OSPF DR(1) - 라우터 상태"의 예제에서 R4 노드가 DR로 선출된 것은 (사용자의 설정이 없어서) 모든 노드의 Router Priority가 모두 동일하였기 때문에, 그 다음 비교값인 Router ID(즉, IP 주소)가 가장 큰 노드로 선정되었기 때문이다.

이제, Router Priority 값을 변경하여 특정 노드가 DR로 선출되도록 해보자. "OSPF DR(1) - 라우터 상태"의 예제를 활용하여 Hub 노드와 연결된 R1 노드 인터페이스의 Router Priority 값을 2로 수정한다. R2, R3, R4 노드는 여전히 기본값인 1의 Router Priority를 가질 것이므로, 더 높은 Router Priority를 가진 노드 1이 DR로 선출될 것이다.
다음 그림은 수정된 예제에서 R1, R2, R3, R4 노드에 구성된 OSPF 인터페이스 정보를 ODB를 통해 살펴본 것이다.

예상한 것처럼 192.0.1.x 네트워크에 대하여 R1 노드가 DR로 동작하고 있음을 확인할 수 있다.

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

Broadcast 네트워크나 NBMA 네트워크에서 OSPF는 DR(Designated Router)를 사용한다[1]. 다음은 Riverbed(OPNET) Modeler OSPF Model에서 DR이 사용되고 있음을 확인하기 위한 시험망의 구조이다. "OSPF 라우팅 예제"에서 사용한 시나리오를 수정한 것으로, R1, R2, R3, R4 노드간을 Broadcast 방식인 Ethernet으로 연결하였다.

시뮬레이션 수행시 실제로 할당된 IP주소 내역은 다음과 같다.

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

192.0.1.x 네트워크에 대하여 R4 노드가 DR로, R3 노드가 BDR(Backup DR)로 동작하고 있음을 확인할 수 있다. 이 정보는 [2]에서 제시한 양식을 따른 것이다.

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

OSPF에서는 이웃(Neighbor) 노드의 상태를 Down, Attempt, Init, 2-Way, ExStart, Exchange, Loading, Full로 구분하며, 이웃 노드의 상태가 ExStart 이상일 때를 Adjacency 관계라고 한다[1]. Riverbed Modeler(OPNET) OSPF Model에서도 이웃 노드와 이러한 관계가 맺어져 있음을 시뮬레이션을 통해 확인해보기로 하자. 다음은 "OSPF 라우팅 예제"에서 사용한 시험망 구조와, 시뮬레이션 수행시 실제로 할당된 IP주소 내역을 보인 것이다.

이 때, R2 노드와 연결된 R1 노드 인터페이스에서 구성된 이웃 정보를 ODB를 통해 살펴보면 다음과 같다.

R2 노드와 (Full 상태이므로) Adjacency 관계로 맺어져 있음을 확인할 수 있다. 이 정보는 [2]에서 제시한 양식을 따른 것이다.

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

"RIP 라우팅 예제"에서 사용한 예제망의 라우팅 프로토콜을 OSPF로 변경하여 OSPF의 동작을 확인해보기로 하자. 첫번째 예제의 네트워크 토폴로지와 실제로 할당된 IP주소 내역은 다음과 같다.

시뮬레이션을 수행한 후, R1 노드에서 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다. ("라우팅 경로 확인하기" 참조).

R2 - R4, R3 - R4, R4 - Server 네트워크에 대한 라우팅 정보가 OSPF에 의해 생성되었으며, R2 - R4, R3 - R4 네트워크에 대한 Metric은 4, R4 - Server 네트워크에 대한 Metric은 5임을 확인할 수 있다. (R4 - Server 네트워크에 대해서 2개의 경로 정보가 구성된 것은 ECMP 때문이다. ECMP의 영향에 대해서는 이후의 글에서 살펴볼 것이다.) "OSPF에서의 링크 비용"에서 설명하였듯이 OSPF는 대역폭 정보로부터 계산된 인터페이스의 비용을 기본 Metric으로 사용하며, 기본값 사용시 DS3(44.746Mbps) 링크의 비용은 2, Fast Ethernet(100Mbps) 링크의 비용은 1로 계산된다. 따라서, R1 -> R2 -> (R4) 경로와 R1 -> R3 -> (R4) 경로의 Metric은 2 + 2 = 4가 되며, R1-> R2-> R4 -> (Server) 경로의 Metric은 2 + 2 + 1= 5가 된다.

Client 노드로부터 Server 노드로의 트래픽 전달 경로는 다음과 같이 2홉 경로(R1 -> R3 -> R4 경로)으로 확인되며, 이는 라우팅 테이블과 일치한다. (이후의 1홉 예제의 결과와 비교할 것이므로 R1 -> R3 -> R4 경로, 또는 R1 -> R2 -> R4 경로 어느 쪽이던 별 상관은 없다)

이제 R1 노드와 R4 노드사이에 1홉 링크를 추가하여 OSPF의 특성을 보다 자세히 살펴보자. 다음 그림은 첫번째 예제를 변형한 두번째 예제의 구조이다. R1 노드와 R4 노드 사이에 다른 링크(DS3)보다 작은 대역폭의 링크(DS1)를 추가하였다.

시뮬레이션을 수행한 후, 두 번재 시나리오에서 R1 노드에 구성된 라우팅 테이블을 살펴보면 다음 그림과 같다.

R1 노드와 R4 노드를 연결하는 링크가 추가되었음에도 불구하고 R4 - Server 네트워크에 대한 경로는 변경이 없으며, Metric도 동일하게 5임을 확인 할 수 있다.
이제 Client 노드로부터 Server 노드로의 트래픽 전달 경로를 살펴보면 라우팅 테이블의 구성과 같이 2홉 경로(R1 -> R3 -> R4)인 것을 알 수 있다.

즉, 기본적으로 OSPF는 링크의 대역폭 정보로부터 계산된 인터페이스의 비용을 기반으로 라우팅 경로를 선정한다. 만약, 링크(인터페이스) 비용이 더 작은 경로가 존재하는 경우라면, 홉 수에 상관없이 해당 경로를 라우팅 경로로 선정한다.

OSPF에서 라우팅 테이블 구성할 때 사용되는 Metric은 링크(정확하게는 인터페이스)의 비용(cost)이다[1]. CISCO사의 제품에서는 해당 링크의 대역폭 정보를 사용하여 cost를 계산하며[2, 3], Riverbed Modeler(OPNET)의 OSPF 모델 역시 이와 동일한 방법으로 cost를 계산한다.
다음 그림은 Riverbed Modeler(OPNET)에서 제공하는 인터페이스별 OSPF Cost 설정창을 보인 것이다. 1 ~ 65,535 범위의 정수값을 입력하거나 또는 Auto Calculate로 지정할 수 있다. Auto Calculate로 지정되면 해당 인터페이스에 연결된 링크 대역폭에 대한 Reference Bandwidth의 비율로 자동 계산된다.

다음 그림은 OSPF Cost가 Auto Calculate로 지정된 경우 링크 Cost 계산에 사용되는 Reference Bandwidth (bps) 설정창을 보인 것이다. 0 보다 큰 실수값을 입력하거나 10, 100, 1000 Mbps 중에서 선택할 수 있다.

[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/7039-1.html#t6
[3] http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/9237-9.html#q3