Network Multi-tenancy in the Bare Metal service

Overview

Ironic contains several different networking use models and is largely built around an attachment being requested by the user, be it the nova-compute service on behalf of a Nova user, or directly using the vif attachment (openstack baremetal node vif attach or baremetal node vif attach commands).

Ironic manages the requested attachment state of the vif with the Networking service, and depending on the overall network-interfaces chosen, Ironic will perform additional actions such as attaching the node to an entirely separate provider network to improve the overall operational security.

The underlying network_interface chosen, covered in network-interfaces has significant power in the overall model and use of Ironic, and operators should choose accordingly.

Concepts

Terminology

  • vif or VIF - Virtual Interface which is best described as a Neutron port. VIFs are always referred to utilizing the port ID value.

  • ML2 - ML2 is a plugin model for Neutron, the Networking service. Advanced networking interactions including 3rd party plugins are utilized in this model along with some community plugins to achieve various actions.

Network interfaces

Network interface is one of the driver interfaces that manages network switching for nodes. There are 3 network interfaces available in the Bare Metal service:

  • noop interface is used for standalone deployments, and does not perform any network switching;

  • flat interface places all nodes into a single provider network that is pre-configured on the Networking service and physical equipment. Nodes remain physically connected to this network during their entire life cycle. The supplied VIF attachment record is updated with new DHCP records as needed.

  • neutron interface provides tenant-defined networking through the Networking service, separating tenant networks from each other and from the provisioning and cleaning provider networks. Nodes will move between these networks during their life cycle. This interface requires Networking service support for the switches attached to the baremetal servers so they can be programmed.

Physical networks

A Bare Metal port may be associated with a physical network using its physical_network field. The Bare Metal service uses this information when mapping between virtual ports in the Networking service and physical ports and port groups in the Bare Metal service. A port’s physical network field is optional, and if not set then any virtual port may be mapped to that port, provided that no free Bare Metal port with a suitable physical network assignment exists.

The physical network of a port group is defined by the physical network of its constituent ports. The Bare Metal service ensures that all ports in a port group have the same value in their physical network field.

When attaching a virtual interface (VIF) to a node, the following ordered criteria are used to select a suitable unattached port or port group:

  • Require ports or port groups to not have a physical network or to have a physical network that matches one of the VIF’s allowed physical networks.

  • Prefer ports and port groups that have a physical network to ports and port groups that do not have a physical network.

  • Prefer port groups to ports. Prefer ports with PXE enabled.

Configuring and using Network Multi-tenancy

See the Configure tenant networks section in the installation guide for the Bare Metal service.

Configuring nodes

  1. Ensure that your python-ironicclient version and requested API version are sufficient for your requirements.

    • Multi-tenancy support was added in API version 1.20, and is supported by python-ironicclient version 1.5.0 or higher.

    • Physical network support for ironic ports was added in API version 1.34, and is supported by python-ironicclient version 1.15.0 or higher.

    • Smart NIC support for ironic ports was added in API version 1.53, and is supported by python-ironicclient version 2.7.0 or higher.

    The following examples assume you are using python-ironicclient version 2.7.0 or higher.

    Export the following variable:

    export OS_BAREMETAL_API_VERSION=<API version>
    
  2. The node’s network_interface field should be set to a valid network interface. Valid interfaces are listed in the [DEFAULT]/enabled_network_interfaces configuration option in the ironic-conductor’s configuration file. Set it to neutron to use the Networking service’s ML2 driver:

    baremetal node create --network-interface neutron --driver ipmi
    

    Note

    If the [DEFAULT]/default_network_interface configuration option is set, the --network-interface option does not need to be specified when creating the node.

  3. To update an existing node’s network interface to neutron, use the following commands:

    baremetal node set $NODE_UUID_OR_NAME \
        --network-interface neutron
    
  4. Create a port as follows:

    baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
        --local-link-connection switch_id=$SWITCH_MAC_ADDRESS \
        --local-link-connection switch_info=$SWITCH_HOSTNAME \
        --local-link-connection port_id=$SWITCH_PORT \
        --pxe-enabled true \
        --physical-network physnet1
    

    An Infiniband port requires client ID, while local link connection information will be populated by Infiniband Subnet Manager. The client ID consists of <12-byte vendor prefix>:<8 byte port GUID>. There is no standard process for deriving the port’s MAC address ($HW_MAC_ADDRESS); it is vendor specific. For example, Mellanox ConnectX Family Devices prefix is ff:00:00:00:00:00:02:00:00:02:c9:00. If port GUID was f4:52:14:03:00:38:39:81 the client ID would be ff:00:00:00:00:00:02:00:00:02:c9:00:f4:52:14:03:00:38:39:81. Mellanox ConnectX Family Device’s HW_MAC_ADDRESS consists of 6 bytes; the port GUID’s lower 3 and higher 3 bytes. In this example it would be f4:52:14:38:39:81. Putting it all together, create an Infiniband port as follows:

    baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
        --pxe-enabled true \
        --extra client-id=$CLIENT_ID \
        --physical-network physnet1
    
  5. Create a Smart NIC port as follows:

    baremetal port create $HW_MAC_ADDRESS --node $NODE_UUID \
        --local-link-connection hostname=$HOSTNAME \
        --local-link-connection port_id=$REP_NAME \
        --pxe-enabled true \
        --physical-network physnet1 \
        --is-smartnic
    

    A Smart NIC port requires hostname which is the hostname of the Smart NIC, and port_id which is the representor port name within the Smart NIC.

  6. Check the port configuration:

    baremetal port show $PORT_UUID
    

After these steps, the provisioning of the created node will happen in the provisioning network, and then the node will be moved to the tenant network that was requested.

Configuring the Networking service

In addition to configuring the Bare Metal service some additional configuration of the Networking service is required to ensure ports for bare metal servers are correctly programmed. This configuration will be determined by the Bare Metal service network interfaces you have enabled and which top of rack switches you have in your environment.

flat network interface

In order for Networking service ports to correctly operate with the Bare Metal service flat network interface the baremetal ML2 mechanism driver from networking-baremetal needs to be loaded into the Networking service configuration. This driver understands that the switch should be already configured by the admin, and will mark the networking service ports as successfully bound as nothing else needs to be done.

  1. Install the networking-baremetal library

    $ pip install networking-baremetal
    
  2. Enable the baremetal driver in the Networking service ML2 configuration file

    [ml2]
    mechanism_drivers = ovs,baremetal
    

neutron network interface

The neutron network interface allows the Networking service to program the physical top of rack switches for the bare metal servers. To do this an ML2 mechanism driver which supports the baremetal VNIC type for the make and model of top of rack switch in the environment must be installed and enabled.

This is a list of known top of rack ML2 mechanism drivers which work with the neutron network interface:

Cisco Nexus 9000 series

To install and configure this ML2 mechanism driver see Nexus Mechanism Driver Installation Guide.

FUJITSU CFX2000

networking-fujitsu ML2 driver supports this switch. The documentation is available here.

Networking Generic Switch

This is an ML2 mechanism driver built for testing against virtual bare metal environments and some switches that are not covered by hardware specific ML2 mechanism drivers. More information is available in the project’s README.