사내망에서 한 개발 서버가 접속됐다 끊겼다를 반복합니다. IP는 맞고 스위치 포트도 살아 있는데, 같은 주소를 쓰는 장비가 네트워크 어딘가에 숨어 있습니다.
ARP 캐시를 볼 줄 모르면 이 문제는 "간헐적 네트워크 장애"로만 남습니다. MAC 주소 단서로 충돌 장비를 좁혀야 합니다.
ARP 캐시와 사내망 IP 충돌 확인
사내망에서 갑자기 특정 서버로의 통신이 끊겼다가 다시 살아나는 현상, 경험해본 적 있는가? 원인 중 하나가 **IP 충돌(IP Conflict)**이다. 이 챕터에서는 ARP 프로토콜의 역할을 이해하고, arp -an과 arping을 사용해 IP 충돌을 진단하는 방법을 배운다.
- 1ARP(Address Resolution Protocol)의 역할과 IP-MAC 주소 변환 원리
- 2arp -an / ip neigh show 명령어로 ARP 캐시 테이블 확인 및 해석
- 3IP 충돌(IP Conflict)의 발생 원인과 간헐적 ping 끊김 증상
- 4arping으로 동일 IP에 응답하는 장비 수를 확인하여 충돌 확정
- 5ip neigh flush로 ARP 캐시 초기화 및 tcpdump로 ARP 트래픽 관찰
- 6IP 충돌 발생 시 네트워크 팀에 리포팅하는 정보 수집 방법
arp -anip neigh showwhich arping || sudo yum install -y iputilssudo arping -I eth0 -c 5 <대상 IP>ARP란 무엇인가 — IP 주소를 MAC 주소로 변환하는 프로토콜
새로 추가한 서버가 같은 서브넷의 다른 서버와 통신이 간헐적으로 끊깁니다. IP는 맞는데 ping이 응답했다 안 했다 합니다. 알고 보니 같은 IP를 가진 다른 서버가 네트워크에 잡혀 있는 IP 충돌 상황이었습니다. ARP가 어떻게 동작하는지 알아야 이런 충돌 증상을 진단하고 arping으로 원인을 찾을 수 있습니다.
인터넷 통신은 IP 주소를 기반으로 이루어지지만, 실제로 같은 네트워크 세그먼트(LAN) 안에서 프레임을 주고받을 때는 MAC 주소가 필요하다. IP 주소만 알고 있다면 어떻게 MAC 주소를 알 수 있을까? 이 역할을 하는 것이 **ARP(Address Resolution Protocol)**이다.
ARP 동작 원리
[내 PC: 192.168.1.10] [스위치] [목적지: 192.168.1.20]
| | |
| ARP Request (브로드캐스트) | |
| "192.168.1.20의 MAC는?" ---->--------------------> |
| | |
| | ARP Reply (유니캐스트)
| <---------------------------- "나야, MAC: aa:bb:cc:dd:ee:ff"
| | |
[ARP 캐시에 저장]
192.168.1.20 → aa:bb:cc:dd:ee:ff
- 내 PC가
192.168.1.20으로 패킷을 보내려 할 때, MAC 주소를 모른다면 ARP Request를 브로드캐스트로 전송한다. 192.168.1.20을 가진 장비가 자신의 MAC 주소를 포함한 ARP Reply를 유니캐스트로 돌려보낸다.- 내 PC는 이 정보를 **ARP 캐시(ARP 테이블)**에 저장한다. 이후에는 캐시를 참조해 바로 통신한다.
ARP 캐시의 TTL
ARP 캐시는 영구적이지 않다. 리눅스 기본값으로 약 60초(soft TTL) 이후 stale 상태가 되고 300초(hard TTL) 이후 삭제된다. 덕분에 IP 재할당 등으로 MAC이 바뀌더라도 시간이 지나면 자동으로 갱신된다.
현재 시스템의 ARP 캐시를 확인하는 가장 기본적인 명령어는 arp -an이다.
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part4/exam_19 && cd /tmp/networking/part4/exam_19
$ arp -an
? (192.168.1.1) at 00:11:22:33:44:55 [ether] on eth0
? (192.168.1.30) at aa:bb:cc:11:22:33 [ether] on eth0
? (192.168.1.50) at <incomplete> on eth0
? (192.168.1.100) at ff:ee:dd:cc:bb:aa [ether] on eth0
- 핵심 출력—명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
- 대상 식별—IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
- 다음 분기—결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다
각 컬럼의 의미: ARP 테이블 출력에서 각 필드가 의미하는 바입니다.
| 컬럼 | 설명 |
|---|---|
? (192.168.1.1) | IP 주소 (-a는 호스트명, -n은 숫자 표시) |
at 00:11:22:33:44:55 | 해당 IP의 MAC 주소 |
[ether] | 이더넷 인터페이스 |
on eth0 | 어느 인터페이스에서 학습했는지 |
<incomplete> | ARP 요청을 보냈으나 응답 없음 |
유용한 옵션 조합
# 특정 인터페이스의 ARP 테이블만 보기
arp -an -i eth0
# ip 명령어로 neighbor 테이블 확인 (더 자세한 정보)
ip neigh show
# ip neigh 출력 예시
# 192.168.1.1 dev eth0 lladdr 00:11:22:33:44:55 REACHABLE
# 192.168.1.50 dev eth0 INCOMPLETE
# 192.168.1.30 dev eth0 lladdr aa:bb:cc:11:22:33 STALE
STALE 상태란? 캐시가 만료 기간에 가까워져 다음 통신 시 재확인이 필요한 상태이다. 통신에 즉각적인 문제는 없다.
IP 충돌(IP Conflict)이란 무엇인가
신규 서버를 추가했더니 기존 서버가 간헐적으로 네트워크에서 사라집니다. 재시작하면 잠깐 돌아오다가 또 먹통이 됩니다. 알고 보니 새 서버에 기존 서버와 같은 IP를 실수로 배정한 것이었습니다. IP 충돌이 어떤 상황에서 발생하고 어떤 증상으로 나타나는지 알아야 이 상황을 빠르게 진단할 수 있습니다.
같은 네트워크 세그먼트에 동일한 IP 주소를 가진 장비가 두 대 이상 존재하는 상황을 IP 충돌이라고 한다.
발생 원인
- 정적 IP 수동 설정 실수: 담당자가 이미 사용 중인 IP를 다른 서버에 할당
- DHCP 범위와 정적 IP 범위 겹침: DHCP 풀이 정적으로 할당된 IP 범위를 침범
- VM/컨테이너 복제: 동일한 네트워크 설정을 가진 VM을 복제할 때 IP 중복
- VPN 연결: VPN으로 연결된 원격 장비와 사내망 IP가 겹침
IP 충돌 시 증상
정상 상태:
A (192.168.1.50, MAC: aa:bb:cc:...) ──→ 스위치 ──→ 목적지 서버
IP 충돌 상태:
A (192.168.1.50, MAC: aa:bb:cc:...) ──┐
├──→ 스위치 ──→ 목적지 서버 (ARP 혼란)
B (192.168.1.50, MAC: dd:ee:ff:...) ──┘
결과:
- ARP 캐시에 192.168.1.50 → MAC이 A와 B 사이를 왔다갔다 함
- 패킷이 A 또는 B로 번갈아 전달됨
- 연결이 간헐적으로 끊기거나 엉뚱한 서버로 트래픽이 흘러감
전형적인 증상 패턴
ping 192.168.1.50시 응답이 왔다 안 왔다 함- 같은 서버에 SSH 접속했는데 갑자기 다른 서버의 응답이 옴
- Windows 시스템이라면 "IP 주소 충돌이 감지되었습니다" 팝업 등장
arp -an결과에서 동일 IP의 MAC 주소가 계속 변경됨
arping은 ARP 레벨에서 특정 IP에 요청을 보내 응답을 확인하는 도구이다. 일반 ping이 ICMP를 사용하는 것과 달리, arping은 L2(데이터링크) 레벨에서 동작하므로 ICMP가 차단된 환경에서도 동작한다.
arping 설치 확인
# CentOS/RHEL
sudo yum install -y iputils
# Ubuntu/Debian
sudo apt-get install -y arping
# 또는 iputils 패키지에 포함된 arping 사용
which arping
기본 사용법
# 형식: arping -I [인터페이스] -c [횟수] [IP주소]
sudo arping -I eth0 -c 5 192.168.1.50
정상 응답 (충돌 없음): 하나의 MAC 주소에서만 응답이 옵니다.
ARPING 192.168.1.50 from 192.168.1.10 eth0
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.203ms
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.187ms
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.195ms
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.201ms
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.198ms
Sent 5 probes (1 broadcast(s))
Received 5 response(s)
→ 동일한 MAC 주소만 응답. 정상이다.
IP 충돌 응답 (두 장비가 동일 IP 사용): 서로 다른 MAC에서 동일 IP로 응답하면 충돌입니다.
ARPING 192.168.1.50 from 192.168.1.10 eth0
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.203ms
Unicast reply from 192.168.1.50 [dd:ee:ff:11:22:33] 1.540ms
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.199ms
Unicast reply from 192.168.1.50 [dd:ee:ff:11:22:33] 1.601ms
Unicast reply from 192.168.1.50 [aa:bb:cc:dd:ee:ff] 1.207ms
Sent 5 probes (1 broadcast(s))
Received 5 response(s)
→ 두 가지 다른 MAC 주소(aa:bb:cc:dd:ee:ff와 dd:ee:ff:11:22:33)에서 교대로 응답. IP 충돌 확정!
MAC 주소로 장비 식별하기
충돌하는 MAC 주소를 파악했다면, MAC의 앞 6자리(OUI)로 제조사를 추측하거나 DHCP 서버 로그에서 해당 MAC의 등록 정보를 찾을 수 있다.
# OUI 조회 (온라인 도구 또는 로컬 DB)
# MAC aa:bb:cc:dd:ee:ff 에서 aa:bb:cc 가 OUI (제조사 코드)
# DHCP 서버(ISC DHCP)에서 MAC으로 장비 찾기
sudo grep "dd:ee:ff:11:22:33" /var/lib/dhcpd/dhcpd.leases
IP 충돌 문제를 해결한 후, 또는 테스트를 위해 ARP 캐시를 직접 초기화하는 방법이다.
# 특정 IP의 ARP 캐시 항목 삭제
sudo arp -d 192.168.1.50
# 또는 ip 명령어로 삭제
sudo ip neigh del 192.168.1.50 dev eth0
# ARP 캐시 전체 비우기
sudo ip neigh flush all
# 특정 인터페이스의 ARP 캐시만 비우기
sudo ip neigh flush dev eth0
강제 ARP 갱신 확인
# 캐시를 지운 후 ping을 한 번 보내면 ARP가 다시 발생
sudo ip neigh del 192.168.1.50 dev eth0
ping -c 1 192.168.1.50
# 갱신된 ARP 캐시 확인
ip neigh show | grep 192.168.1.50
tcpdump로 ARP 트래픽 직접 관찰
# ARP 패킷만 캡처
sudo tcpdump -i eth0 -n arp
# 특정 IP 관련 ARP만
sudo tcpdump -i eth0 -n "arp and host 192.168.1.50"
# 출력 예시:
# 14:23:01 ARP, Request who-has 192.168.1.50 tell 192.168.1.10
# 14:23:01 ARP, Reply 192.168.1.50 is-at aa:bb:cc:dd:ee:ff
# 14:23:01 ARP, Reply 192.168.1.50 is-at dd:ee:ff:11:22:33 ← 충돌!
상황
오전에는 잘 되던 DB 서버(192.168.10.55) 연결이 점심 이후부터 간헐적으로 끊기기 시작했다. ping 192.168.10.55를 해보면 응답이 왔다 안 왔다 한다.
진단 과정
# 1단계: ping으로 간헐적 끊김 확인
ping 192.168.10.55
# 64 bytes from 192.168.10.55: icmp_seq=1 ttl=64 time=0.8ms
# 64 bytes from 192.168.10.55: icmp_seq=2 ttl=64 time=0.9ms
# Request timeout for icmp_seq 3
# 64 bytes from 192.168.10.55: icmp_seq=4 ttl=64 time=1.1ms
# Request timeout for icmp_seq 5
# 2단계: ARP 테이블에서 MAC이 변하는지 관찰
watch -n 1 'arp -an | grep 192.168.10.55'
# ? (192.168.10.55) at 00:50:56:aa:bb:cc [ether] on eth0 ← DB 서버 MAC
# ? (192.168.10.55) at b8:27:eb:11:22:33 [ether] on eth0 ← 다른 MAC!
# 3단계: arping으로 확정
sudo arping -I eth0 -c 10 192.168.10.55
# Unicast reply from 192.168.10.55 [00:50:56:aa:bb:cc] ...
# Unicast reply from 192.168.10.55 [b8:27:eb:11:22:33] ...
# → IP 충돌 확인
# 4단계: MAC OUI로 제조사 추측
# b8:27:eb → Raspberry Pi Foundation
# 누군가 라즈베리파이를 사무실 프린터 옆에 꽂았고,
# 정적 IP를 192.168.10.55로 잘못 설정한 것으로 추정
원인 및 해결
점심시간에 새로 연결된 라즈베리파이 개발 보드가 192.168.10.55를 정적으로 설정하고 있었다. 해당 장비의 IP를 변경하거나 네트워크에서 분리해 해결.
상황
인프라팀이 신규 VM(web-server-new)을 배포한 직후, 기존 web-server-old(192.168.20.100)의 외부 통신이 완전히 끊겼다.
진단 및 원인
# 피해 서버(web-server-old)에서 확인
ip addr show eth0
# inet 192.168.20.100/24 brd 192.168.20.255 scope global eth0
# 외부에서 두 서버 향해 arping
sudo arping -I eth0 -c 5 192.168.20.100
# 결과: 두 개의 MAC 주소에서 응답
# 신규 VM(web-server-new)이 동일한 192.168.20.100으로 설정된 것이 원인
# VM 템플릿에서 복제할 때 네트워크 설정을 그대로 가져온 것
# DHCP 서버 로그에서 VM MAC 확인
sudo journalctl -u dhcpd | grep "192.168.20.100"
재발 방지책
- VM 배포 시 IP 할당 전 DHCP 서버 또는 IP 관리 대장(IPAM)에서 중복 여부 확인
- VM 템플릿에 정적 IP를 설정하지 않고 배포 후 할당하는 프로세스 수립
IP 충돌을 발견했다면 네트워크 팀에 아래 정보를 포함해 정확히 전달해야 신속하게 해결된다.
필수 수집 정보
# 리포팅 전 수집해야 할 정보
# 1. 충돌 IP 주소
CONFLICT_IP="192.168.10.55"
# 2. 충돌하는 두 MAC 주소 (arping 결과)
sudo arping -I eth0 -c 10 $CONFLICT_IP 2>&1 | tee /tmp/arping_result.txt
# 3. 내 서버 정보
ip addr show eth0
hostname
date
# 4. ARP 테이블 전체 스냅샷
ip neigh show > /tmp/arp_table.txt
# 5. tcpdump로 ARP 충돌 패킷 캡처 (30초)
sudo timeout 30 tcpdump -i eth0 -w /tmp/arp_conflict.pcap "arp and host $CONFLICT_IP"
리포팅 템플릿
제목: [긴급] IP 충돌 감지 - 192.168.10.55
발생 시간: 2024-03-15 14:30 KST
신고자: 홍길동 (개발팀)
[증상]
- 192.168.10.55 (DB 서버) 로의 연결이 간헐적으로 끊김
- ping 타임아웃이 약 30% 발생
[진단 결과]
- arping으로 두 개의 MAC 주소에서 응답 확인
- MAC 1: 00:50:56:aa:bb:cc (기존 DB 서버 - VMware VM)
- MAC 2: b8:27:eb:11:22:33 (미확인 장비 - Raspberry Pi 추정)
- 충돌 시작 시간: 점심 이후 (12:30~13:00 사이 추정)
[첨부]
- arping 결과: /tmp/arping_result.txt
- ARP 테이블: /tmp/arp_table.txt
- tcpdump 캡처: /tmp/arp_conflict.pcap
[요청 사항]
MAC b8:27:eb:11:22:33 장비 확인 및 IP 변경 조치 부탁드립니다.
온프레미스 서버 운영 환경에서
대형 사내망에서는 수백~수천 대의 장비가 IP를 공유한다. DHCP를 사용하더라도 일부 서버, 프린터, NAS는 정적 IP를 사용하는 경우가 많아 관리가 소홀하면 IP 충돌이 발생한다.
신입/주니어 엔지니어가 자주 마주치는 상황:
- 새 서버 셋업 시 IP를 임의로 설정하다가 충돌 발생
- DR(재해복구) 사이트 테스트 중 운영망 IP와 충돌
- 개발자가 로컬 VM에 운영 서버와 동일한 IP를 잘못 설정
클라우드 환경에서
AWS, GCP 등의 VPC 환경에서는 클라우드 SDN이 IP 할당을 관리하므로 일반적인 ARP 충돌은 발생하지 않는다. 그러나 온프레미스 ↔ 클라우드 하이브리드 구성의 VPN/Direct Connect 환경에서는 IP 대역 겹침으로 충돌이 발생할 수 있다.
IPAM(IP Address Management) 도구
규모가 큰 조직에서는 IPAM 도구(phpIPAM, NetBox, Infoblox 등)를 사용해 IP 할당을 중앙에서 관리한다. IP 충돌 예방의 기본은 IP 할당 전 반드시 IPAM 시스템을 먼저 확인하는 것이다.
이 기술이 쓰이는 직무
- 시스템 엔지니어 / 인프라 엔지니어: 서버 네트워크 설정 및 장애 대응
- 네트워크 엔지니어: 스위치/라우터 레벨 ARP 테이블 관리
- DevOps / SRE: VM, 컨테이너 배포 시 네트워크 충돌 예방
- 보안 엔지니어: ARP 스푸핑(Man-in-the-Middle) 탐지
정리
이 챕터에서 배운 핵심 내용:
| 개념/명령어 | 설명 |
|---|---|
| ARP | IP 주소 → MAC 주소 변환 프로토콜 (L2/L3 경계) |
arp -an | 현재 ARP 캐시 테이블 확인 |
ip neigh show | 더 상세한 neighbor(ARP) 테이블 확인 |
arping -I eth0 -c N [IP] | ARP 수준에서 장비 응답 확인 |
| IP 충돌 증상 | 간헐적 ping 실패 + ARP 테이블 MAC 주소 계속 변경 |
ip neigh flush all | ARP 캐시 전체 초기화 |
다음 챕터 예고: 라우팅 테이블과 게이트웨이가 날아가는 현상을 진단하고 복구하는 방법을 배운다.