태그: Routing

Network Study – 5주차 : OSPF의 설계와 표준화

 

OSPF 스터디의 마무리를 짓기 위하여 OSPF – Anatomy of an Internet Routing Protocol를 읽고 있다. 본래는 OSPF의 상세 동작을 공부하기 위하여 읽기 시작하였으나, 의외로 라우팅 프로토콜 -특히 OSPF- 의 역사에 대해 충실하게 서술하고 있었기에, 이번 주 주제를 이것으로 정하게 되었다.

1. Internet의 역사

모두가 잘 알다시피 인터넷은 ARPANET으로부터 시작되었다. ARPANET은 미 국방성에서 패킷 스위칭 네트워크를 테스트하기 위해서 구축한 일종의 실험 네트워크였으며, 차차 미군의 군사 네트워크 시스템을 대체하게 된다. 한편, 패킷 스위칭 기술이 일반에 공개된 후 1985년, NSF(National Science Foundation)에서 NSFNET을 구축한다. NSFNET은 LSI-11 기반의 라우터들과 56Kbps Leased-Line으로 구축되었으며, 곧 ARPANET을 대체하였다. 1987년 NSFNET은 IBM RT 베이스의 라우터와 T1 회선으로 업그레이드 된다. 1992년에는 회선 속도가 T3로 올라가며, 1995년에 폐기되었다.

NSFNET Backbone은 인터넷의 모태가 되었으며, 지금은 ISP들의 백본과 IX(Internet Exchange)들이 그 자리를 대신하고 있다.

2. OSPF의 개발

OSPF(Open Shortest Path First Protocol)은 인터넷의 표준 라우팅 프로토콜을 목표로 개발이 시작되었다. 1987년 OSPF Working Group이 IETF에서 구성되면서 시작된 개발은 1997년, OSPFv2가 발표되고, 2016년 현재에 이르기까지 계속 발전되어 오고 있다.
OSPF Working Group이 탄생하였던 1987년, OSPF 개발에 참여하였던 개발자들은 다음과 같은 몇 가지 목표를 두고 OSPF의 기본 디자인을 시작하였다.

– RIP의 대체 : 네트워크의 크기가 증가하면서, RIP 트래픽의 크기가 점증, 회선에 부하를 가하기 시작하였고, Count Infinity와 Late Convergence 등의 문제를 가지고 있었다. 당시 AS간의 프로토콜로 사용되던 EGP도 문제가 있었으나, OSPF의 개발자들은 RIP를 대체할 프로토콜을 개발하는 것이 EGP의 대체품을 개발하는 것보다 더 쉽고, RIP를 대체하는 편이 더 광범위하게 받아들여질 것으로 기대했기 때문이라 밝히고 있다.
– 라우팅 메트릭의 구체적인 서술 : RIP는 홉 카운트를 메트릭 값으로 사용하였고, 이것은 대역폭이 더 큰 링크를 사용하지 않게 되는 등의 부작용을 가져왔다.
– 계층화된 라우팅 : 수 천대에 이르는 라우터들을 포괄하는 네트워크를 위해서는 라우팅을 계층화하는 것이 필요하다고 여겨졌다. OSPF는 2계층의 라우팅 규칙을 가진다.
– 내부/외부 경로의 분리 : RIP를 사용하는 AS들은 신뢰 문제를 가지고 있었다. AS 운영자들은 내부 루트를 외부 루트보다 우선하고 싶어했지만, RIP는 이 두 종류의 루트를 구분하지 못하였다. OSPF는 내부 경로가 외부 경로를 덮어쓴다.
– 더 유연한 서브네팅 방법 : OSPF가 디자인되던 시기에 인터넷은 클래스 A, B, C에 따른 서브네팅을 수행하고 있었다. OSPF의 개발자들은 CIDR와 VLSM이 빠른 속도로 확산될 것이라 믿었고, OSPF는 VLSM을 지원하도록 만들어졌다.
– 보안 :  RIP는 누구나 라우팅 광고를 보낼 수 있고, 가짜 광고에 취약하게 된다. OSPF LSA는 Key를 통한 인증을 수행할 수 있으며, 인증된 라우터만이 OSPF 도메인에 참여할 수 있다.
– ToS 기반 라우팅: TCP/IP는 ToS 필드를 통해서 5가지의 클래스를 지원하였는데, 각 클래스별로 다른 경로를 선택할 수 있기를 바랬다.

OSPF는 ToS 기반 라우팅을 클래스 별로 다른 메트릭 값을 줌으로써 실현하였다. 하지만 IP에서 ToS의 지원은 옵션이었고, OSPF의 ToS 기반 라우팅 구현들이 많이 등장하였음에도 불구하고 ToS 기반 라우팅은 인터넷에 적용되지 않았다.
그 이유는 아마 달걀과 닭의 문제일 것이다. 라우터가 ToS 필드를 처리하지 않기에 호스트는 ToS 필드를 태그하지 않는다. 그리고 호스트가 ToS필드를 태그하지 않기에 라우터는 ToS 필드를 태그하지 않는다.

2-1. Link-State vs Distance Vector

RIP를 위시한 Distance Vector 프로토콜들이 인터넷에서 널리 사용되고 있었다. Distance Vector 프로토콜은 분산된 처리 모델을 적용하고 있는데, 그것은 각 라우터들이 자신의 이웃 라우터로부터 받은 정보를 가지고 라우팅 계산을 수행한다는 의미이다.
라우터는 현재 토폴로지의 정보를 이웃 라우터로부터 전달받고, 계산을 수행한 뒤 그 정보를 다시 다른 라우터에게 전파한다. 이 과정은 모든 라우터들이 최적 경로를 수립할때까지 계속된다.
Link-State 프로토콜은 대개 분산 데이터베이스 모델을 채택한 다익스트라 최단 거리 알고리즘을 사용한다. 각  라우터는 토폴로지 환경을 LSA(Link-State Advertisement)를 통해 알리고, 그것을 수신한 라우터는 LSA를 플러딩한다. 결국 토폴로지의 모든 라우터가 동일한 LSDB(Link-State Database)를 가지게 된다.
그리고 데이터베이스의 정보를 다익스트라 최단 거리 알고리즘으로 계산함으로써, 목적지까지의 최단 경로를 알아내게 된다.

RIP는 인터넷의 대형 AS에 적용하였을 경우 문제가 많았다. 느린 수렴 시간을 가졌고, 네트워크 대역폭을 많이 소비하였다. 그리고 절단된 경로를 제거하는 것이 느려 Counting to Infinity 문제를 발생시켰다.
BBN은 ARPANET의 라우팅 프로토콜에서 동일한 문제점을 발견하였고, 이러한 문제점을 해결하기 위하여 최초의 Link-State 라우팅 프로토콜을 개발하게 된다. 이 라우팅 프로토콜은 원래의 Distance Vector 라우팅 프로토콜을 성공적으로 대체하였으며, 이러한 성공을 본 OSPF 개발자들은 TCP/IP를 위한 Link-State 라우팅 프로토콜을 개발하고자 하였다.

Link-State 프로토콜이 많은 사람들에게 있어 매력적으로 보였음에도 불구하고 구체화-구현까지의 과정이 Distance Vector 프로토콜에 비해 더 복잡하였기 때문에 멀티벤더 Link-State 프로토콜은 존재하지 않는 상황이었다 -몇몇 사람들은 그것이 불가능한 일이라고 생각하였다-
사실, 이것은 OIGP(Open Interior Gateway Protocol ) 워킹 그룹이 OSPFIGP(Open Shortest Path First Interior Gateway Protocol)와 ODVP(Open Distance Vector Protocol) 워킹 그룹으로 나뉘어지기에 충분한 이유가 되었다.
비록 ODVP 워킹 그룹이 단명하기는 했지만, 이 두 그룹은 직접적인 경쟁관계에 놓이게 된다.
되돌아보면, 그 뒤로 Link-State 라우팅 프로토콜이 대세를 차지하게 된다. OSPF 외에도 OSI의 IS-IS나 노벨의 NetWare Link Service Protocol, IBM의 Advanced Peer-to-Peer Networking과 ATM의 Private Network-to-Network Interface가 만들어졌다.

한편, 연구자들은 Distance Vector 프로토콜의 단점을 보완하기 위하여 노력하였고, Cisco 독점의 IGRP와, RIPv2를 통하여 계속해서 사용되게 된다. 물론, BGP도 Distance Vector를 사용한다.

 

2-2. Link-State 알고리즘 기본

Link-State 알고리즘을 개발하기로 결정했을 때, OSPF의 개발자들은 이미 존재하는 기술에  대해서 조사하였다. BBN이 Link-State 프로토콜을 개척하였고, 최초의 Link-State 프로토콜은 1979년 5월에 ARPANET에 적용되었다.
ARPANET의 단순성(동일한 장비, 동일한 소프트웨어, Point to Point 시리얼 연결) 덕분에  라우팅 프로토콜의 적용 또한 (상대적으로) 간편하였다. 반면에, TCP/IP 라우팅 프로토콜과는 달리, ARPANET의 라우팅 프로토콜은 경로 결정 뿐만이 아닌, 네트워크의 혼잡 또한 감지할 수 있도록 설계되었다.

ARPANET의 Link-State 프로토콜은 Link-State 프로토콜이 가져야 할 기본적인 부분들을 모두 확립하였다. LSDB와 확산 알고리즘에 따른 LSA 전파, 그리고 최단 거리 경로 계산이 그렇다. Area 기반의 라우팅 또한 ARPANET에서 개발되었는데, 실제로 적용되지는 않았다.

반면, 개선이 필요한 부분도 있었는데, 새로 연결된 링크를 탐지하기 위해서는 LSDB의 갱신 주기가 빨라져야 했고, 네트워크가 확산되던 시기, ARPANET의 플러딩 알고리즘의 취약점이 전체 네트워크를 마비시키기도 하였다.

BBN에서는 ARPANET의 라우팅 프로토콜을 TCP/IP 라우팅 프로토콜로 포팅하기도 했지만, 이 프로토콜은 Ethernet 네트워크 상에서 시리얼 연결을 시뮬레이션하였기 때문에 인터넷에서 사용하기에는 너무 비효율적이었다.
OSPF의 개발이 진행되고 있을 때 ISO에서는 OSI 프로토콜 스택에 포함되는 IS-IS를 개발하였다.

그래서 혹자는 “IS-IS를 사용하면 되지 않을까요?”라며 묻기도 한다. 하지만 IS-IS를 그대로 사용하기에는 몇 가지 문제점이 있었다.
첫번째로, IS-IS는 Link Layer 바로 위에서 동작한다. 이것은 레이어별 동작 위치에 따른 장단점을 이야기 할 때 다루도록 하겠다. 그리고 IS-IS는 LSA의 단편화를 지원하지 않는다. 라우터는 자신의 모든 라우팅 데이터를 하나의 LSA에 실어서 보내야만 한다.
또한, 많은 TCP/IP 환경에서 라우터들은 외부  경로(External Route)를 가지고 있는데, 이러한 설계는 유용하지 않다. IS-IS는 에어리어 기반의 라우팅을 지원하지만, 에어리어 사이의 쇼트컷을 지원하지 않는다. 이것은 OSPF 개발자들이 인터넷을 위한 라우팅 프로토콜을 개발할 때 반드시 필요하다고 생각했던 것이다.
또한, IS-IS는 패킷 포맷에서 필드 정렬(Alignment)를 수행하지 않는다. 이것은 프로토콜을 구현하는 것을 좀 더 힘들게 만든다.[1](원문 : making life more difficult for protocol implementors)

이러한 기술적인 문제들 때문에, IS-IS와 같은 프로토콜을 수정하는 것 보다 새로운 프로토콜을 설계하는 것이 더 쉽다고 생각되었다. 그리고 비 기술적인 부분으로, Internet Society의 많은 사람들은 IETF가 OSPF 프로토콜을 전적으로 설계하는 것이 더 바람직하다고 생각했다.
ISO Committee의 지향점은 ISO 프로토콜 스택을 위한 프로토콜을 개발하는 것이다. 이것은 인터넷을 위한 프로토콜을 개발하는 것과는 다소간 달랐다.

Link-State vs Distance Vector 논쟁과 마찬가지로, 새로운 라우팅 프로토콜을 만드는 것은 1992년, OSPF가 인터넷의 권장 IGP(Recommended IGP)가 되기 전까지 논쟁거리가 되었다.

 

2-3. 캡슐화

TCP/IP 라우팅 프로토콜을 설계할 때, 3종류의 캡슐화 방법을 선택할 수 있다. 라우팅 프로토콜은 Link Layer 위에서 돌아가거나, IP 네트워크 레이어 위에서 돌아가거나, TCP나 UDP 위에서 돌아갈 수 있을 것이다.
Link Layer 위에서 구현하기 위해서는 몇 가지 문제가 따른다. 대부분의 링크 계층 프로토콜들은 단편화 및 재조립 기능을 제공하지 않으며, 이것을 직접 구현해야 한다. 그리고 하위의 많은 링크 레이어 프로토콜들을 지원하기 위한 액세스 포인트가 제공되어야 할 것이다.

IP 위에서 구현할 경우, IP가 제공하는 단편화와 재조립 기능을 사용할 수 있다. 그리고, IP는 어떠한 링크 계층 위에서도 동작할 수 있도록 설계되었기에, 하위 레벨의 구현에 대해 신경쓸 필요가 없다. 하지만 IP의 포워딩 경로를 결정하는 프로토콜의 정보가 IP를 통해서 전달되는 것이므로, 정보 전달 방법을 매우 세심하게 설계할 필요가 있다.

UDP를 사용할 경우 체크섬과 8-bit인 IP 프로토콜 번호보다 더 큰 16-bit UDP 포트 번호를 사용할 수 있다. 그리고 몇몇 시스템들은 IP에 직접 접근하는 것은 특권을 필요로 한다(UNIX의 경우 superuser 권한) TCP를 사용할 경우 여기에 더해 신뢰성 있는 통신이라는 추가적인 이점을 가진다. TCP를 사용하는 프로토콜에는 BGP가 있다.

 

OSPF를 설계하던 시점에서, Link-State 라우팅 프로토콜은 자체적으로 신뢰성 있는 통신과 플러딩 메커니즘을 구현하고 있었다. 그리고 IP를 사용하는 것에 시스템 특권이 필요하다는 것은 일종의 ‘보안 장벽’으로 여겨졌다. UDP를 사용하는 것은 매 패킷마다 8바이트의 오버헤드를 더하는 일이었고, 그것을 통해 얻을 수 있는 8bit의 추가 공간은 사실 불필요한 것이었다.
그리하여 OSPF는 IP 레이어 위에서 동작하게 되었으며, IANA로부터 프로토콜 번호 89번을 부여받는다.

그리고, 캡슐화와 관련하여 추가적인 이슈가 있었는데, Ethernet과 같은 브로드캐스트 서브넷에서 동작할 때의 문제였다. 라우팅 정보 전송에 IP 브로드캐스트를 사용하는 RIP는 OSPF를 사용하지 않는 모든 단말에게도 패킷을 보냈고, 이것은 불필요한 라우팅 트래픽을 만들었다. 당시 개발중이었던 IP 멀티캐스트가 이 문제의 해결책이 될 것으로 여겨졌지만, 멀티캐스트를 사용하는 시스템의 수가 너무 적다는 문제가 있었다. 당시 UNIX에서 멀티캐스트를 사용하려면 커널을 직접 빌드해야만 했다. 하지만 OSPF의 개발자들은 멀티캐스트가 더 나은 방법이라 확신했고, 멀티캐스트 기반으로 OSPF를 설계하였다.

 

2-4. LSA 단편화

Link-State 프로토콜을 사용하는 라우터들은 자신의 라우팅 정보를 LSA(Link-State Advertisement)를 통해 주변 라우터에게 알린다. 만약 라우터가 자신의 정보를 하나의 LSA로 보내야 한다면, LSA의 크기는 아주 커질 것이다. 예를 들어, 인터넷의 IP 라우터들은 수천개에 이르는 경로들을 광고해야 한다. 그렇기에 많은 Link-State 프로토콜들은 하나의 큰 LSA 대신 작은 다수의 LSA를 만드는 것을 택하였다. 이것을 “LSA 단편화”라고 한다.

OSPF의 경우, LSA를 꽤 크게 만들 수 있었다. OSPF는 IP의 단편화와 재조립 기능을 사용할 수 있었고, 최대 65000바이트까지의 크기를 가질 수 있었다. 하지만, IP 단편화는 일반적으로 기피의 대상이 되었고, 대부분의 Link MTU 값이 1500Byte였기에 LSA의 크기를 그것보다 더 줄이기 위해 노력하였다.

LSA를 만들 때, 패킷의 크기를 가능한 한 크게 만드는 것은 패킷 전체에서 LSA 헤더가 차지하는 비율을 줄일 수 있다. 즉, 패킷 오버헤드가 감소한다. 하지만 OSPF는 LSA의 크기를 최대한 줄이는 것을 택하였다. 다수의 LSA를 통하여 개별 경로를 광고하는 것은 LSDB의 크기를 더 키우겠지만, 전체 라우팅 패킷의 양을 최소화 할 수 있을 것으로 여겨졌다. OSPF 도메인에서 변동이 발생하면, 오로지 변경된 경로의 정보만이 다시 플러딩된다.

LSA의 크기를 작게 만들고, 구조를 고정시킴으로써 LSA를 만들고 해석하는 것을 쉽게 하였다. 이것은 프로토콜을 구현하는 사람들에게 중요한 일이었다.
OSPF는 의도적으로 정적인 구조를 가지도록 설계되었다. 프로토콜에 유연성을 부여하는 것은 구현을 더 어렵게 만들고, 더 긴 테스트 시간을 필요로 한다. 그리고 최악의 경우에는 그러한 유연성 덕분에 구현체에서 보안 취약점이 생길 수 있다.

 

2-5. 서로 다른 Link Layer 프로토콜 위의 공통 매커니즘

각기 다른 특징을 가지는 많은 수의 Link-Layer 프로토콜들이 인터넷에서 사용된다. 어떤 프로토콜은 2개의 라우터끼리 서로 연결되고, 다른 프로토콜은 수 많은 라우터들이 서로 연결된다. 그리고 Ethernet과 같은 멀티캐스트가 지원되는 프로토콜과 ATM과 같이 멀티캐스트가 지원되지 않는 프로토콜이 존재한다. 이러한 프로토콜들은 서로 다른 MTU 값을 가지기도 하였다. Link-State가 ARPANET에서 개발되었을 때는 Point-to-Point 시리얼 연결만 고려하면 되었지만, 인터넷에서 OSPF가 널리 사용되기 위해서는 모든 종류의 Link-Layer 프로토콜들을 지원해야만 했다.

이러한 프로토콜들을 지원하기 위해서 OSPF는 3종류로 네트워크를 구분하였다.

첫번째가 바로 Ethernet이 사용하는 BMA(Broadcast Multi Access) 네트워크로, 브로드캐스팅이 지원되는 다중 접속 네트워크를 의미한다.
BMA 네트워크의 경우 LSA를 플러딩하는 방법이 문제가 되었는데, 각 라우터가 LSA를 전부 플러딩하게 되면 n2-n/2개의 LSA가 발생하게 된다. 이것은 네트워크 부하를 증가시킬 것으로 예상되었고(물론 RIP보다는 낫다), OSPF의 개발자들은 네트워크를 논리적인 성(Star)형 망으로 보는 구성을 취하게 된다. BMA 네트워크에서 OSPF는 LSA를 생성하는 역할을 맡는 DR(Designated Router)를 선출하며, 다른 라우터들은 LSA를 전달하는 역할만을 맡는다.
n개의 연결을 갖는 네트워크에서 Point-to-Point 플러딩 알고리즘을 사용함으로써, OSPF는 플러딩 트래픽을 최소화할 수 있었다.

두번째로, 브로드캐스팅이 지원되지 않는 다중 접속 네트워크인 NBMA(Non-Broadcast Multi Access)의 경우 DR 선출과 플러딩 매커니즘은 동일하나, 이웃 라우터들을 동적으로 찾을 수 없다는 차이점이 있다. 브로드캐스팅(멀티캐스팅)이 지원되지 않기에 이웃 라우터는 수동으로 지정되어야 한다.

마지막으로 포인트 투 포인트 네트워크의 경우, 1:1로 연결되기에 DR과 BDR을 선출하지 않으며, Neighbor끼리 LSA를 주고받음으로써 LSDB를 형성한다.

 

2-6. Backup Designated Router

브로드캐스트와 NBMA 네트워크에서는 DR에 의존하여 OSPF가 작동하게 된다. 하지만 DR이 다운된다면 새로운 DR이 선출되기까지 포워딩 결정이 이루어지지 못한다는 문제가 있었다. 이런 문제를 회피하기 위하여 BDR(Backup Designated Router)을 선출하고, DR과 동일한 매커니즘으로 LSDB를 유지, DR이 다운될 시 그 역할을 물려받게 하였다.

한편, 서브넷에 새로운 라우터가 추가될 때마다 SPF 재계산을 수행하는 것은 비효율적인 일이었고, 새로 추가된 라우터는 네트워크에 DR이 이미 존재하면 DR에 종속되어서 동작하도록 설계되었다.

 

2-7. 외부 경로 태그

OSPF는 OSPF 도메인 외부로부터 경로를 얻을 수 있도록 설계되었다. 외부 경로는 다른 라우팅 프로토콜로부터 학습하거나, 관리자가 직접 Static으로 지정할 수 있다. OSPF 워킹 그룹의 멤버였던 Milo Medin에 의해 외부 경로의 LSA에 External Route Tag를 붙였고, 이것은 OSPF에서 사용되지 않고, OSPF 도메인을 건너서 전달될 때 추가적인 정보를 전달하는 용도였다. OSPF가 최초로 디자인되었을 때, 이 외부 경로 태그의 용도는 아직 정해지지 않았으나 수 년 뒤 그것이 아주 유용하다는 사실이 증명되었다.
첫번째로, 태그는 라우팅 정책을 적용하기 위하여 사용되었다. 인터넷에서 하나의 라우터는 수 천개의 외부 경로를 전달받고, 포워딩 경로를 결정하며, ABR의 경우 그것을 다시 전달할 지 결정해야 한다. 이러한 결정은 대개 수동으로 입력된 라우팅 필터 리스트를 검색함으로써 이루어지는데, 외부 경로 태그는 OSPF 도메인으로 들어오는 경로들을 그룹화함으로써 설정을 단순화할 수 있었다. 특히 이것은 BGP-OSPF 간의 경로 전달에 유용하였다.

 

2-8. 계층적 축약

커다란 OSPF 네트워크를 구축하기 위하여 OSPF 라우팅 도메인은 지역별로 쪼개질 수 있다. 이것을 ‘Area’라고 한다. 에어리어의 세부 정보는 다른 에어리어들에게 감춰지며, 경로 정보는 집약되어(aggregated) 에어리어 경계를 넘어 전달된다. 이를 통해 라우팅 테이블의 크기가 지나치게 커지는 것을 방지하고, 더 큰 규모의 OSPF 도메인을 구성할 수 있도록 한다. OSPF 도메인을 에어리어 규모로 나누는 것은 2단계 계층 라우팅 방법으로 간주될 수 있다.

이러한 Area 구성을 위하여 디자인 단계에서 몇 가지 결정들이 내려져야 했다. 첫번째로, 무엇이 에어리어 경계가 될 것인지 결정해야 했다. 라우터? 네트워크 세그먼트? 혹은 둘 다? 앞서 다루었듯이 인터넷은 이미 네트워크 세그먼트들을 단위로 하는 Autonomous System을 경계로 나뉘어졌다.  하지만 OSPF는 정 반대의 선택을 하였고, OSPF Area의 경계는 라우터가 되었다. 이것으로 각 네트워크 세그먼트는 단 하나의 에어리어에만 속할 수 있으며, 이것은 Area Boundary에서의 주소 축약을 쉽게 만들어줄 것으로 생각되었다.

두번째로, 다른 에어리어에 어떻게 정보를 전달할 것인지 결정해야 했다. 목표로 하였던 스케일링 규모를 달성하기 위하여 에어리어를 건너서 전달되는 정보의 양을 줄여야 했다. 이것은 Abstraction(축약)이라 불리었는데, Link-State 프로토콜에서의 축약은 어려운 문제였다. OSPF 개발자들은 OSPF Network LSA와 유사한 구조로 정보를 전달할 수 있을지 검토하였다. 하지만 이러한 방법의 축약(DR과 연결된 라우터들의 ID를 전달하는 것)은 메트릭 값을 왜곡시킬 위험성이 있었다(Network LSA는 Metric을 포함하지 않는다) 그래서 단순히 Area 내부의 서브넷 정보를 축약해서 Distance Vector 프로토콜처럼 전달하였다(Summary LSA)

이러한 접근 방식을 취하면서도 Distance Vector 프로토콜의 문제점들을 피하기 위해서 OSPF는 모든 에어리어들은 Backbone Area라는 특별한 에어리어에 직접 연결되도록 강제했다. 에어리어 간 라우팅 정보는 반드시 Backbone Area를 거쳐서 전달되어야 하며, 단순한 Distance Vector 알고리즘으로 아무런 문제 없이 운용할 수 있게 되었다.
그리고 Backbone Area로의 물리적인 직접 연결이 힘든 경우를 위해, Backbone Area로의 논리적인 연결인 Virtual Links를 정의하였다.

 

3. OSPF 표준화

최초의 OSPF 프로토콜 명세가 1989년 8월 출판되었다. 대부분의 인터넷 프로토콜과 같이 OSPF도 버젼 넘버를 부여받았고, RFC 1131이 OSPFv1 프로토콜 문서가 되었다.
IETF의 모토가 “거친 합의, 작동하는 코드”였기 때문에 OSPF 설계가 종료되고, OSPF 워킹 그룹은 OSPF를 구현하여 실제로 동작한다는 것을 보여야 했다. 그리고 2개의 OSPFv1 구현체가 작성되었다. 하나는 Proteon의 라우터에서 동작하였고, 다른 하나는 메릴랜드 대학의 Rob Coltun에 의해 작성된 UNIX용 데몬이었다. 이 구현체의 소스코드를 아주 적은 값으로 입수할 수 있었기 때문에 널리 확산되었고, GATED 배포판에 포함되었다.

새로운 프로토콜의 구현체는 다양한 문제점을 숨기고 있었고, OSPFv1 또한 예외는 아니었다.
OSPF 라우터는 MaxAge가 지난 LSA를 폐기해야 하나, OSPFv1에서는 MaxAge가 초과된 LSA들이 라우팅 시스템을 돌아다니는 것이 확인되었다. 이 현상은 새로운 정보가 유입되는 것을 막을 수 있었고, 다음 버젼의 OSPF에서 이 문제가 해결되었음에도 MaxAge LSA를 폐기하는 문제는 많은 구현체에서 수 년간 남아 있었다.

다른 하나의 문제는 더 가상적인 것이었는데,  ARPANET의 Link-State 프로토콜은 라우팅 업데이트가 네트워크를 계속 순환하면서 전체 네트워크를 다운시켜 버리는 문제가 있었다. 이것은 ARPANET의 프로토콜이 LSA의 업데이트를 감지하기 위해서 사용한 Sequence Number에 기인하는데, Sequence Number의 공간이 충분히 크다고(패킷당 64Bit) 가정하였음에도 잘못 세트된 Sequence Number를 가진 패킷이 Wrap-around 되고, 또 Wrap-around 되었을 경우 Sequence Number를 업데이트 하기 위한 메커니즘의 결함으로, 특정한 Sequence Number를 가진 일련의 패킷들이 라우터로 들어오면, 무한히 정보를 업데이트하면서 네트워크를 마비시키는 문제였다. OSPFv1도 순환식 Sequence Number를 가지고 있었고, 이 문제를 해결하기 위하여 도입한 알고리즘의 결함이 발견되었기에, Linear한 Sequence Number를 가지도록 수정되어야 했다.

3-1. Sequence Number 문제

ARPANET은 원형의 Sequence Number를 가지고 있었다. 즉, 순환식 구조를 가지고 있었다. 그리고 Sequence Number는 한 시점에서 반원을 기준으로 유효하다고 판단되었는데(K1 < K2 < K1+n/2), 이 반원을 넘어가는 Sequence Number는 잘못된 것으로 판단되어 폐기되었다. 하지만, 만약 전체 공간을 1/3으로 나누는 일련의 Sequence Number들(K1<  K2<  K3)가 순차적으로 전송된다면, 각 LSA는 폐기되는 일 없이 네트워크를 순환하며 대역폭을 고갈시키고, 라우팅을 마비시키게 될 것이다. 실제로 ARPANET에서 이러한 문제가 발생하였고, OSPFv1에서는 Lolipop-Shaped Sequence Space를 도입하여 이것을 회피하였다. 최초 시작 값(S0)을 두고, 순환하게 되었을 때는 S1부터 시작하게 만든 알고리즘이었는데, 이 또한 S1~S3사이에서 문제가 발생할 경우 똑같은 취약점을 가지고 있었다.

그리하여 OSPFv2에서는 Linear Sequence Space를 도입하게 되는데, 32Bit의 Sequence Number 공간은 Signed 32-bit로 간주되고, 다음과 같은 순서로 동작한다.

1. 라우터는 최초의 Sequence Number(Initial Sequence Number, S0)를 0x80000001로 설정한다.
2. Sequence Number는 최대값(SMAX)인 0x7FFFFFFF까지 순차적으로 증가한다.
3. Sequence Number가 0x80000000이 되는 순간, Sequence Number는 S0으로 리셋된다.
4. 이 Sequence Number를 다른 라우터가 최신이라고 받아들이게 하기 위해 SMAX에 도달한 LSA를 MaxAge필드를 최대값으로 세트하여 플러딩, 폐기시킨다.

또한, OSPF는 체크섬을 통한 에러 감지와 홉을 지날때마다 LS Age 필드의 값을 증가시켜 MaxAge에 도달할 시 폐기함으로써 잘못된 LSA가 무한히 루핑하는 것을 막았다.

이러한 문제점을 해결하고 나서, OSPFv1는 몇 가지 최적화를 더했다. 이러한 문제점들은 널리 알려지지는 않았는데, 왜냐하면 OSPFv1이 인터넷에 적용되지 않았기 때문이다. 그리고 1991년 7월, OSPFv2가 RFC 1247로 출판된다.

3-2. 상호 운용성 테스트

다수의 독립된 구현체들이 서로 함께 동작하는 것은 좋은 프로토콜의 제작에 있어 필수적이다. 상호 운용성 테스트가 이루어지기 전까지는 프로토콜 명세 상의 모호함이 잘 드러나지 않는다. 구현자가 명세를 처음 읽고, 구현에 있어 모호한 점을 찾아내기란 쉬운 일이 아니기 때문이다. 그렇기에 종종 상호 운용성 테스트는 프로토콜의 구멍을 찾아내기도 한다. 특히, IETF의 라우팅 프로토콜 표준화 과정에서 상호운용성 검증은 필수적인데, TCP와 같이 호스트간의 운용성만 검증해야 하는 경우와는 달리, 라우팅 프로토콜은 네트워크 전체의 수 많은 라우터들과 협업해야만 하기 때문이다.

OSPF 프로토콜을 개발하는 동안 1990~1994년에 걸쳐 6번의 상호운용성 검증이 이루어졌다. 이 세션들에서 개발자들은 문제를 찾고, 버그를 고치고 경쟁자들의 어께 너머로 기술을 배우며 OSPF를 구현해나갔다.
테스트 토폴로지는 대개 작았지만, 3Com에서 열린 세션에서 인터넷(당시에는 BARBNet)연결을 통한 테스트를 진행하기도 했다.
OSPF의 bake-off는 이제 이루어지지 않지만, 벤더들이 자신들이 구현한 프로토콜들의 상호 운용성을 테스트하기 위한 장소는 여전히 존재한다.

테스트 중에 발견된 문제들은 주로 구현체의 문제였다. 테스트에 참가한 개발자들은 자신의 구현체를 빠른 속도로 탄탄하게 만들어갔으며, 테스트는 온갖 종류의 상황들을 만들어 냈다. 이들 중 몇몇은 프로토콜 명세와 충돌하기도 했는데, 주로 잘못된 프로토콜 패킷들이 발생하였다.
대부분의 문제들은 프로토콜 명세-특히 OSPF 패킷과 LSA 포맷-가 완성되지 않았기에 발생했다. 예를 들어, 최초의 테스트에서 디폴트 경로를 어떻게 나타낼 것인지에 대한 의견이 불일치하였다. OSPF에서 경로는 [네트워크, 마스크]쌍으로 표현되는데, OSPF 명세에서 네트워크만을 0.0.0.0으로 지정하였기에 한 구현체에서는 0.0.0.0과 0이 아닌 마스크를 디폴트 루트로 해석하고, 다른 구현체에서는 네트워크 마스크를 해석해서 디폴트 루트가 아니라고 생각하였다. (지금은 0.0.0.0 대역이 Reserved되어 있어 사용되지 않기에 이런 일이 발생하지 않는다)

테스트에서는 급격히 토폴로지가 변동하는 환경을 조성하기도 했는데, 라우터들이 주기적으로 리부트되고, 인터페이스가 살아났다 죽었다를 반복하는 등의 환경이었다. 이러한 환경은 OSPF 프로토콜 매커니즘에 부하를 가했고, 한 가지 예로 이웃 OSPF 라우터들이 서로의 OSPF Database를 동기화하는 과정 중에서 Sequence Number는 항상 증가할 것이라고 생각되었지만, Database Exchange 중에 LSA가 삭제되고 처음부터 다시 시작하는 경우가 발생하였다. 그래서 Database Exchange 메커니즘은 적절히 수정되어야 했다.

가끔은 OSPF가 디자인될 때 예상하지 못했던 상황이 발생하기도 했다. 한 경우, Virtual Link 설정이 OSPF 라우팅 계산을 실패하도록 만들었는데, 그 결과 OSPF 프로토콜 명세는 1994년, Virtual Links를 뜯어고치고서 재출판되었다.

 

3-3. 필드 테스트

상호운용성 테스트가 프로토콜 개발에 있어 많은 도움을 주긴 했지만, 여전히 실제 환경에서도 정상적으로 동작할지는 미지수였다. 그래서 상호운용성 테스트가 진행되던 도중 OSPF를 적용할 장소를 인터넷에서 찾기 시작했다.
처음은 OSPF의 개발자들이 OSPF를 사용하기 시작하였다. 그들은 자신들이 사용하는 네트워크에 OSPF를 적용하였고, 잘 동작할 때까지 테스트하였다. 그리고 OSPF 소프트웨어가 잘 동작한다는 확신이 들자 OSPF 개발자 외의 사람도 잘 사용할 수 있을지 테스트해볼 네트워크를 찾았다. NSF 지역 네트워크들이 적절한 대상으로 보였는데, 이 네트워크들은 당시 존재하던 TCP/IP 네트워크 중 가장 큰 네트워크였다. 그리하여 1990년, SURANet을 전환하려는 시도가 있었다.
OSPF로의 전환은 점진적으로 이루어지고, 라우터들은 RIP와 OSPF를 동시에 작동시킨 뒤, RIP 루트를 OSPF 루트로 전환할 계획이었다.

하지만 라우팅 테이블이 RIP를 사용하건, OSPF를 사용하건 간에 똑같아 보이는 문제와, 전환이 이루어지는 동안 전체 라우터를 텔넷과 SNMP만의 in-band management로 관리해야 하는 문제가 있었다. 이러한 이유로 몇 번의 시도 끝에 SURANet의 전환은 포기되었고, NASA Science Internet Network가 1990년 4월, RIP에서 OSPF로 전환되면서 OSPF가 최초로 인터넷에 적용된 사례가 되었다.

이러한 적용으로 OSPF는 몇 가지의 개선점을 발견하게 된다. 그 중 하나로, OSPF 라우터들이 불필요한 추가 Hop을 건너서 트래픽을 전달하는 경우가 있었다.
이것은 AS간 경계(OSPF Domain 경계)에서 발생했는데, AS 1의 Router A는 DMZ(현재는 Network Access Point라 불린다)에 연결되어 있고, AS 2의 Router C와 EGP로 정보를 교환한 뒤, “AS 2로 트래픽을 전달하고 싶으면 나에게로 보내”라고 말한다.
한편, 마찬가지로 DMZ에 직접 연결되어 있는 Router B도 AS 2로 트래픽을 전달하기 위해 Router C로 직접 전송하는 대신 Router A를 거치게 된다.
이 문제를 해결하기 위하여 OSPF에 Forwarding Address 개념이 도입되었다. 이제 라우터 A는 “AS 2로 트래픽을 전달하려면 Router C를 거쳐야 해”라고 말하게 되었다.

그리고 OSPF의 SPF Calculation을 수행하기에 충분하지 않은 CPU와 메모리를 가진 라우터들이 있었고, 이런 라우터들이 OSPF를 지원하기 위해 Stub Area라는 개념이 추가된다. Stub Area 내부의 라우터들은 외부 네트워크로의 트래픽 전달을 위해 ABR의 디폴트 루트만을 라우팅 테이블에 가지고 있는다. 이로써 라우팅 테이블의 크기를 줄이고, 연산 부하를 극단적으로 낮출 수 있었다.

또한, 실제 환경에서는 프로토콜 설계시 예상했던 것과 달리 IP 대역의 오버래핑이 발생하였다. OSPF는 Area 사이에서 IP 대역을 축약할 수 있는데, 최초에는 주소 대역의 오버래핑이 지원되지 않았다.
하지만, 하나의 IP 대역을 할당한 뒤 다른 Area에서 그 대역 중 일부를 재사용하는 것이 가능해야 했고, OSPF 명세는 이러한 설정을 지원하도록 수정되었다.

3-4. 표준이 되다

1992년부터 IETF는 인터넷의 공통 IGP를 선정하기 위한 작업에 들어간다. 사실상의 공통 IGP였던 RIP는 더 이상 적합해 보이지 않았다. 그리고 두 개의 공통 IGP 후보가 선정되었는데, 하나는 OSPF고, 다른 하나는 인터넷용으로 이식된 IS-IS(Integrated IS-IS)였다.
OSPF와 IS-IS가 둘 다 링크 상태 프로토콜이긴 하지만 둘 사이에는 기술적인 차이가 있었다. Integrated IS-IS가 기존 IS-IS의 개선판이기는 했지만, OSPF의 개발자들은 자신들이 IS-IS를 선택하지 않았던 원인들은 여전히 존재하며, OSPF가 더 좋은 선택이라고 생각했다. 물론, IS-IS의 개발자들은 IS-IS를 선호하는 자신들만의 기술적인 이유가 있었다.

한편, 기술적인 원인 외에도 IS-IS와 OSPF 사이의 논쟁은 계속되었는데, SNMP와 CIMP에서 시작되어, IPv6의 다양한 버전들에 이르기까지 이어져 온 IETF와 ISO 사이의 알력 다툼이 하나의 이유였다. OSPF 지지자들은 IETF에서 만들고, 변경할 수 있는 권리를 가진 OSPF가 인터넷 라우팅 프로토콜로 사용되는 것이 적합하다고 생각했다. 다른 한편으로 IS-IS 지지자들은 공통 IGP로의 선정이 OSI 프로토콜 수트가 인터넷에 적용될 기회라고 생각하였다.
그리고 다른 하나는 통합된 라우팅 프로토콜 그 자체에 관한 논쟁이었다. 두 개의 다른 프로토콜 집단이 있고, 두 종류의 프로토콜 집단을 지원하려 할 때 두 개의 라우팅 프로토콜 대신 하나의 통합된 라우팅 프로토콜을 가지는 편이 운용과 관리, 개발 면에서 훨씬 유리하지 않은가 하는 주장과, 충분한 수준의 유연성을 제공하기 위해서는 프로토콜이 두 종류로 분리되어야 한다는 주장이 서로 충돌하였다.

“거친 합의와 작동하는 코드”를 모토로 하는 IETF는 빠른 의사결정을 내릴 수 있도록 만들어지지 않았지만, 결국 OSPF를 공통 IGP 프로토콜로 선정한다. 하지만 그 시점에 대부분의 제조사들은 이미 OSPF를 적용하는 것을 선택한 후였다.

Network Study – 2주차 : 라우팅

 

지난 주에는 Ethernet은 OSI 7계층 중 두번째인 Data-Link 계층이며, 근거리 통신을 위한 기술이라는 것을 알아보았다.
하지만 Ethernet만으로는 인터넷을 구축할 수 없다. LAN과 LAN을 통합하고, WAN들을 서로 연결하는 범 지구적인 네트워크를 구축하기 위해서는 좀 더 큰 범위의 네트워크를 다룰 수 있는 표준이 필요하다.
그리고 이것을 구현하는 스택이 바로 Layer3, Network Layer이다.

1. Network Layer와 프로토콜

OSI 모델에서 Network Layer가 맡는 역할은 다음과 같다.

– 네트워크 사이의 연결 확립
– 네트워크 호스트에 대한 고유한 주소 발급
– 메시지 전송

이제, 이 역할들에 대해 좀 더 자세히 알아보도록 하자.

1-1. 네트워크 세그먼트 사이의 연결 확립

  Layer2 프로토콜인 이더넷을 다룰 때, 우리는 이더넷이 근거리 통신을 위한 프로토콜이라는 것을 배웠다.
이더넷 단독으로는 하나의 세그먼트에서의 통신만이 가능할 뿐, 세그먼트 사이의 통신은 지원하지 않는다. 이더넷 표준에는 세그먼트를 구분하는 방법과 해당 세그먼트로의 경로를 결정하는 방법이 정의되어 있지 않기 때문이다.
컴퓨터 네트워크가 확산되면서, IP(Internet Protocol), IPX(Internet Protocol Exchange)등의 프로토콜들이 등장하였고, 이 프로토콜들은 네트워크 세그먼트를 구분하는 방법을 제공한다.

또한, 통신 경로를 결정하는 방법으로 라우팅 프로토콜(Routing Protocol)이 제안되었다.

그럼 먼저, 네트워크의 구분 방법을 살펴보도록 하자.
IP가 만들어졌을 때에는 클래스(Class)를 통해 네트워크 세그먼트를 구분하였다.

예를 들자면,

– Class A: 0.0.0.0 ~ 127.255.255.255 / 128개의 네트워크, 네트워크당 16,777,216개의 호스트
– Class B: 128.0.0.0 ~ 191.255.255.255 / 16,384개의 네트워크, 네트워크당 65,536개의 호스트
– Class C: 192.0.0.0 ~ 223.255.255.255 / 2,097,152개의 네트워크, 네트워크당 256개의 호스트
– Class D(멀티캐스트): 224.0.0.0 ~ 239.255.255.255
– Class E(예약된 주소): 240.0.0.0 ~ 255.255.255.255

로 구분을 하였다. 각 클래스들은 IP 주소의 제일 앞 4비트를 통해 구분되며, 클래스가 내려갈수록 네트워크 비트가 8비트씩 증가하도록 약속되었다.

이것을 그림으로 나타내면 다음과 같다.

네트워크 비트에서 빨간색으로 표현된 부분이 바로 클래스를 구분하는 식별자이다.
Class A는 0(2), Class B는 10(2), Class C는 110(2), Class D는 1110(2), Class E는 1111(2)이 된다.

네트워크 비트가 달라지면, 해당 주소들은 ‘다른 네트워크’로 취급되며, 상호간의 통신을 위해서는 라우팅을 거쳐야 한다.
만약 이렇게 네트워크를 구분하지 않는다면, 컴퓨터 시스템은 어떤 호스트가 자신과와 같은 네트워크에 속해 있고, 추가적인 경로 설정 없이도 통신이 가능한지 알 수 없게 될 것이다.

이렇게 클래스를 통하여 세그먼트를 구분하는 네트워크를 클래스풀 네트워크(Classful Network)라 하며, 인터넷의 초창기에 이용되었다.
그리고 이러한 클래스풀 네트워크 사이의 통신 경로를 결정하기 위한 프로토콜로써 Classful Routing Protocol을 사용하게 된다.

하지만, 클래스풀 네트워크는 곧 문제에 봉착하게 되는데, 이 문제는 조금 뒤에 다루도록 하겠다.

1-2. Classful 라우팅 프로토콜(RIP)

  RIP(Routing Information Protocol)은 거리 벡터 알고리즘(Distance-Vector Algorithm)을 사용하는 라우팅 프로토콜로써, BSD 4.2에 라우팅 데몬으로 포함되면서 유명해졌다.
RIPv1은 Classful Routing을 수행하며, 일정 시간(30초)마다 모든 라우팅 정보를 교환하는 것(255.255.255.255/ 로컬 브로드캐스트 주소 사용), 그리고 전달 거리가 최대 15홉으로 제한되는 등의 이유로 현재는 거의 사용되지 않는다.
RIPv2는 VLSM(Variable Length Subnet Mask)를 지원하며 Classless Routing을 수행한다는 차이점이 있다. 현재의 최신 버젼은 IPv6를 지원하는 RIPIng이며, RIP의 버젼 별 상세는 조금 뒤에 다루겠다.

RIPv1은 Ethernet 상위의 프로토콜에 대한 경로 결정을 위하여 Xerox에서 개발한 프로토콜로, RFC 1058을 통해 표준화가 완료되었다.
RIP의 동작 방식은 다음과 같다. RIP가 활성화된 인터페이스는 30초마다 Broadcast Address(255.255.255.255)로 Request Message를 내보내고, Request를 수신한 다른 라우터가 Response Message를 내보낸다. 이 때, Response Message에는 라우팅 테이블 정보가 들어간다.

30초 마다 토폴로지를 공유하며, 링크 다운 등의 장애가 발생하였을 때 추가적으로 메시지를 내보내는 기능이 존재하지 않기 때문에, RIP는 매우 느린 수렴 시간을 갖는다. 이 때문에 잘못된 토폴로지 정보가 네트워크를 계속해서 순환하며 링크를 마비시킬 가능성이 있다. 이를 해결하기 위해 홉 카운트(Hop Count)를 두고, 15에서 라우터를 하나 거칠때마다 1씩 감소시키며, 0이 된 메시지는 폐기한다.
때문에 RIP는 최대 16개의 라우터만을 통과할 수 있다는 제약을 가지며, 규모가 큰 네트워크에서는 사용할 수 없다.

또한, 거리 벡터 알고리즘에 가중치가 존재하지 않기에, RIP는 홉 수가 작은 경로만을 최선의 경로라고 판단한다. 이에 따라 대역폭이 더 넓고, 지연시간이 더 짧지만, 홉 수가 더 큰 링크가 이용되지 않을 가능성이 있다.

이러한 문제점 때문에, RIP가 간편한 설정, 직관적인 전달 경로라는 장점을 가지고 있음에도 실제 네트워크에서는 사용되지 않는다. 대부분의 AS들은 IGP(Interior Gateway Protocol)로 OSPF를 사용한다.

1997년에 RIPv1을 개선한 RIPv2가 제안되었다. RIPv2는 RFC 2453으로 표준화되었으며, VLSM, MD5 인증 지원, 메시지 전송을 위해 멀티캐스트 주소(224.0.0.9) 사용 등의 기능이 추가되었다.

1-3. 라우팅 프로토콜

  앞 문단에서는 Classful 라우팅 프로토콜인 RIP를 다루었다. 그런데 라우팅 프로토콜이란 무엇이며, 어떤 역할을 하는 것일까? 더 깊이 들어가기 전에 이것을 먼저 알아보도록 하자.

인터넷이 확산되기 전에는 Static Routing이 주류를 이루고 있었다. 네트워크 자체가 크지 않았을 뿐더러, 변동 또한 적었기 때문이었다. 하지만 인터넷의 크기가 점점 커지면서, 경로 수정을 위해 사람이 일일히 개입해야 하는 Static Routing 대신 Dynamic Routing이 주류를 이루게 되었다. 그리고 이 Dynamic Routing을 수행하는 프로토콜이 바로 라우팅 프로토콜이다.

라우팅 프로토콜은 크게 두 종류가 존재한다. AS(Autonomous System)내부의 라우팅을 위한 IGP(Interior Gateway Protocol)과, AS간의 라우팅을 위한 EGP(Exterior Gateway Protocol)가 바로 그것이다.
우리가 흔히 접하는 RIP, EIGRP, OSPF, IS-IS등의 프로토콜은 모두 IGP이며, 현재 인터넷에서 사용되는 EGP는 BGP가 유일하다.

간단히 말하자면, 우리가 흔히 생각하는 회사의 내부 네트워크에 사용되는 프로토콜이 IGP이며, 이 내부 시스템이 Gateway를 통해서 인터넷에 노출되면, 인터넷 상에서의 라우팅을 위해 사용되는 프로토콜이 EGP이다.
그렇기 때문에, BGP는 대규모 인터넷 사업자나 ISP에서 사용하게 되며, BGP의 잘못된 설정은 인터넷 전체에 영향을 미칠 가능성이 있다. 이 때문에 시스코에서는 소규모 AS의 경우 BGP 대신 Static Routing을 적용할 것을 권장한다.

1-4. Classful Routing과 Classless Routing, 그리고 Subnet Mask

  라우팅에 대해 이야기하다 보니 IP의 일부를 다룰 필요가 생겼다. 앞서, 라우팅 프로토콜은 네트워크 세그먼트간의 통신 경로를 결정하기 위해 사용되는 프로토콜이라고 했다. 그리고 Classful Network에 대해 이야기하였다.
물론, Classful Network에도 서브넷 마스크는 있었다. 하지만, 이는 컴퓨터에서 빠르게 IP 주소의 계층을 확인하기 위해 만들어진 것이었지(AND 연산), 다른 추가적인 기능을 가진 것은 아니었다. 그래서 RIPv1은 Subnet Mask를 주고받지 않는다. IP의 범위만 봐도 이미 다 정해져 있기 때문이다!

하지만 Classful Network에는 아주 치명적인 문제가 있었으니, IP 주소의 비효율적인 할당이 바로 그것이다. 인터넷의 초창기에는 클래스 단위의 할당이 그리 문제되지 않았다. 하지만 곧 이것은 큰 문제가 되었는데, 예를 들어 A 클래스의 IP 대역을 할당받은 기업은 16,777,216개의 고유 주소를 갖게 된다. 하지만 대체 어떤 기업이나 조직이 이만한 수의 호스트를 갖는다는 말인가? 클래스 단위의 IP 주소 할당은 곧 IP 주소를 완전히 고갈시켜버릴 것으로 예측되었고, 이 문제를 해결하기 위해 CIDR(Classless Inter-Domain Routing)이 제안된다.

그리고, CIDR의 근간을 이루는 부분이 바로 VLSM(Variable Length Subnet Mask)이다. Classful Network에서는 서브넷 마스크의 길이가 고정되어 있었다. 하지만, CIDR을 도입하게 되면 서브넷 마스크를 가변적으로 설정할 수 있게 된다!
이를테면, 10.0.0.0/8 네트워크를 256개의 10.0.0.0/16 네트워크로 쪼갤 수 있는 것이다. 이로써 훨씬 효율적인 IP 주소의 할당이 가능해졌고, 이렇게 호스트/네트워크 비트를 알려주기 위한 수단으로 서브넷 마스크가 사용되게 되었다.

이제, 서브넷 마스크의 계산 방법을 한번 살펴보자.

CIDR을 이용하여 네트워크의 범위를 결정하는 방법은 아주 단순하다. IP 주소와, 해당 주소의 서브넷 마스크를 서로 AND 연산하기만 하면, 해당 주소의 네트워크 ID가 나온다. 그리고 네트워크 ID가 같은 주소는 같은 네트워크에 속한 것이다.
사실, 앞서 적었었던 192.168.0.0/24, 10.0.0.0/8과 같은 표기법은 CIDR에서 서브넷 마스크를 쉽게 표기하기 위해 만들어진 방법으로, CIDR Notation이라 한다.

이것을 좀 더 보기 쉽게 그림으로 나타내면 다음과 같다.

 이렇듯, CIDR을 사용하게 되면 네트워크 세그먼트를 식별하기 위한 Network ID라는 특별한 주소가 하나 필요하다. 이 IP 주소는 해당 네트워크를 대표하는 주소로써, 호스트에 할당되는 IP 주소는 Network ID 다음 주소부터가 된다.
또한, 한 가지 더 재미있는 부분은 CIDR에서는 직접 브로드캐스트 주소 또한 달라진다는 점이다. 이는 로컬 브로드캐스트 주소의 정의가 호스트 비트를 전부 1로 채우는 것임을 생각해보면 자명하다.

그리고 CIDR는 라우팅을 수행하는 것에 있어 부가적인 이점을 제공하는데, 여러개의 작은 네트워크로 가는 경로를 하나의 네트워크 경로로 축약할 수 있다는 점이다. 이를 Routing Prefix Summarization이라 한다.
이러한 축약은 대형 백본 라우터가 가지고 있는 라우팅 테이블의 크기를 줄여주지만, 이와 동시에 Longest Prefix Match라는 문제도 함께 불러온다.
현대의 라우터는 Longest Prefix Match를 wire-speed로 수행하기 위하여 TCAM을 사용하지만, 이것은 동시에 TCAM에 입력된 서브넷 마스크가 미리 정렬되어 있어야 한다는 것을 의미한다.

TCAM에 쓰기 작업을 하는 것은 (상대적으로) 긴 시간을 소비하기에, 라우팅 테이블을 갱신하는 횟수를 최대한 줄이기 위한 많은 알고리즘들이 있으며, 지금도 개발되고 있다.

1-5. Longest Prefix Match

  CIDR을 사용하는 네트워크 라우터에서 경로 판단을 위해 사용하는 알고리즘인 Longest Prefix Match에 대하여 자세히 알아 보자.

Longest Prefix Match란, 어떤 호스트로 가는 경로를 결정할 때, 가장 긴 Prefix를 가진 네트워크로 패킷을 전송한다는 것을 의미한다.
앞서 말했듯이, CIDR를 사용하는 라우터는 경로가 같은 작은 서브넷 여러 개를 묶어서 하나의 네트워크로 축약(Summarization)한다.

하지만, 궁극적으로 패킷이 전달되어야 할 네트워크는 하나이며, IP 주소를 할당받는 구성에 따라 자신과 목표 서브넷이 직접 연결되고, 축약된 나머지 네트워크들은 다음 라우터로 포워딩해야 할 수 있다.

예를 들어, 이런 구조의 네트워크가 있다고 하자.

이렇게 네트워크가 구성될 경우, R1은 172.16.0.0/24로 축약된 라우팅 경로를 R2에게 전달하고, R2의 라우팅 테이블에는 172.16.0.0/24는 R1에 연결되어 있다고 기록된다.
한편, R2의 라우팅 테이블에는 172.16.128.0./26이 자신과 직접 연결되어 있다는 정보도 함께 존재한다.

이런 상황에서 R2로부터 172.16.128.1로 가는 IP 패킷은 어디로 전달되어야 하는가?
Longest Prefix Match를 적용하면 172.16.128.1은 172.16.0.0/24보다 172.16.128.0/26에서 더 길게 매칭되므로, 패킷은 172.16.128.0/26으로 전달된다.

2. 라우팅 프로토콜 상세

2-1. 디스턴스 벡터(Distance-Vector) 라우팅 프로토콜

  디스턴스 벡터란, 라우팅 경로를 결정하는 것에 있어 목적지 네트워크까지의 메트릭(Metric)을 사용하는 것을 말한다. 메트릭이란 최적 경로 선택 기준을 말하며, 메트릭을 산정하는 방법은 프로토콜마다 다르다.
디스턴스 벡터를 사용하는 대표적인 프로토콜로는 RIP, EIGRP, BGP가 있다.
이 프로토콜들은 자신이 알고 있는 네트워크로의 메트릭 값을 인접 라우터에게 광고(Advertisement)한다. 디스턴스 벡터 프로토콜들은 전체 네트워크의 상태를 알지 못하며, 그저 목적지 네트워크로의 메트릭 값만을 안다.

또한, 디스턴스 벡터 프로토콜은 스플릿 호라이즌을 가진다. 스플릿 호라이즌이란, ‘라우팅 정보를 수신한 인터페이스로는 다시 그 정보를 광고하지 않는다’는 규칙으로, 디스턴스 벡터 프로토콜에서 발생할 수 있는 라우팅 루프를 방지하는 역할을 한다.
라우팅 루프란, 잘못 광고된 메시지 때문에 전달 경로가 계속 변경되는 것을 말하며, 다음과 같은 경우를 생각할 수 있다.
1. R1이 R2에게 자신이 10.1.0.0/24 네트워크와 연결되어 있다고 광고한다.
2. R2는 R1과 R3에게 이 정보를 전파한다.
3. R1과 R3는 R2가 10.1.0.0/24와 연결되어 있다고 생각한다.

이러한 상황을 막기 위하여 라우터들은 자신이 메시지를 수신한 인터페이스로 광고하지 않지만, 특정한 경우에는 이러한 스플릿 호라이즌 룰을 깰 필요가 있다. 이 부분은 추후 다시 살펴보도록 하자.

또한, 디스턴스 벡터 프로토콜 중 EIGRP와 BGP는 네트워크의 자동 축약을 지원한다. 즉, 앞서 Routing Prefix Summarization에서 설명했던 것처럼 작은 서브네트워크들을 주 네트워크 경계에서 자동으로 축약해서 전달하는 기능을 가지고 있다.

2-2. 링크 상태(Link-State) 라우팅 프로토콜

  링크 상태 라우팅 프로토콜은 목적지까지의 경로를 결정하는 것에 있어, 전체 네트워크 토폴로지를 가지고 계산을 수행한다. 각 라우터들이 자신과 접속된 네트워크와 인접 라우터 정보를 네트워크 전체에 공유함으로써 모든 라우터가 전체 네트워크 토폴로지를 알 수 있다. 따라서, 단순히 메트릭에 따라 경로를 결정하는 디스턴스 벡터 라우팅 프로토콜에 비해 더 정확한 경로를 알 수 있지만, 네트워크에 속한 라우터가 늘어남에 따른 메시지의 증가와 장애 발생시 수렴까지 걸리는 시간이 상대적으로 길다는 약점을 가지고 있다.
대표적인 링크 상태 프로토콜로는 OSPF와 IS-IS가 있다.

2-3. 라우팅 네트워크의 종류

  라우터가 연결된 L2 네트워크의 종류에 따라 라우팅 정보를 전달하는 방법이 달라지거나 제약될 수 있다.
이를테면, 브로드캐스트가 지원되지 않는 경우가 있을 것이다. 이런 유형의 네트워크를 NBMA(Non-Broadcast Multi Access)네트워크라 하며, 대표적으로 Frame Relay, ATM 네트워크가 있다. Frame Relay와 ATM은 가상 회로(Virtual Circuit)을 통하여 다중 접속을 구현하는데, 해당 장비와 연결된 물리적 인터페이스가 하나이더라도 내부적으로는 가상의 인터페이스를 만들어서 전송한다. 이 경우, 논리적으로는 이전의 회선 교환망과 같이 출발지와 목적지가 하나의 회선으로 연결된 것 처럼 보이게 된다는 장점이 있다.
때문에, NBMA 네트워크에서 브로드캐스팅으로 라우팅 정보를 전달해야 한다면, 라우터는 패킷을 복제해서 각 가상 회선별로 하나씩 보낼 것이다. 그렇기에 라우팅 정보를 광고해야 할 장비가 많다면 그 자체로 회선 대역폭을  소비할 수 있으니 주의가 필요하다.

다음으로 포인트 투 포인트(Point-to-Point) 네트워크가 있다. 하나의 인터페이스에 연결되는 상대 장비가 하나인 네트워크를 말하며, HDLC, PPP 등의 프로토콜이 있다. 포인트 투 포인트 네트워크에서는 접속된 상대방이 하나이기 때문에 어떠한 방법으로 라우팅 광고를 보내도 상관이 없다. 실제로 라우팅 프로토콜들은 이러한 경우 멀티캐스트나 브로드캐스트 주소로 라우팅 메시지를 광고하는 경우가 많다.

2-4. RIP(Routing Information Protocol) 상세 동작

  RIP가 동작하는 방식은 Classful Network를 다룰 때 이미 설명하였다.
여기서는 기본적인 동작 외에, 추가적으로 다룰 동작들을 설명하도록 하겠다.

RIPv2에서 VLSM지원이 추가되면서 축약 기능이 추가되었다. 물론, RIPv1은 이러한 기능을 지원하지 않으며, RIPv1과 v2를 혼용하는 환경에서는 둘 다 동일한 서브넷 마스크를 사용하거나 auto-summarization 기능을 꺼야 한다.
Cisco 라우터에서 자동 축약은 auto-summary가 활성화되어 있을 때 작동하며, 주 네트워크 경계(Major Network Boundary)를 기준으로 축약이 일어난다. 주 네트워크 경계란, Classful 네트워크에서의 네트워크 경계를 말한다.
그리고, RIPv2는 수동 축약을 지원하는데, 다른 주 네트워크 경계에 포함된 경로는 축약할 수 없다. 즉, 1.1.0.0/24와 1.1.0.8/24를 1.1.0.0/21로 축약할 수 있지만, 1.0.0.0/8과 2.0.0.0/8을 1.0.0.0/7로 축약할 수는 없다.

2-5. EIGRP(Enhanced Interior Gateway Routing Protocol)

  EIGRP는 Cisco에서 개발한 프로토콜로, OSPF와 더불어 현업에서 가장 많이 사용되는 프로토콜이다.
OSPF 대비 EIGRP가 가지는 장점으로는 Enequal Cost 부하 분산(메트릭 값의 차이에 따른 불균등한 부하 분산 적용)을 지원한다는 것과, 상대적으로 설정이 단순하다는 것이 있으나, Cisco 라우터에서만 사용 가능한 비표준 프로토콜이라는 치명적인 단점과, 대규모 네트워크에서의 SIA(Stuck In Active)문제가 있다.

EIGRP는 다음과 같은 순서로 라우팅 경로를 결정한다.

1. 네이버(Neighbor)구성, 네이버 테이블 생성
2. 라우팅 정보 교환, 토폴로지 테이블 생성
3. 라우팅 경로 계산과 라우팅 테이블 저장

이를 위해 EIGRP는 헬로, 업데이트, 라우팅 정보요청, 응답 및 수신확인 패킷을 사용한다.

1. 헬로(Hello) 패킷
헬로 패킷은 EIGRP가 네이버 정보를 구성하고 유지하기 위하여 사용된다. 또한, 헬로 패킷은 멀티캐스트 주소인 224.0.0.10으로 전송된다.
헬로 패킷의 구조는 다음과 같다.

먼저 EIGRP 패킷의 구조를 설명하겠다.
EIGRP 패킷은 헤더와 TLV(Type-Length-Value)로 구성된다. 먼저, 헤더의 구조는 다음과 같다

(1) Version : EIGRP 프로토콜의 버젼을 나타내며, 현재는 2이다.
(2) Opcode : EIGRP 패킷의 종류를 나타내며, Hello는 0x05이다.
(3) Checksum : EIGRP 패킷 전체의 체크섬 값이다.
(4) Flags : 1로 설정 시, 네이버 관계를 맺을 때 인접 라우터의 엔트리가 포함되어 있음을 알린다.
(5)/(6) Sequence / Acknowledge Number : RTP(Reliable Transport Protocol) 사용 시, 신뢰성있는 EIGRP 통신을 위해 사용된다.

헤더의 뒤에 TLV 쌍이 온다. Type과 Length는 각각 16비트의 값을 가지며, Length는 전체 TLV의 길이를 바이트 단위로 나타낸다.
따라서, 만약 Value의 길이를 알고 싶다면 Length의 값에 -4를 취하면 된다.
TLV는 EIGRP 패킷의 종류에 따라 유동적이며, 지금은 Hello 패킷을 기준으로 설명하도록 하겠다.

(1)~(5) K1~5 : EIGRP 메트릭 상수인 K1~5의 값이다.
(6) Reserved : 현재 사용되지 않는 값이다.
(7) Hold Time : EIGRP 라우터는 인접 라우터에게서 일정 시간동안 헬로 패킷을 받지 못하면 문제가 발생한 것으로 보고 네이버 관계를 해제하는데, 이 때의 시간값이다.

Hello 패킷에서 중요한 부분은 EIGRP Parameter의 Hold Time과, 헤더의 Autonomous System Number이다.
EIGRP는 Hello를 수행하면서 AS 정보와 홀드 주기를 알게 된다.

2. Update 패킷
EIGRP Update는 라우팅 정보를 전송할 때 사용된다. 네트워크의 종류에 따라 224.0.0.10 / 유니캐스트로 전송된다.
Update 패킷의 구조는 다음과 같다. (헤더 생략)

IPv4의 IP Internal Route TLV이다.
Update 패킷은 일련의 Internal Route TLV들을 포함하고 있으며, 필드의 정보는 다음과 같다.

(1) Next Hop : Destination 네트워크로 가는 다음 홉 라우터의 정보를 말한다
(2) Delay : 목적지 네트워크까지의 지연 시간의 합을 나타낸다. EIGRP에서는 라우터를 거칠 때마다 Delay가 증가한다.
(3) Bandwidth : 해당 네트워크까지의 최소 인터페이스 대역폭을 나타낸다
(4) MTU : 해당 네트워크까지의 MTU값이다. 자신의 MTU값이 더 작다면 이 필드를 재기록해서 다른 라우터들에게 광고한다.
(5) Hop Count : 해당 네트워크까지의 홉 수를 나타낸다. EIGRP의 기본 최대 홉 수는 100이며, 최대 255까지 설정할 수 있다.
(6) Reliability : 해당 링크의 신뢰성을 말한다. 메트릭 값을 결정할 때 사용되며, 현재는 잘 이용하지 않는다.
(7) Load : 해당 링크의 부하를 말한다. 마찬가지로 잘 이용되지 않는다.
(8) Prefix Length : CIDR Rrefix 길이를 나타낸다.
(9) Destination : 목적지 주소값이다.

IPv4의 IP External Route TLV이다.

Internal Route TLV에서 추가된 부분만 언급하자면,

(1) Originating Router : 해당 네트워크의 정보를 EIGRP AS에 재분배한 라우터의 Router ID 혹은 IP Address를 말한다.
(2) Originating AS Number : Originating Router의 AS 번호를 말한다.
(3) Arbitrary Tag : 라우트 맵(Route-Map)에 의해 지정된 태그 정보를 가진다.
(4) External Protocol Metric : 해당 프로토콜의 메트릭 값을 말한다.
(5) External Protocol ID : 재분배된 프로토콜의 구분자이다. 0x01은 IGRP, 0x02는 EIGRP, 0x03은 정적 루트, 0x04는 RIP, 0x05는 Hello 프로토콜, 0x06은 OSPF, 0x07은 IS-IS, 0x09는 BGP, 0x0A는 IDRP, 0x0B는 직접 연결된 링크이다.
(6) Flags : 0x01인 경우 해당 경로가 재분배된 경로임을 뜻한다. 0x02인 경우, 이 재분배된 경로가 디폴트 루트임을 뜻한다.

이렇듯, EIGRP는 Hello와 Update값에 포함된 정보로 해당 네트워크의 메트릭 값을 결정하게 된다.
EIGRP에서 메트릭 값을 결정하는 식은 다음과 같은데,


일반적으로 K1, K3를 1로 설정하고 나머지를 0으로 두기 때문에, 실질적으로는 Bandwidth값과 Delay 값으로 메트릭을 결정하게 된다.
Reliability와 Load를 사용하지 않는 것은, 이 두 가지 패러매터가 빈번하게 변동되기 때문에 라우팅 경로가 계속 변동하면서 네트워크 전체가 불안정해 질 수 있기 때문이다.
그렇기에 자주 사용되지 않으며, 특수한 경우 metric weights 명령어를 사용하여 설정할 수 있다.
metric weights 명령어는 6개의 인자를 받으며, 첫번째 수는 TOS 값으로 항상 0, 나머지는 K1~5 상수값이다.

또한, EIGRP에 속한 모든 라우터들의 K 상수값이 일치하지 않으면 Neighbor 관계가 성립하지 않으므로 주의가 필요하다.

Query와 Reply 패킷 또한 동일한 Internal/External Routes TLV를 사용하며, 자세한 내용은 추후 다루겠다.

2.5.1. DUAL 알고리즘

  라우팅 정보 교환을 마쳤다면, 이제 토폴로지 테이블을 작성해야 한다. 이 때 사용되는 것이 바로 DUAL(Diffusing Update ALgorithm)이다.
토폴로지 테이블이란, DUAL에서 사용하는 인접 라우터에서 수신한 네트워크와 메트릭 값을 저장해 둔 데이터베이스를 말한다.
토폴로지 테이블에는 다음과 같은 값들이 저장된다.

1. RD(Reported Distance) : Next-hop 라우터에서 목적지 네트워크까지의 메트릭 값
2. FD(Feasible Distance) : 현재 라우터에서 목적지 네트워크까지의 최적 메트릭값
3. Successor : 최적 경로상에서의 Next-hop 라우터
4. Feasible Successor : Successor가 아닌 라우터 중에서 RD < FD를 만족하는 넥스트 홉 라우터

이제 이 라우터가 네이버로부터 Update 패킷을 수신하면 다음과 같이 DUAL 알고리즘이 동작한다.

1. 기존의 경로보다 더 좋은 메트릭을 가진 경로를 수신하였을 때 : 석세서를 그 경로를 전송한 라우터로 변경하고, 네이버에게 Update 전송
2. 기존보다 나쁜 경로를 석세서가 아닌 네이버로부터 수신하였을 때 : 해당 정보를 무시한다.
3. 기존보다 나쁜 경로를 석세서로부터 수신하였을 때 : 피저블 석세서를 선택하고 네이버에게 Update 전송.
3-1. 피저블 석세서가 존재하지 않을 때
해당 라우터는 네이버에게  쿼리(Query) 패킷을 전송한다. 이것을 확산(Diffusing)이라고 하며, 이를 통하여 전체 네트워크가 최적 경로를 다시 결정한다.
쿼리 패킷은 네트워크를 타고 전파되는데, 라우터가 해당 네트워크의 정보를 가지고 있지 않거나, 네이버가 없거나, 피저블 석세서가 존재하거나, 액티브(Active) 상태이면 그 라우터에서 쿼리 전송이 종료된다.
쿼리 패킷을 보내고 응답(Reply)을 받지 못한 상태를 액티브(Active), 쿼리 패킷을 전송하지 않은 상태를 패시브(Passive)라 한다.
쿼리를 전송한 라우터들은 자신이 쿼리를 전송한 네이버들의 리스트를 유지하면서, 해당 라우터들에게서 응답 패킷을 전부 수신한 뒤에야 패시브 상태로의 천이와 경로 계산이 가능해진다.
그리고 기본적으로 3분 이내에 응답을 수신하지 못하면 네이버 관계를 해제한다.

이로써 모든 네트워크 노드가 새로운 최적 경로를 갖게 되지만, 장애 유형에 따라 최적 경로가 계속 변동되고 링크가 절단되는 SIA(Stuck In Active) 문제가 발생할 수 있다.

2.5.2. EIGRP 네트워크 축약

  EIGRP 또한 RIP와 같이 주 경계 네트워크에서 자동 축약을 지원한다. 하지만 최근 버젼의 IOS에서는 EIGRP 자동 축약이 기본적으로 비활성화되어 있다.
자동 축약을 활성화, 비활성화 하려면 다음과 같은 명령어를 사용한다.

EIGRP는 자동 축약과 별개로 수동 축약을 지원한다. 이 때, 수동 축약 설정은 축약된 네트워크를 전송하고자 하는 인터페이스에서 설정한다.

EIGRP로 네트워크를 축약하여 광고할 경우, 라우터는 축약된 모든 네트워크가 다운되어야 축약된 네트워크의 광고를 중단한다.
이 때문에 디폴트 루트에 따른 라우팅 루프가 발생할 수 있는데, 이 문제를 미연에 방지하기 위하여 네트워크를 축약한 라우터의 라우팅 테이블에는 축약된 네트워크의 기본 게이트웨이가 null 0(블랙홀) 인터페이스로 잡히게 된다.
정상적으로 라우팅이 이루어질 때에는 Longest Prefix Match 룰에 의해 세부 경로로 라우팅이 이루어지지만, 만약 일부 네트워크가 다운된다면 네트워크를 축약한 라우터는 다른 라우터에서 들어오는 다운된 네트워크로 가는 패킷들을 블랙홀 인터페이스로 보내 폐기한다.

또한, EIGRP에서 축약된 네트워크의 메트릭 값은 세부 네트워크들의 메트릭 중 가장 낮은 값을 가진다.

2.5.3. EIGRP 네임드 모드

EIGRP를 AS번호와 같이 사용하는 것이 아닌, 이름을 이용해서 사용한다면, EIGRP는 네임드 모드로 작동한다. 네임드 모드에서는 EIGRP 와이드 메트릭 사용과 하나의 설정 모드에서 거의 모든 EIGRP 설정을 할 수 있다는 장점이 있다.
EIGRP 네임드 모드로 진입하려면 다음과 같은 명령어를 사용한다.
router eigrp testEIGRP

그리고 EIGRP 네임드 모드 사용시, 프로토콜 설정 모드와 인터페이스 설정 모드에서 설정해야 했던 항목들을 eigrp 설정 모드에서 조작할 수 있게 된다.

address-family의 인자로는 ipv4/ipv6를, 그 뒤에는 바로 AS를 지정하거나 unicast, VRF이름을 지정할 수 있다.
unicast 옵션 다음에는 다시 AS 번호나 VRF이름을 지정할 수 있다.

AS 설정 모드로 진입한 후에는 해당 AS의 네트워크 설정을 할 수 있다.

EIGRP 네임드 모드에서 사용할 수 있는 명령어는 다음과 같다.

– af-interface : EIGRP 인증, EIGRP 대역폭, BFD, 헬로 주기, 홀드 타임, passive-interface 기능, 스플릿 호라이즌, 네트워크 축약 설정
– eigrp : EIGRP 경로 태깅, EIGRP 네이버 로그 설정, EIGRP Router ID 확인, Stub 에어리어 설정
– maximum-prefix : EIGRP 네이버에게서 수신할 수 있는 최대 네트워크 수를 초과하였을 때의 동작
– metric : EIGRP 메트릭 패러메터와 RIB-Scale 설정
– neighbor : EIGRP 네이버 주소와 네이버에게서 수신할 수 있는 최대 네트워크 수 설정
– topology : 축약, 재분배, distance 설정, offset-list, 부하 분산 설정

2.5.4. EIGRP 와이드 메트릭

기존 EIGRP 메트릭이 10Gbps 이상의 인터페이스 대역폭을 제대로 계산하지 못하는 것과, 1Gbps 이상의 인터페이스 딜레이를 제대로 반영하지 못하는 문제를 해결하기 위하여 64bit 값을 사용하는 EIGRP 와이드 메트릭을 도입하였다.
와이드 메트릭의 복합 메트릭 계산 방법은 다음과 같다.

일반적으로 K1, K3 = 1이므로 복합 메트릭 값은 Throughput + Latency이다.
이 때 Throughput 값은 65536 * 107 / 가장 느린 인터페이스의 대역폭이다. 결과적으로 와이드 메트릭의 대역폭은 기존 EIGRP 메트릭의 값에 65536을 곱한 값이 된다.
또한, 인터페이스 딜레이 값의 단위가 밀리세컨드(ms)에서 피코세컨드(ps)로 조정되었으며 1Gbps 이상의 인터페이스 딜레이 값은 1013 / 인터페이스 대역폭으로 정의되었다.

그리고, 64비트 값을 가지는 와이드 메트릭 값은 RIB에 탑재되기 전에 32비트에 맞도록 크기를 조절해야 하는데, 이 때 이용되는 것이 rib-scale 명령어이다.
기본값은 128로 설정되어 있으며, 와이드 메트릭 값 / rib-scale 값이 RIB에 탑재되게 된다.

2-6. 라우팅 경로의 재분배

  복수의 라우팅 프로토콜이 운영되는 환경에서, 다른 방법으로 알게 된 정보를 라우팅 프로세스에 포함시키는 것이 ‘라우팅 경로 재분배’이다.
이 때, ‘다른 방법’은 직접 연결된 경로, 정적 경로, 다른 프로토콜의 경로 정보를 말한다. 직접 연결된 경로를 재분배하는 것이 상당히 의아할 수 있는데, network 명령어 대신 재분배를 이용하여 네트워크를 연산 과정에 포함하면 해당 인터페이스와 네이버 관계를 맺지 않기 때문에 네트워크의 보안을 강화할 수 있다. 이러한 특성으로 종단 단말과 연결된 스위치를 라우터와 연결할 때 주로 사용하는 방법이다.
또한, 루프백 인터페이스를 호스트 루트가 아닌 것으로 광고하기 위하여 사용되기도 한다.

경로 재분배를 사용할 때 주의해야 할 점으로는 한 라우터 내에서 하나의 프로토콜이 재분배받은 경로는 다른 프로토콜에게 다시 재분배 해 줄 수 없다는 것과 라우팅 프로토콜 간의 AD 값, 메트릭, 컨버전스 시간, 서브넷 정보 전송 여부 등이 다르기 때문에 네트워크를 불안정하게 만들거나 비최적 경로 라우팅이 일어날 수 있다는 점이다. 이것은 초기 메트릭(Seed Metric)값 조정, AD 조정 등의 방법으로 극복될 수 있다.

2-7. OSPF(Open Shortest Path First Protocol)

OSPF는 RFC2328을 통해 표준화된 Internet Standard 프로토콜이다. 시스코 독점이었던 EIGRP와 달리, OSPF는 인터넷에 연결되는 장비라면 반드시 지원해야 하는 프로토콜이며, 이 때문에 가장 널리 사용되는 IGP가 되었다.
OSPFv2는 기본적으로 IPv4를 지원하며, IPv6 확장인 OSPF for IPv6(RFC5340)이2008년 제안되었다.
OSPF의 특징으로는 링크 상태 프로토콜이라는 것과 에어리어 단위로 동작하는 프로토콜이라는 점이 있다.
OSPF에 대해 이야기 하기 전에, OSPF에서 사용하는 용어를 먼저 정리하고 들어가도록 하자.

– LSA(Link State Advertisement) : OSPF에서 라우팅 정보를 전달하기 위하여 사용하는 패킷
– Area : OSPF에서 경로 연산을 수행하는 단위 영역
– Area 0(Backbone Area) : OSPF Area들이 반드시 직접 연결되어야 하는 Area.
– Router ID : OSPF에서 라우터를 식별하는 고유 값. 기본값은 라우터의 루프백 인터페이스 IP이며, 루프백 인터페이스가 없을 경우 인터페이스에 할당된 IP중 가장 작은 값이다. 문제를 피하기 위해 대부분 수동으로 설정한다.
– Adjancent Neighbor : LSA를 주고받는 네이버, DR/BDR

2.7.1. OSPF 패킷

OSPF에서 Neighbor관계를 맺고 정보를 교환하는 과정을 다루기 위해서 먼저 OSPF 패킷 구조를 알아보도록 하자.

(1) OSPF 공통 헤더

(1) Version : OSPF 프로토콜의 버젼을 의미한다. 현재 OSPF 프로토콜의 버젼은 2이다.
(2) Type : OSPF 메시지 타입을 알린다. 0x01은 Hello, 0x02는 Database Description Packet, 0x03은 Link State Request Packet, 0x04는 Link State Update, 0x05는 Link State Acknowledgement 이다.
(3) Packet Length : OSPF 공통 헤더를 포함한 전체 메시지의 길이를 나타낸다.
(4) Router ID : 해당 메시지를 전송한 라우터의 OSPF ID를 말한다.
(5) Area ID : 이 메시지가 속한 OSPF Area ID를 말한다.
(6) Checksum : Authentication Data 필드를 제외한 나머지 패킷 전체에 대한 CRC-16 체크섬 값이다. 인증 데이터 필드를 제외하는 이유는 체크섬 또한 인증 프로세스의 일부로 간주되기 때문이다. 그리고 인증 방식으로 MD5를 사용할 경우 체크섬 필드는 사용되지 않고, 0으로 설정된다.
(7) Authentication Type : OSPF 인증 방식을 나타낸다. 0은 인증 없음, 1은 Plain Text 패스워드 인증, 2는 패스워드의 MD5 해쉬이다.
(8) Authentication Data : 인증 방식에 따라 다른 값을 갖는다. Plain-Text 인증의 경우, 64bit 길이의 패스워드가 오며, 이 때문에 최대 패스워드 길이는 8자로 제한된다. (검증 필요)
MD5 인증의 경우 Auth Crypt Key ID, Auth Crypt Data Length, Auth Crypt Sequence Number, Auth Crypt Data가 차례로 온다. MD5 해쉬의 길이가 128Bit이기에 Auth Crypt Data Length는 16(바이트), Auth Crypt Data는 128Bit의 값이 온다.

(2) OSPF Hello

(1) Network Mask : 해당 인터페이스에 할당된 서브넷 마스크를 나타낸다.
(2) Hello Interval : Hello 패킷을 보내는 주기를 초로 나타낸다. Neighbor을 맺기 위해서는 이 값이 동일해야 한다.
(3) Options : OSPF Option 필드이다. 왼쪽부터 DN, O, DC, L, N, MC, E, MT 플래그 값을 나타낸다.

(3-1) DN : MPLS Based L3 VPN(RFC2547)에서 OSPF를 사용할 경우 세트된다. 이 환경에서 발생할 수 있는 라우팅 루프를 방지하기 위하여, DN 플래그가 1인 Type 3,5,7 LSA를 받으면, 이 LSA는 OSPF 경로 계산에 사용되지 않는다.
(3-2) O : 라우터가 Type 9, 10, 11 Opaque LSA를 지원할 경우 세트된다.
(3-3) DC : 라우터가 OSPF over Demand Circuit을 지원할 경우 세트된다.
(3-4) L : OSPF 패킷이 Link-Logical Signalling(LLS) 데이터 블록을 가질 경우 세트된다. LLS는 Cisco사에서 제안한 OSPF 확장 프로토콜로, RFC5613에 정의되어 있다.
(3-5) N : Hello 패킷에서만 사용된다. 라우터가 Type 7 NSSA-External-LSA를 지원할 경우 세트된다. N비트가 세트된 라우터들 끼리 네이버를 맺는 것이 가능하며, E비트는 반드시 0으로 세트되어야 한다.
(3-6) P : NSSA-External-LSA 헤더에서 세트된다. 때문에, P와 N은 옵션 필드에서 같은 역할을 공유한다. P 플래그는 NSSA ARB가 Type-7 LSA를 Type-5 LSA로 변환할 수 있음을 알린다.
(3-7) MC : 라우터가 OSPF Multicast Extension(MOSPF)를 지원할 경우 세트된다.
(3-8) E : 라우터가 AS External LSA를 받아들일 수 있을 경우 세트된다. 따라서 모든 AS External LSA와 백본 에어리어, non-stub 에어리어에서 만들어진 메시지는 E플래그가 세트되어 있어야 한다. E플래그가 일치하지 않는 라우터 사이에서는 네이버 관계를 맺을 수 없다. (검증 필요)
(3-9) MT : 라우터가 Multitopology OSPF(MT-OSPF)를 지원할 경우 세트된다.

(4) Router Priority : OSPF에서의 우선순위를 나타낸다. 이 값이 클수록 우선적으로 Designated Router/Backup Designated Router에 선출된다. 기본값은 1이며, 0일 경우 Designated Router에 선출되지 않는다.
(5) Router Dead Interval : 라우터가 죽은 것으로 판단하기까지의 시간 값을 초로 나타낸다. Hello 패킷 수신시마다 리셋되며, 서로 일치하지 않을 경우 네이버 관계를 형성할 수 없다.
(6) Designated Router : Designated Router의 Router ID값을 나타낸다. 선출되지 않았을 경우 0.0.0.0이다.
(7) Backup Designated Router : Backup Designated Router의 Router ID 값이다. 상동.
(8) Active Neighbor : Active 상태인 Neighbor가 존재할 경우 해당 라우터의 Router ID 값을 나타낸다.

(3) OSPF LSA

OSPF에서 정보를 주고받기 위하여 사용되는 구조체인 LSA를 다룬다. 먼저, OSPFv2(RFC2328)에서 5종류의 LSA가 정의되었다. 그리고 몇 개의 확장이 더해져 현재는 11종류의 LSA가 존재한다.
LSA는 Hello를 제외한 다른 모든 OSPF 패킷에서 사용되며, DD와 LSA Request, LSA Ack는 LSA 헤더만을 사용한다.

0. OSPF LSA Header

OSPF LSA의 공통 부분인 헤더이다. LSA의 종류, 중복 방지 매커니즘 등을 담고 있다. 각 요소의 기능은 다음과 같다.

(1) LS Age : LSA가 생성되고 나서 지난 시간을 초 단위로 나타낸다. LSA Max Age 매커니즘과 LSA Refresh에 사용된다. Max Age의 길이는 1시간이며, LSA Refresh는 30분 단위로 일어난다.
(2) Options : OSPF Options 필드와 동일
(3) LSA Type을 지정. 현재 총 11종류의 LSA가 존재한다.

3-1. Router LSA
LSA Type은 0x01, 모든 라우터에서 생성되는, 자신의 인터페이스 상태를 나타내는 LSA이다. Area를 넘어갈 수 없다.
Router LSA는 인터페이스의 IP 주소를 가지고 있으며, Router LSA를 수신한 ‘모든’ 라우터들은 수신한 인터페이스를 제외한 다른 모든 (OSPF가 활성화된) 인터페이스로 LSA를 플러딩해야 한다.

3-2. Network LSA
LSA Type은 0x02, Broadcast/Non-Broadcast Multi Access 네트워크에서 DR에 의해 생성되는 LSA이다. DR과 연결된 라우터들의 Router ID를 갖는다.
Area 내부의 네트워크에 대한 정보를 가지고 있다.
Broadcast Netrowk에 속한 OSPF 라우터들은 Network LSA의 네트워크  정보와 Router LSA의 인터페이스 주소 정보를 기반으로 전달 경로를 찾는다.

3-3. ABR Summary LSA (Type 3)
LSA Type은 0x03, Area Border Router(ABR)에 의해 생성된다. Area 외부의 네트워크에 대한 정보를 Area 내부로 전파한다.

3-4. ASBR Summary  LSA (Type 4)
LSA Type은 0x04, ABR에 의해 생성되며, AS Boundary Router(ASBR)로 가는 경로와 Cost를 알린다.

3-5. AS-External-LSA
LSA Type은 0x05, ASBR에 의해 생성되며, OSPF 도메인 외부의 네트워크로 가는 경로를 OSPF 도메인 내부로 전파한다. 즉, 재분배된 경로를 전파한다.

3-6. Group Membership LSA
LSA Type은 0x06, MOSPF(Multicast Extensions to OSPF)에서 제안된 LSA로, RFC1584가 표준화 과정에서 폐기되었기에 사용하지 않는다.

3-7. NSSA External LSA
LSA Type은 0x07, OSPF NSSA Option(RFC1587, 현 RFC3101)에서 제안된 LSA로, NSSA(Not-so-stubby-Area)에 속한 라우터가 재분배받은 정보를 전파할 때 사용한다.
앞서 말했듯이, Type 7과 Type 5를 동시에 처리할 수는 없으므로, ABR중 하나가 Type7 to 5 Translator 기능을 수행하여 Non-stub Area로 외부 경로를 전파하게 된다.
RFC1587에 따르면 Type 5 LSA가 Type 7 LSA보다 우선적으로 LSDB에 탑재된다.

3-8. External-attribute-LSA / Link-Local Only LSA for OSPFv3
LSA Type은 0x08, BGP 정보를 AS내부에서 전달할 때 iBGP 대신 OSPF를 사용할 경우를 위해 만들어졌다. LSA Type 8 내부에 LSA Type 5를 여러 개 탑재하여 BGP Attribute 정보를 전달한다는 발상이었으나, 표준화가 중단되었기에 지금은 사용되지 않는다.
OSPFv3에서는 Link-Local Address와 해당 링크의 IPv6 주소 정보를 전달한다.

Type 9~11은 Opaque LSA로써, OSPF Opaque LSA Option을 다룰 때 같이 설명하겠다.

(4) Link State ID : LSA의 종류에 따라 다른 값을 갖는다.

4-1. Router LSA : LSA를 생성한 라우터의 Router ID 값
4-2. Network LSA : DR의 IP 인터페이스 주소 값
4-3. Summary LSA : 목적지 네트워크의 IP 주소
4-4. Summary LSA : LSA에 서술된 ASBR의 Router ID 값
4-5. AS-External-LSA : 목적지 네트워크의 IP 주소

여기서 알 수 있듯이, Router LSA의 경우 Link State ID와 Advertising Router 필드의 값은 동일하다.

(5) Advertising Router : LSA를 생성한 라우터의 Router ID 값
(6) LS Sequence Number : LSA를 식별할 수 있는 식별자. 낡거나, 중복된 LSA를 식별하기 위해 사용된다.
(7) LS Checksum : LS Age 필드를 제외한 LSA의 CRC-16 체크섬
(8)Length : LSA의 길이. 20Byte의 LSA Header를 포함한다.

(4) OSPF DD(Database Description) 패킷

OSPF Database Description 패킷은 Hello 종료 후 Adjacency가 시작될 때 교환된다. DD 패킷은 LSDB에 대한 간략한 정보(LSA Header들)을 가지고 있으며, Master-Slave를 선출하여 Ack을 수행한다.

DD 패킷의 구조는 다음과 같다. (OSPF 헤더 생략)

(1) Interface MTU : DD를 전송하는 인터페이스의 최대 MTU값을 나타낸다. Virtual link에서는 0으로 세트된다.
(2) Options : Hello의 Options과 동일.
(3) Flags : DD 패킷에서 사용되는 플래그로, 첫 5비트는 0, 나머지 3비트가 플래그로 사용된다.

(3-1) I-Bit : Init Bit. 첫 DD 패킷인 경우 1로 세트된다.
(3-2) M-Bit : More Bit. DD 패킷이 뒤에 더 온다는 것을 알린다.
(3-3) MS-Bit : Master/Slave Bit. 라우터가 Master일 경우 1로 세트된다. Router ID가 높은 쪽이 Master가 된다.

(4) DD Sequence Number : DD Sequence에서 패킷을 구분하기 위해 사용된다. 순차적으로 증가하며, Master만이 Sequence Number를 증가시킬 수 있다. Master가 DD를 보내면, Slave가 그 응답으로써 같은 Sequence Number를 가진 DD를 보낸다. 그리고 Master는 Sequence Number를 1 증가시킨다. Database를 완전히 전달할 때 까지 이것을 반복한다. (Q: Master는 아직 줄 게 남았는데, Slave는 줄 게 없을 경우? / Slave는 줄 게 남았는데, Master는 줄 게 없을 경우?)
(5) LSA Header : LSDB를 구성하는 LSA들의 헤더 정보이다. 이를 통해 라우터는 자신이 가지고 있는 LSA와 가지고 있지 않은 LSA를 구분한다.

(5) Link State Update 패킷

(6) Link State Acknowledgement 패킷

2.7.2. OSPF Stub Area / OSPF Not-so-stubby Area

OSPF에서는 외부 네트워크 경로의 전파를 차단하여 LSDB의 크기와 라우팅 테이블의 변동을 줄일 수 있는 Stub Area라는 기능을 지원한다.
Stub Area에서는 ABR을 통해 AS 외부로 가는 경로가 모두 디폴트 루트로 광고되며, Stub Area 내부 라우터들의 라우팅 테이블과 SPF 연산량을 줄여준다. 하지만 백본 라우터의 라우팅 테이블 크기를 줄여주지는 못한다는 한계점을 가지고 있다.
Type 4, 5 LSA가 지원되지 않으며, (Optional) 다른 Area의 정보를 담은 Type-3 LSA가 내부로 전달될 수 있다. Cisco 독점 사양으로 Type-3 LSA도 차단하는 Totally Stubby Area가 있다. 이 경우에는 OSPF 도메인 내의 경로라도 디폴트 루트를 통한 라우팅이 이루어지게 된다.
Stub Area와 NSSA의 차이점은 Area 내부에 ASBR이 존재할 수 있는지의 여부인데, Stub Area의 내부에는 ASBR이 존재할 수 없지만, NSSA의 내부에는 ASBR이 존재할 수 있다. (Type 5 LSA Support)
그런데, NSSA는 ASBR Summary LSA (Type 4)를 지원하지 않는다. 즉, 외부 경로를 OSPF 도메인 내부로 전파하지 않는다. 대신, NSSA의 ASBR은 Type-7 LSA를 통하여 외부 네트워크로 가는 디폴트 루트를 AS 내부에 광고하며, 이것이 NSSA 외부로 전파될 때는 ABR에서 Type 5 to Type 7 Translation을 수행하여 경로를 전파하게 된다.

2.7.3. Link-Logical-Signalling Extension

RFC5613에서 제안된 OSPF 확장 프로토콜로, 새로운 기능을 추가할 때 마다 새로운 LSA를 정의하는 것 대신, LSA를 좀 더 유연하게 확장하기 위하여 만들어졌다.
EIGRP와 마찬가지로 TLV 데이터 블록을 사용하여 확장성을 추가하는 것을 골지로 하며, 하위 호환성을 중시한다. 이를 위하여 OSPF Length Field의 값은 LLS Data Block을 포함하지 않으며, LLS Data Block의 길이는 IP Packet Length로부터 도출된다.
LLS Data Block은 OSPF Hello, DD(Database Description) 패킷에 더해질 수 있으며, 다른 패킷에 포함되어서는 안된다. Hello 패킷에 동적으로 LLS Data를 추가할 수 있지만, 전달이 보장되지 않는다. 하지만 DD에 포함된 LLS Data는 Adjacency 과정의 일부로 간주됨으로써, 전달이 보장된다.

LLS 데이터 블록의 구조는 다음과 같다.

이 때, TLV 값은 다음과 같은 값들이 올 수 있다.

(1) Extended Options and Flags

(2) Ctyptographic Authentication TLV (OSPFv2 Only)

(3) Private TLVs
LLS 타입 값 중 32768-65536는 사설 사용을 위해 예약되었다. 1-32767까지는 IANA에서 관리하지만, 나머지 LLS 타입 값은 임의의 추가적인 확장을 위해 사용될 수 있다.
단, Value 필드의 첫 4바이트는 Private Enterprise Code 값으로, 한 네트워크에 다수 벤더의 장비들이 존재할 경우 발생할 수 있는 충돌을 예방한다.

2.7.4. OSPF Opaque LSA Option

RFC5250에서 제안된 LSA 확장 프로토콜이다. LLS와 마찬가지로 미래의 OSPF 확장에 대비하기 위하여 만들어졌으며, LSA를 통해 직간접적으로 데이터를 전파할 경우 사용할 수 있다고 되어 있다.
Link-Local Opaque LSA, Area-Local Opaque LSA, Domain-Wide Opaque LSA로 이루어져 있으며, 각각 네트워크 내부, 에어리어 내부, AS 외부로 정보를 전파하기 위하여 사용된다.

Opaque LSA의 패킷 구조는 다음과 같다.

2.7.5. OSPF DR/BDR 선출 방법

기본적으로 OSPF는 모든 Neighbor들이 서로 LSA를 교환하지 않는다. Point-to-Point와 Point to Multi-Access 네트워크에서는 DR, BDR을 선출하지 않고 Neighbor간 LSA를  교환하지만, Broadcast/NBMA(Non-Broadcast Multi Access)네트워크에서는 DR과 BDR을 선출하여, DR이 Network LSA를 생성, Adjancent Neighbor에게 토폴로지 정보를 전파한다. 이를 통해 불필요한 LSA 트래픽을 줄일 수 있다.

이제, OSPF에서 DR과 BDR을 선출하는 방법을 알아보자.

1. OSPF가 활성화된 인터페이스로 Hello를 내보낸 뒤 상대방의 Hello를 기다린다.
2. Neighbor 관계를 형성하고, DR/BDR이 선출되지 않은 상태인 것을 확인한 뒤 아직 Hello를 보내지 않은 라우터를 OSPF Dead Interval 동안 기다린다.
3. 모든 라우터들이 온라인이라고 판단, Election Process를 시작한다.
4. 먼저, 자신의 Neighbor과 자신을 포함한 목록에서 Priority가 가장 높은 라우터를 BDR로 선출한다. 만약 Priority가 같다면 Router ID가 높은 쪽이 BDR이 된다.
5. BDR이 된 라우터가 네트워크에 Active DR이 없다는 것을 확인, 본인을 DR로 선출하고, 그 다음 순위의 라우터를 BDR로 선출한다.
5-1. 만약 BDR이 될 라우터가 없다면 새로운 라우터의 접속을 기다린다. 새로운 라우터가 접속되면, BDR이 없는 것을 확인하고 본인을 BDR로 선출한다.
6. 한번 DR과 BDR이 선출된 후로는 DR과 BDR은 다운되지 않는 이상 변동하지 않는다. 이것은 토폴로지 변경이 일어날 때마다 DR/BDR 선출이 이루어지는 것을 방지하기 위함이다.

DR이 다운되면 BDR이 DR을 대체하고 BDR Election을 시작한다. BDR이 다운되면 DR을 제외한 라우터들이 BDR Election을 시작한다.

2.7.6. LSDB 생성, Link-State 알고리즘에 따른 최적 경로 선택 방법

OSPF는 다음과 같은 순서로 LSDB(Link-State Database)를 생성하고, 최단 경로 계산을 수행한다.

2.7.6-1. OSPF 상태 천이

OSPF Neighbor 관계 형성부터, LSDB를 생성하기까지 몇 가지 단계를 거친다.

1. Init
라우터가 자신의 이웃으로부터 Hello 패킷을 받았지만, 이 패킷에 자신의 Router ID가 포함되어 있지 않을 경우 천이한다. Neighbor 관계를 수립하기 위하여 Hello 패킷을 보낸 이웃의 Router ID를 포함한 Hello 패킷을 보낸다.

2. 2-Way
서로 Hello를 주고 받아 쌍방향 통신이 수립된 상태를 말한다. 네이버 관계가 수립되고, Adjacency를 수립할 지의 여부를 결정한다. Broadcast/NBMA 네트워크에서는 DR과 BDR만이 Full State로 천이되는 것을 허용하며, 다른 라우터들은 Adjacency를 수립하지 않기에 2-Way에 머몰러 있게 된다. 거꾸로 말하자면 Point to Point Network와 Point to Multipoint Network의 경우에는 Exchange-Loading이 종료된 후 Full State로 천이하게 된다.

3. Exstart
DR과 BDR이 선출되고, Adjacency를 수립한다. DD 패킷을 교환하기 위하여 Master/Slave와 DD Sequence Number를 결정한다.

4. Exchange
DD 패킷을 교환하고, 자신에게 있는 정보가 더 오래되었거나, 자신이 가지고 있지 않은 정보를 Link State Request List에 기록해 둔다. Exchange가 종료되고 Link State Request List에 요청할 정보가 없으면 바로 Full State로 천이한다.

5. Loading
실질적인 링크 정보를 교환한다. Link State Request List를 참조, Request/Update 패킷으로 자신의 LSDB를 업데이트 한다. 모든 Update 패킷은 Acknowledgement 패킷을 통한 응답 확인이 이루어져야 한다.

6. Full
모든 라우터들이 같은 상태 정보를 공유하고 있다. 이 단계에서 일정 시간(OSPF SPF Throttling) 대기한 후 SPF 연산을 수행한다.OSPF Throttling은 뒤에서 자세히 다루도록 하겠다.

이러한 OSPF Status는 Neighbor 관계를 맺은 라우터마다 독립적으로 이루어지는 일이다. 모든 네이버가 Full Status일 필요도 없고, 네이버마다 다른 상태로 천이될 수도 있음을 알아두어야 하겠다.

LSDB의 최신화가 완료되고, OSPF는 목적지까지의 최단 경로 계산을 수행한다. 그리고 이 때 사용되는 알고리즘이 바로 다익스트라(Dijkstra) 알고리즘이다.
다익스트라 알고리즘에 대한 설명은 이 문서의 범위를 벗어나므로, 링크의 문서로 대체하겠다.
LSDB의 라우터-네트워크-인터페이스 정보와 코스트 정보를 이용해서 목적지로의 최적 경로를 계산하게 된다.

(Q: OSPF Update를 통한 네트워크 다운 전파. 구체적으로 어떤 과정을 거치는가? Packet Capture 필요)

SPF 재연산은 토폴로지 변동시마다 이루어지는 것이 원칙이나, 잦은 토폴로지 변동이 발생할 때 매번 재연산을 수행하는 것은 부하가 많이 걸리는 일이다. 그렇기에 Throttling Timer를 두어 토폴로지 변동을 누적한 뒤 재연산을 수행하도록 한다.
이것의 구현은 벤더별로 조금씩 차이가 나는데, Cisco와 Juniper를 기준으로 살펴보도록 하자.

1. OSPF Throttling – Cisco의 경우
Cisco의 SPF Interval은 Exponential하게 증가한다. spf-interval 명령어를 통해 Max Interval, Init Wait, Increase 값을 설정한다.
각각 SPF 재연산 사이의 최대 간격, 첫 번째 트리거와 재연산 사이의 간격, 첫 번째 재연산과 두 번째 재연산 사이의 증가 시간을 의미한다.
그리고 SPF 재연산 사이의 간격은 트리거 될 때마다 2배씩 증가한다. 물론 Max Interval이 경과하는 경우에도 재연산을 수행한다.

2. OSPF Throttling – Juniper의 경우
Juniper는 spf-delay 명령어를 통해 SPF 간격을 설정한다. 단, 첫 3번의 SPF에 한해서 적용된다.
만약 3번의 SPF 재연산 이후에도 다시 토폴로지 변동이 발생하면, Juniper 장비는 5초간 대기한 뒤 SPF 재연산을 수행한다.
이 방법을 통해 대부분의 링크 장애는 빠르게 Convergence 하고, 적은 수의 노드 장애는 LSA들을 한번에 모아서 재연산을 수행할 수 있다.

이러한 OSPF Throttling Interval이 서로 불일치할 경우에는 라우터마다 SPF 재연산을 수행하는 시간이 달라, 라우팅 루프가 발생할 수 있다는 것에 주의해야 한다.

2.7.7. OSPF Passive Interface 동작

2.7.8. ECMP(Equal-Cost Multi Path) 동작

2.7.9. OSPF for IPv6(OSPFv3) 상세

2.7.10. OSPF Virtual Link

라우터/스위치의 구조

인터넷이라는 거대한 통신망을 구성하고 있는 여러 프로토콜의 동작을 이해하려면 가장 먼저 실제로 데이터를 전송하는 장비들인 라우터와 스위치에 대한 이해가 필요하다.

이 글은 내가 네트워크 공부를 하면서 느꼈던 가장 큰 어려움인 ‘왜?’라는 질문에 대한 답이며, 그 때의 나와 같은 어려움을 겪고 있을 누군가를 위해 쓰여졌다.

라우터의 구성요소에 대해 체계적이고 자세한 정보를 올려주신 ‘넷매니아즈 (http://netmanias.com)’ 에 무한한 감사를 보낸다.


목차

  1. Introduction
  2. 라우터의 하드웨어 구성 요소
  3. 통신 시나리오

 

 

1. Introduction

우리는 네트워크로 전송된 패킷이 스위치와 라우터 사이를 계속 건너가면서 상대방 컴퓨터에 도달한다고 배웠다. 그리고 그 과정에서 ARP/MAC/IP 등등의 프로토콜을 통해 목적지를 식별할 수 있다고 배웠다.
그러나, 난 이것을 듣고 가장 먼저 의문이 들었다.

“클라이언트는 서버의 MAC을 어떻게 알 수 있을까?”, “IP 주소만으로 어떻게 목적지를 찾을 수 있을까?”

아직 캡술화(Encapsulation)와 라우팅 프로토콜에 대한 개념이 제대로 잡혀있지 않았기 때문에 생긴 의문이지만, 이것을 제대로 이해하는 것에는 상당한 시간과 노력이 필요했다.
그리고 실제로 이 기능을 구현한 장비의 작동 로직을 파악함으로써 완전한 이해에 도달할 수 있었다.

이 글은 아무것도 모르는 사람을 위해 작성된 것은 아니다. 이 글을 이해하려면 최소한 Lan Switching에 대한 지식은 갖추고 있어야 할 것이다.

그렇지만, 만약 당신이 지식은 갖고 있지만 스위칭과 라우팅의 명확한 개념을 잡지 못 하고 있다면, 이 글이 많은 도움이 될 것이라고 나는 확신한다.

 

2. 라우터의 하드웨어 구성 요소

Supervisor Engine
라우터의 핵심 기능을 가지고 있는 모듈로, Layer3 이상의 제어를 담당하며, Control Plane으로 불리기도 한다.
보통 범용 CPU 위에 여러 가지 기능을 수행하는 OS(IOS/JUNOS)가 올라가며, RIB/LSDB/ARP Table/MAC Table 등의 정보와, 라우팅, Management 등의 기능을 수행하는 프로세스들이 동작하는 모듈이다.

Line Card
패킷 송수신, QoS 등의 기능을 수행하는 모듈로, 실제 믈리 계층과의 연동을 맡는다. 이를 위해 FIB(Forwarding Information Base), MAC Table 등이 존재하며, 패킷을 실제로 처리하는 Packet Processor와 입/출력 패킷을 임시로 저장하는 Ingress Packet Buffer와 Egress Packet Buffer가 존재한다.
Data Plane으로 불리기도 한다.

Switch Fabric Module
Line Card간에 패킷을 전달하기 위한 가교 역할을 한다. Module 형태로 구현된 장비들의 경우, Line Card의 개수가 여러 개일 수 있는데, (Ex. Fa 0/1, Fa 1/1) 이들 사이의 데이터 전송에 이용된다.

3. 통신 시나리오

Host A가 Router B를 통해 Host C로 IP 패킷을 전송하는 사나리오를 이용해 라우터가 어떻게 동작하는지 알아보자.

Router_Structure

1. Host A가 Host C로 데이터를 보내려고 하지만 상대방의 MAC Address를 모르므로 먼저 ARP Request를 보낸다.

2-1. Router B의 Line Card #0에 Host A가 보낸 ARP Request가 도착한다.

2-2. Line Card #0의 Packet Processor는 ARP Request의 L2 헤더를 검사, 자신의 MAC Address Table에 Host A의 MAC이 존재하지 않는 것을 확인하고, Source MAC Learning Event를 발생시킨다. 이는 Control Plane으로 전달되어 CP의 MAC Address Table에 Host A의 MAC이 기록되고, Line Card #0의 MAC Address Table에도 같은 정보가 기록된다.

2-3. 해당 패킷이 ARP임을 Ether-Type Field(0x0806)을 통해 확인한 Packet Processor는 이 패킷을 Supervisor Engine으로 올려보낸다.

2-4. Line Card #0에서 보내온 ARP Request를 받은 Supervisor Engine은 자신의 ARP Entry를 확인한 뒤, ARP Table에 Host A의 MAC/IP Address와 인터페이스(Fa 0/1)를 기록한다.

2-5. 해당 요청이 ARP Request임을 확인한(ARP Operation Field) Supervisor Engine은 Line Card들에게 이 패킷이 들어온 인터페이스를 제외한 모든 인터페이스로 이 패킷을 Flooding 할 것을 지시한다.

2-6. Fa 0/0을 제외한 다른 모든 인터페이스로 ARP Request가 전송되고, Fa 1/0에 연결되어 있는 Host B가 이 패킷을 수신, ARP Reply를 내보낸다.

2-7. Line Card #1은 Host B의 ARP Reply를 수신, 자신의 MAC Address Table에 Host B의 MAC이 존재하지 않는 것을 확인하고 MAC Address Learning Event를 발생시킨다.

2-8. –MAC Learning, ARP 식별 설명 생략- Supervisor Engine은 자신의 FIB(Fowarding Information Base)를 참조, 이 Unicast 패킷이 Fa 0/0으로 전달되어야 함을 확인, Line Card #0에게 이 패킷을 Fa 0/0으로 내보낼 것을 지시한다.

2-9. Host A가 Host C의 ARP Reply를 수신, 자신의 ARP Table에 Host C의 MAC을 기록한다.

3. Host A와 C는 Ethernet Switching을 통해 통신한다.