Ports

The Network service (OpenStack Neutron) implements ports as the logical attachment between a network and a device, most often a VM’s virtual NIC, but also router interfaces and other integrations. Ports carry IP configuration, MAC addresses, security group bindings, and metadata the platform uses to program switches and routers. They are the layer where “this instance is on this subnet with these addresses and these firewall rules” becomes real.

IP addresses, security policies, and floating IPs in the API and Console all resolve through port objects.

What a port represents#

A port is a connection point on a network. It receives one or more IP addresses from the subnet’s allocation pool (IPv4, IPv6, or both). It has a MAC address for Ethernet framing on the L2 fabric. When you attach a security group, rules apply to traffic entering or leaving through that port.

Fixed IPs stay tied to the port on the private network. A floating IP associates with a port when you need a public address that can be remapped without rebuilding the instance.

Capabilities#

Ports act as attachment points for instance NICs and router internal interfaces. They carry address assignment, MAC identity, and security group enforcement so packets reach the correct destination.

State fields such as ACTIVE or DOWN reflect whether the port is bound and usable. Name and key-value metadata help you correlate ports with instance names or automation tags. You manage ports through the Console, CLI, or REST API for repeatable infrastructure.

How ports fit the datapath#

Creating a network defines an isolated L2 domain; subnets carve out IP ranges and options (gateway, DNS). When you create an instance on a network, Neutron creates a port per NIC, assigns addresses from the subnet, connects the port to the virtual switch, and applies security groups. Traffic between instances on the same network bridges at L2; traffic to other subnets or the internet flows through routers, NAT, and floating IP mappings according to your topology.

DHCP, DNS integration, and extra routes are often expressed at the subnet and router layers, but the port is still the object that owns the addresses your instance sees on the wire inside the guest.

Troubleshooting often starts at the port when packets never arrive despite a listening process: wrong subnet, missing security group rule, or absent floating association.

Manual creation and extra interfaces#

Launching an instance creates its primary port for you, but you can also create ports explicitly and attach them when you need additional NICs, preselected fixed addresses, or automation-driven topologies. Multi-homed designs use explicit port creation when one NIC faces a private application network and another faces management.

Metadata on ports (names, tags, or integration-specific keys) helps operators and scripts correlate OpenStack resources with application tiers without inferring from IP alone.

Typical use cases#

Ports enable basic instance connectivity, enforce per-NIC firewall policy, front load-balanced services by targeting member addresses and ports, and give you audit points (IP, MAC, security groups) when diagnosing connectivity.

When something “listens on 0.0.0.0” inside the guest but clients still cannot connect, check the security group on the port, the route to the subnet, and the floating IP association. If a reverse proxy fronts the workload, check its backend route and health status too.

Further reading#

On this platform:

• Networks: the L2 domains that ports attach to
• Security groups: traffic filtering rules applied at the port level
• Floating IPs: public addresses associated with ports
• Ports console: console reference for port management
• Ports CLI reference: all openstack port commands

External resources:

• OpenStack Neutron port documentation: upstream reference for port architecture, DHCP, and metadata