[OpenStack] OpenStack Neutron 네트워크 장애 진단 및 해결 5단계

목차

• 1. OpenStack Neutron을 쉽게 말해보면
• 2. OpenStack 네트워크 문제를 해결하는 Neutron 트러블슈팅 5단계
• 3. 1단계: OpenStack 네트워크 장애 범위를 먼저 자르기
• 4. 2단계: Neutron Agent 상태부터 확인하기
• 5. 3단계: Namespace와 Port를 보면 길이 보입니다
• 6. 4단계: Data Plane 확인, 특히 OVS 브리지와 보안 정책
• 7. 5단계: MTU, DHCP, 외부망 라우팅까지 마무리 확인
• 8. 자주 겪는 장애 패턴과 해결 메모
• 9. 검증, 결과 확인, 그리고 다음 단계
• FAQ

[OpenStack] OpenStack Neutron 네트워크 장애 진단 및 해결 5단계

OpenStack Neutron 네트워크 장애는 경험해보신 분들은 알겠지만, VM은 떠 있는데 통신이 안 되고, Floating IP는 붙었는데 외부 접속이 안 되고, DHCP는 살아 있는 것 같은데 IP를 못 받아오는 식으로 정말 답답합니다. 저도 홈랩이랑 테스트 클러스터에서 OpenStack Neutron 네트워크 장애를 몇 번 크게 겪었는데요. 처음엔 인스턴스 문제인가 싶다가, 알고 보니 L2 브리지, L3 Agent, Security Group, MTU가 각각 따로 발목을 잡고 있더라고요. 그래서 이번 글에서는 제가 실제로 쓰는 흐름대로 OpenStack 네트워크 문제를 5단계로 줄여서 확인하는 방법을 정리해보겠습니다.

컨트롤 플레인과 데이터 플레인이 어디서 갈리는지 한눈에 보는 구조입니다.

1. OpenStack Neutron을 쉽게 말해보면

쉽게 말해, Neutron은 클라우드 안에서 가상 스위치, 라우터, DHCP, 보안 정책을 한군데 관리해주는 네트워크 제어 계층이라고 보면 돼요. 여기서 중요한 건 Control Plane(컨트롤 플레인, 설정과 상태를 관리하는 영역)과 Data Plane(데이터 플레인, 실제 패킷이 흐르는 영역)을 분리해서 봐야 한다는 점입니다.

예를 들어 CLI에서 네트워크와 포트가 멀쩡하게 보여도, 실제 노드의 Open vSwitch(오픈 브이 스위치, 가상 스위치) 브리지나 Linux namespace(리눅스 네임스페이스, 격리된 네트워크 공간)가 꼬이면 통신은 바로 끊깁니다. 저도 처음엔 API 결과만 보고 안심했다가 한참 삽질했었는데, 결국 패킷이 어디까지 갔는지를 봐야 답이 나오더라고요.

2. OpenStack 네트워크 문제를 해결하는 Neutron 트러블슈팅 5단계

1. 장애 범위 확인: 특정 VM만 문제인지, 특정 네트워크인지, 전체 노드 공통인지 먼저 자릅니다.
2. Agent 상태 확인: DHCP Agent, L3 Agent, Open vSwitch Agent 또는 Linux Bridge Agent 상태를 봅니다.
3. Namespace와 Port 확인: qdhcp, qrouter namespace 내부 인터페이스와 라우팅을 봅니다.
4. Data Plane 확인: 브리지 매핑, 터널, 보안 정책, 포트 바인딩을 추적합니다.
5. MTU, 라우팅, 외부망 확인: 마지막으로 잘 안 보이는 설정 불일치를 잡습니다.

여기서 중요한 포인트! 위에서 아래로 내려가야 합니다. 반대로 보면 같은 명령만 반복하게 되거든요.

3. 1단계: OpenStack 네트워크 장애 범위를 먼저 자르기

장애가 났을 때 가장 먼저 할 일은 "어디까지 되느냐"를 확인하는 겁니다. 인스턴스 내부에서 게이트웨이 Ping이 되는지, 같은 서브넷끼리 통신이 되는지, Floating IP로 외부에서 들어오는지 순서대로 보면 생각보다 빨리 좁혀집니다.

openstack server list
openstack network list
openstack subnet list
openstack port list --server <INSTANCE_ID>
openstack router list
openstack floating ip list

이 단계에서는 아래처럼 메모를 남기면 좋습니다.

• 특정 인스턴스만 안 되는가
• 특정 Compute 노드에 올라간 인스턴스만 안 되는가
• 내부 통신은 되고 외부만 안 되는가
• DHCP 할당부터 실패하는가

실제로 써보니까 이 메모 한 줄이 뒤에서 시간을 많이 줄여줍니다. 특히 특정 호스트에만 문제가 몰리면 Neutron 전체보다 하이퍼바이저 측 OVS나 브리지 설정을 먼저 의심해볼 수 있거든요.

4. 2단계: Neutron Agent 상태부터 확인하기

Neutron 트러블슈팅에서 가장 먼저 손에 잡히는 건 Agent 상태입니다. API는 살아 있는데 Agent가 죽어 있거나 heartbeat(하트비트, 상태 보고)가 끊긴 경우가 꽤 많습니다.

openstack network agent list
systemctl status neutron-server
systemctl status neutron-dhcp-agent
systemctl status neutron-l3-agent
systemctl status neutron-openvswitch-agent

환경에 따라 Linux Bridge를 쓰면 마지막 서비스명은 다를 수 있습니다. 핵심은 내가 쓰는 ML2 드라이버와 에이전트 조합을 정확히 알고 보는 겁니다.

증상	우선 확인할 컴포넌트	자주 보는 포인트
IP를 못 받음	DHCP Agent	qdhcp namespace, dnsmasq 동작 여부
외부 통신 안 됨	L3 Agent	qrouter namespace, SNAT, 외부 게이트웨이
동일 네트워크 간 통신 실패	OVS/Linux Bridge Agent	브리지 매핑, 포트 바인딩, 터널 상태
간헐적 패킷 손실	MTU 및 Overlay 네트워크	VXLAN/GRE 오버헤드 반영 여부

저는 여기서 꼭 로그도 같이 봅니다. 상태가 alive여도 내부적으로 재시도만 반복하는 경우가 있더라고요.

journalctl -u neutron-openvswitch-agent -n 100
journalctl -u neutron-l3-agent -n 100
journalctl -u neutron-dhcp-agent -n 100

장애 분석 시 어떤 Agent부터 확인하는지 흐름을 시각적으로 정리한 이미지입니다.

5. 3단계: Namespace와 Port를 보면 길이 보입니다

이제부터가 진짜입니다. CLI 결과는 정상인데 통신이 안 되는 경우, 저는 거의 습관처럼 namespace부터 봅니다. DHCP와 L3는 namespace 안에서 움직이기 때문에, 인터페이스가 실제로 붙어 있는지 보면 감이 옵니다.

ip netns
ip netns exec qdhcp-<NETWORK_ID> ip addr
ip netns exec qdhcp-<NETWORK_ID> ip route
ip netns exec qrouter-<ROUTER_ID> ip addr
ip netns exec qrouter-<ROUTER_ID> ip route
ip netns exec qrouter-<ROUTER_ID> ping -c 3 <GATEWAY_IP>

여기서 자주 보는 체크 포인트는 이렇습니다.

• qdhcp namespace가 아예 없으면 DHCP 스케줄링이나 Agent 문제일 가능성이 큽니다.
• qrouter namespace는 있는데 외부 인터페이스가 없으면 라우터 게이트웨이 연결을 다시 봐야 합니다.
• 포트 상태가 DOWN이면 바인딩 실패나 하이퍼바이저 측 문제를 의심합니다.

openstack port show <PORT_ID>
openstack router show <ROUTER_ID>
openstack network show <NETWORK_ID>

제가 직접 해보니 port binding:vif_type, binding:host_id 정보도 꽤 중요했습니다. 인스턴스는 떠 있는데 바인딩이 엉킨 상태면 네트워크만 죽어 있는 애매한 상황이 나오거든요.

6. 4단계: Data Plane 확인, 특히 OVS 브리지와 보안 정책

이제 패킷이 실제로 흐르는 길을 봐야 합니다. Open vSwitch를 쓴다면 브리지와 포트 구성이 의도대로 들어갔는지부터 체크합니다. 여기서 클라우드 네트워크 오류가 많이 납니다. 설정 파일은 맞는데 실제 브리지 매핑이 빠진 경우, 터널 인터페이스가 안 살아난 경우가 생각보다 흔합니다.

ovs-vsctl show
ovs-vsctl list-br
ovs-vsctl list-ports br-int
ovs-vsctl list-ports br-tun
ip link show
bridge fdb show

대표적으로 보는 설정 파일 예시는 이런 형태입니다.

[ovs]
bridge_mappings = physnet1:br-ex
local_ip = 10.0.0.10

[agent]
tunnel_types = vxlan
l2_population = true

[securitygroup]
enable_security_group = true

여기서 제가 몇 번 당했던 게 Security Group(시큐리티 그룹, 가상 방화벽)입니다. 운영 중에는 OpenStack 장애 해결을 위해 네트워크가 죽은 것처럼 보여도 사실은 ICMP나 SSH만 막혀 있는 경우가 있습니다.

openstack security group rule list
iptables -S
ip netns exec qrouter-<ROUTER_ID> iptables -t nat -S

혹시 이런 경험 있으신가요? Floating IP는 붙었는데 외부에서만 접속이 안 되는 경우요. 저는 처음엔 라우터가 문제인 줄 알았는데, 실제론 보안 그룹 규칙과 외부 브리지 uplink 설정이 같이 꼬여 있었습니다. 삽질 좀 했습니다 ㅎㅎ

br-int, br-tun, br-ex가 어떻게 이어지는지 이해하면 장애 지점이 훨씬 빨리 보입니다.

7. 5단계: MTU, DHCP, 외부망 라우팅까지 마무리 확인

여기까지 다 맞는데도 이상하면 MTU를 꼭 보셔야 합니다. VXLAN 같은 Overlay network(오버레이 네트워크, 기존 네트워크 위에 캡슐화해 올리는 가상 네트워크)는 헤더 오버헤드가 있어서, 물리망 MTU와 가상망 MTU가 어긋나면 큰 패킷에서만 조용히 깨집니다. 이게 진짜 사람 괴롭힙니다.

openstack subnet show <SUBNET_ID>
ip link show dev <INTERFACE>
ping -M do -s 1400 <TARGET_IP>

DHCP가 의심될 때는 dnsmasq 로그나 lease 파일도 같이 봅니다.

ps -ef | grep dnsmasq
ip netns exec qdhcp-<NETWORK_ID> cat /var/lib/neutron/dhcp/<NETWORK_ID>/hosts

외부망 연결에서는 아래 항목을 같이 체크하면 좋습니다.

1. 외부 네트워크가 올바른 물리 브리지에 매핑되었는가
2. L3 Agent가 해당 라우터를 실제로 호스팅하고 있는가
3. SNAT 규칙이 생성되었는가
4. 업스트림 스위치 또는 라우터에서 VLAN/Untagged 설정이 맞는가

사실 마지막 4번이 종종 핵심입니다. OpenStack 장애 해결이라고 들어왔는데, 알고 보면 물리 스위치 설정 하나 때문에 고생하는 경우가 꽤 있습니다.

8. 자주 겪는 장애 패턴과 해결 메모

• ⚠️ DHCP namespace 없음: DHCP Agent down 또는 스케줄링 문제를 먼저 확인합니다.
• ⚠️ Router namespace는 있는데 외부 IP Ping 실패: br-ex uplink, gateway, upstream 라우팅을 봅니다.
• ⚠️ 특정 Compute에 올라간 VM만 통신 실패: 해당 노드의 OVS Agent, 터널, 포트 바인딩을 우선 점검합니다.
• ⚠️ 작은 Ping은 되는데 애플리케이션 통신 실패: MTU mismatch 가능성이 큽니다.
• ⚠️ 재부팅 후 간헐적으로 실패: 서비스 기동 순서나 브리지 자동 생성 누락을 의심합니다.

제가 예전에 제일 오래 잡았던 건 "상태는 다 정상이지만 큰 패킷만 죽는" 케이스였는데요. 결국 MTU 문제였습니다. 드디어 됐다! 싶었던 순간이 아직도 기억나네요. 그래서 요즘은 Neutron 쪽에서 원인 못 찾으면 MTU 테스트를 꽤 빨리 해보는 편입니다. 이게 진짜 편하더라고요.

진단 전후로 어떤 항목이 정상화됐는지 비교하는 검증용 시각 자료입니다.

9. 검증, 결과 확인, 그리고 다음 단계

수정 후에는 반드시 검증(Validation, 적용 결과 확인)을 남겨야 합니다. 눈으로 한 번 되고 끝내면 다음 장애 때 같은 길을 또 돌게 됩니다.

openstack network agent list
openstack port list --server <INSTANCE_ID>
ip netns exec qrouter-<ROUTER_ID> ping -c 3 8.8.8.8
ip netns exec qdhcp-<NETWORK_ID> ping -c 3 <INSTANCE_IP>

• ✅ 인스턴스가 DHCP로 IP를 정상 할당받는지
• ✅ 같은 네트워크 내 동서 트래픽이 되는지
• ✅ 라우터를 통해 남북 트래픽이 되는지
• ✅ Floating IP를 통한 외부 접근이 되는지
• ✅ 재시작 후에도 동일하게 유지되는지

정리하면, OpenStack Neutron 네트워크 장애는 복잡해 보여도 "범위 자르기 → Agent 확인 → Namespace 확인 → Data Plane 추적 → MTU/외부망 점검" 순서로 가면 훨씬 덜 헤맵니다. 저도 처음엔 이게 뭔가 싶었는데, 결국 패킷이 어디서 멈추는지만 찾으면 답은 나오더라고요.

다음 글에서는 Security Group과 Distributed Virtual Routing(DVR, 분산 가상 라우팅) 관점에서 장애를 더 세분화해서 다뤄볼 예정입니다. 이전 글에서 다뤘던 Linux bridge와 OVS 기본 구조를 같이 보시면 이해가 더 빨라집니다. 🎉

FAQ

• Q. Neutron API는 정상인데 통신만 안 됩니다.
  A. API 정상과 데이터 플레인 정상은 다릅니다. namespace, OVS 브리지, 보안 정책을 같이 봐야 합니다.
• Q. Floating IP만 안 됩니다.
  A. L3 Agent, SNAT, br-ex 연결, 업스트림 라우팅을 우선 확인해보세요.
• Q. 장애 재현이 어렵습니다.
  A. 호스트별, 네트워크별, 패킷 크기별로 조건을 나눠 기록하면 원인 파악이 훨씬 쉬워집니다.

운영자가 바로 따라 할 수 있도록 5단계 흐름을 한 장으로 요약한 이미지입니다.

📚 함께 읽으면 좋은 글

• VMware ESXi에서 OpenStack으로 전환한 실제 사례
• OpenStack 멀티노드 배포, 컨트롤러/컴퓨트/네트워크 노드 역할 분석
• OpenStack Trove 도입 전 필수 체크리스트: 데이터베이스 서비스 최적화
• Wireshark로 악성 트래픽 탐지: 네트워크 포렌식 기법
• 10G 네트워크 비용, 홈랩에 정말 필요할까? 비용 효율성 심층 분석