Kyunghoon Kim
Notes

OpenStack / Jun 15, 2026 / 9 min

OpenStack Neutron: Networking for Instances

Network, Subnet, Port, Router, Floating IP와 Security Group부터 OVN·OVS 및 동적 Swarm Worker 구성까지 정리한다.

OpenStackNeutronOVNOpen vSwitch

Summary

Neutron은 OpenStack 인스턴스에 가상 네트워크, IP 주소, 라우터와 보안 정책을 제공하는 Networking Service다. Nova가 VM의 compute resource와 lifecycle을 관리한다면, Neutron은 VM이 다른 VM이나 외부 네트워크와 통신할 수 있도록 연결을 준비한다.

Neutron이 관리하는 대표 기능은 다음과 같다.

  • 가상 Network와 Subnet 생성
  • Port 생성과 IP 주소 할당
  • VM의 가상 NIC 연결
  • 가상 Router와 외부 Network 연결
  • Floating IP와 NAT 구성
  • Security Group 적용
  • DHCP와 metadata 접근 제공

Neutron은 사용자가 요청한 네트워크의 desired state를 API와 database에 관리한다. 실제 packet forwarding은 배포 backend에 따라 OVN, Open vSwitch, Linux bridge 같은 구성 요소가 수행한다.

Core Resources

ResourceRole
NetworkVM과 다른 device가 연결되는 논리적 L2 network다.
SubnetNetwork에서 사용할 CIDR, gateway, allocation pool, DNS 같은 IP 설정을 정의한다.
PortVM의 가상 NIC 같은 device를 Network에 연결하는 논리적 접점이다.
RouterSubnet 사이의 L3 routing과 external network 연결을 제공한다.
Security GroupPort 단위로 ingress와 egress traffic을 제어하는 stateful virtual firewall 규칙이다.
Floating IPExternal network의 주소를 Port의 fixed IP와 연결한다.
External NetworkOpenStack 외부의 provider network로 나가는 연결 지점을 표현한다.

리소스의 관계를 단순화하면 다음과 같다.

External Network
       │
   Router Gateway
       │
    Router
       │
  Subnet / Network
       │
     Port
       │
   VM Virtual NIC

Network and Subnet

Network는 논리적인 L2 broadcast domain을 표현하고, Subnet은 그 Network에서 사용할 IP 주소 체계를 정의한다. 하나의 Network에 IPv4와 IPv6처럼 여러 Subnet을 연결할 수도 있다.

Network: app-network
├── Subnet: 192.168.10.0/24
│   ├── Gateway: 192.168.10.1
│   └── DNS: 1.1.1.1
└── Ports
    ├── 192.168.10.20
    └── 192.168.10.21

Self-service network는 project가 직접 만드는 격리된 가상 network다. 외부 통신에는 보통 Neutron Router와 External Network 연결이 필요하다. Provider network는 datacenter의 flat 또는 VLAN network에 직접 매핑되며, 구성에 따라 VM이 물리 network와 L2로 연결될 수 있다.

Neutron Port

Neutron의 Port는 TCP·UDP port number가 아니다.

VM의 가상 NIC 같은 device가 가상 Network에 연결되는 논리적인 접점이다.

Port에는 다음과 같은 정보가 포함될 수 있다.

  • MAC address
  • Fixed IP와 Subnet
  • Security Group
  • 연결된 Network
  • device ID와 device owner
  • 어느 compute host에 binding되었는지에 대한 정보
VM
└── Virtual NIC
    └── Neutron Port
        ├── MAC address
        ├── Fixed IP
        ├── Security Groups
        └── Network

Port는 VM보다 먼저 직접 만들 수도 있고, VM 생성 요청 중 Nova가 Neutron에 생성을 요청할 수도 있다. 미리 만든 Port를 사용하면 원하는 fixed IP, Security Group, allowed address pair 같은 설정을 instance 생성 전에 확정할 수 있다.

Instance Network Lifecycle

VM 생성 과정에서 Nova와 Neutron은 다음과 같이 협력한다.

User requests a server
        │
        ▼
Nova selects a compute host
        │
        ▼
Neutron creates or looks up a Port
        │
        ├── Allocates a fixed IP
        ├── Applies Security Groups
        └── Binds the Port to the host
        │
        ▼
Backend configures the virtual datapath
        │
        ▼
Nova attaches a virtual NIC and starts the VM

Nova는 vCPU, memory, disk와 hypervisor scheduling을 담당한다. Neutron은 Network, Port, IP와 연결 정책을 준비한다. 실제 순서와 port binding 방식은 Nova·Neutron 설정과 backend에 따라 세부적으로 달라질 수 있지만 역할의 경계는 같다.

VM이 다른 node의 VM과 통신하면 backend는 provider VLAN 또는 Geneve, VXLAN 같은 overlay tunnel을 통해 packet을 전달할 수 있다.

VM A
→ virtual NIC
→ local virtual switch
→ VLAN or overlay tunnel
→ remote virtual switch
→ VM B

External Connectivity

Router and External Network

Self-service network의 VM이 외부와 통신하려면 일반적으로 Router의 external gateway가 필요하다.

VM
→ Self-service Network
→ Neutron Router
→ External Network
→ Physical Network

Router는 서로 연결된 Subnet 사이를 route하고, IPv4 self-service network가 외부로 나갈 때 SNAT을 제공할 수 있다. Router가 network node에서 중앙 처리되는지, compute node에 분산되는지는 ML2/OVS, DVR, OVN과 deployment topology에 따라 달라진다.

Fixed IP and Floating IP

Fixed IP는 Neutron Port에 연결된 Subnet에서 할당된 주소다. 흔히 private network의 사설 IP지만, provider network의 주소일 수도 있으므로 Fixed IP = 항상 RFC1918 사설 IP는 아니다.

Floating IP는 External Network에서 할당해 Port의 fixed IP에 연결하는 외부 접근용 주소다.

External Client
      │
Floating IP: 203.0.113.20
      │ DNAT
Fixed IP: 192.168.10.20
      │
     VM

Floating IP는 일반적으로 VM 내부 interface에 직접 설정되지 않는다. Neutron의 logical mapping과 backend의 NAT rule을 통해 fixed IP로 변환된다. 필요하면 같은 Floating IP의 연결 대상을 다른 Port로 변경할 수도 있다.

외부 traffic이 gateway node를 통과하는 중앙형 구조와 compute node에서 직접 처리되는 distributed floating IP 구조가 모두 가능하다. 따라서 실제 packet path를 확인할 때는 사용 중인 backend와 DVR 설정을 함께 봐야 한다.

Security, DHCP, and Metadata

Security Groups

Security Group은 Port의 ingress와 egress traffic을 제어하는 stateful allow rule 집합이다. 하나의 Port에 여러 Security Group이 연결되면 허용 규칙은 합쳐서 적용된다.

DirectionProtocolPortExample
IngressTCP22관리 network에서 SSH 허용
IngressTCP80HTTP service 공개
IngressTCP443HTTPS service 공개
IngressICMP해당 ICMP type진단 목적의 ping 허용

일반적인 default Security Group은 egress를 허용하고 ingress를 제한하지만, cloud operator가 default rule을 변경할 수 있으므로 실제 환경의 규칙을 확인해야 한다. Stateful rule에서는 허용된 connection의 return traffic을 위한 반대 방향 규칙을 별도로 만들 필요가 없다.

Security Group은 guest OS 내부 firewall과 별개다.

Neutron Security Group
→ Port 경계의 virtual firewall

nftables / iptables / firewalld
→ VM 내부 firewall

외부에서 접속할 수 있으려면 두 계층 모두 traffic을 허용해야 한다.

DHCP

DHCP가 활성화된 Subnet에서는 VM이 다음 정보를 받을 수 있다.

  • IP address와 subnet mask
  • Default gateway
  • DNS server
  • Host route
VM boots
→ Sends a DHCP request
→ Receives network configuration
→ Configures its interface

ML2/OVS deployment에서는 Neutron DHCP agent와 dnsmasq가 이를 제공할 수 있고, OVN backend는 logical switch의 DHCP option을 이용한 native DHCP를 사용할 수 있다. 따라서 Neutron이 DHCP를 제공한다는 API 관점의 설명과 실제 DHCP packet을 처리하는 backend 구성 요소를 구분해야 한다.

Metadata

Instance는 보통 169.254.169.254의 metadata endpoint를 통해 SSH public key, hostname, user data 같은 정보를 가져온다. Cloud-init은 이 정보를 이용해 초기 설정을 수행할 수 있다.

Neutron은 network가 겹칠 수 있는 multi-tenant 환경에서 metadata 요청이 어느 instance에서 왔는지 식별해 Nova metadata service로 전달하는 경로에 관여한다. OVN 환경에서는 OVN metadata agent와 local port가 이 기능을 구현할 수 있다.

Default egress rule을 제거하면 metadata endpoint의 TCP 80 접근까지 막힐 수 있으므로 제한적인 egress 정책을 설계할 때 주의해야 한다.

Nova and Neutron

ServiceResponsibility
NovaVM 생성, scheduling, compute resource와 lifecycle 관리
NeutronNetwork, Port, IP, routing과 network security 관리
Nova prepares the VM
        +
Neutron prepares network connectivity
        ↓
Running instance with attached virtual NICs

Nova가 --network 또는 --nic 요청을 처리하면 Neutron의 Network나 Port를 사용해 virtual NIC를 VM에 연결한다. Neutron이 VM process를 실행하는 것도 아니고, Nova가 virtual network의 desired state를 직접 구현하는 것도 아니다.

Neutron, OVN, and Open vSwitch

Neutron, OVN, Open vSwitch는 서로 다른 계층을 담당한다.

ComponentRole
Neutron API사용자가 요청한 Network, Port, Router, Security Group의 상태를 관리한다.
ML2/OVN mechanism driverNeutron resource를 OVN의 logical resource로 변환한다.
OVNLogical Switch, Logical Router, ACL과 distributed network policy를 계산한다.
Open vSwitch각 node에서 flow rule에 따라 실제 packet을 forwarding한다.

조금 더 자세한 control flow는 다음과 같다.

User / Nova
    │
Neutron API
    │
ML2/OVN Driver
    │
OVN Northbound DB
    │
ovn-northd
    │
OVN Southbound DB
    │
ovn-controller on each node
    │
Open vSwitch flows
    │
Packet forwarding

예를 들어 Neutron Security Group은 OVN의 Port Group과 ACL로 표현되고, Neutron Port는 OVN Logical Switch Port로 연결된다. ovn-controller는 해당 node에 필요한 logical flow를 실제 OVS flow로 설치한다.

따라서 다음과 같이 이해할 수 있다.

Neutron defines what networking should exist.
OVN translates that intent into distributed logical networking.
Open vSwitch executes packet forwarding on each node.

이 설명은 OVN backend를 사용할 때의 구조다. ML2/OVS backend에서는 Neutron L2, L3, DHCP agent와 Linux network namespace가 더 직접적인 역할을 맡으므로 두 architecture의 troubleshooting 명령과 packet path가 다르다.

Dynamic Swarm Worker Example

OpenStack에서 동적으로 Docker Swarm Worker VM을 만든다면 Neutron은 다음을 담당한다.

  • Worker VM의 Network와 Port 연결
  • Fixed IP 할당
  • Security Group 적용
  • SSH 또는 Ansible 접근 경로 제공
  • image와 package 다운로드를 위한 외부 통신
  • cloud-init이 사용할 metadata 접근

Worker가 기존 Swarm에 직접 연결되는 구조라면 node 사이에 다음 traffic이 필요하다.

Protocol and PortPurposeScope
22/tcpSSH와 Ansible관리 host에서 Worker로만 제한
2377/tcpSwarm management와 joinWorker에서 Manager로 접근
7946/tcp, 7946/udpNode discovery와 gossip신뢰할 수 있는 Swarm node 사이
4789/udpVXLAN overlay data path신뢰할 수 있는 Swarm node 사이

4789/udp의 VXLAN traffic은 자체 인증을 제공하지 않으므로 public network나 perimeter에 노출하면 안 된다. 가능하면 전용 tenant network, 제한된 Security Group 또는 암호화된 network 경로를 사용해야 한다.

Controller calls OpenStack API
→ Nova schedules a Worker VM
→ Neutron creates a Port and fixed IP
→ Security Groups are applied
→ VM boots and reads cloud-init metadata
→ Docker and ZeroTier are installed
→ Worker joins the existing Swarm Manager

ZeroTier를 사용한다면 Neutron과 ZeroTier는 서로 대체되지 않는다. Neutron은 VM이 동작할 underlay 연결과 외부 통신을 만들고, ZeroTier는 VM 내부에서 node 사이의 overlay 경로를 만든다.

Swarm traffic을 ZeroTier interface로 보낼 때는 Manager의 --advertise-addr와 node의 --data-path-addr가 의도한 interface를 사용하는지 확인해야 한다. Neutron Security Group은 ZeroTier transport에 필요한 외부 traffic을 허용하고, VM 내부 firewall은 Swarm port를 ZeroTier interface와 신뢰할 수 있는 peer로 제한하는 방식으로 역할을 나눌 수 있다.

Common Misconceptions

  • Neutron Port는 TCP·UDP port number가 아니다.
  • Fixed IP는 Port의 Subnet에서 할당된 주소이며 항상 사설 IP인 것은 아니다.
  • Floating IP는 일반적으로 VM interface에 직접 설정되지 않고 fixed IP와 NAT로 연결된다.
  • Nova는 VM을 관리하고 Neutron은 VM의 network resource를 관리한다.
  • Security Group은 Neutron Port에 적용되며 guest firewall과는 별개다.
  • Neutron은 desired state를 관리하고 실제 packet 처리는 backend가 수행한다.
  • OVN과 ML2/OVS는 Router, DHCP, NAT의 구현 방식과 packet path가 다르다.
  • ZeroTier는 VM 내부 overlay이고 Neutron은 그 기반이 되는 cloud network를 제공한다.

Key Takeaways

  • Neutron은 Network, Subnet, Port, Router, Floating IP와 Security Group을 통해 instance connectivity를 구성한다.
  • Port는 VM의 virtual NIC를 Network에 연결하며 MAC, fixed IP와 보안 정책을 가진다.
  • 외부 연결에는 External Network와 Router가 사용되고, Floating IP는 외부 주소를 Port의 fixed IP와 연결한다.
  • Security Group, guest firewall, physical network ACL은 서로 다른 계층이므로 모두 확인해야 한다.
  • OVN backend에서는 Neutron의 desired state가 OVN logical resource와 OVS flow로 변환된다.
  • 실제 packet path는 backend와 centralized 또는 distributed routing 설정에 따라 달라진다.

Review Questions

  1. Network, Subnet, Port는 각각 어떤 정보를 표현하는가?
  2. Fixed IP와 Floating IP는 VM에서 어떻게 다르게 보이는가?
  3. Nova와 Neutron은 VM 생성 과정에서 어떻게 협력하는가?
  4. Security Group과 VM 내부 firewall을 모두 확인해야 하는 이유는 무엇인가?
  5. Neutron, OVN, Open vSwitch의 역할은 어떻게 구분되는가?
  6. Swarm의 4789/udp를 외부에 공개하면 안 되는 이유는 무엇인가?

References