Routers

The Network service (OpenStack Neutron) implements routers as virtual layer-3 gateways inside your project. They connect private subnets to each other and, when you set an external gateway, to provider or internet-facing networks. They perform NAT so instances with private addresses can initiate outbound sessions and so floating IPs can map inbound public addresses to specific instances.

A router decides which prefixes are directly connected, which need NAT, and where default routes should point.

Subnets without a routed path stay isolated within the project. Attach a router when you need traffic to leave the project or return on a controlled path.

Core functions#

Inter-subnet routing forwards between networks you attach to the same router so instances in different CIDR blocks can talk without extra hops through your own VMs.

External gateway links the router to a public or external network, which is where floating IP pools and default routes for internet access typically live.

NAT includes source NAT (SNAT) for outbound traffic from private addresses to the router’s external address, and destination NAT (DNAT) for inbound floating IP traffic destined to a private instance IP.

Routing tables hold connected routes for attached subnets and any static routes you add for special topologies.

High availability and distributed virtual routing (DVR) patterns spread or duplicate forwarding so a single network node failure does not sever all north-south traffic; exact behavior depends on platform deployment options.

With DVR, parts of the router datapath run closer to compute nodes hosting the instances, which can reduce centralized bottlenecks and hairpinning for east-west plus north-south flows in large deployments. Whether DVR is enabled, and how HA pairs fail over, is a platform characteristic; check Quake AI networking documentation for the supported modes in your region.

Routers forward packets between subnets and external gateways. Security groups and broader firewall policy filter which traffic reaches each port.

How routers fit a typical layout#

You define private networks for application tiers and an external network provided by the platform. A router gets an external gateway on that external network, then interfaces (connected subnets) on each private network that should reach the internet or each other through that gateway.

Multiple routers are useful when you want hard isolation between segments (one router per zone or per compliance boundary), so routing policy does not accidentally bridge networks that should never meet except through controlled inspection points.

Instances receive private IPs from their subnets. For inbound public access you allocate a floating IP from the external pool and associate it with the instance’s port; the router applies DNAT. For outbound internet access, instances default-route to the router, which SNATs to the external gateway address as needed.

Operational considerations#

Combine routers with least-privilege security groups so exposure matches intent. If uptime requirements are strict, use HA-capable router deployments where available and monitor north-south traffic and error counters. As you add networks, plan whether each should attach to the same router or a different one to keep blast radius and routing complexity under control.

Default routes advertised to subnets typically send internet-bound traffic to the router that owns the external gateway; more specific static routes override that behavior when you peer to on-prem networks or dedicated appliances.

Further reading#

On this platform:

• Create a router: step-by-step router creation via Console, CLI, and API
• Networks: private and external networks that routers connect
• Floating IPs: how public addresses map through router NAT
• Routers console: console reference for router management
• Routers CLI reference: all openstack router commands

External resources:

• OpenStack Neutron Layer 3 networking: upstream documentation for routing, NAT, and distributed virtual routing