ARP(Address Resolution Protocol) 완벽 이해
시스템 엔지니어를 위한 네트워크 7편
ARP(Address Resolution Protocol) 완벽 이해
앞선 글에서는 Gateway와 Routing에 대해 알아봤습니다.
서버가 목적지 IP를 확인하고 Routing Table을 검색한 뒤, 목적지 또는 Gateway로 패킷을 전달한다는 것을 살펴봤습니다.
그런데 여기에서 한 가지 중요한 문제가 남습니다.
서버는 목적지의 IP Address는 알고 있습니다.
하지만 Ethernet 통신을 하려면 MAC Address가 필요합니다.
예를 들어 서버가 다음과 같다고 가정해 보겠습니다.
Server IP : 192.168.10.100 MAC : 00:11:22:33:44:55
목적지는:
192.168.10.200
입니다.
서버는 목적지 IP를 알고 있습니다.
하지만 Ethernet Frame을 만들려면 다음 정보가 필요합니다.
Destination MAC = ?
이때 사용하는 프로토콜이 바로 **ARP(Address Resolution Protocol)**입니다.
즉 ARP를 한 문장으로 설명하면:
IPv4 주소를 이용해 같은 L2 네트워크에서 통신할 상대의 MAC Address를 알아내는 프로토콜
입니다.
1. 왜 ARP가 필요한가?
네트워크 통신에는 IP와 MAC이 함께 사용됩니다.
OSI 관점에서 보면:
L3
IP Address
↓
어느 장비로 갈 것인가?
L2
MAC Address
↓
현재 Ethernet 구간에서 어느 장비로 Frame을 전달할 것인가?
예를 들어:
Source 192.168.10.100 Destination 192.168.10.200
IP만 알고 있어서는 Ethernet Frame을 만들 수 없습니다.
Ethernet Frame에는 다음과 같은 정보가 필요합니다.
+-----------------------------+ | Destination MAC | +-----------------------------+ | Source MAC | +-----------------------------+ | EtherType | +-----------------------------+ | Payload | +-----------------------------+
따라서:
192.168.10.200
↓
MAC Address 확인
↓
Ethernet Frame 생성
↓
Switch 전달
과정이 필요합니다.
이때 IP → MAC Address 변환을 담당하는 것이 ARP입니다.
2. ARP의 기본 구조
ARP가 동작하는 기본적인 구조를 먼저 보겠습니다.
Server A
IP : 192.168.10.100
MAC : AA:AA:AA:AA:AA:AA
|
| ARP Request
|
v
"192.168.10.200의 MAC 주소가 누구인가?"
|
| Broadcast
v
+-------------------+
| Switch |
+-------------------+
| | |
v v v
Server B Server C Server D
192.168.10.200
MAC : BB:BB:BB:BB:BB:BB
|
| ARP Reply
|
v
"192.168.10.200은
BB:BB:BB:BB:BB:BB 입니다."
결과적으로 Server A는 다음 정보를 얻습니다.
192.168.10.200
↓
BB:BB:BB:BB:BB:BB
그리고 이 정보를 이용해 Ethernet Frame을 생성합니다.
3. ARP Request
서버가 목적지의 MAC Address를 모르는 상태라고 생각해 보겠습니다.
Server A:
IP = 192.168.10.100
Server B:
IP = 192.168.10.200
Server A는 다음과 같이 질문합니다.
Who has 192.168.10.200? Tell 192.168.10.100
이것이 ARP Request입니다.
그런데 Server A는 Server B의 MAC Address를 모릅니다.
그렇다면 이 요청을 특정 MAC Address로 보낼 수 없습니다.
따라서 ARP Request는 Broadcast로 전송됩니다.
Ethernet Broadcast MAC은:
FF:FF:FF:FF:FF:FF
입니다.
즉:
Destination MAC FF:FF:FF:FF:FF:FF
가 됩니다.
4. ARP Request는 왜 Broadcast인가?
ARP Request를 처음 보내는 시점에는 상대방 MAC Address를 모릅니다.
따라서 특정 MAC으로 보낼 수 없습니다.
그래서 같은 Broadcast Domain에 있는 모든 장비에게 물어봅니다.
"192.168.10.200인 장비 누구야?"
네트워크 구조로 보면:
ARP Request
|
v
FF:FF:FF:FF:FF:FF
|
+---+---+
| Switch|
+---+---+
/ | \
/ | \
v v v
PC A PC B PC C
|
192.168.10.200
모든 장비가 ARP Request를 받을 수 있지만:
Target IP = 192.168.10.200
인 장비만 응답합니다.
5. ARP Reply
Server B가 ARP Request를 받았습니다.
자신의 IP가:
192.168.10.200
이므로 응답합니다.
ARP Reply:
192.168.10.200 is-at BB:BB:BB:BB:BB:BB
즉:
192.168.10.200
↓
BB:BB:BB:BB:BB:BB
입니다.
ARP Reply는 일반적으로 요청한 장비의 MAC Address를 알고 있으므로 Unicast로 응답할 수 있습니다.
전체 과정은:
Server A
192.168.10.100
|
| ARP Request
| Broadcast
|
v
Switch
|
v
Server B
192.168.10.200
|
| ARP Reply
| Unicast
|
v
Server A
입니다.
6. ARP 전체 과정을 패킷 관점에서 이해하기
실제 통신 과정을 단계별로 보면 다음과 같습니다.
Step 1. 애플리케이션이 통신 요청
예:
ping 192.168.10.200
Step 2. Linux Kernel이 목적지 확인
Destination 192.168.10.200
Step 3. Routing 확인
192.168.10.0/24 dev ens160
같은 네트워크이므로 직접 통신합니다.
Step 4. ARP Cache 확인
192.168.10.200 → ?
MAC Address가 없다면 ARP Request를 발생시킵니다.
Step 5. ARP Request
Who has 192.168.10.200?
Step 6. ARP Reply
192.168.10.200 is-at BB:BB:BB:BB:BB:BB
Step 7. ARP Cache 저장
192.168.10.200
↓
BB:BB:BB:BB:BB:BB
Step 8. Ethernet Frame 생성
SRC MAC = Server A DST MAC = Server B
Step 9. 실제 IP Packet 전달
SRC IP = 192.168.10.100 DST IP = 192.168.10.200
이제 정상적으로 통신할 수 있습니다.
7. ARP Cache란 무엇인가?
매번 통신할 때마다 ARP Request를 보내면 네트워크에 불필요한 Broadcast가 계속 발생합니다.
그래서 운영체제는 ARP 결과를 일정 시간 동안 저장합니다.
이것이 ARP Cache입니다.
Linux에서는 다음 명령어로 확인할 수 있습니다.
ip neigh
예:
192.168.10.1 dev ens160 lladdr 00:11:22:33:44:01 REACHABLE 192.168.10.200 dev ens160 lladdr 00:11:22:33:44:02 REACHABLE
구조는 다음과 같습니다.
IP Address
|
v
MAC Address
|
v
State
예:
192.168.10.200
|
v
00:11:22:33:44:02
|
v
REACHABLE
8. ip neigh란 무엇인가?
최근 Linux에서는 과거의 arp 명령어보다 다음 명령어를 사용하는 것이 일반적입니다.
ip neigh
특정 IP만 확인하려면:
ip neigh show 192.168.10.1
예:
192.168.10.1 dev ens160 lladdr 00:11:22:33:44:01 REACHABLE
의미:
IP 192.168.10.1 Interface ens160 MAC 00:11:22:33:44:01 State REACHABLE
9. ARP 상태(State)의 의미
ip neigh를 사용하다 보면 다양한 상태를 볼 수 있습니다.
대표적인 상태는 다음과 같습니다.
상태의미REACHABLE최근 정상적으로 통신 가능STALE오래된 정보이지만 아직 Cache에 존재DELAY재확인이 필요한 상태PROBE상대방 응답 확인 중INCOMPLETEMAC Address를 아직 확인하지 못함FAILEDNeighbor 확인 실패PERMANENT영구적으로 설정된 Neighbor
특히 장애 분석에서는:
INCOMPLETE FAILED
상태를 중요하게 봐야 합니다.
10. ARP INCOMPLETE가 중요한 이유
다음과 같은 결과가 있다고 가정해 보겠습니다.
ip neigh
결과:
192.168.10.200 dev ens160 INCOMPLETE
이것은:
192.168.10.200의 MAC Address를 알아내려고 했지만 정상적으로 확인하지 못했다.는 의미입니다.
즉:
ARP Request
|
v
Who has 192.168.10.200?
|
X
ARP Reply 없음
일 가능성이 높습니다.
이 경우 다음을 의심해야 합니다.
1. 상대 서버 Down 2. 잘못된 IP 3. 잘못된 Subnet 4. 잘못된 VLAN 5. Switch 문제 6. NIC 문제 7. 네트워크 케이블/링크 문제 8. 중간 네트워크 장비 문제
11. Gateway도 ARP를 사용한다
ARP를 이해할 때 가장 중요한 부분입니다.
목적지가 다른 네트워크에 있다면 어떻게 될까요?
서버:
192.168.10.100/24
Gateway:
192.168.10.1
목적지:
192.168.20.100
서버는 목적지가 다른 네트워크라는 것을 확인합니다.
따라서 목적지 서버의 MAC Address를 찾는 것이 아닙니다.
Gateway의 MAC Address를 찾습니다.
즉:
Destination IP
192.168.20.100
|
v
다른 네트워크
|
v
Gateway 사용
|
v
ARP
|
v
192.168.10.1의 MAC 확인
이것이 매우 중요합니다.
12. 다른 네트워크로 통신할 때의 ARP
다음과 같은 구조를 생각해 보겠습니다.
Server
192.168.10.100/24
|
|
Gateway
192.168.10.1
|
|
Router
|
|
192.168.20.100
Server가:
192.168.20.100
으로 통신합니다.
ARP Request는 다음과 같은 내용이 됩니다.
Who has 192.168.10.1?
절대로:
Who has 192.168.20.100?
가 아닙니다.
왜냐하면 192.168.20.100은 현재 서버가 직접 연결된 L2 네트워크에 존재하지 않기 때문입니다.
서버는 Gateway의 MAC Address를 알아낸 뒤 Frame을 Gateway로 전달합니다.
13. IP와 MAC의 차이
ARP를 제대로 이해하려면 IP와 MAC의 역할을 구분해야 합니다.
IP Address → 논리적인 주소 → L3 → 최종 목적지를 식별 MAC Address → 물리/링크 계층 주소 → L2 → 현재 Ethernet 구간의 장비 식별
예를 들어:
Server IP = 192.168.10.100 MAC = AA:AA:AA:AA:AA:AA
목적지:
IP = 192.168.20.100
Gateway:
IP = 192.168.10.1 MAC = BB:BB:BB:BB:BB:BB
서버가 만드는 첫 번째 Frame:
Ethernet -------------------------------- SRC MAC = AA:AA:AA:AA:AA:AA DST MAC = BB:BB:BB:BB:BB:BB IP -------------------------------- SRC IP = 192.168.10.100 DST IP = 192.168.20.100
즉:
MAC → 현재 홉 IP → 최종 목적지
라는 개념으로 이해하면 좋습니다.
14. tcpdump로 ARP 확인하기
이제 실제 패킷을 확인해 보겠습니다.
Linux에서 가장 유용한 명령어 중 하나입니다.
tcpdump -e -nn -i ens160 arp
옵션을 보면:
-e Ethernet Header 표시 -nn IP와 Port를 이름으로 변환하지 않음 -i ens160 ens160 인터페이스 캡처 arp ARP 패킷만 표시
15. ARP Request를 tcpdump에서 확인
다음 명령어를 실행합니다.
tcpdump -e -nn -i ens160 arp
그리고:
ping 192.168.10.200
을 실행합니다.
예상되는 출력은 다음과 비슷합니다.
ARP, Request who-has 192.168.10.200 tell 192.168.10.100
의미:
192.168.10.200 누구야? 192.168.10.100이 물어봄
Ethernet MAC 관점에서는:
SRC MAC Server MAC DST MAC ff:ff:ff:ff:ff:ff
입니다.
16. ARP Reply를 tcpdump에서 확인
상대방이 응답하면:
ARP, Reply 192.168.10.200 is-at 00:11:22:33:44:55
처럼 나타납니다.
즉:
192.168.10.200
|
v
00:11:22:33:44:55
라는 정보를 얻은 것입니다.
그 이후 실제 ICMP Packet이 전달됩니다.
17. ARP + ICMP를 동시에 확인
ARP와 Ping을 같이 보고 싶다면:
tcpdump -e -nn -i ens160 'arp or icmp'
실행:
ping 192.168.10.200
정상적인 흐름은 대략:
ARP Request
↓
ARP Reply
↓
ICMP Echo Request
↓
ICMP Echo Reply
입니다.
이것을 패킷 수준에서 직접 확인하면 ARP의 역할이 매우 명확해집니다.
18. ARP Request는 보이는데 Reply가 없다
가장 대표적인 ARP 장애입니다.
tcpdump:
ARP, Request who-has 192.168.10.200 tell 192.168.10.100 ARP, Request who-has 192.168.10.200 tell 192.168.10.100 ARP, Request who-has 192.168.10.200 tell 192.168.10.100
그런데:
ARP Reply
가 없습니다.
이 경우:
Server A | | ARP Request v Switch | X | Server B
가 됩니다.
가능한 원인:
Server B Down NIC Down VLAN 문제 Switch Port 문제 잘못된 IP 잘못된 Subnet 네트워크 분리
19. ARP Request 자체가 보이지 않는다면?
반대로:
tcpdump -e -nn -i ens160 arp
를 실행했는데 ARP 패킷 자체가 발생하지 않는 경우도 있습니다.
이때는 다음을 확인해야 합니다.
ip route
그리고:
ip neigh
또한 인터페이스 상태:
ip link show ens160
IP:
ip -4 addr show ens160
를 확인합니다.
특히 목적지가 실제로 해당 Interface를 통해 나가는지:
ip route get 192.168.10.200
확인해야 합니다.
20. 잘못된 Subnet과 ARP
ARP 장애를 분석할 때 Subnet Mask가 매우 중요합니다.
예를 들어:
Server A:
192.168.10.100/24
Server B:
192.168.20.100/24
서버 A 입장에서 B는 다른 네트워크입니다.
따라서:
ARP → Gateway
가 발생해야 합니다.
그런데 잘못된 Subnet이 설정되어:
Server A 192.168.10.100/16
이라면 상황이 달라집니다.
Server A는:
192.168.20.100
을 같은 네트워크라고 판단할 수 있습니다.
그러면 Gateway가 아니라 직접 ARP를 시도할 수 있습니다.
Who has 192.168.20.100?
결과적으로 통신이 실패할 수 있습니다.
이것이 잘못된 Subnet Mask가 만들어내는 대표적인 ARP 장애입니다.
21. 잘못된 VLAN과 ARP
실제 기업 네트워크에서는 VLAN 문제도 매우 자주 발생합니다.
예를 들어:
Server VLAN 100 192.168.10.100
상대방:
Server VLAN 200 192.168.10.200
같은 IP 대역을 사용하더라도 L2 Broadcast Domain이 분리되어 있다면 서로 ARP Broadcast를 전달받지 못할 수 있습니다.
구조:
VLAN 100
192.168.10.0/24
X
VLAN 200
192.168.10.0/24
서버에서:
ip neigh
가:
192.168.10.200 INCOMPLETE
로 나타날 수 있습니다.
tcpdump:
ARP Request
는 계속 발생하지만:
ARP Reply
가 보이지 않을 수 있습니다.
이 경우 서버만 보지 말고 Switch의 VLAN과 Port 설정까지 확인해야 합니다.
22. Duplicate IP와 ARP
실무에서 매우 위험한 문제 중 하나가 IP 중복입니다.
예를 들어:
Server A 192.168.10.100 MAC = AA:AA:AA:AA:AA:AA
Server B도:
192.168.10.100 MAC = BB:BB:BB:BB:BB:BB
를 사용한다고 가정하겠습니다.
그러면 네트워크에서는:
192.168.10.100
|
+---- AA:AA:AA:AA:AA:AA
|
+---- BB:BB:BB:BB:BB:BB
라는 충돌이 발생합니다.
ARP Cache가:
192.168.10.100 → AA:AA:AA:AA:AA:AA
였다가:
192.168.10.100 → BB:BB:BB:BB:BB:BB
로 변경될 수 있습니다.
결과적으로 통신이 간헐적으로 실패하는 현상이 발생할 수 있습니다.
23. Duplicate IP를 어떻게 확인하는가?
다음 명령어를 사용할 수 있습니다.
arping -D -I ens160 192.168.10.100
-D는 Duplicate Address Detection 용도로 사용합니다.
또는 특정 IP의 응답을 확인합니다.
arping -I ens160 192.168.10.100
MAC Address가 예상과 다르게 응답하거나 여러 장비에서 이상한 응답이 나타난다면 IP 중복을 의심할 수 있습니다.
24. Gratuitous ARP란?
ARP에는 일반적인 Request/Reply 외에도 중요한 개념이 있습니다.
바로 **Gratuitous ARP(GARP)**입니다.
쉽게 말하면:
자신의 IP와 MAC 정보를 네트워크에 알리는 ARP 패킷
이라고 이해할 수 있습니다.
예를 들어 서버가:
192.168.10.100 MAC = AA:AA:AA:AA:AA:AA
를 사용한다고 가정합니다.
서버가 자신의 정보를 알립니다.
Who has 192.168.10.100? 192.168.10.100 is-at AA:AA:AA:AA:AA:AA
주요 용도는:
1. ARP Cache 갱신 2. IP 변경 알림 3. Failover 4. HA 구성 5. IP 이동
등입니다.
25. HA 환경에서 GARP가 중요한 이유
고가용성 환경을 생각해 보겠습니다.
Virtual IP
192.168.10.100
|
+------+------+
| |
Server A Server B
MASTER BACKUP
현재 Server A가 장애가 발생하고 Server B가 서비스를 인계받습니다.
그러면:
192.168.10.100
이라는 Virtual IP가 Server B의 MAC Address를 사용해야 합니다.
네트워크 장비나 다른 서버가 기존 MAC 정보를 계속 가지고 있다면 문제가 발생할 수 있습니다.
그래서 Server B가 GARP를 전송하여:
192.168.10.100
↓
새로운 MAC
정보를 주변 장비에 알려줄 수 있습니다.
Linux HA, VRRP, Keepalived 등의 환경에서 GARP가 중요한 이유입니다.
26. ARP Cache를 직접 삭제하기
장애 테스트 또는 문제 해결 과정에서 Neighbor Cache를 초기화해야 하는 경우가 있습니다.
특정 Neighbor 삭제:
ip neigh del 192.168.10.200 dev ens160
확인:
ip neigh show 192.168.10.200
다시 통신을 시도하면:
ping 192.168.10.200
새로운 ARP 과정이 발생할 수 있습니다.
주의할 점은 운영 서버에서 무작정 Neighbor 정보를 삭제하면 일시적인 통신 영향이 발생할 수 있으므로 상황을 확인하고 사용해야 합니다.
27. ARP 장애 분석 실전
다음과 같은 장애를 가정하겠습니다.
Server A IP : 192.168.10.100/24 NIC : ens160 Server B IP : 192.168.10.200/24
문제:
ping 192.168.10.200
실패
Step 1. IP 확인
ip -4 addr show ens160
정상:
192.168.10.100/24
Step 2. Routing 확인
ip route get 192.168.10.200
예:
192.168.10.200 dev ens160 src 192.168.10.100
정상입니다.
Step 3. Neighbor 확인
ip neigh show 192.168.10.200
결과:
192.168.10.200 dev ens160 INCOMPLETE
ARP 문제가 의심됩니다.
Step 4. tcpdump
tcpdump -e -nn -i ens160 arp
결과:
ARP Request who-has 192.168.10.200 ARP Request who-has 192.168.10.200 ARP Request who-has 192.168.10.200
Reply가 없습니다.
Step 5. 원인 범위 좁히기
현재까지:
IP 정상 Routing 정상 ARP Request 정상적으로 발생 ARP Reply 없음
따라서 다음을 확인합니다.
Server B ↓ NIC ↓ Switch Port ↓ VLAN ↓ Switch
이렇게 장애 범위를 좁힐 수 있습니다.
28. Gateway ARP 장애 실전
이번에는 외부 네트워크로 통신이 안 되는 상황입니다.
Server:
192.168.10.100/24
Gateway:
192.168.10.1
목적지:
8.8.8.8
Step 1
ip route
확인:
default via 192.168.10.1 dev ens160
Route는 존재합니다.
Step 2
ip neigh show 192.168.10.1
결과:
192.168.10.1 dev ens160 INCOMPLETE
Gateway MAC을 찾지 못하고 있습니다.
Step 3
tcpdump -e -nn -i ens160 arp
결과:
ARP Request who-has 192.168.10.1 ARP Request who-has 192.168.10.1 ARP Request who-has 192.168.10.1
하지만:
ARP Reply
가 없습니다.
이제 외부 인터넷 문제가 아니라 서버와 Gateway 사이의 L2 통신 문제로 범위를 좁힐 수 있습니다.
29. ARP 장애 분석의 핵심
ARP 장애를 분석할 때 가장 중요한 질문은 다음 세 가지입니다.
1. ARP Request가 나가는가?
tcpdump -nn -i ens160 arp
2. ARP Reply가 들어오는가?
Request ↓ Reply
두 패킷이 모두 있는지 확인합니다.
3. Neighbor 상태가 무엇인가?
ip neigh
예:
REACHABLE
이면 정상 가능성이 높습니다.
INCOMPLETE FAILED
이면 ARP/Neighbor 문제가 의심됩니다.
30. ARP 장애 분석 명령어 정리
현장에서 자주 사용하는 명령어를 정리하면 다음과 같습니다.
Neighbor Table
ip neigh
특정 IP
ip neigh show 192.168.10.1
ARP 직접 테스트
arping -I ens160 192.168.10.1
ARP Packet Capture
tcpdump -e -nn -i ens160 arp
ARP + ICMP
tcpdump -e -nn -i ens160 'arp or icmp'
전체 인터페이스 확인
ip link
IP 확인
ip -4 addr
Routing 확인
ip route
특정 목적지 경로
ip route get 192.168.10.200
31. ARP 장애 분석 전체 흐름
실제 시스템 엔지니어라면 다음 순서로 접근하는 것이 좋습니다.
통신 장애
|
v
목적지 IP 확인
|
v
ip route get <destination>
|
v
직접 통신인가?
|
/ \
Yes No
| |
| v
| Gateway 확인
| |
| v
| ip neigh
| |
+-----+
|
v
MAC Address 존재?
|
/ \
Yes No
| |
| v
| ARP Request
| |
| v
| ARP Reply?
| |
| / \
| Yes No
| | |
| | v
| | L2/VLAN/NIC
| |
+--+
|
v
Ethernet Frame
|
v
ICMP/TCP
이 흐름을 머릿속에 가지고 있으면 ARP 장애를 훨씬 빠르게 분석할 수 있습니다.
32. ARP와 Switch의 관계
ARP를 이해하려면 Switch의 역할도 같이 이해해야 합니다.
ARP Request는:
Destination MAC FF:FF:FF:FF:FF:FF
Broadcast입니다.
Switch는 이 Broadcast Frame을 같은 VLAN의 여러 Port로 전달합니다.
Switch
+-----------+
| |
+-----------+
/ | \
/ | \
v v v
Server A Server B Server C
하지만 ARP Reply는 상대방의 MAC Address를 알고 있기 때문에 Unicast로 전달할 수 있습니다.
Server B | | ARP Reply v Switch | | Unicast v Server A
따라서:
ARP는 IP와 MAC을 연결하고, Switch는 MAC Address를 이용해 Ethernet Frame을 전달한다.
라고 이해하면 좋습니다.
33. ARP와 Routing의 관계
ARP와 Routing은 별개의 개념이지만 실제 패킷 전달 과정에서는 함께 동작합니다.
예:
Destination 192.168.20.100
서버:
192.168.10.100/24
먼저 Routing이 판단합니다.
192.168.20.100
↓
다른 네트워크
↓
Gateway 사용
그 다음 ARP가 동작합니다.
Gateway IP
192.168.10.1
↓
ARP
↓
Gateway MAC
AA:BB:CC:DD:EE:01
그리고 Ethernet Frame이 만들어집니다.
DST MAC = Gateway MAC SRC MAC = Server MAC DST IP = 192.168.20.100 SRC IP = 192.168.10.100
즉:
Routing
"어디로 보낼 것인가?"
↓
ARP
"그 다음 장비의 MAC이 무엇인가?"
↓
Ethernet
"실제로 Frame을 어떻게 전달할 것인가?"
입니다.
34. ARP를 한 문장으로 정리하면
ARP의 핵심은 다음 한 문장으로 정리할 수 있습니다.
IPv4 통신에서 목적지 또는 Next Hop의 IP Address를 실제 Ethernet 통신에 필요한 MAC Address로 확인하는 과정이다.
그리고 전체 구조는:
Destination IP
|
v
Routing Table
|
v
Direct 또는 Gateway
|
v
ARP
|
v
MAC Address
|
v
Ethernet Frame
|
v
Switch
|
v
Next Hop
입니다.
35. 시스템 엔지니어가 반드시 기억해야 할 핵심
ARP를 공부할 때 단순히:
ARP = IP → MAC
만 외우면 부족합니다.
다음 내용을 함께 기억해야 합니다.
1. 같은 네트워크 통신
Destination IP
↓
ARP
↓
Destination MAC
2. 다른 네트워크 통신
Destination IP
↓
Routing
↓
Gateway 선택
↓
Gateway IP
↓
ARP
↓
Gateway MAC
3. ARP Request
Broadcast FF:FF:FF:FF:FF:FF
4. ARP Reply
일반적으로 요청한 Host로 Unicast 응답
5. Linux 확인
ip neigh
6. 패킷 확인
tcpdump -e -nn -i ens160 arp
7. ARP 장애의 대표적인 상태
INCOMPLETE FAILED
8. 주요 장애 원인
NIC VLAN Switch IP Subnet Gateway Duplicate IP Network Equipment
마무리
ARP는 단순히 "IP 주소를 MAC 주소로 바꾸는 프로토콜"이라고 외우고 끝낼 내용이 아닙니다.
실제 서버에서 패킷이 전달되는 과정을 이해하려면 다음 흐름을 정확하게 이해해야 합니다.
Application
|
v
Destination IP
|
v
Routing Table
|
+----------------------+
| |
같은 네트워크 다른 네트워크
| |
v v
Destination IP Gateway IP
| |
+----------+-----------+
|
v
ARP
|
v
MAC Address
|
v
Ethernet Frame
|
v
Switch
|
v
Next Hop
그리고 장애가 발생했을 때는 단순히 ping만 실행하는 것이 아니라:
ip route get <destination> ip neigh arping -I ens160 <gateway> tcpdump -e -nn -i ens160 arp tcpdump -e -nn -i ens160 'arp or icmp'
를 이용해 실제 ARP Request와 Reply가 발생하는지 직접 확인해야 합니다.
특히 다음과 같은 상황은 현장에서 매우 중요한 장애 패턴입니다.
ARP Request O ARP Reply X
이 경우에는 서버에서 Gateway 또는 목적지까지의 L2 통신 경로를 집중적으로 확인해야 합니다.
반대로:
ARP Request O ARP Reply O ICMP Request O ICMP Reply X
라면 ARP 자체는 정상입니다.
이제 장애 분석 범위는 L2에서 L3 Routing, Firewall, 목적지 서버 등으로 이동합니다.
결국 ARP를 제대로 이해한다는 것은 단순히 ARP 프로토콜 하나를 배우는 것이 아니라,
IP → Routing → Gateway → ARP → MAC → Ethernet → Switch
로 이어지는 실제 패킷 전달 과정을 이해하는 것입니다.
다음 편에서는 여기에서 한 단계 더 나아가 TCP와 UDP를 다루겠습니다.
특히 실제 서버 장애 분석에서 매우 중요한:
TCP vs UDP
↓
Port
↓
Socket
↓
TCP SYN
↓
SYN-ACK
↓
ACK
↓
Connection
의 구조를 살펴보고, ss, nc, tcpdump를 이용해 **"Ping은 되는데 서버 접속은 안 되는 이유"**를 실제 장애 사례와 함께 분석해 보겠습니다.
ARP와 IPv6 차이를 짧게 덧붙여줘중복 설명을 줄이고 글을 압축해줘
댓글
아직 댓글이 없습니다.
로그인 후 댓글을 남길 수 있습니다.