Search
SupportConsoleDevelopersStart a trialContact

Chapter 6. Configuring overcloud networking

download PDF

To configure the physical network for your overcloud, create a network configuration file, network_data.yaml, that follows the structure defined in the network data schema.

6.1. Defining the overcloud networks

Red Hat OpenStack Platform (RHOSP) provides default overcloud networks that you can use to host specific types of network traffic in isolation. If no isolated networks are configured, RHOSP uses the provisioning network for all services.

You can define the following isolated overcloud networks:

IPMI
Network used for power management of nodes. This network is predefined before the installation of the undercloud.
Provisioning

Director uses this network for deployment and management. The provisioning network is normally configured on a dedicated interface. The initial deployment uses DHCP with PXE, then the network is converted to static IP. By default, PXE boot must occur on the native VLAN, although some system controllers allow booting from a VLAN. By default, the compute and storage nodes use the provisioning interface as their default gateway for DNS, NTP, and system maintenance.

The undercloud can be used as a default gateway. However, all traffic is behind an IP masquerade NAT (Network Address Translation), and is not reachable from the rest of the RHOSP network. The undercloud is also a single point of failure for the overcloud default route. If there is an external gateway configured on a router device on the provisioning network, the undercloud neutron DHCP server can offer that service instead.

Internal API
The Internal API network is used for communication between the RHOSP services using API communication, RPC messages, and database communication.
Tenant

The Networking service (neutron) provides each tenant (project) with their own networks using one of the following methods:

  • VLAN segregation, where each tenant network is a network VLAN.
  • Tunneling through VXLAN or GRE.

Network traffic is isolated within each tenant network. Each tenant network has an IP subnet associated with it, and network namespaces means that multiple tenant networks can use the same address range without causing conflicts.

Storage
Network used for block Storage, NFS, iSCSI, and others. Ideally, this would be isolated to an entirely separate switch fabric for performance reasons.
Storage Management
The Object Storage service (swift) uses this network to synchronize data objects between participating replica nodes. The proxy service acts as the intermediary interface between user requests and the underlying storage layer. The proxy receives incoming requests and locates the necessary replica to retrieve the requested data. Services that use a Red Hat Ceph Storage back end connect over the Storage Management network because they do not interact directly with Red Hat Ceph Storage, but instead use the front end service. The RBD driver is an exception, as this traffic connects directly to Red Hat Ceph Storage.
External
Hosts the Dashboard service (horizon) for graphical system management, the public APIs for RHOSP services, and performs SNAT for incoming traffic destined for instances.
Floating IP
Allows incoming traffic to reach instances using 1-to-1 IP address mapping between the floating IP address, and the IP address actually assigned to the instance in the tenant network. If hosting the Floating IPs on a VLAN separate from external, you can trunk the Floating IP VLAN to the Controller nodes and add the VLAN through the Networking Service (neutron) after overcloud creation. This provides a means to create multiple Floating IP networks attached to multiple bridges. The VLANs are trunked but are not configured as interfaces. Instead, the Networking Service (neutron) creates an OVS port with the VLAN segmentation ID on the chosen bridge for each Floating IP network.
Note

The provisioning network must be a native VLAN, the other networks can be trunked.

You must define specific isolated networks for each role:

RoleNetwork

Controller

provisioning, internal API, storage, storage management, tenant, external

Compute

provisioning, internal API, storage, tenant

Ceph Storage

provisioning, internal API, storage, storage management

Cinder Storage

provisioning, internal API, storage, storage management

Swift Storage

provisioning, internal API, storage, storage management

6.2. Creating the network definition file

Create a network definition file to configure your isolated overcloud networks.

Procedure

  1. Copy the sample network definition template you require from /usr/share/openstack-tripleo-heat-templates/network-data-samples to your environment file directory: 

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/<sample_network_definition_file> /home/stack/templates/<networks_definition_file>
    • Replace <sample_network_definition_file> with the name of the sample network definition file that you want to copy, for example, default-network-isolation-ipv6.yaml.
    • Replace <networks_definition_file> with the name of your network definition file, for example, network_data.yaml.
  2. Update the networks and network attributes in your local network definition file to match the requirements for your overcloud network environment. For information about the properties you can use to configure network attributes in your network definition file, see Network definition file configuration options. For an example node definition file, see Example network definition file.

  3. Optional: To change the user-visible names of the default networks, change the name_lower field to the new name for the network and update the ServiceNetMap with the new name: 

    - name: InternalApi
  name_lower: <custom_name>
  service_net_map_replace: <default_name>
    • Do not modify the name field.
    • Replace <custom_name> with the new name you want to assign to the network, for example, MyCustomInternalApi.
    • Replace <default_name> with the default value of the name_lower parameter, for example, internal_api.

  4. Optional: Add custom networks to your network definition file. The following example adds a network for storage backups: 

    - name: StorageBackup
  vip: false
  name_lower: storage_backup
  subnets:
    storage_backup_subnet:
      ip_subnet: 172.16.6.0/24
      allocation_pools:
        - start: 172.16.6.4
        - end: 172.16.6.250
      gateway_ip: 172.16.6.1

6.3. Creating the network VIP definition file

Create a network Virtual IP (VIP) definition file to configure the network VIPs for your overcloud.

Procedure

  1. Copy the sample network VIP definition template you require from /usr/share/openstack-tripleo-heat-templates/network-data-samples to your environment file directory: 

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/<sample_network_VIP_definition_file> /home/stack/templates/<network_VIP_definition_file>
    • Replace <sample_network_VIP_definition_file> with the name of the sample network VIP definition file that you want to copy, for example, vip-data-default-network-isolation.yaml.
    • Replace <network_VIP_definition_file> with the name of your network VIP definition file, for example, vip_data.yaml.

  2. Optional: Configure your network VIP definition file for your environment: 

    - network: <network>
  dns_name: <dns_name>
  name: <vip_name>
  ip_address: <vip_address>
  subnet: <subnet>
    • Replace <network> with the name of the network where the IP address is allocated, for example, internal_api or storage.
    • Optional: Replace <dns_name> with the FQDN (Fully Qualified Domain Name), for example, overcloud.
    • Optional: Replace <vip_name> with the VIP name.
    • Optional: Replace <vip_address> with the virtual IP address for the network.

    • Optional: Replace <subnet> with the name of the subnet to use when creating the virtual IP port. Required for routed networks.

      For example, the following configuration defines the external network and control plane VIPs: 

      - network: external
  dns_name: overcloud
  ip_address: '1.2.3.4'
- network: ctlplane
  dns_name: overcloud

    For information about the properties you can use to configure your network VIPs, see Network VIP attribute properties.

6.4. Network definition file configuration options

You can use the properties in the following tables to configure network attributes in your network_data.yaml file.

Table 6.1. Network definition properties
PropertyValue

name

The name of the network.

name_lower

The lowercase version of the network name. Director maps this name to respective networks assigned to roles in the roles_data.yaml file. The default value is name.lower().

dns_domain

The DNS domain name for the network. Set the dns_domain only if your undercloud node deploys and manages multiple overclouds.

To determine the dns_domain value, complete the following steps:

  • Convert the network name to lowercase.
  • Replace all underscores ("_") in the network name with a hyphen ("-").
  • Suffix the network name with a dot (".") and the name of the CloudDomain.

Example:

  • network.name = InternalApi
  • CloudDomain = cloud.example.com.
  • dns_domain = internalapi.cloud.example.com.
Note

You cannot use the same dns_domain for different networks.

mtu

The Maximum Transmission Unit (MTU). The default value is 1500.

ipv6

Set to true for IPv6. The default value is false.

vip

Set to true to create a VIP on the network. The default value is false.

subnets

Contains the subnets definitions for the network.

Table 6.2. Subnet definition properties
PropertyValue

subnet_name

The name of the subnet.

ip_subnet

The IPv4 subnet in CIDR block notation. The default value is 192.0.5.0/24.

ipv6_subnet

The IPv6 subnet in CIDR block notation. The default value is 2001:db6:fd00:1000::/64

gateway_ip

The gateway address for the IPv4 network. The default value is 192.0.5.1.

gateway_ipv6

The gateway for the IPv6 network.

allocation_pools

The IP range for the IPv4 subnet. Default value: 

start: 192.0.5.100
end: 192.0.5.150

ipv6_allocation_pools

The IP range for the IPv6 subnet. Default value: 

start: 2001:db6:fd00:1000:100::1
end: 2001:db6:fd00:1000:150::1

routes

List of IPv4 networks that require routing through the network gateway.

routes_ipv6

List of IPv6 networks that require routing through the network gateway.

vlan

The VLAN ID for the network.

Note

The routes and routes_ipv6 options contain a list of routes. Each route is a dictionary entry with the destination and nexthop keys. Both options are of type string. 

routes:
  - destination: 198.51.100.0/24
    nexthop: 192.0.5.1
  - destination: 203.0.113.0/24
    nexthost: 192.0.5.1
routes:
  - destination: 2001:db6:fd00:2000::/64
    nexthop: 2001:db6:fd00:1000:100::1
  - destination: 2001:db6:fd00:3000::/64
    nexthost: 2001:db6:fd00:1000:100::1

6.5. Network VIP attribute properties

You can use the following properties to configure network VIP attributes in your network_data.yaml file.

Table 6.3. Network VIP attribute properties
PropertyValue

name

The virtual IP name. The default value is $network_name_virtual_ip.

network

(Mandatory) The network name.

ip_address

The fixed IP address of the VIP.

subnet

The subnet name. Specifies the subnet for the virtual IP port. Required for deployments that use routed networks.

dns_name

The FQDN (Fully Qualified Domain Name). The default value is overcloud.

6.6. Example network definition file

The following example network definition file configures the storage, storage management, internal API, tenant, and external networks. 

- name: Storage
  name_lower: storage
  vip: true
  ipv6: true
  mtu: 1500
  subnets:
    storage_subnet:
      ipv6_subnet: fd00:fd00:fd00:3000::/64
      ipv6_allocation_pools:
        - start: fd00:fd00:fd00:3000::10
          end: fd00:fd00:fd00:3000:ffff:ffff:ffff:fffe
      vlan: 30
- name: StorageMgmt
  name_lower: storage_mgmt
  vip: true
  ipv6: true
  mtu: 1500
  subnets:
    storage_mgmt_subnet:
      ipv6_subnet: fd00:fd00:fd00:4000::/64
      ipv6_allocation_pools:
        - start: fd00:fd00:fd00:4000::10
          end: fd00:fd00:fd00:4000:ffff:ffff:ffff:fffe
      vlan: 40
- name: InternalApi
  name_lower: internal_api
  vip: true
  ipv6: true
  mtu: 1500
  subnets:
    internal_api_subnet:
      ipv6_subnet: fd00:fd00:fd00:2000::/64
      ipv6_allocation_pools:
        - start: fd00:fd00:fd00:2000::10
          end: fd00:fd00:fd00:2000:ffff:ffff:ffff:fffe
      vlan: 20
- name: Tenant
  name_lower: tenant
  vip: false # Tenant networks do not use VIPs
  ipv6: true
  mtu: 1500
  subnets:
    tenant_subnet:
      ipv6_subnet: fd00:fd00:fd00:5000::/64
      ipv6_allocation_pools:
        - start: fd00:fd00:fd00:5000::10
          end: fd00:fd00:fd00:5000:ffff:ffff:ffff:fffe
      vlan: 50
- name: External
  name_lower: external
  vip: true
  ipv6: true
  mtu: 1500
  subnets:
    external_subnet:
      ipv6_subnet: 2001:db8:fd00:1000::/64
      ipv6_allocation_pools:
        - start: 2001:db8:fd00:1000::10
          end: 2001:db8:fd00:1000:ffff:ffff:ffff:fffe
      gateway_ipv6: 2001:db8:fd00:1000::1
      vlan: 10
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.