Linux 서버에 여러 개의 네트워크 인터페이스(NIC)가 연결되어 있는 환경에서는 간혹 동일한 IP 대역에서 예상하지 않은 인터페이스가 ARP 응답을 보내는 현상이 발생합니다. 이러한 문제를 ARP Flux라고 합니다.

ARP Flux가 발생하면 특정 서버에 접속이 불안정해지고, 간헐적인 Ping 실패, 세션 끊김, 패킷 손실 등의 문제가 발생할 수 있습니다. 특히 Multi-Homing, Bonding, Kubernetes 노드, 가상화 환경에서 자주 발생합니다.

이번 글에서는 Linux에서 ARP Flux가 발생하는 원인과 해결 방법을 실무 중심으로 알아보겠습니다.

ARP Flux란?

ARP Flux는 하나의 서버가 여러 개의 NIC를 가지고 있을 때, 요청을 받은 인터페이스가 아닌 다른 인터페이스에서 ARP Reply를 보내는 현상입니다.

예를 들어 다음과 같은 구조입니다.

        Linux Server
     ┌──────────────┐
     │              │
 eth0           eth1
192.168.10.10 192.168.10.20
     │              │
     └────Switch────┘

Client → Who has 192.168.10.10?

↓

eth1이 대신 ARP Reply

이처럼 잘못된 인터페이스가 응답하면 클라이언트의 ARP Cache가 잘못 저장되어 통신이 불안정해질 수 있습니다.

ARP Flux 문제가 발생하는 주요 원인

대표적인 원인은 다음과 같습니다.

Multi-Homing 환경
동일 Subnet에 여러 NIC 연결
arp_ignore 기본 설정
arp_announce 기본 설정
Policy-Based Routing 미설정
Bonding 구성 오류
Kubernetes CNI 설정
가상화 환경
Keepalived(VRRP)
VIP(Virtual IP) 구성

실무에서는 동일 Subnet에 여러 NIC를 연결한 환경에서 가장 많이 발생합니다.

1. 인터페이스 확인하기

먼저 NIC 구성을 확인합니다.

ip addr

또는

ip link

동일한 Subnet에 여러 NIC가 존재하는지 확인합니다.

2. ARP 관련 설정 확인하기

현재 설정을 확인합니다.

sysctl -a | grep arp_ignore

sysctl -a | grep arp_announce

예시

net.ipv4.conf.all.arp_ignore = 0
net.ipv4.conf.all.arp_announce = 0

기본값에서는 ARP Flux가 발생할 가능성이 높습니다.

3. arp_ignore 설정

현재 인터페이스에서만 ARP Reply를 보내도록 설정합니다.

sysctl -w net.ipv4.conf.all.arp_ignore=1

인터페이스별 적용

sysctl -w net.ipv4.conf.eth0.arp_ignore=1

이 설정을 적용하면 요청받은 인터페이스에서만 응답합니다.

4. arp_announce 설정

가장 적절한 Source IP를 사용하도록 설정합니다.

sysctl -w net.ipv4.conf.all.arp_announce=2

인터페이스별 적용

sysctl -w net.ipv4.conf.eth0.arp_announce=2

ARP Reply의 정확성이 향상됩니다.

5. 영구 설정하기

/etc/sysctl.conf

vi /etc/sysctl.conf

다음을 추가합니다.

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.default.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.default.arp_announce=2

적용합니다.

sysctl -p

6. ARP Cache 확인하기

현재 ARP 정보를 확인합니다.

ip neigh

또는

arp -n

MAC 주소가 계속 변경되는지 확인합니다.

7. tcpdump로 ARP 확인하기

ARP 패킷을 분석합니다.

tcpdump -i eth0 arp

또는

tcpdump -i eth1 arp

어느 인터페이스에서 Reply가 발생하는지 확인합니다.

8. Routing 확인하기

라우팅 정책도 함께 확인합니다.

ip route

또는

ip rule

Policy-Based Routing이 필요한 환경인지 확인합니다.

9. 로그 확인하기

커널 로그를 확인합니다.

journalctl -k

또는

dmesg

ARP 관련 오류는 로그가 많지 않으므로 tcpdump 분석이 더욱 중요합니다.

10. 서비스 테스트

설정 변경 후 다음 항목을 확인합니다.

Ping
SSH
HTTP
VIP
Keepalived
Kubernetes Pod 통신

간헐적인 연결 문제가 해결되었는지 확인합니다.

ARP Flux 문제 점검 순서

실무에서는 다음 순서대로 확인하는 것이 좋습니다.

NIC 구성 확인
동일 Subnet 여부 확인
arp_ignore 확인
arp_announce 확인
ARP Cache 확인
tcpdump 분석
Routing 확인
Policy Routing 확인
영구 설정 적용
서비스 테스트

ARP Flux 사용 시 주의사항

다음 사항을 확인해야 합니다.

동일한 Subnet에 여러 NIC를 연결하는 경우 주의한다.
arp_ignore=1을 사용하는 것이 일반적이다.
arp_announce=2를 함께 설정하면 효과적이다.
Keepalived나 VRRP 환경에서는 별도의 ARP 정책이 필요할 수 있다.
Kubernetes CNI에서도 유사한 문제가 발생할 수 있다.
설정 변경 후 반드시 실제 트래픽을 테스트한다.

ARP Flux는 간헐적으로 발생하는 경우가 많아 원인을 찾기 어렵지만, tcpdump와 sysctl 설정을 함께 확인하면 대부분 해결할 수 있습니다.

ARP Flux와 ARP Spoofing의 차이

항목	ARP Flux	ARP Spoofing
원인	시스템 설정	공격
목적	의도하지 않은 응답	MAC 주소 위조
발생 환경	Multi-Homing	악성 사용자
해결 방법	sysctl 설정	보안 장비, Dynamic ARP Inspection

ARP Flux는 운영상의 설정 문제이며, ARP Spoofing은 네트워크 공격이라는 점이 가장 큰 차이입니다.

자주 묻는 질문

ARP Flux는 모든 서버에서 발생하나요?

아닙니다. 대부분 Multi-Homing이나 동일한 Subnet에 여러 NIC가 연결된 환경에서 발생합니다.

arp_ignore와 arp_announce를 모두 설정해야 하나요?

네. 일반적으로 arp_ignore=1과 arp_announce=2를 함께 설정하는 것이 가장 많이 사용하는 방법입니다.

ARP Flux는 Ping만 실패하게 하나요?

아닙니다. SSH, HTTP, 데이터베이스 연결, Kubernetes Pod 통신 등 다양한 네트워크 서비스에서 간헐적인 연결 장애를 유발할 수 있습니다.

마무리

ARP Flux는 Multi-Homing 환경에서 자주 발생하는 네트워크 문제로, 잘못된 인터페이스에서 ARP Reply를 보내면서 통신 장애를 유발합니다. ip neigh, tcpdump, sysctl, ip route 등을 활용하면 원인을 빠르게 분석할 수 있으며, arp_ignore와 arp_announce를 적절히 설정하면 대부분의 문제를 예방할 수 있습니다.

Linux ARP Flux 문제의 원인과 해결 방법