2.3. Networking Requirements

The Undercloud host requires at least two networks:
  • Provisioning Network - This is a private network the director uses to provision and manage the Overcloud nodes. The Provisioning network provides DHCP and PXE boot functions to help discover bare metal systems for use in the Overcloud. This network must use a native VLAN on a trunked interface so that the director serves PXE boot and DHCP requests. This is also the network you use to control power management through Intelligent Platform Management Interface (IPMI) on all Overcloud nodes.
  • External Network - A separate network for remote connectivity to all nodes. The interface connecting to this network requires a routable IP address, either defined statically, or dynamically through an external DHCP service.
This represents the minimum number of networks required. However, the director can isolate other Red Hat OpenStack Platform network traffic into other networks. Red Hat OpenStack Platform supports both physical interfaces and tagged VLANs for network isolation. For more information on network isolation, see Section 3.2, “Planning Networks”.
Note the following:
  • Typical minimal Overcloud network configuration can include:
    • Single NIC configuration - One NIC for the Provisioning network on the native VLAN and tagged VLANs that use subnets for the different Overcloud network types.
    • Dual NIC configuration - One NIC for the Provisioning network and the other NIC for the External network.
    • Dual NIC configuration - One NIC for the Provisioning network on the native VLAN and the other NIC for tagged VLANs that use subnets for the different Overcloud network types.
    • Multiple NIC configuration - Each NIC uses a subnet for a different Overcloud network type.
  • Additional physical NICs can be used for isolating individual networks, creating bonded interfaces, or for delegating tagged VLAN traffic.
  • If using VLANs to isolate your network traffic types, use a switch that supports 802.1Q standards to provide tagged VLANs.
  • During the Overcloud creation, you will refer to NICs using a single name across all Overcloud machines. Ideally, you should use the same NIC on each Overcloud node for each respective network to avoid confusion. For example, use the primary NIC for the Provisioning network and the secondary NIC for the OpenStack services.
  • Make sure the Provisioning network NIC is not the same NIC used for remote connectivity on the director machine. The director installation creates a bridge using the Provisioning NIC, which drops any remote connections. Use the External NIC for remote connections to the director system.
  • The Provisioning network requires an IP range that fits your environment size. Use the following guidelines to determine the total number of IP addresses to include in this range:
    • Include at least one IP address per node connected to the Provisioning network.
    • If planning a high availability configuration, include an extra IP address for the virtual IP of the cluster.
    • Include additional IP addresses within the range for scaling the environment.

    Note

    Duplicate IP addresses should be avoided on the Provisioning network. For more information, see Section 11.4, “Troubleshooting IP Address Conflicts on the Provisioning Network”.

    Note

    For more information on planning your IP address usage, for example, for storage, provider, and tenant networks, see the Networking Guide.
  • Set all Overcloud systems to PXE boot off the Provisioning NIC, and disable PXE boot on the External NIC (and any other NICs on the system). Also ensure that the Provisioning NIC has PXE boot at the top of the boot order, ahead of hard disks and CD/DVD drives.
  • All Overcloud bare metal systems require an Intelligent Platform Management Interface (IPMI) connected to the Provisioning network, as this allows the director to control the power management of each node.
  • Make a note of the following details for each Overcloud system: the MAC address of the Provisioning NIC, the IP address of the IPMI NIC, IPMI username, and IPMI password. This information will be useful later when setting up the Overcloud nodes.
  • If an instance needs to be accessible from the external internet, you can allocate a floating IP address from a public network and associate it with an instance. The instance still retains its private IP but network traffic uses NAT to traverse through to the floating IP address. Note that a floating IP address can only be assigned to a single instance rather than multiple private IP addresses. However, the floating IP address is reserved only for use by a single tenant, allowing the tenant to associate or disassociate with a particular instance as required. This configuration exposes your infrastructure to the external internet. As a result, you might need to check that you are following suitable security practices.
  • To mitigate the risk of network loops in Open vSwitch, only a single interface or a single bond may be a member of a given bridge. If you require multiple bonds or interfaces, you can configure multiple bridges.

Important

Your OpenStack Platform implementation is only as secure as its environment. Follow good security principles in your networking environment to ensure that network access is properly controlled. For example:
  • Use network segmentation to mitigate network movement and isolate sensitive data; a flat network is much less secure.
  • Restrict services access and ports to a minimum.
  • Ensure proper firewall rules and password usage.
  • Ensure that SELinux is enabled.
For details on securing your system, see: