We run multiple teams on the same OpenStack platform, one project per team. Traffic between two projects always hairpins through the gateway nodes, even with DVR enabled. This is expected behavior, not a misconfiguration. Below is the technical summary of why.

What DVR distributes

  • East-west between networks on the same router: routed locally on the ingress chassis, tunneled to the destination chassis. Fully distributed.
  • North-south with a floating IP: the chassis hosting the VM performs the 1:1 NAT and answers ARP for the FIP on the external network. Distributed, but requires the provider network to be attached to every compute node and distributed FIP to be enabled.
  • North-south with SNAT: centralized. The router’s external address is shared by all VMs behind it; it can be ARP-owned at only one point of the external segment, and the NAT state must live in a single conntrack table. It is pinned to a gateway chassis by design.

DVR distributes only what it can bind 1:1 to a single chassis. Everything based on a shared, stateful address is centralized.

Inter-project traffic

Two projects means two routers; there is no common router, so the traffic is never east-west (unless both projects attach to the same shared/provider network, which bypasses the per-project networks entirely).

Direct routing between the projects is impossible because projects may use overlapping prefixes — the external network can route a prefix to only one destination. NAT is therefore mandatory, and the path is:

  • Egress from project A: SNAT on router A’s gateway chassis (centralized), or A’s floating IP (distributed).
  • Ingress to project B: only via a floating IP on the destination VM. Without a FIP, the destination is simply unreachable from outside its project — there is no DNAT to enter through.
flowchart LR
  VMA["project A VM"] -->|"SNAT (centralized)<br/>or FIP (distributed)"| EXT["external network"]
  EXT -->|"FIP/DNAT required"| VMB["project B VM"]

So at best this is FIP-to-FIP communication over the external network — two independent NAT operations, not tenant-to-tenant routing. DVR never routes between the two topologies.

Sharing one router between the projects would make the traffic east-west, but Neutron resists it: it requires RBAC workarounds, a router cannot hold interfaces with overlapping subnets, and the address space must then be coordinated across projects (shared subnet pools, address scopes). At that point the projects are effectively merged.

The conclusion: overlapping IP support and traffic isolation are the purpose of tenancy. A platform that allows two projects to run the same 10.10.10.0/24 cannot route between them directly — the limitation is the isolation guarantee itself, comparable to separate root accounts on a public cloud. Teams that need distributed routing between each other belong in the same project.

IPv6 tenant networks

Neutron has no NAT for IPv6 — no floating IPs, no SNAT. DVR’s entire north-south distribution mechanism is NAT-based, so it has nothing to work with:

  • The fabric has one route for the tenant prefix, pointing at the router’s gateway port.
  • That port and its ND responder exist on exactly one chassis.
  • There is no per-VM binding on the external segment to anchor per-chassis answers.

All IPv6 north-south traffic is therefore centralized even with DVR enabled (documented explicitly for ML2/OVS; OVN behaves the same, since its distributed path is implemented per dnat_and_snat record with external_mac — records that do not exist for IPv6).

The way out

Both cases are solved only by a different model: expose the tenant topology to the fabric via routing. BGP agents advertising host routes from the chassis handle floating IPs and IPv6 without the Layer-2 external network; EVPN L3 VPN integration maps tenant networks to VRFs in the fabric, separating overlapping prefixes by VRF instead of NAT. Native BGP-EVPN support with type-5 routes is being added to OVN itself. Until then: isolation per project, centralized routing between projects — as designed.

The content of this post was created by the author; AI was used for editing and restructuring.