사내망에서 한 개발 서버가 접속됐다 끊겼다를 반복합니다. 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이 바뀌더라도 시간이 지나면 자동으로 갱신된다.
MAC 주소를 알아내는 법 — ARP 해석과 캐시
IP만 알 때 MAC을 얻는 ARP 해석 흐름 — 캐시 조회부터 프레임 전송까지
같은 서브넷의 192.168.1.50에 패킷을 보내려는데, 커널이 손에 쥔 건 IP뿐입니다. 실제 이더넷 프레임은 MAC 주소로 배달되므로, 보내기 전에 반드시 IP를 MAC으로 변환하는 과정을 거쳐야 합니다. 이 변환이 ARP이고, 아래 흐름으로 진행됩니다. 이 단계를 알면 "IP는 닿는데 통신이 안 된다", "arp -an에 incomplete가 뜬다", "MAC이 자꾸 바뀐다"가 각각 어느 지점의 문제인지 구분됩니다.
[내 PC 192.168.1.10] 192.168.1.50 에 패킷을 보내려 함
│
① ARP 캐시(ip neigh) 조회
│ ├─ REACHABLE 매핑 있음 → ④ 로 직행 (캐시 히트)
│ └─ 없음/만료 → ②
│
② ARP request 브로드캐스트 (목적지 MAC = ff:ff:ff:ff:ff:ff)
│ "who-has 192.168.1.50? tell 192.168.1.10"
│
③ 그 IP 의 주인이 ARP reply 유니캐스트
│ "192.168.1.50 is-at aa:bb:cc:dd:ee:ff"
│ → 매핑을 ARP 캐시에 저장 (TTL 뒤 STALE → 재확인)
│
④ 목적지 MAC 을 채운 이더넷 프레임 전송
▼
[192.168.1.50] 프레임 수신 (이후 통신은 캐시 재사용)
각 단계에서 무슨 일이 일어나고, 어긋나면 어떤 증상인가:
| 단계 | 하는 일 | 여기서 어긋나면 |
|---|---|---|
| ① 캐시 조회 | ip neigh에서 목적지 IP의 MAC이 REACHABLE인지 확인 | STALE은 통신 가능(재확인 예정), FAILED면 직전 해석 실패 |
| ② request 브로드캐스트 | MAC을 모르면 세그먼트 전체에 who-has 질의 | 대상이 다른 서브넷이면 브로드캐스트가 안 닿음 → 게이트웨이 MAC을 대신 해석 |
| ③ reply 수신·저장 | IP 주인이 is-at <MAC>으로 유니캐스트 응답, 캐시에 기록 | 대상 다운·케이블 빠짐이면 무응답 → ip neigh에 INCOMPLETE |
| ③′ 두 MAC이 응답 | 같은 IP를 두 장비가 쓰면 서로 다른 MAC이 교대로 응답 | arping에 두 MAC = IP 충돌, arp -an의 MAC이 펄럭임 |
| ④ 프레임 전송 | 해석된 MAC을 목적지로 한 L2 프레임 송신 | 인터페이스 DOWN이면 캐시가 있어도 전송 불가 |
한 가지 더 — 장비가 자기 IP에 대한 ARP를 스스로 브로드캐스트하는 gratuitous ARP도 이 흐름 위에 있습니다. HA failover로 VIP가 새 장비로 옮겨갈 때 주변 캐시를 즉시 갱신시키는 용도이자, OS가 "누가 내 주소로 응답하네?"로 IP 충돌을 감지하는 수단입니다. 그래서 진단은 이렇게 좁힙니다 — 'IP는 닿는데 통신이 안 되면' ip neigh·arping으로 ③(상대가 응답하는가)을 의심하고, INCOMPLETE(무응답)와 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
- at 필드(MAC 주소)를 먼저 확인 — 그 다음 같은 IP에 다른 MAC이 있는지 비교: 동일 IP 행에 MAC이 두 줄 보이거나 watch로 관찰 시 MAC이 계속 바뀌면 IP 충돌
- <incomplete> 상태: ARP 요청을 보냈으나 응답 없음 — 해당 IP 장비가 꺼져 있거나 존재하지 않음, STALE은 60초 이내 재확인 예정이지만 통신 가능
- REACHABLE(정상)이고 MAC이 변하지 않으면 → L2 통신 정상; FAILED이면 → ARP 응답 없음으로 통신 불가; MAC이 교대로 바뀌면 → 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 충돌 시 증상
확대
전형적인 증상 패턴
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 변경 조치 부탁드립니다.
심화 — arp 캐시는 커널이 초 단위로 늙히고 청소한다
심화: neighbor 테이블의 수명 관리 — GC 임계값과 gratuitous ARP
arp -an이 보여주는 건 한 순간의 스냅샷일 뿐, 커널은 이 이웃 테이블을 초 단위로 늙히고 청소합니다. 이웃이 많은 노드(라우터·게이트웨이·파드 밀집 호스트)에선 이 청소 규칙이 곧 장애의 씨앗이 됩니다.
- 엔트리는 상태 머신을 돕니다: 통신이 뜸하면 REACHABLE→STALE로 늙고, 다음 전송 시 DELAY→PROBE로 조용히 재확인한 뒤 응답이 없으면 FAILED가 됩니다. 이 전이가 "쓰면 유지, 안 쓰면 만료"를 만듭니다.
- 총량은 gc_thresh 3단계로 관리됩니다: 커널은 엔트리 총수를 net.ipv4.neigh.default.gc_thresh1/2/3으로 통제합니다. thresh1 이하는 청소를 미루고, thresh2를 넘으면 적극적으로 GC하며, thresh3(기본 1024)을 넘으면 새 엔트리 생성을 거부하고 그 목적지로 프레임을 못 보내며 dmesg에 neighbour: arp_cache: neighbor table overflow! 를 남깁니다.
- 그래서 규모 함정입니다: 평평한 대형 서브넷(/16 등), 한 브리지에 수천 컨테이너, 많은 클라이언트를 마주하는 LB·게이트웨이는 이웃이 순식간에 thresh3을 넘깁니다. 증상은 "일부 목적지로만 무작위 실패"라 IP 충돌과 헷갈리지만, 이쪽은 MAC이 펄럭이지 않는다는 점이 결정적으로 다릅니다.
- gratuitous ARP의 두 얼굴: 장비가 자기 IP에 대한 ARP를 스스로 브로드캐스트해 주변 캐시를 즉시 갱신하는 것이 gratuitous ARP입니다. HA failover로 VIP가 새 장비로 옮겨갈 때 이걸로 이동을 알리고, OS는 이걸로 IP 충돌(누가 내 주소에 응답하면 팝업)을 감지합니다. 반대로 위조된 gratuitous ARP는 캐시를 오염시켜 트래픽을 가로채는 ARP 스푸핑이 됩니다.
상황: 라우팅을 담당하는 노드(또는 파드가 빽빽한 호스트)에서 일부 목적지로만 ping·연결이 무작위로 실패합니다. arp -an의 MAC은 그대로라 IP 충돌은 아닌 듯한데, dmesg에는 neighbour: arp_cache: neighbor table overflow! 가 반복해서 올라옵니다.
원인: 이 노드가 마주하는 이웃 수가 커널의 gc_thresh3(기본 1024)을 넘어섰습니다. 상한을 넘으면 커널은 새 neighbor 엔트리를 만들지 못해, 아직 캐시에 없는 목적지로의 프레임을 폐기합니다. 이미 캐시에 있는 목적지는 되고 신규·만료된 목적지는 안 되니 "무작위로 일부만 실패"하는 얄궂은 그림이 됩니다.
진단: ip neigh show | wc -l 로 현재 엔트리 수를 세어 sysctl net.ipv4.neigh.default.gc_thresh3 값과 비교합니다. dmesg -T | grep 'table overflow' 로 발생 시점을 잡고, /proc/net/stat/arp_cache의 table_fulls 카운터가 증가하는지 보면 확정입니다. MAC이 바뀌지 않는다는 점으로 IP 충돌·물리 장애를 먼저 배제합니다.
해결: 근본 대책은 한 노드가 마주하는 이웃 수 자체를 줄이는 것 — 거대한 평면 서브넷을 잘게 쪼개 브로드캐스트 도메인을 작게 하고 라우팅으로 이웃을 분산합니다. 즉효 완화로 gc_thresh1/2/3을 상향(예: 4096/8192/16384)하고 gc_stale_time/gc_interval을 조정해 만료를 촉진합니다. 다만 무한정 키우면 메모리·GC 비용이 커지므로 서브넷 분할이 정석입니다(Port Security와 VLAN 필터링 기초).
온프레미스 서버 운영 환경에서
대형 사내망에서는 수백~수천 대의 장비가 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 캐시 전체 초기화 |
명령어·단축키 빠른 참조
이 모듈에서 다룬 ARP·IP 충돌 진단 명령을 실전 옵션과 함께 모았습니다. "예" 열의 조합을 그대로 써도 됩니다.
| 명령어/단축키 | 용도 | 자주 쓰는 예 |
|---|---|---|
arp -an | ARP 캐시 스냅샷(IP↔MAC) | arp -an | grep 192.168.1.50 (특정 IP MAC 확인) |
ip neigh show | neighbor 테이블 상태까지 확인 | REACHABLE/STALE/INCOMPLETE/FAILED 판독 |
watch arp -an | MAC 펄럭임(충돌) 실시간 관찰 | watch -n1 'arp -an | grep 192.168.10.55' |
arping -I -c | 같은 IP에 응답하는 MAC 수 확인 | sudo arping -I eth0 -c 5 192.168.1.50 (두 MAC=충돌) |
arping -D | 배포 전 IP 중복 사전 점검 | sudo arping -D -I eth0 192.168.1.60 (응답=이미 사용 중) |
ip neigh flush all | ARP 캐시 전체 초기화 | 충돌 해결 후 옛 MAC 강제 갱신 |
ip neigh del / arp -d | 특정 항목만 삭제 | sudo ip neigh del 192.168.1.50 dev eth0 |
tcpdump -n arp | ARP 요청/응답 직접 캡처 | sudo tcpdump -i eth0 -n "arp and host 192.168.1.50" |
ip neigh show | wc -l | 현재 엔트리 수 세기(포화 진단) | gc_thresh3(기본 1024)과 비교 |
sysctl ...gc_thresh3 | neighbor 테이블 하드 상한 확인 | sysctl net.ipv4.neigh.default.gc_thresh3 |
dmesg | neighbor table overflow 확인 | dmesg -T | grep 'table overflow' |
관련 모듈로 더 깊이:
- netstat과 ss 명령어로 커넥션 상태(ESTABLISHED 등) 분석 — ARP/이웃 테이블과 함께 보는 소켓·연결 상태 점검
- Port Security와 VLAN 필터링 기초 — IP 충돌이 일어나는 L2 브로드캐스트 도메인의 구조
- ping과 ICMP 프로토콜을 이용한 초동 경로 진단 — 간헐적 ping 실패 증상을 ICMP 레벨에서 확인하는 법
다음 챕터 예고: 라우팅 테이블과 게이트웨이가 날아가는 현상을 진단하고 복구하는 방법을 배운다.