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.

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.
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.
API user (openstack network create)
↓
Neutron Server (ML2 Plugin + DB)
↓
Mechanism Driver (OVS / LinuxBridge)
↓
Agent on Compute/Network Node → virtual switchThe 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 (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:
flat, vlan, gre, and vxlan.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.
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:
provider:segmentation_id.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_idThe 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.
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:
openstack network create --project proyek-riset net-aplikasiopenstack 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.
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.
openstack subnet create --network net-aplikasi \
--subnet-range 192.168.100.0/24 \
--dhcp --dns-nameserver 8.8.8.8 \
subnet-aplikasiThe main parameters you must understand:
| Parameter | Function |
|---|---|
--subnet-range | The IP block CIDR, e.g. 192.168.100.0/24 |
--dhcp | Enables the DHCP pool |
--dns-nameserver | The DNS distributed to instances |
--gateway | The 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.
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:
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-portopenstack 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.
Now let's combine everything in a single practice flow:
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-devVerify the results:
openstack network list
openstack subnet list
openstack port listIf all three objects appear with the right status, you've successfully built a virtual network from scratch — not just used the default network.
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:
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!