OSPF 라우팅 프로토콜은 Basic Topology를 구성하는 Link와 그렇지 않은 Link를 구분하지 않기 때문에 어떠한 Link 정보가 변경되더라도 ‘Complete SPF Computation’을 수행한다고 이미 앞에서 설명을 하였다. 그렇다면 다음 토폴로지의 경우를 생각해 보자.

  상위 토폴로지에서 라우터와 라우터 사이의 네트워크를 제외하고, 모든 라우터가 Loopback을 포함하여 5개의 네트워크 정보를 가지고 있다면 총 76개의 네트워크가 존재하게 된다. 만일 상위 토폴로지에 OSPF 라우팅 프로토콜을 구동시키기 되면 76개 네트워크 중 하나의 네트워크, 즉 하나의 Link만 문제가 생겨도 모든 장비가 SPF 알고리즘을 수행하게 될 것이다. 또한, 어느 장비에서라도 필요에 의해 네트워크를 추가하는 경우에도 모든 장비가 SPF 알고리즘을 수행하게 된다.

  이 부분은 다음과 같이 토폴로지를 구성해서 쉽게 확인이 가능하다.

  그리고, R1, R2, R3에 다음의 명령어를 수행한다.

  이 상태에서 R1에서 Loopback interface를 다운시킨 후 각 라우터에서 debug에 의해 발생하는 Log 정보를 확인해 보면 다음과 같다. (Log 양이 너무 많기 때문에 R3의 Log 정보만 표시하였다.)

  Log 정보와 같이 OSPF 라우팅 프로토콜은 Basic Topology 구성 Link가 아닌 Link에 변화가 발생해도 모든 장비가 ‘Complete SPF Computation’를 수행하게 된다. 예시처럼 라우터 3대, 네트워크 5개인 작은 토폴로지 구조에서도 Log를 확인해 보면 상당히 많은 작업을 수행한다는 것을 눈으로 확인할 수 있을 것이다.

  Log에서 나오는 내용들이 무엇을 하는 것인지는 ‘OSPF 라우팅 프로토콜의 SPF 알고리즘 수행방법’에서 자세히 알아보기로 하고, 우리는 여기서 OSPF 라우팅 프로토콜이 가지고 있는 문제점을 몇가지 찾아볼 수 있다.

  첫째, 각각의 라우터가 가지고 있는 모든 Link 정보를 OSPF 데이터베이스에 저장해야 하기 때문에 네트워크 망이 커질수록 OSPF 데이터베이스 크기가 증가하여 모든 장비의 메모리 사용량이 증가하게 된다.

  둘째,  어떠한 Link 정보가 변경되더라도 ‘Complete SPF Computation’를 수행하기 때문에 Link의 수가 많아지게 되면 Link 정보의 변경 횟수가 많아져서 모든 장비의 CPU 사용량이 증가하게 된다.

  셋째, OSPF 라우팅 프로토콜은 모든 장비의 데이터베이스를 동기화해야 하기 때문에 네트워크 정보를 Filter하거나 Summery할 수 없다. 그래서, Link 정보의 변화가 발생할 때 마다 업데이트 정보를 전체 네트워크로 전달해야 하는데, 업데이트 Packet에 의해 전체 네트워크 회선의 자원을 사용하게 된다.

  이러한 문제를 해결하기 위해 필요한 것이 바로 ‘Area’이다. Area는 하나의 OSPF 네트워크 망을 여러 개의 작은 영역으로 구분하여 OSPF 데이터베이스를 동기화하여야 하는 장비들의 범위를 다음과 같이 나누는 것이다.

  이렇게 Area를 구분하면 R1, R2, R3, R4, R5는 Area 0 데이타베이스를 동기화하고, R4, R5, R6, R7, R8이 Area 1 데이터베이스를 동기화한다. 그리고, R9, R10, R11, R12, R13이 Area 2의 데이터베이스를 동기화한다. 즉, 자신이 속해 있는 Area 내의 장비간에만 데이터베이스를 동기화하면 되는 것이다.

  이렇게 Area를 구분하고 나면 Area 1에 속해 있는 장비는 전체 토폴로지를 다음과 같이 그린다.

  그리고, Area 0에 속해 있는 장비는 전체 토폴로지를 다음과 같이 그린다.

  마지막으로 Area 2에 속해 있는 장비는 전체 토폴로지를 다음과 같이 그리게 된다.

  즉, 다른 Area가 어떻게 구성되어 있는지는 모르기 때문에 각 장비는 자신이 속해 있는 Area에 대해서만 토폴로지를 구성하고 SPF 알고리즘을 수행하게 되는 것이다. 그러므로, 다른 Area의 Link 정보가 변경되어도 자신의 Area 내부 Link 정보는 변경이 되지 않았기 때문에 SPF 알고리즘을 구동시킬 필요가 없는 것이다.

  그렇다면, Area 2에 있는 장비들은 Area 0와 Area 1에 있는 네트워크 정보를 어떻게 알 수 있을 것인가? 이전에 ‘Link’와 ‘Network’는 구분되어야 하고, ‘Network’은 단순히 장비가 가지고 있는 정보(Information)일 뿐이라고 설명을 한 적이 있다. 전체 토폴로지를 보면 R4와 R9은 하나의 Area가 아닌 여러 개의 Area에 속해 있다는 것을 알 수 있다. R4와 R9에서 Area 간에 정보를 교환하면서 ‘Link’ 정보를 ‘Network’ 정보로 다음과 같이 변경시킨다.

  이렇게 서로 다른 Area 간에 데이터베이스를 교환하는 장비를 Area와 Area 사이에 있다고 해서 ABR(Area Bother Router)라고 하는데, 이 부분은 바로 다음 ‘OSPF의 문제점 및 계층적 구조’에서 살펴보도록 하겠다.

  그럼, Link-State 라우팅 프로토콜은 Link 정보의 변경없이 ‘Network’ 정보만 변경되는 경우 어떠한 방식으로 SPF 알고리즘을 수행하는가? ‘Complete SPF Computation’를 수행하지 않고 변경된 ‘Network’에 대한 새로운 Best-Path를 찾기 위한 PFC만 수행한다고 설명했었다.

  기존 예시에서 다음 설정을 추가한 다음 정말로 다른 Area의 Link 정보가 변경되면 PFC만 수행하는지  확인해 보자. 만일, ‘debug ip ospf spf’를 중지시킨 경우라면 해당 명령어를 다시 넣어주어야 SPF 알고리즘 수행 과정을 확인할 수 있다.

  이 상태에서 R4에서 Loopback interface를 다운시킨 후 각 라우터에서 debug에 의해 발생하는 Log 정보를 확인해 보면 다음과 같다. (Log 양이 너무 많기 때문에 R3의 Log 정보만 표시하였다.)

  이와 같이 Area를 구분함으로써 OSPF 라우팅 프로토콜이 SPF 알고리즘 수행에 따른 CPU 사용량을 낮출 수 있게 되었다. 또한, 데이터베이스에서 다른 Area의 ‘Link’ 정보를 삭제함으로써 메모리의 사용량을 줄일 수 있게 되었다.

  그리고, 마지막으로 Area간에 데이터베이스를 교환하면서 서로 다른 Area 간에는 데이터베이스를 동기화할 필요가 없기 때문에 네트워크 Filter나 Summary가 가능해진다. 그래서, 필요한 경우 네트워크 Filter나 Summary 기술을 통하여 업데이트의 양을 줄일 수 있게 되었다.

  이 모든 것이 Area를 구분함으로써 가능한 일이니 Area가 OSPF 라우팅 프로토콜에서 얼마나 중요한 역할을 하는지 알 수 있다.