Neutron: networking · Prasanta Kumar Behera

OpenStack networking from the tenant's view to the wire: provider vs self-service networks, routers and floating IPs, security groups, the ML2 plugin with OVS or OVN, and how to trace an instance's traffic when it has no connectivity.

Self-service networks per project, joined to the outside by a Neutron router.

Two kinds of networks

	Provider networks	Self-service (tenant) networks
Created by	Admins	Project users
Maps to	A physical network (flat or VLAN)	An overlay (VXLAN or Geneve)
Routing	The physical network's routers	Neutron routers (with SNAT)
Public access	Instance IPs are directly routable	Floating IPs (1:1 NAT)
Typical use	Telecom/NFV, simple setups, performance	General cloud tenancy

Provider networks are like giving a flat a door straight onto the public street. Self-service networks are like a private corridor inside the building for each tenant; to go outside, you pass through the building's main door (the router), which hides which flat you live in (SNAT). A floating IP is a street address that forwards visitors to one specific flat.

Tenant building blocks

$ openstack network create private
$ openstack subnet create --network private --subnet-range 10.0.0.0/24 --dns-nameserver 10.1.0.53 private-subnet
$ openstack router create r1
$ openstack router set r1 --external-gateway public
$ openstack router add subnet r1 private-subnet
$ openstack server create --flavor m1.small --image ubuntu-24.04 --network private --key-name mykey vm1
$ openstack floating ip create public
$ openstack server add floating ip vm1 203.0.113.50

Security groups are stateful, per-port firewalls (like AWS security groups). The default group allows traffic between its members and all egress, but no inbound from elsewhere: add rules for SSH/HTTP as needed.

Under the hood: ML2 with OVS or OVN

Neutron's ML2 plugin drives a mechanism driver:

	OVS + agents (classic)	OVN (current default in many deployments)
Control	L2/L3/DHCP/metadata agents on nodes	`ovn-northd` translates Neutron into logical flows; `ovn-controller` on each chassis
Routers	`qrouter-` namespaces on network nodes (or DVR on computes)	Distributed logical routers
DHCP	`qdhcp-` namespaces with dnsmasq	Native in OVN flows
Debug tools	`ip netns`, `ovs-vsctl show`, `ovs-ofctl dump-flows`	`ovn-nbctl show`, `ovn-sbctl show`, `ovn-trace`

Overlays add headers: tenant networks typically get an MTU of 1450 (VXLAN) or 1442 (Geneve) on a 1500-byte physical network, unless the underlay uses jumbo frames (see Networking Deep Dive, lesson 01).

Troubleshooting an unreachable instance

Walk it in order:

Port: openstack port list --server vm1 --long: is it ACTIVE, bound to the right host?
IP: did the instance get its address? (console log: openstack console log show vm1). If not, check DHCP (agent namespace, or OVN).
Security group: does a rule allow the traffic? (ICMP and SSH are the usual missing ones.)
Router and floating IP: is the router's gateway set, the subnet attached, the floating IP associated with the right port?
Physical: provider network VLANs trunked to the right switch ports; MTU consistent end to end.

With OVN, ovn-trace simulates a packet through the logical topology and tells you exactly which rule dropped it.

Try it: build and break tenant networking (lab cloud)

Build the private network, router and floating IP setup above; SSH into the instance via its floating IP.
Remove the SSH rule from the security group, and confirm SSH times out. Add it back.
Detach the subnet from the router; confirm outbound internet fails from the instance but in-network traffic works.
Find the instance's port and follow it on the compute node (ovs-vsctl show for OVS, or ovn-sbctl show for OVN).
Check the instance's MTU (ip link inside) and explain it.

Going deeper: Neutron at scale

Plan VLAN ranges, VNI ranges and external networks with the network team up front; changes later touch every tenant.
Use Octavia for tenant load balancers (amphora VMs, or the OVN provider for simple L4).
For high-performance workloads, SR-IOV ports and DPDK-accelerated OVS give near-line-rate networking, at the cost of flexibility (security groups, live migration limits).
Monitor agent liveness (openstack network agent list) or OVN database health; a dead agent or out-of-sync OVN DB silently breaks new ports.

Recap

Provider networks map to physical VLAN/flat networks; self-service networks are overlays with routers, SNAT and floating IPs.
Security groups are stateful per-port firewalls; the default allows no inbound.
ML2 + OVS agents (namespaces) or OVN (distributed logical flows); know the debug tools for yours.
Troubleshoot: port → IP/DHCP → security group → router/floating IP → physical/MTU.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.