Neutron is the networking service that lets every OpenStack project build its own isolated, software-defined networks without touching a physical switch. On a modern cloud it is usually backed by OVN, which programs the data plane so tenants get private subnets, routers, and public connectivity entirely through the API. Understanding this layer is what turns a single bootable instance into a properly connected application.

This tutorial builds tenant networking from the ground up: a private network and subnet, a router that links it to the provider network, and floating IPs that expose instances to the outside world. It is the practical companion to launching your first instance, and it builds on Linux fundamentals like bridge networking that sit beneath the SDN layer.

Prerequisites

• A running OpenStack 2025.2 cloud with the openstack client and project-scoped credentials.
• An existing external (provider) network created by the cloud admin. List it to get its name.
• The member role on your project so you can create networks and routers.

source ~/acme-openrc
openstack network list --external

The Neutron object model

Four objects do the work. A network is a Layer 2 broadcast domain. A subnet is an IP range with a gateway and DNS attached to a network. A router connects subnets to each other and to the external network, performing SNAT for outbound traffic. A floating IP is a public address from the external network that you map (via DNAT) onto an instance's private port.

Step 1: Create a tenant network and subnet

Create a private network for your project, then carve a subnet out of it with a DHCP range, gateway, and DNS resolver. The CIDR is yours to choose because it is isolated from every other tenant.

openstack network create acme-net
openstack subnet create acme-subnet 

--network acme-net 

--subnet-range 10.0.0.0/24 

--gateway 10.0.0.1 

--dns-nameserver 1.1.1.1 

--allocation-pool start=10.0.0.10,end=10.0.0.200

Step 2: Create a router

A router gives the subnet a path to the outside. Create it, set the external network as its gateway, then attach the tenant subnet as an internal interface:

openstack router create acme-router
openstack router set acme-router --external-gateway ext-net
openstack router add subnet acme-router acme-subnet

With the gateway and internal interface in place, instances on acme-subnet can already reach the internet outbound via source NAT. Inbound access still requires a floating IP.

Step 3: Verify routing

Inspect the router to confirm it has both an external gateway and an internal port on your subnet:

openstack router show acme-router -c external_gateway_info -c name
openstack port list --router acme-router

Step 4: Allocate and associate a floating IP

To make an instance reachable from outside, allocate a floating IP from the external network and bind it to the instance. The instance must already be on acme-net:

openstack floating ip create ext-net

note the returned address, e.g. 203.0.113.50
openstack server add floating ip web-01 203.0.113.50
openstack server show web-01 -c addresses

Neutron installs a DNAT rule on the router so traffic to 203.0.113.50 is forwarded to the instance's private address. Combined with an SSH security-group rule, you can now reach the VM.

Step 5: Test connectivity end to end

From a host on the external network, ping the floating IP, then SSH in. Inside the instance, confirm outbound routing works too:

ping -c3 203.0.113.50
ssh -i ~/.ssh/mykey.pem ubuntu@203.0.113.50

inside the VM:
ip route
ping -c3 1.1.1.1

Common errors and troubleshooting

External network has no subnet or no free IPs

If floating ip create fails, the provider network may be exhausted or lack a subnet. An admin can check with openstack subnet show on the external network and widen the allocation pool.

Instance can ping out but not be reached

Outbound works through SNAT even without a floating IP, so this points to a missing floating IP association or a security group that blocks inbound ICMP/SSH. Verify with openstack floating ip list and add the relevant rules from the security groups guide.

No route to host / router missing gateway

If outbound fails entirely, the router probably lacks an external gateway or the subnet interface. Re-run openstack router set --external-gateway and openstack router add subnet, then confirm with openstack router show.

MTU and fragmentation issues

Overlay networks (VXLAN/Geneve) add encapsulation overhead. If large packets hang while small ones work, lower the instance MTU or ensure the network's MTU is set correctly — a classic SDN gotcha inherited from the underlying tunnels.

Cleaning up

openstack server remove floating ip web-01 203.0.113.50
openstack floating ip delete 203.0.113.50
openstack router remove subnet acme-router acme-subnet
openstack router delete acme-router
openstack network delete acme-net

Conclusion

You have built a complete tenant network: a private subnet, a router to the outside, and floating IPs that expose instances on demand — all software-defined and isolated from every other project. This self-service networking is the same model that public clouds offer, running on infrastructure you control. Pair it with security groups to lock down access and with your first instance for a complete workload.

Designing resilient, multi-tenant SDN at scale — with redundant routers, sane MTUs, and predictable performance — is exactly what clouditiv operates for you on a managed on-premise cloud, so your teams get self-service networking without owning the SDN complexity.