태그: IP

Network Study – 6주차 : VPN(Virtual Private Network) 프로토콜

VPN(Virtual Private Network, 가상 사설망)은 본래 전용 회선(Leased-Line)을 사용하던 기업체들이 인터넷의 확산과 더불어 비용 절감을 꾀하기 위해 만들어낸 기술이다.
전용 회선을 임대하거나, 속도가 보장된 가상 회선을 임대하는 경우(MPLS)와 달리 VPN은 인터넷 망을 그대로 이용한다는 차이점이 있다. 이를 통해서 일반적인 인터넷 회선 사용료를 지불하는 것으로 본-지사간의 네트워크를 구성할 수 있었으나, 전용 회선 혹은 MPLS에서 보장하던 QoS등의 서비스를 제공받을 수 없게 되었다.

또한, 물리적 혹은 논리적으로 하나의 회선을 독점하였던 기존의 서비스와는 달리 인터넷 망을 사용하기에 외부로부터의 접근에 취약해진다는 문제가 있었다. 이를 해결하기 위해 모든 VPN 프로토콜들은 사용자를 인증하고 전송하는 모든 패킷을 암호화한다.
물론 사용하는 암호화 알고리즘과, VPN 터널 생성 방법은 프로토콜마다 다르다.

그리고 개발 목적이 본-지사간의 네트워크를 연결하는 것이었기에, 물리적으로 연결되어 직접 있지 않은 네트워크와 직접 통신할 수 있다는 특징을 가진다.

 

1. VPN 프로토콜의 종류

흔히 사용되는 VPN 프로토콜들은 다음과 같다.

– Internet Protocol Security(IPSec)
– Transport Layer Security(SSL/TLS)
– Datagram Transport Layer Security(DTLS)
– Point to Point Tunneling Protocol(PPTP)
– Secure Socket Tunneling Protocol(SSTP)
– Secure Socket Shell VPN(SSH-VPN)

이제 각 프로토콜의 알고리즘을 살펴 보자.

1-1. IPSec

IPSec은 AH(Authentication Header), ESP(Encapsulating Security Payload), IKE(Internet Key Exchange)로 구성되어 있다. AH는 인증 과정을, ESP는 페이로드의 암호화와 흐름 제어를 제공한다. 그리고 IKE는 키 매니지먼트를 제공한다.
IPSec은 고품질의 통합된 암호화 기반의 보안을 IPv4와 v6에 제공하기 위해 디자인되었고, 접근 제어, 비연결형 무결성(Connectionless Integrity), 데이터 출처 인증(Data Origin Authentication)과 재전송 공격의 차단, 암호화에 의한 기밀성, 제한적인 흐름 제어 무결성(Limited Flow Control Integrity)를 제공한다. 이러한 서비스들은 IP레이어에서 제공되며, IP 자신을 포함한 상위 프로토콜들에게 보호를 제공한다.

IPSec은 또한 최소한의 방화벽 기능을 포함한다. 이것은 IP 레이어에서의 접근 제어 측면에서 필수불가결한데, 만약 좀 더 정교한 방화벽 메커니즘을 제공할 수 있다면 그것을 사용하면 될 것이다(다만, IPSec 구현체에 의해 방화벽의 흐름 제어 기능이 강제되고, 트래픽 선택자(Traffic Selector)기능이 IKEv2에 의해 협상되지 않는다면 상호 운용성 측면에서 문제가 생길 것이다.)
IPSec 방화벽 기능은 강제 암호화된 인증과 무결성을 모든 IPSec 트래픽에게 제공할 수 있으며, 이것은 방화벽에 암호화에 의한 보호를 더하는 것 보다 나을 것이다.

IPSec이 성공적으로 적용되고 배포된 뒤, IPSec의 보호를 적용받지 않는 유저와 호스트, 그리고 다른 네트워크 구성요소들에게 영향을 미쳐서는 안 된다. AH와 ESP, 그리고 필요하다면 IKE는 독립적인 암호화 알고리즘으로 개발되었으며, 이것은 다른 구현 부분에 영향을 미치지 않고 적절한 암호화 알고리즘을 선택할 수 있도록 한다. 광역 인터넷에서의 상호 운용성을 만족하기 위하여, AH와 ESP에 쓰이는 기본 암호화 알고리즘이 RFC 4305에 정의되었다. 그리고 IKEv2를 위해 반드시 구현되어야 하는 암호화 알고리즘이 RFC 4307에 정의되었다. 이 알고리즘들은 암호화 기술의 발전에 따라 주기적으로 업데이트 될 수 있으며, 이러한 표준 암호화 알고리즘들을 분리함으로써 각 프로토콜들은 서로에게 영향을 미치지 않고 알고리즘을 갱신할 수 있다.

 

IPSec 보안 서비스는 IP레이어에서 Security Protocol, 암호화 알고리즘과 암호화 키를 선택할 수 있게 한다. IPSec은 (1) 호스트와 호스트 간의 경로를 보호하거나, (2) 보안 게이트웨이 사이의 연결을 보호하거나, (3) 보안 게이트웨이와 호스트 사이의 연결을 보호할 수 있다. 호스트 구현체들은 반드시 (1)(3)을 구현해야 하며, 보안 게이트웨이의 구현체는 3가지의 연결을 모두 구현해야 한다.
앞서 말했듯이 IPSec은 보안 기능을 제공하기 위해 AH, ESP 프로토콜을 사용하는데, 각각의 역할은 다음과 같다.

– AH(Authentication Header) : 무결성과 데이터 출처 인증을 제공한다. 옵션으로 재전송 공격을 차단하는 기능을 제공한다(수신자 단에서 구현한다)
– ESP(Encapsulating Security Payload) : AH의 기능과 더불어 기밀성을 제공한다. 무결성 없이 기밀성을 사용하는 것은 권장되지 않는다. 그리고 ESP의 기밀성이 활성화되면 제한된 트래픽 흐름 기밀성을 제공한다. 예를 들어 패킷 길이를 감추고, 효율적으로 더미 패킷을 생성하고 파기할 수 있다.

AH와 ESP 모두 접근 제어를 제공한다. 이것은 SPD(Security Policy Database)에 서술되어 있는 암호화 키의 분배와 프래픽 흐름 관리에 의해 강제된다.
두 프로토콜들은 모두 개별/통합적으로 제공될 수 있다. 하지만 대부분의 경우 ESP만을 사용하는 것으로 보안 요구사항이 충족될 것이다.
그리고 각 프로토콜들은 Transport Mode와 Tunnel Mode를 지원한다. Transport 모드의 경우 AH와 ESP는 다음 레이어의 프로토콜에 보안성을 제공한다. 그리고 Tunnel 모드에서는 IP 자신도 함께 보호한다.
이 두 모드의 차이점에 대해서는 추후 좀 더 자세히 다루겠다.

IPSec에서 제공하는 대부분의 보안 기능들이 암호화 키를 필요로 하기에, IPSec은 적절한 곳에 적절한 키를 입력해주는 매커니즘을 필요로 한다. IPSec은 수동과 자동 입력을 모두 지원하지만, 그 중 자동화된 공개키 기반의 키 관리 방법이 IKEv2로 정의되었으며, RFC 4306으로 배포되었다. 하지만 다른 자동 키 분배 메커니즘도 사용될 수 있을 것이다.

1-1.1. Security Associations

이 단락에서는 AH와 ESP를 포함한 IPv6, IPv4 구현체가 필요로 하는 IPSec fundamental에 대하여 다룬다. SA를 구성하기 위해 AH와 ESP가 사용되며, IKE의 주된 기능 또한 SA를 형성하고 유지하는 데 이용된다.
모든 AH와 ESP의 구현체는 SA의 개념을 만족해야 한다.
SA는 간단히 말해 보안 기능을 제공하고 트래픽을 옮기는 “연결”을 말한다. 보안 기능은 AH나 ESP를 사용함으로써 SA에 의해 제공되고, AH와 ESP의 보호가 동시에 적용되는 경우, 두 개의 SA가 형성되어 보호를 두 번 적용하는 것으로 동시에 사용된다. 일반적으로, 양방향 통신이 이루어질 때 한 쌍의 SA가 필요하다.

SA가 유니캐스트 트래픽 전달에 사용될 경우 SPI(Security Parameters Index)만으로 SA를 나타내기에 충분하다. 하지만 지역적인 문제로(SPI Collision?) IPSec 구현체들은 SA인증을 위해 SPI와 IPSec 프로토콜을 함께 사용해야 할 것이다. 만약 구현체가 멀티캐스트를 지원한다면, 그것은 멀티캐스트 SA를 지원하기 위해 de-multiplexing 알고리즘을 지원해야 한다.

많은 안전한 멀티캐스트 알고리즘들이 있지만, 그 중에서 RFC 3740에서 정의된 중앙 그룹 컨트롤러/일방적으로 할당된 GSA의 SPI를 가지는 키 서버 모델은 키 매니지먼트 서브시스템에 의해 협상될 수 없고, 그렇기에 GSA와 유니캐스트 SA가 동시에 같은 SPI를 사용할 수 있다. 멀티캐스트 지원 IPSec 구현체는 반드시 de-multiplex 인바운드 트래픽을 SPI 충돌이 발생하는 상황에서도 올바르게 전달하여야 한다.

 

여기서 IPSec에서 사용하는 데이터베이스의 개념을 짚고 가자.
IPSec은 크게 두 종류의 데이터베이스를 사용하는데, 하나는 SAD(Security Association Database), 다른 하나는 SPD(Security Policy Database)이다.

SAD는 SA의 집합체인데, IPSec이 적용되는 특정 Connection에 대하여 SA가 정의되고, 그것의 집합이 SAD가 된다. Incoming, Outgoing 트래픽에 따라 각각 정의된다.
SAD에는 다음과 같은 내용이 포함된다.

– AH Parameter : AH 사용시 이와 관련된 인증 알고리즘 및 관련 Key
– ESP Parameter : ESP 사용시 이와 관련된 인증 알고리즘 및 관련 Key
– Mode : Transport Mode / Tunnel Mode
– Destination IP Addr, IPSec Protocol (AH or ESP), SPI : SPI는 하나의 목적지에 대해 다수의 SA가 정의되어 있을 경우 사용하는 식별자(Index)이다.
– Lifetime : SA의 생존시간

SPD는 System Manager에 의해 정의되며, 어떠한 트래픽에 IPSec 서비스가 적용될지 정의한다. 참고로 IPSec의 동작에는 Discard, Protection, Passthrough가 있음을 미리 밝혀 둔다.
이러한 Policy의 적용은 다음과 같은 항목에 의하여 결정된다.

– Source / Destination Address
– Name : DNS 사용자 식별자 / FQDN
– Transport Layer Protocol : TCP or UDP
– Source / Destination Port

SPD는 조건에 맞는 SAD의 SA들을 지정하고, 트래픽이 IPSec 레이어를 통과할 때 정책을 적용한다.

다시 원점으로 돌아가, SAD의 각 엔트리는 반드시 Source/Destination IP Address를 표시해야 한다. 이것은 멀티캐스트의 경우 SPI가 중복될 수 있기 때문에, SPI가 중복될 경우 Destination IP Address로 목적지를 결정하기 위함이다.
이렇게 SA와 Source-Destination Address를 매칭하는 것은 들어오는 IPSec 트래픽과 SA를 매핑해야 한다는 것을 의미한다.

그리고 제한적인 QoS의 경우, DSCP(Differentiated Service Code Point) 비트가 같은 SA로 전송되고, 수신자가 재전송 방지 기능을 AH와 ESP에서 활성화해 놓았다면 그 결과 더 낮은 우선순위의 패킷이 Windowing 메커니즘에 의해 파기되게 된다.
그렇기 때문에 송신자는 반드시 트래픽을 다른 클래스로 보내고, 같은 셀렉터 값을 지정한 뒤 다른 SA를 할당해야 한다. 이 기능을 지원하기 위해 IPSec 구현체는 송신자와 수신자 사이에 다수의 SA를 만들고 유지할 수 있어야 한다.
이러한 병렬 SA를 통한 트래픽 분산은 송신자에 의해 지엽적으로 결정되며, IKE에 의한 교섭을 거치지 않는다. 수신자는 다른 SA들로 들어오는 트래픽을 편견 없이 처리해야 한다.

앞서 서술했듯이, Transport Mode와 Tunnel Mode. 두 종류의 SA가 정의된다. IKE가 한 쌍의 SA를 만들고, 처리의 단순화를 위해 한 쌍의 SA는 반드시 같은 모드여야만 한다.
Transport Mode SA는 주로 한 쌍의 호스트가 종단간 보안을 제공해야 할 경우 사용된다. Transport Mode가 Security Gateway간, Host-Security Gate간에서 사용될 경우 Transport Mode는 in-IP Tunneling이나 GRE(Generic Routing Encapsulation)을 사용할 것이다. 상황을 명확하게 하기 위해, Intermediate System에 의한 Transport Mode 사용은 인바운드의 Destination Address 아웃바운드의 Source Address가 Intermediate System에 속해있는 경우로 한한다. 그리고 Transport Mode의 경우 종단간 패킷 헤더에는 적용되지 않는다. 그러므로 이 모드의 IPSec은 신중히 적용되어야 할 것이다.

Tunnel Mode SA의 경우,  SA는 IP tunnel을 적용받는다. 접근 제어가 헤더와 트래픽에 모두 적용되며, 두 호스트는 반드시 서로에게 Tunnel SA를 만들어야 한다. 아래의 두 예외를 제외하고, Tunnel SA의 종단은 Security Gateway가 된다. 그러므로 두 Security Gateway 사이의 연결은 보통 Tunnel Mode SA이며, 그렇지 않은 두 종류의 예외는 다음과 같다.

–  트래픽이 Security Gateway를 지나갈 때 : 예를 들어 SNMP 프로토콜의 경우 Security Gateway가 호스트처럼 동작하고, Transport Mode가 허용된다. 이 경우 SA는 Security Gateway내의 호스트(매니지먼트) 기능에서 종단된다.
– 앞서 말했듯이 Security Gateway들은 경로 상의 IP 트래픽에게 보안을 제공하기 위하여 Transport Mode를 지원할 수 있다.

이러한 보안 서비스의 집합들은 SA 모드와 프로토콜의 선택에 달렸다.
예를 들어, AH와 ESP 둘 다 무결성과 인증 기능을 제공하지만, 적용 범위는 각각의 프로토콜마다 다르며, Transport/Tunnel 모드에 따라서도 다르다. 만약 IPv4옵션과 IPv6 확장 헤더의 무결성이 보장되어야 한다면, 옵션이 예키치 못하게 수정될 수 있는 AH 대신 ESP를 사용해야 할 것이다.
접근 제어를 쪼개보면, 가장 먼저 어떠한 셀렉터를 고르느냐에 따라 결정된다. 예를 들어, IKE와 Child에 따라서 다른 접근 제어 방법을 가진다.

일단 암호화에 사용되는 프로토콜이 결정되면, ESP SA는 양쪽 끝단에서 부분적인 트래픽 흐름 기밀성을 제공할 수 있다. 터널 모드를 사용하는 것은 내부 IP 헤더를 암호화하고, 트래픽의 발신지와 수신지를 감춘다. 거기에 ESP 페이로드의 패딩은 패킷 사이즈를 감추어 트래픽의 특정을 어렵게 만들 수도 있다.
IPSec 구현체들은 반드시 ESP SA가 암호화와 무결성 알고리즘을 사용하지 않고는 설정될 수 없도록 만들어야 한다.

 

1-1.2. AH(Authentication Header)

AH는 IP Extension Header로서, IP Packet에 대한 인증을 제공한다. 암호화를 수행하지 않기에 데이터그램의 기밀성은 보장하지 않으며, 앞서 말했듯이 IP 패킷 인증, 무결성 검증, 출발지 기반 인증과 재전송 공격의 방어를 제공할 수 있다.

IPSec Transport Mode와 Tunnel Mode에서의 패킷 구조를 나타낸 것이다. Transport Mode를 사용할 경우 IPv4 헤더의 뒤에 AH가 오고, Tunnel Mode를 사용할 경우 IPv4 헤더의 앞에 위치하여 IPv4 데이터그램을 캡슐화한다.

AH의 상세 구조를 나타낸 것이다. Payload Length는 IPv4 페이로드의 길이를, SPI는 앞서 설명한 SA 식별자를, Sequence Number는 AH Processing을 수행할 때마다 1씩 증가하며, 재전송 공격의 방어에 사용된다.
마지막으로 Authentication Data는 패킷 데이터 전체에 대한 해쉬 값으로, 변하기 쉬운(Mutable) 값들은 0으로 세팅하여 계산한다.

1-1.3. ESP(Encapsulating Security Payload)

ESP는 AH의 기능에 덧붙여 암호화를 제공한다. 때문에 대부분의 IPSec 연결들은 ESP를 사용하며, VPN에서 사용되는 것도 ESP이다.

ESP 또한 Transport Mode와 Tunnel Mode를 지원한다. AH와는 달리 ESP 헤더가 오고, ESP Auth Data가 마지막에 위치하는 것을 알 수 있다. 이는 ESP 헤더 ~ ESP Auth Data 사이의 페이로드만이 암호화 되기 때문이다.

ESP 패킷의 상세 구조이다. 페이로드 뒤에 패딩이 오고, 패딩을 포함하여 암호화를 하는 것에 주목하자. 패딩이 적용될 경우 원본 데이터그램의 길이를 유추하는 것이 불가능하기에 패킷 분석에 어려움을 더한다.
따라서 공격자로부터 더 안전한 프로토콜이 되겠다.

1-2. PPTP

PPTP는 인터넷의 초창기에 등장한 암호화 프로토콜로, Microsoft와 Ascend Communications, 3Com에 의하여 개발되었다.
PPTP의 프로토콜 명세는 1999년, RFC 2637로 배포되었으며, Microsoft Windows에 기본적으로 내장되어 있기에 가장 널리 쓰이는 VPN 프로토콜이 되었다.

하지만 RC4 해쉬 알고리즘이 Bias를 가진다는 것이 널리 알려져 있으며, 인증 프로토콜로 사용되었던 MS-CHAPv1이 56-Bit DES 암호화를 사용하기에 현대의 컴퓨팅 기술로는 비밀키를 손쉽게 추론할 수 있게 되어서 더 이상 안전하지 않은 프로토콜로 분류, IPSec, L2TP 등의 더 안전한 프로토콜을 사용할 것을 권고하고 있다.

 

PPTP는 터널 형성을 위해 PPP(Point-to-Point Protocol)과 GRE(Generic Routing Encapsulation)을 사용한다.
PPP가 Data-Link 계층에서 사용하기 위해 개발되었기에, PPP를 캡슐화하기 위해서 GRE가 사용되며, IP 패킷은 PPP로 캡슐화된 뒤 GRE로 다시 캡슐화된다. 따라서 아래와 같은 패킷 구조를 갖는다.

그리고 PPTP는 데이터 전송 채널과 제어 채널이 분리되어 있는데, 제어 채널은 TCP 연결을 사용하고, 캡슐화되지 않는다.

그리고 GRE-PPP만으로는 터널은 구성되지만 페이로드에 대한 암호화가 수행되지 않기에, 따로 MPPE(Microsoft Point-to-Point Encryption)을 이용하여 암호화를 수행한다.
MPPE는 RFC 3078로 출판되었으며, PPP Payload에 대한 암호화를 수행한다.

MPPE는 Keberos나 TLS 등의 방법으로 세션 키를 교환하고, 세션 키를 이용해 RC4 암호화를 수행함으로써 동작한다.

Network Study – 4주차 : TCP/IP

 

지난 주에는 패킷 교환망에서 패킷의 경로를 결정하는 방법인 라우팅 프로토콜에 대해 알아보았다.
그리고, 이번 주에는 TCP/IP 네트워크에서 핵심적인 역할을 하는 TCP와 IP에 대해 알아보자

1. IP(Internet Protocol)의 역사

IP는 본래, TCP/IP Protocol Suite에 속한 하나의 프로토콜이다. 이것은 IAB(Internet Architecture Board)에 의해 관리되는 IANA(Internet Assigned Number Authority), IRTF(Internet Research Task Force), IETF(Internet Engineering Task Force)에서 관리된다.
이들 중 하나인 IETF에서 TCP/IP 표준인 RFC(Request for Comments)를 배포한다. 단, 모든 RFC가 표준인 것은 아니다. IAB의 검토를 거친 RFC만이 인터넷 스텐다드로써 등재되고, 전체 네트워크에서 지켜야 할 표준으로 지정된다.
그러므로, 대부분의 RFC들은 실험적인 적용이나 단순 권고를 담고 있다.

TCP/IP에 대해 다루기 전에 먼저 TCP/IP의 역사를 알아보자.

– 1970년, ARPANET 호스트들이 TCP의 전신인 NCP(Network Control Protocol)을 사용하여 운영되기 시작한다.
– 1972년, Telnet 프로토콜이 만들어진다. Telnet은 서로 다른 시스템 터미널을 에뮬레이션 하기 위해 사용되었다. 1970년대 초, 이 시스템들은 서로 다른 종류의 메인프레임들로 이루어져 있었다.
– 1973년, FTP(File Transfer Protocol)이 사용된다. FTP는 서로 다른 시스템 사이에서 파일을 전송하기 위해 사용되었다.
– 1974년, TCP(Transmission Control Protocol)이 구체화된다. TCP는 NCP를 대체하였으며, 더 개선된 신뢰성 있는 통신을 제공하였다.
– 1981년, IP(Internet Protocol)이 구체화된다. IP는 단대단 전송에서 어드레싱과 라우팅을 제공하였다.
– 1982년, DCA(Defense Communications Agency)와 ARPA는 TCP와 IP를 합쳐 TCP/IP Protocol Suite를 만든다.
– 1983년, ARPANET이 NCP에서 TCP/IP로 이전한다.
– 1984년, DNS(Domain Name System)가 제안된다. DNS는 도메인 이름을 IP 주소로 바꾸어 주었다.
– 1995년, ISP(Internet Service Provider)들이 인터넷을 개인과 기업들에게 제공하기 시작한다.
– 1996년, HTTP(Hypertext Transfer Protocol)이 제안된다. WWW(World Wide Web)이 HTTP를 사용한다.
– 1996년, 최초의 IPv6 표준이 발표된다.

이상이 간략하게 살펴본 TCP/IP의 역사이다. 본래 TCP/IP는 TCP와 하나였으며, 네트워크 계층이 구체화되면서 TCP와 IP로 분리되게 되었다.
2017년 현재 IP에서 이슈가 되는 부분은 IPv6로의 전환과 4 to 6, 6 to 4의 터널링이며, 추후 IPv6를 다룰 때 더 자세히 알아보도록 하겠다.

2. TCP/IP Protocol Suite

IP를 다루다 보면 필연적으로 상위 계층의 프로토콜들이 따라온다. IP만으로는 인터넷을 운영하는 것이 불가능하기 때문이다.
이 중 특히 ARP와 ICMP에 대한 의존도가 특히 높다고 할 수 있으리라. 이 프로토콜들에 대해 이야기하기 전에, 먼저 TCP/IP Protocol Suite를 훑어보자.

TCP/IP Protocol Suite는 다음과 같은 구조로 이루어져 있다.

이를  OSI Layer와 비교해보면 L1~2가 Network Layer로, L3가 Internet Layer로, L4가 Transport Layer로. 그리고 L5~7이 Application Layer와 대응되는 것을 알 수 있다.
이렇듯, TCP/IP Protocol Suite는 ISO에서 제정한 OSI 7계층과는 다른 구조를 가지고 있음을 알 수 있다.
이것은 OSI Layer가 프로토콜에 대한 표준안을 제시하는 것이 아닌, 프로토콜의 발전을 위하여 각 계층에서 수행하는 일들을 체계적으로 나눠 놓은 것에 불과하기 때문이며, 실제로 프로토콜을 설계할 때는 더 세부적으로 구분된 OSI 7계층을 참조하여 개발이 이루어지고 있다.

또한, 특기할 점으로는 IP(v4)와 같은 Internet Layer에 속한 ARP와 IGMP, ICMP가 있는데, 목적지까지의 전달이라는 핵심 목표를 수행하는 것은 IP이지만, IP가 좀 더 효율적으로 동작하도록 도와주는 프로토콜들이 이들 프로토콜이 되겠다. 특히 ARP는 2계층과의 연동을 담당하는 프로토콜로써, ARP 없이 IP 단독으로는 사실상 데이터 전송이 불가능하다.

IGMP를 제외한 각 프로토콜에 대해서는 이미 별도의 문서로 다루었기에, 이 글에서는 간단하게 프로토콜의 역할 정도만 소개하고 넘어가고자 한다.

2-1. ARP(Address Resolution Protocol)

ARP는 IP 네트워크에서 IP주소를 물리적 주소(PHY Address)로 대응시키기 위해 사용하는 프로토콜이다.
L3 프로토콜 주소인 IP 주소를 이용해 최종 목적지까지 라우팅 되어 온 패킷은 하부 시스템에 전달되기 위하여 L2 프로토콜 주소(e.g. MAC Address)를 필요로 하게 된다. 이 때 사용되는 프로토콜이 바로 ARP이다.

ARP의 상세 동작과 RARP, gARP 등을 알고 싶다면, CCNA Study – ARP Protocol을 참조하자.

2-2. ICMP(Internet Control Message Protocol)

ICMP는 오류 보고와 흐름 제어 기능이 없는 IP를 보조하기 위하여 만들어진 프로토콜이다.
현대 인터넷에서는 오류 보고와 흐름 제어의 역할이 L4로 넘어갔기에 이 일은 TCP가 수행하지만, 실제로 TCP에서 흐름 제어 기능을 수행할 때, TCP는 ICMP를 이용하여 오류 제어와 흐름 제어를 수행한다.
이렇듯, ICMP는 현대 인터넷이 트래픽 폭증으로 인하여 다운되지 않고 운영될 수 있게 하는 역할의 한 축을 담당하고 있다.

ICMP의 상세 동작은 CCNA Study – ICMP를 참조하자.

2-3. IGMP(Internet Group Management Protocol)

IGMP는 IP 네트워크에서 라우터가 멀티캐스트 그룹을 판단할 때 사용하는 프로토콜이다.
IGMP의 동작을 다루기 위해선 먼저 멀티캐스트에 대해 알아볼 필요가 있다. 멀티캐스트란 Unicast/Broadcast로 구성되어 있던 IP 네트워크에서 일대 다수(One to many) 혹은 다수 대 다수(Many to many) 통신을 지원하기 위해서 개발되었다.
멀티캐스트를 지원하기 위하여 IP 대역의 일부(클래스 D/224.0.0.0 ~ 239.255.255.255)를 멀티캐스트 대역으로 할당하였으며, 특히 이 중에서 224.0.0.0/24 대역은 로컬 멀티캐스트 대역으로 지정되어 있다.

IGMP는 최초 RFC 1112를 통해 표준화되었으며, IGMPv3가 Proposed Standard로써 제안되었다.
여기서는 Internet Standard인 RFC 1112를 기반으로 IGMP의 동작을 알아본다.

IPv4 Protocol Suite은 이 정도로 해두고, IPv4의 핵심 역할인 고유 주소 할당과 경로 결정은 라우팅을 다루면서 충분히 설명하였다고 생각한다.
그렇기에 이 글에서는 이전에 미처 다루지 못하였던 IPv4 패킷의 구조 정도만을 짚고 넘어가고자 한다.

(1) Version : IPv4를 나타내기에 4의 값을 가진다.
(2) Header Length : 헤더의 크기를 워드(4Byte)단위로 나타낸다.
(3) ToS or DiffServ : 본래 IP 패킷의 응용에 따라 적절한 경로를 선택하기 위해 도입되었던 ToS 필드는 그 저조한 사용률 덕에 DiffServ 필드로 대체되었다. ‘최저 비용’, ‘처리량 최대’, ‘지연 최소’ 등의 상당히 모호하고 변동성이 심한 플래그를 담고 있던 ToS와는 달리, DiffServ는 ‘패킷의 클래스별 QoS’라는 정량화된 목표를 나타낸다. 이 클래스는 ECN 2비트를 제외하고 6비트를 사용, 최대 64개로 분류될 수 있으며, 네트워크 서비스 주체가 커스터마이징 할 수 있다.
(4) Total Length : 전체 패킷의 길이를 1바이트 단위로 나타낸다.
(5) Identifier : IP 패킷에 할당되는 고유 값. 패킷이 생성될 때 설정되며, 단편화된 패킷의 경우 같은 값을 갖는다. 이것은 루핑 때문에 발생한 패킷을 IP레벨에서 네트워크로부터 제거할 수 있다는 것을 의미한다. TCP의 Sequence Number와 유사.
(6) Flags : Fragment Flags. 첫 비트는 0, 두번째 비트는 DF(Don’t Fragment) 플래그로 1로 세트될 시 단편화 불가. 세번째 비트는 More Fragment로 단편화된 패킷이 뒤에 더 있을 경우 1로 세트된다.
(7) Fragment Offset : 해당 패킷이 단편화된 데이터그램에서 어느 부분에 해당하는지 알려주는 값이다.
(8) Time to Live(TTL) : 한 홉(Hop)을 건널 때마다 1씩 감소하여, 0이 되면 폐기된다. TTL 만료로 패킷을 폐기한 라우터는 해당 패킷의 발신지를 향하여 ICMP 11 – Time Exceeded를 전송한다.
(9) Protocol : IP 상위의 프로토콜을 알려주는 SAP.
(10) Header Checksum : 헤더 전체를 대상으로 CRC-16을 수행한다.
(11) Source Address : 출발지 IP 주소
(12) Destination Address : 목적지 IP 주소
(13) Options : IPv4에서 실험용으로 사용되었던 옵션들이 다수 존재. IANA에 등록되지 않은 옵션도 직접 정의하여 사용할 수 있으나, 실제 네트워크에서는 거의 사용되지 않는다.
(14) Padding : 패킷이 32Bit(4Byte)의 배수로 만들어지지 않을 경우, 효율적인 데이터 처리를 위하여 4바이트 배수로 맞추기 위한 필드. 더미값이 들어간다.

3. IPv6 (Internet Protocol Version 6)

지난 30여년간 IPv4가 보여주었던 여러 한계점들과 문제를 해결하기 위한 대안으로써 1998년, IPv6(RFC2460)가 제안되었다.
IPv6는 IPv4의 고갈된 주소 공간을 훨씬 큰 크기로 확장하고, 주소의 파편화로 복잡화된 라우팅 테이블을 최적화 하는 것, 프로토콜 헤더의 간략화, 추후 인터넷의 변화를 유연하게 수용할 수 있는 옵션과 확장들의 개선,  우선순위에 따른 흐름 제어와 QoS등을 목표로 하여 디자인되었다.

또한 흔히들 IPv4 대비 강화된 보안성을 추가적인 장점으로 들고 있지만, 아직 IPv6와 인접 프로토콜들은 표준화가 진행중이기 때문에 오히려 IPv4 시스템에서 발생하지 않는 보안 취약점이 추가로 발견될 수 있다는 점을 염두에 두어야 할 것이다.

IPv6에서 극명히 드러나는 IPv4와의 차이점은 바로 헤더이다. IPv6는 IPv4헤더를 간략화하고, 공통 헤더와 옵션 헤더를 나누어 전체 헤더 크기를 감소시키며 확장성을 확보하였다.

(1) IPv6 Basic Header

IPv6의 가장 기본이 되는 헤더이다. IPv4의 그것과 비교하여 확연히 간략화된 모습을 확인할 수 있다.

(1) Version : IPv6이기에 6의 값을 갖는다.
(2) Traffic Class : IPv4의 ToS와 유사한 역할. 아직 표준이 확정되지 않았기에 명확한 정의는 이루어지지 않음.
(3) Flow Label : IP 프로토콜은 비연결적인 프로토콜로 설계되었으나, IPv4의 사례에서 주로 연결 지향적 프로토콜로 사용하는 경향을 확인할 수 있었다. IPv4에 대하여 연결 지향적인 프로토콜 기능을 제공해주는 기술로 MPLS가 제안되었으며, IPv6에서는 MPLS가 담당하던 부분이 IP 프로토콜에 포함되었다. Flow Label은 같은 특성을 가지는 패킷의 ‘흐름’을 나타낼 수 있으며, 이를 통해 응용별 서비스를 제공할 수 있다. 이를테면 실시간 비디오 응용의 경우 처리에 필요한 자원을 미리 예약해둘 수 있으며, 이를 위해 RTP(Real Time Protocol)과 RSVP(Resource Preservation Protocol)이 사용된다.
(4) Payload Length : 헤더를 제외한 나머지의 크기를 바이트 단위로 나타낸다. 확장 헤더는 페이로드의 일부로 간주된다.
(5) Hop Limit : IPv4의 TTL과 동일.
(6) Next Header : IPv6 공통 헤더의 다음에 위치할 헤더의 종류를 나타내는 8bit 선택자. 상위 레벨 프로토콜이나 IPv6 Extension Header를 나타낼  수 있다.
(7) Source Address : 출발지 주소
(8) Destination Address : 목적지 주소

IPv4와 비교하면 다음과 같은 차이가 있다.

– 헤더 길이 필드의 제거 : 헤더의 길이가 고정되어 있기 때문에 제거되었다.
– 서비스 유형 필드의 제거 : ToS/DiffServ는 Flow Label로 대체되었다.
– Total Length 필드의 제거 : Payload Length 필드로 대체된다.
– 단편화 관련 필드의 제거 : 단편화 확장 헤더에서 제공된다.
– 프로토콜 필드의 제거 : Next Header 필드로 대체되었다.
– 옵션 필드의 제거 : 확장 헤더를 통하여 제공된다.
– 헤더 Checksum 제거 : 상위 계층에서 제공되기에 삭제되었다.

(2) IPv6 Extension Header

IPv6에서는 헤더 부분이 네트워크에서 차지하는 대역폭을 줄이고, 확장성을 도모하기 위하여 Extension Header(이하 확장 헤더)를 도입하였다. IPv4와는 달리 용도와 페이로드의 종류에 따라 확장 헤더를 사용할 수 있으며, 각각의 확장 헤더는 독립적이고, 동시에 중첩 가능하다.

RFC2460에서 정의된 확장 헤더는 다음과 같다.

– Hop by Hop Options
– Routing (Type 0)
– Fragment
– Destination Options
– Authentication (RFC2402)
– Encrypted Security Payload

확장 헤더는 IPv6의 표준화가 진행됨에 따라 더 늘어날 수 있으며, 임의의 확장 헤더를 정의하는 것 또한 허용된다.

(2-1) Hop-By-Hop Option Header

이 옵션 헤더는 발신자가 데이터그램이 통과하는 모든 라우터에 정보를 전달할 필요가 있을 경우 사용한다.
현재는 3가지 옵션(Pad1, PadN, Jumbo Payload)가 정의되어 있으며, 각 옵션에 대한 자세한 설명은 다음 절에서 다루겠다.

– Pad1 Option : Pad1 옵션은 어떤 옵션이 특정한 위치에서 시작될 필요가 있을 때 사용된다. 만약 지정 위치에서 1바이트가 부족하다면, 정렬(Alignment)을 위해 Pad1이 추가된다. Pad1은 1바이트의 크기를 가지며,  값은 0이다.
– PadN Option : 특정 옵션이 N Byte가 모자라다면 PadN이 사용된다. PadN의 첫번째 바이트(옵션 코드)는 1, 두번째 바이트(옵션 길이)는 패딩의 크기, 나머지 바이트들은 옵션 길이만큼의 크기를 가지며 0의 값을 갖는다.
– Jumbo Payload Option : IPv6에서는 데이터그램의 최대 크기가 65,535바이트로 증가하였다. 하지만 어떠한 이유로 이것보다 더 큰 페이로드가 요구된다면 점보 페이로드 옵션을 사용할 수 있다. 점보 페이로드 옵션은 ‘정렬 제한’을 갖는다. 즉, 옵션 헤더의 시작으로부터 (4n+2)바이트의 위치에서 시작해야 한다.

(2-2) Source Routing

IPv6의 Source Routing 옵션은 IPv4의 느슨한 라우팅 옵션과 엄격한 라우팅 옵션을 결합한 것이다.
Address Left 필드는 목적지까지 도달하기 위한 홉 수를 나타내며, Strict/Loose Mask를 통하여 느슨한/엄격한 라우팅 옵션을 선택한다.

IPv4의 그것과 마찬가지로, 엄격한 라우팅 옵션은 이 패킷이 반드시 정해진 순서의 라우터를 통과하여 전송되야 함을 의미하고, 느슨한 라우팅 옵션의 경우에는 각 라우터 사이에 다른 라우터들이 들어갈 수 있다.

(2-3) Fragment

IPv6에서는 IPv4헤더에 포함되어 있던 단편화 옵션이 별도의 확장 헤더로 분리되었다. 단, IPv6에서는 오로지 발신자만이 단편화를 수행할 수 있기에 반드시 최대 MTU 값을 찾아내는 일이 선행되어야 한다. 이것은 MTU 탐색 기법(Path MTU Discovery Technique)을 통해 이루어지며, 다음과 같은 순서로 수행된다.

IPv6에서의 MTU 탐색 기법은 RFC 1981으로 표준화 작업이 진행중이다.

1. 발신지 호스트는 큰 사이즈의 데이터그램을 전송한다
2. 라우팅 경로 상에 있는 장비가 자신의 MTU 값보다 더 큰 데이터그램을 수신하면 Packet too big 메시지를 발신지로 돌려보낸다.
3. 발신지 호스트는 Packet too big 메시지에 들어 있는 MTU 값으로 재전송을 수행한다.

이렇게 보면 참 단순한 방법이지만, 여기에는 몇가지 문제가 있다.
먼저, 1회의 Packet too big  메시지만으로 Path MTU를 결정할 수 없다. 최초로 에러를 발생시킨 라우터의 다음 홉에 있는 라우터가 가진 MTU 값이 더 작을 수도 있다.
그리고 Path MTU값이 하나의 값으로 고정되게 된다면, 토폴로지 변동에 따라서 증가할 수 있는 MTU 값을 효율적으로 사용하지 못한다.

첫번째 문제는 ICMP Error 메시지가 도착하지 않을 때까지 MTU를 감소시키는 것으로 대응할 수 있다. 하지만 두번째 문제의 경우는 좀 더 복잡하다.

RFC 1981은 호스트는 Path MTU값을 좀 더 높게 ‘추정할 수 있다’고 명시한다. 하지만 이것 또한 전송하려는 데이터의 크기가 PMTU보다 커서 MTU를 확장할 필요가 있을 경우에 한한다. 그리고 이러한 시도는 Packet too big 메시지를 수신한 뒤 5분 이내에는 이루어질 수 없다.

이것을 통해 알 수 있는 것은 현재 IPv6의 표준화에 참여하고 있는 사람들은 Path MTU를 최적화하는 것 보다, 이로 인해서 발생할 수 있는 회선의 부하를 좀 더 중시한다는 점이다.
그리고 당연하지만 Path MTU 값은 IPv6의 최소 패킷 길이보다 작을 수 없다.

또 하나 쟁점이 되는 부분은 ‘어느 레이어에서 PMTU 탐색을 진행할까?’ 라는 것이다.
PMTU 탐색을 전송 레이어에서 수행하는 것은 내부 구현적 측면에서 유리하지만, 전송 프로토콜마다 알고리즘을  새로 구현해야 하며 이것은 다른 프로토콜간의 MTU 공유를 방해한다.
이러한 이유로 IP 계층에서 PMTU Discovery를 구현하게 되었고, ‘IP 레이어에서 PMTU 정보를 저장하고, ICMP가 Packet too big 메시지를 처리하는’ 식으로 구현이 이뤄졌다.

(2-4) Destination Option

기본적으로 Hop-by-Hop Option과 동일하며, 발신자가 오직 목적지 호스트에게만 정보를 전달하고 싶을 때 사용한다. 현재까지는 Pad1과 PadN만이 정의되어 있다.

(2-5) Authentication

인증 확장 헤더는 두 가지의 목적을 갖는다. 메시지 송신자를 검증하는 것과, 데이터의 무결성을 검증하는 것이다.
Security Parameter Index에서 인증 방법을 전달하며, Authentication Data가 따라온다.

(2-6) Encrypted Security Payload

IPv6에서 제공하는 도청 방지 및 비밀 보장을 위한 확장이다. 터널 모드와 전송 모드로 구현되며, 대표적인 응용으로는 IPSec이 있다.

 

(3) IPv6의 주소 공간과 할당

IPv6가 만들어진 가장 큰 이유인 IPv4의 주소 고갈 문제, 이것을 해결하기 위하여 IPv6는 주소 공간의 크기를 128비트로 확장하였다.
IPv4 대비 4배의 길이를 가지는 이 주소값은 IPv4와는 다른 구분 방법, 분배 방법 및 읽는 방법이 필요하였다.

먼저, IPv6은 IPv4와 같은 점 10진법 표기법으로 나타낼 수 있다. 하지만 이것은 IPv4 대비 4배의 길이를 가지게 되므로, 잘 쓰이지 않는다.
두번째 방법이 흔히 사용되는 16진수 콜론 표기법으로, 10진법 표기 대비 길이를 절반으로 줄일 수 있었다.
이것만으로는 가독성이 떨어졌으므로, 이 16진수 표기를 축약하는 방법이 또 제공되는데, 하나의 콜론에서 앞에 위치하는 0들을 하나의 0으로 표현하는 방법과 0으로 이루어진 콜론의 연속을 제거하고 ::으로 표기하는 방법(Zero Compression)이 있다. 특히 제로 압축은 하나의 IPv6 주소에서 두 번 이상 사용시 정확한 해석이 불가능하기에 한번만 사용될 수 있음에 주의해야 할 것이다.

IPv6은 주소 공간의 구분을 위한 CIDR를 지원하며, IPv4와 같은 해석 방법을 갖는다.

IPv6 주소 공간은 현재 Global Unicast, Unique Local Unicast, Link-Scoped Unicast, Multicast 주소와 특수 목적용 주소가 할당되어 있으며, 7/8가량의 공간이 미래 사용을 위해 예약된 채로 남아있다.
이들 주소 중에서 특히 자주 사용되는 Global Unicast, Unique Local Unicast, Multicast의 주소 영역은 다음과 같다.

– Global Unicast : 2000::/3
– Unique Local Unicast : FC00::/7
– Multicast : FF00::/8

 

(4) ICMPv6

 

(5) RTP/RSVP

 

(6) MLD

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

Anatomy of OpenFlow – Chapter 1. 소개

소프트웨어 정의 네트워크(SDN)는 널리 알려진 buzzword가 되었다. 이제, 모든 네트워크 벤더들은 자신들만의 SDN 솔루션을 가져야만 한다. 그리고 ‘SDN’에 대한 언급이 없는 마케팅 브로셔는 거의 배포되지도 않게 되었다. 이러한 추세로부터 판단컨데, 이제 클라우드와 SDN을 빼놓고서는 네트워크에 대해 많은 것들을 이야기 할 수 없게 될 것이다.

‘이 용어'(SDN)가 너무나 유명해진 나머지 비슷하면서도 다른 많은 용어들이 만들어졌다. 소프트웨어 정의 데이터센터, 소프트웨어 정의 스토리지, 소프트웨어 정의 애플리케이션 배포, 네트워크 기능 가상화(NFV) 등등.

업계의 수많은 CIO와 CTO들의 머리를 아프게 만드는 이 ‘SDN’이라는 용어란 과연 무엇일까? 그리고 그들의 사업에 대해서 어떤 의미를 가지는 것일까? 내가 알기로는 SDN이란 ‘컨트롤 평면과 데이터 평면을 분리하는 것’, ‘네트워크에 프로그래밍 기능을 제공하는 것’이다. 물론, SDN이 ‘데이터 평면을 추상화 한 것’이라는 것을 안다. 하지만 그게 대체 무슨 뜻인가? SDN은 OpenFlow와 동의어인가? NFV와 SDN의 차이점은 무엇일까? 그리고 현 시스템에 SDN을 도입하는 것을 검토할 때, ‘파괴적인 기술’이라는 것은 대체 무슨 의미인가? SDN을 도입하려면 기존 시스템을 없애야 한다는 말인가?

이 무엇보다 중요한 것은, SDN은 어떤 효용성을 가지는 것일까?

이 책이 OpenFlow를 다루고 있음에도 불구하고, SDN 아키텍쳐에서 OpenFlow의 역할을 알기 위해서는 먼저 SDN을 이해할 필요가 있다. 이 챕터는 OpenFlow에 대해 이야기하기 위해 필요한 기본적인 개념을 다룰 것이며, 몇 가지의 기본적인 질문들에 대해 답할 것이다.

 

SDN이란 무엇인가?

먼저, 2가지의 정의로부터 시작해보자. 하나는 매우 구체적이며, 다른 하나는 조금 더 일반화된 것이다. 두 정의 모두 현재 산업계가 직면한 문제점에 대한 지향점을 보여준다.

정의 1.

SDN은 중앙 집중화된 컨트롤러가 분산된 스위치들의 포워딩 동작을 제어하는 L2/L3 아키텍쳐이다

정의 2.

SDN은 개별 네트워크 구성 요소들을 최소한의 조작만으로 프로그래밍 할 수 있는 추상화된 네트워크를 위한 개념적인 프레임워크이다.

이 두 가지의 정의가 같은 것을 의미한다고 하기에는 상당히 무리가 있을지도 모른다. 하지만 이 두 정의는 분명 ‘동일하다’. 당신은 SDN의 첫번째 정의를 자주 들어 보았을 것이다. 하지만 첫번째 정의는 두번째 정의를 좀 더 엄밀하게 정의한 부분집합에 불과하다.

우리는 먼저 첫번째 정의로부터 시작하여 두번째 정의를 향해 나아갈 것이다.

 

컨트롤 평면과 제어 평면

전체 SDN 아키텍쳐는 네트워크의 초창기로부터 이어져 온 연속적인 발전들을 상징한다. 개념적으로는 오래 전 스위치에서 관리, 데이터, 제어 평면이 분리되었을 시점으로 거슬러 올라간다.

 각 평면들의 기능에 대해 간단하게 다루자면

  • 관리 평면은 동작 모니터링과 접근 기능을 제공한다. CLI와 SNMP, syslog, NetFlow 등이 여기에 속한다.
  • 데이터 혹은 포워딩 평면은 수신한 PDUs(Protocol Data Units)를 전송하는 포트 혹은 인터페이스와 스위칭 패브릭, 인터페이스 사이에서 포워딩을 수행하기 위한 필수적인 정보로 구성되어 있다. 예를 들어, 라우터에서 이러한 정보는 FIB(Forwarding Information Base)에 저장되어 있으며, 패킷을 보내기 위한 목적지 주소와 인터페이스 정보, 그리고 이더넷 스위치에서는 포트별로 매핑된 MAC 주소 테이블이 있다.
  • 제어 평면은 데이터 평면이 올바르게 PDU를 전송하기 위해 필요한 정보들을 제공한다. 라우터의 제어 평면에서는 OSPF, IS-IS, BGP 등의 라우팅 프로토콜이 동작하며, 데이터 평면의 FIB를 갱신한다.

 

제어 평면은 네트워크에서 ‘지능적인’ 것으로 간주되는데, 왜냐하면 그것이 PDU를 이상적인 경로로 전송하는 것과 루프 회피, QoS, 장애 복구, 그리고 트래픽 관리에 있어 중요한 결정을 내리기 때문이다. 데이터 평면은 PDU를 최대한 빠르고 효율적이게 입력 포트에서 출력 포트로 내보내는 일만을 한다. 데이터 평면은 PDU가 어떻게, 어디로 보내지는지에 대해 아무런 결정을 내리지 않는다.

 

1990년대 말, 고성능 스위치에서 한 샤시 내에서 데이터 평면과 제어 평면이 하드웨어적으로 분리되는 혁신을 이루었다. 제조업체들은 독립된 제어 평면을 라우터 프로세서(Router Processor), 혹은 Supervisor Module이나 Routing Engine 등으로 불렀다. 이 구조를 택함으로써 얻는 이점은 동일하다. 제어 평면에 대한 부하가 데이터 평면의 전송 속도에 영향을 미치지 않고, 그 역도 마찬가지이다. 그리고 데이터 평면이 제어 평면 없이도(Headless) 잠시 동작할 수 있게 되면서 NSF(Non Stop Forwarding), ISSU(In-Service Software Upgrades) 등의 고가용성 기술이 등장하게 되었다.

한편, MPLS는 데이터 평면과 제어 평면을 좀 더 밀접한 관계로 만들었다. 네트워크의 “지능적인” 부분은 경계면으로 옮겨지고, MPLS Privider Edge(PE) 라우터가 최적 경로 결정을 내리고, 코어의 Provider 라우터는 단순히 패킷을 스위칭하기만 하면 되었다. 하지만 MPLS Provider 라우터도 자신만의 제어 평면을 가지고 있었는데, 때문에 PE 라우터 없이도 자체적으로 라우팅 기능을 수행할 수 있었다.

MPLS 네트워크는 IP 네트워크에서 제어 평면에 대한 생각의 방향성을 바꾸어 놓았다. 우리는 분산된 토폴로지에서 제어 평면을 최적화하는 일에 많은 시간을 투자했다. 모든 라우터가 각각의 제어 평면을 가지고 있지만, 전달 경로 선택은 라우터 단독으로 이루어질 수 없었다. 그래서 라우팅 프로토콜을 사용하여 서로간의 최적 경로를 결정하게 되었다. 여기서의 핵심 과제는 각각의 제어 평면들이 네트워크에 대하여 동일한 정보를 공유하는(Convergence)것에 시간이 걸린다는 점이다. IP 네트워크에서 루프를 피해서 믿을만한 최적 경로를 결정하는 것에는 시간과 계산이 필요했지만, MPLS는 대부분의 제어 평면을 PE 라우터가 전담하게 되면서 분산된 제어 평면의 문제점을 상당히 감소시킬 수 있었다.

그리고 이 두 가지의 경향성 -독립된 하드웨어에 설치된 제어 평면이 데이터 평면에게 정보를 보내주는 것과 제어 평면을 네트워크의 에지에 위치시키는 것-을 합친 것이 기본적인 SDN 아키텍쳐이다. 네트워크에서 “뇌”의 역할을 하는 제어 기능은 중앙 집중화하고, 포워딩 정보를 네트워크의 스위치들에게 업데이트 해 주는 것이 바로 그것이다.

 

중앙 집중화된 컨트롤러는 분산된 제어 평면 환경에서 발생한 몇 가지 문제들을 해결해 준다.

  • 장애에 대한 정보를 다수의 노드에게 공유할 필요가 없기 때문에, 링크 혹은 노드의 장애 대처를 더 빠르게 수행할 수 있다.
  • 컨트롤러가 전체 네트워크의 청사진을 가지고 있기 때문에 루프 회피가 더 간단해진다.
  • 프로그래밍 가능한 네트워크에서 가장 중요한 개념으로, 데이터 평면과 유저 사이의 단일 인터페이스로 포워딩에 대한 오케스트레이팅을 수행할 수 있다.

물론, 중앙 집중화된 컨트롤러는 또 다른 주의점을 가지고 있다.

  • 하나의 컨트롤러는 전체 네트워크의 단일 장애점(Single Point of Failure)이 될 수 있다. 그러므로 동기화와 리던던시 확보를 위한 멀티호밍이 요구된다.
  • 중앙 집중화된 컨트롤러는 좋은 공격 대상이다. 만약 당신이 컨트롤러를 지배할 수 있다면, 네트워크 전체를 가진 것과 같다.
  • 컨트롤러에서 스위치로의 FIB 업데이트는 일시적으로 비일관적인 포워딩을 만들 수 있고, 따라서 마이크로 루프가 발생할 수 있다. 물론, 동일한 문제점이 하드웨어적으로 제어 평면과 전송 평면이 분리된 라우터들에서도 나타난다. 하지만 ‘지리적으로’ 멀리 떨어지게 되면 문제가 더 커질 것이다.

주로 언급되는 장점으로 관리자가 네트워크 변경을 매우 빠른 시간에 적용할 수 있다는 것이 있다(buzzword로는 Network Agility라 한다). 컨트롤러에 변경사항이 적용되면, 컨트롤러가 스위치들에게 포워딩 규칙들을 전송하고, 네트워크를 구성한다. 관리자는 개별 스위치들을 설정할 필요가 없으며, 벤더별 명령어들을 외울 필요도 없다.

 

OpenFlow란 무엇인가?

 

네트워크의 모든 스위치들에 탑재된 OS의 명령어들을 컨트롤러에 입력하는 것은 거의 불가능하다. 하나의 벤더에서 나온 스위치들도 여러 OS를 가지고 있으며, 각각의 OS에 따라서 명령어들에 약간, 혹은 아주 많은 차이가 있다. 예를 들어 Cisco Systems의 경우, 대형 네트워크를 모두 Cisco사의 장비로 구축할 때 당신은 IOS, IOS-XR, CAT-OS 그리고 NX-OS를 운용하게 될 것이다. 이 OS들은 모두 각각 다른 기능을 지원하고, 다른 명령어 문법을 가진다. 여기에 배포된 소프트웨어의 종류와 버젼에 따른 차이를 고려하면 문제는 더욱 복잡해진다. 그리고 당신이 네트워크 장비를 구매하려고 할 때 -이더넷 스위치 뿐만 아니라, 라우터, 방화벽, 로드 밸런서, 웹 가속기, NAT, WAN 옵티마이저, 터널 서버, IDS/IPS 등등- 이 모든 장비들이 하나의 벤더의 제품일 가능성은 거의 없다.

그러므로 스위치와 컨트롤러 사이에는 반드시 개방된 통신 표준이 필요하다. 여기서 바로 OpenFlow가 등장한다.

OpenFlow는 다음과 같은 사항을 정의한다.

  • 스위치의 포워딩 동작을 정의하는 flow instruction들
  • 컨트롤러의 변경 사항을 스위치에서 수신하기 위한 메시지들
  • Instruction과 메시지를 담는 포맷
  • 컨트롤러와 스위치 사이에서 메시지를 주고 받기 위한 프로토콜

 

고수준에서는 OpenFlow는 다음과 같은 컴포넌트로 이루어져 있다

  • 컨트롤러
  • 스위치의 OpenFlow 인터페이스
  • 컨트롤러와 스위치 사이의 보안 채널
  • Flow instruction들로 이루어진 flow table

이것들은 OpenFlow를 구성하는 가장 기본적인 요소에 불과하다. 3장에서 OpenFlow의 세부 구성요소와 프로세스, 메시지 구조를 다룰 것이다. 하지만 SDN 아키텍쳐에서의 OpenFlow를 이해하는 것에는 이러한 고수준의 정의만으로 충분할 것이다.

이를 요약하자면 다음과 같다.

“OpenFlow는 제어 평면이 데이터 평면에게 포워딩 동작을 지시할 수 있게 해 주는 둘 사이의 통신 프로토콜이다.”

 

그리고 OpenFlow를 이해하는 것에는 ‘OpenFlow란 무엇인가?’만큼이나 ‘OpenFlow는 무엇이 아닌가?’도 중요하다.

  • OpenFlow는 컨트롤러와 스위치의 상세를 정의하지 않는다. OpenFlow는 오직 둘 사이의 통신 규약만을 정의할 뿐이다.
  • OpenFlow는 데이터 평면과 제어 평면을 제외한 다른 어느 곳에서도 동작하지 않는다. OpenFlow는 SDN 아키텍쳐에서 한 부분을 뚜렷하게 차지하고 있다.
  • OpenFlow는 네트워크 자신이나 네트워크의 구성 요소들을 만들어내지 않는다. OpenFlow는 오로지 데이터 평면의 포워딩 동작만 제어할 뿐이다.
  • 제어 평면과 데이터 평면이 통신하기 위한 수단으로 OpenFlow만 있는 것은 아니다. OpenFlow를 대체하기 위한 기술들로는 NETCONF, XMPP, BGP, OVSDB(OpenvSwitch Database Management Protocol), 그리고 시스코의 One’s PK가 있다.

OpenFlow와 마찬가지로, 이들 중 많은 수가 공개 표준이다. -다중 벤더 지원과 API 개발 및 개선을 위하여- 하지만 OpenFlow는 이 점에 있어 다른 솔루션들을 크게 앞서는데, 넓은 범위의 벤더 지원과 그들의 강력한 개발 커뮤니티 덕분이다. 또한, OpenFlow는 거의 모든 다른 대체제들과 비교하여 Flow Instructions를 스위치의 FIB나 TCAM에 직접 입력할 수 있다는 장점이 있다. 대부분의 솔루션들은 로컬 노드의 OS와 통신하여 기능을 구현한다. 이 점에 있어 다른 대체제들이 개별 노드로부터 제어 평면을 없애는 것에 실패하였다는 입장과, SDN이건 아니건 스위치 OS는 일정 부분의 제어 기능을 가지고 있어야 한다는 입장 사이에서 논쟁이 이어지고 있다.

 

간단한 SDN 아키텍쳐

‘SDN과 OpenFlow란 무엇인가’에 대해 어느 정도 답변이 되었을 것이다. 이제, 우리는 “왜”라는 질문에 답해야 한다. 설득력 있는 적용 사례 없이는, 최고의 기술적인 솔루션이라도 고독한 최후를 맞이하게 될 것이다.

SDN에 대한 공감대는 ‘오늘날의 평면들(Planes)을 우리가 어떻게 제어할 것인가’ 에서 출발한다. 데이터 평면은 반드시 분산되어야만 한다. 우리는 출발지와 목적지 인터페이스를 최대한 가까이 위치시켜야 한다. 하지만 우리의 현 세대 장비들은 하나의 샤시에 통합되었거나 분리된 컨트롤러가 붙어 있다. 그러므로, 제어 평면 또한 데이터 평면 노드와 같은 장소에 분산되어 위치한다. 이 말은 라우팅, CoS, 보안, 루프 회피, 장애 복구 등의 제어 평면 기능을 네트워크 사이에서 수행하는 일이 매우 복잡해진다는 것을 의미한다. 최악의 경우, 네트워크에 n개의 노드가 있을 때 모든 노드는 반드시 다른 모든 노드와 통신해야만 하며, n2-n의 간접 연결이 필요해진다.

OSPF를 예시로 들어보자. 각 노드로부터 다른 노드까지의 최단거리 트리를 계산하는 OSPF의 알고리즘은 간단하고 빠르다. OSPF의 복잡성은 모든 연결이 신뢰성 있는 adjacencies를 성립해야 하며, Link-State Database(LSB)를 구성하고 인접 라우터와 LSB를 동기화해야 한다. 그리고 현 시점에서 데이터베이스 엔트리가 모두 정확해야 한다는 것에 기인한다. OSPF의 n 제곱 복잡도는 area를 설정하는 것으로 경감될 수 있다. 하지만 이 경우 라우팅 정보의 정확성을 어느 정도 희생하게 된다. 링크 상태의 변경에 대한 알림이 네트워크 전체로 전파되는 것에는 시간이 걸리며, 그 동안 블랙홀과 마이크로 루프가 발생할 수 있다.

네트워크의 모든 노드들이 링크 상태를 다른 모든 노드로 전파하는 것 대신 중앙 집중화된 컨트롤러로 직접 정보를 전달한다고 가정해 보자. 컨트롤러는 변형된 SPF 계산을 수행하고, 다른 노드의 FIB를 직접 갱신한다. 이 경우 단 하나의 컨트롤러만이 존재하기 때문에 복잡한 컨트롤러간 동기화를 수행할 필요가 없다. 또한 네트워크에 단 하나의 제어 평면이 존재하기 때문에 마이크로 루프와 블랙홀은 감소한다. 그러므로 FRR(Fast Reroute)나 LFA(Loop-Free Alternates)와 같은 제어 평면이 재수렴을 수행하는 동안 트래픽을 우회시키기 위한 기술들의 필요성이 줄어든다.

이 시나리오는 완벽함과는 거리가 있다. 중앙 집중화의 효율성은 네트워크의 지리적 크기가 점점 커짐에 따라 감소하고, 복잡도는 중복 컨트롤 노드들이 분산되어야 함에 따라 증가한다. 그리고 컨트롤러와 스위치 간의 직접 통신에 따르는 비용은 두 장치 간의 거리에 비례하여 늘어난다.

그럼에도 불구하고, SDN 솔루션을 검증하고 도입을 계획할 강력한 인센티브들이 있다.

  • CAPEX 감소: 대부분의 고성능 스위치에 들어가는 비용은 제어 평면에서 나온다. 특수한 서버와 별반 다를 것이 없는 하드웨어가 아니라, 컨트롤러에 포함된 네트워크 OS의 가격 때문이다. 이 소프트웨어는 개발에 수 만 시간이 들었고,  -한 네트워크 장비 제조사는 그들의 OS를 자신들이 축적해온 경험의 저장소라고 칭했다- 이 비용은 반드시 회수되어야만 한다. 중앙 집중화된 컨트롤러는 새 네트워크 노드를 구입할 때마다 비용을 지불하는 것이 아닌, 단 한번의 비용 지출만 이루어지면 된다는 것을 의미한다.
  • OPEX 감소: 운영은 IT 예산에서 언제나 가장 큰 비중을 차지해 왔다. 인적 자원은 비싸다. 하지만 네트워크의 모든 장비들을 다루는 것이 아닌, 단 하나의 제어 평면만을 설정하는 것으로 충분하다면 비용은 절감될 것이다. -특히 다수의 CLI와 OS가 존재하는 환경에서는 더 긴 교육 기간을 가지게 된다-
  • 신뢰성 증대: 사람의 직접적인 조작은 네트워크 단절의 주된 원인이다. 그리고 설정 실수의 가능성은 설정해야 하는 장비들의 개수와, CLI의 종류에 비례한다. SDN 컨트롤러는 이러한 설정의 일정 부분을 자동화시키고, 일관성을 보장해 준다. 그리고 사람의 조작에 대한 가이드라인들의 모음인 운영 정책이나 절차는 매우 중요하지만 만들고 유지하는 데에는 비용이 많이 들어간다는 것도 특기할 법 하다. SDN은 이러한 정책과 절차의 중요성을 감소시켜 신뢰성을 높이고 운영 비용을 감소시킨다.
  • 작업 흐름(Workflow) 통합: 특히 데이터 센터에서 네트워크 재설정은 가상화 워크플로우와 서버/스토리지/애플리케이션의 이동성에 방해물이 된다. SDN은 네트워크를 가상화 관리에 통합시키는 것으로 시작했다.
  • 민첩성: SDN은 새로운 서비스를 도입하거나 서비스 프로파일을 변경하는 것에 드는 시간을 감소시킨다. 그러므로 클라우드 서비스가 더 에자일해지는 것에 따른 이점이 있다.
  • 접근 제어: SDN은 L2/L3 환경에서 집중화된 정책 적용을 가능케 한다. 또한 컨트롤러도 REST API를 통해 L4-7의 동적인 정책 제어와 변동하는 애플리케이션 요구에 통합적으로 대응하는 것이 가능하다. 그러므로 애플리케이션 주도의 네트워크에 좀 더 가까지 다가갈 수 있다. 여기에 대해서는 이 챕터의 뒤에서 좀 더 자세하게 다룬다.

 

구체적인 사례: 차세대 데이터 센터

 

SDN은 스탠포드와 다른 몇몇 대학들이 네트워크 기술을 개발하기 위하여 만든 학술 네트워크로부터 시작되었다. 챕터 5,6에서는 다양한 SDN 적용 사례들을 알아본다. 하지만 지금, SDN은 데이터 센터에서 압도적으로 많이 적용되고 있다. 그 이유를 찾는 것은 어렵지 않다. 수 년 전까지만 해도 대부분의 데이터 센터 네트워크는 15년도 더 된 기술들과 싸우고 있었다. 데이터 센터 엔지니어에게 있어 가장 독한 놈은 바로 STP(Spanning Tree Protocol)이었다 -넓은 의미에서는 여전히 문제가 된다-. L2 토폴로지의 빽빽한 연결 사이에서 루프를 방지하기 위해 개발된 STP는 리던던시를 위해 50% 이상의 대역폭을 차단했고 끔찍한 장애 복구 시간과, 잘못된 설정에 취약했다.

수 년간 이러한 부작용을 감소시키기 위해 많은 STP의 개량형들이 등장했다.

  • RSTP(Rapid Spanning Tree Protocol, 802.1w): 30-50초씩 걸리던 STP의 장애 복구 시간을 약 6초로 줄였다. -하지만 밀리초에서 마이크로초 단위의 정밀도가 필요한 곳에서는 여전히 수용 불가능하다-
  • MSTP(Multiple Spanning Tree Protocol, 802.1s): 다른 VLAN그룹끼리 독립된 스패닝 트리를 구성함으로써 자원 활용성을 높였다.
  • LACP(Link Aggregation Control Protocol, 802.1ax): 다수의 병렬 링크를 묶어 STP가 마치 그것들이 단일 링크인 것 처럼 취급하게 한다.
  • SPB(Shortest Path Bridging, 802.1aq)와 Transparent Interconnection of Lots of Links(TRILL): 최단 경로 우선 알고리즘을 L3에서 적용하여 루프 방지, 장애 복구 시간의 감소를 이루었다.

SPB와 TRILL을 제외한 모든 프로토콜들이 문제가 있는 프로토콜(STP)를 임시로 때워놓은 것에 불과하다. 여기서 한 가지 사실을 고려해보자. ‘토폴로지에 트리가 없으면, 스패닝 트리도 필요없다’. 이것이 바로 최근 몇년 사이 몇몇 벤더들에 의해서 소개된 스위칭 패브릭의 목표이다.

벤더별로 스위치 패브릭의 적용 방법이 각각 다르긴 하지만, 기본적인 개념은 동일하다. 평평한, 가상화된 데이터 평면을 만들어 데이터 센터 내의 모든 TOR(Top of Rack), EOR(End of Row)스위치를 단일 스위치에 연결된 것 처럼 만든다. 모든 물리 또는 가상 스위치의 포트들은 하나의 스위치 패브릭에 속한다.

데이터 센터가 가상 스위치 패브릭으로 이전하는 것에는 그 외에도 많은 이유가 있으나, 간략한 논의의 범주를 벗어나기에 다루지 않는다.  우리의 논의에 있어서 핵심은 L2 데이터 평면이 서로 연결된 스위치에서 가상화된 단일 스위치로 진화하였다는 것이다. 이 스위치는 여전히 다수의 물리 장치로 구성되어 있다. 하지만 스위치들은 하나의 스위치처럼 동작하고 관리된다. 다시 말해, 데이터 평면은 ‘추상화되었다’. 우리는 이제 전체 데이터 평면을 한번에 운용할 수 있게 되었다.

 

-가상화와 추상화

 

가상화에 대한 이해 없이는 데이터 센터에서 살아남을 수 없다. 만약 당신이 네트워크 기술자라면 언제나 가상화와 대면하게 될 것이다: 가상 회로, 가상 LAN, 가상 사설 네트워크, VRRP, VRF, VPLS 등등. 모든 경우에서 가상 네트워크의 본질은 진짜처럼 보이는 것이 사실은 진짜가 아니라는 것이다. 그것은 백그라운드에서 동작하는 물리적 장비들에 의해서 만들어지고, 나타난다. 예를 들어 VRRP(Virtual Router Redundancy Protocol)의 경우, 호스트에게는 하나의 라우터가 존재하는 것 처럼 보이지만, 이 라우터는 사실 존재하지 않는다. 대신 둘 이상의 실제 라우터가 서로를 감시하고 있으면서, 호스트로부터의 업스트림 경로가 언제나 유지되도록 한다. 달리 말해, VRRP 토폴로지의 실제 라우터들은 가상 라우터로 추상화되어서 호스트에게 노출된다. 호스트의 트래픽은 실제 라우터들에 의하여 처리되지만, 토폴로지 장애는 호스트에게 감춰진다. 백업 라우터가 가상 라우터의 일을 넘겨받아 포워딩을 계속 수행한다.

이 사례로부터 심지어 기능과 서비스에 대해 심지어 그것들이 변동되더라도 사용자에게 일관성 있는 시점을 제공해 주는 추상화가 가지는 이점을 확인했을 것이다.

 

이 모든 것은 다음과 같은 결론을 이끌어낸다: 만약 추상화가 우리에게 통합된 데이터 평면을 제공한다면 제어 평면 또한 통합되어 추상화되어야 할것이다. 그리고 이 챕터의 시작 부분에서 다뤘던 SDN의 2번 정의에 가까워졌다:  ‘SDN은 네트워크를 추상화되어 동작하게 하는 개념적인 프레임워크이다’

이것은 또한 우리를 첫번째 정의로부터 멀어지게 만들었다. 우리가 SDN을 중앙 집중화된 컨트롤러라고 생각하는 동안은 개별 서버와 장비들, 혹은 심지어 중앙 집중화된 서버와 장비들에 대해서도 SDN은 필요하지 않았다. 이제, SDN은 네트워크 인터페이스로 기능하는 소프트웨어의 집합체이다.

그러나 우리는 이 일반화로부터 더 나아갈 수 있다.

 

프로그래밍 가능한 네트워크를 향하여

 

오퍼레이터는 관리 평면을 통하여 스위치와 라우터의 제어 평면에 접근한다. -CLI, GUI, SNMP, XML 기반 API 등등-  설정을 변경하고, 통계를 모으고, 장치들을 모니터링한다. 간단히 말해, 관리 평면은 오퍼레이터와 제어 평면이 서로 통신하기 위한 방법이다.

우리는 이미 그 방법을 보았다. 하부의 데이터 평면이 추상화되고, SDN 제어 평면은 오퍼레이터가 개별 네트워크 장비들과 직접 상호작용할 필요성을 없앴다. 그리고 OpenFlow와 같은 “Southbound” 프로토콜은 데이터 평면과 상호작용하기 위하여 오퍼레이터 혹은 제어 평면 자신이 벤더별 언어를 익힐 필요를 없엤다.

이와 비슷하게, 추상화된 제어 평면은 일반화된 “Northbound” API를 관리 평면에 제공한다. 오퍼레이터는 이 단일 인터페이스를 통하여 전체 네트워크를 프로그래밍하고 정보를 얻을 수 있다. 이것의 중요성을 이해하기 위하여, 다시 데이터 센터의 진화로 돌아가 보자.

현대 데이터 센터에 있어 가상화는 거의 당연한 일이다. 서버와 스토리지는 급격히 변하는 요구에 맞추어 그때그때 만들어지고, 변경되고, 이동한다. 만약 데이터 센터가 그 자체로 사업이라면-예를 들어 클라우드 프로바이더의 경우- 에자일한 이익 중심점의 오케스트레이션은 사업 성공을 위하여 반드시 필요한 일이다. Puppet, Salt, Ansible, Chef, CFEngine과 같은 설정 관리 툴은 수만대의 서버에 대한 반복되는 오케스트레이션 작업을 자동화시켰다. 그렇지만 이들은 여전히 진짜 프로그래밍 언어 – 배포와 관리 작업 루틴을 기술할 수 있는- 가 아니다. 이 프로그램들은 단지 모든 디바이스들에게 한번의 CLI 명령으로 설정을 적용할 수 있는 방법을 제공할 뿐이다. 당신은 한 곳에서 어떠한 일이 일어날 것인지를 정의하고, 당신의 명령은 네트워크 전체에서 실행된다.

그리고 서비스 유래 인프라의 배포와 관리를 위해 가상화된 데이터 센터를 제어하는 관리 수트가 있다. 이들 중 널리 알려진 것으로 OpenStack이 있는데, 클라우드 서비스를 배포하기 위하여 사용된다. OpenStack은 오퍼레이터가 자신들의 클라우드를 관리할 수 있게 할 뿐만 아니라 사용자가 직접 서비스를 프로비져닝하고 관리하는 것을 가능케 한다. OpenStack은 계산, 스토리지, 네트워킹을 관리하는 소프트웨어와 그것들을 오케스트레이팅 하기 위한 대쉬보드로 구성되어 있다. 그 외에도 여러 클라우드 오케스트레이션 수트들이 있으나, 오픈 스택의 강력한 공개 지원과 개발 커뮤니티 때문에 대부분의 대형 클라우드 프로바이더들은 오픈 스택을 사용한다.

OpenStack의 유명세가 부분적으로 OpenDaylight 커뮤니티에 의해 개발된 오픈 소스 SDN 컨트롤러에 영향을 끼친 것은 의심의 여지가 없다. 다음 그림에서 OpenDaylight 컨트롤러가 데이터 평면과 OpenFlow, BGP, LISP, NETCONF, 그리고 몇 가지 다른 방법으로 통신하는 것을 볼 수 있을 것이다. Northbound로는 유저와 컨트롤러가 GUI, CLI를 통해, OpenStack 과는 Neutron을 통해 통신하는 것을 알 수 있다.

여기서 예시로 든 것은 OpenDaylight 컨트롤러에 대한 선전이 아니다. -폐쇄된, 혹은 공개된 다른 많은 컨트롤러들이 있다- 단지 이 예시는 데이터 평면과 제어 평면이 프로그래밍을 위하여 어떻게 추상화되지는지를 보여주기 위한 것이다.

물리적, 논리적 토폴로지 디자인을 포함한 전통적 네트워킹에서 네트워크 노드간의 케이블 설치와 설정은 당신의 설계에 따라야 한다. 그것은 정적인 모델이다: 만약 네트워크 동작을 바꿔야 한다면 개별 노드들을 다시 찾아 재설정 해야 할 것이다.

SDN은 제어 평면에게 당신이 “If, Then, Else” 명령어를 이용하여 데이터 평면에서 적절한 명령어를 실행하도록 할 수 있다. 이런 프로그램적 접근은 당신의 네트워크를 더 에자일하고, 적응적이고, 동적으로 만들어 줄 것이다. 그리고 이것이 우리가 추상화에 역점을 두는 이유이기도 하다. 추상화에 의한 유용하고 편리한 프로그래밍 기술 말이다. SDN의 경우, 우리는 네트워크의 모델을 프로그래밍 한다. 그리고 컨트롤러가 그것을 실제로 적용한다.

우리는 이제 두번째-그리고 더욱 정확한- SDN의 정의에 완전히 도착했다. 그러니 여기서 다시 한번 살펴보자: SDN은 개별 네트워크 구성 요소들을 최소한의 조작만으로 프로그래밍 할 수 있는 추상화된 네트워크를 위한 개념적인 프레임워크이다.

 

네트워크 기능 가상화

 

“소프트웨어 정의 네트워크”라는 용어는 마치 그것이 네트워크의 구성요소나 기능을 정의하는 것 처럼 들린다. 이건 이해할 수 있는 오해지만, 실제로 SDN이 동작하는 방법을 흐리게 만든다. 더 명확하고 간단한 다른 용어로 NFV(Network Function Virtualization)이 소개되었다. NFV는 두 가지 측면을 갖는다.

  • NFV는 VPN, VRF, 터널, QoS와 보안 정책, VLAN, 오버레이 등의 네트워크 기능을 정의한다.
  • NFV는 소프트웨어적으로 기존의 물리 네트워크 장비였던 라우터, L2 스위치, 방화벽, 로드 밸런서, IDS/IPS, WAN 가속기 등을 정의한다.

여기에 맡은 일의 명확한 차이점이 있다.

  • SDN은 flow를 프로그램 한다.
  • NFV는 네트워크 기능을 프로그램 한다.

보통, 이건 항상 명확한 것은 아니다. 이 둘 사이에는 트래픽 엔지니어링과 같은 여러 모호한 영역이 존재한다. 우리는 네트워크 흐름을 프로그래밍 해서 TE를 달성해야 할까? 혹은 논리적 경로를 프로그래밍 해서 달성해야 할까? SDN과 NFV는 누구도 이 질문에 대답할 수 없을 정도로 새로운 기술이다. 왜냐하면 이 기술들은 여전히 진화중이고 산업계 또한 아직 믿을 수 있는 정의를 찾지 못했기 때문이다. 하지만 SDN과 NFV의 개발 목적은 빠르게 변화하고 있고, 조만간 산업계가 좀 더 정확한 정의를 만들어 낼 수 있을 것이다.

당신은 이러한 정의에 동의하지 않는 사람을 쉽게 찾을 수 있을 것이다. 하지만 괜찮다. 우리가 이 책에서 이야기하고자 하는 부분은 오로지 차이점만 알고 있으면 된다.

 

-유전적 다양성

흥미롭게도 SDN과 NFV는 다른 유산을 가지고 있으면서 서로 보완적이다. SDN은 학계로부터 시작하였고 빠르게 데이터 센터에 적용되었다. 이제 SDN은 데이터 센터에서 WAN, 전화, 이동통신, 서비스 공급자망으로 이동하고 있다

한편, 대형 통신사업자와 전화 사업자들은 ETSI를 통하여 NFV를 발족시켰다. 그것의 유전자는 전화에 뿌리를 두고 있다. 하지만 NFV 응용은 빠르게 데이터 센터와 클라우드 제공자망으로 이동중이다.

SDN과 NFV는 서로 별개로 사용될 수 있다. 하지만 함께일 때 그것들은 우리가 네트워크를 구축하고  운용하는 방식을 바꾸어 놓을 것이다.

 

SDN은 파괴적인 기술인가?

 

SDN과 NFV는 네트워크의 혁신적인 변화를 위한 촉매이다. 우리는 추상화되고, 가상화되고, 노드간의 개별 링크가 아닌 그것들을 실어 나르는 흐름(flows)를 다루는 세계로 나아가고 있다. 다년간 우리는 네트워크를 구름으로 표현했다. 그리고, 지금 구름이 여기 있다.

SDN은 그저 파괴적인 기술이 아니다. 우리가 TCP/IP의 출현에서 본 것과 같이 SDN은 아주 파괴적인 기술이 될 것이다.

 

혼란스러운 기능들

SDN은 다른 훌륭한 네트워크 관리 시스템이 그렇듯이, 그저 우리가 네트워크와 상호작용하는 방법을 바꾸지만은 않을 것이다. SDN은 우리가 네트워크를 바라보는 시각을 노드끼리 서로 연결된 그래프에서 종단점 사이의 흐름군(system of flows)으로 바꾸었다. 우리는 더 이상 개별 기기 및 연결과 상호작용하지 않는다. 대신 네트워크 전체와 상호작용한다.  여기에 NFV를 더하면, 개별 네트워크 기능들이 물리 장치에서 가상 기능들로 바뀔 것이다.

 

혼란스러운 재무 모델들

시장 지배적 위치에 있는 라우터나 스위치 벤더는 자신들의 제어 평면 소프트웨어에 심도 있는 기술적 투자를 한다. 그리고 당신이 라우터나 스위치를 구매할 때마다 당신은 같은 소프트웨어를 구매하면서 벤더들의 투자비용 회수에 기여한다.

SDN은 이 모델을 바꾼다. 네트워크 OS를 위해서 단 한번만(혹은 몇 번) 비용을 지불하면 되고, “베어 메탈” 기기를 이용하여 OS 없이, 혹은 최소한의 OS만으로 당신만의 데이터 평면을 구성할 수 있다.

 

이러한 관점에서 보았을 때, 시장 지배적 기업이 SDN에 대한 논의를 제어하고, SDN을 재정의하고, 주제를 완전히 바꾸려고 하는 이유는 매우 명백하다.

 

혼란스러운 능력들

우리는 이미 데이터센터의 가상화가 직무 설명과 능력들을 어떻게 혼란시키는지 보았다. 한 때 애플리케이션 개발자와 오퍼레이션 엔지니어는 다른 직업이었다(그리고 때때로 서로 다투기도 했다). 그리고 가상화는 이 둘을 DevOps로 묶었다 -개발자는 계산과 스토리지 리소스를 Operations 전문가 없이 사용할 수 있게 되었다-

지금의 DevOps에서는 네트워킹에 대한 내용이 빠져있다. 그리고 SDN이 그것을 바꿀 것이다. SDN과 NFV의 범위에 따라 가상화된 네트워크 구성요소와 제로-터치 프로비져닝을 가능하게 한다. “CLI Jockeys”-엄격하게 검증된 벤더 전용 네트워크 OS-는 필요성이 줄어들 것이다.

네트워킹은 애플리케이션과 더 긴밀하게 통합되고, 네트워크 엔지니어는 네트워크 프로그래머가 될 것이다.

 

애플리케이션 정의 네트워크를 향하여

 

SDN과 NFV는 궁극적인 파괴를 이끌 수 있을 것이다. 네트워크에 대한 인간의 간섭을 완전히 막는 것이 바로 그렇다. 네트워크를 설계하고, 구축하고, 유지하는 것 뿐만이 아니라 애플리케이션에 맞춰 네트워크를 적용하거나 그 역에 이르기까지 말이다.

생각해보자, 지금은 “인간 계층”이 네트워크와 애플리케이션 사이에서 중재자 역할을 하고 있다. 우리는 어떠한 애플리케이션이 돌아갈지 분석하고, 어떤 네트워크 자원이 사용 가능한지, 그리고 최대한 타협하여 설정한다. 지금은 SDN과 NFV가 프로그램 가능한 패러매터와 모인 네트워크 정보를 기반으로 오케스트레이션을 수행할 수 있다. SDN이 완전히 자리를 잡으면, 우리는 애플리케이션 계층이 오케스트레이션 계층과 직접 상호작용하도록 만들 수 있을 것이다.

우리는 이미 네트워킹을 아는 애플리케이션을 가지고 있다-적어도 어느 정도는-. 하지만 그건 앞뒤가 바뀐 것이다. 네트워크가 애플리케이션을 지원하기 위해 존재하는 것이 더 낫다. 네트워크는 애플리케이션을 모니터하고 무엇이 필요한지 추론한다. 혹은 애플리케이션이 네트워크에게 무엇이 필요한지 직접 이야기하거나?

실시간으로 애플리케이션 요구 사항에 맞추어 동적으로 조정하는 네트워크를 상상해 보라. 애플리케이션 정의 네트워크는 SDN 이후의 파괴적인 물결이 될 수 있을 것이다.

 

결론

 

이 챕터에서는 SDN의 기본적인 내용을 알아보았다. 제어 평면과 데이터 평면을 분리하는 것이 SDN의 핵심이며, 이것을 이루는 방법에는 여러가지 길이 있다는 것을 아는 것은 중요하다.

이 챕터를 읽은 뒤, SDN과 NFV에 의해 탄생한 사업 케이스들이 있다는 것은 매우 명백하게 보일 것이다. 데이터센터는 명백히 더 나은 스케일 능력과 리소스 사용을 보여주었고, 서비스 제공자들은 NFV를 부가가치 서비스와 조직의 이윤 창출에 활용할 수 있었다.

이 책의 나머지 부분에서는 공개 SDN의 개념에 초점을 맞출 것이며, OpenFlow 프로토콜의 역사와 기능을 자세히 다룰 것이다.

CCNA Study – ICMP

 

1. Introduction

ICMP(Internet Control Message Protocol)은 TCP/IP Suite에서 IP에 문제가 생겼을 때, IP 자신은 오류를 보고하고, 연결을 제어할 수 있는 기능이 없기 때문에, 이를 보조하기 위하여 만들어진 프로토콜이다.

ICMP는 RFC 792에서 처음으로 정의되었으며, 관련된 다른 RFC로는 RFC 1122, RFC 1812가 있다. 현재는 IPv6에 대응하는 ICMPv6가 나왔기 때문에 이전의 ICMP는 ICMPv4로 불리게 되었다.

ICMP는 IP 의 상위에서 캡슐화(Encapsulation)되어 동작하기 때문에 기본적으로 IP에 대해 의존적이지만, 실질적으로 IP가 잘 동작하려면 ICMP의 보조가 반드시 필요하기에 이 둘은 상호 보완적인 관계라고 볼 수 있다.

 

2. ICMP 패킷의 구조

ICMP 패킷은 다음과 같은 구조를 가진다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 1. Type (1 Byte): ICMP 메시지의 타입을 지정하는 필드로, 자세한 내용은 나중에 다루겠다.

2. Code (1 Byte): ICMP 메시지 타입에 따른 하위 타입을 지정하는 필드로, 이것 또한 뒤에 다루겠다.

3. Checksum (2 Byte): ICMP 헤더의 무결성을 검증하기 위해 사용된다.

4. Data (N Byte): ICMP 메시지의 실제 데이터로, 길이는 타입과 코드에 따라 달라진다.

2-1. ICMP Type

ICMP 메시지의 타입(Type)에는 다음과 같은 것들이 있다.

All Rights Reserved IANA
All Rights Reserved IANA[1]
 

이 중에서 Deprecated된 타입을 제외한 Type 0, 3, 4, 5, 8, 9, 10, 11, 12에 대해 알아보자.

 

Type 0: Echo Reply 메시지를 나타낸다. Echo Reply는 Echo에 대한 응답으로, Identifier와 Sequence Number를 포함한다. RFC 792에 따르면 Identifier는 세션 구별을 위한 포트 넘버와 같은 것들이 들어가고, Sequence Number는 TCP의 그것과 동일하다.

 

Type 3: 목적지 도달 불가 메시지를 나타낸다. 이 메시지는 1바이트의 코드(Code) 값을 갖는데 이는 다음과 같다.

Typ3-Code

이 중에서 Code 0은 목적지 네트워크에 도달할 수 없음을 알리고(주로 라우팅 테이블 불일치), Code 1은 목적지 네트워크에는 도달했으나, 목적지 호스트에는 도달할 수 없었음을 말한다.

그리고 Code 4는 주로 링크 상의 최대 MTU를 찾는 용도로 사용된다.

 

Type 4: 발신지 억제 메시지를 나타낸다. IP는 데이터 전송 속도를 제어하는 흐름 제어 기능을 갖지 않고 있기 때문에(Best Effort) 라우터가 자신이 처리 가능한 용량을 넘어서는 패킷을 받는 경우(e.g Ingress Buffer Overflow) 나머지 패킷들을 폐기시켜야 하고, 패킷을 폐기할 때 그 패킷을 송신한 호스트에게 Source Quench 메시지를 전송한다.

그러나 폐기되는 모든 패킷에 대해 전송되는 메시지의 특성 상 이 메시지를 수신하더라도 호스트는 자신이 혼잡을 유발하고 있다고 단정지을 수 없다.

 

Type 5: 재지정 메시지를 나타낸다. 목적지로 데이터를 전송하는 경로 상에 있는 라우터가 해당 목적지로 가는 더 나은 경로가 있음을 알리기 위해 사용된다.

Type 5에는 2가지의 코드(Code)가 있는데, 이는 다음과 같다.

Typ5-code

Code 0: 네트워크 재지정. 해당 목적지 네트워크로 가는 모든 패킷의 경로를 재지정할 것을 권고한다.

Code 1: 호스트 재지정. 해당 목적지 호스트로 가는 패킷의 경로를 재지정할 것을 권고한다.

 

Type 8: Echo 메시지를 나타낸다. 이 메시지를 수신한 호스트는 발신자 주소를 목적지로 하여 Echo Reply 메시지를 전송한다.

Type 9, 10: IRDP (ICMP Router Discovery Protocol)에서 사용하는 메시지이다. 이것은 RFC 1256에서 정의되었으며, Type 9는 RS (Router Solicitation) 메시지, Type 10은 RA (Router Advertisement) 메시지이다.

각각의 패킷 구조는 다음과 같다.

RA Message

RA_Msg

RS Message

RS_Msg
All Rights Reserved ktworld.co.kr

이 때 IRDP 메시지는 Multicast 주소(224.0.0.1)로 전송되거나, Broadcast 주소를 사용한다. (Cisco는 기본적으로 Broadcast)

IRDP를 사용하는 라우터는 자신이 네트워크에 연결되었을 때 RS를 전송하고, 주기적으로 RA를 전송한다. 또한 RA는 RS에 대한 응답으로써 전송될 수도 있다.

 

Type 11: 시간 초과 메시지를 나타낸다. 이 메시지는 두 가지 경우에 전송되는데, 하나는 IP 패킷의 TTL이 0이 되었을 때이며, 다른 하나는 단편화 재조합 타이머(Fragment Reassembly Timer)가 만료되었을 경우이다.

여기서 재조합 타이머는 단편화되어 전송되는 패킷 중 일부가 전송 중 손실될 경우, 목적지 호스트가 손실된 패킷의 도착을 영구히 기다리는 상황을 막기 위해 타이머 만료 시간까지 전체 패킷이 도착하지 못했다면 버퍼에서 단편화된 패킷 조각들을 전부 폐기하고, 재전송을 위해 시간 초과 메시지를 보내기 위해 사용된다.

Code 0은 TTL 값의 만료, Code 1은 단편화 재조합 타이머 만료를 나타낸다.

 

Type 12: Parameter Problem. 이 메시지는 IP 데이터그램의 구조에 문제가 있어, 그 패킷을 폐기할 때 전송된다. 또한, Parameter Problem 메시지는 다른 ICMP 메시지에 해당되지 않는 모든 오류에 대해서도 전송되어야 한다.[2]

이 메시지가 가질 수 있는 Code는 다음과 같다.

Typ12-Code-1

Code 0: IP 데이터그램의 구조에 문제가 있음을 나타냄.

Code 1: 필요한 옵션이 정의되지 않음. 미 국방성에서 사용하는 특별한 보안 옵션과 이용됨[3]

Code 2: IP 데이터그램의 Header Length나 Total Packet Length값이 올바르지 않음.

 


각주

 

[1] IANA – ICMP Type Numbers

[2]  RFC 1122 Section 3.2.2.5 – “The ICMP Parameter Problem message is sent to the source host for any problem not specifically covered by another ICMP message.”

[3] RFC 1122  Section 3.2.2.5– “NOTE: This variant is currently in use in the military community for a missing security option.

 

 

CCNA Study – DHCP

 

DHCP (Dynamic Host Configuration Protocol)는 호스트의 네트워크 설정을 쉽게 하기 위하여 개발된 프로토콜이다.

이에 앞서 RARP라는 자동 IPv4 할당 프로토콜이 있었지만, RARP는 오로지 IP만을 정적(Static)으로 할당받을 수 있었기에 디폴트 게이트웨이, 서브넷 마스크, DNS 서버 주소 등의 통신에 필요한 추가적인 정보를 제공받을 수 있는 새로운 방법이 필요했고, IETF는 RFC 951에서 BOOTP를 정의하여 이 문제를 해결하였다.

그러나 BOOTP는 여전히 IP를 Static하게만 할당할 수 있었고, 유연성 부족과 확장 옵션의 비표준화 등의 문제로 인해 BOOTP를 개량한 DHCP가 RFC 2131에서 새로 정의되었다.

 

그럼, 일반적인 환경에서의 DHCP 동작 알고리즘을 살펴보자.

 

1. 클라이언트는 부팅이 완료된 뒤 UDP 68번 포트로 DHCP DISCOVER 메시지를 보낸다.

2. DHCP 서버는 DISCOVER 메시지를 수신한 뒤 해당 클라이언트에게 DHCP OFFER 메시지를 전송, 자신이 IP를 제공할 수 있음을 알린다.

3. DHCP 클라이언트는 자신이 수신한 OFFER 중 하나를 선택(DHCP 서버가 다수일 경우), DHCP REQUEST 메시지를 브로드캐스팅한다. 이는 자신이 선택한 IP 주소를 알리고, 선택받지 못한 다른 서버들이 IP 주소를 재사용할 수 있게 하기 위함이다.

4. DHCP 서버가 DHCP 클라이언트에게 DHCP ACK 메시지를 전송함으로써 IP 할당이 완료된다.

5. 클라이언트는 자신이 할당받은 IP로 ARP Probe를 전송함으로써 충돌 확인을 한다. 만약 ARP Reply가 돌아오지 않으면 이 IP를 사용하게 된다.

 

앞서 말했듯이 DHCP는 이전에 사용하던 RARP/BOOTP의 부족한 부분을 보완하여 만들어졌다. 또한 여러 상황들에 유연하게 대응할 수 있도록 확장성 있는 구조를 가지는데, 상세 동작을 다루기 위해서는 먼저 DHCP 패킷의 구조를 이해할 필요가 있다.

 

DHCP 패킷은 다음과 같이 구성되어 있다.

 

1. Opcode (1Byte): DHCP 메시지의 타입을 나타낸다. 1은 BOOTREQUEST(요청), 2는 BOOTREPLY(응답)라 한다.

2. Hardware Type (1Byte): L2 Protocol의 유형을 나타낸다. ARP의 그것과 동일하다.

3. Hardware Length (1Byte): 하드웨어 주소 길이를 바이트 단위로 나타낸다.

4. Hop Count (1Byte): DHCP Relay가 사용될 경우 패킷이 중계된 횟수를 나타낸다. 기본값은 0이며, 경유한 Relay Agent마다 1씩 증가한다.

5. Transaction ID (4Byte): 클라이언트가 선택하는 랜덤한 32비트짜리 수이다. DISCOVER와 OFFER를 짝짓는데 사용한다.

6. Number of Seconds (2Byte): 임대 획득/갱신 이후 경과한 시간을 나타낸다.

7. Broadcast Flags (2Byte): 첫번째 비트가 0이면 응답 메시지를 유니캐스트로, 1이면 브로드캐스트로 전송한다.

8. Client IP Address (4Byte): 클라이언트의 IP 주소를 나타낸다. 최초 요청시에는 IP가 할당되지 않았으므로 0.0.0.0이 들어간다.

9. Your IP Address (4Byte): 클라이언트에게 할당되는 IP 주소로, 서버의 응답 메시지에 포함된다.

10. Client H/W Address (16Byte): 할당을 요청한 클라이언트의 하드웨어 주소가 들어간다.

11. Server Name String (64Byte): 서버 호스트 이름. 널 문자로 끝난다.

12. Options (가변 길이): DHCP 옵션들을 나타낸다. 최초 4바이트가 0x63, 0x82, 0x53, 0x63으로 되어 있다. 이 ‘Magic Cookie’는 RFC 1497 (BOOTP Extension)에서 정의된 것으로, BOOTP와의 호환성을 유지하기 위해 사용된다.

 

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

 

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

BOOTP 프로토콜과 비교해 보면, 마지막 Option Field만이 약간 달라진 것을 알 수 있다.

DHCP Option Field의 구조는 다음과 같으며, DHCP는 이 Option Field를 이용하여 BOOTP와는 다른 확장 기능들을 구현한다.

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

그러면 이제 DHCP Option들에 대해 알아보자.

실제 사용할 수 있는 DHCP Option은 굉장히 많으나, 이 중 RFC 2132에서 정의된 것은 다음과 같다.

DHCP Option
All Rights Reserved IANA

 

전체 옵션 리스트는 다음 파일을 참조하라.

 options.xlsx

 

이 글에서는 IP  할당 및 임대 갱신에 사용되는 Option 50, 51, 53, 54, 61과 네트워크 통신을 위한 추가 정보를 제공하는 Option 1, 3, 5, 6, 15에 대해 서술한다.

 

Option 1 (Subnet Mask): 해당 클라이언트의 Subnet Mask를 지정한다.

Option 3 (Router): 해당 클라이언트의 Default Gateway를 지정한다.

Option 5 (Name Server): 클라이언트가 사용할, IEN 116에 정의된 네임서버의 주소를 지정한다.

Option 6 (Domain Server): 클라이언트가 사용할 DNS 주소를 지정한다.

Option 15 (Domain Name): 클라이언트의 도메인 이름을 지정한다.

Option 50 (Address Request): DHCP 서버가 클라이언트에게 할당할 IP Address를 지정한다.

Option 51 (Address Time): 할당해줄 IP Address의 임대 만료 시간을 지정한다.

Option 53 (DHCP Msg Type): DHCP 메시지의 타입을 지정한다. 아래의 표를 참조하라.

dhcp_msg

Option 54 (DHCP Server ID): DHCP 메시지를 전송한 서버의 IP 주소를 알린다.

Option 61 (DHCP Client ID): 클라이언트를 식별할 수 있는 식별자가 들어간다. 이 식별자로는 클라이언트의 MAC Address, FQDN 등이 사용될 수 있다.

 

부록

A. DHCP Relay Agent

DHCP의 설정 과정에서 브로드캐스팅이 사용되기 때문에 DHCP의 동작 범위는 기본적으로 하나의 서브넷으로 한정된다. 그러나 대규모 네트워크에서 이러한 구성은 다수의 DHCP 서버를 필요로 하고, 높은 비용을 발생시키며, 관리를 어렵게 만든다.

이에 따라 제안된 것이 바로 DHCP Relay Agent이다.

DHCP Relay Agent는 DHCP 서버와 클라이언트 간의 메시지 전달을 중계하여 DHCP 메시지가 서브넷을 넘어서 이동할 수 있도록 한다.

 

다음으로 DHCP Relay Agent가 어떻게 동작하는지 알아보자.

1. 클라이언트가 DHCP Discover 메시지를 브로드캐스팅한다.

2. Relay Agent는 Discover 메시지를 수신, DHCP 서버로 유니캐스팅한다. 이 때 Giaddr(Gateway Address)에 0.0.0.0 대신 자신의 IP를 기록하여 이 메시지가 Relay Agent로부터 온 것임을 서버에게 알린다.

3. DHCP 서버는 Giaddr 필드의 주소에 맞는 IP 풀을 선택, IP를 할당하고 Relay Agent의 주소로 DHCP Offer 메시지를 보낸다.

4. Relay Agent는 DHCP Offer를 클라이언트에게 중계한다. 이 때 Discover 메시지 안의 Broadcast Flag가 0이면 유니캐스트로, 1이면 브로드캐스트로 전송한다.

 

이것으로 Relay Agent의 기본적인 동작을 알아보았다.

그런데 메시지가 Relay Agent를 지날 때 Giaddr 필드에 Relay 자신의 IP를 기록한다면, 다수의 Relay를 거쳐서 서버로 요청이 전송되는 경우에는 서버가 클라이언트의 IP 대역을 잃어버리게 된다(Giaddr 주소에 근거하여 판단하므로) 따라서 여러 릴레이를 거치는 구성은 불가능한데, 어째서 Hop Count가 존재할까?

나는 이것이 DHCP 패킷이 루핑 등의 이유로 네트워크를 계속 떠돌아다니는 것을 막기 위해서 사용된다고 결론지었다. 실제로 여러 네트워크 회사의 DHCP 서버 설정에 max-hop-count가 존재하기도 하고.

만약 다른 이유가 있거나, 다수의 릴레이를 거치는 구성이 가능하다면 의견을 남겨 주길 바란다.

 

B. APIPA

DHCP 클라이언트가 DHCP를 통한 IP 할당에 실패하는 경우, 클라이언트는 네트워크와의 연결을 위해 APIPA(Automatic Private IP Addressing)을 사용해 169.254.0.0/16의 주소 중 하나를 임의로 할당한다.

APIPA는 RFC3927에서 정의되었고, BOOTP와 마찬가지로 네트워크 구성에 필요한 여러 정보를 얻을 수 없기 때문에 소규모 사설 네트워크에서의 통신에서만 사용될 수 있다.

CCNA Study – ARP Protocol

 


 

목차

1. Introduction

2. ARP 동작 예시

3. ARP의 변형

3-1. Reverse ARP (RARP)

3-2. Inverse ARP (InARP)

3-3. DHCP ARP

3-4. Gratuitous ARP (gARP)

3-5. ARP Probe

3-5.1. ARP Probe의 동작

3-6. UnARP


 

1. Introduction

Ethernet에서 물리 계층 주소(MAC)을 얻어낼 때 사용하는 프로토콜인 ARP에 대해 RFC를 참조하여 알아본다.

ARP는 1982년, RFC 826에 처음으로 정의되었다. 여기서 ARP의 목적은 ‘프로토콜 주소를 로컬 네트워크 주소로 변환하는 방법을 제공하는 것’이라고 밝히고 있다. 즉, 기본적으로 Ethernet을 위해 개발된 프로토콜이긴 하지만, 경우에 따라서 다른 프로토콜 위에서 동작할 수 있으며, 실제로 X.25, HDLC, FDDI, 802.11, ATM 등에서도 ARP를 사용하고 있다. ARP는  STD 37이라는 이름의 인터넷 프로토콜로 승인되었고, RFC 1122에서의 ‘잘못된 ARP Entry에 대한 처리’에 대한 모호함을 보완하였다. (The ARP specification [LINK:2] suggests but does not require a timeout mechanism to invalidate cache entries when hosts change their Ethernet addresses.)[1]

그러면 다시 RFC 826으로 돌아가 ARP가 어떻게 동작하는지 알아보자.
RFC 826에서는 ARP 헤더를 다음과 같이 정의하고 있다.

1. Hardware Address (16bit) – 로컬 네트워크에서 사용하는 하드웨어 타입을 규정한다.

2. Protocol Address (16bit) – 하드웨어 타입 필드를 보완하며, 3계층 프로토콜의 종류를 규정한다. Ethernet의 경우 Ether-type 필드의 값과 동일하다.

3. Hardware Address Length (8bit) – 뒤에 올 하드웨어 주소의 길이를 바이트 단위로 지정한다. 예를 들어 Ethernet은 48bit이므로 6의 값을 갖는다.

4. Protocol Address Length (8bit) – 이 메시지에 포함된 3계층 프로토콜의 주소 길이를 바이트 단위로 지정한다. 예를 들어 IPv4는 4의 값을 갖는다.

5. Opcode (16bit) – 이 ARP 패킷의 목적을 밝힌다. Opcode의 값은 좀 더 뒤에서 다루겠다.

6. Sender Hardware Address (n Byte) – 앞서 말한 길이의 송신자 하드웨어 주소가 온다.

7. Sender Protocol Address – (m Byte) – 앞서 말한 길이의 송신자 프로토콜 주소가 온다.

8. Target Hardware Address – (n Byte) – 앞서 말한 길이의 수신자 하드웨어 주소가 온다. 당연히 ‘알고 있을 경우’에 한하여 기록된다.

9. Target Protocol Address (m Byte) – 앞서 말한 길이의 수신자 프로토콜 주소가 온다.

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

All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

 

2. ARP 동작 예시

Host A가 Host B에게 ARP Request를 보내는 시나리오를 이용하여 일반적인 ARP의 동작을 알아본다.

1. Host A는 이더넷 프레임에 사용할 목적지 MAC 주소를 결정하기 위해 자신의 ARP 캐시 테이블을 확인한다.

2. 캐시 테이블에 MAC 주소가 없다면 Host B의 MAC을 얻기 위해 ARP Request를 Dst-MAC-Addr을 FF:FF:FF:FF:FF:FF로 설정하여 브로드캐스팅한다.

3-1. 동일한 네트워크 세그먼트 상의 시스템들은 모두 이 ARP 패킷을 수신하고, 자신의 Protocol Address와 패킷의 TPA를 비교, 같지 않으면 폐기한다.

3-2. 만약 패킷의 TPA와 자신의 Protocol Address가 일치한다면, 자신의 Protocol Address를 기록한 ARP Reply 패킷을 Request를 보낸 시스템에 유니캐스트로 전송한다.

4. ARP Reply를 수신한 Host A는 자신의 ARP 캐시 테이블에 그 정보를 기록한다.

5. ARP Request에는 응답 만료 시간(Timeout)이 존재하지 않기 때문에, 응답을 수신하지 못하더라도 상관없다. 물론 이 경우에는 호스트와의 통신이 이루어지지 않는다.

 

 

3. ARP의 변형

Ethernet이 확산되고, 증가하는 여러 요구들에 대응하기 위해 ARP의 변형들이 사용되게 되었다.

대표적으로 Reverse ARP, Inverse ARP, Gratuitous ARP 등이 존재하는데, 이것들을 다루기 전에 먼저 ARP Packet의 Operation Code를 살펴볼 필요가 있다.

 

from IANA Reference
from IANA Reference [2]

여기서 Opcode 1, 2번은 일반적인 ARP 요청과, 변형 ARP 중 gARP, DHCP ARP, ARP Probe 등에 사용되는 Request/Reply이고, 이 글에서는 이에 더하여 Reverse ARP(3,4번) Inverse ARP(8, 9번)을 다루겠다.

 

 

3-1. Reverse ARP (RARP)

IPv4를 사용하는 장비가 자신의 하드웨어 주소는 알고 있지만, 자신에게 할당된 IPv4 주소는 모를 때 사용한다.

과거에 저장 매체가 없는 단말들(터미널)이 라우팅이 필요하지 않은 LAN 통신을 위해 주로 사용했지만, 디폴트 게이트웨이, DNS 서버 주소, 서브넷 마스크 등을 알 수 없기 때문에 지금은 DHCP와 BOOTP로 대체되었다.

 

Reverse ARP의 동작 과정은 다음과 같다.

1. 부팅된 터미널 장비가 Sender MAC-Addr와 Target MAC-Addr을 자신의 하드웨어 주소로 채운 RARP Request 패킷을 브로드캐스팅한다. 이 때 Sender IP-Addr과 Target IP-Addr은 전부 0.0.0.0이다.

2. RARP 서버가 이것을 수신하고, Target Protocol Address를 터미널 장비에 할당된 IP로 넣은 RARP Reply 패킷을 L2 Unicast 한다.

3. 터미널이 RARP Reply를 수신하고, 자신의 IP를 설정한다. Calssful Network를 기반으로 한 LAN 통신만이 가능하다.

RARP에 대한 자세한 설명은 RFC 903[3]에 기술되어 있다.

 

 

3-2. Inverse ARP (InARP)

Inverse ARP는 Frame-Relay와 ATM과 같이 여러 물리 계층 장비가 연결되어 WAN 네트워크를 구성하고 있지만, 하나의 논리적인 회선을 구성하여 통신을 하는 네트워크에서 쓰인다.

Frame Relay 망에서 Inverse ARP는 네트워크 장비가 자신과 연결된 VC 단말의 정보를 얻는 데 사용되며, 이를 위해서는 당연히 L2 설정이 제대로 되어 있어야 한다.

L2 통신에 필요한 DLCI를 동적으로 할당하고, 링크의 상태를 확인하는 프로토콜로 LMI가 있는데, 이것은 추후 Frame Relay를 살펴볼 때 알아볼 것이다.

 

그럼 간단한 Frame Relay 망을 예시로 InARP가 어떻게 동작하는지 알아보자.

 

InARP

 

1. Router A는 자신에게 할당된 DLCI 10, 20이 어디에 연결되어 있는지를 알고 싶어한다.

2. Router A는 SHA를 DLCI 10, SPA를 ipA로 하여 InARP Request를 전송한다.

3. Router A의 InARP Request를 수신한 Router B는 자신의 InARP 캐시에 Router A의 DLCI와 IP를 기록하고, SHA에 DLCI 40, SPA에 ipB를 기록한 InARP Reply를 전송한다.

4. Router B의 InARP Reply를 수신한 Router A는  자신의 InARP 캐시에 RouterB의 DLCI와 IP를 기록한다.

5. 이제 L3 통신을 위한 모든 정보가 갖추어졌으므로 통신이 이루어질 수 있다.

 

Inverse ARP의 구현에 대한 자세한 정보는 RFC 2390[4]을 참조하자.

 

3-3. DHCP ARP

DHCP를 이용한 IPv4 자동 할당은 편리하지만, 자칫 IPv4 주소의 충돌이라는 문제를 발생시킬 우려가 있다.

이 문제를 미연에 방지하기 위해 DHCP ARP가 RFC 2131[5]을 통해 정의되었다.

 

DHCP ARP는 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: 0.0.0.0

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Assigned-IP-Addr

 

여기서 출발지 프로토콜 주소가 0.0.0.0인 것은 이 ARP Request를 수신한 장비들이 자신의 ARP Cache Entry를 갱신하지 않도록 하기 위해서이며 (When broadcasting an ARP request for the suggested address, the client must fill in its own hardware address as the sender’s hardware address, and 0 as the sender’s IP address, to avoid confusing ARP caches in other hosts on the same subnet.[6]) 이 요청에 대한 ARP Reply를 수신하지 못한다면 클라이언트는 할당받은 IP 주소를 사용할 것이다.

RFC 2131은 또한 ‘IP 주소의 갱신을 다른 시스템에게 보고하기 위해 ARP Reply를 브로드캐스팅하여 다른 시스템이 오래된 ARP Entry를 갱신하도록 해야 한다’ ( The client SHOULD broadcast an ARP reply to announce the client’s new IP address and clear any outdated ARP cache entries in hosts on the client’s subnet.[7])고 규정하고 있으나, 대부분의 시스템에서는 Gratuitous ARP라 불리는 ARP Request를 이용해 이 기능을 구현하고 있다.

 

3-4. Gratuitous ARP (gARP)

Gratuitous ARP (이하 gARP)는 자신의 IP나 MAC이 변동되어, 같은 서브넷 내의 다른 장비들의 ARP Cache Entry를 갱신할 필요가 있을 때 사용된다.

예를 들어 DHCP로부터 새로운 IP를 할당받았거나, VRRP에서 Active Router를 변경할 때, 클라이언트에서 2개의 NIC를 이용하여 고가용성(HA) 구성을 하였을 경우 등이 있다.

 

gARP 패킷은 다음과 같이 구성된다.

 

Dst-MAC: FF-FF-FF-FF-FF-FF

Src-MAC: Client-MAC

Opcode: 1 (Request)

Src-Har-Addr: Client-MAC

Src-Pro-Addr: Client-IP-Addr

Target-Har-Addr: 00-00-00-00-00-00

Target-Pro-Addr: Client-IP-Addr

 

DHCP ARP 와는 다르게 출발지 프로토콜 주소 필드가 자신의 IP 주소로 설정되었다는 것을 알 수 있다.

gARP는 앞서 말했듯이 오래된 ARP 캐시 엔트리의 갱신이 목적이기 때문에 ARP Reply가 돌아오는 것을 기대하지 않지만, 만약 Reply가 돌아온다면 IP 주소가 충돌한다는 것을 의미하게 되므로 적절한 대처가 요구된다.

 

3-5. ARP Probe

ARP Probe는 IPv4 주소의 충돌을 감지하기 위한 수단으로써, RFC 5227[8]에 정의되어 있다.

ARP Probe는 기본적으로 DHCP ARP와 동일한 구성을 가지는데, 이것은 ARP Probe가 DHCP ARP를 참조했기 때문이다. (The DHCP specification [RFC2131] briefly mentions the role of ARP in detecting misconfiguration, as illustrated in the following three excerpts from RFC 2131: [9])

RFC 5227에서는 DHCP ARP를 확장하여, ‘IPv4를 할당받는 모든 경우에 ARP Request를 전송하도록'(Before beginning to use an IPv4 address (whether received from manual configuration, DHCP, or some other means)[10]) 규정하고 있으며

RFC 2131의 모호함을 (the DHCP specification does not give any guidance to implementers[11]) 해결하였다.

 

3-5.1. ARP Probe의 동작

ARP Probe는 크게 Probing – Announcing – Conflict Detection and Address Defense의 순으로 이루어진다.

먼저, Probing은 DHCP ARP의 패킷 구성을 따르되, IP 할당 이후 0~1초 사이의 랜덤한 시간을 대기한 뒤 3개의 Probing Packet을 전송한다. 이 Probing Packet의 사이에는 1~2초 사이의 임의의 시간 간격을 준다.

마지막 Proving Packet을 전송하고 2초가 지난 뒤에도 ‘Sender IP Address’가 할당받은 IP인 ARP Packet(Request/Reply)이 도착하지 않으면, 클라이언트는 이 IP를 사용해도 된다고 판단, ARP Announcement 패킷-gARP와 동일-을 전송하고, 마지막 단계인 Conflict Detection and Address Defense로 천이한다.

 

Conflict Detection and Address Defense 단계에서 호스트는 Sender IP Address가 자신이 할당받은 IP이면서 Sender Hardware Address가 자신이 아닌 ARP 패킷이 들어오는지를 계속 확인한다.

만약 그러한 패킷이 발견되면, 호스트는 다음 3가지 중 하나의 동작을 취한다.

 

A. 즉시 그 IP 주소의 사용을 포기한 뒤, 설정 Agent(e.g. DHCP Server)에게 오류를 보고한다.

B. 현재 열려있는 TCP 세션이 있어서 IP를 포기할 수 없고, 10초가 지나도 다른 문제가 되는 ARP 패킷이 들어오지 않는다면 그 IP를 계속 사용하도록 결정할 수 있다. 그리고 ARP Announcement 패킷을 한번 더 전송한다. 만약 추가로 문제가 되는 ARP 패킷이 들어오면 호스트는 즉시 그 IP를 폐기하고, 오류를 Agnet에게 보고한다.

C. 만약 이 클라이언트가 네트워크에서 매우 중요한 시스템(e.g. Default Gateway)이어서 IP를 무슨 일이 있어도 포기할 수 없다면, 이 IP를 계속 사용하도록 결정할 수 있다. 이 경우 클라이언트는 Sender-MAC-Addr와 같은 정보를 로그에 기록하고, 네트워크 관리자에게 문제를 알려야 한다. 10초가 지나도 문제가 되는 ARP 패킷이 추가로 유입되지 않으면, 호스트는 ARP Announcement를 1회 전송하고 이 IP를 계속 사용할 수 있다. 만약 10초 이내에 다시 문제가 되는 ARP 패킷이 유입되면, 호스트는 IP  Defense loop를 방지하기 위해 ARP Announcement를 전송해서는 안 된다.

 

 

3-6. UnARP

UnARP는 Proxy ARP 환경에서의 ARP Cache Invaild 문제를 해결하기 위해 RFC 1868[12]을 통해 제시되었고, 현재 실험 프로토콜(Experimental Protocol)로 지정되어 있다.

RFC 1868은 현재 사용되는 timeout을 통한 ARP Entry 제거 방식 대신 클라이언트가 네트워크로부터 접속을 종료할 때, 그것을 명시적으로 ARP를 통해 알리는 것을 골지로 하며, 실험 프로토콜의 특성상 이것을 준수하는 장비는 잘 없다.

 


각주

[1] https://tools.ietf.org/html/rfc1122#page-22

[2] http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-1

[3] https://tools.ietf.org/rfc/rfc903.txt

[4] https://tools.ietf.org/html/rfc2390

[5] https://tools.ietf.org/html/rfc2131

[6] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[7] RFC 2131 – Section 4.4.1 : https://tools.ietf.org/html/rfc2131#section-4.4

[8] https://tools.ietf.org/html/rfc5227

[9] RFC 5227 – Section 1 (Introduction) : https://tools.ietf.org/html/rfc5227#section-1

[10] RFC 5227 – Section 2.1 : https://tools.ietf.org/html/rfc5227#section-2.1

[11] RFC 5227 – Section 1 : https://tools.ietf.org/html/rfc5227#section-1

[12] https://tools.ietf.org/html/rfc1868