OpenStack Neutron Network Calculator

Plan Neutron tenant networks: usable addresses per subnet, port counts, floating IP demand and VXLAN segment usage.

About OpenStack Neutron Network Calculator

Neutron consumes more of a subnet than the instances do: the network and broadcast addresses go first, then the router gateway, then one address per DHCP agent — and redundant DHCP means two. Port count matters separately because ports, not addresses, are what the ML2 plugin and the database actually track. Port count drives Neutron server and agent load far more than instance count does, and a subnet sized exactly to the instance count will fail its first scale-out because the infrastructure ports were never budgeted.

Formula

OpenStack Neutron Network

usable addresses = 2^(32 − prefix) − 2 − 1 gateway − DHCP agent ports; ports = instance ports + DHCP ports + router interfaces, and VXLAN usage = networks ÷ 16,777,216 available VNIs.

DHCP agent ports: One address per agent per subnet, doubled for agent redundancy
router interfaces: One port per network plus the external gateway port
16,777,216: VNIs addressable by the 24-bit VXLAN segment ID

Worked example

With the default values below, OpenStack Neutron Network Calculator returns Neutron Ports Required of 5,080. Change any input above and every figure here is recalculated in your browser.

Inputs used

Projects (tenants)accepts 1–20,000 projects: 40 projects
Networks per projectaccepts 1–100 networks: 2 networks
Subnet prefix lengthaccepts 8–30 bits: 24 bits
Instances per networkaccepts 1–4,000 instances: 60 instances
DHCP agents per networkaccepts 0–8 agents: 2 agents
Routers per projectaccepts 0–20 routers: 1 routers
Instances needing a floating IPaccepts 0–100 %: 35 %

Results

Neutron Ports Required: 5,080 ports
Usable Addresses per Subnet: 251 addresses
Tenant Networks: 80 networks
Floating IPs Required: 1,680 addresses
VXLAN Segment Usage: 0.0005%
Subnet Sizing Verdict: Comfortable address headroom for growth

Step by step

1Values used
2OpenStack Neutron Network
3Neutron Ports Required= 5,080 ports
4Usable Addresses per Subnet= 251 addresses
5Tenant Networks= 80 networks
6Floating IPs Required= 1,680 addresses
7VXLAN Segment Usage= 0.0005
8Subnet Sizing Verdict= Comfortable address headroom for growth

Assumptions and limits

The result is derived only from the 7 inputs listed above. Anything not among them is not part of the calculation.
In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
Figures are rounded for display to 4 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.

How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.

Frequently Asked Questions

How is OpenStack Neutron Network calculated?

usable addresses = 2^(32 − prefix) − 2 − 1 gateway − DHCP agent ports; ports = instance ports + DHCP ports + router interfaces, and VXLAN usage = networks ÷ 16,777,216 available VNIs. Neutron consumes more of a subnet than the instances do: the network and broadcast addresses go first, then the router gateway, then one address per DHCP agent — and redundant DHCP means two. Port count matters separately because ports, not addresses, are what the ML2 plugin and the database actually track.

Why does OpenStack Neutron Network matter?

Port count drives Neutron server and agent load far more than instance count does, and a subnet sized exactly to the instance count will fail its first scale-out because the infrastructure ports were never budgeted.

What values do I need to enter?

This calculator takes 7 inputs: Projects (tenants), Networks per project, Subnet prefix length, Instances per network, DHCP agents per network, Routers per project, Instances needing a floating IP. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Does VXLAN really give 16 million networks?

The 24-bit VNI space does, but practical limits arrive much sooner — the tunnel mesh, the number of ports per agent and the ML2 driver's database load all bite long before the VNI range is exhausted.