정전 이후 kea-dhcp / VLAN10 통신 장애 트러블슈팅

정전 이후 kea-dhcp / VLAN10 통신 장애 트러블슈팅

DATE: 2026-07-17 ~ 2026-07-18
TARGET: kea-dhcp(LXC, pve3), KeepLiNK KP-9000 스위치, 내부 테스트망 VLAN10(10.0.0.0/24)
RESULT: 홈 네트워크(192.168.0.0/24) DHCP 복구 + VLAN10 pve/pve2/pve3 전체 통신 정상화

---

배경 및 증상

• 자택 정전 발생 → pve3(LXC 전용 호스트) 재부팅
• 재부팅 이후 홈 네트워크에서 IP 자동할당(DHCP)이 되지 않음

---

1단계: kea-dhcp4-server 기동 실패 (홈 DHCP 전체 다운)

원인 확인

systemctl status kea-dhcp4-server

DHCP4_PARSER_FAIL failed to create or run parser for configuration element
interfaces-config: Failed to select interface: interface 'eth1' doesn't exist

kea-dhcp4.conf의 interfaces-config.interfaces가 ["eth0", "eth1"]로 설정되어 있었는데,
컨테이너에는 eth0만 존재했다(net1이 Proxmox 설정에 없었음). Kea는 명시된 인터페이스가
하나라도 없으면 전체 데몬 기동을 거부하기 때문에, VLAN10용 미완성 설정 하나가 홈 네트워크
DHCP 전체를 물고 늘어진 구조였다.

추가로 dhcp4.leases 파일을 확인한 결과 10.0.0.0/24(VLAN10) 대역 리스가 단 한 번도 발급된
적이 없었다 — eth1/net1은 정전과 무관하게 애초부터 컨테이너에 연결된 적이 없던 미완성
설정이었다.

조치

# 1. interfaces-config에서 eth1 제거 → 홈 네트워크 DHCP 즉시 복구
# (kea-dhcp4.conf를 python -c로 안전하게 JSON 편집, 원본은 .bak로 보존)

# 2. VLAN10용 net1을 hot-plug로 정식 추가 (컨테이너 재시작 불필요)
pct set 910 -net1 name=eth1,bridge=vmbr0,tag=10,ip=10.0.0.11/24

# 3. kea 설정에 eth1 재반영 후 검증 → 재시작
kea-dhcp4 -t /etc/kea/kea-dhcp4.conf
systemctl restart kea-dhcp4-server

참고: VLAN10을 위한 별도 물리 브리지는 필요 없었다. pve3의 vmbr0가 이미
bridge-vlan-aware yes, bridge-vids 2-4094로 설정되어 있어 tag=10만 지정하면 충분했다
(다른 pve 노드의 VLAN10 VM들도 전부 이 방식).

컨테이너 재부팅(pct reboot 910)까지 테스트해서 정전 재발 시에도 문제없이 자동 복구되는 것을
확인했다.

---

2단계: VLAN10 IP 정리 (부수적으로 발견된 이슈)

• kea 예약값과 실제 VM들의 IP를 대조하던 중, WS2022(AD/WSUS 서버)의 VLAN10 예약 주소
  10.0.0.100이 다른 서버 몫으로 착각되어 혼선이 있었음 → 실제로는 WS2022 서버 고유 예약이었고,
  이후 해당 서버의 VLAN10 IP를 10.0.0.100 → 200으로 재배치하고 kea reservation도 동기화.
• 그 과정에서 pve 호스트 자신(vmbr0.10 인터페이스)과 Rocky9-Security-Srv 게스트가 똑같이
  10.0.0.1을 쓰고 있는 IP 중복을 발견 → Rocky9의 VLAN10 IP를 10.0.0.100으로 재배치해서
  해소.

---

3단계: pve ↔ pve3 VLAN10 L2 불통 (가장 오래 걸린 부분)

증상 확인

kea-dhcp에 VLAN10 net1을 붙였는데도, 같은 VLAN10 대역의 다른 호스트(claude-ubuntu, pve
소속)에서 kea-dhcp(pve3)로 ping이 전혀 안 됨. ip neigh로 확인하니 ARP가 INCOMPLETE.

패킷 캡처로 원인 좁히기

pve/pve2/pve3 물리 NIC(nic0)에서 동시에 tcpdump를 걸고 VLAN10 ARP를 발생시켜본 결과:

노드	VLAN10 태그 ARP 프레임
pve (발신)	✅ 정상적으로 태그 붙여서 나감
pve2	❌ 도착 안 함
pve3	❌ 도착 안 함

→ 호스트 쪽 설정(Kea, vmbr0 vlan-aware, bridge-vids)은 전부 정상. 원인은 스위치로 좁혀짐.

스위치 조사

내부 테스트망을 담당하는 KeepLiNK KP-9000 스위치에 직접 로그인해서 확인.

• 기존 문서의 포트 매핑(1/2/4 = pve/pve2/pve3)이 틀렸다. MAC 포워딩 테이블로 실제 확인한
  결과: 포트 2 = pve3, 포트 4 = pve2, 포트 5 = pve (포트 1은 무관한 기기, 포트 3은 ESXi,
  포트 8은 공유기 업링크).
• Port Isolation이 전체 포트(1~9) 상호 격리 상태로 설정되어 있었음 — 이게 VLAN10 신규 통신이
  막히는 직접적인 원인.
• Loop Detection, Spanning Tree 둘 다 비활성(Off/Disable) — 루프 방지 장치가 전혀 없는 상태.

시도 1 (실패 → 즉시 롤백): Port Isolation 해제

실제 포트(2/4/5)의 상호 격리를 풀자 메인 네트워크(192.168.0.0/24) 전체가 단절됨
(pve2/pve3 SSH 불가). Loop/STP 안전장치가 없는 상태에서 물리적으로 존재하던 루프가 브로드캐스트
스톰으로 이어진 것으로 추정. 즉시 원상복구(전체 포트 재격리)해서 메인 네트워크 정상화 확인.

시도 2 (성공): 802.1Q VLAN10 정식 생성

Port Isolation은 그대로 둔 채, 스위치에 VLAN 10을 정식으로 생성(포트 2/4/5를 Tagged
멤버로 등록)했다.

VLAN ID: 10
Tagged Ports: 2, 4, 5

결과: Port Isolation을 전혀 건드리지 않았는데도 VLAN10 양방향 통신이 완전히 정상화됨.
메인 네트워크(VLAN1)는 격리가 그대로 유지되어 루프/스톰 위험 없이 안전했다.

---

최종 결과 요약

항목	상태
홈 네트워크(192.168.0.0/24) DHCP	정상 복구, 재부팅 테스트 통과
VLAN10(10.0.0.0/24) DHCP	정상 (net1 hot-plug)
pve ↔ pve2 ↔ pve3 VLAN10 통신	정상 (양방향 확인)
메인 네트워크	영향 없음

---

교훈 / 체크리스트

1. Kea(및 유사 서비스)는 설정에 명시된 인터페이스가 하나라도 없으면 전체 기동을 거부한다.
   미완성/미사용 기능의 설정 하나가 핵심 기능까지 잡아먹을 수 있으므로, interfaces-config류
   설정은 실존 여부를 항상 확인할 것.
2. 스위치 포트 매핑 문서는 시간이 지나면 실제와 어긋날 수 있다. 확신이 안 서면 스위치의 MAC
   포워딩 테이블로 재검증하는 게 가장 확실하다.
3. Port Isolation 해제는 위험할 수 있다. Loop Detection/STP 같은 안전장치가 없는 상태에서
   포트 격리를 풀면, 그동안 격리가 가려주던 물리적 루프가 브로드캐스트 스톰으로 드러날 수 있다.
4. 대안이 더 안전할 수 있다. 이번 건은 Port Isolation을 억지로 풀기보다, 802.1Q VLAN을
   정식으로 정의하는 쪽이 훨씬 안전하고 실제로 문제를 해결했다. 비슷한 상황이면 이 방법을
   먼저 시도할 것.
5. 정전/재부팅 이후에는 방화벽·스위치 등 네트워크 장비의 물리 상태(DIP 스위치 등)도 함께
   점검 대상에 포함하는 게 좋다 (이번 건은 DIP 스위치가 원인은 아니었지만, 조사 초반에 가능성
   중 하나로 검토했었음).