태그: L3

VXLAN(Virtual eXtensible Local Area Network) – 1

최근 데이터센터에서 멀티 테넌트 환경을 지원하기 위해 각광받고 있는 VXLAN을 RFC를 바탕으로 이해해 보자.

RFC7348에서는 VXLAN을 ‘가상화된 L2 네트워크를 오버레이로 L3네트워크 상에서 구현하는 프레임워크’라 정의하고 있다. 그리고 RFC7348은 Informational 카테고리에 등록되어 있다.

 

1. 개요

IDC에서 서버 가상화가 확산되고, 하나의 서버가 많은 VM들을 가지게 되면서 Ethernet Switch가 가지는 MAC Address Table도 급격히 커지게 되었다. 또한 Extended VLAN의 최대 갯수가 4096개인 것에 비해 멀티 테넌트 환경에서 수천개, 혹은 그 이상의 VLAN을 요구하게 됨에 따라, 잠재적으로 중복된 VLAN ID가 발생할 가능성이 생겼다. 그리고 가상화된 L2 네트워크를 전체 데이터센터에 적용하게 되면, 기존에 사용되던 STP 같은 루프 방지 알고리즘은 많은 비활성화 된 링크를 만들어낸다. 이런 상황을 피하기 위해서 Equal-Cost Multipath(ECMP)를 도입한다 하더라도, VM간 통신에는 여전히 기존의 L2 모델을 남겨둘 수 밖에 없다.

이러한 문제점들을 해결하기 위하여 오버레이 네트워크가 제안되었다. 오버레이 네트워크란, 각각의 VM들이 만들어내는 MAC 트래픽을 논리적인 ‘터널’을 통해 캡슐화하여 전달하는 것을 의미한다. 그리고 VXLAN은 오버레이 네트워크를 실현하기 위한 프레임워크이다.

 

2. 가상화 환경에서의 제약 사항

2-1. STP(Spanning Tree Protocol)과 VLAN 범위의 제약

현재, L2 네트워크는 루프 회피를 위하여 IEEE 802.1D STP를 사용하고 있다. STP는 중복되는 링크를 블록하는 것으로 루프 방지를 구현한다. 때문에 데이터센터는 실제로 사용할 수 있는 것보다 더 많은 물리적 링크를 가져야 하고, 다중 경로를 통해 얻을 수 있는 복원성도 사라진다. 이를 해결하기 위한 최근의 시도로 TRILL(RFC6325)과 SPB(802.7ag)가 있지만, 멀티패스틑 구현할 수 있도록 도와주거나, STP의 문제들 중 일부를 덮어둘(surmount) 뿐이다. STP의 제약은 서버와 랙을 하나의 Layer 3 네트워크로 구성하는 것으로 해결될 수 있다. 하지만 이것 또한 VM 사이의 통신을 위한 L2 모델과 호환되지 않는다.

L2 데이터 센터의 특징은 Broadcast isolation을 위해 VLAN을 사용한다는 점이다. 12bit의 VLAN ID는 최대 4096개의 VLAN을 제공할 수 있으며, 기존의 데이터센터들에서는 4096개보다 더 적은 VLAN을 사용했기에 문제가 없었다. 하지만 서버 가상화의 도입으로 고객들에게 독립된 환경(Tenant)를 제공하는 것이 중요해졌고, 한 서버에 수많은 VM들이 올라감에 따라 VLAN ID는 급속도로 고갈되었다.

 

2-2. 멀티 테넌트 환경

클라우드 컴퓨팅은 om-demand한 동적 프로비저닝을 요구한다. 대부분의 클라우드 컴퓨팅은 Private Cloud이며, 서비스 제공자는 하나의 물리적 인프라 위에서 각 고객들에게 독립된 환경을 제공해주어야 한다. 테넌트를 이용한 네트워크 트래픽 분리는 L2, L3네트워크에서 적용될 수 있다. L2 네트워크에서는 이것을 위해 VLAN이 자주 사용된다. 클라우드 서비스 제공자는 많은 수의 테넌트를 제공해야 하며, 각 테넌트당 하나의 VLAN ID가 할당되어야 하는 환경에서 4096개의 VLAN ID 제한은 적합하지 않다. 게다가 하나의 테넌트가 여러개의 VLAN을 요구할 수도 있는데(Ex. 부서간 네트워크 분리) 이는 상황을 더욱 악화시킨다. 관련된 다른 문제로 cross-pod 확장이 있다. pod이란 연관된 네트워크와 스토리지로 구성된 하나 또는 그 이상의 랙을 말한다. 테넌트는 그것이 더 많은 서버와 VM을 필요로 할 때 다른 Pod으로 확장될 수 있어야 한다. 특히, 인접 Pod의 자원 활용율이 낮다면 더욱 그렇다. 이러한 환경에서는 “확장된” L2 환경이 필요하다.

L3 네트워크 또한 멀티테넌시 환경에 대한 포괄적인 해결책은 아니다. 두 테넌트가 자신들의 네트워크에서 동일한 L3 주소를 사용할 수 있으려면, 클라우드 서비스 제공자가 고립된 네트워크 환경을 제공해 주어야 한다.

 

2-3. ToR Switch의 부적절한 테이블 크기

지금의 가상화된 환경에서는 ToR(Top of Rack)스위치의 MAC Address Table의 크기가 증가되어야 한다. 서버의 링크당 하나의 MAC Address를 학습해야 했던 이전과는 달리, 스위치는 이제 VM에 붙은 링크 수만큼의 MAC Address를 학습해야 한다. 데이터센터는 여러대의 랙으로 이루어져 있고, 다른 랙에 있는 VM과 통신하기 위하여 MAC을 학습해야 한다. 때문에 가상화되지 않은 환경에 비해 큰 테이블 크기를 요구한다.

스위치는 테이블이 다 찼을 시, 학습을 중단하고 학습되지 않은 패킷들을 모든 포트로 플러딩한다.

 

3. VXLAN

VXLAN은 L3 네트워크 위에 가상의 L2 네트워크를 오버레이하는 기술이다. 오버레이된 네트워크들을 VXLAN segment라고 하며 각각의 segment에 포함된 VM끼리만 통신이 가능하다. 각 VXLAN segment는 24비트의 식별자(VXLAN Network Identifier)를 가지며, 최대 1600만개 이상의 VXLAN 세그먼트가 만들어질 수 있다. VXLAN Netrowk Identifier(이하 VNI)는 내부의 캡슐화된 이더넷 프레임이 어떤 VM으로부터 나왔는지 특정하며, 때문에 세그먼트들 사이의 MAC을 오버래핑 하더라도, 트래픽이 세그먼트들을 ‘통과하는’일은 일어나지 않는다. 이러한 캡슐화 때문에 VXLAN은 L3 네트워크에서 L2 네트워크를 구성하는 터널링 기술로 불리기도 한다. 이 터널이 stateless 하기 때문에 각각의 프레임들은 일정한 규칙에 따라 캡슐화될 필요가 있다.

이 터널의 종단(VXLAN Tunnel End Point, 혹은 VTEP)은 VM을 서비스하고 있는 서버나 하이퍼바이저에 위치한다. 여기서, 물리적인 네트워크 장비나 서버 또한 사용될 수 있음을 기억하자.

그럼 이제 VXLAN이 터널을 어떻게 구성하는지 알아보자.

 

1. VXLAN이 적용된 VM은 VXLAN을 인지하지 못한다. 이 VM은 다른 VM과 통신하기 위하여 일반적인 MAC 프레임을 전송한다.

2. 물리 호스트 위의 VTEP는 프레임을 수신하고, 해당 VM이 속한 VNI를 찾는다. 그리고 목적지 MAC이 같은 세그먼트에 속하는 VM이라면, 원격 VTEP의 MAC을 매핑한다. 이 시점에서의 패킷 구조는 IP-MAC 헤더-원본 L2 프레임이다.

3. L3 네트워크를 타고 전송된 프레임이 원격 VTEP에 도착한다. 원격 VTEP는 VNI를 검증하고 목적지 VM이 해당 VNI에 속해있는지 확인한 뒤, 프레임의 캡슐화를 풀고, VM에 전달한다.

 

RFC7348은 VTEP의 구현과 프레임을 최종적으로 전달할 때의 구현에 대해선 정의하고 있지 않다. 따라서 이러한 부분에서 벤더간 호환성 문제가 발생할 수 있을 것으로 보인다.

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 – 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

 

라우터/스위치의 구조

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

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

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


목차

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

 

 

1. Introduction

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

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

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

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

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

 

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

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

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

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

3. 통신 시나리오

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

Router_Structure

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

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

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

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

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

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

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

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

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

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

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