태그: Cisco

Network Study – 3주차 : Layer2 보충(VLAN, STP)

Layer2, 이더넷 스위칭을 다루면서 L2에서 사용하는 VLAN과 STP를 다루지 않았기에 다시금 보충하게 되었다.

VLAN에는 802.1Q, Cisco ISL(Inter-Switch Link), 802.1aq SPB(Shortest Path Bridging)이 있고, STP는 802.1D STP(Spanning Tree Protocol), 802.1w RSTP(Rapid Spaning Protocol), 802.1s MSTP(Multiple Spanning Tree Protocol) 그리고 SPB를 다룬다.

1. VLAN 개요

VLAN이란, L2단에서 하나의 물리적인 LAN을 여러 개의 가상의 LAN으로 나누는 기술을 말한다. 물리 망은 공유하지만, 부서에 따라 다른 네트워크 정책을 적용해야 할 경우나, 단순히 트래픽을 서로 격리할 필요가 있을 경우 사용된다. VLAN을 적용하면 일반적으로 보안이 강화된다.
VLAN의 동작은 VLAN Tagging을 통하여 이루어진다. VLAN이 설정된 포트로 프레임이 들어오면, 해당 프레임에 VLAN Tag를 붙인다. 그리고 목적지 포트가 같은 VLAN에 속하지 않으면 그 프레임을 폐기한다. 정상적으로 전달되는 경우 출력 포트를 나갈 때 VLAN Tag를 제거하여 호스트들이 패킷을 수신하게 한다. 이렇듯 VLAN은 종단간 통신에 있어 투명한 기술이다.
그리고 Trunk Port와 같이 다중 VLAN이 적용된 포트의 경우는 Tag를 붙인 채로 프레임을 보낸다. 덧붙여, Default 또는 Native VLAN이라 불리는 VLAN 1(설정으로 변경 가능)에 속한 프레임은 VLAN Tagging을 하지 않으며, Trunk Port로부터 태깅이 되지 않은 프레임이 넘어오면 Native VLAN으로 취급된다.

이러한 Port-Based VLAN이 전형적인 VLAN 적용 방식이며, 다른 방식으로는 Protocol-Based VLAN(802.1v)이 있다.

1-1. IEEE 802.1Q 상세 동작

IEEE 표준인 802.1Q의 동작에 대해 알아본다. 802.1Q는 표준 프로토콜이기에 가장 많이 사용되는 VLAN 프로토콜이라 할 수 있다.
단, 이더넷에서만 이용할 수 있다는 제약을 가진다. 몇몇 벤더는 비표준 기술로써 ATM 등에 대한 802.1Q을 지원한다.

802.1Q는 다음과 같이 프레임에 VLAN 태그를 삽입한다. Source MAC Address 뒤에 802.1Q 헤더가 오며, 첫 두 바이트 값은 0x8100이다. 이는 Ether-Type 필드와 겹쳐서, 802.1Q 프레임과 일반 프레임을 구분할 수 있도록 한다. 그리고 다음 3비트가 Priority 필드, 다음 1비트는DEI(Drop Eligible Indicator)로 혼잡 상황 발생시 이 프레임이 폐기될 수 있는지의 여부를 결정한다. 이전에는 이 값이 Ethernet-Token Ring 연동을 위한 CFI 값이었다.
그 뒤의 12비트가 VLAN ID 값으로 2^12 = 4096개의 VLAN ID 중에서 예약된 0과 4096을 제외한 1~4095, 최대 4094개의 VLAN ID를 사용할 수 있다.
특히, VLAN ID 0은 VLAN이 설정되지 않은 프레임을 의미하는데, 이  경우에는 Priority 옵션만을 사용하게 된다.

802.1Q는 지금도 계속 갱신되고 있으며, 최신 버젼의 802.1Q 지원은 벤더와 소프트웨어 버젼마다 다르다. 많은 Draft 중에서 802.1Q-2014 Draft Standard는 802.1aq와 병합되었다.

1-2. Cisco ISL 상세 동작

802.1Q와는 달리, ISL은 프레임을 캡슐화(Encapsulation) 한다. 때문에 프레임의 앞에 ISL Header가 추가되며, 끝에 FCS가 추가된다.

ISL 프레임의 구조는 다음과 같다.

(1) Destination Address (40Bit) : 특이하게도 48비트가 아닌 40Bit의 MAC을 사용한다. 이 주소는 멀티캐스트 주소로써, “01-00-0C-00-00” 또는 “03-00-0c-00-00″이다. 이 주소값은 패킷이 ISL 포맷임을 알린다.
(Q: 어째서 일반적인 L2 Address Type이 아닌가? Multicast Address가 맞긴 한가?)
(2) Type : ISL 프레임이 담고 있는 프레임의 포맷을 알린다. 0 : Ethernet, 1 : Token Ring, 2: FDDI, 3: ATM
(3) User : Type 필드의 확장으로, Priority를 나타낸다. 기본값은 0, 최대값은 3이다.
(4) Source Address : Source MAC Address이다.
(5) Length : ISL 프레임에서 DA, Type, User, SA, Len, FCS를 제외한 길이를 바이트 단위로 나타낸다. 따라서 총 길이 –  20Byte가 Length 값이 된다.
(6) SNAP (24Bit) : SNAP 값이다. 0xAAAA03을 가진다.
(7) High Bits of Source Address : OUI 값을 나타낸다. Cisco가 소유하고 있는 OUI 중 “00-00-0C”를 사용한다.
(8) Destination VLAN ID : VLAN ID값을 나타낸다. 최대 4096개의 VLAN을 지원한다. 이 중 0과 4096은 예약되어 있기에 사용 가능한 VLAN은 1-4095이다.
(9) BPDU and CDP Indicator : BPDU나 CDP 패킷을 캡슐화하였을 경우 세트된다.
(10) Index : 스위치의 Egress Port 번호를 나타낸다. 진단용으로만 사용되며, 수신한 측에서는 이 값을 무시한다.
(11) Reserved : Token-Ring, FDDI 프레임을 위해 예약된 값이다.
(12) Encapsulated Frame : 캡슐화된 원본 L2 프레임이다.
(13) FCS : 전체 ISL 프레임의 32Bit CRC 값이다.

ISL이 개발된 이후 802.1Q가 개발되었고, 현재는 ISL을 거의 사용하지 않는다. Ethernet에 맞춰 개발된 802.1q와 달리 더 다양한 네트워크를 지원한다는 장점이 있다.

 

2. STP 개요

STP(Spanning Tree Protocol)은 스위치 패킷의 루프를 방지하기 위하여 고안된 프로토콜이다. 토폴로지 구성에 있어, 스위치간 중복 링크가 활성화된 경우 브로드캐스트 패킷이 복사되어서 링크를 떠돌게 되는 브로드캐스트 스톰(Broadcast Storm)이 발생할 수 있다. 이러한 상태를 ‘루프가 발생했다’고 하며, 브로드캐스트 프레임, 혹은 다른 프레임이 스위치 링크를 무한히 떠돌아다니는 상황을 방지하고, 링크가 다운되었을 경우의 리던던시(Redundancy)를 제공하기 위해 STP가 사용된다.
한 가지 흥미로운 점은 Ethernet Frame에는 이러한 상황을 방지하기 위한 TTL 필드가 존재하지 않는다는 것인데, Ethernet을 만들 당시에는 이러한 문제를 미처 생각하지 못했던 것이 아닐까?
STP가 동작하는 방식은 매우 간단하다. Root Bridge를 선정하고, Root Bridge로 갈 수 있는 최단 경로의 포트를 선정한 뒤 다른 링크는 전부 블록시켜 버린다. 이를 통하여 모든 브리지(스위치)간의 통신이 가능해지며, 링크가 단절되었을 경우 자동으로 재연산을 수행하여 대체 경로를 찾는다.

STP의 문제점은 수렴 시간(Convergence Time)이 길어 링크 절체 시간이 길다는 것과, 대체 경로를 사용한 로드 밸런싱이 불가능하다는 것이 있다. 전자는 RSTP의 등장으로 어느 정도 해소되었지만, STP 알고리즘의 특성 상 대체 경로를 형성하는 것이 불가능하기에 현대 데이터센터에서 STP를 사용하는 것은 상당히 낭비가 큰 일이다. STP/RSTP를 대체하기 위한 프로토콜로는 SPB, TRILL 등이 있다. 물론 SDN을 통한 경로 관리도 대안이 될 수 있으리라.

2-1. STP 상세 동작

RSTP를 다루기에 앞서, STP의 동작을 먼저 다루도록 하겠다. STP에서 사용되는 용어들은 다음과 같다.

– Root Bridge : STP의 중심이 되는 브리지. 주로 Bridge ID값이 높은 장비가 선출된다.
– Root Port : Root Bridge로 가는 최단 경로에 위치한 포트
– Designated Port : Designated Bridge에 속한 포트 중 해당 LAN Segment의 Minimum Path Cost를 갖는 포트.
– Designated Bridge : LAN Segment에 연결되어 있는 브리지 중 Root 브리지로 가는 Path Cost 값이 가장 작은 경로를 가진 Bridge. 각 LAN 세그먼트마다 하나씩 선출된다. 이 때 주의해야 할 점은, 여기서의 LAN 세그먼트는 물리적인 세그먼트라는 것이다.
– BPDU(Bridge Protocol Data Unit) : STP에서 토폴로지 정보를 교환하기 위한 프레임을 말한다. 여러 종류의 BPDU들이 존재한다.

STP는 다음과 같은 순서로 동작한다.

1. 루트 브리지(Root Bridge) 선출
2. 루트 포트(Root Port) 선출
3. Designated Bridge 선출 (각 LAN Segment마다)
4. Designated Port 결정
5. Port State 천이 (Blocking – Listening – Leaning – Forwarding)

이제 이 과정을 좀 더 자세히 다뤄 보자. 하지만 상세 동작을 다루기 위해서는 BPDU에 대한 이해가 필요하기에 BPDU의 구조를 먼저 다루도록 하겠다.

BPDU 프레임의 구조는 다음과 같다.

(1) Configuration BPDU

(1) Protocol ID : 0x0000(STP)
(2) Protocol Version : 0x00 (IEEE 802.1D)
(3) BPDU Type : 0x00, Configuration BPDU
(4) Flags : 첫번째 비트가 TC, 마지막 비트가 TC Ack 플래그이다.
(5) Root Identifier (64Bit) : BPDU를 만든 브리지가 Root Bridge로 여기는 브리지의 ID.
(6) Root Path Cost (32Bit) : BPDU를 만든 브리지로부터 루트 브리지까지의 총 Path Cost값.
(7) Bridge Identifer (64Bit) : BPDU를 만든 브리지의 Bridge ID
(8) Port Identifier : BDPU를 전송한 포트의 Port ID
(9) Message Age (16Bit) : 루트 브리지에서 BPDU를 전송할 때 0으로 세트된다. 그리고 브리지를 타고 내려갈 때마다 1씩 증가하며, 각 브리지는 (자신의 Max Age – Messeage Age)만큼 BPDU를 보관한다. Timer가 Max Age를 넘어서면 BPDU는 만료된다.
(Q: 만약 Timer가 짧고, 많은 브리지를 거쳐야 한다면 BPDU가 도달 불가능한 브리지도 생길 것인가?)
(10) Max Age : Root Bridge의 Max Age 값.
(11) Hello Time (16Bit) : Root Bridge가 Hello를 보내는 주기.
(12) Forwarding Delay : Root Bridge에 설정된 Bridge Forwarding Delay 값.

여기서 주의할 점은 STP 타이머 값들은 모두 루트 브리지의 설정을 사용한다는 것이다. 루트 브리지의 타이머 설정은 Configuration BPDU를 통해 전체 브리지들로 전파된다.

(2) TCN(Topology Change Notification) BPDU

 

이제 BPDU에 대해 알아보았으니, BPDU의 정보를 기반으로 STP가 트리를 구성하는 과정을 살펴보자.

2-1.1. Root Bridge 선출
스위치의 초기화가 완료되면, 스위치는 자신이 Root Bridge라고 생각한다. 때문에 모든 포트를 Designated Port로 간주, Configuration BPDU를 내보낸다.
스위치들은 Configuration BPDU 내의 Root Identifier와 자신이 알고 있는 Root Identifier를 비교, 더 값이 높은 쪽을 루트 브리지로 선정한다.

2-1.2. Root Port 선출
루트 브리지의 선출이 완료된 뒤, 각 브리지들은 루트 브리지의 BPDU를 수신한 포트들 중에서 Root Path Cost가 가장 작은 포트를 Root Port로 지정한다.
만약 코스트가 같은 포트가 둘 이상이면 Designated Bridge ID가 작은 포트를, 그것도 같으면 Designated Port ID를, 마지막으로 자신의 Port ID를 비교해서 낮은 쪽을 Root Port로 지정한다.

2.1.3. Designated Bridge 선출
LAN Segment에서 Root Path Cost값이 가장 작은 브릿지가 Designated Bridge가 된다. 이 때 같은 LAN Segment에 존재하는 브리지들을 파악하기 위하여 BPDU의 Bridge ID와 Port ID를 사용한다.
스위치 환경에서는 스위치 하나에 연결된 장비들이 하나의 LAN Segment가 되므로, 하나의 LAN Segment에 여러 스위치들이 존재할 수 없다. 때문에 Root에 더 가까운 스위치가 Designated Bridge가 될 것이다.

2.1.4. Designated Port 선정
LAN Segment에서 Designated Bridge와 연결된 포트가 Designated Port가 된다.

2.1.5. Forwarding State로 천이
Designated Port와 Root Port가 Forwarding 상태로 천이되며, 프레임과 BPDU를 전송한다.

2.1.6. STP Port Status

앞서 STP가 루프를 방지하기 위해서 일부 포트를 활성화하고, 일부 포트는 차단(Blocking)한다고 설명하였다. STP의 포트 상태에 대해 좀 더 자세히 알아보자.

(1) Disabled : 관리자에 의하여 사용이 중단되었거나, 물리적으로 링크가 Down된 상태
(2) Blocking : STP 연산 결과 Designated, Root 포트가 아니어서 프레임 전달 기능이 비활성화된 상태
(3) Forwarding : 프레임 전달 및 MAC Address Learning을 수행하는 상태.
(4) Listening : Blocking에서 Forwarding으로 천이하는 과정에서 생길 수 있는 루프를 방지하기 위해, 프레임 전달 및 MAC Learning을 수행하지 않고 대기하는 상태. Forwarding Delay 값의 영향을 받는다.
(5) Learning : Listening에서 천이되는 상태로, 프레임 전달은 수행하지 않고 MAC Address Learning만 수행하는 단계. 마찬가지로 Forwarding Delay 값의 영향을 받음.

여기서 주의해야 할 부분은 Blocking된 포트라 하더라도 BPDU 송신을 하지 않을 뿐, BPDU 수신은 이루어진다는 것이다.
그리고 Listening – Learning – Forwarding으로 천이되는 동안 Forwarding Delay동안 대기(기본값 20초)하여, 토폴로지 변동 시 절체 시간이 약 50초에 이른다는 것을 확인할 수 있다.

이상으로 STP의 상세 동작을 알아보았다.
추후 STP에서 문제가 되는 부분인 긴 절체시간을 해결하기 위하여 802.1w RSTP(Rapid Spanning Tree Protocol)가 제안된다.

2-2 RSTP 상세 동작

2-3. MSTP 상세 동작

2-4. 결론

 

3. SPB 상세 동작

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