Learn OpenStack - Neutron Networking Fundamentals (Networks, Subnets & Ports)
Episode 6 of 21

Learn OpenStack - Neutron Networking Fundamentals (Networks, Subnets & Ports)

This episode opens the networking phase: the Neutron SDN architecture with the ML2 plugin and mechanism drivers, the difference between provider networks and self-service networks, subnet definition with CIDR, gateway, DHCP pool, and DNS, and the concept of ports as virtual NICs.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Introduction

Welcome to the Networking Phase! Up to episode 5, you created instances living on DevStack's default private network without really knowing what happens behind it. Episode 6 changes that: you'll understand how OpenStack builds virtual networks on top of physical networks — this is the essence of Neutron, OpenStack's Networking Service and SDN (Software-Defined Networking).

Neutron is the service most often misunderstood by beginners because its terminology piles up: network, subnet, port, provider, self-service, VXLAN. This episode breaks them all down one by one: the Neutron SDN architecture with the ML2 plugin, then the three fundamental objects — networks, subnets, and ports. After this episode, you can build networks from scratch without copying commands you don't understand.

Neutron SDN Architecture

Separating the Logical Plane from Physical Infrastructure

SDN is essentially one sentence: separating network control from physical hardware and turning it into logic managed through APIs. Neutron is the implementation of SDN in OpenStack. You command via the API openstack network create, and Neutron translates it into real configuration on a virtual switch — not a physical one.

Neutron's position in OpenStack SDN
API user (openstack network create)

Neutron Server (ML2 Plugin + DB)

Mechanism Driver (OVS / LinuxBridge)

Agent on Compute/Network Node → virtual switch

The Neutron Server itself doesn't handle data packets. It only manages state and commands the agents running on the nodes. Data packets flow through the agents and virtual switches.

ML2 Plugin and Mechanism Drivers

ML2 (Modular Layer 2) is Neutron's core plugin that handles the abstraction of networks, subnets, and ports in a modular way. ML2 has two layers:

  • Type Drivers: determine the network technology used, such as flat, vlan, gre, and vxlan.
  • Mechanism Drivers: determine the implementation mechanism on the switch, mainly Open vSwitch (OVS) and LinuxBridge.

DevStack uses Open vSwitch by default. The mechanism driver and type driver configuration lives in ml2_conf.ini, and this choice determines your entire networking behavior.

Neutron Basic Networking Concepts

Provider Networks

A provider network is a network mapped directly to physical infrastructure. It fits cases that need low latency and direct access — for example, management networks or segments that already exist on a physical switch. There are two main types:

  • Flat: a single network without segmentation, passing straight through to a physical port.
  • VLAN: the network is mapped to a physical VLAN with provider:segmentation_id.
View the provider network configuration
openstack network show public -f value -c provider:network_type
openstack network show public -f value -c provider:physical_network
openstack network show public -f value -c provider:segmentation_id

The output of openstack network show public shows the type, physical network, and segmentation ID of DevStack's default public network. Provider networks are usually created by admins, not by project users.

Self-Service / Tenant Networks

A self-service network — often called a tenant network — is a virtual network isolated per project. Instances inside it are invisible from the outside unless they go through a virtual router. Segmentation uses overlays:

  • VXLAN: tunneling with a 24-bit VNI, suitable for large scale.
  • GRE: an alternative tunneling option also supported by ML2.
Create a self-service network
openstack network create --project proyek-riset net-aplikasi

openstack network create --project proyek-riset net-aplikasi creates a VXLAN overlay network that only the proyek-riset project can see. This is the multi-tenancy pattern: one physical cloud, many isolated networks.

Subnets

A subnet is a logical IP block within a network — the definition of CIDR, gateway, DHCP pool, and DNS nameservers. A single network can have many subnets, for example IPv4 and IPv6.

Create a subnet with DHCP
openstack subnet create --network net-aplikasi \
  --subnet-range 192.168.100.0/24 \
  --dhcp --dns-nameserver 8.8.8.8 \
  subnet-aplikasi

The main parameters you must understand:

ParameterFunction
--subnet-rangeThe IP block CIDR, e.g. 192.168.100.0/24
--dhcpEnables the DHCP pool
--dns-nameserverThe DNS distributed to instances
--gatewayThe gateway address, defaulting to the CIDR's first IP

The openstack subnet create command above creates a /24 subnet with DHCP and DNS 8.8.8.8. Instances attached to this network automatically get an IP from that pool.

Ports

A port is a virtual connection point — think of it as a virtual NIC. An instance attaches to a network through a port, and each port has a MAC address plus one or more IP addresses. Advanced operators often create the port first, then attach it to an instance:

Create a port and attach it to an instance
openstack port create --network net-aplikasi --fixed-ip ip-address=192.168.100.50 port-web
openstack server create --image ubuntu-jammy --flavor m1.small \
  --port port-web --key-name mykey ubuntu-port

openstack port create --fixed-ip ip-address=192.168.100.50 reserves a static IP for the instance — the pattern used for servers that need a fixed IP, such as databases or API gateways. Port security is managed through security groups, which we'll cover in episode 7.

Practice: Building a Network from Scratch

Assembling Network, Subnet, and Port

Now let's combine everything in a single practice flow:

Assemble a complete network
openstack network create net-dev
openstack subnet create --network net-dev --subnet-range 10.10.10.0/24 --dhcp subnet-dev
openstack port create --network net-dev port-dev-1
openstack port list --network net-dev

Verify the results:

Verify network objects
openstack network list
openstack subnet list
openstack port list

If all three objects appear with the right status, you've successfully built a virtual network from scratch — not just used the default network.

Summary

Episode 6 lays the foundation for the entire networking phase: Neutron as SDN with the ML2 plugin and OVS/LinuxBridge mechanism drivers, the distinction between provider networks and self-service networks, the anatomy of a subnet with CIDR, gateway, DHCP, and DNS, and ports as the virtual NICs that connect instances to networks.

Key takeaways:

  • Neutron separates network control from physical hardware through the ML2 plugin.
  • Provider networks map to physical infrastructure; self-service networks use VXLAN/GRE overlays.
  • A subnet defines CIDR, gateway, DHCP pool, and DNS.
  • A port is a virtual NIC whose IP can be reserved as static.
  • The practical flow: create a network, then a subnet, then a port.
  • The ML2 type driver determines the technology: flat, vlan, vxlan, or gre.

In episode 7, we'll cover Neutron Routers, Floating IPs, and Security Groups — connecting tenant networks to the internet through virtual routers with SNAT and DNAT, allocating floating IPs that can be assigned and unassigned dynamically, and creating security groups as stateful firewalls for instances. Your network will soon be truly connected to the outside world!

Learn OpenStack - Neutron Networking Fundamentals (Networks, Subnets & Ports) | Learn OpenStack