/neutron

name: openstack-neutron
description: "OpenStack Neutron software-defined networking service. Provides network abstraction for cloud instances including security groups, floating IPs, DHCP, L3 routing, ML2 plugin architecture with OVN/OVS backends, network namespaces, provider and tenant networks, VXLAN/VLAN/flat network types, and port management. Use for deploying, configuring, operating, and troubleshooting OpenStack networking."
user-invocable: true
allowed-tools: Read Grep Glob
metadata:
  extensions:
    gsd-skill-creator:
      version: 1
      createdAt: "2026-02-23"
      triggers:
        intents:
          - "neutron"
          - "network"
          - "subnet"
          - "router"
          - "floating ip"
          - "security group"
          - "SDN"
          - "OVN"
          - "OVS"
          - "DHCP"
          - "L3"
          - "port"
        contexts:
          - "deploying openstack networking"
          - "configuring SDN"
          - "troubleshooting network connectivity"
          - "managing security groups"

OpenStack Neutron -- Software-Defined Networking

Neutron is OpenStack's networking service and the most complex component in the stack. It provides the network abstraction layer that connects every instance, container, and service in the cloud. Where physical networking uses cables, switches, and routers, Neutron virtualizes all of these into software constructs that operators manage through APIs.

Architecture

Neutron uses the **ML2 (Modular Layer 2) plugin** architecture, which separates the network model from the mechanism that implements it. The ML2 plugin supports multiple mechanism drivers -- the two primary backends for Kolla-Ansible deployments are:

• **OVN (Open Virtual Network):** The recommended backend for new deployments. OVN provides distributed virtual routing, native DHCP, and security group implementation without requiring separate agents. It uses a northbound/southbound database architecture for state management.
• **OVS (Open vSwitch):** The legacy backend that uses separate agents for L3 routing, DHCP, and metadata. Each function runs in its own network namespace. More mature but more complex operationally.

**Network types supported:** flat (untagged), VLAN (802.1Q tagged), VXLAN (overlay tunnels), GRE (generic routing encapsulation). Single-node deployments typically use flat for provider networks and VXLAN for tenant networks.

**The agent model (OVS backend):** Neutron runs multiple agents -- `neutron-openvswitch-agent` (L2 connectivity), `neutron-l3-agent` (routing and NAT), `neutron-dhcp-agent` (IP assignment), `neutron-metadata-agent` (instance metadata). Each agent manages its domain through network namespaces. OVN consolidates these into `ovn-controller` on each node.

Deploy

Kolla-Ansible Configuration

Key settings in `globals.yml`:

# Backend selection (choose one)
neutron_plugin_agent: "ovn"          # Recommended for new deployments
# neutron_plugin_agent: "openvswitch"  # Legacy, more agents to manage

# External network interface (the physical NIC for provider networks)
neutron_external_interface: "eth1"    # Adjust to your hardware

# Provider networks (required for floating IPs and external access)
enable_neutron_provider_networks: "yes"

# DVR (Distributed Virtual Router) -- disable for single-node
enable_neutron_dvr: "no"

# Network types
neutron_tenant_network_types: "vxlan"
neutron_type_drivers: "flat,vlan,vxlan"

Network Bridge Configuration

The external bridge (`br-ex`) connects Neutron to the physical network:

# Verify the bridge exists after deployment
docker exec openvswitch_vswitchd ovs-vsctl show
# Should show br-ex with neutron_external_interface as a port

# For OVN: verify integration bridge
docker exec openvswitch_vswitchd ovs-vsctl show | grep br-int

Container Verification

# List Neutron containers
docker ps --format '{{.Names}}' | grep neutron

# Expected containers (OVN backend):
# neutron_server, neutron_ovn_metadata_agent
# Plus OVN containers: ovn_controller, ovn_northd, ovsdb-nb, ovsdb-sb

# Expected containers (OVS backend):
# neutron_server, neutron_openvswitch_agent, neutron_l3_agent,
# neutron_dhcp_agent, neutron_metadata_agent

# Check agent status
openstack network agent list
# All agents should show "alive" and "UP"

Configure

Provider Networks vs Tenant Networks

• **Provider networks** are mapped to physical network infrastructure. They provide external connectivity and floating IP pools. Created by admins only.
• **Tenant networks** are virtual overlay networks (VXLAN) that tenants create for their instances. Isolated from each other by default.

# Create a provider network (flat, mapped to physnet1)
openstack network create --share --external \
  --provider-physical-network physnet1 \
  --provider-network-type flat \
  provider-net

# Create a provider subnet with allocation pool
openstack subnet create --network provider-net \
  --subnet-range 192.168.1.0/24 \
  --gateway 192.168.1.1 \
  --allocation-pool start=192.168.1.100,end=192.168.1.200 \
  --dns-nameserver 8.8.8.8 \
  provider-subnet

Subnet Configuration

Key parameters for every subnet: CIDR range, gateway IP, DHCP allocation pool (avoid overlap with static IPs), DNS nameservers, and host routes.

# Create a tenant subnet with DHCP
openstack subnet create --network tenant-net \
  --subnet-range 10.0.0.0/24 \
  --gateway 10.0.0.1 \
  --dns-nameserver 8.8.8.8 \
  tenant-subnet

Router Configuration

Routers connect tenant networks to provider networks and provide SNAT for outbound traffic and DNAT for floating IPs.

# Create a router and set its external gateway
openstack router create main-router
openstack router set --external-gateway provider-net main-router
openstack router add subnet main-router tenant-subnet

Security Groups

Default security group policy: **deny all ingress, allow all egress**. Every