)
Introduction
Neutron defines two major types of networks that can be used to provide connectivity to OpenStack instances: provider networks and tenant networks. In general, provider networks are directly associated with a physical network in the data center. They are created by the OpenStack administrator on behalf of tenants and can either be dedicated to a particular tenant or shared across all tenants. On the other hand, tenant networks are created by tenants for use by their own instances and cannot be shared. Typically, tenants are unaware of how their tenant networks are physically realized.
The table below lists the various network topologies available with the NSX for vSphere Neutron plugin for Icehouse. It also attempts to compare and contrast each network topology. It’s important to note that it’s perfectly possible to use all of these network topologies simultaneously within a given tenant.
*If SNAT or DNAT is not used, the upstream next hop physical routers must be manually configured to send network traffic destined to the tenant network to the appropriate Neutron router (since Neutron does not currently support dynamic routing).
**Selection of an appropriate IP address space by tenants is a significant challenge, even if SNAT or DNAT is used. If the tenant picks an IP address space that is in use elsewhere in the enterprise (including RFC 1918 private address space), the tenant subnet and the enterprise subnet will be unable to communicate with each other since they are both using the same IP address space (OpenStack optionally applies NAT to the source IP address of network traffic sourced from inside the cloud but NOT to the source IP address of network traffic sourced from outside the cloud). Subnet pools (introduced in KIlo) and IPv6 prefix delegation (planned for Liberty) are mechanisms to deal with the tenant network IP address space selection issue. Unfortunately, the Horizon interface in Kilo has not been extended to support subnet pools. Horizon enhancements to support subnet pools are planned for the Liberty release.
Shared VLAN-backed Provider Networks
Shared VLAN-backed provider networks are visible and usable by all tenants.
The general form of the Neutron command to create a VLAN-backed provider network is:
net-create <network name> --provider:network_type vlan --provider:physical_network <dvs-moref> --provider:segmentation_id <VLAN ID>where “dvs-moref” is the managed object reference of the distributed virtual switch the distributed port group should be created on. The distributed port group name is created by concatenating the name of the Neutron network with the Neutron network UUID. For example, for the network below a distributed port group was created with the following name: “shared-provider-net-vlan15-b48815d2-9c1a-44fd-a6bd-9f8f86200402.”
If the argument “–provider:physical_network” is omitted, the distributed port group will be created on the distributed virtual switch that is specified by the dvs_id configuration parameter in the nsx.ini NSX-v plugin configuration file.
Note: The specified distributed virtual switch MUST span across the Compute and Edge clusters because the DHCP server (an NSX edge services gateway) resides in the Edge Cluster.
Here’s an example of Neutron commands to create a shared VLAN-backed provider network.
(neutron) net-create shared-provider-net-vlan15 --provider:network_type vlan --provider:segmentation_id 15 --shared
Created a new network:
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | b48815d2-9c1a-44fd-a6bd-9f8f86200402 |
| name | shared-provider-net-vlan15 |
| port_security_enabled | True |
| provider:network_type | vlan |
| provider:physical_network | dvs-7909 |
| provider:segmentation_id | 15 |
| shared | True |
| status | ACTIVE |
| subnets | |
| tenant_id | admin |
+---------------------------+--------------------------------------+
(neutron) subnet-create shared-provider-net-vlan15 10.250.211.0/26 --name shared-provider-subnet-vlan15 --allocation-pool start=10.250.211.4,end=10.250.211.62 --gateway=10.250.211.1
Created a new subnet:
+------------------+---------------------------------------------------+
| Field | Value |
+------------------+---------------------------------------------------+
| allocation_pools | {"start": "10.250.211.4", "end": "10.250.211.62"} |
| cidr | 10.250.211.0/26 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.250.211.1 |
| host_routes | |
| id | 958ea074-77cc-432f-b4e3-1f5d313ad118 |
| ip_version | 4 |
| name | shared-provider-subnet-vlan15 |
| network_id | b48815d2-9c1a-44fd-a6bd-9f8f86200402 |
| tenant_id | admin |
+------------------+---------------------------------------------------+
(neutron)Here’s what the network topologies look like for Tenant1 and Tenant2 after launching a few instances:
Dedicated VLAN-backed Provider Networks
Dedicated VLAN-backed provider networks are only visible and usable by the tenant that owns the network.
Here’s an example of Neutron commands to create dedicated VLAN-backed provider networks for Tenant1 and Tenant2.
(neutron) net-create dedicated-provider-net-vlan16 --provider:network_type vlan --provider:segmentation_id 16 --tenant-id Tenant1
Created a new network:
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | 9bac4b07-530e-4e2c-a247-29f408ec0959 |
| name | dedicated-provider-net-vlan16 |
| port_security_enabled | True |
| provider:network_type | vlan |
| provider:physical_network | dvs-7909 |
| provider:segmentation_id | 16 |
| shared | False |
| status | ACTIVE |
| subnets | |
| tenant_id | Tenant1 |
+---------------------------+--------------------------------------+
(neutron) subnet-create dedicated-provider-net-vlan16 10.250.211.64/26 --name dedicated-provider-subnet-vlan16 --allocation-pool start=10.250.211.68,end=10.250.211.126 --gateway=10.250.211.65 --tenant_id Tenant1
Created a new subnet:
+------------------+-----------------------------------------------------+
| Field | Value |
+------------------+-----------------------------------------------------+
| allocation_pools | {"start": "10.250.211.68", "end": "10.250.211.126"} |
| cidr | 10.250.211.64/26 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.250.211.65 |
| host_routes | |
| id | c6b19f5c-0346-443d-bc6f-851d148a49bc |
| ip_version | 4 |
| name | dedicated-provider-subnet-vlan16 |
| network_id | 9bac4b07-530e-4e2c-a247-29f408ec0959 |
| tenant_id | Tenant1 |
+------------------+-----------------------------------------------------+(neutron) net-create dedicated-provider-net-vlan18 --provider:network_type vlan --provider:segmentation_id 18 --tenant-id Tenant2
Created a new network:
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | d33db734-dd53-422c-9a76-8184ded1da5f |
| name | dedicated-provider-net-vlan18 |
| port_security_enabled | True |
| provider:network_type | vlan |
| provider:physical_network | dvs-7909 |
| provider:segmentation_id | 18 |
| shared | False |
| status | ACTIVE |
| subnets | |
| tenant_id | Tenant2 |
+---------------------------+--------------------------------------+(neutron) subnet-create dedicated-provider-net-vlan18 10.250.211.192/26 --name dedicated-provider-subnet-vlan18 --allocation-pool start=10.250.211.196,end=10.250.211.254 --gateway=10.250.211.193 --tenant_id Tenant2
Created a new subnet:
+------------------+------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------+
| allocation_pools | {"start": "10.250.211.196", "end": "10.250.211.254"} |
| cidr | 10.250.211.192/26 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.250.211.193 |
| host_routes | |
| id | 4b4d7802-4c95-45bd-ad44-bbbe1b999b9c |
| ip_version | 4 |
| name | dedicated-provider-subnet-vlan18 |
| network_id | d33db734-dd53-422c-9a76-8184ded1da5f |
| tenant_id | Tenant2 |
+------------------+------------------------------------------------------+
(neutron)Here’s what the network topologies look like now for Tenant1 and Tenant2 after launching a couple instances on the newly created networks:
Shared VXLAN-backed Provider Networks
Shared VXLAN-backed provider networks are visible and usable by all tenants. In order to connect these logical networks to the physical network, an NSX-v distributed logical router (DLR) must be deployed out-of-band from OpenStack to bridge each VXLAN network identifier (VNI) to the appropriate VLAN. VMware is currently working on implementing an L2 gateway Neutron extension that will enable this out-of-band step to be performed from within Neutron.
Here’s an example of Neutron commands to create a shared VXLAN-backed provider network.
(neutron) net-create shared-provider-net-vni5001 --shared
Created a new network:
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| admin_state_up | True |
| id | 646bf44c-64c1-415c-963b-036d4b496be9 |
| name | shared-provider-net-vni5001 |
| port_security_enabled | True |
| shared | True |
| status | ACTIVE |
| subnets | |
| tenant_id | admin |
+-----------------------+--------------------------------------+
(neutron) subnet-create shared-provider-net-vni5001 10.250.211.64/26 --name shared-provider-subnet-vni5001 --allocation-pool start=10.250.211.68,end=10.250.211.126 --gateway=10.250.211.65
Created a new subnet:
+------------------+-----------------------------------------------------+
| Field | Value |
+------------------+-----------------------------------------------------+
| allocation_pools | {"start": "10.250.211.68", "end": "10.250.211.126"} |
| cidr | 10.250.211.64/26 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.250.211.65 |
| host_routes | |
| id | 8f2d2a21-1460-4c8c-82a5-2a2ab567d347 |
| ip_version | 4 |
| name | shared-provider-subnet-vni5001 |
| network_id | 646bf44c-64c1-415c-963b-036d4b496be9 |
| tenant_id | admin |
+------------------+-----------------------------------------------------+
(neutron)Here’s what the network topologies look like now for Tenant1 and Tenant2 after deleting the dedicated, VLAN-backed provider networks and launching a few instances on the newly created shared, VXLAN-backed provider network:
Dedicated VXLAN-backed Provider Networks
Dedicated VXLAN-backed provider networks are only visible and usable by the tenant that owns the network. In order to connect this logical network to the physical network, an NSX-v distributed logical router (DLR) must be deployed out-of-band from OpenStack to bridge the VXLAN network identifier (VNI) to the appropriate VLAN.
Here’s an example of Neutron commands to create dedicated VXLAN-backed provider networks for Tenant1 and Tenant2.
(neutron) net-create dedicated-provider-net-vni5002 --tenant-id Tenant1
Created a new network:
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| admin_state_up | True |
| id | 092106d2-f8ac-4aed-976a-486125f1f568 |
| name | dedicated-provider-net-vni5002 |
| port_security_enabled | True |
| shared | False |
| status | ACTIVE |
| subnets | |
| tenant_id | Tenant1 |
+-----------------------+--------------------------------------+(neutron) subnet-create dedicated-provider-net-vni5002 10.250.211.128/26 --name dedicated-provider-subnet-vni5002 --allocation-pool start=10.250.211.132,end=10.250.211.190 --gateway=10.250.211.129 --tenant-id Tenant1
Created a new subnet:
+------------------+------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------+
| allocation_pools | {"start": "10.250.211.132", "end": "10.250.211.190"} |
| cidr | 10.250.211.128/26 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.250.211.129 |
| host_routes | |
| id | b3ea3483-bd45-4e90-a223-d3f079ee6a80 |
| ip_version | 4 |
| name | dedicated-provider-subnet-vni5002 |
| network_id | 092106d2-f8ac-4aed-976a-486125f1f568 |
| tenant_id | Tenant1 |
+------------------+------------------------------------------------------+(neutron) net-create dedicated-provider-net-vni5003 --tenant-id Tenant2
Created a new network:
+-----------------------+--------------------------------------+
| Field | Value |
+-----------------------+--------------------------------------+
| admin_state_up | True |
| id | 4e2383c4-f672-4060-8410-8406711d1ef6 |
| name | dedicated-provider-net-vni5003 |
| port_security_enabled | True |
| shared | False |
| status | ACTIVE |
| subnets | |
| tenant_id | Tenant2 |
+-----------------------+--------------------------------------+(neutron) subnet-create dedicated-provider-net-vni5003 10.250.211.192/26 --name dedicated-provider-subnet-vni5003 --allocation-pool start=10.250.211.196,end=10.250.211.254 --gateway=10.250.211.193 --tenant-id Tenant2
Created a new subnet:
+------------------+------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------+
| allocation_pools | {"start": "10.250.211.196", "end": "10.250.211.254"} |
| cidr | 10.250.211.192/26 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip | 10.250.211.193 |
| host_routes | |
| id | ebe7a9db-6357-47f9-92db-f27250bc9a7a |
| ip_version | 4 |
| name | dedicated-provider-subnet-vni5003 |
| network_id | 4e2383c4-f672-4060-8410-8406711d1ef6 |
| tenant_id | Tenant2 |
+------------------+------------------------------------------------------+
(neutron)Here’s what the network topologies look like now for Tenant1 and Tenant2:
VXLAN-backed Tenant Networks
Tenant networks are created in exactly the same way as dedicated, VXLAN-backed provider networks (see the immediately preceding section). However, in this case the tenant creates the network rather than the OpenStack administrator.
Tenant networks must use a provider network that is designated as an external network in conjunction with a Neutron router in order to communicate with the physical network.
The general form of the Neutron command to create an external provider network is:
net-create <network name> --provider:network_type portgroup --provider:physical_network <portgroup-moref> --router:external --sharedwhere “portgroup-moref” is the managed object reference of the distributed port group the external network should use.
If the arguments “–provider:network_type” and “–provider:physical_network” are omitted, the external network will use the distributed port group that is specified by the external_network configuration parameter in the nsx.ini NSX-v plugin configuration file.
Note: The specified distributed port group MUST be present on a distributed virtual switch that spans across the Edge cluster because Neutron routers reside in the Edge Cluster.
Here’s an example of Neutron commands to create an external provider network:
(neutron) net-create external-net-vlan17 --provider:network_type portgroup --provider:physical_network dvportgroup-20940 --router:external --shared
Created a new network:
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | True |
| id | c7c002c9-19b3-416a-b1b5-f551b206b64b |
| name | external-net-vlan17 |
| port_security_enabled | True |
| provider:network_type | portgroup |
| provider:physical_network | dvportgroup-20940 |
| provider:segmentation_id | 0 |
| router:external | True |
| shared | True |
| status | ACTIVE |
| subnets | |
| tenant_id | admin |
+---------------------------+--------------------------------------+(neutron) subnet-create external-net-vlan17 10.250.211.128/26 --name external-subnet-vlan17 --allocation-pool start=10.250.211.132,end=10.250.211.190 --gateway=10.250.211.129 --enable_dhcp=False
Created a new subnet:
+------------------+------------------------------------------------------+
| Field | Value |
+------------------+------------------------------------------------------+
| allocation_pools | {"start": "10.250.211.132", "end": "10.250.211.190"} |
| cidr | 10.250.211.128/26 |
| dns_nameservers | |
| enable_dhcp | False |
| gateway_ip | 10.250.211.129 |
| host_routes | |
| id | 6e06129b-594b-4c8f-98e7-1d64026b842f |
| ip_version | 4 |
| name | external-subnet-vlan17 |
| network_id | c7c002c9-19b3-416a-b1b5-f551b206b64b |
| tenant_id | admin |
+------------------+------------------------------------------------------+
(neutron)Here’s what the network topologies look like for Tenant1 and Tenant2 after creating a multi-tier tenant network topology for each:
Conclusion
This article demonstrated how to provision the different types of network topologies that are available when leveraging the NSX-v Neutron plugin for Icehouse. The NSX-v Neutron plugin for Icehouse supports the creation of provider networks that are either VLAN-backed or VXLAN-backed as well as tenant networks that are VXLAN-backed. It’s important to reiterate that the various network topologies are not mutually exclusive. In fact, it’s entirely possible to use all of the network topologies simultaneously within a specific tenant/project. A forthcoming article will discuss in greater depth the tradeoffs associated with provider networks and tenant networks in the context of a private cloud.
This post was contributed by Alain Swanson. Swanson has approximately 20 years of IT infrastructure experience, with much of that time spent in the network engineering and Unix system engineering spaces. He is a member of Wells Fargo’s OpenStack private cloud engineering team, focused on software-defined networking (SDN) and network functions virtualization (NFV). Prior to joining Wells Fargo, he worked in the semiconductor (Micron Technology), e-commerce (Amazon.com) and higher education (Bethel University) industries. Alain holds a Bachelor of Science degree in physics and a Master of Science degree in computer science.
Superuser is always interested in how-tos and other contributions from the OpenStack community, please get in touch! Write to [email protected]
Cover Photo// CC BY NC
- Tenant networks vs. provider networks in the private cloud context - March 4, 2016
- Provisioning Neutron networks with the NSX-v Plugin - December 11, 2015
Alain Swanson
Superuser
Ramon Acedo
Anita Tragler
Franck Baudin
