Chapter 11. VLAN-aware instances
11.1. VLAN trunks and VLAN transparent networks
VM instances can send and receive VLAN-tagged traffic over a single virtual NIC. This is particularly useful for NFV applications (VNFs) that expect VLAN-tagged traffic, allowing a single virtual NIC to serve multiple customers or services.
In ML2/OVN deployments you can support VLAN-aware instances using VLAN transparent networks. As an alternative in ML2/OVN or ML2/OVS deployments, you can support VLAN-aware instances using trunks.
In a VLAN transparent network, you set up VLAN tagging in the VM instances. The VLAN tags are transferred over the network and consumed by the instances on the same VLAN, and ignored by other instances and devices. In a VLAN transparent network, the VLANs are managed in the instance. You do not need to set up the VLAN in the OpenStack Networking Service (neutron).
VLAN trunks support VLAN-aware instances by combining VLANs into a single trunked port. For example, a project data network can use VLANs or tunneling (VXLAN, GRE, or Geneve) segmentation, while the instances see the traffic tagged with VLAN IDs. Network packets are tagged immediately before they are injected to the instance and do not need to be tagged throughout the entire network.
The following table compares certain features of VLAN transparent networks and VLAN trunks.
| Transparent | Trunk | |
|---|---|---|
| Mechanism driver support | ML2/OVN | ML2/OVN, ML2/OVS |
| VLAN setup managed by | VM instance | OpenStack Networking Service (neutron) |
| IP assignment | Configured in VM instance | Assigned by DHCP |
| VLAN ID | Flexible. You can set the VLAN ID in the instance | Fixed. Instances must use the VLAN ID configured in the trunk |
11.2. Enabling VLAN transparency in ML2/OVN deployments
Enable VLAN transparency if you need to send VLAN tagged traffic between virtual machine (VM) instances. In a VLAN transparent network you can configure the VLANS directly in the VMs without configuring them in neutron.
Prerequisites
- Deployment of Red Hat OpenStack Platform 16.1 or higher, with ML2/OVN as the mechanism driver.
- Provider network of type VLAN or Geneve. Do not use VLAN transparency in deployments with flat type provider networks.
- Ensure that the external switch supports 802.1q VLAN stacking using ethertype 0x8100 on both VLANs. OVN VLAN transparency does not support 802.1ad QinQ with outer provider VLAN ethertype set to 0x88A8 or 0x9100.
- You must have RHOSP administrator privileges.
Procedure
- Log in to the undercloud host as the stack user.
Source the stackrc undercloud credentials file:
$ source ~/stackrc
In an environment file on the undercloud node, set the
EnableVLANTransparencyparameter totrue. For example, add the following lines toovn-extras.yaml.parameter_defaults: EnableVLANTransparency: trueInclude the environment file in the
openstack overcloud deploycommand with any other environment files that are relevant to your environment and deploy the overcloud:$ openstack overcloud deploy \ --templates \ … -e <other_overcloud_environment_files> \ -e ovn-extras.yaml \ …
Replace
<other_overcloud_environment_files>with the list of environment files that are part of your existing deployment.Create the network using the
--transparent-vlanargument.Example
$ openstack network create network-name --transparent-vlan
Set up a VLAN interface on each participating VM.
Set the interface MTU to 4 bytes less than the MTU of the underlay network to accommodate the extra tagging required by VLAN transparency. For example, if the underlay network MTU is 1500, set the interface MTU to 1496.
The following example command adds a VLAN interface on
eth0with an MTU of 1496. The VLAN is 50 and the interface name isvlan50:Example
$ ip link add link eth0 name vlan50 type vlan id 50 mtu 1496 $ ip link set vlan50 up $ ip addr add 192.128.111.3/24 dev vlan50
Choose one of these alternatives for the IP address you created on the VLAN interface inside the VM in step 4:
Set an allowed address pair on the VM port.
Example
The following example sets an allowed address pair on port,
fv82gwk3-qq2e-yu93-go31-56w7sf476mm0, by using192.128.111.3and optionally adding a MAC address,00:40:96:a8:45:c4:$ openstack port set --allowed-address \ ip-address=192.128.111.3,mac-address=00:40:96:a8:45:c4 \ fv82gwk3-qq2e-yu93-go31-56w7sf476mm0
Disable port security on the port.
Disabling port security provides a practical alternative when it is not possible to list all of the possible combinations in allowed address pairs.
Example
The following example disables port security on port
fv82gwk3-qq2e-yu93-go31-56w7sf476mm0:$ openstack port set --no-security-group \ --disable-port-security \ fv82gwk3-qq2e-yu93-go31-56w7sf476mm0
Verification
- Ping between two VMs on the VLAN using the vlan50 IP address.
-
Use
tcpdumponeth0to see if the packets arrive with the VLAN tag intact.
Additional resources
- Environment files in the Customizing your Red Hat OpenStack Platform deployment guide
- Including environment files in overcloud creation in the Customizing your Red Hat OpenStack Platform deployment guide
- port set in the Command line interface reference
11.3. Reviewing the trunk plug-in
During a Red Hat openStack deployment, the trunk plug-in is enabled by default. You can review the configuration on the controller nodes:
On the controller node, confirm that the trunk plug-in is enabled in the /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf file:
service_plugins=router,qos,trunk
11.4. Creating a trunk connection
To implement trunks for VLAN-tagged traffic, create a parent port and attach the new port to an existing neutron network. When you attach the new port, OpenStack Networking adds a trunk connection to the parent port you created. Next, create subports. These subports connect VLANs to instances, which allow connectivity to the trunk. Within the instance operating system, you must also create a sub-interface that tags traffic for the VLAN associated with the subport.
Identify the network that contains the instances that require access to the trunked VLANs. In this example, this is the public network:
openstack network list +--------------------------------------+---------+--------------------------------------+ | ID | Name | Subnets | +--------------------------------------+---------+--------------------------------------+ | 82845092-4701-4004-add7-838837837621 | private | 434c7982-cd96-4c41-a8c9-b93adbdcb197 | | 8d8bc6d6-5b28-4e00-b99e-157516ff0050 | public | 3fd811b4-c104-44b5-8ff8-7a86af5e332c | +--------------------------------------+---------+--------------------------------------+
Create the parent trunk port, and attach it to the network that the instance connects to. In this example, create a neutron port named parent-trunk-port on the public network. This trunk is the parent port, as you can use it to create subports.
openstack port create --network public parent-trunk-port +-----------------------+-----------------------------------------------------------------------------+ | Field | Value | +-----------------------+-----------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | | | binding_profile | | | binding_vif_details | | | binding_vif_type | unbound | | binding_vnic_type | normal | | created_at | 2016-10-20T02:02:33Z | | description | | | device_id | | | device_owner | | | extra_dhcp_opts | | | fixed_ips | ip_address='172.24.4.230', subnet_id='dc608964-9af3-4fed-9f06-6d3844fb9b9b' | | headers | | | id | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 | | mac_address | fa:16:3e:33:c4:75 | | name | parent-trunk-port | | network_id | 871a6bd8-4193-45d7-a300-dcb2420e7cc3 | | project_id | 745d33000ac74d30a77539f8920555e7 | | project_id | 745d33000ac74d30a77539f8920555e7 | | revision_number | 4 | | security_groups | 59e2af18-93c6-4201-861b-19a8a8b79b23 | | status | DOWN | | updated_at | 2016-10-20T02:02:33Z | +-----------------------+-----------------------------------------------------------------------------+
Create a trunk using the port that you created in step 2. In this example the trunk is named
parent-trunk.openstack network trunk create --parent-port parent-trunk-port parent-trunk +-----------------+--------------------------------------+ | Field | Value | +-----------------+--------------------------------------+ | admin_state_up | UP | | created_at | 2016-10-20T02:05:17Z | | description | | | id | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 | | name | parent-trunk | | port_id | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 | | revision_number | 1 | | status | DOWN | | sub_ports | | | tenant_id | 745d33000ac74d30a77539f8920555e7 | | updated_at | 2016-10-20T02:05:17Z | +-----------------+--------------------------------------+
View the trunk connection:
openstack network trunk list +--------------------------------------+--------------+--------------------------------------+-------------+ | ID | Name | Parent Port | Description | +--------------------------------------+--------------+--------------------------------------+-------------+ | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 | parent-trunk | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 | | +--------------------------------------+--------------+--------------------------------------+-------------+
View the details of the trunk connection:
openstack network trunk show parent-trunk +-----------------+--------------------------------------+ | Field | Value | +-----------------+--------------------------------------+ | admin_state_up | UP | | created_at | 2016-10-20T02:05:17Z | | description | | | id | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 | | name | parent-trunk | | port_id | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 | | revision_number | 1 | | status | DOWN | | sub_ports | | | tenant_id | 745d33000ac74d30a77539f8920555e7 | | updated_at | 2016-10-20T02:05:17Z | +-----------------+--------------------------------------+
11.5. Adding subports to the trunk
Create a neutron port.
This port is a subport connection to the trunk. You must also specify the MAC address that you assigned to the parent port:
openstack port create --network private --mac-address fa:16:3e:33:c4:75 subport-trunk-port +-----------------------+--------------------------------------------------------------------------+ | Field | Value | +-----------------------+--------------------------------------------------------------------------+ | admin_state_up | UP | | allowed_address_pairs | | | binding_host_id | | | binding_profile | | | binding_vif_details | | | binding_vif_type | unbound | | binding_vnic_type | normal | | created_at | 2016-10-20T02:08:14Z | | description | | | device_id | | | device_owner | | | extra_dhcp_opts | | | fixed_ips | ip_address='10.0.0.11', subnet_id='1a299780-56df-4c0b-a4c0-c5a612cef2e8' | | headers | | | id | 479d742e-dd00-4c24-8dd6-b7297fab3ee9 | | mac_address | fa:16:3e:33:c4:75 | | name | subport-trunk-port | | network_id | 3fe6b758-8613-4b17-901e-9ba30a7c4b51 | | project_id | 745d33000ac74d30a77539f8920555e7 | | project_id | 745d33000ac74d30a77539f8920555e7 | | revision_number | 4 | | security_groups | 59e2af18-93c6-4201-861b-19a8a8b79b23 | | status | DOWN | | updated_at | 2016-10-20T02:08:15Z | +-----------------------+--------------------------------------------------------------------------+
NoteIf you receive the error
HttpException: Conflict, confirm that you are creating the subport on a different network to the one that has the parent trunk port. This example uses the public network for the parent trunk port, and private for the subport.Associate the port with the trunk (
parent-trunk), and specify the VLAN ID (55):openstack network trunk set --subport port=subport-trunk-port,segmentation-type=vlan,segmentation-id=55 parent-trunk
11.6. Configuring an instance to use a trunk
You must configure the VM instance operating system to use the MAC address that the Red Hat OpenStack Platform (RHOSP) Networking service (neutron) assigned to the subport. You can also configure the subport to use a specific MAC address during the subport creation step.
Prerequisites
If you are performing live migrations of your Compute nodes, ensure that the RHOSP Networking service RPC response timeout is appropriately set for your RHOSP deployment. The RPC response timeout value can vary between sites and is dependent on the system speed. The general recommendation is to set the value to at least 120 seconds per/100 trunk ports.
The best practice is to measure the trunk port bind process time for your RHOSP deployment, and then set the RHOSP Networking service RPC response timeout appropriately. Try to keep the RPC response timeout value low, but also provide enough time for the RHOSP Networking service to receive an RPC response. For more information, see Section 11.7, “Configuring Networking service RPC timeout”.
Procedure
Review the configuration of your network trunk, using the
network trunkcommand.Example
$ openstack network trunk list
Sample output
+---------------------+--------------+---------------------+-------------+ | ID | Name | Parent Port | Description | +---------------------+--------------+---------------------+-------------+ | 0e4263e2-5761-4cf6- | parent-trunk | 20b6fdf8-0d43-475a- | | | ab6d-b22884a0fa88 | | a0f1-ec8f757a4a39 | | +---------------------+--------------+---------------------+-------------+
Example
$ openstack network trunk show parent-trunk
Sample output
+-----------------+------------------------------------------------------+ | Field | Value | +-----------------+------------------------------------------------------+ | admin_state_up | UP | | created_at | 2021-10-20T02:05:17Z | | description | | | id | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 | | name | parent-trunk | | port_id | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 | | revision_number | 2 | | status | DOWN | | sub_ports | port_id='479d742e-dd00-4c24-8dd6-b7297fab3ee9', segm | | | entation_id='55', segmentation_type='vlan' | | tenant_id | 745d33000ac74d30a77539f8920555e7 | | updated_at | 2021-08-20T02:10:06Z | +-----------------+------------------------------------------------------+
Create an instance that uses the parent
port-idas its vNIC.Example
openstack server create --image cirros --flavor m1.tiny --security-group default --key-name sshaccess --nic port-id=20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 testInstance
Sample output
+--------------------------------------+---------------------------------+ | Property | Value | +--------------------------------------+---------------------------------+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | | | OS-EXT-SRV-ATTR:host | - | | OS-EXT-SRV-ATTR:hostname | testinstance | | OS-EXT-SRV-ATTR:hypervisor_hostname | - | | OS-EXT-SRV-ATTR:instance_name | | | OS-EXT-SRV-ATTR:kernel_id | | | OS-EXT-SRV-ATTR:launch_index | 0 | | OS-EXT-SRV-ATTR:ramdisk_id | | | OS-EXT-SRV-ATTR:reservation_id | r-juqco0el | | OS-EXT-SRV-ATTR:root_device_name | - | | OS-EXT-SRV-ATTR:user_data | - | | OS-EXT-STS:power_state | 0 | | OS-EXT-STS:task_state | scheduling | | OS-EXT-STS:vm_state | building | | OS-SRV-USG:launched_at | - | | OS-SRV-USG:terminated_at | - | | accessIPv4 | | | accessIPv6 | | | adminPass | uMyL8PnZRBwQ | | config_drive | | | created | 2021-08-20T03:02:51Z | | description | - | | flavor | m1.tiny (1) | | hostId | | | host_status | | | id | 88b7aede-1305-4d91-a180-67e7eac | | | 8b70d | | image | cirros (568372f7-15df-4e61-a05f | | | -10954f79a3c4) | | key_name | sshaccess | | locked | False | | metadata | {} | | name | testInstance | | os-extended-volumes:volumes_attached | [] | | progress | 0 | | security_groups | default | | status | BUILD | | tags | [] | | tenant_id | 745d33000ac74d30a77539f8920555e | | | 7 | | updated | 2021-08-20T03:02:51Z | | user_id | 8c4aea738d774967b4ef388eb41fef5 | | | e | +--------------------------------------+---------------------------------+
Additional resources
11.7. Configuring Networking service RPC timeout
There can be situations when you must modify the Red Hat OpenStack Platform (RHOSP) Networking service (neutron) RPC response timeout. For example, live migrations for Compute nodes that use trunk ports can fail if the timeout value is too low.
The RPC response timeout value can vary between sites and is dependent on the system speed. The general recommendation is to set the value to at least 120 seconds per/100 trunk ports.
If your site uses trunk ports, the best practice is to measure the trunk port bind process time for your RHOSP deployment, and then set the RHOSP Networking service RPC response timeout appropriately. Try to keep the RPC response timeout value low, but also provide enough time for the RHOSP Networking service to receive an RPC response.
By using a manual hieradata override, rpc_response_timeout, you can set the RPC response timeout value for the RHOSP Networking service.
Procedure
On the undercloud host, logged in as the stack user, create a custom YAML environment file.
Example
$ vi /home/stack/templates/my-modules-environment.yaml
TipThe RHOSP Orchestration service (heat) uses a set of plans called templates to install and configure your environment. You can customize aspects of the overcloud with a custom environment file, which is a special type of template that provides customization for your heat templates.
In the YAML environment file under
ExtraConfig, set the appropriate value (in seconds) forrpc_response_timeout. (The default value is 60 seconds.)Example
parameter_defaults: ExtraConfig: neutron::rpc_response_timeout: 120NoteThe RHOSP Orchestration service (heat) updates all RHOSP nodes with the value you set in the custom environment file, however this value only impacts the RHOSP Networking components.
Run the
openstack overcloud deploycommand and include the core heat templates, environment files, and this new custom environment file.ImportantThe order of the environment files is important as the parameters and resources defined in subsequent environment files take precedence.
Example
$ openstack overcloud deploy --templates \ -e [your-environment-files] \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-modules-environment.yaml
Additional resources
- Environment files in the Customizing your Red Hat OpenStack Platform deployment guide
- Including environment files in overcloud creation in the Customizing your Red Hat OpenStack Platform deployment guide
11.8. Understanding trunk states
-
ACTIVE: The trunk is working as expected and there are no current requests. -
DOWN: The virtual and physical resources for the trunk are not in sync. This can be a temporary state during negotiation. -
BUILD: There has been a request and the resources are being provisioned. After successful completion the trunk returns toACTIVE. -
DEGRADED: The provisioning request did not complete, so the trunk has only been partially provisioned. It is recommended to remove the subports and try again. -
ERROR: The provisioning request was unsuccessful. Remove the resource that caused the error to return the trunk to a healthier state. Do not add more subports while in theERRORstate, as this can cause more issues.
