Chapter 8. ML2 networking-ansible

You can enable and configure the networking-ansible ML2 driver on an overcloud with the Networking service (neutron) and integrate it with the Bare Metal Provisioning service (ironic)

8.1. Modular Layer 2 (ML2) networking-ansible

OpenStack Networking (neutron) contains networking-ansible, which is an ML2 driver that uses Ansible Engine Networking to manage network switches. This driver also integrates with OpenStack Bare Metal (ironic) to configure VLANs on switch ports for the bare metal guests. This means that any bare metal guest that uses a VLAN neutron network causes this driver to configure the physical switch using Ansible Engine Networking.

The current networking-ansible driver includes the following functionality:

  • Define a VLAN on the switch when creating a network in Red Hat OpenStack Platform (RHOSP)
  • Assign a VLAN to an access port on the switch when creating or updating a port in RHOSP
  • Remove a VLAN from an access port on the switch when deleting a port in RHOSP

8.2. Networking requirements for networking-ansible

To enable networking-ansible functionality, your environment must include the following networking configuration:

  • A network switch with Ansible Network Automation support:

    • Juniper Networks (junos)
    • Arista Extensible Operating System (eos)
Important

Arista Extensible Operating System (eos) support is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.

  • The network switch requires an SSH user so that Ansible Network Automation can interact with the device. This user requires the following permissions on the switch:

    • Access mode
    • Assign a VLAN to a port
    • Create VLANs

    For security purposes, do not provide the SSH user with administrator access to the switch.

  • Prepare the VLANs that you want the switch to use. To prepare the VLANs, create each VLAN on the switch, and then delete each VLAN.
  • The network switch ports reserved for bare metal guests initially require configuration to connect to the dedicated network for introspection. Beyond this, these ports require no additional configuration.

8.3. Openstack Bare Metal (ironic) requirements for networking-ansible

The networking-ansible driver integrates with the Openstack Bare Metal (ironic) service. To ensure successful integration, deploy the Bare Metal Provisioning service (ironic) to your overcloud with the following recommendations:

  • The overcloud requires a provisioning network. Use one of the following options:

    • A bridged network for ironic services.
    • A custom composable network for ironic services.

    For more information about configuring the provisioning network, see Chapter 3, Deploying an IPv4 overcloud with the Bare Metal Provisioning service or Chapter 4, Deploying an IPv6 overcloud with the Bare Metal Provisioning service.

  • The overcloud requires a tenant network for the bare metal systems to use after the provisioning process. The examples in this guide use the default baremetal network mapped to a bridge named br-baremetal. This network also requires a range of VLAN IDs. The following heat parameters set these values to suit examples in this guide:

    parameter_defaults:
      NeutronNetworkVLANRanges: baremetal:1200:1299
      NeutronFlatNetworks: datacentre,baremetal
      NeutronBridgeMappings: datacentre:br-ex,baremetal:br-baremetal
  • The overcloud uses the introspection service to automatically identify certain hardware details and map them for other services to use. It is recommended that you enable the ironic introspection service to help map your interface-to-port details for networking-ansible to use. You can also accomplish this task manually.

For more information about deploying the Bare Metal Provisioning service (ironic), see Chapter 3, Deploying an IPv4 overcloud with the Bare Metal Provisioning service or Chapter 4, Deploying an IPv6 overcloud with the Bare Metal Provisioning service.

8.4. Enabling networking-ansible ML2 functionality

To enable the networking-ansible ML2 driver in your overcloud, you must add two environment files to your deployment:

/usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml
This file enables the networking-ansible driver and sets the network type to vlan. This file already exists in the core heat template collection.
/home/stack/templates/ml2-ansible-hosts.yaml
A file that contains details about your switches. You create this file manually.

Procedure

  1. Create the /home/stack/templates/ml2-ansible-hosts.yaml and add the following initial content:

    parameter_defaults:
      ML2HostConfigs:
  2. The ML2HostConfigs parameter requires a dict value with details about your switches. Each initial key in the dict is a name for the switch. This value defines a specific ansible:[switchname] section in your OpenStack Networking (neutron) ML2 configuration. Each switch name key requires its own dict that contains the actual switch details. For example, to configure three switches, add three switch keys:

    parameter_defaults:
      ML2HostConfigs:
        switch1:
          [SWITCH DETAILS]
        switch2:
          [SWITCH DETAILS]
        switch3:
          [SWITCH DETAILS]
  3. Each switch requires certain key value pairs in the dict:

    ansible_network_os

    (Required) The operating system of the switch. Options include junos and eos.

    Important

    Arista Extensible Operating System (eos) support is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.

    ansible_host
    (Required) The IP or hostname of the switch.
    ansible_user
    (Required) The user that Ansible uses to access the switch.
    ansible_ssh_pass
    (Required) The SSH password that Ansible uses to access the switch.
    mac
    Chassis MAC ID of the network device. Used to map the link layer discovery protocol (LLDP) MAC address value to the switch name defined in the ML2HostConfigs configuration. This is a required value when using introspection to perform automatic port configuration.
    manage_vlans
    A Boolean variable to define whether OpenStack Networking (neutron) controls the creation and deletion of VLANs on the physical device. This functionality causes the switch to create and delete VLANs with IDs respective to their Neutron networks. If you have predefined these VLANs on the switch and do not require Neutron to create or delete VLANs on the switch, set this parameter to false. The default value is true.
  4. The following example shows how to map these values to their respective keys in a full ML2HostConfigs parameter:

    parameter_defaults:
      ML2HostConfigs:
        switch1:
          ansible_network_os: juno
          ansible_host: 10.0.0.1
          ansible_user: ansible
          ansible_ssh_pass: "p@55w0rd!"
          mac: 01:23:45:67:89:AB
          manage_vlans: false
  5. Save the /home/stack/templates/ml2-ansible-hosts.yaml file.
  6. When you run the overcloud deployment command, include the /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml and /home/stack/templates/ml2-ansible-hosts.yaml files with the -e option. The following example demonstrates how to include these files:

    $ openstack overcloud deploy --templates \
      ...
      -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-ansible.yaml \
      -e /home/stack/templates/ml2-ansible-hosts.yaml \
      ...

Director enables the driver as a part of the OpenStack Networking (neutron) API on the neutron_api container.

8.5. Configuring networks for networking-ansible

After you deploy the overcloud with bare metal provisioning and the networking-ansible driver enabled, you must create provisioning and tenant networks for your bare metal nodes. You must also configure ports for your bare metal nodes either in access mode or trunk mode, depending on your requirements.

Access mode
In access mode, switch ports carry the traffic of only one VLAN and operate on a single broadcast domain. All traffic that arrives to access ports belongs to the VLAN that is assigned to the port.
Trunk mode

In trunk mode, switch ports can belong to more than one VLAN. You can use switch ports in trunk mode to carry the traffic of a group of VLANs, or if you want to exchange traffic between multiple switches with more than one VLAN.

Important

This feature is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.

The Bare Metal service (ironic) uses networking-ansible to assign the switchport of the bare metal guest to the ironic provisioning network so that the provisioning process can complete successfully. After provisioning is complete, ironic assigns the switchport of the bare metal guest to the VLAN that the Networking service (neutron) assigns to the tenant networks of the bare metal guest.

8.5.1. Configuring networks for networking-ansible in access mode

After you deploy the overcloud with bare metal provisioning and the networking-ansible driver enabled, create the following networks for your bare metal nodes:

Provisioning network
Bare metal systems use this network for their initial creation.
Tenant network
Bare metal systems switch to this network after provisioning and use this network for internal communication.

Procedure

  1. Create the provisioning network and subnet. This depends on the type of provisioning network you are using. For more information about configuring the provisioning network, see Chapter 5, Configuring the Bare Metal Provisioning service after deployment.
  2. Create a tenant network and subnet:

    $ openstack network create --provider-network-type vlan --provider-physical-network baremetal tenant-net
    $ openstack subnet create --network tenant-net --subnet-range 192.168.3.0/24 --allocation-pool start=192.168.3.10,end=192.168.3.20 tenant-subnet

    Ensure that you set the --provider-network-type option to vlan to ensure networking-ansible functionality.

8.5.2. Configuring ports for bare metal guests in access mode

Bare metal guests require port information to connect to the switch. There are two methods to accomplish this:

  • Automatic: Introspection of nodes. To use the automatic method, set the mac value for the respective switch as a part of the ML2HostConfigs parameter.
  • Manual: Set the OpenStack Networking (neutron) port configuration. Use this method if your overcloud does not include bare metal introspection functionality.

Procedure

  • Automatic:

    1. Run the introspection command:

      $ openstack baremetal introspection start [--wait] <NODENAME>

      The bare metal nodes obtain the MAC address of the switch during introspection. The networking-ansible ML2 driver uses this MAC address to map to the same MAC address that you define with the mac parameter for the respective switch in the ML2HostConfigs parameter.

    2. Wait until the introspection completes.
  • Manual:

    1. Create a port for the bare metal node. Use the following example command as a basis to create the port:

      $ openstack baremetal port create [NODE NIC MAC] --node [NODE UUID] \
          --local-link-connection port_id=[SWICH PORT ID] \
          --local-link-connection switch_info=[SWITCH NAME] \
          --local-link-connection switch_id=[SWITCH MAC]

      Replace the following values in brackets with your own environment details:

      [NODE NIC MAC]
      The MAC address of the NIC that is connected to the switch.
      --node [NODE UUID]
      The UUID of the node that uses the new port.
      --local-link-connection port_id=[SWITCH PORT ID]
      The port ID on the switch that connects to the bare metal node.
      --local-link-connection switch_info=[SWITCH NAME]
      The name of the switch that connects to the bare metal node. The switch name must match the respective switch name that you define in the ML2HostConfigs parameter.
      --local-link-connection switch_id=[SWITCH MAC]
      The MAC address of the switch. This must match the respective mac value from the switch configuration from the ML2HostConfigs parameter. This is an alternative option to using switch_info.

8.5.3. Configuring networks for networking-ansible in trunk mode

Important

This feature is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.

After you deploy the overcloud with bare metal provisioning and the networking-ansible driver enabled, create the following networks for your bare metal nodes:

Provisioning network
Bare metal systems use this network for their initial creation.
Tenant network
Bare metal systems switch to this network after provisioning and use this network for internal communication.

Procedure

  1. Create the provisioning network and subnet. This depends on the type of provisioning network you are using. For more information about configuring the provisioning network, see Chapter 5, Configuring the Bare Metal Provisioning service after deployment.
  2. Create a primary tenant VLAN network, a secondary tenant network, and subnets for each network that use the physical network that the guest is attached to:

    $ openstack network create --provider-network-type vlan --provider-physical-network baremetal primary-tenant-net
    $ openstack network create --provider-network-type vlan --provider-physical-network baremetal secondary-tenant-net
    $ openstack subnet create --network primary-tenant-net --subnet-range 192.168.3.0/24 --allocation-pool start=192.168.3.10,end=192.168.3.20 primary-tenant-subnet
    $ openstack subnet create --network secondary-tenant-net --subnet-range 192.168.7.0/24 --allocation-pool start=192.168.7.10,end=192.168.7.20 secondary-tenant-subnet

    Ensure that you set the --provider-network-type option to vlan to ensure networking-ansible functionality.

8.5.4. Configuring ports for bare metal guests in trunk mode

Important

This feature is available in this release as a Technology Preview, and therefore is not fully supported by Red Hat. It should only be used for testing, and should not be deployed in a production environment. For more information about Technology Preview features, see Scope of Coverage Details.

Bare metal guests require port information to connect to the switch so that you can use the Bare Metal Provisioning service (ironic) to deploy on multiple networks with a single switch port. The switch port is configured in trunk mode using the VLANs that the Networking service (neutron) assigns from the supplied networks.

Complete the following steps to configure trunk ports for bare metal guests.

Procedure

  1. Create a port and a trunk, and assign the port to the trunk as the parent port:

    $ port create --network primary-tenant-net primary-port
    $ network trunk create --parent-port primary-port my-trunk
  2. Create a port for the secondary network and add the new port as a subport to the trunk:

    $ port create --network secondary-tenant-net secondary-port
    $ network trunk set --subport port=secondary-port,segmentation-type=vlan,segmentation-id=1234 my-trunk

8.6. Testing networking-ansible ML2 functions

After the networking-ansible configuration for the bare metal node is complete, create a bare metal workload to verify that the configuration is correct.

Prerequisites

  • An overcloud with OpenStack Baremetal (ironic) services.
  • An enabled networking-ansible ML2 driver.
  • The ML2HostConfigs parameter contains switch access details.
  • A registered bare metal node.
  • Configuration of the respective bare metal port used for the node connection on the switch. This port can be either an access port or a trunk port.
  • A VLAN-based provisioning network defined in OpenStack Networking (neutron) for initial provisioning.
  • A VLAN-based tenant network defined in OpenStack Networking (neutron) for internal communication.
  • Disk images and key pairs available in the overcloud.

Procedure

  1. Create the bare metal system:

    • To create a bare metal system that uses an access port, run the following command:

      openstack server create --flavor baremetal --image overcloud-full --key default --network tenant-net test1
    • To create a bare metal system that uses a trunk port, run the following command:

      openstack server create --flavor baremetal --image overcloud-full --port {primary-port-uuid} --key default test1

The overcloud initially creates the bare metal system on the provisioning network. When the creation completes, the networking-ansible driver changes the port configuration on the switch so that the bare metal system uses the tenant network.