Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for OpenStack By James Joyner IV · · 10 min read

OpenStack Error Guide: 'Floating IP pool not found' external network failure

Allocating a floating IP and hitting Floating IP pool not found or ExternalNetworkNotReachable? Diagnose missing external networks and bad pool names step by step.

  • #openstack
  • #troubleshooting
  • #errors
  • #neutron

Exact Error Message

$ openstack floating ip create public
Floating IP pool not found.  Neutsecond (HTTP 404)

$ nova floating-ip-pool-list
ERROR (NotFound): Floating ip pool not found. (HTTP 404)

In the neutron-server log:

2026-06-27 19:11:48.226 8 INFO neutron.api.v2.resource [req-3c1a9d44-7b10-4e02-9a31-8c2b1d3e4400 ...]
create failed (client error): The network None could not be found.
2026-06-27 19:11:48.226 8 INFO neutron.api.v2.resource ExternalNetworkNotReachable:
External network <id> is not reachable from subnet ... Therefore, cannot associate Port ...
with a Floating IP.

What the Error Means

A floating IP in Neutron is allocated from a floating IP pool, which is simply a network flagged as external (router:external = True) that has a subnet with a public/routable address range. “Floating IP pool not found” means the request named (or defaulted to) a network that either does not exist, is not marked external, or has no subnet from which to draw an address.

The error therefore points at the external-network configuration, not at the floating IP itself. Either there is no external network at all, the pool name in the request does not match any external network, multiple external networks exist and none was specified, or the router that must carry the floating IP is not connected to that external network (ExternalNetworkNotReachable). The fix is to identify the correct external network and ensure the project’s router gateways it.

Common Causes

  • No external network exists — the deployment never created one, or it was deleted.
  • Network not flagged external — a candidate network exists but router:external is False, so it is not a valid pool.
  • Wrong pool/network name in the request — a typo or a stale name from an old environment.
  • External network has no subnet — the network is external but has no allocatable address range.
  • Multiple external networks, none specified — Neutron cannot pick a default and reports the pool as not found.
  • Router not gatewayed to the external networkExternalNetworkNotReachable when associating the FIP to a port.
  • Project lacks access (RBAC) — the external network is not shared with the requesting project.

How to Reproduce the Error

Request a floating IP from a non-existent pool:

  1. Confirm no network named public is flagged external.
  2. Run the allocation.
openstack floating ip create public

Neutron finds no external network matching public and returns Floating IP pool not found (HTTP 404). Creating a network without --external and then allocating from it reproduces the not-flagged-external variant. Associating a FIP to a port whose router has no gateway reproduces ExternalNetworkNotReachable.

Diagnostic Commands

Read-only. Identify the external networks and confirm one is usable as a pool.

# Which networks are external (valid floating IP pools)?
openstack network list --external
openstack network show <ext-net-id> -c name -c router:external -c subnets

# Does the external network have an allocatable subnet?
openstack subnet show <ext-subnet-id> -c cidr -c allocation_pools -c gateway_ip
+----+--------+-------------------+
| ID | Name   | router:external   |
+----+--------+-------------------+
| 7a | public | True              |
+----+--------+-------------------+

Check the router gateway (for the association variant) and the logs:

# Is the project's router gatewayed to the external network?
openstack router show <router-id> -c external_gateway_info

# Kolla-Ansible
docker logs neutron_server 2>&1 | grep -i "pool not found\|ExternalNetworkNotReachable" | tail
# Traditional packages
journalctl -u neutron-server | grep -i "pool not found\|ExternalNetworkNotReachable" | tail

Step-by-Step Resolution

  1. List the external networks. Run openstack network list --external. If it returns nothing, there is no floating IP pool at all — that is the root cause; an external network must be created.

  2. Verify the network is flagged external and has a subnet. A network missing router:external = True or lacking a subnet cannot serve floating IPs:

    openstack network show <ext-net-id> -c router:external -c subnets
  3. Allocate from the correct network by ID or exact name. Use the real external network rather than a guessed pool name:

    openstack floating ip create <ext-net-id-or-name>
  4. Specify the network explicitly when several externals exist. With multiple external networks, name the one you want so Neutron does not have to guess.

  5. Gateway the router to the external network for the association variant. If you see ExternalNetworkNotReachable, the router carrying the port needs an external gateway:

    openstack router set --external-gateway <ext-net-id> <router-id>
  6. Grant project access if RBAC is blocking it. If the external network is not visible to the project, share it (or use an admin to confirm visibility), then retry the allocation and confirm:

    openstack floating ip list --project <project-id>

Prevention and Best Practices

  • Maintain at least one clearly named external network (e.g. public) flagged router:external with a sized subnet, and document its name so users request the right pool.
  • When running multiple external networks, communicate which projects should use which, and have users always pass the network explicitly.
  • Monitor the external subnet’s allocation pool and alert before it exhausts — a depleted pool produces a different but related “no more IPs” failure.
  • Use Neutron RBAC to share external networks with the projects that need them, rather than leaving allocation to fail with a confusing 404.
  • Verify every tenant router has an external gateway before users attempt floating-IP associations, so ExternalNetworkNotReachable never surprises them.
  • ExternalNetworkNotReachable — the router carrying the port is not gatewayed to the external network.
  • No more IP addresses available on network — the external subnet’s allocation pool is exhausted; covered standalone in our /categories/openstack/ networking guides.
  • Router could not be created/updated: ... external gateway — a gateway-attach failure rather than a pool lookup.
  • FloatingIpLimitExceeded — a quota rejection, distinct from a missing pool.

Frequently Asked Questions

What exactly is a floating IP pool? It is a Neutron network flagged router:external = True with a subnet providing routable addresses. Floating IPs are drawn from that subnet’s allocation pool.

Why does the request default to a pool I do not have? Older clients and some workflows assume a pool named public or nova. If no external network has that name, you get a 404. Always allocate from the actual external network’s ID or name.

I have an external network but still get the error — why? Confirm it is genuinely flagged external (router:external = True) and has a subnet. A regular network, or an external network with no subnet, cannot serve as a pool.

What is the difference between this and ExternalNetworkNotReachable? “Pool not found” is a 404 at allocation time — the external network is missing or misnamed. ExternalNetworkNotReachable is an association-time error — the network exists but the router carrying the port lacks a gateway to it.

Does Kolla-Ansible configure an external network automatically? Not necessarily. Kolla-Ansible deploys Neutron, but the external/provider network is usually created post-deploy. If openstack network list --external is empty, create one before expecting floating IPs to work.

Free download · 368-page PDF

Download the Free 500-Prompt DevOps AI Toolkit

500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.

  • 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
  • Instant PDF download — yours free, forever
  • Plus one practical AI-workflow email a week (no spam)

Single opt-in · unsubscribe anytime · no spam.