L2/L3 스위치 & ARP 트러블슈팅¶

네트워크 스위치와 ARP 문제 해결 실전 가이드

네트워크 레이어 기본¶

L2 Switch (Data Link Layer)¶

MAC Learning: - 스위치가 어떤 포트로 프레임을 전달할지 결정 - MAC 주소 테이블 자동 학습 - 출발지 MAC 주소를 보고 포트 매핑

동작 방식:

1. 프레임 수신 → 출발지 MAC 주소 기록 (포트 번호와 함께)
2. 목적지 MAC 주소 확인
   - 테이블에 있음 → 해당 포트로 전달 (Unicast)
   - 테이블에 없음 → 모든 포트로 전달 (Flooding)

L3 Switch (Network Layer)¶

기능: - IP 주소 기반 라우팅 - VLAN 간 통신 - ARP를 통한 MAC ↔ IP 매핑

VLAN (Virtual LAN): - IP 대역을 논리적으로 분리 - 브로드캐스트 도메인 격리 - 목적: 네트워크 세그먼테이션, 보안, 트래픽 관리

ARP (Address Resolution Protocol)¶

기본 개념¶

역할: MAC 주소 ↔ IP 주소 매핑

프로세스:

sequenceDiagram
    participant Host as Host A
    participant Switch as L3 Switch
    participant Target as Host B

    Host->>Switch: ARP Request (브로드캐스트)<br/>IP 192.168.0.200의 MAC 주소는?
    Switch->>Target: ARP Request 전달
    Target->>Switch: ARP Reply (유니캐스트)<br/>MAC: aa:bb:cc:dd:ee:ff
    Switch->>Host: ARP Reply 전달
    Host->>Host: ARP 테이블에 저장

ARP 테이블¶

확인 방법:

# Linux/macOS
arp -a

# Windows
arp -a

# 출력 예시
Internet  192.168.0.100         0   b8:27:eb:12:34:56      ARPA
Internet  192.168.0.200         0   Incomplete             ARPA

상태 설명:

상태	의미	원인
정상 MAC 주소	ARP 응답 받음	정상 통신 중
Incomplete	ARP 응답 없음	1) 대상 호스트 다운 2) 네트워크 단절 3) 방화벽 차단 4) ARP 테이블 만료

ARP 테이블 특징: - TTL (Time To Live): 일정 시간 후 자동 만료 - 지속 조건: 패킷이 지속적으로 지나가야 유지 - 갱신 주기: 일반적으로 60초~240초 (OS/스위치마다 다름)

트러블슈팅 사례¶

사례 1: ARP Incomplete 문제¶

증상:

$ arp -a
Internet  192.168.0.200         0   Incomplete      ARPA

원인 분석:

대상 호스트 확인: ping 192.168.0.200 → 응답 없음
네트워크 경로 확인: L3 스위치까지는 정상
ARP 브로드캐스트 전달 실패: 스위치에서 응답 없음

원인: L3 스위치가 ARP Request를 브로드캐스트했으나 응답 없음 → 대상 호스트 문제 가능성 70%

해결 과정:

스위치 설정 확인 (변경 이력 없음)
케이블 확인 (물리 계층)
호스트 네트워크 설정 확인

사례 2: VIP 설정 시 커널 무시 문제¶

증상: - VIP(Virtual IP)로 들어오는 패킷을 커널이 무시

원인: - Linux 커널 파라미터 rp_filter (Reverse Path Filtering) - 기본값 = 1 (Strict mode) - 자신의 인터페이스에 바인딩된 IP가 아니면 패킷 무시

해결:

# rp_filter 확인
sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.eth0.rp_filter

# rp_filter 비활성화 (VIP 허용)
sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.eth0.rp_filter=0

# 영구 적용 (/etc/sysctl.conf)
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0

rp_filter 값:

값	모드	동작
0	Disabled	모든 패킷 허용 (VIP 사용 가능)
1	Strict	바인딩된 IP만 허용 (기본값)
2	Loose	라우팅 가능하면 허용

사례 3: arping으로 L3 스위치 MAC 테이블 갱신¶

실제 상황: - Istio Gateway LoadBalancer IP (VIP) 할당 후 트래픽이 도달하지 않음 - LoadBalancer IP는 할당되었으나 외부에서 접근 불가

문제: - Kubernetes LoadBalancer Service가 VIP 할당 시 Gratuitous ARP를 자동으로 브로드캐스트하지 않음 - L3 스위치의 MAC 주소 테이블이 VIP에 대한 MAC 매핑을 학습하지 못함 - 스위치가 VIP로 향하는 패킷을 어느 포트로 전달할지 모름

원인: - L3 스위치는 MAC Learning으로 "IP → MAC → Port" 매핑 테이블 유지 - VIP가 할당되어도 ARP 브로드캐스트가 없으면 스위치가 학습 불가 - 결과: 스위치가 VIP 패킷을 Flooding (모든 포트로 전달) 또는 Drop

해결: netshoot pod에서 arping 실행:

# 1. netshoot pod 생성 (host network 모드)
kubectl run netshoot --rm -it --image=nicolaka/netshoot --overrides='
{
  "spec": {
    "hostNetwork": true,
    "nodeName": "worker-node-1"
  }
}' -- bash

# 2. pod 내부에서 arping 실행
# LoadBalancer IP (VIP)에 대해 Gratuitous ARP 전송
arping -U -I eth0 <LoadBalancer-IP>

# 예시:
arping -U -I eth0 10.0.1.100

# 옵션:
# -U: Unsolicited (Gratuitous) ARP - 요청 없이 자발적으로 보냄
# -I: 인터페이스 지정 (보통 eth0)
# -c: 전송 횟수 (기본 무한, -c 3으로 3회만 가능)

동작 원리:

Gratuitous ARP 브로드캐스트
Source IP: 10.0.1.100 (VIP)
Source MAC: aacc:dd:ee:ff (현재 노드 NIC MAC)
Destination: FF:FF:FF:FF:FF:FF (브로드캐스트)
L3 스위치 MAC Learning
스위치가 ARP 패킷의 출발지 MAC 주소 확인
MAC 테이블 업데이트: 10.0.1.100 → aa:bb:cc:dd:ee:ff → Port 5
이후 패킷 전달
외부에서 10.0.1.100으로 패킷 전송
L3 스위치가 MAC 테이블 조회
Port 5로 패킷 전달 (정확한 Unicast)

L3 스위치의 역할: - ARP 패킷을 통해 MAC Learning 수행 - IP ↔ MAC ↔ Port 매핑 테이블 유지 - VIP에 대한 Gratuitous ARP가 없으면 학습 불가

Kubernetes 환경에서 흔한 이유: - MetalLB, Istio Gateway 등 LoadBalancer 구현체가 VIP 할당 시 Gratuitous ARP를 자동으로 보내지 않는 경우 - 수동으로 arping 실행하여 L3 스위치에 VIP ↔ MAC 매핑 알림 필요

tcpdump로 ARP 패킷 확인¶

문제 진단 시 tcpdump 활용:

# 1. ARP 패킷 모니터링 (arping 실행 전)
tcpdump -i eth0 -nn arp

# 2. VIP 관련 ARP만 필터링
tcpdump -i eth0 -nn arp and host 10.0.1.100

# 3. Gratuitous ARP 확인 (arping 실행 후)
# 출력 예시:
# ARP, Request who-has 10.0.1.100 tell 10.0.1.100, length 28
# (출발지와 목적지 IP가 같음 = Gratuitous ARP)

# 4. VIP로 향하는 모든 트래픽 확인
tcpdump -i eth0 -nn host 10.0.1.100

# 5. ICMP (ping) 패킷만 확인
tcpdump -i eth0 -nn icmp and host 10.0.1.100

# 옵션:
# -i eth0: 인터페이스 지정
# -nn: IP 주소/포트 숫자로 표시 (DNS 조회 안 함)
# -v: 상세 정보 출력
# -c 10: 10개 패킷만 캡처

tcpdump 출력 분석:

# Gratuitous ARP 패킷 예시
# arping 실행 전: ARP 패킷 없음

# arping 실행 후:
# 15:30:45.123456 ARP, Request who-has 10.0.1.100 (ff:ff:ff:ff:ff:ff) tell 10.0.1.100, length 28
# 출발지 IP = 목적지 IP = 10.0.1.100 (Gratuitous ARP의 특징)
# 출발지 MAC = aa:bb:cc:dd:ee:ff (현재 노드 MAC)

트러블슈팅 절차 (tcpdump + arping):

현재 ARP 상태 확인:

arp -a | grep 10.0.1.100
# 출력: ? (10.0.1.100) at <incomplete> on eth0

tcpdump 시작 (별도 터미널):

tcpdump -i eth0 -nn arp and host 10.0.1.100

arping 실행 (원래 터미널):
```
arping -U -c 3 -I eth0 10.0.1.100
```
tcpdump에서 Gratuitous ARP 확인:
who-has 10.0.1.100 tell 10.0.1.100 패킷 보임
L3 스위치가 이 패킷의 출발지 MAC 학습

트래픽 도달 확인:

tcpdump -i eth0 -nn host 10.0.1.100
# 외부에서 ping 시도
# ICMP echo request/reply 패킷 보이면 정상

스위치 설정 (Cisco 예시)¶

기본 명령어¶

# 스위치 접속
ssh admin@<switch-ip>

# enable 모드 진입 (항상 필수!)
enable

# 설정 모드
configure terminal

# VLAN 확인
show vlan

# MAC 주소 테이블 확인
show mac address-table

# ARP 테이블 확인
show ip arp

# 특정 포트 상태 확인
show interface GigabitEthernet1/0/1

중요: enable 명령은 항상 실행해야 설정 권한을 얻음

스위치 설정 변경 주의사항¶

스위치 설정은 자주 변경하지 않음: - 새로운 망 추가가 아니면 거의 변경 없음 - 변경 시 영향 범위가 크므로 신중히 계획

트러블슈팅 시 우선순위:

노드 문제 (70%): 호스트 네트워크 설정, 케이블, NIC
ARP 테이블 만료 (20%): arping으로 갱신
스위치 설정 (10%): 설정 변경 이력 확인

트러블슈팅 체크리스트¶

1단계: 기본 확인¶

# Ping 테스트
ping <target-ip>

# ARP 테이블 확인
arp -a

# 라우팅 테이블 확인
ip route

2단계: 물리 계층¶

케이블 연결 상태
NIC LED 상태
스위치 포트 LED

3단계: 네트워크 계층¶

IP 주소 설정 (ip addr)
서브넷 마스크
게이트웨이 설정
rp_filter 설정 (VIP 사용 시)

4단계: 스위치 레벨¶

MAC 주소 테이블 (show mac address-table)
ARP 테이블 (show ip arp)
VLAN 설정 (show vlan)
포트 설정 (show interface)

5단계: 패킷 분석 및 ARP 갱신¶

# tcpdump로 ARP 패킷 모니터링
tcpdump -i eth0 -nn arp and host <vip>

# Gratuitous ARP 전송 (별도 터미널)
arping -U -c 3 -I eth0 <vip>

# tcpdump에서 "who-has <vip> tell <vip>" 확인
# → Gratuitous ARP 브로드캐스트 성공

# VIP 트래픽 확인
tcpdump -i eth0 -nn host <vip>

# ARP 캐시 삭제 후 재학습
arp -d <ip>
ping <ip>

핵심 개념 정리¶

계층	프로토콜/장비	주요 역할
L2	MAC, Switch	MAC Learning, 포트 전달
L3	IP, ARP, Router/L3 Switch	IP 라우팅, MAC ↔ IP 매핑

3가지 주요 테이블¶

네트워크 장비가 사용하는 3가지 테이블:

테이블	위치	매핑	확인 명령어	TTL	용도
ARP Table	호스트, L3 스위치, 라우터	IP ↔ MAC	`arp -a` (호스트) `show ip arp` (스위치)	60~240초	IP 주소를 MAC 주소로 변환
Routing Table	라우터, L3 스위치	목적지 네트워크 → Next Hop	`ip route` (Linux) `show ip route` (Cisco)	정적 (수동 설정) 동적 (라우팅 프로토콜)	패킷을 어느 경로로 전달할지 결정
MAC Address Table	L2/L3 스위치	MAC → Port	`show mac address-table` (Cisco)	300초 (기본값)	MAC 주소를 물리 포트로 매핑

3가지 테이블의 협력 과정:

외부 (192.168.1.10) → L3 스위치 → 내부 호스트 (10.0.1.100)

1단계: Routing Table 조회
- 목적지 IP: 10.0.1.100
- Routing Table: 10.0.1.0/24 → eth0 인터페이스로 전달

2단계: ARP Table 조회
- 10.0.1.100의 MAC 주소는?
- ARP Table: 10.0.1.100 → aa:bb:cc:dd:ee:ff

3단계: MAC Address Table 조회
- aa:bb:cc:dd:ee:ff는 어느 포트?
- MAC Table: aa:bb:cc:dd:ee:ff → Port 5

4단계: 패킷 전달
- Port 5로 프레임 전송

트러블슈팅 시 점검 순서:

Routing Table: 목적지 네트워크로 가는 경로가 있는가?
```
ip route | grep 10.0.1.0
```

ARP Table: 목적지 IP의 MAC 주소를 알고 있는가?

arp -a | grep 10.0.1.100
# Incomplete → ARP 응답 없음

MAC Address Table: MAC 주소가 어느 포트로 매핑되어 있는가?

show mac address-table | include aa:bb:cc:dd:ee:ff
# 없음 → MAC Learning 안 됨 (arping 필요)

ARP 트러블슈팅 핵심:

ARP 테이블은 TTL이 있어 주기적으로 만료됨
VIP 설정 시 rp_filter=0 필요
tcpdump로 ARP 패킷 확인 → Gratuitous ARP 브로드캐스트 여부 진단
arping으로 L3 스위치 MAC 테이블 강제 갱신
문제의 70%는 노드(호스트) 문제
Cisco Switch 기본 설정
Linux ARP 관리
arping 사용법