Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 2. Configuring the undercloud


This section describes a use case on how to configure the undercloud to accommodate routed spine-leaf with composable networks.

2.1. Configuring the spine leaf provisioning networks

To configure the provisioning networks for your spine leaf infrastructure, edit the undercloud.conf file and set the relevant parameters as defined in the following procedure.

Procedure

  1. Log into the undercloud as the stack user.
  2. If you do not already have an undercloud.conf, copy the sample template file:

    [stack@director ~]$ cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf
    Copy to Clipboard Toggle word wrap
  3. Edit your undercloud.conf.
  4. In the [DEFAULT] section:

    1. Set local_ip to the undercloud IP on leaf0:

      local_ip = 192.168.10.1/24
      Copy to Clipboard Toggle word wrap
    2. Set undercloud_public_vip to the externally facing IP address of the undercloud:

      undercloud_public_vip = 10.1.1.1
      Copy to Clipboard Toggle word wrap
    3. Set undercloud_admin_vip to the administration IP address of the undercloud. This IP address is usually on leaf0:

      undercloud_admin_vip = 192.168.10.2
      Copy to Clipboard Toggle word wrap
    4. Set local_interface to the interface to bridge for the local network:

      local_interface = eth1
      Copy to Clipboard Toggle word wrap
    5. Set enable_routed_networks to true:

      enable_routed_networks = true
      Copy to Clipboard Toggle word wrap
    6. Define your list of subnets using the subnets parameter. Define one subnet for each layer 2 segment in the routed spine and leaf:

      subnets = leaf0,leaf1,leaf2
      Copy to Clipboard Toggle word wrap
    7. Specify the subnet associated with the physical layer 2 segment local to the undercloud using the local_subnet parameter:

      local_subnet = leaf0
      Copy to Clipboard Toggle word wrap
  5. Create a new section per each subnet defined with the subnets parameter:

    [leaf0]
    cidr = 192.168.10.0/24
    dhcp_start = 192.168.10.10
    dhcp_end = 192.168.10.90
    inspection_iprange = 192.168.10.100,192.168.10.190
    gateway = 192.168.10.1
    masquerade = False
    
    [leaf1]
    cidr = 192.168.11.0/24
    dhcp_start = 192.168.11.10
    dhcp_end = 192.168.11.90
    inspection_iprange = 192.168.11.100,192.168.11.190
    gateway = 192.168.11.1
    masquerade = False
    
    [leaf2]
    cidr = 192.168.12.0/24
    dhcp_start = 192.168.12.10
    dhcp_end = 192.168.12.90
    inspection_iprange = 192.168.12.100,192.168.12.190
    gateway = 192.168.12.1
    masquerade = False
    Copy to Clipboard Toggle word wrap
  6. Save the undercloud.conf file.
  7. Run the undercloud installation command:

    [stack@director ~]$ openstack undercloud install
    Copy to Clipboard Toggle word wrap

This creates three subnets on the provisioning network / control plane. The overcloud uses each network to provision systems within each respective leaf.

To ensure proper relay of DHCP requests to the undercloud, you might need to configure a DHCP relay. The next section provides some information on how to configure a DHCP relay.

2.2. Configuring a DHCP relay

The undercloud uses two DHCP servers on the provisioning network:

  • one for introspection.
  • one for provisioning.

When configuring a DHCP relay make sure to forward DHCP requests to both DHCP servers on the undercloud.

You can use UDP broadcast with devices that support it to relay DHCP requests to the L2 network segment where the undercloud provisioning network is connected. Alternatively you can use UDP unicast which relays DHCP requests to specific IP addresses.

Note

Configuration of DHCP relay on specific devices types is beyond the scope of this document. As a reference, this document provides a DHCP relay configuration example using the implementation in ISC DHCP software is available below. Please refer to manual page dhcrelay(8) for further details on how to use this implementation.

Broadcast DHCP relay

This method relays DHCP requests using UDP broadcast traffic onto the L2 network segment where the DHCP server(s) resides. All devices on the network segment receive the broadcast traffic. When using UDP broadcast, both DHCP servers on the undercloud receive the relayed DHCP request. Depending on implementation this is typically configured by specifying either the interface or IP network address:

Interface
Specifying an interface connected to the L2 network segment where the DHCP requests are relayed.
IP network address
Specifying the network address of the IP network where the DHCP request are relayed.

Unicast DHCP relay

This method relays DHCP requests using UDP unicast traffic to specific DHCP servers. When using UDP unicast, you must configure the device providing DHCP relay to relay DHCP requests to both the IP address assigned to the interface used for introspection on the undercloud and the IP address of the network namespace created by the OpenStack Networking (neutron) service to host the DHCP service for the ctlplane network.

The interface used for introspection is the one defined as inspection_interface in undercloud.conf.

Note

It is common to use the br-ctlplane interface for introspection. The IP address defined as local_ip in undercloud.conf is on the br-ctlplane interface.

The IP address allocated to the Neutron DHCP namespace is the first address available in the IP range configured for the local_subnet in undercloud.conf. The first address in the IP range is the one defined as dhcp_start in the configuration. For example: 192.168.10.10 would be the IP address when the following configuration is used:

[DEFAULT]
local_subnet = leaf0
subnets = leaf0,leaf1,leaf2

[leaf0]
cidr = 192.168.10.0/24
dhcp_start = 192.168.10.10
dhcp_end = 192.168.10.90
inspection_iprange = 192.168.10.100,192.168.10.190
gateway = 192.168.10.1
masquerade = False
Copy to Clipboard Toggle word wrap
Warning

The IP address for the DHCP namespace is automatically allocated. In most cases, it will be the first address in the IP range. Ensure sure to verify this is the case by running the following commands on the undercloud:

$ openstack port list --device-owner network:dhcp -c "Fixed IP Addresses"
+----------------------------------------------------------------------------+
| Fixed IP Addresses                                                         |
+----------------------------------------------------------------------------+
| ip_address='192.168.10.10', subnet_id='7526fbe3-f52a-4b39-a828-ec59f4ed12b2' |
+----------------------------------------------------------------------------+
$ openstack subnet show 7526fbe3-f52a-4b39-a828-ec59f4ed12b2 -c name
+-------+--------+
| Field | Value  |
+-------+--------+
| name  | leaf0  |
+-------+--------+
Copy to Clipboard Toggle word wrap

Example dhcrelay configuration

In the following example, the dhcrelay command in the dhcp package uses the following configuration:

  • Interfaces to relay incoming DHCP request: eth1, eth2, and eth3.
  • Interface the undercloud DHCP servers on the network segment are connected to: eth0.
  • The DHCP server used for introspection is listening on IP address: `192.168.10.1.
  • The DHCP server used for provisioning is listening on IP address 192.168.10.10.

This results in the following dhcrelay command:

$ sudo dhcrelay -d --no-pid 172.20.0.10 172.20.0.1 \
  -i eth0 -i eth1 -i eth2 -i eth3
Copy to Clipboard Toggle word wrap

Example Cisco IOS routing switch configuration

This example uses the following Cisco IOS configuration to perform the following tasks:

  • Configure a VLAN to use for our provisioning network.
  • Add the the IP address of the leaf.
  • Forward UDP and BOOTP requests to the introspection DHCP server listening on IP address: 192.168.10.1.
  • Forward UDP and BOOTP requests to the provisioning DHCP server listening on IP address 192.168.10.10.
interface vlan 2
ip address 192.168.24.254 255.255.255.0
ip helper-address 192.168.10.1
ip helper-address 192.168.10.10
!
Copy to Clipboard Toggle word wrap

Now that you have configured the provisioning network, you can configure the remaining overcloud leaf networks. You accomplish this with a series of configuration files.

2.3. Creating flavors and tagging nodes for leaf networks

Each role in each leaf network requires a flavor and role assignment so you can tag nodes into their respective leaf. This procedure shows how to create each flavor and assign them to a role.

Procedure

  1. Source the stackrc file:

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  2. Create flavors for each custom role:

    $ ROLES="control0 compute_leaf0 compute_leaf1 compute_leaf2 ceph-storage_leaf0 ceph-storage_leaf1 ceph-storage_leaf2"
    $ for ROLE in $ROLES; do openstack flavor create --id auto --ram 4096 --disk 40 --vcpus 1 $ROLE ; done
    $ for ROLE in $ROLES; do openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="$ROLE" $ROLE ; done
    Copy to Clipboard Toggle word wrap
  3. Tag nodes to their respective leaf networks. For example, run the following command to tag a node with UUID 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 to the compute role on Leaf2:

    $ openstack baremetal node set --property capabilities='profile:compute_leaf2,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13
    Copy to Clipboard Toggle word wrap
  4. Create an environment file (~/templates/node-data.yaml) that contains the mapping of flavors to roles:

    parameter_defaults:
      OvercloudController0Flavor: control0
      Controller0Count: 3
      OvercloudCompute0Flavor: compute_leaf0
      Compute0Count: 3
      OvercloudCompute1Flavor: compute_leaf1
      Compute1Count: 3
      OvercloudCompute2Flavor: compute_leaf2
      Compute2Count: 3
      OvercloudCephStorage0Flavor: ceph-storage_leaf0
      CephStorage0Count: 3
      OvercloudCephStorage1Flavor: ceph-storage_leaf1
      CephStorage1Count: 3
      OvercloudCephStorage2Flavor: ceph-storage_leaf2
      CephStorage2Count: 3
    Copy to Clipboard Toggle word wrap

    You can also set the number of nodes to deploy in the overcloud using each respective *Count` parameter.

To enable deployment onto a L3 routed network the bare metal ports must have its physical_network field configured. Each baremetal port is associated with a bare metal node in the OpenStack Bare Metal (ironic) service. The physical network names are the ones used in the subnets option in the undercloud configuration.

Note

The physical network name of the subnet specified as local_subnet in undercloud.conf is special. It is always named ctlplane.

Procedure

  1. Source the stackrc file:

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  2. Check the bare metal nodes:

    $ openstack baremetal node list
    Copy to Clipboard Toggle word wrap
  3. Ensure the bare metal nodes are either in enroll or manageable state. If the bare metal node is not in one of these states, the command used to set the physical_network property on the baremetal port will fail. To set all nodes to manageable state run the following command:

    $ for node in $(openstack baremetal node list -f value -c Name); do openstack baremetal node manage $node --wait; done
    Copy to Clipboard Toggle word wrap
  4. Check which baremetal ports are associated with which baremetal node. For example:

    $ openstack baremetal port list --node <node-uuid>
    Copy to Clipboard Toggle word wrap
  5. Set the physical-network parameter for the ports. In the example below, three subnets are defined in the configuration: leaf0, leaf1, and leaf2. The local_subnet is leaf0. Since the physical network for the local_subnet is always ctlplane, the baremetal port connected to leaf0 uses ctlplane. The remaining ports use the other leaf names:

    $ openstack baremetal port set --physical-network ctlplane <port-uuid>
    $ openstack baremetal port set --physical-network leaf1 <port-uuid>
    $ openstack baremetal port set --physical-network leaf2 <port-uuid>
    $ openstack baremetal port set --physical-network leaf2 <port-uuid>
    Copy to Clipboard Toggle word wrap
  6. Make sure the nodes are in available state before deploying the overcloud:

    $ openstack overcloud node provide --all-manageable
    Copy to Clipboard Toggle word wrap
Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat