OpenStack OVS Networking: br-int, br-tun, and br-ex

Summary

Open vSwitch는 Linux host 안에서 VM의 virtual NIC, overlay tunnel과 physical NIC를 연결하는 software switch다. OpenStack에서 Neutron ML2/OVS backend를 사용하면 OVS agent가 Neutron의 network state를 OVS Port와 OpenFlow rule로 변환한다.

VM
│
TAP interface
│
br-int
├── br-tun ── VXLAN ── Remote Node
└── br-ex  ── Physical NIC ── External Network

이 글은 ML2/Open vSwitch agent backend를 기준으로 한다. OVN도 Open vSwitch를 data plane으로 사용하지만 보통 별도의 br-tun 대신 br-int에서 Geneve tunnel을 처리한다. 따라서 OVS를 사용한다고 항상 세 bridge가 모두 존재하는 것은 아니다.

Lab Environment

Kolla-Ansible 설정은 다음과 같다.

neutron_external_interface: "ens36"
neutron_plugin_agent: "openvswitch"

Neutron OVS agent에는 개념적으로 다음 설정이 적용된다.

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

[agent]
tunnel_types = vxlan

local_ip은 node 자신의 overlay tunnel endpoint다. cloud02에는 cloud02의 tunnel IP가 필요하며, 모든 node에 172.16.8.136을 동일하게 넣는 값이 아니다.

OVS Components

OVS는 configuration database, userspace daemon과 kernel datapath가 함께 동작한다.

Neutron OVS Agent / Management Tools
                 │
                 ▼
            ovsdb-server
                 │ configuration
                 ▼
            ovs-vswitchd
                 │ flow programming
                 ▼
         Linux Kernel Datapath
                 │
        TAP / VXLAN / Physical NIC

ovsdb-server

ovsdb-server는 OVS의 지속적인 configuration state를 저장한다.

• Bridge와 Port 목록
• 각 Port에 연결된 Interface
• Physical NIC와 Bridge 관계
• Tunnel option과 controller endpoint

Packet forwarding에 사용하는 모든 dynamic datapath flow가 OVSDB에 저장되는 것은 아니다.

ovs-vswitchd and Kernel Datapath

ovs-vswitchd는 OVSDB 구성을 읽고 virtual switch를 구현하는 userspace daemon이다. OpenFlow와 datapath flow를 관리하며 Linux kernel OVS module과 통신한다.

일반적인 kernel datapath에서는 자주 처리되는 packet이 kernel fast path에서 forwarding된다. Flow miss가 발생하면 userspace가 처리 방법을 결정하고 datapath flow를 설치할 수 있다. 모든 packet이 매번 Kolla container의 userspace를 통과하는 것은 아니다.

neutron-openvswitch-agent

OVS 자체는 OpenStack Project, Network, Port, Security Group의 의미를 알지 못한다. neutron-openvswitch-agent가 Neutron의 desired state를 해당 host의 OVS 구성과 flow로 반영한다.

Neutron Server
      │
Neutron Open vSwitch Agent
      │
OVSDB configuration and OpenFlow rules
      │
Open vSwitch datapath

주요 역할은 다음과 같다.

• VM VIF를 br-int에 연결
• Local VLAN과 Neutron segmentation ID 매핑
• VXLAN tunnel endpoint와 flow 관리
• Provider bridge와 br-int 연결
• Security Group rule 적용
• Port 상태를 Neutron Server에 보고

Security Group이 iptables_hybrid driver를 사용하면 VM TAP와 br-int 사이에 qbr... Linux bridge가 존재할 수 있다. Native OVS firewall driver에서는 경로가 달라지므로 실제 topology를 확인해야 한다.

OVS Tools

ovs-vsctl은 OVSDB 구성을 조회하거나 수정하는 client다. 그 자체가 switch process는 아니다.

sudo ovs-vsctl show
sudo ovs-vsctl list-br
sudo ovs-vsctl list-ports br-ex
sudo ovs-vsctl port-to-br ens36

OpenFlow rule은 sudo ovs-ofctl dump-flows <bridge>로 확인한다.

Kolla 환경에서는 관련 container 안에서 명령을 실행해야 올바른 socket에 연결되는 경우가 있다.

Bridge Roles

br-int: Integration Bridge

br-int는 OpenStack workload와 virtual network를 연결하는 중심 bridge다.

VM eth0
  │
TAP or VIF
  │
br-int

환경에 따라 VM VIF, DHCP와 Router namespace interface, br-tun 및 provider bridge로 이어지는 patch port가 연결된다. 같은 Neutron network의 local traffic은 br-int를 통해 전달되지만, 서로 다른 network 사이의 L3 routing은 Neutron Router가 담당한다.

br-tun: Tunnel Bridge

br-tun은 ML2/OVS agent가 VXLAN 같은 overlay를 처리하는 bridge다.

cloud01                           cloud02
br-int                            br-int
  │ patch-tun                       │ patch-tun
br-tun ───── VXLAN over IP ────── br-tun

Tenant frame이 node 사이를 이동할 때 br-int의 node-local VLAN tag와 VXLAN VNI가 서로 매핑된다.

Local VLAN on br-int
→ VXLAN VNI on br-tun
→ Underlay IP network
→ Remote br-tun
→ Remote local VLAN

local_ip은 host underlay에서 다른 tunnel endpoint가 도달할 수 있는 주소여야 한다. VM tenant IP나 Floating IP가 아니다.

br-ex: External Bridge

br-ex는 OpenStack의 provider physical network를 실제 NIC와 연결한다.

Neutron external path
        │
      br-ex
        │
      ens36
        │
VMware external network

다음 명령으로 ens36의 연결을 확인할 수 있다.

sudo ovs-vsctl port-to-br ens36

br-ex

NIC를 bridge에 넣으면 기존 host IP 연결이 끊길 수 있다. SSH와 management traffic에 사용하는 NIC를 그대로 external interface로 지정하지 않도록 Kolla의 host network layout을 먼저 확인해야 한다.

Physical Network Mapping

bridge_mappings는 Neutron physical network label을 host의 OVS bridge에 연결한다.

bridge_mappings = physnet1:br-ex

physnet1
   │ mapping
   ▼
 br-ex
   │ port
   ▼
 ens36

physnet1은 Linux interface 이름이나 OpenStack Network display name이 아니다. Provider network 생성 시 provider:physical_network로 참조한다.

openstack network create \
  --external \
  --share \
  --provider-network-type flat \
  --provider-physical-network physnet1 \
  clover-public

ML2 설정에서도 physnet1의 flat network 사용이 허용되어 있어야 한다. Bridge mapping만으로 모든 provider network type을 사용할 수 있는 것은 아니다.

Kolla and the Host Kernel

Host service로 실행하는 OVS와 Kolla container의 OVS는 다른 제품이 아니다. 같은 OVS daemon을 누가 배포하고 lifecycle을 관리하는지가 다르다.

Kolla Containers
├── openvswitch_db
├── openvswitch_vswitchd
└── neutron_openvswitch_agent
          │
          ▼
Host Linux kernel OVS datapath
          │
br-int / br-tun / br-ex
          │
TAP / VXLAN / ens36

Daemon이 container에 있어도 physical NIC, TAP와 kernel datapath는 host에 존재한다. Kolla가 OVS를 관리하는 host에서 별도 systemd OVS daemon을 독립적으로 시작하면 같은 database와 bridge를 두 관리 주체가 다룰 수 있으므로 하나의 lifecycle manager를 기준으로 운영해야 한다. Container 상태와 log는 docker ps와 docker logs로 확인하되 실제 이름은 version과 container engine에 따라 달라질 수 있다.

Packet Flows

아래 경로는 핵심 bridge만 표시한 것이다. Firewall driver, Router mode와 provider network type에 따라 Linux bridge, namespace와 patch port가 추가될 수 있다.

Same Compute Node

같은 Neutron network의 VM이 같은 compute host에 있으면 tunnel을 사용하지 않는다.

VM-A → TAP → br-int → TAP → VM-B

Different Compute Nodes

서로 다른 compute host에서는 VXLAN overlay를 통과한다.

VM-A → cloud02 br-int → br-tun
     → VXLAN over underlay
     → remote br-tun → br-int → VM-B

Centralized External Path

Legacy 또는 centralized L3 구조에서는 network node의 Router namespace를 거쳐 외부로 나간다.

VM on cloud02 → br-int → br-tun
→ VXLAN → cloud01 br-tun → br-int
→ Router namespace: routing / SNAT
→ br-ex → ens36 → External Network

Router의 internal interface와 external interface가 어느 bridge에 연결됐는지 확인해야 실제 경로를 알 수 있다. DVR을 사용하면 East-West routing이나 Floating IP traffic 일부가 compute node에서 처리될 수 있으므로 모든 외부 traffic이 cloud01을 통과한다고 단정할 수 없다.

Floating IP는 VM NIC에 직접 추가되는 주소가 아니라 Neutron routing path의 NAT rule로 fixed IP와 연결된다.

External Client
→ Floating IP
→ DNAT
→ VM Fixed IP

Project Topology

현재 lab의 resource와 physical path를 연결하면 다음과 같다.

VM Fixed IP: 192.168.21.x
        │
clover-private / clover-private-subnet
        │
clover-router
        │
clover-public
        │
provider:physical_network = physnet1
        │
bridge_mappings = physnet1:br-ex
        │
br-ex → ens36
        │
VMware network: 172.16.8.0/24

External Subnet은 172.16.8.0/24, gateway는 172.16.8.2로 계획했다. Allocation pool은 VMware DHCP 범위, gateway와 OpenStack host IP를 제외해야 한다. Nested VMware에서 여러 source MAC이 ens36을 통해 보이면 virtual switch의 forged transmit, MAC change 또는 promiscuous 관련 설정도 확인해야 한다.

Troubleshooting

먼저 bridge, port와 agent 상태를 확인한다.

sudo ovs-vsctl list-br
sudo ovs-vsctl show
sudo ovs-vsctl list-ports br-int
sudo ovs-vsctl list-ports br-tun
sudo ovs-vsctl list-ports br-ex

openstack network agent list

Agent 설정은 container에서 확인할 수 있다.

sudo docker exec neutron_openvswitch_agent \
  grep -E '^\s*(bridge_mappings|tunnel_types|local_ip)' \
  /etc/neutron/plugins/ml2/openvswitch_agent.ini

문제가 발생하면 다음 순서로 범위를 좁힌다.

1. Neutron Port가 ACTIVE이고 예상 compute host에 binding됐는지 확인한다.
2. VM VIF와 Security Group path가 br-int에 연결됐는지 확인한다.
3. 다른 host traffic이면 br-tun, tunnel port와 local_ip 도달성을 확인한다.
4. Provider traffic이면 bridge_mappings, br-ex, ens36을 확인한다.
5. Router namespace, route와 NAT rule을 확인한다.
6. TAP → bridge → tunnel NIC → external NIC 순서로 tcpdump를 실행한다.

Bridge가 존재한다는 사실만으로 정상이라고 판단할 수 없다. Agent, OpenFlow rule, namespace와 underlay 연결을 함께 봐야 한다. 운영 중 flow를 직접 변경하면 Neutron agent가 덮어쓸 수 있으므로 우선 관찰용 명령으로 원인을 확인한다.

ML2/OVS vs. OVN

OVN 환경에서 neutron_openvswitch_agent나 br-tun이 없다고 바로 장애로 판단하면 안 된다. 먼저 neutron_plugin_agent와 실제 backend를 확인해야 한다.

Key Takeaways

• OVSDB는 구성을 저장하고, ovs-vswitchd와 kernel datapath가 forwarding을 구현한다.
• Neutron OVS agent는 OpenStack network state를 OVS Port와 OpenFlow rule로 반영한다.
• br-int는 workload 연결, br-tun은 overlay tunnel, br-ex는 physical network 연결을 담당한다.
• physnet1:br-ex는 Neutron physical network label과 host bridge의 mapping이다.
• Kolla 환경에서도 fast path는 host kernel에 있으며 daemon lifecycle은 container가 관리한다.
• Packet path는 centralized L3, DVR와 firewall driver에 따라 달라진다.
• ML2/OVS와 OVN은 모두 OVS를 사용하지만 control plane과 tunnel 구조가 다르다.

References

• Open vSwitch Introduction
• Open vSwitch Architecture
• Neutron Open vSwitch Agent Configuration
• Neutron OVS Self-service Networks
• Neutron OVS Provider Networks
• Kolla-Ansible Neutron Guide