Using OpenStack Networking You can use OpenStack Networking in the following ways: Expose the OpenStack Networking API to cloud tenants, which enables them to build rich network topologies. Have the cloud administrator, or an automated administrative tool, create network connectivity on behalf of tenants. A tenant or cloud administrator can both perform the following procedures.
Core OpenStack Networking API features After you install and run OpenStack Networking, tenants and administrators can perform create-read-update-delete (CRUD) API networking operations by using either the neutron CLI tool or the API. Like other OpenStack CLI tools, the neutron tool is just a basic wrapper around the OpenStack Networking API. Any operation that can be performed using the CLI has an equivalent API call that can be performed programmatically. The CLI includes a number of options. For details, refer to the OpenStack End User Guide.
API Abstractions The OpenStack Networking v2.0 API provides control over both L2 network topologies and the IP addresses used on those networks (IP Address Management or IPAM). There is also an extension to cover basic L3 forwarding and NAT, which provides capabilities similar to nova-network. In the OpenStack Networking API: A 'Network' is an isolated L2 network segment (similar to a VLAN), which forms the basis for describing the L2 network topology available in an OpenStack Networking deployment. A 'Subnet' associates a block of IP addresses and other network configuration (for example, default gateways or dns-servers) with an OpenStack Networking network. Each subnet represents an IPv4 or IPv6 address block and, if needed, each OpenStack Networking network can have multiple subnets. A 'Port' represents an attachment port to a L2 OpenStack Networking network. When a port is created on the network, by default it is allocated an available fixed IP address out of one of the designated subnets for each IP version (if one exists). When the port is destroyed, its allocated addresses return to the pool of available IPs on the subnet. Users of the OpenStack Networking API can either choose a specific IP address from the block, or let OpenStack Networking choose the first available IP address. The following table summarizes the attributes available for each of the previous networking abstractions. For more operations about API abstraction and operations, please refer to the Networking API v2.0 Reference.
Network Attributes
Attribute Type Default value Description
admin_state_up bool True Administrative state of the network. If specified as False (down), this network does not forward packets.
id uuid-str Generated UUID for this network.
name string None Human-readable name for this network; is not required to be unique.
shared bool False Specifies whether this network resource can be accessed by any tenant. The default policy setting restricts usage of this attribute to administrative users only.
status string N/A Indicates whether this network is currently operational.
subnets list(uuid-str) Empty list List of subnets associated with this network.
tenant_id uuid-str N/A Tenant owner of the network. Only administrative users can set the tenant identifier; this cannot be changed using authorization policies.
Subnet Attributes
Attribute Type Default Value Description
allocation_pools list(dict) Every address in cidr, excluding gateway_ip (if configured). List of cidr sub-ranges that are available for dynamic allocation to ports. Syntax: [ { "start":"10.0.0.2", "end": "10.0.0.254"} ]
cidr string N/A IP range for this subnet, based on the IP version.
dns_nameservers list(string) Empty list List of DNS name servers used by hosts in this subnet.
enable_dhcp bool True Specifies whether DHCP is enabled for this subnet.
gateway_ip string First address in cidr Default gateway used by devices in this subnet.
host_routes list(dict) Empty list Routes that should be used by devices with IPs from this subnet (not including local subnet route).
id uuid-string Generated UUID representing this subnet.
ip_version int 4 IP version.
name string None Human-readable name for this subnet (might not be unique).
network_id uuid-string N/A Network with which this subnet is associated.
tenant_id uuid-string N/A Owner of network. Only administrative users can set the tenant identifier; this cannot be changed using authorization policies.
Port Attributes
Attribute Type Default Value Description
admin_state_up bool true Administrative state of this port. If specified as False (down), this port does not forward packets.
device_id string None Identifies the device using this port (for example, a virtual server's ID).
device_owner string None Identifies the entity using this port (for example, a dhcp agent).
fixed_ips list(dict) Automatically allocated from pool Specifies IP addresses for this port; associates the port with the subnets containing the listed IP addresses.
id uuid-string Generated UUID for this port.
mac_address string Generated Mac address to use on this port.
name string None Human-readable name for this port (might not be unique).
network_id uuid-string N/A Network with which this port is associated.
status string N/A Indicates whether the network is currently operational.
tenant_id uuid-string N/A Owner of the network. Only administrative users can set the tenant identifier; this cannot be changed using authorization policies.
Basic operations Before going further, it is highly recommended that you first read the few pages in the OpenStack End User Guide that are specific to OpenStack Networking. OpenStack Networking's CLI has some advanced capabilities that are described only in that guide. The following table provides just a few examples of the neutron tool usage.
Basic OpenStack Networking operations
Action Command
Create a network. $ neutron net-create net1
Create a subnet associated with net1. $ neutron subnet-create net1 10.0.0.0/24
List ports on a tenant. $ neutron port-list
List ports on a tenant, and display the id, fixed_ips, and device_owner columns. $ neutron port-list -c id -c fixed_ips -c device_owner
Display details of a particular port. $ neutron port-show port-id
The device_owner field describes who owns the port. A port whose device_owner begins with: "network:" is created by OpenStack Networking. "compute:" is created by OpenStack Compute.
Administrative operations The cloud administrator can perform any neutron call on behalf of tenants by specifying an OpenStack Identity tenant_id in the request, as follows: $ neutron net-create --tenant-id=tenant-id network-name For example: $ neutron net-create --tenant-id=5e4bbe24b67a4410bc4d9fae29ec394e net1 To view all tenant IDs in OpenStack Identity, run the following command as an OpenStack Identity (keystone) admin user: $ keystone tenant-list
Advanced operations The following table provides a few advanced examples of using the neutron tool to create and display networks, subnets, and ports.
Advanced OpenStack Networking operations
Action Command
Create a "shared" network (that is, a network that can be used by all tenants). $ neutron net-create --shared public-net
Create a subnet that has a specific gateway IP address. $ neutron subnet-create --gateway 10.0.0.254 net1 10.0.0.0/24
Create a subnet that has no gateway IP address. $ neutron subnet-create --no-gateway net1 10.0.0.0/24
Create a subnet in which DHCP is disabled. $ neutron subnet-create net1 10.0.0.0/24 --enable_dhcp False
Create subnet with a specific set of host routes. $ neutron subnet-create test-net1 40.0.0.0/24 --host_routes type=dict list=true destination=40.0.1.0/24,nexthop=40.0.0.2
Create subnet with a specific set of dns nameservers. $ neutron subnet-create test-net1 40.0.0.0/24 --dns_nameservers list=true 8.8.8.7 8.8.8.8
Display all ports/IPs allocated on a network. $ neutron port-list --network_id net-id
Using OpenStack Compute with OpenStack Networking
Basic Operations
Basic Compute/Networking operations
Action Command
Check available networks. $ neutron net-list
Boot a VM with a single NIC on a selected OpenStack Networking network. $ nova boot --image img --flavor flavor --nic net-id=net-id vm-name
Search for all ports with a device_id corresponding to the OpenStack Compute instance UUID. $ neutron port-list --device_id=vm-id
Search for ports, but limit display to only the port's mac_address. $ neutron port-list -c mac_address --device_id=vm-id
Temporarily disable a port from sending traffic. $ neutron port-update port-id --admin_state_up=False
Delete a VM. $ nova delete --device_id=vm-id
When you: Boot a Compute VM, a port on the network is automatically created that corresponds to the VM Nic. You may also need to configure security group rules to allow access to the VM. Delete a Compute VM, the underlying OpenStack Networking port is automatically deleted as well.
Advanced VM creation
VM creation operations
Action Command
Boot a VM with multiple NICs. $ nova boot --image img --flavor flavor --nic net-id=net1-id --nic net-id=net2-id vm-name
Boot a VM with a specific IP address: first create an OpenStack Networking port with a specific IP address, then boot a VM specifying a port-id rather than a net-id. $ neutron port-create --fixed-ip subnet_id=subnet-id,ip_address=IP net-id $ nova boot --image img --flavor flavor --nic port-id=port-id vm-name
Boot a VM that connects to all networks that are accessible to the tenant who submits the request (without the --nic option). $ nova boot --image img --flavor flavor vm-name
OpenStack Networking does not currently support the v4-fixed-ip parameter of the --nic option for the nova command.
Security Groups (Enabling Ping and SSH on VMs) You must configure security group rules depending on the type of plugin you are using. If you are using a plugin that: Implements OpenStack Networking security groups, you can configure security group rules directly by using neutron security-group-rule-create. The following example allows ping and ssh access to your VMs. $ neutron security-group-rule-create --protocol icmp --direction ingress default $ neutron security-group-rule-create --protocol tcp --port-range-min 22 --port-range-max 22 --direction ingress default Does not implement OpenStack Networking security groups, you can configure security group rules by using the nova secgroup-add-rule or euca-authorize command. The following nova commands allow ping and ssh access to your VMs. $ nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 $ nova secgroup-add-rule default tcp 22 22 0.0.0.0/0 If your plugin implements OpenStack Networking security groups, you can also leverage Compute security groups by setting security_group_api = neutron in nova.conf. After setting this option, all Compute security group commands are proxied to OpenStack Networking.