> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.
# Quotas and troubleshooting
> Telling a routing problem from a filtering one, what each refusal is protecting, the order things have to come apart in, and the quotas.
## Silence has two causes
A packet that never arrives looks identical whether the route is missing or the
security group dropped it. From outside there is no difference at all, which is
why "check the security group" is the wrong first move about half the time.
The two fail differently on the *other* side, and that is the tell:
**Outbound from the instance also fails.** The reply to an inbound packet
has no way out, so nothing works in either direction — `curl` from inside
the instance hangs too.
Check the subnet's route table for a `0.0.0.0/0` (or `::/0`) entry and
confirm it targets a gateway that is attached to *this* VPC. See
[routing](/networking/routing).
**Outbound from the instance still works**, because a new group allows all
egress by default. Only the specific inbound port is silent.
Check the interface's groups, and remember an interface in **no** group
drops everything. See [security groups](/networking/security-groups).
A third case looks like both: **IPv6 works over v4 and fails over v6**. The
default egress rule a new security group starts with is IPv4 only, so a
dual-stack instance can have wide-open v4 and no `::/0` egress at all. Add an
`ipv6` egress rule explicitly.
## What each refusal is protecting
Every one of these is a guard against leaving something pointing at nothing.
The message names the blocker; this is what it is defending.
| You tried to | It refuses when | Because |
| ------------------------------------------ | ---------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Attach a floating IP | the subnet has no default route to an internet gateway | the address would be dead on arrival, and would look like a filtering problem |
| Delete the `0.0.0.0/0` route | floating IPs in the table's subnets depend on it | it would silently unreach every one of them |
| Attach a second floating IP to a NIC | one is already attached | a NIC has one public identity |
| Attach a second interface to an address | it already has a member | see [anycast](/networking/floating-ips#one-address-in-front-of-several-instances) |
| Release a floating IP | it is still attached, or a pool owns it | the owner would lose an address underneath it |
| Detach or delete a gateway | a route still targets it | the route would point at nothing |
| Delete a NAT gateway's subnet | the gateway lives there | same |
| Delete an interface | an instance or floating IP holds it | deleting it would break the attachment, even if the instance is stopped |
| Delete a VPC | subnets remain, or a gateway is attached | same |
| Delete a subnet | interfaces remain, a NAT gateway lives there, or another resource holds an address in it | the third is the surprising one: a load balancer's VIP sits in your subnet without being an interface |
| Delete a security group | an interface still belongs to it | that interface would silently lose its rules |
| Delete a route table | it is `main`, or subnets still use it | subnets would have no routing |
| Add a second route to the same destination | one already exists | there is no equal-cost pair here |
Adding a second route to the same destination returns `409`. No route is
created, and the existing one is untouched.
## Attachment and health fields
`attached_to` contains the owning instance's UUID, or null when no instance
holds the interface. Stopping an instance does not release its NICs.
`DELETE /v1/interfaces/{interface_id}` refuses while an instance binding or
a floating IP holds the interface. Detach it from the instance and detach
any floating IP first. List the instance's NICs on the [compute](/compute)
API to manage its attachments.
`unknown` means nobody is checking that member — the default for one you
attached yourself with no `health_check` on the address. It stays advertised.
Configure a `health_check` on the floating IP (the same shape as a load
balancer target group's: protocol, path, port, interval, timeouts,
healthy/unhealthy thresholds, matcher) and each member's `health` then
reflects it: `healthy` while the check passes, `unhealthy` while it fails,
and the member's `reason` says why — `passing`, `probe_failed` (the service
is not answering), `booting` (the guest has not been reached yet), or
`unprobed` (no check). An unhealthy member is withdrawn from the address; if
every member fails, the address goes dark, so a misconfigured check is a
visible outage rather than the platform advertising something it believes is
down.
Read a floating IP's `attached_to` for ownership: null means unattached;
otherwise it names the interface, instance pool, or load balancer by CRN.
An empty pool can still own an address with `members: []`. Member interface
and instance summaries may be null; see
[Reading the bindings](/networking/floating-ips#reading-the-bindings).
Without a readiness check, a pool member's health reflects guest liveness.
A booting replica remains listed as unhealthy and receives no traffic until
admitted. Healthy does not by itself prove your application is ready.
## Tearing it down in the right order
Each of these refusals exists because the step before it was skipped. Working
inwards:
Release refuses while attached, and the default-route delete refuses while
any floating IP in the table's subnets is live.
Every gateway type refuses detach and delete while a route still references
it.
A NAT gateway also blocks the delete of the subnet it lives in.
An attached gateway also blocks the VPC delete.
Detach each interface from its instance first — see
[interfaces](/networking/interfaces).
The console can do this walk for you. **Delete VPC** opens a plan page that
discovers everything inside the VPC, shows the order, and works through it —
which is the same order as above, because it is the same set of guards.
## Quotas
Six regional quotas apply to your organization. The names below are what the
[quota](/billing) API and the console report, and several do not match what the
resource is called:
| Quota | Counts |
| ----------------- | ----------------------------------------------- |
| `networks` | VPCs |
| `subnets` | subnets |
| `ports` | interfaces |
| `routers` | route tables |
| `security_groups` | security groups |
| `floating_ips_v4` | IPv4 floating IPs **and NAT gateway addresses** |
| `floating_ips_v6` | IPv6 floating IPs |
Public IPv4 is the one worth watching. Floating IPs and NAT gateway addresses
draw on the **same** `floating_ips_v4` allowance, so a NAT gateway costs you a
floating IP's worth of quota and a full allowance blocks both.
`rules_per_security_group` is a **per-resource** quota: it caps the rules on
each individual group, not the total across them. Hitting it on one group says
nothing about the others.
Nothing charges quota for gateways themselves, for routes, or for route-table
associations. An internet gateway and an egress-only gateway are free; a NAT
gateway is charged for its address, not for being a gateway.
## Next
The layer that fails silently, and how to read a table.
When the refusal is a `403` rather than a guard.