Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 12. VLAN-aware instances
12.1. VLAN trunks and VLAN transparent networks Copier lienLien copié sur presse-papiers!
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.
Instances can send and receive VLAN-tagged traffic over a single vNIC. This is particularly useful for NFV applications (VNFs) that expect VLAN-tagged traffic, allowing a single vNIC to serve multiple customers or services.
For example, the project data network can use VLANs, or tunneling (VXLAN/GRE) segmentation, while the instances see the traffic tagged with VLAN IDs. As a result, network packets are tagged just before they are injected to the instance and do not need to be tagged throughout the entire network.
To implement 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.
12.2. Reviewing the trunk plug-in Copier lienLien copié sur presse-papiers!
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/neutron/etc/neutron/neutron.conf file:
service_plugins=router,qos,trunk
service_plugins=router,qos,trunk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.3. Creating a trunk connection Copier lienLien copié sur presse-papiers!
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 requires the trunk port connection. This would be the network that will contain the instance that requires access to the trunked VLANs. In this example, this is the public network:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create a trunk using the port that you created in step 2. In this example the trunk is named
parent-trunk
.Copy to Clipboard Copied! Toggle word wrap Toggle overflow View the trunk connection:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow View the details of the trunk connection:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4. Adding subports to the trunk Copier lienLien copié sur presse-papiers!
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:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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
openstack network trunk set --subport port=subport-trunk-port,segmentation-type=vlan,segmentation-id=55 parent-trunk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.5. Configuring an instance to use a trunk Copier lienLien copié sur presse-papiers!
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 12.6, “Configuring Networking service RPC timeout”.
Procedure
Review the configuration of your network trunk, using the
network trunk
command.Example
openstack network trunk list
$ openstack network trunk list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Sample output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Example
openstack network trunk show parent-trunk
$ openstack network trunk show parent-trunk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Sample output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create an instance that uses the parent
port-id
as 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
openstack server create --image cirros --flavor m1.tiny --security-group default --key-name sshaccess --nic port-id=20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 testInstance
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Sample output
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.6. Configuring Networking service RPC timeout Copier lienLien copié sur presse-papiers!
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
$ vi /home/stack/templates/my-modules-environment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 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: 120
parameter_defaults: ExtraConfig: neutron::rpc_response_timeout: 120
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NoteThe 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 deploy
command 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
$ openstack overcloud deploy --templates \ -e [your-environment-files] \ -e /usr/share/openstack-tripleo-heat-templates/environments/services/my-modules-environment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.7. Understanding trunk states Copier lienLien copié sur presse-papiers!
-
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 theERROR
state, as this can cause more issues.