왜 OVN 환경에서 단일 NIC 구성이 위험한가 - localnet 추가 후 관리 트래픽이 끊긴 이유

인스턴스 통신 문제를 검증하는 과정에서 localnet 포트를 재생성하게 되었는데, 아래 명령어 입력 직후 노드 세션이 끊겼고 나중에는 proxmox 연결까지 끊겼다.

LS_NAME="neutron-<provider-network-UUID>"
PHYSNET="phynet2"

ovn-nbctl lsp-add ${LS_NAME} ln-${PHYSNET}
ovn-nbctl lsp-set-type ln-${PHYSNET} localnet
ovn-nbctl lsp-set-options ln-${PHYSNET} network_name=${PHYSNET}
ovn-nbctl lsp-set-addresses ln-${PHYSNET} "unknown"

서버에 접근할 수 없어서 상황 분석을 할 수 없었기에, 아래와 같은 재부팅 과정을 거쳤다.

LAN 케이블 재연결
노드 재부팅

재부팅 후 플로우/캐시/링크가 정상적으로 초기화되면서 노드 접속은 복구되었다. 문제 원인을 분석해보니, localnet 포트를 추가하면서 OVN Controller가 OVS를 통해 br-ex 구성을 다시 적용하는 과정에서 일시적으로 관리 트래픽을 처리하지 못하게 되어 다음과 같은 현상이 발생한 것이다.

Localnet 추가로 인한 OVN 구성 변경
ovn-nbctl lsp-add … type=localnet 명령을 통해 새 localnet 포트를 추가하면, OVN Controller는 해당 물리 네트워크 physnet2와 매핑된 브리지 br-ex를 다시 동기화한다. 이 과정에서 br-int ↔ br-ex 패치 포트를 재생성하고 OpenFlow 규칙을 재적용하여, Logical Switch(ls-xxxx)에서 물리 NIC(enp6s18)를 통해 외부 네트워크로 나가는 경로가 다시 활성화된다.
관리 네트워크가 br-ex에 종속된 구조적 문제
일반적으로 관리 네트워크(SSH, API, Proxmox UI 등)는 외부 통신용 브리지 br-ex와 분리하여 구성하는 것이 권장된다. 하지만 본 환경에서는 netplan이 아래와 같이 설정되어 있었기 때문에 관리 트래픽이 모두 br-ex를 통해 흐르는 구조였다.
```
bridges:
br-ex:
  interfaces: [enp6s18]
  addresses:
    - node_ip_addr/24
```
위 설정은 Host IP가 물리 NIC(enp6s18)가 아닌 br-ex에 직접 할당되어 있다는 뜻이며, 결과적으로 외부에서 노드로 들어오는 SSH와 Proxmox Web UI 접속이 모두 br-ex를 경유하도록 구성되어 있었다. 따라서 br-ex는 외부 네트워크 연결뿐 아니라 사실상 관리망 역할까지 겸하고 있었다고 볼 수 있다.
br-ex 재적용 과정에서 관리 트래픽 단절
따라서 OVN이 br-ex구성을 재적용하는 동안, 해당 브리지를 통해 전달되던 관리 트래픽(SSH, Web UI 등)의 네트워크 경로가 일시적으로 초기화되면서 관리 인터페이스가 일시적으로 down 되어 기존 연결 세션이 모두 끊기고 Proxmox 콘솔과 Web UI 접근이 불가능해진 것이다. 이후 OVS가 LOCAL 경로를 다시 세팅하면 복구되지만, 세션은 이미 끊겼다.
재구성 후 연결 복구 (세션은 종료됨)
OVS가 br-ex의 LOCAL 경로와 플로우 테이블을 재구성한 뒤 br-ex 인터페이스가 다시 UP 상태로 전환되면, Host IP가 정상적으로 복구되고 통신이 다시 가능해진다. 하지만 세션(SSH, Web UI)은 이미 끊긴 상태이므로 재접속이 필요하다.

💡 왜 localnet 추가가 br-ex에 영향을 주는가?
type=localnet 포트는 OVN에서 물리 네트워크 연결을 위한 provider 포트이다. 이 포트는 ovn-bridge mappings에 정의된 OVS 브리지와 연결되며, 대부분의 환경에서 이는 br-ex이다. 따라서 localnet 포트를 추가하면 OVN은 해당 포트를 물리 네트워크에 연결하기 위해 br-ex를 재구성한다. 이 과정에서 br-int ↔ br-ex 사이의 패치 포트와 OpenFlow 규칙이 다시 적용되므로 일시적인 경로 재조정(플랩)이 발생할 수 있다.

그러나 재부팅 이후에도 문제가 완전히 해결된 것은 아니었다. Compute 노드만 ssh 연결이 안되는 문제가 있었는데, 생성했던 localnet 포트를 삭제(ovn-nbctl lsp-del ln-phynet2)한 뒤 노드를 재부팅하자 SSH 연결이 정상적으로 복구되었다.

문제의 원인은 OVN이 Compute 노드를 provider 네트워크 uplink 노드로 오인해 br-ex를 통한 데이터 경로를 구성하려 했기 때문이다. 그 결과 관리 네트워크 트래픽이 잘못된 경로를 따라가면서 통신 경로가 꼬이게 되었고, Compute 노드에 외부 접근이 불가능한 상태가 발생했다.

여기서 다른 노드들은 ssh 접속에 문제가 없었는데 Compute 노드만 접속이 안됐던 이유는 다음과 같다. ln-phynet2 같은 논리 포트 정보는 OVN Northbound DB에 저장된 뒤 모든 노드의 ovn-controller가 이를 구독해 플로우를 동기화하는 방식으로 동작한다. 그러나 논리 구성 정보가 전파되었다고 해서 노드의 물리 네트워크 경로가 변경되는 것은 아니다. OVN이 실제로 물리 브리지 br-ex와 연동하여 외부 네트워크와 연결되는 데이터 플레인 경로를 구성하는 작업은 bridge_mappings가 선언된 노드에서만 수행된다. 즉, OVN이 localnet 네트워크를 물리 네트워크에 연결하려면 phynet2:br-ex와 같이 bridge_mappings가 필요하며, 이 설정이 있는 노드에서만 OVN이 br-ex를 통해 외부 uplink 연결을 시도한다.

Compute 노드는 phynet2:br-ex 매핑이 선언되어 있었기 때문에 OVN은 Compute 노드에서도 br-ex를 provider uplink 용도로 사용하려고 시도했고, 이 과정에서 관리 트래픽 경로까지 br-ex를 통해 OVN datapath로 라우팅되며 SSH 연결이 끊기는 현상이 발생했다. 반면 storage 노드는 bridge_mappings 설정이 없어 OVN이 해당 노드의 물리 NIC나 br-ex를 건드리지 않았고, network 노드는 애초에 provider 네트워크 트래픽을 담당하는 노드라 충돌이 발생하지 않았다.

과정을 정리해보면,

ln-phynet2 존재
→ OVN이 Compute 노드를 provider uplink 노드(외부 네트워크로 나가는 게이트웨이 역할을 하는 노드)로 간주
→ Compute 노드에서도 br-ex를 통해 external 경로 구성 시도
→ 관리망 라우팅이 br-ex를 통해 OVN datapath로 빨려들어감
→ 관리망 세션(SSH, 컨트롤러 연결 등) 끊김
→ lsp-del ln-phynet2 후 OVN이 provider 경로 구성을 중단 (br-ex를 더 이상 잡아먹지 않음)
→ Compute 노드 관리 네트워크 경로 복구
→ SSH 정상 동작

이번 문제를 통해 OVN 환경에서는 단일 NIC로 관리망과 외부 네트워크 트래픽을 모두 처리할 경우 충돌과 장애 위험이 크다는 점을 실감했으며, 운영 안정성을 위해 SSH, API, DB, RPC와 같은 제어 및 관리 트래픽을 전담하는 관리망 NIC와 Provider/External NIC를 분리한 설계의 필요성을 확인했다. 다음 글에서 NIC를 분리하는 과정을 살펴보자.