Networking Guide

Procedure

1. On the undercloud host, logged in as the stack user, create a custom YAML environment file.

   Example

   $ vi /home/stack/templates/my-ovs-environment.yaml

   Tip

   The 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.

2. In the YAML environment file under parameter_defaults, add the following Puppet variables:

   parameter_defaults:
       ExtraConfig:
           neutron::agents::ml2::ovs::of_interface: ovs-ofctl
           neutron::agents::ml2::ovs::ovsdb_interface: vsctl
           ...

   Important

   Ensure that you add a whitespace character between the single colon (:) and the value.

3. Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file.

   Important

   The 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-ovs-environment.yaml

1. In the dashboard, select Project > Network > Networks.

2. Click +Create Network and specify the following values:

   Field	Description
   Network Name	Descriptive name, based on the role that the network will perform. If you are integrating the network with an external VLAN, consider appending the VLAN ID number to the name. For example, webservers_122, if you are hosting HTTP web servers in this subnet, and your VLAN tag is 122. Or you might use internal-only if you intend to keep the network traffic private, and not integrate the network with an external network.
   Admin State	Controls whether the network is immediately available. Use this field to create the network in a Down state, where it is logically present but inactive. This is useful if you do not intend to enter the network into production immediately.

3. Click the Next button, and specify the following values in the Subnet tab:

   Field	Description
   Create Subnet	Determines whether to create a subnet. For example, you might not want to create a subnet if you intend to keep this network as a placeholder without network connectivity.
   Subnet Name	Enter a descriptive name for the subnet.
   Network Address	Enter the address in CIDR format, which contains the IP address range and subnet mask in one value. To determine the address, calculate the number of bits masked in the subnet mask and append that value to the IP address range. For example, the subnet mask 255.255.255.0 has 24 masked bits. To use this mask with the IPv4 address range 192.168.122.0, specify the address 192.168.122.0/24.
   IP Version	Specifies the internet protocol version, where valid types are IPv4 or IPv6. The IP address range in the Network Address field must match whichever version you select.
   Gateway IP	IP address of the router interface for your default gateway. This address is the next hop for routing any traffic destined for an external location, and must be within the range that you specify in the Network Address field. For example, if your CIDR network address is 192.168.122.0/24, then your default gateway is likely to be 192.168.122.1.
   Disable Gateway	Disables forwarding and isolates the subnet.

4. Click Next to specify DHCP options:

   • Enable DHCP - Enables DHCP services for this subnet. You can use DHCP to automate the distribution of IP settings to your instances.

   • IPv6 Address - Configuration Modes. If you create an IPv6 network, you must specify how to allocate IPv6 addresses and additional information:

     • No Options Specified - Select this option if you want to set IP addresses manually, or if you use a non OpenStack-aware method for address allocation.
     • SLAAC (Stateless Address Autoconfiguration) - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. Use this configuration to create an OpenStack Networking subnet with ra_mode set to slaac and address_mode set to slaac.
     • DHCPv6 stateful - Instances receive IPv6 addresses as well as additional options (for example, DNS) from the OpenStack Networking DHCPv6 service. Use this configuration to create a subnet with ra_mode set to dhcpv6-stateful and address_mode set to dhcpv6-stateful.
     • DHCPv6 stateless - Instances generate IPv6 addresses based on Router Advertisement (RA) messages sent from the OpenStack Networking router. Additional options (for example, DNS) are allocated from the OpenStack Networking DHCPv6 service. Use this configuration to create a subnet with ra_mode set to dhcpv6-stateless and address_mode set to dhcpv6-stateless.
   • Allocation Pools - Range of IP addresses that you want DHCP to assign. For example, the value 192.168.22.100,192.168.22.100 considers all up addresses in that range as available for allocation.

   • DNS Name Servers - IP addresses of the DNS servers available on the network. DHCP distributes these addresses to the instances for name resolution.

     Important

     For strategic services such as DNS, it is a best practice not to host them on your cloud. For example, if your cloud hosts DNS and your cloud becomes inoperable, DNS is unavailable and the cloud components cannot do lookups on each other.

   • Host Routes - Static host routes. First, specify the destination network in CIDR format, followed by the next hop that you want to use for routing (for example, 192.168.23.0/24, 10.1.31.1). Provide this value if you need to distribute static routes to instances.

5. Click Create.

   You can view the complete network in the Networks tab. You can also click Edit to change any options as needed. When you create instances, you can configure them now to use its subnet, and they receive any specified DHCP options.

1. In the dashboard, select Project > Network > Routers.

2. Select your virtual router name in the Routers list, and click Add Interface.

   In the Subnet list, select the name of your new subnet. You can optionally specify an IP address for the interface in this field.

3. Click Add Interface.

   Instances on your network can now communicate with systems outside the subnet.

1. In the dashboard, select Project > Network > Networks.

   Remove all router interfaces associated with the target network subnets.

   To remove an interface, find the ID number of the network that you want to delete by clicking on your target network in the Networks list, and looking at the ID field. All the subnets associated with the network share this value in the Network ID field.

2. Navigate to Project > Network > Routers, click the name of your virtual router in the Routers list, and locate the interface attached to the subnet that you want to delete.

   You can distinguish this subnet from the other subnets by the IP address that served as the gateway IP. You can further validate the distinction by ensuring that the network ID of the interface matches the ID that you noted in the previous step.

3. Click the Delete Interface button for the interface that you want to delete.
4. Select Project > Network > Networks, and click the name of your network.

5. Click the Delete Subnet button for the subnet that you want to delete.

   Note

   If you are still unable to remove the subnet at this point, ensure it is not already being used by any instances.

6. Select Project > Network > Networks, and select the network you would like to delete.
7. Click Delete Networks.

1. In the dashboard, select Project > Network > Networks.
2. Click the name of your network.
3. Select the target subnet, and click Delete Subnets.

1. In the dashboard, select Project > Network > Routers, and click Create Router.
2. Enter a descriptive name for the new router, and click Create router.
3. Click Set Gateway next to the entry for the new router in the Routers list.
4. In the External Network list, specify the network that you want to receive traffic destined for an external location.

5. Click Set Gateway.

   After you add a router, you must configure any subnets you have created to send traffic using this router. You do this by creating interfaces between the subnet and the router.

1. In the dashboard, select Project > Network > Routers, and click the name of the router that you want to delete.
2. Select the interfaces of type Internal Interface, and click Delete Interfaces.
3. From the Routers list, select the target router and click Delete Routers.

Procedure

1. Log in as the stack user on the overcloud Networking controller host and open l3_agent.conf in a text editor.

   Example

   vi /var/lib/config-data/neutron/etc/neutron/l3_agent.conf

2. Locate the ha_vrrp_advert_int option, and increase the VRRP advert interval. (The default is 2 seconds.)

   Example

   [DEFAULT]
   ha_vrrp_advert_int = 7
   ha_vrrp_garp_master_repeat = 5
   ha_vrrp_garp_master_delay = 5

   There are also options for gratuitous ARP messages that you can set:

   ha_vrrp_garp_master_repeat

   The number of gratuitous ARP messages to send at one time after the transition to the master state. (The default is 5 messages.)

   ha_vrrp_garp_master_delay

   The delay for second set of gratuitous ARP messages after the lower priority advert is received in the master state. (The default is 5 seconds.)

   Tip

   The next time that the openstack overcloud deploy command is run, any manual changes like this one to l3_agent.conf are overwritten. You can write a post-deployment script that re-applies your changes after future overcloud updates. If you incorporate the puppet hieradata role name described in the following document in your script, the script will run only on the overcloud node roles that must have your l3_agent.conf changes re-applied. For more information, see Post-Configuration: Customizing All Overcloud Roles in the Advanced Overcloud Customization guide.

1. In the dashboard, select Project > Network > Network Topology.
2. Locate the router that you want to manage, hover your mouse over it, and click Add Interface.

3. Specify the Subnet that you want to connect to the router.

   You can also specify an IP address. The address is useful for testing and troubleshooting purposes, since a successful ping to this interface indicates that the traffic is routing as expected.

4. Click Add interface.

   The Network Topology diagram automatically updates to reflect the new interface connection between the router and subnet.

1. In the dashboard, select Project > Network > Routers.
2. Click the name of the router that hosts the interface that you want to delete.
3. Select the interface type (Internal Interface), and click Delete Interfaces.

Procedure

1. In the dashboard, select Admin > Networks > Create Network > Project.
2. Select the project that you want to host the new network with the Project drop-down list.

3. Review the options in Provider Network Type:

   • Local - Traffic remains on the local Compute host and is effectively isolated from any external networks.
   • Flat - Traffic remains on a single network and can also be shared with the host. No VLAN tagging or other network segregation takes place.
   • VLAN - Create a network using a VLAN ID that corresponds to a VLAN present in the physical network. This option allows instances to communicate with systems on the same layer 2 VLAN.
   • GRE - Use a network overlay that spans multiple nodes for private communication between instances. Traffic egressing the overlay must be routed.
   • VXLAN - Similar to GRE, and uses a network overlay to span multiple nodes for private communication between instances. Traffic egressing the overlay must be routed.

4. Click Create Network.

   Review the Project Network Topology to validate that the network has been successfully created.

Procedure

1. Enter the following command to allocate a floating IP address from the pool. In this example, the network is named public.

   Example

   $ openstack floating ip create public

   Sample output

   In the following example, the newly allocated floating IP is 192.0.2.200. You can assign it to an instance.

   +---------------------+--------------------------------------------------+
   | Field               | Value                                            |
   +---------------------+--------------------------------------------------+
   | fixed_ip_address    | None                                             |
   | floating_ip_address | 192.0.2.200                                      |
   | floating_network_id | f0dcc603-f693-4258-a940-0a31fd4b80d9             |
   | id                  | 6352284c-c5df-4792-b168-e6f6348e2620             |
   | port_id             | None                                             |
   | router_id           | None                                             |
   | status              | ACTIVE                                           |
   +---------------------+--------------------------------------------------+

2. Enter the following command to locate your instance:

   $ openstack server list

   Sample output

   +-------------+-------------+--------+-------------+-------+-------------+
   | ID          | Name        | Status | Networks    | Image | Flavor      |
   +-------------+-------------+--------+-------------+-------+-------------+
   | aef3ca09-88 | prod-serv1  | ACTIVE | public=198. | rhel8 | review-     |
   | 7d-4d20-872 |             |        | 51.100.56   |       | ephemeral   |
   | d-1d1b49081 |             |        |             |       |             |
   | 958         |             |        |             |       |             |
   |             |             |        |             |       |             |
   +-------------+-------------+--------+-------------+-------+-------------+

3. Associate the instance name or ID with the floating IP.

   Example

   $ openstack server add floating ip prod-serv1 192.0.2.200

Procedure

1. Open /etc/sysconfig/network-scripts/ifcfg-eth0 in a text editor, and update the following parameters with values appropriate for the network at your site:

   • IPADDR
   • NETMASK GATEWAY

   • DNS1 (name server)

     Here is an example:

     # vi /etc/sysconfig/network-scripts/ifcfg-eth0
     DEVICE=eth0
     TYPE=OVSPort
     DEVICETYPE=ovs
     OVS_BRIDGE=br-ex
     ONBOOT=yes

2. Open /etc/sysconfig/network-scripts/ifcfg-br-ex in a text editor and update the virtual bridge parameters with the IP address values that were previously allocated to eth0:

   # vi /etc/sysconfig/network-scripts/ifcfg-br-ex
   DEVICE=br-ex
   DEVICETYPE=ovs
   TYPE=OVSBridge
   BOOTPROTO=static
   IPADDR=192.168.120.10
   NETMASK=255.255.255.0
   GATEWAY=192.168.120.1
   DNS1=192.168.120.1
   ONBOOT=yes

   You can now assign floating IP addresses to instances and make them available to the physical network.

Procedure

1. Log in to the undercloud as the stack user, and source the stackrc file to enable the director command line tools.

   Example

   $ source ~/stackrc

2. Create a custom YAML environment file (my-neutron-environment.yaml).

   Note

   Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with ones that are appropriate for your site.

   Example

   $ vi /home/stack/templates/my-neutron-environment.yaml

   Tip

   The undercloud includes a set of Orchestration service templates that form the plan for your overcloud creation. You can customize aspects of the overcloud with environment files, which are YAML-formatted files that override parameters and resources in the core Orchestration service template collection. You can include as many environment files as necessary.

3. In the environment file, add a parameter_defaults section. Under this section, add the dns_domain for ports extension, dns_domain_ports.

   Example

   parameter_defaults:
     NeutronPluginExtensions: "qos,port_security,dns_domain_ports"

   Note

   If you set dns_domain_ports, ensure that the deployment does not also use dns_domain, the DNS Integration extension. These extensions are incompatible, and both extensions cannot be defined simultaneously.

4. Also in the parameter_defaults section, add your domain name (example.com) using the NeutronDnsDomain parameter.

   Example

   parameter_defaults:
       NeutronPluginExtensions: "qos,port_security,dns_domain_ports"
       NeutronDnsDomain: "example.com"

5. Run the openstack overcloud deploy command and include the core Orchestration templates, environment files, and this new environment file.

   Important

   The order of the environment files is important because 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-neutron-environment.yaml

Verification steps

1. Log in to the overcloud, and create a new port (new_port) on a network (public). Assign a DNS name (my_port) to the port.

   Example

   $ source ~/overcloudrc
   $ openstack port create --network public --dns-name my_port new_port

2. Display the details for your port (new_port).

   Example

   $ openstack port show -c dns_assignment -c dns_domain -c dns_name -c name new_port

   Output

   +-------------------------+----------------------------------------------+
   | Field                   | Value                                        |
   +-------------------------+----------------------------------------------+
   | dns_assignment          | fqdn='my_port.example.com',                  |
   |                         | hostname='my_port',                          |
   |                         | ip_address='10.65.176.113'                   |
   | dns_domain              | example.com                                  |
   | dns_name                | my_port                                      |
   | name                    | new_port                                     |
   +-------------------------+----------------------------------------------+

   Under dns_assignment, the fully qualified domain name (fqdn) value for the port contains a concatenation of the DNS name (my_port) and the domain name (example.com) that you set earlier with NeutronDnsDomain.

3. Create a new VM instance (my_vm) using the port (new_port) that you just created.

   Example

   $ openstack server create --image rhel --flavor m1.small --port new_port my_vm

4. Display the details for your port (new_port).

   Example

   $ openstack port show -c dns_assignment -c dns_domain -c dns_name -c name new_port

   Output

   +-------------------------+----------------------------------------------+
   | Field                   | Value                                        |
   +-------------------------+----------------------------------------------+
   | dns_assignment          | fqdn='my_vm.example.com',                    |
   |                         | hostname='my_vm',                            |
   |                         | ip_address='10.65.176.113'                   |
   | dns_domain              | example.com                                  |
   | dns_name                | my_vm                                        |
   | name                    | new_port                                     |
   +-------------------------+----------------------------------------------+

   Note that the Compute service changes the dns_name attribute from its original value (my_port) to the name of the instance with which the port is associated (my_vm).

Procedure

1. Log in to the undercloud host as the stack user.

2. Source the undercloud credentials file:

   $ source ~/stackrc

3. Create a custom YAML environment file.

   Example

   $ vi /home/stack/templates/my-octavia-environment.yaml

4. Your environment file must contain the keywords parameter_defaults. Under these keywords, add the extra DHCP option extension, extra_dhcp_opt.

   Example

   parameter_defaults:
     NeutronPluginExtensions: "qos,port_security,extra_dhcp_opt"

5. Run the deployment command and include the core heat templates, environment files, and this new custom environment file.

   The order of the environment files is important because 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/octavia.yaml \
   -e /home/stack/templates/my-octavia-environment.yaml

Verification

1. Source your credentials file.

   Example

   $ source ~/overcloudrc

2. Create a new port (new_port) on a network (public). Assign a valid attribute from the DHCP specification to the new port.

   Example

   $ openstack port create --extra-dhcp-option name=domain-name,value=test.domain --extra-dhcp-option name=ntp-server,value=192.0.2.123 --network public new_port

3. Display the details for your port (new_port).

   Example

   $ openstack port show new_port -c extra_dhcp_opts

   Sample output

   +-----------------+--------------------------------------------------------------------+
   | Field           | Value                                                              |
   +-----------------+--------------------------------------------------------------------+
   | extra_dhcp_opts | ip_version='4', opt_name='domain-name', opt_value='test.domain'    |
   |                 | ip_version='4', opt_name='ntp-server', opt_value='192.0.2.123'     |
   +-----------------+--------------------------------------------------------------------+

Procedure

1. 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

   Tip

   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.

2. In the YAML environment file under parameter_defaults, set ExtraKernelModules to the name of the module that you want to load.

   Example

   ComputeParameters:
     ExtraKernelModules:
       nf_conntrack_proto_gre: {}
   ControllerParameters:
     ExtraKernelModules:
       nf_conntrack_proto_gre: {}

3. Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file.

   Important

   The 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

1. To view all the ports that attach to the router named r1, run the following command:

   #  openstack port list --router r1

   Example result:

   +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
   | id                                   | name | mac_address       | fixed_ips                                                                            |
   +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
   | b58d26f0-cc03-43c1-ab23-ccdb1018252a |      | fa:16:3e:94:a7:df | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
   | c45e998d-98a1-4b23-bb41-5d24797a12a4 |      | fa:16:3e:ee:6a:f7 | {"subnet_id": "43f8f625-c773-4f18-a691-fd4ebfb3be54", "ip_address": "172.24.4.225"}  |
   +--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+

2. To view the details of each port, run the following command. Include the port ID of the port that you want to view. The result includes the port status, indicated in the following example as having an ACTIVE state:

   # openstack port show b58d26f0-cc03-43c1-ab23-ccdb1018252a

   Example result:

   +-----------------------+--------------------------------------------------------------------------------------+
   | Field                 | Value                                                                                |
   +-----------------------+--------------------------------------------------------------------------------------+
   | admin_state_up        | True                                                                                 |
   | allowed_address_pairs |                                                                                      |
   | binding:host_id       | node.example.com                                                      |
   | binding:profile       | {}                                                                                   |
   | binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}                                       |
   | binding:vif_type      | ovs                                                                                  |
   | binding:vnic_type     | normal                                                                               |
   | device_id             | 49c6ebdc-0e62-49ad-a9ca-58cea464472f                                                 |
   | device_owner          | network:router_interface                                                             |
   | extra_dhcp_opts       |                                                                                      |
   | fixed_ips             | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
   | id                    | b58d26f0-cc03-43c1-ab23-ccdb1018252a                                                 |
   | mac_address           | fa:16:3e:94:a7:df                                                                    |
   | name                  |                                                                                      |
   | network_id            | 63c24160-47ac-4140-903d-8f9a670b0ca4                                                 |
   | security_groups       |                                                                                      |
   | status                | ACTIVE                                                                               |
   | tenant_id             | d588d1112e0f496fb6cac22f9be45d49                                                     |
   +-----------------------+--------------------------------------------------------------------------------------+

3. Perform step 2 for each port to retrieve its status.

1. Ping the gateway with ping <gateway-IP-address>.

   Consider this example, in which a network is created with these commands:

   # openstack network create --provider-network-type vlan --provider-physical-network phy-eno1 --provider-segment 120 provider
   # openstack subnet create --no-dhcp --allocation-pool start=192.168.120.1,end=192.168.120.153 --gateway 192.168.120.254 --network  provider public_subnet

   In this example, the gateway IP address is 192.168.120.254.

   $ ping 192.168.120.254

2. If the ping fails, do the following:

   1. Confirm that you have network flow for the associated VLAN.

      It is possible that the VLAN ID has not been set. In this example, OpenStack Networking is configured to trunk VLAN 120 to the provider network. (See --provider:segmentation_id=120 in the example in step 1.)

   2. Confirm the VLAN flow on the bridge interface using the command, ovs-ofctl dump-flows <bridge-name>.

      In this example the bridge is named br-ex:

      # ovs-ofctl dump-flows br-ex
      
       NXST_FLOW reply (xid=0x4):
        cookie=0x0, duration=987.521s, table=0, n_packets=67897, n_bytes=14065247, idle_age=0, priority=1 actions=NORMAL
        cookie=0x0, duration=986.979s, table=0, n_packets=8, n_bytes=648, idle_age=977, priority=2,in_port=12 actions=drop

1. List all the project networks using the openstack network list command:

   # (overcloud)[stack@osp13-undercloud ~]$ openstack network list
   +--------------------------------------+-------------+-------------------------------------------------------+
   | id                                   | name        | subnets                                               |
   +--------------------------------------+-------------+-------------------------------------------------------+
   | 9cb32fe0-d7fb-432c-b116-f483c6497b08 | web-servers | 453d6769-fcde-4796-a205-66ee01680bba 192.168.212.0/24 |
   | a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 | private     | c1e58160-707f-44a7-bf94-8694f29e74d3 10.0.0.0/24      |
   | baadd774-87e9-4e97-a055-326bb422b29b | private     | 340c58e1-7fe7-4cf2-96a7-96a0a4ff3231 192.168.200.0/24 |
   | 24ba3a36-5645-4f46-be47-f6af2a7d8af2 | public      | 35f3d2cb-6e4b-4527-a932-952a395c4bb3 172.24.4.224/28  |
   +--------------------------------------+-------------+-------------------------------------------------------+

   In this example,examine the web-servers network. Make a note of the id value in the web-server row (9cb32fe0-d7fb-432c-b116-f483c6497b08). This value is appended to the network namespace, which helps you identify the namespace in the next step.

2. List all the network namespaces using the ip netns list command:

   # ip netns list
   qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08
   qrouter-31680a1c-9b3e-4906-bd69-cb39ed5faa01
   qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b
   qdhcp-a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81
   qrouter-e9281608-52a6-4576-86a6-92955df46f56

   The output contains a namespace that matches the web-servers network id. In this example the namespace is qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08.

3. Examine the configuration of the web-servers network by running commands within the namespace, prefixing the troubleshooting commands with ip netns exec <namespace>:

   # ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n
   
   Kernel IP routing table
   Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
   0.0.0.0         172.24.4.225    0.0.0.0         UG    0      0        0 qg-8d128f89-87
   172.24.4.224    0.0.0.0         255.255.255.240 U     0      0        0 qg-8d128f89-87
   192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 qr-8efd6357-96

Procedure

1. 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

   Tip

   The Red Hat OpenStack Platform 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 orchestration templates.

2. In the YAML environment file under parameter_defaults, use the NeutronBridgeMappings to specify which OVS bridges are used for accessing external networks.

   Example

   parameter_defaults:
     NeutronBridgeMappings: 'physnet1:br-net1,physnet2:br-net2'

3. In the custom NIC configuration template for the Controller and Compute nodes, configure the bridges with interfaces attached.

   Example

   ...
                 - type: ovs_bridge
                   name: br-net1
                   mtu: 1500
                   use_dhcp: false
                   members:
                   - type: interface
                     name: eth0
                     mtu: 1500
                     use_dhcp: false
                     primary: true
                 - type: ovs_bridge
                   name: br-net2
                   mtu: 1500
                   use_dhcp: false
                   members:
                   - type: interface
                     name: eth1
                     mtu: 1500
                     use_dhcp: false
                     primary: true
   ...

4. Run the openstack overcloud deploy command and include the templates and the environment files, including this modified custom NIC template and the new environment file.

   Important

   The order of the environment files is important because 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-neutron-environment.yaml

Verification steps

1. Create an external network (public1) as a flat network and associate it with the configured physical network (physnet1).

   Configure it as a shared network (using --share) to let other users create VM instances that connect to the external network directly.

   Example

   # openstack network create --share --provider-network-type flat --provider-physical-network physnet1 --external public01

2. Create a subnet (public_subnet) using the openstack subnet create command.

   Example

   # openstack subnet create --no-dhcp --allocation-pool start=192.168.100.20,end=192.168.100.100 --gateway 192.168.100.1 --network public01 public_subnet

3. Create a VM instance and connect it directly to the newly-created external network.

   Example

   $ openstack server create --image rhel --flavor my_flavor --network public01 my_instance

1. Packets leave the eth0 interface of the instance and arrive at the linux bridge qbr-xx.
2. Bridge qbr-xx is connected to br-int using veth pair qvb-xx <-> qvo-xxx. This is because the bridge is used to apply the inbound/outbound firewall rules defined by the security group.
3. Interface qvb-xx is connected to the qbr-xx linux bridge, and qvoxx is connected to the br-int Open vSwitch (OVS) bridge.

1. Incoming traffic arrives at eth1 on the physical node.
2. The packet passes to the br-ex bridge.
3. The packet moves to br-int via the patch-peer phy-br-ex <--> int-br-ex.

Observing the traffic flow on br-int

1. When the packet arrives at int-br-ex, an OVS flow rule within the br-int bridge amends the packet to add the internal VLAN tag 5. See the entry for actions=mod_vlan_vid:5:

1. The second rule manages packets that arrive on int-br-ex (in_port=15) with no VLAN tag (vlan_tci=0x0000): This rule adds VLAN tag 5 to the packet (actions=mod_vlan_vid:5,NORMAL) and forwards it to qvoxxx.
2. qvoxxx accepts the packet and forwards it to qvbxx, after stripping away the VLAN tag.
3. The packet then reaches the instance.

Procedure

1. 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

   Tip

   The Red Hat OpenStack Platform 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 orchestration templates.

2. In the YAML environment file under parameter_defaults, use NeutronTypeDrivers to specify your network type drivers.

   Example

   parameter_defaults:
     NeutronTypeDrivers: vxlan,flat,vlan

3. Configure the NeutronNetworkVLANRanges setting to reflect the physical network and VLAN ranges in use:

   Example

   parameter_defaults:
     NeutronTypeDrivers: 'vxlan,flat,vlan'
     NeutronNetworkVLANRanges: 'physnet1:171,172'

4. Create an external network bridge (br-ex), and associate a port (eth1) with it.

   This example configures eth1 to use br-ex:

   Example

   parameter_defaults:
     NeutronTypeDrivers: 'vxlan,flat,vlan'
     NeutronNetworkVLANRanges: 'physnet1:171,172'
     NeutronBridgeMappings: 'datacentre:br-ex,tenant:br-int'

5. Run the openstack overcloud deploy command and include the core templates and the environment files, including this new environment file.

   Important

   The order of the environment files is important because 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-neutron-environment.yaml

Verification steps

1. Create the external networks as type vlan, and associate them with the configured physical_network.

   When you create the external networks, use the --shared option so that users in other project can share the external networks and can connect VM instances directly.

   Run the following example command to create two networks: one for VLAN 171, and another for VLAN 172:

   Example

   $ openstack network create \
   			--provider-network-type vlan \
   			--external \
   			--provider-physical-network physnet1 \
   			--provider-segment 171 \
   			--share \
   			provider-vlan171
   
   $ openstack network create \
   			--provider-network-type vlan \
   			--external \
   			--provider-physical-network physnet1 \
   			--provider-segment 172 \
   			--share \
   			provider-vlan172

2. Create a number of subnets and configure them to use the external network.

   You can use either openstack subnet create or the dashboard to create these subnets. Ensure that the external subnet details you have received from your network administrator are correctly associated with each VLAN.

   In this example, VLAN 171 uses subnet 10.65.217.0/24 and VLAN 172 uses 10.65.218.0/24:

   Example

   $ openstack subnet create \
   			--network provider-171 \
   			--subnet-range 10.65.217.0/24 \
   			--dhcp \
   			--gateway 10.65.217.254 \
   			subnet-provider-171
   
   $ openstack subnet create \
   			--network provider-172 \
   			--subnet-range 10.65.218.0/24 \
   			--dhcp \
   			--gateway 10.65.218.254 \
   			subnet-provider-172

1. Packets leaving the eth0 interface of the instance arrive at the linux bridge qbr-xx connected to the instance.
2. qbr-xx is connected to br-int using veth pair qvbxx <→ qvoxxx.
3. qvbxx is connected to the linux bridge qbr-xx and qvoxx is connected to the Open vSwitch bridge br-int.

Procedure

1. On the undercloud host, logged in as the stack user, create a custom YAML environment file.

   Example

   $ vi /home/stack/templates/my-ovs-environment.yaml

   Tip

   The 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.

2. In the YAML environment file under the ExtraConfig section for the appropriate role, set the Puppet variable, igmp_snooping_enable, to true.

   Example

   If the role used is ComputeOvsDpdk, then the lines that you add to the custom envirnoment file would be:

   parameter_defaults:
     ComputeOvsDpdkExtraConfig:
       neutron::agents::ml2::ovs::igmp_snooping_enable: true

   Important

   Ensure that you add a whitespace character between the single colon (:) and the value.

3. Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file.

   Important

   The 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-ovs-environment.yaml

Procedure

1. Configure security to allow multicast traffic to the appropriate VM instances. For instance, create a pair of security group rules to allow IGMP traffic from the IGMP querier to enter and exit the VM instances, and a third rule to allow multicast traffic.

   Example

   A security group mySG allows IGMP traffic to enter and exit the VM instances.

    openstack security group rule create --protocol igmp --ingress mySG
   
    openstack security group rule create --protocol igmp --egress mySG

   Another rule allows multicast traffic to reach VM instances.

   openstack security group rule create  --protocol udp mySG

   As an alternative to setting security group rules, some operators choose to selectively disable port security on the network. If you choose to disable port security, consider and plan for any related security risks.

2. Set the heat parameter NeutronEnableIgmpSnooping: True in an environment file on the undercloud node. For instance, add the following lines to ovn-extras.yaml.

   Example

   parameter_defaults:
           NeutronEnableIgmpSnooping: True

3. Include the environment file in the openstack overcloud deploy command 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.

Verification steps

1. Verify that the multicast snooping is enabled. List the northbound database Logical_Switch table.

   $ ovn-nbctl list Logical_Switch

   Sample output

   _uuid         : d6a2fbcd-aaa4-4b9e-8274-184238d66a15
   other_config  : {mcast_flood_unregistered="false", mcast_snoop="true"}
   ...

   The Networking Service (neutron) igmp_snooping_enable configuration is translated into the mcast_snoop option set in the other_config column of the Logical_Switch table in the OVN Northbound Database. Note that mcast_flood_unregistered is always “false”.

2. Show the IGMP groups.

   $ ovn-sbctl list IGMP_group

   Sample output

   _uuid    : 2d6cae4c-bd82-4b31-9c63-2d17cbeadc4e
   address  : "225.0.0.120"
   chassis  : 34e25681-f73f-43ac-a3a4-7da2a710ecd3
   datapath : eaf0f5cc-a2c8-4c30-8def-2bc1ec9dcabc
   ports    : [5eaf9dd5-eae5-4749-ac60-4c1451901c56, 8a69efc5-38c5-48fb-bbab-30f2bf9b8d45]
   ...

1. If the qos extension is not already enabled for OpenStack Networking in /etc/neutron/plugins/ml2/<agent_name>_agent.ini, then follow these steps:

   1. Create a custom Heat environment file, and add the following lines:

      parameter_defaults:
        NeutronSriovAgentExtensions: 'qos'

      Important

      YAML files are extremely sensitive about where in the file a parameter is placed. Make sure that parameter_defaults: starts in the first column (no leading whitespace characters), and your parameter value pair starts in column three (the parameter has two whitespace characters in front of it).

   2. Run the Red Hat OpenStack Platform director command, openstack overcloud deploy and include all your current environment files and this custom new one.

      For more information, see "Modifying the overcloud environment" in the Director Installation and Usage guide.

2. Review the list of tenants and determine the id of where you need to create QoS policy:

   # openstack project list
   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
   | 519e6344f82e4c079c8e2eabb690023b | services |
   | 80bf5732752a41128e612fe615c886c6 | demo     |
   | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
   +----------------------------------+----------+

3. Create a QoS policy named bw-limiter in the admin tenant:

   # openstack network qos policy create --project 98a2f53c20ce4d50a40dac4a38016c69 bw-limiter

4. Configure the policing rules for the bw-limiter policy:

   # openstack network qos rule create --type bandwidth-limit --max-kbps 3000 --max-burst-kbits 30000 bw-limiter

5. Configure a neutron port to apply the bw-limiter policy:

   # openstack port set --qos-policy bw-limiter port_name_or_id

6. Review the QoS rule. For example:

   # openstack network qos policy show 9be535c3-daa2-4d7b-88ea-e8de16
   
   +-------------------+---------------------------------+
   | Field             | Value                           |
   +-------------------+---------------------------------+
   | id                | 9be535c3-daa2-4d7b-88ea-e8de16  |
   | rule_type         | bandwidth_limit                 |
   | description       |                                 |
   | max_kbps          | 3000                            |
   | max_burst_kbps    | 300                             |
   +-------------------+---------------------------------+

Procedure

1. If you are:

   • using ML2/OVN, skip to step 2.
   • using ML2/OVS without a tunneling protocol, skip to step 2.

   • using ML2/OVS with a tunneling protocol (VXLAN and GRE), then perform the following steps:

     1. Log in to the undercloud host as the stack user.

        $ source ~/stackrc

     2. Create a custom YAML environment file.

        Example

        $ vi /home/stack/templates/my-neutron-environment.yaml

     3. In the YAML environment file under parameter_defaults, add the following lines:

        parameter_defaults:
            ControllerExtraConfig:
                neutron::config::server_config:
                  agent/dscp_inherit:
                    value: true

        When dscp_inherit is true, the Networking service copies the DSCP value of the inner header to the outer header.

     4. Run the deployment command and include the core heat templates, environment files, and this new custom environment file.

        Important

        The 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/ \
        neutron-ovs.yaml \
        -e /home/stack/templates/my-neutron-environment.yaml

2. Source your credentials file.

   Example

   $ source ~/overcloudrc

3. Create a new QoS policy:

   Example

   openstack network qos policy create --project 98a2f53c20ce4d50a40dac4a38016c69 qos-web-servers

4. Create a DSCP rule and apply it to a policy.

   Example

   In this example, a DSCP rule is created using DSCP mark 18 and is applied to the qos-web-servers policy:

   openstack network qos rule create --type dscp-marking --dscp-mark 18 qos-web-servers

   Sample output

   Created a new dscp_marking_rule:
   +-----------+--------------------------------------+
   | Field     | Value                                |
   +-----------+--------------------------------------+
   | dscp_mark | 18                                   |
   | id        | d7f976ec-7fab-4e60-af70-f59bf88198e6 |
   +-----------+--------------------------------------+

5. You can change the DSCP value assigned to a rule.

   Example

   openstack network qos rule set --dscp-mark 22 qos-web-servers d7f976ec-7fab-4e60-af70-f59bf88198e6

6. You can delete a DSCP rule.

   Example

   openstack network qos rule delete qos-web-servers d7f976ec-7fab-4e60-af70-f59bf88198e6

Procedure

1. Create a custom environment file and add the NeutronBridgeMappings heat parameter with values that are appropriate for your site.

   parameter_defaults:
     NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"

   The NeutronBridgeMappings heat parameter associates a physical name (datacentre) to a bridge (br-ex).

   Note

   When the NeutronBridgeMappings parameter is not used, the default maps the external bridge on hosts (br-ex) to a physical name (datacentre).

2. To apply this configuration, deploy the overcloud, adding your custom environment file to the stack along with your other environment files.

   (undercloud) $ openstack overcloud deploy --templates \
     -e [your environment files]
     -e /home/stack/templates/<custom-environment-file>.yaml

3. You are ready for the next steps, which are the following:

   1. Using the network VLAN ranges, create the provider networks that represent the corresponding external networks. (You use the physical name when creating neutron provider networks or floating IP networks.)
   2. Connect the external networks to your project networks with router interfaces.

1. 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:

   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 |
   +--------------------------------------+---------+--------------------------------------+

2. 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                                                        |
   +-----------------------+-----------------------------------------------------------------------------+

3. 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                 |
   +-----------------+--------------------------------------+

4. 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 |             |
   +--------------------------------------+--------------+--------------------------------------+-------------+

5. 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                 |
   +-----------------+--------------------------------------+

1. 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                                                     |
   +-----------------------+--------------------------------------------------------------------------+

   Note

   If 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.

2. 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

Procedure

1. Review the configuration of your network trunk, using the network trunk command.

   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                                 |
   +-----------------+------------------------------------------------------+

2. 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

   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                               |
   +--------------------------------------+---------------------------------+

Procedure

1. 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

   Tip

   The 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.

2. In the YAML environment file under ExtraConfig, set the appropriate value (in seconds) for rpc_response_timeout. (The default value is 60 seconds.)

   Example

   parameter_defaults:
     ExtraConfig:
       neutron::rpc_response_timeout: 120

   Note

   The 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.

3. Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file.

   Important

   The 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

1. View the list of available networks:

   # openstack network list
   +--------------------------------------+-------------+-------------------------------------------------------+
   | id                                   | name        | subnets                                               |
   +--------------------------------------+-------------+-------------------------------------------------------+
   | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 | web-servers | 20512ffe-ad56-4bb4-b064-2cb18fecc923 192.168.200.0/24 |
   | bcc16b34-e33e-445b-9fde-dd491817a48a | private     | 7fe4a05a-4b81-4a59-8c47-82c965b0e050 10.0.0.0/24      |
   | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 | public      | 2318dc3b-cff0-43fc-9489-7d4cf48aaab9 172.24.4.224/28  |
   +--------------------------------------+-------------+-------------------------------------------------------+

2. View the list of projects:

   # openstack project list
   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 4b0b98f8c6c040f38ba4f7146e8680f5 | auditors |
   | 519e6344f82e4c079c8e2eabb690023b | services |
   | 80bf5732752a41128e612fe615c886c6 | demo     |
   | 98a2f53c20ce4d50a40dac4a38016c69 | admin    |
   +----------------------------------+----------+

3. Create a RBAC entry for the web-servers network that grants access to the auditors project (4b0b98f8c6c040f38ba4f7146e8680f5):

   # openstack network rbac create --type network --target-project 4b0b98f8c6c040f38ba4f7146e8680f5 --action access_as_shared web-servers
   Created a new rbac_policy:
   +----------------+--------------------------------------+
   | Field          | Value                                |
   +----------------+--------------------------------------+
   | action         | access_as_shared                     |
   | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
   | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | object_type    | network                              |
   | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
   | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
   +----------------+--------------------------------------+

1. Run the openstack network rbac list command to retrieve the ID of your existing role-based access control (RBAC) policies:

   # openstack network rbac list
   +--------------------------------------+-------------+--------------------------------------+
   | id                                   | object_type | object_id                            |
   +--------------------------------------+-------------+--------------------------------------+
   | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
   +--------------------------------------+-------------+--------------------------------------+

2. Run the openstack network rbac-show command to view the details of a specific RBAC entry:

   # openstack network rbac show 314004d0-2261-4d5e-bda7-0181fcf40709
   +----------------+--------------------------------------+
   | Field          | Value                                |
   +----------------+--------------------------------------+
   | action         | access_as_shared                     |
   | id             | 314004d0-2261-4d5e-bda7-0181fcf40709 |
   | object_id      | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | object_type    | network                              |
   | target_project | 4b0b98f8c6c040f38ba4f7146e8680f5     |
   | project_id     | 98a2f53c20ce4d50a40dac4a38016c69     |
   +----------------+--------------------------------------+

1. Run the openstack network rbac list command to retrieve the ID of your existing role-based access control (RBAC) policies:

   # openstack network rbac list
   +--------------------------------------+-------------+--------------------------------------+
   | id                                   | object_type | object_id                            |
   +--------------------------------------+-------------+--------------------------------------+
   | 314004d0-2261-4d5e-bda7-0181fcf40709 | network     | fa9bb72f-b81a-4572-9c7f-7237e5fcabd3 |
   | bbab1cf9-edc5-47f9-aee3-a413bd582c0a | network     | 9b2f4feb-fee8-43da-bb99-032e4aaf3f85 |
   +--------------------------------------+-------------+--------------------------------------+

2. Run the openstack network rbac delete command to delete the RBAC, using the ID of the RBAC that you want to delete:

   # openstack network rbac delete 314004d0-2261-4d5e-bda7-0181fcf40709
   Deleted rbac_policy: 314004d0-2261-4d5e-bda7-0181fcf40709

Procedure

1. Verify that the value for OS::TripleO::Compute::Net::SoftwareConfig matches the value of OS::TripleO::Controller::Net::SoftwareConfig in the file overcloud-resource-registry.yaml or in an environment file included in the deployment command.

   This value names a file, such as net_config_bridge.yaml. The named file configures Neutron bridge mappings for external networks Compute node L2 agents. The bridge routes traffic for the floating IP addresses hosted on Compute nodes in a DVR deployment. Normally, you can find this filename value in the network environment file that you use when deploying the overcloud, such as environments/net-multiple-nics.yaml.

   Note

   If you customize the network configuration of the Compute node, you may need to add the appropriate configuration to your custom files instead.

2. Verify that the Compute node has an external bridge.

   1. Make a local copy of the openstack-tripleo-heat-templates directory.
   2. $ cd <local_copy_of_templates_directory.

   3. Run the process-templates script to render the templates to a temporary output directory:

      $ ./tools/process-templates.py -r <roles_data.yaml> \
        -n <network_data.yaml> -o <temporary_output_directory>

   4. Check the role files in <temporary_output_directory>/network/config.
3. If needed, customize the Compute template to include an external bridge that matches the Controller nodes, and name the custom file path in OS::TripleO::Compute::Net::SoftwareConfig in an environment file.

4. Include the environments/services/neutron-ovs-dvr.yaml file in the deployment command when deploying the overcloud:

   $ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/services/neutron-ovs-dvr.yaml

5. Verify that L3 HA is disabled.

   Note

   The external bridge configuration for the L3 agent was deprecated in Red Hat OpenStack Platform 13 and removed in Red Hat OpenStack Platform 15.

Procedure

1. Upgrade your deployment and validate that it is working correctly.
2. Run the director stack update to configure DVR.
3. Confirm that routing functions correctly through the existing routers.

4. You cannot transition an L3 HA router to distributed directly. Instead, for each router, disable the L3 HA option, and then enable the distributed option:

   1. Disable the router:

      Example

      $ openstack router set --disable router1

   2. Clear high availability:

      Example

      $ openstack router set --no-ha router1

   3. Configure the router to use DVR:

      Example

      $ openstack router set --distributed router1

   4. Enable the router:

      Example

      $ openstack router set --enable router1

   5. Confirm that distributed routing functions correctly.

1. Enable LBaaS:

   # yum install openstack-neutron-lbaas -y

2. Add the LBaaS tables to the neutron database:

   $ neutron-db-manage --subproject neutron-lbaas --config-file /var/lib/config-data/neutron/etc/neutron/neutron.conf --config-file /var/lib/config-data/neutron/etc/neutron/plugins/ml2/ml2_conf.ini upgrade head

3. Change the service provider in /var/lib/config-data/neutron/etc/neutron/neutron_lbaas.conf. In the [service providers] section, comment out (#) all entries except for this entry:

   service_provider=LOADBALANCERV2:Haproxy:neutron_lbaas.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

4. In /var/lib/config-data/neutron/etc/neutron/neutron.conf, confirm that you have the LBaaS v2 plugin configured in service_plugins:

   service_plugins=neutron_lbaas.services.loadbalancer.plugin.LoadBalancerPluginv2

   You can also expect to see any other plugins you have previously added.

   Note

   If you have lbaasv1 configured, replace it with the above setting for lbaasv2.

5. In /var/lib/config-data/neutron/etc/neutron/lbaas_agent.ini, add the following to the [DEFAULT] section:

   ovs_use_veth = False
   interface_driver =neutron.agent.linux.interface.OVSInterfaceDriver

6. In /var/lib/config-data/neutron/etc/neutron/services_lbaas.conf, add the following to the [haproxy] section:

   user_group = haproxy

   1. Comment out any other device driver entries.

      Note

      If the l3-agent is in a failed mode, see the l3_agent log files. You may need to edit /var/lib/config-data/neutron/etc/neutron/neutron.conf and comment out certain values in [DEFAULT], and uncomment the corresponding values in oslo_messaging_rabbit, as described in the log file.

7. Configure the LbaaS services, and review their status:

   1. Stop the lbaasv1 services and start lbaasv2:

      # systemctl disable neutron-lbaas-agent.service
      # systemctl stop neutron-lbaas-agent.service
      # systemctl mask neutron-lbaas-agent.service
      # systemctl enable neutron-lbaasv2-agent.service
      # systemctl start neutron-lbaasv2-agent.service

   2. Review the status of lbaasv2:

      # systemctl status neutron-lbaasv2-agent.service

   3. Restart neutron-server and check the status:

      # systemctl restart neutron-server.service
      # systemctl status neutron-server.service

   4. Check the Loadbalancerv2 agent:

      $ openstack network agent list

Procedure

1. Retrieve the project ID of the Project where you want to create the IPv6 subnet. These values are unique between OpenStack deployments, so your values differ from the values in this example.

   # openstack project list
   +----------------------------------+----------+
   | ID                               | Name     |
   +----------------------------------+----------+
   | 25837c567ed5458fbb441d39862e1399 |    QA    |
   | f59f631a77264a8eb0defc898cb836af |  admin   |
   | 4e2e1951e70643b5af7ed52f3ff36539 |   demo   |
   | 8561dff8310e4cd8be4b6fd03dc8acf5 | services |
   +----------------------------------+----------+

2. Retrieve a list of all networks present in OpenStack Networking (neutron), and note the name of the network where you want to host the IPv6 subnet:

   # openstack network list
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | id                                   | name             | subnets                                                     |
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
   | 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
   | 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers |                                                             |
   +--------------------------------------+------------------+-------------------------------------------------------------+

3. Include the project ID, network name, and ipv6 address mode in the openstack subnet create command:

   # openstack subnet create --ip-version 6 --ipv6-address-mode dhcpv6-stateful --project 25837c567ed5458fbb441d39862e1399 --network database-servers --subnet-range fdf8:f53b:82e4::53/125 subnet_name
   
   Created a new subnet:
   +-------------------+--------------------------------------------------------------+
   | Field             | Value                                                        |
   +-------------------+--------------------------------------------------------------+
   | allocation_pools  | {"start": "fdf8:f53b:82e4::52", "end": "fdf8:f53b:82e4::56"} |
   | cidr              | fdf8:f53b:82e4::53/125                                       |
   | dns_nameservers   |                                                              |
   | enable_dhcp       | True                                                         |
   | gateway_ip        | fdf8:f53b:82e4::51                                           |
   | host_routes       |                                                              |
   | id                | cdfc3398-997b-46eb-9db1-ebbd88f7de05                         |
   | ip_version        | 6                                                            |
   | ipv6_address_mode | dhcpv6-stateful                                              |
   | ipv6_ra_mode      |                                                              |
   | name              |                                                              |
   | network_id        | 6aff6826-4278-4a35-b74d-b0ca0cbba340                         |
   | tenant_id         | 25837c567ed5458fbb441d39862e1399                             |
   +-------------------+--------------------------------------------------------------+

Validation steps

1. Validate this configuration by reviewing the network list. Note that the entry for database-servers now reflects the newly created IPv6 subnet:

   # openstack network list
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | id                                   | name             | subnets                                                     |
   +--------------------------------------+------------------+-------------------------------------------------------------+
   | 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers | cdfc3398-997b-46eb-9db1-ebbd88f7de05 fdf8:f53b:82e4::50/125 |
   | 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
   | 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
   +--------------------------------------+------------------+-------------------------------------------------------------+

   Result

   As a result of this configuration, instances that the QA project creates can receive a DHCP IPv6 address when added to the database-servers subnet:

   # openstack server list
   +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
   | ID                                   | Name       | Status | Task State | Power State | Networks                            |
   +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
   | fad04b7a-75b5-4f96-aed9-b40654b56e03 | corp-vm-01 | ACTIVE | -          | Running     | database-servers=fdf8:f53b:82e4::52 |
   +--------------------------------------+------------+--------+------------+-------------+-------------------------------------+

1. Install the FWaaS packages:

   # dnf install openstack-neutron-fwaas python-neutron-fwaas

2. Enable the FWaaS plugin in the /var/lib/config-data/neutron/etc/neutron/neutron.conf file:

   service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin

3. Configure FWaaS in the fwaas_driver.ini file:

   [fwaas]
   driver = neutron.services.firewall.drivers.linux.iptables_fwaas.IptablesFwaasDriver
   enabled = True
   
   [service_providers]
   service_provider = LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

4. Enable the FWaaS dashboard management option in the local_settings.py file, usually located on the Controller node:

   /usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py
   'enable_firewall' = True

5. Restart neutron-server to apply the changes.

   # systemctl restart neutron-server

1. Create a firewall rule:

   $ neutron firewall-rule-create --protocol <tcp|udp|icmp|any> --destination-port <port-range> --action <allow|deny>

   The CLI requires a protocol value. If the rule is protocol agnostic, you can use the value any.

2. Create a firewall policy:

   $ neutron firewall-policy-create --firewall-rules "<firewall-rule IDs or names separated by space>" myfirewallpolicy

   The order of the rules that you specify in the neutron firewall-policy-create command is important. You can create an empty firewall policy and add rules later, either with the update operation (when adding multiple rules) or with the insert-rule operations (when adding a single rule).

Procedure

1. Log in to the undercloud as the stack user, and source the stackrc file to enable the director command line tools.

   Example

   $ source ~/stackrc

2. Create a custom YAML environment file.

   Example

   $ vi /home/stack/templates/my-neutron-environment.yaml

   Tip

   The 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.

3. Set the NeutronL3HA parameter to true in the YAML environment file. This ensures HA is enabled even if director did not set it by default.

   parameter_defaults:
     NeutronL3HA: 'true'

4. Set the maximum number of L3 agents on which an HA router is scheduled.

   Set the max_l3_agents_per_router parameter to a value between the minimum and total number of network nodes in your deployment. (A zero value indicates that the router is scheduled on every agent.)

   Example

   parameter_defaults:
     NeutronL3HA: 'true'
     ControllerExtraConfig:
       neutron::server::max_l3_agents_per_router: 2

   In this example, if you deploy four Networking service nodes, only two L3 agents protect each HA virtual router: one active, and one standby.

   If you set the value of max_l3_agents_per_router to be greater than the number of available network nodes, you can scale out the number of standby routers by adding new L3 agents. For every new L3 agent node that you deploy, the Networking service schedules additional standby versions of the virtual routers until the max_l3_agents_per_router limit is reached.

5. Run the openstack overcloud deploy command and include the core heat templates, environment files, and this new custom environment file.

   Important

   The order of the environment files is important because 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-neutron-environment.yaml

   Note

   When NeutronL3HA is set to true, all virtual routers that are created default to HA routers. When you create a router, you can override the HA option by including the --no-ha option in the openstack router create command:

   # openstack router create --no-ha