Learn OpenStack - Production Networking: Provider Networks, VXLAN & DVR

#Introduction

Episodes 6-7 built networking that's conceptually correct; episode 15 builds networking that's correct at the production architecture level. In production, there's no single NIC doing everything, no VLAN left to chance, and no single node that becomes a routing bottleneck. All of that is solved with three pillars: a dual-NIC layout, well-organized provider networks, and DVR.

Episode 15 covers all three: how nodes are arranged with two separate NICs, how provider networks map to physical VLANs, how VXLAN isolates tenants, and how the Distributed Virtual Router removes the bottleneck at a centralized network node.

#Production Networking Architecture

#Dual-NIC Node Layout

Production OpenStack nodes don't use one interface for everything. The standard dual-NIC layout separates two network planes:

• Management NIC: carries API, message queue, database, and ssh traffic between nodes — an internal, unexposed segment.
• Provider/Tenant NIC: carries instance data traffic — physical VLANs and VXLAN/GRE overlays toward switches and external networks.

Node Controller / Compute
  ens192 → Management Network  (API, DB, RabbitMQ)
  ens224 → Provider/Tenant     (VLAN + VXLAN data plane)

This separation isn't just tidy — it protects the control plane from data traffic spikes and makes troubleshooting easier. In globals.yml, network_interface points to the management NIC and neutron_external_interface points to the provider NIC.

#Why One NIC Isn't Enough

If one NIC carried both, an instance traffic spike could slow down the APIs and database — your cluster would feel slow or even die in the worst case. Separating the planes is also a requirement for using DVR and lets you scale network capacity independently.

#Provider Networks (Flat & VLAN)

#Mapping to Physical VLANs

A provider network connects Neutron directly to physical networking through segmentation. For VLAN, each provider network is mapped to a VLAN ID on the managed switch — this configuration is a contract between Neutron and the network team.

openstack network create --project admin --share \
  --provider-network-type vlan \
  --provider-physical-network physnet1 \
  --provider-segment 100 net-vlan100

openstack network create --provider-network-type vlan --provider-segment 100 maps the network to VLAN 100 on the physnet1 physical network. On the switch, the ports connected to the node must be set as trunk ports for that VLAN.

#Flat Networks

A flat network maps a network to a segment without a VLAN tag — one large network that passes straight through to a specific physical segment. Common uses: the external network where floating IPs live, or infrastructure networks that don't need segmentation.

openstack network create --project admin --share \
  --provider-network-type flat \
  --provider-physical-network physnet2 external

The openstack network create --provider-network-type flat command above creates the external network for floating IPs — exactly like the public network in the lab, but with a clear physical mapping in production.

#Tenant VXLAN Overlay

#Multi-Tenant Isolation with Tunneling

For tenant networks, production uses VXLAN as the overlay: each tenant network gets a VNI (VXLAN Network Identifier) that logically separates it, and tenant packets are wrapped in UDP toward the destination node — crossing physical infrastructure without interfering with other networks.

openstack network show net-aplikasi -f value -c provider:network_type
openstack network show net-aplikasi -f value -c provider:segmentation_id

The output of openstack network show net-aplikasi shows the vxlan type and its VNI. Because VXLAN supports up to 16 million VNIs, tenant capacity is nearly unlimited compared to VLAN's limit of 4094.

#VLAN vs VXLAN in Production

VLAN is used for provider networks that need performance and physical integration. VXLAN is used for tenant networks that need isolation and scale. Both coexist: provider VLAN for external, VXLAN overlay for internal — exactly the architecture we'll assemble in episode 20.

#Distributed Virtual Router (DVR)

#The Centralized Network Node Problem

In the classic architecture, all routing happens on a centralized network node. The problem: all inter-tenant and internet traffic has to stop there — a single bottleneck and a single point of failure. With many compute nodes, this bottleneck becomes real.

#Distributing Routing to Compute Nodes

DVR (Distributed Virtual Router) moves the routing function to every compute node. Instances can route east-west (between instances) and north-south (to the internet) directly on the node where they run.

openstack network agent list --type l3 -f table

The output of openstack network agent list --type l3 shows the L3 agents on every node — with DVR, you'll see dvrsnat and l3 agents on compute nodes, not just the network node. In ml2_conf.ini and l3_agent.ini, DVR is enabled with agent_mode = dvr_snat.

#DVR Benefits

DVR provides three advantages: no routing bottleneck because the function is distributed, no SPOF because routing doesn't depend on a single node, and shorter east-west traffic because instances on the same compute node don't need to leave for the network node.

#Summary

Episode 15 brings your networking up to production standard: a dual-NIC layout separating the management and data planes, provider VLAN networks explicitly mapped to physical switches, VXLAN overlays for large-scale tenant isolation, and DVR distributing routing to every compute node to eliminate bottlenecks.

Key takeaways:

• Dual-NIC separates management traffic from instance data traffic.
• Provider VLAN maps Neutron to physical VLANs on managed switches.
• VXLAN gives tenant isolation with nearly unlimited VNI capacity.
• A centralized network node is a bottleneck and a SPOF.
• DVR distributes routing to compute nodes.
• Production uses VLAN for external and VXLAN for internal.

In episode 16, we'll cover Production Storage: Ceph Integration (RBD, RGW, CephFS) — why Ceph is the best storage backend for production OpenStack, integrating Glance, Cinder, and Nova with Ceph RBD, and sizing and deploying a Ceph cluster with a minimum of three OSD, monitor, and manager nodes.