네트워크 시뮬레이션 공방

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

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

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

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

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 범위내의 시간 값도 같이 고려된다.

Riverbed(OPNET) Modeler OSPF 모델에서 제공하는 "Convergence Activity"와 "Convergence Duration"의 의미에 대해서는 "OSPF 수렴 시간 (1) - Convergence Duration"에서 살펴보았다. 이번에는 예제를 통해 실제 시뮬레이션에서 어떤 결과값이 측정되는지 살펴보기로 하자.
다음은 "OSPF 라우팅 예제"의 예제망에서 측정된 "Convergence Activity"와 "Convergence Duration" 결과값을 보인 것이다.

Convergence가 1번 기록되었는데, convergence activity는 6초대에 시작되어 51초대에 끝났으며 convergence duration은 약 45초로 기록된 것을 알 수 있다. 네트워크가 가동된 후 convergence가 1번만 기록되었으므로 네트워크 개통에서 기인한 OSPF 라우팅 테이블 갱신 완료에 걸린 시간(Convergence time)은 45초로 볼 수 있다.

다음은 "OSPF DR(1) - 라우터 상태"의 예제망에서 측정된 "Convergence Activity"와 "Convergence Duration" 결과값을 보인 것이다.

Convergence가 2번 기록되었는데, 첫번째 convergence acvitiy는 6초대에 시작되어 23초대에 끝났고 convergence duration은 약 17초로 기록되었다. 두번쨰 convergence acvitity는 46초대에 시작되어 64초대에 끝났으며, convergence duration은 약 18초로 기록되었다. 네트워크 개통 이후 추가적인 토폴로지 변경은 없으므로 네트워크 개통에서 기인한 OSPF 라우팅 테이블 갱신 완료에 걸린 시간(Convergence time)은 약 58초(6초 ~ 64초)로 보아야 한다. 23초 ~ 46초 구간은 OSPF 라우팅 테이블 갱신이 완료된 것은 아니지만, "일정 간격" 동안 convergence activity가 없는 상태이다.

OSPF Convergence time으로 각각 45초, 58초가 소요된 이유를 구체적으로 설명하는 것은 대단히 복잡한 작업이며, 라우터들간에 송수신된 메시지와 인터페이스 상태 변화등을 상세히 추적해야만 한다. (OSPF 라우터들간에 송수신된 메시지 순서와 메시지간 상관 관계에 대해서는 이후의 글에서 분석해 볼 예정이다.)

네트워크 토폴로지 변경 횟수가 동일하지만 예제망마다 convergence 기록 횟수가 다른 것은 네트워크 토폴로지의 차이와 convergence(일정 시간 간격 동안 라우팅 테이블 갱신이 없는 것) 도달 여부를 판단하는 "일정 시간" 기준값 때문이다.

라우팅 프로토콜 성능 분석에 있어 중요한 결과 항목 중의 한가지는 라우팅 테이블 수렴 시간(Convergence Time)이다. 이는 네트워크 토폴로지에 변경이 발생(또는, 최초 가동)되었을 때 이 정보를 라우팅 테이블에 반영 완료하는데 걸리는 시간을 의미한다.
OSPF의 Global Statistics 결과 항목들을 보면 다음 그림과 같이 "Network Convergence Activity" 항목과 "Network Converence Duration (sec)" 항목을 볼 수 있다.

얼핏 보기에는 "Network Convergence Activity"와  "Network Convergence Duration" 결과값만 측정하면 OSPF 라우팅 테이블 갱신 활동이 수행된 시간과 라우팅 테이블이 완성(안정화)되는데 걸린 시간을 쉽게 알 수 있을 것처럼 생각된다. 하지만, 이 두 결과 항목은 우리가 일반적으로 생각하는 라우팅 테이블 수렴 시간(Convergence Time)과는 약간 의미가 다르므로 결과값 해석시 주의가 필요하다. 

"Network Convergence Activity"와  "Network Convergence Duration" 결과값은 별도의 메커니즘을 통해 계산되는 것은 아니며, 각 노드의 OSPF "Router Convergence Activity"와 "Router Convergence Duration (sec)" 결과 항목값이 취합되어 기록된 것이다.  Node Statistics의 OSPF 그룹에 속한 "Router Convergence Activity" 결과 항목에 대한 설명을 살펴보면 다음과 같다.
Convergence activity가 없는 구간에서는 0, 있는 구간에서는 1이 기록된다는 것을 알 수  있다. (Convergence acvitity란 LSA 수신/생성을 의미한다.)
==================================================
Records a square wave alternating between ordinates 0 and 1. It is 0 during the time interval in which no sign of convergence activity is detected; it is 1 during the time interval in which there are signs of convergence activity. 
==================================================

역시 Node Statistics의 OSPF 그룹에 속한 "Router Convergence Duration (sec)" 결과 항목에 대한 설명을 살펴보면 다음과 같다.
OSPF 라우팅 테이블이 수렴하는데 걸린 시간이 기록되며, 이 때의 수렴 시간(Convergence Time)이란 첫 번째 Convergence activity 발생시점으로부터 해당 convergence activity 이후 일정 간격 동안 convergence activity가 없는 특정 convergence activity 발생시점까지의 경과시간을 의미한다는 것을 알 수 있다.
==================================================
Records the time it takes the OSPF routing table on this router to convergence. 
The convergence time is the time elapsed since a first sign of convergence activity occurs (initially, or with each new disturbance) until the a sign of convergence activity occurs that is followed by a certain interval of no convergence activity. 
In this case, we take a sign of convergence activity to mean a recomputation of the OSPF routing table. 
==================================================

여기에서 주목해야 할 점은 "일정 간격"이라는 표현이다. 즉, 해당 convergence activity 이후 "영원히" convergence activity가 없는 마지막 convergence activity까지의 경과시간이 아니라, 해당 convergence activity 이후 "일정 간격" 동안 convergence activity가 없는 특정 convergence activity까지의 경과시간이라는 것이다.
간혹 이 사실을 간과하고 네트워크 토폴로지 변경(혹은 최초 가동)으로부터 기인한 라우팅 테이블 갱신이 완전히 끝나는 OSPF 수렴 시간을 측정하는 용도로 "Convergence Duration" 결과값을 사용하면 엉뚱한 값을 측정하게 될 수도 있다. 

OSPF Model에서 실제로 Hello 메시지가 전송되는 간격은 Hello Inteval 값과 정확히 일치하지 않는다("Hello Interval" 참조). 다음은 이를 확인하기 위하여 "Hello Interval" 예제에서 실제로 Hello 메시지가 송신된 간격을 표로 정리한 것이다.

간격이 계속 변화하며, 그 값이 10초(Hello Interval 속성 값)보다는 약간 큰 것을 알 수 있다. 이렇게 Hello 메시지 간격이 지정된 Hello Interval 값보다 큰 이유는 Riverbed(OPNET) Modeler OSPF Model에는 Hello Jitter 시간이 추가로 반영되어 있기 때문이다.
Hello Jitter 값을 17.5 PL6 버전("OPNET Modeler 17.5 PL6 발표" 참조)까지는 사용자가 변경할 수 없으며, 18.0 버전("Riverbed Modeler 18.0 발표" 참조)부터는 GUI를 통해 변경할 수 있다. 다음 그림은 Riverbed(OPNET) Modeler 18.7.0 버전("Riverbed Modeler 18.7.0 발표" 참조)에서 제공하는 Hello Jitter 설정창을 보인 것이다. 입력값은 Hello Interval에 대한 비율을 의미한다.

OSPF Model에서 Hello 메시지("OSPF 메시지(2) - Hello 패킷 정보 확인" 참조)가 전송되는 간격은 기본적으로 "Hello Interval (sec)" 속성에 의해 지정된다. "Hello Interval (sec)"의 기본값은 10(초)이다.

실제로 Hello 메시지가 이 시간 간격마다 전송되는 것을 예제를 통해 확인해보자. 다음 그림은 "OSPF DR(5) - 메시지 Encapsulation"에서 사용한 시험망의 R1 노드에서 전송하는 Hello 메시지 간격을 살펴본 것이다.

예상했던 것처럼 Hello 메시지가 약 10초마다 송신되고 있는 것을 볼 수 있다. (하지만, 그 간격이 정확히 10초는 아닌데, 그 이유에 대해서는 이후의 글에서 다시 살펴보겠다.)

실제 OSPF 구현물에서는 네트워크 토폴로지 변경을 인지(즉, LSA 정보를 수신하거나 인터페이스 상태가 변경)하였을 때에도 라우팅을 위한 네트워크 토폴로지 정보(Short-path tree)를 즉시 재계산하지 않으며, 일정 시간 지연 혹은 간격을 가진 후에 재계산한다.
이 시간 지연 혹은 간격을 설정하는 방법은 제품 벤더에 따라 다르며, 다음 그림은 Riverbed(OPNET) Modeler OSPF 모델에서 제공하는 Shortest-path tree 재계산 조건 항목을 보인 것이다.

- Style: LSA Driven 방식과 Periodic 방식중에서 선택. 기본값은 LSA Driven.
- Delay (seconds) : 네트워크 토폴로지 변경을 인지한 후 SPF 계산을 할 때까지의 지연 시간.
- Hold Time (sedonds) : 이전 SPF 계산이후 다음 번 SPF 계산까지의 최소 간격. 따라서, 이 시간 간격보다 더 자주 SPF 계산이 일어나지는 않는다.

OSPF 망에서 DR("OSPF DR(1) - 라우터 상태" 참조) 변경이 발생할 경우, 이웃 노드들은 Hello 패킷("OSPF 메시지(2) - Hello 패킷 정보 확인" 참조)을 통해 이를 알수 있다. DR 변경후 Hello 메시지 수신은 다음 2가지 경우가 존재한다.

1) 새로운 DR로 선출된 노드로부터의 Hello 패킷 수신: 이전에는 DR 노드가 아니었던 이웃이 자신을 DR로 선언함.2) 이전 DR 노드로부터의 Hello 패킷 수신: 이전에는 DR 노드였던 이웃이 자신이 DR이 아님을 선언함.

이러한 경우, NeighborChange 이벤트가 발생하고 이웃 노드들과의 관계("OSPF DR(3) - 이웃 상태" 참조) 변경 여부에 대한 점검이 숫행된다. 또한, NeighborChange 이벤트는 BDR 노드 변경시에도 동일하게 발생한다.

라우팅 프로토콜 모델들은 동작 시작 시점을 지정하는 "Start Time" 속성을 가지고 있으며, OSPF Mdoel 역시 해당 속성을 가지고 있다. 라우팅 프로토콜 모델들이 "Start Time" 속성을 제공하는 이유는 동일한 네트워크 토폴로지에서도 시작 시간에 따라 동작이 달라지거나, 라우팅 테이블 결과가 달라질 수 있기 때문이다.

사용자가 설정해준 "Start Time" 값은 ospf_v2 프로세스 모델로부터 ospf_process 프로세스 모델로 전달된다("OSPF 프로세스 모델 구조" 참조). ospf_process 프로세스 모델은 해당 시간이 지난 후에 Init 스테이트로부터 Idle 스테이트로 천이하므로，OSPF 프로토콜의 실질적인 동작은 "Start Time" 이후에 일어나게 되는 것이다.

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) - 천이 순서"에서 살펴본 내용과 일치하는 것이다.