태그: CCNA

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

 

CCNA Study – Lan Switching

 

이 글은 Switch에서 L2 Switching이 어떻게 처리되는지를 서술한다.

그리고 Cisco사의 장비를 예시로 설정법을 알아본다.

 

목차

 

 

1. Ethrnet의 역사

우리가 사용하는 Ethernet Frame은 대부분 1983년에 국제 표준이 된 Ethernet II (DIX 2.0)을 따른다. 802.3에서 802.3ab에 이르기까지, Ethernet Frame은 거의 변하지 않은 모습을 보인다. 그런데, DIX 2.0은 어떻게 만들어지게 된 것일까?

Ethernet은 1974년에 ALOHA 네트워크의 CSMA 아키텍쳐에 영감을 받은 Xerox사의 연구자들에 의해 개발되었다. 이들이 만들어낸 프로토콜은 ‘Xerox 시험 네트워크’를 거치면서 실증되었고, 그 이후 Intel과 DEC를 끌어들여 1980년, Data Link layer와 Physical Layer를 정의하고 48비트의 주소와 16비트의 Ether-type 필드를 골지로 한 DIX 1.0 프로토콜을 발표하였다. 그리고 1982년, 이들은 DIX 1.0의 개정판인 DIX 2.0을 발표, 이는 Ethernet II라는 이름으로 알려지게 되고, 이 프로토콜은 IEEE의 근거리 통신용 프로토콜 표준 작업인 802.3에 지대한 영향을 끼쳐, 거의 동일한 프로토콜이 1983년 IEEE 802.3으로 승인된다.

 

2. Ethernet Frame, L2 Switching

OSI 7 Layer중 두번째인 Data Link Layer에서 데이터가 어떻게 처리되는지를 알아보자.

Data Link Layer의 프로토콜 중 하나인 Ethernet에서 데이터의 단위는 Frame이다. 앞으로 Ethernet 데이터를 지칭할 때는 Frame이라고 하겠다.

 

Ethernet Frame의 구조는 다음과 같다.

  1. Preamble (7Byte)
  2. SOF or SFD (1Byte)
  3. Destination MAC Address (48bit)
  4. Source MAC Address (48bit)
  5. Ethernet Type (16bit)
  6. L3 Data
  7. Padding (Optional)
  8. CRC (32bit)
All Rights Reserved ktworld.co.kr
All Rights Reserved ktworld.co.kr

이러한 순서로 구성된 이더넷 프레임은 L3 Protocol Data를 안에 품고 있는 형태가 된다. 이를 캡슐화(Encapsulation)라고 하며, 계층 사이의 독립성을 보장하는 기능을 한다.

이 중 Preamble은 10101010(2)의 나열로 이루어진 신호로, 송/수신측의 비트 동기화에 이용된다. Preamble의 바로 뒤에 오는 10101011(2)이라는 신호를 SOF(Start of Frame)이라고 부르며, 이 뒤에 이더넷 프레임이 온다는 것을 알린다.

또한, Dst-MAC, Src-MAC 다음에 오는 Ethernet Type의 값이 0x600보다 작으면 IEEE 802.2 LLC의 확장인 SNAP PDU가 되고, 이 값이 0x600보다 크면 Ethernet II (DIX 2.0) Frame이 된다. Ethernet II의 Ethernet Type은 이 프레임이 어떠한 상위 계층 프로토콜을 포함하고 있는 것인지를 알려준다.

그 중 대표적인 프로토콜은 다음과 같다.

0x0800 IPv4

0x0806 ARP

0x8100 VLAN Tag

0x8864 PPPoE

여기서 0x8100(VLAN Tag)은 TPID(Tag Protocol Identifier)라고 불리며, 그 뒤에 VLAN(802.1Q)와 QoS(802.1p)정보를 담은 TCI(Tag Control Information)가 온다는 것을 알린다. 그리고 TCI (16bit)가 지난 뒤에 다시 Ethernet Type (16bit)이 나와 L3 프로토콜을 지정한다.

자세한 IEEE 802.1q Frame의 구조는 이 글의 범위를 벗어나므로 여기서는 다루지 않겠다. 앞으로 VLAN Tagging을 공부할 때 다시 확인할 수 있을 것이다.

마지막으로 Padding은 Destination MAC부터 CRC까지의 Ethernet Frame의 크기가 64Byte보다 작을 경우에 추가되는데, 이것은 802.3의 CSMA/CD 알고리즘에서 Collision Detect를 위한 slot time을 보장하기 위한 최소 길이가 64byte인 것에 기인한다. 단, 전송률이 더욱 올라간 Gigabit Ethernet (802.3ab)에서는 최대 케이블 길이를 줄이는 것 대신(10M 이하로 줄어든다!) 프레임의 최소 길이는 64Byte로 유지하되, 512Byte에 미달할 경우 CRC 정보 뒤에 임의의 Symbol을 채워주도록 하였고, 이를 Carrier Extension이라고 한다.

이더넷 프레임의 구조를 알았으니,  실제로 L2 장비에서 이더넷 프레임이 어떻게 처리되는지를 알아보자.

 

1. Host A가 Switch B의 Fa 0/1 인터페이스로 프레임을 보낸다. 이 때 Source MAC Address는 Host A 자신의 MAC을, Destination MAC Address는 Host B의 MAC을 사용한다.

2. Switch B의 Line Card의 Fa 0/1로 이더넷 프레임이 들어온다. Switch B는 자신의 ARP Table을 확인하고 만약 Table에 Source MAC이 존재하지 않으면 Source MAC Learning Event를 발생시켜 Control Module의 ARP Table에 Source MAC을 기록하고, 자신의 ARP Table에도 Source MAC을 기록한다. 이렇게 Dynamic으로 기록된 MAC은 기본값으로 300초간 저장된다.

3. Line Card의 Packet Processor는 이 Ethernet Frame을 열어보고 목적지가 자신의 MAC과 일치하는지 확인한다. 이 경우에는 아니므로 프레임은 Ethernet Switching 되어야 하고, Packet Processor는 Switching을 위해 자신의 ARP Table을 참조한다. 만약 ARP Table에 Dst-MAC이 있으면 라인 카드는 프레임을 그 인터페이스로 포워딩하고, Dst-MAC이 없다면 프레임을 자신의 모든 인터페이스로 플러딩한다. (설명의 편의를 위해 이 스위치의 라인 카드의 수는 하나로 가정한다)

4. Host B가 Host A가 보낸 이더넷 프레임을 수신한다.

3. Cisco Switch에서의 Ethernet 설정

여기서 나오는 명령어들은 Cisco사의 Catalyst 2950 스위치를 기준으로 한다.

interfaceinterface port (range) (port Number)

Global Configuration 모드에서 사용하며, 스위치의 인터페이스 설정 모드로 들어간다. range 명령이나 하이픈(-)을 사용하여 여러 인터페이스를 동시에 설정할 수 있다.

duplexduplex auto/full/half

Interface Configuration 모드의 하위 명령어로, 이 인터페이스 포트가 어떠한 Duplex 모드로 동작할 것인지를 결정한다. 기본값은 auto이며, Interface Config에서 full-duplex, half-duplex를 입력하는 것으로도 동작 모드를 변경할 수 있다.

bandwidthbandwidth number (1 – 10000000)

Interface Configuration 모드의 하위 명령어로, 이 인터페이스에 할당된 Bandwidth를 지정한다. 여기서 유의할 점은 bandwidth 명령어로 설정하는 대역폭은 실제 링크 속도와는 관계가 없다는 것이다. 이 설정값은 EIGRP, OSPF 라우팅 프로토콜이 해당 인터페이스의 Metric 값을 결정하는 것에 영향을 미친다.