[ACSA 교육#37] OSPFv2 - 루바루바의 엣지있는 네트워크 이야기

OSPF는 기업이 조직 내에서 트래픽을 라우팅하는데 가장 널리 사용되는 방법입니다.

그 중에서 OSPFv2는 기업 인터네트워크 내에서 IPv4 패킷을 라우팅하는 데 사용됩니다.
오늘은 OSPF 영역, 라우터 ID와 다양한 메시지 유형 및 인접 상태(Neighbor State) 등에 대해 알아보겠습니다.

OSPF 소개

RFC2328에서는 IPv4 주소를 라우팅하기 위한 OSFPv2에 대해 설명하고 있습니다.
OSPF는 TCP나 UDP와 같은 프로토콜을 사용하지 않습니다. 대신에 IP 패킷 내부에 광고 메시지를 직접 배치합니다.
따라서 TCP나 UDP 포트 번호가 없고 IP 프로토콜의 89번 번호를 사용합니다.

IP 프로토콜 번호는 Layer 4에서 사용 중인 프로토콜과 관련된 번호입니다.
이는 Layer 3 헤더의 필드에 포함됩니다. Layer 3에 위치한 이 정보는 네트워크 장치가 패킷을 Decapsulation 하지 않고도 Layer 4 프로토콜을 인식하는 데 도움이 됩니다.
TCP는 프로토콜 번호 6을 사용하고 UDP는 프로토콜 번호 17을 사용합니다.

이것은 계층적 확장성과 보안 메커니즘 때문에 엔터프라이즈 IGP 라우팅 솔루션에서 아주 널리 사용됩니다.
링크 상태 프로토콜(Link-State Protocol)인 OSPF를 지원하는 라우터는 연결된 Layer 3 인터페이스와 네트워크(링크) 및 해당 인터페이스와 관련된 Cost에 대한 정보를 알립니다.

그럼 어떻게 작동하는지 알아볼까요?

OSPF Router ID

모든 OSPF 라우터에는 점으로 구분되는 32비트 IP주소로 표시된 고유한 라우터 식별자(RID)가 필요합니다.
라우터는 보내는 모든 OSPF 패킷에 자신의 ID를 포함하여 보냅니다.

우리가 그림의 토폴로지를 보면서 Server Switch, Core-1, Core-2 스위치를 구분하는 것처럼 라우터는 10.0.100.0, 10.1.100.1, 10.1.100.2라는 것으로 식별하게 됩니다.

관리자는 라우터가 스스로 식별하도록 놔둘 수도 있고, 상황을 직접 제어하여 RID를 수동으로 지정할 수도 있습니다.
자동으로 RID가 할당되도록 하는 것은 관리자가 따로 건들 필요가 없기 때문에 굉장히 매력적으로 보일 수도 있지만, 많은 엔지니어들은 문서 작성이나 트러블슈팅, 관리적인 이유 등 때문에 수동으로 RID를 할당하는 것을 선호합니다.

AOS-CX 스위치는 다음 순서를 통해 라우터의 ID를 결정합니다.

RID를 수동으로 지정하면 라우터 기능을 사용합니다.
RID를 지정하지 않으면, IP 주소가 가장 높은 Loopback 인터페이스가 RID로 됩니다.
Loopback 인터페이스가 없다면, 가장 높은 IP 주소를 가진 일반 non-Loopback 인터페이스가 RID로 됩니다. Down 상태에 있는 인터페이스는 고려되지 않습니다.

Loopback 인터페이스는 항상 작동 중인 상태인 논리적 인터페이스입니다. (관리자가 직접 비활성화 하지 않는 한)
이 인터페이스는 Up 상태인 인터페이스에 의존하는 특정 프로세스나 프로토콜에 유용하게 사용됩니다. Loopback 인터페이스에 연결된 IP 주소는 라우팅 가능하기 때문에 외부의 장치가 해당 IP주소와 통신할 수 있습니다.

네트워크를 운영하다보면, 확장성이나 트러블슈팅, 네트워크 관리 등으로 Loopback 인터페이스를 유용하게 사용하는 것을 알게 될 것입니다.

OSPF의 일반적인 동작 방식

라우터의 역할은 모든 경로에 대해 학습하고 최상의 경로를 선택하여 해당 경로를 따라 패킷을 라우팅 하는 것입니다. 이를 위해서 OSPF는 4단계 접근 방식을 사용합니다. 각 단계는 각 라우터의 로컬 메모리에 구축하고 유지 및 저장되는 일종의 테이블을 생성합니다. 각 단계들과 그와 관련된 테이블을 이해할수록 OSPF 네트워크를 더 잘 설계하고 배포 및 트러블슈팅 할 수 있게 됩니다.

1단계: 이웃 테이블(Neighbor Table) 구축 – 각 OSPF 라우터는 OSPF 이웃과의 관계를 설정합니다.
이 정보는 Neighbor Table에서 사용할 수 있습니다.
2단계: 토폴로지(Topology) 데이터베이스(또는 LSDB(Link State Database)) 구축 – OSPF 지원하는 라우터는 네트워크 접두사(Prefix)와 매개변수(Parameter)를 교환합니다. 이 정보는 LSDB 테이블에 저장됩니다.
3단계: OSPF 라우팅 테이블 작성 – OSPF를 지원하는 라우터는 SPF 알고리즘을 실행하여 특정 대상에 대한 최상의 경로를 얻습니다. 결과는 OSPF 라우팅 테이블에 저장합니다.
4단계: 전달 테이블 또는 FIB(Forwarding Information Base, 전달 정보 기반)이라 하는 라우팅 테이블 구축 – 이 단계에서 OSPF 내부 프로세스는 결과를 라우팅 테이블에 저장합니다.

그럼 이제 각 단계별로 상세하게 알아볼까요?

1단계 – 이웃 테이블(Neighbor Table) 구축

우선, 직접 연결된 OSPF 이웃(Neighbor)에게 자신을 소개합니다. 이건 서로 호환되는 확인하기 위함입니다. 방법은 OSPF “Hello” 패킷을 각 OSPF 인터페이스로 보내게 됩니다.

예를 들어, 위 그림과 같이 Core-1 스위치는 서브넷 10.11.0.0/30의 LAG10을 포함한 OSPF가 활성화된 모든 인터페이스에 Hello 패킷을 보내게 됩니다.

"안녕하세요, 난 Core-1 스위치입니다. 우리는 지금 11구역(Area 11)에 같이 살고 있고, 보안 인증을 사용할 필요가 없다고 생각됩니다. 우리는 10.11.0.0/30 서브넷에 연결되어 있습니다."

Core-2 스위치는 LAG10으로 비슷한 정보를 담아 Hello 패킷을 보내게 됩니다.

기준(Criteria)이 일치하게 되면 OSPF 라우터는 서로를 이웃(Neighbor)으로 인정하게 되고 OSPF Neighbor 관계를 형성합니다.
하지만, 이러한 매개변수 중 하나라도 일치하지 않으면(일반적으로 구성이 잘못된 경우) 라우터는 Neighbor 관계 형성을 거부하고 네트워크에 문제가 발생하게 됩니다.

위 그림처럼 각 라우터가 직접 연결되어 있는 피어 라우터와 Neighbor 관계를 성공적으로 형성하게 되면 각 라우터는 Neighbor Table에 이 정보를 반영하게 됩니다.

※ 참고: 여기서는 Neighbor 관계 형성에 대한 정보 전달을 위해 Hello 패킷의 일부 내용만 표시하고 설명합니다.
실제 Hello 패킷은 훨씬 더 많은 정보가 교환됩니다.

2단계 – 토폴로지 데이터베이스 구축

라우터는 인접성(adjacency)이 완전하게 형성된 경우에만 다른 라우터와 알려진 서브넷을 공유합니다.

“인접성(adjacency)”라는 용어는 각각에 물리적으로 서로 연결된 두 개의 라우터를 나타냅니다.
물리적으로 연결되지 않는 라우터 사이에서도 OSPF Neighbor 관계가 설정될 수 있기 때문에 OSPF Neighboring 과는 다릅니다.

서브넷을 공유하는 것은 결국 토폴로지 데이터베이스를 구축하기 위함입니다. 즉, 모든 단일 링크(서브넷)과 모든 단일 라우터, 그리고 해당 라우터와 서브넷이 어떻게 연결되어 있는지에 대한 목록을 만들게 됩니다.
구축하는 방법은 멀티캐스트 LSA(Link State Advertisement)를 보내는 것입니다.

위 그림에서 Server Switch는 모든 인터페이스로 LSA 메시지를 보냅니다.

"모든 라우터들 주목해주세요. 저는 Server Switch입니다. 10.20.0.0/22, 10.1.1.0/24, 10.1.2.0/24 네트워크에 직접 연결되어 있습니다."

다른 모든 OSPF 라우터는 이러한 LSA를 수신하고 해당 정보를 토폴로지 데이터베이스에 추가합니다.
곧 모든 라우터는 다른 라우터들로부터 LSA를 수신합니다. 즉, 각 라우터에는 전체 토폴로지 데이터베이스가 존재하게 됩니다. 다시 말해, 위 그림과 같은 다이어그램을 숫자로 표시하는 데이터베이스인 것입니다.
따라서, 모든 OSPF 라우터에는 동일한 토폴로지 데이터베이스가 있습니다.

위 예제의 그림은 Server Switch가 현재 알고 있는 네트워크의 전부이기 때문에 직접 연결되어 있는 Server Subnet 정보만 광고하게 됩니다. 그러나 Server Switch가 다른 라우터로부터 LSA를 수신하면 그 경로도 함께 알려주게 됩니다.
라우터는 다른 모든 라우터에게 토폴리지 데이터베이터의 전부를 광고합니다.
그래서 토폴로지 데이터베이스를 Link-State 데이터베이스(LSDB)라고도 합니다.

3단계 – OSPF 라우팅 테이블 구축

아래 그림에서 토폴로지는 하나만 있지만 해당 토폴로지 내에서 각 라우터의 위치와 연결은 유일합니다.
따라서 각 라우터의 목표는 토폴로지 내에서 각 링크에 대한 최상(Best)의 경로를 결정하는 것입니다.

이 경로를 결정하는 방법은 토폴로지 데이터베이스, 즉 LSDB(Link-State Database)에서 SPF(Dijkstra) 알고리즘을 실행하는 것입니다.

예를 들어, Core-1 스위치의 SPF 알고리즘은 토폴로지 데이터베이스를 분석해서 목적지 10.20.0.0/22로 가는 방법이 ① LAG10에서 패킷을 라우팅하여 Core-2를 통해 가거나, ② 포트 47번으로 나가서 Server Switch를 통해 갈 수 있다는 것을 확인합니다.

알고리즘은 각 경로와 관련된 Cost(대역폭 기준)를 고려하여 Cost가 가장 낮은(가장 빠른) 경로를 선택하게 됩니다. 그리고 이 최적의 경로는 라우팅 테이블에 추가됩니다.

4단계 – 라우팅 테이블에 최상 경로 게시

OSPF에 의해 계산된 최상의 경로는 라우팅 테이블(FIB, Forwarding Information Base) 상에 게시됩니다.

위 그림에서 Core-1이 목적지(Server Subnet)로 가는 최상의 경로는 Server Switch를 통해서 가는 것입니다.

이렇게 OSPF의 기본 동작 방식을 단계별로 한 번 살펴보았습니다.

그럼 그 중에 Neighboring 에 대해 좀 더 알아보겠습니다.

OSPF – Neighboring

Hello 메시지

직접 연결된 OSPF 라우터는 양방향 통신을 보장하고 장애 감지 메커니즘을 자동하기 위해서 Hello 패킷을 보냅니다. 기본적으로 이러한 패킷은 10초마다 멀티캐스트 IP주소 224.0.0.5로 전송합니다. 이 주소는 “모든 OSFP 라우터들 주목하세요!” 목적으로 예약된 멀티캐스트 주소입니다. 매핑된 MAC주소는 01:00:5E:00:00:05입니다.

모든 Layer 2 스위치는 브로드캐스트 패킷을 플러딩(Flooding)하고, 브로드캐스트 도메인의 모든 포트에서 멀티캐스트 프레임을 내보내기 때문에 직접 연결된 모든 라우터는 OSPF 교환 프로세스에서 전송되는 첫 번째 패킷인 Hello를 교환합니다.

Hello 패킷의 또 다른 주 목적은 Neighbor 테이블을 만들고 유지하는 것입니다.
호환 가능하게 구성되어 있는 피어만 Neighbor 관계를 형성합니다.
동일한 서브넷에 있고 동일한 서브넷 마스크가 있다는 데 동의해야 합니다. 그리고 같은 지역에 있어야 하고 지역 유형에도 동의해야 합니다. 뿐만 아니라 타이머(OSPF Hello 타이머: 10초)도 일치해야 하고 동일한 인증 유형을 사용하도록 구성해야 합니다.

Hello 간격을 확인하기 위해서는 “show ip ospf neighbor detail” 명령어를 사용하여 확인 가능합니다.

Core-2# show ip ospf neighbor detail
Neighbor 10.11.100.1, interface address 10.11.0.1
-------------------------------------------------
Process ID 11 VRF TABLE-11, in area 0.0.0.11 via interface vlan110
Neighbor priority is 1, State is FULL
DR is 10.11.0.1, BDR is 10.11.0.2
Options is 0x42
Dead timer due in 00:00:30
Retransmission queue length 0
Time since last state change 00h:02m:39s

AOS-CX 스위치에서 Hello 간격은 10초이지만, 간격을 1초에서 65553까지 변경할 수 있습니다.

Switch(config)# interface <interface-id>
Swtich(config-if)# ip ospf hello-interval <seconds>

Dead 간격은 Neighbor가 Dead 상태로 선언된 후의 시간 간격입니다. 일반적으로 Hello 간격의 4배입니다. 이 값 역시도 Neighboring 관계 형성을 위해서 일치해야 합니다.

OSPF Neighbor 상태

OSPF는 FSM(Finite State Machine)을 사용하여 특정 조건이 충족될 때 라우터 간의 Neighbor 상태 전환을 처리합니다. 이 프로세스는 두 가지 주요 단계로 나눠볼 수 있습니다.

Neighbor간 인접성(Adjacency) 설정
OSPF 데이터베이스 동기화

브로드캐스트 네트워크에서 데이터베이스 동기화는 지정 라우터(Designated Router, DR)과 DROTHER(DR과 BDR이 아닌 라우터) 라우터 사이, 그리고 백업 지정 라우터 (Backup Designated Router, BDR)과 DROTHER 라우터 사이에서만 발생합니다.
즉, DROTHER 라우터간에는 Neighbor Adjacency를 설정하고, 2-WAY 상태(안정된 상태를 의미)를 유지하지만 데이터베이스를 동기화하지는 않습니다.

아래 그림의 예제를 통해, 두 개의 코어 스위치가 브로드캐스트 네트워크를 통해 OSPF Neighbor가 되려고 시도한다고 가정해보겠습니다.

Neighbor Adjacency 설정

Core-1과 Core-2는 Neighbor 상태가 Down으로 시작합니다.
Core-1은 첫 번째 hello 메시지를 보낼 때 INIT 상태로 전환합니다. 이 메시지는 라우터 ID = 10.1.100.1이 포함됩니다. Hello 메시지에는 Seen 필드를 포함합니다. Seen 필드는 Core-1 스위치가 Hello 메시지를 수신하기 위한 필드입니다. 이 메시지는 첫 번째 Hello 메시지이기 때문에 필드에 NULL 값으로 들어가 있습니다.
Core-2는 Core-1의 Hello 메시지를 수신하고, 응답 메시지에 메시지를 보았고 호환 가능하다는 것을 담아 메시지를 전달합니다. 그리고 Core-2 스위치 역시 INIT 상태로 전환합니다.
Core-1 스위치는 다시 Hello 메시지를 수신하고 2-WAY 상태로 전환합니다. 다시 Core-2 스위치로 Hello 메시지를 보내지만 이번에는 Router ID와 Seen 필드를 포함하여 보냅니다.
Core-2 스위치는 이 메시지를 수신하고 2-WAY 상태로 전환합니다.

여기서 이 네트워크에는 Core-1 스위치와 Core-2 스위치, 두 개의 장치만 있습니다. 그래서 데이터베이스 동기화 프로세스를 진행합니다.

OSPF 데이터베이스 동기화

6. Core-1 스위치는 Database Description 패킷을 보내서 동기화 프로세스를 시작합니다. 스위치는 EXSTART neighbor 상태로 전환합니다.
7. Core-2 스위치는 유사한 프로세스를 수행합니다. Database Description 패킷을 보내서 EXSTART 상태로 전환합니다. EXSTART 상태의 목적은 가장 높은 Router ID를 기반으로 링크의 MASTER가 될 스위치를 결정하는 것입니다. MASTER의 역할은 데이터베이스 교환 프로세스를 시작할 스위치를 정하는 것입니다. 이 역할은 DR/BDR과 아무 관련이 없고 LSDB(Link-State Database) 교환 전용입니다.
8. Core-2 스위치는 EXCHANGE 상태로 전환할 때 또 다른 Database Description 패킷을 보냅니다. Core-2 스위치는 이제 LSDB의 내용 Summary를 Core-1 스위치와 공유합니다.
9. Core-1 스위치도 Database Description 패킷을 보내고 Core-2 스위치와 LSDB를 공유하면서 EXCHANGE 상태로 전환합니다.

EXCHANGE 상태에서 여러 패킷을 보내고 받은 후에 각 라우터는 다른 전체 LSDB의 Summary를 갖게 됩니다. 각자는 서로 받은 정보를 비교하고 다음 단계에서 누락된 정보를 요청하게 됩니다.

10. Core-1 스위치와 Core-2 스위치는 LSU(Link State Update) 패킷을 사용하여 누락된 정보를 요청합니다. 요청을 받은 피어는 요청된 데이터베이스 정보를 전송하여 응답합니다. 두 스위치 모두 LOADING 상태로 전환합니다.

이 LOADING 상태는 실제 라우팅 정보를 교환합니다.

11. Core-1 스위치와 Core-2 스위치 모두 더 이상 교환할 정보가 없을 때 FULL 상태로 전환하게 됩니다. 이 때 두 장치 모두 동일한 LSDB(Link-State Database)를 갖게 됩니다.

“show ip ospf neighbors” 명령어를 사용하여 OSPF의 Neighbor 상태를 확인할 수 있습니다.

Core-1# show ip ospf neighbors

Neighbor ID      Priority  State               Nbr Address          Interface
--------------------------------------------------------------------------------
10.1.100.2       1         FULL/DR             10.11.0.2            LAG10

이렇게 오늘은 가장 많이 사용하는 OSPF 라우팅 프로토콜에 대해 이론적으로 간단하게나마 알아보았습니다.
다음 포스팅에는 OSPF 운영과 동작 방식에 대해서 좀 더 자세하게 다뤄보도록 하겠습니다.