ARP는 IP Address와 MAC Address를 어떻게 연결하는가

ARP는 IP Address와 MAC Address를 어떻게 연결하는가#

1장 IP Address만으로는 Ethernet Frame을 보낼 수 없다#

1.1 같은 네트워크인데 왜 MAC Address가 필요할까#

다음과 같은 주차관제 네트워크가 있다고 가정해보겠습니다.

Parking Server
192.168.10.10

Gate Controller
192.168.10.20

두 장비는 같은 /24 네트워크에 있습니다.

Server 프로그램은 Controller의 IP Address인:

192.168.10.20

을 알고 있습니다.

하지만 실제 Ethernet Network에서 데이터를 전달하려면 Ethernet Frame을 만들어야 합니다.

Ethernet Frame에는 다음 정보가 필요합니다.

Destination MAC
Source MAC
EtherType
Payload
FCS

여기서 문제가 하나 생깁니다.

Server는:

Destination IP
192.168.10.20

은 알고 있지만 처음에는:

Destination MAC
?

을 모를 수 있습니다.

이때 사용하는 것이 ARP입니다.

1.2 ARP의 역할#

ARP는 Address Resolution Protocol의 약자입니다.

IPv4 Network에서 같은 Link에 있는 장비의:

IP Address
↓
MAC Address

관계를 알아내는 데 사용됩니다.

예를 들어:

192.168.10.20
↓
ARP
↓
00:11:22:33:44:55

라는 관계를 확인할 수 있습니다.

즉 ARP를 한 문장으로 정리하면 다음과 같습니다.

IPv4 Address를 이용해 같은 Ethernet Network에서 사용할 MAC Address를 알아내는 Protocol입니다.

2장 ARP Request와 ARP Reply#

2.1 ARP Request는 네트워크에 질문한다#

Server가 Controller의 MAC Address를 모른다고 가정해보겠습니다.

Server는 다음과 같은 질문을 보냅니다.

192.168.10.20을 사용하는 장비는 누구인가?
내게 MAC Address를 알려달라.

Wireshark에서는 비슷하게:

Who has 192.168.10.20?
Tell 192.168.10.10

처럼 표시될 수 있습니다.

이것이 ARP Request입니다.

2.2 ARP Request는 Broadcast로 전달된다#

문제는 Server가 Controller의 MAC을 모르기 때문에 특정 장비에게 Ethernet Frame을 직접 보낼 수 없다는 것입니다.

그래서 ARP Request의 Ethernet Destination MAC에는 Broadcast Address가 사용됩니다.

FF:FF:FF:FF:FF:FF

구조를 단순화하면:

Server
192.168.10.10
      │
      │ ARP Request
      ↓
   Switch
   ├─ Camera
   ├─ Controller
   ├─ Kiosk
   └─ 관리 PC

같은 VLAN 또는 Broadcast Domain에 있는 장비들이 ARP Request를 받을 수 있습니다.

2.3 대상 장비가 ARP Reply를 보낸다#

Controller가 자신을 찾는 ARP Request를 받았다고 가정합니다.

Target IP
192.168.10.20

자신의 IP와 일치하므로 Controller는 다음과 같이 응답합니다.

192.168.10.20은 나다.

내 MAC Address는
00:11:22:33:44:55이다.

이것이 ARP Reply입니다.

일반적인 ARP Reply는 요청을 보낸 장비에게 Unicast로 전달됩니다.

2.4 전체 ARP 흐름#

ARP의 기본 과정을 한 번에 보면 다음과 같습니다.

Server
192.168.10.10
MAC AA:AA:AA:AA:AA:AA
        │
        │
        │ ARP Request
        │
        ▼
FF:FF:FF:FF:FF:FF

"192.168.10.20은 누구인가?"
        │
        ▼

Controller
192.168.10.20
MAC BB:BB:BB:BB:BB:BB
        │
        │ ARP Reply
        ▼

"192.168.10.20은
 BB:BB:BB:BB:BB:BB이다."

이제 Server는 Controller의 MAC Address를 알게 됩니다.

3장 ARP Cache는 왜 필요한가#

3.1 통신할 때마다 ARP를 하면 비효율적이다#

Server가 Controller로 1초마다 데이터를 보낸다고 생각해보겠습니다.

매번:

ARP Request
↓
ARP Reply
↓
Data

를 반복하면 불필요한 Broadcast Traffic이 발생합니다.

그래서 운영체제와 Network 장비는 알아낸 ARP 정보를 일정 시간 저장해 둡니다.

이를 ARP Cache 또는 Neighbor Table이라고 부릅니다.

3.2 ARP Cache에는 무엇이 저장될까#

개념적으로 다음과 같습니다.

IP Address            MAC Address

192.168.10.20    →    00:11:22:33:44:55
192.168.10.30    →    00:11:22:33:44:66
192.168.10.1     →    00:11:22:33:44:01

이 정보가 있으면 다음 통신에서는 새로운 ARP Request 없이 기존 MAC Address를 사용할 수 있습니다.

3.3 ARP Cache는 영구적인 정보가 아니다#

Dynamic ARP Entry는 일반적으로 일정 시간이 지나면 갱신되거나 제거될 수 있습니다.

정확한 유지 시간과 상태 전이 방식은 운영체제나 Network 장비에 따라 다를 수 있습니다.

따라서:

ARP Cache에 한번 들어갔다
=
영원히 유지된다

라고 생각하면 안 됩니다.

4장 ARP와 Switch의 MAC Address Table은 다르다#

4.1 가장 많이 혼동하는 두 Table#

ARP를 배우면서 가장 많이 혼동하는 것이:

ARP Table

MAC Address Table

입니다.

둘은 완전히 다른 정보를 관리합니다.

4.2 ARP Table은 IP와 MAC을 연결한다#

Host의 ARP Table은 다음 관계를 관리합니다.

IP Address
↓
MAC Address

예:

192.168.10.20
↓
00:11:22:33:44:55

4.3 Switch MAC Table은 MAC과 Port를 연결한다#

Switch는 다음 관계를 관리합니다.

MAC Address
↓
Switch Port

예:

00:11:22:33:44:55
↓
Gi1/0/7

4.4 두 정보를 연결하면 실제 전달 과정이 보인다#

Server가 192.168.10.20으로 데이터를 보낸다고 가정해보겠습니다.

먼저 Server가 ARP 정보를 확인합니다.

192.168.10.20
↓
ARP Cache
↓
00:11:22:33:44:55

Ethernet Frame을 만듭니다.

Destination MAC
00:11:22:33:44:55

Switch는 자신의 MAC Table을 확인합니다.

00:11:22:33:44:55
↓
Gi1/0/7

결국:

Destination IP
192.168.10.20
        ↓
       ARP
        ↓
Destination MAC
00:11:22:33:44:55
        ↓
Switch MAC Table
        ↓
      Port 7
        ↓
   Controller

로 이어집니다.

이 구조를 이해하면 ARP와 Switch의 역할을 혼동하지 않게 됩니다.

5장 같은 Network와 다른 Network에서 ARP는 다르게 사용된다#

5.1 같은 Subnet의 장비로 보낼 때#

다음 두 장비가 있다고 가정합니다.

Server
192.168.10.10/24

Controller
192.168.10.20/24

둘은 같은:

192.168.10.0/24

Network에 있습니다.

Server는 Controller의 MAC을 ARP로 알아내고 직접 Ethernet Frame을 보냅니다.

192.168.10.20
↓
ARP
↓
Controller MAC
↓
Ethernet Frame 전송

5.2 다른 Subnet의 장비로 보낼 때#

이번에는 목적지가 다음과 같습니다.

Server
192.168.10.10/24

Remote Server
192.168.20.50/24

서로 다른 Network입니다.

이때 Server가:

192.168.20.50의 MAC이 무엇인가?

라고 직접 ARP하는 것이 일반적인 Routed Network의 동작은 아닙니다.

대신 자신의 Default Gateway로 Packet을 전달합니다.

예:

Default Gateway
192.168.10.1

Server는:

192.168.10.1의 MAC Address는 무엇인가?

를 ARP로 확인합니다.

5.3 다른 Network로 갈 때의 Ethernet Destination#

IP Packet의 최종 목적지는:

192.168.20.50

입니다.

하지만 현재 Ethernet Frame의 Destination MAC은:

Default Gateway MAC

이 됩니다.

즉:

IP Destination
192.168.20.50

Ethernet Destination
Gateway MAC

처럼 서로 다른 주소를 사용할 수 있습니다.

이 개념은 이후 Gateway와 Routing을 이해하는 데 매우 중요합니다.

6장 ARP Packet 안에는 어떤 정보가 있을까#

6.1 ARP Request의 주요 정보#

ARP Request에는 대표적으로 다음 정보가 포함됩니다.

Sender MAC Address
Sender IP Address

Target MAC Address
Target IP Address

Request에서는 아직 Target MAC을 모르기 때문에 이를 알기 위한 요청을 보냅니다.

예:

Sender IP
192.168.10.10

Sender MAC
AA:AA:AA:AA:AA:AA

Target IP
192.168.10.20

입니다.

6.2 ARP Reply에서는 대상 MAC을 알려준다#

Reply에서는:

192.168.10.20
=
BB:BB:BB:BB:BB:BB

라는 정보를 전달합니다.

이 정보를 받은 Host가 ARP Cache를 갱신할 수 있습니다.

7장 실제 Packet Capture에서 ARP를 확인해보자#

7.1 tcpdump로 ARP만 확인하기#

Linux에서는 다음처럼 ARP Traffic만 볼 수 있습니다.

tcpdump -i eth0 arp

출력은 다음과 비슷할 수 있습니다.

ARP, Request who-has 192.168.10.20 tell 192.168.10.10

ARP, Reply 192.168.10.20 is-at 00:11:22:33:44:55

첫 번째가 ARP Request이고 두 번째가 ARP Reply입니다.

7.2 Ethernet Header까지 함께 보기#

다음처럼 사용할 수도 있습니다.

tcpdump -e -i eth0 arp

그러면 Ethernet Source와 Destination MAC도 함께 확인할 수 있습니다.

Request에서는 대표적으로:

Source
AA:AA:AA:AA:AA:AA

Destination
FF:FF:FF:FF:FF:FF

을 볼 수 있습니다.

7.3 Wireshark에서 확인할 항목#

Wireshark에서 Filter를:

arp

로 설정하면 ARP Packet만 확인할 수 있습니다.

주요 항목은:

Opcode
Sender MAC Address
Sender IP Address
Target MAC Address
Target IP Address

입니다.

ARP 장애를 분석할 때는 단순히 Request가 보이는지만 보지 말고:

누가 물었으며 누가 어떤 MAC으로 답했는가?

를 봐야 합니다.

8장 운영체제에서 ARP Cache 확인하기#

8.1 Windows#

다음 명령으로 ARP Cache를 확인할 수 있습니다.

arp -a

예:

Internet Address      Physical Address

192.168.10.1          00-11-22-33-44-01
192.168.10.20         00-11-22-33-44-55

8.2 Linux#

Linux에서는 다음 명령을 많이 사용합니다.

ip neigh

또는:

ip neigh show dev eth0

결과에는 Neighbor 상태도 함께 나타날 수 있습니다.

예:

192.168.10.20 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE

8.3 arping으로 같은 LAN의 장비 확인하기#

시험망이나 허가된 환경에서는:

arping -I eth0 -c 3 192.168.10.20

처럼 특정 IPv4 Address에 ARP Request를 보낼 수 있습니다.

ARP는 같은 Layer 2 Network의 상태를 확인할 때 매우 유용하기 때문에 일반 Ping과는 다른 정보를 얻을 수 있습니다.

9장 ARP가 실패하면 어떤 증상이 나타날까#

9.1 ARP Request는 보이는데 Reply가 없다#

예:

ARP Request
Who has 192.168.10.20?

↓

Reply 없음

가능한 원인은 다양합니다.

대상 장비 전원 OFF
Cable 또는 Link 문제
잘못된 VLAN
대상 IP 설정 오류
장비가 Network에 없음
Switch Port 문제

이때 Application의 TCP Port를 확인하기 전에 Layer 2와 IP 설정부터 확인해야 합니다.

9.2 ARP 자체가 발생하지 않는다#

같은 Subnet의 장비로 통신을 시도했는데 예상한 ARP가 보이지 않는다면 다음을 확인할 수 있습니다.

이미 ARP Cache에 Entry가 있는가?

Subnet Mask가 잘못되어 있는가?

Routing Table이 다른 경로를 선택하는가?

Application이 실제로 Traffic을 보내고 있는가?

즉 Packet이 없다고 해서 항상 상대 장비 문제는 아닙니다.

송신 Host의 판단부터 확인해야 합니다.

10장 IP 충돌과 ARP#

10.1 두 장비가 같은 IPv4 Address를 사용하면#

다음과 같은 설정 오류를 생각해보겠습니다.

Camera A
192.168.10.30

Camera B
192.168.10.30

두 장비가 같은 IPv4 Address를 사용합니다.

그런데 MAC Address는 서로 다릅니다.

Camera A
AA:AA:AA:AA:AA:AA

Camera B
BB:BB:BB:BB:BB:BB

이 경우 Network의 다른 장비에서는:

192.168.10.30
→ AA:AA:AA:AA:AA:AA

였다가 나중에는:

192.168.10.30
→ BB:BB:BB:BB:BB:BB

처럼 보일 수 있습니다.

10.2 IP 충돌은 간헐 장애처럼 보인다#

이 때문에:

Ping 성공
↓
갑자기 실패
↓
다시 성공

하거나:

Camera A 화면
↓
잠시 후 Camera B

같은 이상한 현상이 발생할 수 있습니다.

따라서 장비가 됐다 안 됐다 한다면 다음을 확인할 가치가 있습니다.

IP 중복
ARP Entry 변화
MAC Address 변화
IP 할당표
최근 장비 교체 이력

11장 Gratuitous ARP는 무엇인가#

11.1 요청받지 않아도 자신의 정보를 알릴 수 있다#

장비가 자신의 IPv4 Address와 MAC 정보를 Network에 알리는 형태의 ARP를 볼 수 있습니다.

이를 흔히 Gratuitous ARP라고 부릅니다.

예를 들어:

내 IP는 192.168.10.20이고
내 MAC은 AA:BB:CC:DD:EE:FF이다.

라는 정보를 주변 Network에 알릴 수 있습니다.

11.2 Gratuitous ARP는 언제 사용될까#

환경에 따라 다음과 같은 목적으로 사용될 수 있습니다.

  • IP 중복 감지
  • ARP Cache 갱신 유도
  • 장비 Interface 변경 알림
  • 고가용성 시스템의 MAC/IP 이동 알림

따라서 Packet Capture에서 Gratuitous ARP가 보인다고 해서 무조건 이상 Traffic이라고 판단해서는 안 됩니다.

11.3 장비 교체 후 ARP 문제가 생기는 이유#

예를 들어 Controller를 교체했다고 가정해보겠습니다.

기존 장비:

IP
192.168.10.20

MAC
AA:AA:AA:AA:AA:AA

새 장비:

IP
192.168.10.20

MAC
BB:BB:BB:BB:BB:BB

IP는 동일하지만 MAC이 달라졌습니다.

주변 장비에 기존 ARP Entry가 남아 있으면 일시적으로 오래된 MAC을 사용할 수도 있습니다.

새 장비의 Gratuitous ARP나 ARP 재학습을 통해 정보가 갱신될 수 있습니다.

12장 Proxy ARP란 무엇인가#

12.1 다른 장비 대신 ARP에 응답하는 경우가 있다#

일반적으로 Host는 같은 Network의 목적지에 대해 직접 ARP를 수행합니다.

하지만 Network 장비가 다른 장비 대신 ARP Reply를 하는 구성이 있을 수 있습니다.

이를 Proxy ARP라고 합니다.

개념적으로:

Host
 │
 │ "192.168.20.10의 MAC?"
 ↓
Router
 │
 │ "내 MAC으로 보내라."
 ↓
Host

처럼 보일 수 있습니다.

12.2 Proxy ARP가 있으면 장애 분석이 복잡해질 수 있다#

Packet Capture에서:

왜 목적지 장비가 아닌 Router가 ARP Reply를 하지?

라는 상황을 볼 수 있습니다.

이때 곧바로 비정상이라고 판단하면 안 됩니다.

Router 또는 Firewall의 Proxy ARP 설정을 확인해야 합니다.

반대로 의도하지 않은 Proxy ARP가 활성화되어 Network 구조를 이해하기 어렵게 만드는 경우도 있으므로 설계 문서와 실제 설정을 비교해야 합니다.

13장 주차관제 Network에서 ARP를 어떻게 볼까#

13.1 Gate Controller와 Server가 같은 VLAN인 경우#

예를 들어:

Parking Server
192.168.10.10

Gate Controller
192.168.10.20

VLAN 20

이라고 하겠습니다.

Gate Controller가 Server와 처음 통신하려면:

Server IP
192.168.10.10
↓
ARP
↓
Server MAC 확인
↓
Ethernet Frame 생성
↓
TCP / HTTP 통신

의 흐름을 거칠 수 있습니다.

13.2 LPR Camera도 같은 원리다#

Camera가 Server로 인식 결과를 전송할 때:

LPR Camera
192.168.10.30
↓
ARP
↓
Server MAC
↓
Ethernet
↓
IP
↓
TCP
↓
Application Data

로 이어집니다.

즉 ARP는 사용자가 직접 사용하는 Application Protocol은 아니지만 IPv4 LAN 통신이 시작되기 전에 매우 중요한 연결 역할을 합니다.

14장 VLAN이 다르면 ARP도 넘어가지 않는다#

14.1 ARP Request는 Broadcast Domain 안에서 동작한다#

다음과 같이 VLAN이 나뉘어 있다고 가정하겠습니다.

VLAN 10
192.168.10.0/24

VLAN 20
192.168.20.0/24

VLAN 10에서 발생한 일반적인 ARP Broadcast가 VLAN 20으로 그대로 전달되는 것은 아닙니다.

VLAN 10
ARP Broadcast
     X
VLAN 20

이것이 VLAN이 Broadcast Domain을 분리한다고 말하는 이유 중 하나입니다.

14.2 다른 VLAN으로 갈 때는 Gateway MAC을 찾는다#

VLAN 10의 Host가 VLAN 20의 장비로 Packet을 보내려고 하면 자신의 Gateway에 보내야 합니다.

Destination IP
192.168.20.20
↓
다른 Network라고 판단
↓
Default Gateway MAC을 ARP
↓
Gateway로 Frame 전송

따라서 다른 VLAN 장비와 통신이 안 될 때:

상대 장비 ARP가 안 보인다.

는 것만으로 문제가 있다고 판단해서는 안 됩니다.

상대 장비가 아닌 Gateway MAC을 찾는 것이 정상일 수 있습니다.

15장 ARP 장애를 현장에서 진단하는 순서#

15.1 먼저 IP와 Subnet Mask를 확인한다#

Local IP
Subnet Mask
Destination IP

를 확인합니다.

둘이 같은 Network인지 먼저 계산해야 합니다.

15.2 VLAN을 확인한다#

물리적으로 같은 Switch에 있어도 VLAN이 다르면 Layer 2에서 분리되어 있을 수 있습니다.

Device A
VLAN 10

Device B
VLAN 20

같은 Subnet을 잘못 설정했다고 해서 VLAN을 넘어 ARP가 자동으로 전달되는 것은 아닙니다.

15.3 ARP Cache를 확인한다#

IP
↓
어떤 MAC과 연결되어 있는가?

를 봅니다.

예상 MAC과 다르면:

  • IP 충돌
  • 오래된 Entry
  • Proxy ARP
  • 잘못된 Static ARP
  • Network 구성 오류

등을 확인합니다.

15.4 Packet Capture로 Request와 Reply를 확인한다#

다음 순서를 봅니다.

ARP Request 발생?
        ↓
ARP Reply 도착?
        ↓
Reply의 Sender IP?
        ↓
Sender MAC?

이 네 단계만 봐도 많은 ARP 장애를 구분할 수 있습니다.

16장 IP 충돌을 발견했을 때의 접근#

16.1 의심 장비를 먼저 식별한다#

ARP Cache에서 같은 IP의 MAC이 반복적으로 달라진다면 두 MAC을 기록합니다.

192.168.10.30
→ AA:AA:AA:AA:AA:AA

잠시 후

192.168.10.30
→ BB:BB:BB:BB:BB:BB

그다음 Switch MAC Table에서 각각 어느 Port에 있는지 확인할 수 있습니다.

AA:AA...
→ Port 7

BB:BB...
→ Port 18

이렇게 하면 실제 장비 위치를 좁힐 수 있습니다.

16.2 IP 할당표와 대조한다#

다음 정보를 비교합니다.

장비 ID
IP Address
MAC Address
Switch
Port
위치

따라서 현장 IP 관리 문서에는 IP Address만 적기보다 MAC과 Switch Port까지 함께 기록하는 것이 유용합니다.

17장 ARP Spoofing은 왜 위험한가#

17.1 ARP에는 기본적인 인증 구조가 없다#

ARP는 오래된 단순한 Protocol입니다.

일반적인 ARP 자체에는:

이 Reply를 보낸 장비가 정말 이 IP의 주인인가?

를 강력하게 인증하는 기능이 없습니다.

이 특성 때문에 잘못된 ARP 정보를 보내 다른 Host의 Cache에 잘못된 MAC Mapping을 만들려는 공격이 가능합니다.

이를 흔히:

ARP Spoofing
ARP Poisoning

이라고 부릅니다.

17.2 잘못된 ARP Mapping이 만들어지면#

예를 들어 정상 Gateway는:

192.168.10.1
→ Gateway MAC

이어야 합니다.

하지만 Client가 잘못된 정보를 믿게 되면:

192.168.10.1
→ 공격자 MAC

처럼 될 수 있습니다.

그 결과 Network 구조에 따라 Traffic 가로채기나 통신 방해로 이어질 수 있습니다.

18장 Switch에서 ARP 보안을 강화하는 방법#

18.1 DHCP Snooping#

Managed Switch에서는 DHCP Snooping을 이용해:

어떤 IP가
어떤 MAC에게
어느 Port에서
할당됐는가

같은 Binding 정보를 관리할 수 있는 제품이 있습니다.

18.2 Dynamic ARP Inspection#

Dynamic ARP Inspection, 즉 DAI를 지원하는 Switch에서는 ARP Packet을 검사하여 신뢰할 수 있는 Binding과 맞지 않는 ARP를 차단하도록 구성할 수 있습니다.

개념적으로:

ARP Packet
↓
Switch 검사
↓
정상 Binding인가?
├─ Yes → 허용
└─ No  → 차단

환경에 따라 DHCP Snooping Binding 정보를 활용하기도 합니다.

지원 방식과 세부 설정은 Switch 제조사와 모델에 따라 다릅니다.

18.3 Port Security도 함께 사용할 수 있다#

Port에서 사용할 수 있는 MAC Address를 제한하는 Port Security 기능을 제공하는 Switch도 있습니다.

하지만:

Port Security
=
ARP Spoofing 완전 방어

는 아닙니다.

ARP, MAC, DHCP, VLAN, 인증 기능은 각각 역할이 다르므로 Network 보안 정책 전체로 접근해야 합니다.

19장 Static ARP는 만능 해결책이 아니다#

19.1 Static ARP의 장점#

특정 IP와 MAC 관계를 고정하면 임의의 ARP Reply에 의해 Mapping이 바뀌는 것을 제한할 수 있습니다.

예:

192.168.10.20
→ AA:BB:CC:DD:EE:FF

19.2 운영 부담이 커질 수 있다#

장비를 교체하면 MAC Address가 바뀔 수 있습니다.

Static ARP가 남아 있다면 새 장비와 통신되지 않을 수 있습니다.

기존 MAC
AA:AA...

새 장비 MAC
BB:BB...

Static ARP
AA:AA...
↓
통신 실패

그래서 장비가 많아질수록 Static ARP를 일일이 관리하는 방식은 운영 부담이 커질 수 있습니다.

20장 ARP 관련 흔한 오해#

20.1 ARP는 모든 목적지 IP의 MAC을 찾는다?#

아닙니다.

일반적인 Routed Network에서는 현재 Local Link에서 다음 Hop으로 사용할 MAC Address를 찾습니다.

다른 Subnet의 최종 장비 MAC을 직접 찾는 것이 아닙니다.

20.2 Switch가 ARP로 목적지 Port를 알아낸다?#

아닙니다.

Switch의 기본 L2 Forwarding은 MAC Address Table을 사용합니다.

ARP
IP → MAC

Switch MAC Table
MAC → Port

으로 구분해야 합니다.

20.3 ARP Reply는 항상 안전한 정보인가?#

아닙니다.

ARP 자체에는 강력한 인증 기능이 없기 때문에 잘못된 정보가 유입될 가능성을 고려해야 합니다.

20.4 ARP Cache를 지우면 Network 장애가 해결된다?#

일시적인 잘못된 Entry라면 도움이 될 수 있지만 원인이 IP 충돌이나 Network 설정 오류라면 다시 같은 문제가 발생합니다.

Cache 삭제는 진단 또는 일시적 갱신 방법이지 근본 해결책은 아닙니다.

21장 시험망에서 ARP를 직접 관찰해보자#

21.1 ARP Cache 상태 확인#

먼저 Linux에서:

ip neigh

를 실행합니다.

대상 장비 정보가 없는지 확인합니다.

21.2 Packet Capture 시작#

다른 Terminal에서:

tcpdump -e -n -i eth0 arp

를 실행합니다.

21.3 대상 장비에 통신 시도#

예:

ping 192.168.10.20

ARP Cache에 Entry가 없다면 먼저 ARP 과정이 나타날 수 있습니다.

ARP Request

↓

ARP Reply

↓

ICMP Echo

이 순서를 관찰해보면 ARP와 Ping이 어떻게 연결되는지 이해하기 쉽습니다.

22장 현장에서 사용할 ARP 점검 흐름#

장비가 같은 IPv4 Network에 있는데 통신되지 않는다면 다음 순서로 확인할 수 있습니다.

1. 장비 전원과 Link 확인
        ↓
2. VLAN 확인
        ↓
3. IP Address 확인
        ↓
4. Subnet Mask 확인
        ↓
5. ARP Cache 확인
        ↓
6. ARP Request 발생 여부 확인
        ↓
7. ARP Reply 여부 확인
        ↓
8. Reply MAC이 올바른지 확인
        ↓
9. Switch MAC Table 확인
        ↓
10. TCP / UDP / Application 확인

다른 Network에 있는 장비라면:

Destination 장비 MAC

이 아니라:

Default Gateway MAC

을 ARP하고 있는지도 확인해야 합니다.

23장 핵심 개념 한눈에 정리하기#

개념 역할
ARP IPv4 Address와 Local Link의 MAC Address 연결
ARP Request 대상 IP의 MAC을 묻는 요청
ARP Reply 자신의 MAC 정보를 응답
ARP Cache IP-MAC Mapping을 임시 저장
Gratuitous ARP 자신의 IP-MAC 정보를 능동적으로 알리는 ARP
Proxy ARP 다른 장비를 대신해 ARP에 응답
IP Conflict 둘 이상의 장비가 같은 IPv4 Address 사용
ARP Spoofing 잘못된 ARP 정보를 이용한 위장
DHCP Snooping DHCP Binding을 관리하는 Switch 보안 기능
DAI ARP Packet을 검사하는 Switch 보안 기능

24장 자기 점검#

24.1 ARP Request와 ARP Reply의 차이는 무엇인가#

ARP Request는 대상 IPv4 Address의 MAC을 알아내기 위한 요청이고 일반적으로 Broadcast로 전달됩니다.

ARP Reply는 해당 IPv4 Address를 사용하는 장비가 자신의 MAC을 알려주는 응답이며 일반적으로 요청자에게 Unicast로 전달됩니다.

24.2 ARP Cache는 왜 필요한가#

매번 ARP Request를 반복하지 않고 이미 확인한 IP-MAC Mapping을 재사용하기 위해서입니다.

24.3 다른 Subnet의 Server와 통신할 때 그 Server의 MAC을 ARP로 직접 알아내는가#

일반적인 Routed Network에서는 그렇지 않습니다.

Host는 Default Gateway의 MAC Address를 ARP로 알아내고 Gateway로 Ethernet Frame을 전달합니다.

24.4 IP가 됐다 안 됐다 하면서 ARP Cache의 MAC이 계속 바뀐다면 무엇을 확인할까#

IP Conflict를 우선적으로 확인할 수 있습니다.

같은 IPv4 Address를 사용하는 여러 장비가 존재하는지 IP 할당표와 Switch MAC Table을 함께 확인합니다.

24.5 ARP Table과 Switch MAC Table의 차이는 무엇인가#

ARP Table
IP → MAC

Switch MAC Table
MAC → Port

입니다.

25장 이 글을 마치며#

ARP는 단순히 IP Address를 MAC Address로 바꾸는 작은 기능처럼 보일 수 있습니다.

하지만 Ethernet 기반 IPv4 Network에서는 매우 중요한 연결고리입니다.

전체 흐름을 다시 보면:

Application이
192.168.10.20으로 데이터를 보내려고 한다
        ↓
Subnet Mask로
같은 Network인지 판단한다
        ↓
ARP Cache에서
192.168.10.20의 MAC 확인
        ↓
정보가 없으면 ARP Request
        ↓
ARP Reply 수신
        ↓
IP ↔ MAC Mapping 저장
        ↓
Ethernet Frame 생성
        ↓
Switch가 MAC Table을 보고 전달
        ↓
목적지 장비 도착

다른 Network라면 흐름이 달라집니다.

Destination IP
다른 Network
        ↓
Routing Table 확인
        ↓
Default Gateway 선택
        ↓
Gateway IP의 MAC을 ARP
        ↓
Gateway로 Ethernet Frame 전송

따라서 현장에서:

Ping이 안 된다.

Controller가 Offline이다.

Server에 연결되지 않는다.

라는 증상이 발생했다고 해서 바로 Application을 확인해서는 안 됩니다.

먼저:

같은 Subnet인가?
↓
VLAN은 같은가?
↓
ARP Request가 나가는가?
↓
누가 Reply하는가?
↓
올바른 MAC인가?
↓
Switch는 그 MAC을 어느 Port에서 학습했는가?

를 확인하면 문제 범위를 빠르게 좁힐 수 있습니다.

특히 다음 세 가지를 기억하면 됩니다.

ARP는 IPv4 Address와 MAC Address 사이의 연결고리입니다.

ARP Table과 Switch MAC Address Table은 역할이 다릅니다.

다른 Network로 갈 때는 최종 목적지의 MAC이 아니라 다음 Hop인 Gateway의 MAC을 사용합니다.

이 세 가지가 이해되면 이후 Default Gateway와 Routing이 왜 필요한지도 자연스럽게 이어집니다.

이 페이지의 목차