Chapter 2. Configuring routed spine-leaf in the undercloud
Chapter 2. Configuring routed spine-leaf in the undercloud This section describes a use case about 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 included in the following procedure. Procedure Log in to the undercloud as the stack user. If you do not already have an undercloud.conf file, copy the sample template file: Edit the undercloud.conf file. Set the following values in the [DEFAULT] section: Set local_ip to the undercloud IP on leaf0 : Set undercloud_public_host to the externally facing IP address of the undercloud: Set undercloud_admin_host to the administration IP address of the undercloud. This IP address is usually on leaf0: Set local_interface to the interface to bridge for the local network: Set enable_routed_networks to true : Define your list of subnets using the subnets parameter. Define one subnet for each L2 segment in the routed spine and leaf: Specify the subnet associated with the physical L2 segment local to the undercloud using the local_subnet parameter: Set the value of undercloud_nameservers . Tip You can find the current IP addresses of the DNS servers that are used for the undercloud nameserver by looking in /etc/resolv.conf. Create a new section for each subnet that you define in the subnets parameter: Save the undercloud.conf file. Run the undercloud installation command: This configuration creates three subnets on the provisioning network or 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. 2.2. Configuring a DHCP relay You run the DHCP relay service on a switch, router, or server that is connected to the remote network segment you want to forward the requests from. Note Do not run the DHCP relay service on the undercloud. The undercloud uses two DHCP servers on the provisioning network: An introspection DHCP server. A provisioning DHCP server. You must configure the DHCP relay 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 device 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. For more information, see manual page dhcrelay(8). Important DHCP option 79 is required for some relays, particularly relays that serve DHCPv6 addresses, and relays that do not pass on the originating MAC address. For more information, see RFC6939 . Broadcast DHCP relay This method relays DHCP requests using UDP broadcast traffic onto the L2 network segment where the DHCP server or servers reside. 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 the implementation, you can configure this by specifying either the interface or IP network address: Interface Specify an interface that is connected to the L2 network segment where the DHCP requests are relayed. IP network address Specify the network address of the IP network where the DHCP requests are relayed. Unicast DHCP relay This method relays DHCP requests using UDP unicast traffic to specific DHCP servers. When you use UDP unicast, you must configure the device that provides the DHCP relay to relay DHCP requests to both the IP address that is assigned to the interface used for introspection on the undercloud and the IP address of the network namespace that the OpenStack Networking (neutron) service creates to host the DHCP service for the ctlplane network. The interface used for introspection is the one defined as inspection_interface in the undercloud.conf file. If you have not set this parameter, the default interface for the undercloud is br-ctlplane . Note It is common to use the br-ctlplane interface for introspection. The IP address that you define as the local_ip in the undercloud.conf file is on the br-ctlplane interface. The IP address allocated to the Neutron DHCP namespace is the first address available in the IP range that you configure for the local_subnet in the undercloud.conf file. The first address in the IP range is the one that you define as dhcp_start in the configuration. For example, 192.168.10.10 is the IP address if you use the following configuration: Warning The IP address for the DHCP namespace is automatically allocated. In most cases, this address is the first address in the IP range. To verify that this is the case, run the following commands on the undercloud: Example dhcrelay configuration In the following examples, 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: dhcrelay version 4.2.x: dhcrelay version 4.3.x and later: 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 the provisioning network. Add the IP address of the leaf. Forward UDP and BOOTP requests to the introspection DHCP server that listens on IP address: 192.168.10.1 . Forward UDP and BOOTP requests to the provisioning DHCP server that listens on IP address 192.168.10.10 . Now that you have configured the provisioning network, you can configure the remaining overcloud leaf networks. 2.3. Designating a role for leaf nodes Each role in each leaf network requires a flavor and role assignment so that you can tag nodes into their respective leaf. Complete the following steps to create and assign each flavor to a role. Procedure Source the stackrc file: Retrieve a list of your nodes to identify their UUIDs: Assign each bare metal node that you want to designate for a role with a custom resource class that identifies its leaf network and role. Replace <ROLE> with a name that identifies the role. Replace <node> with the ID of the bare metal node. For example, enter the following command to tag a node with UUID 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 to the Compute role on Leaf2: Add each role to your overcloud-baremetal-deploy.yaml if it is not already defined. Define the resource class that you want to assign to the nodes for the role: Replace <role> with the name of the role. Replace <ROLE> with a name that identifies the role. In a baremetal-deploy.yaml file, define the resource class that you want to assign to the nodes for the role. Specify the role, profile, quantity, and associated networks that you are deploying: Replace <role> with the name of the role. Replace <ROLE> with a name that identifies the role. Note You must create a baremetal-deploy.yaml environment file for every stack you are deploying, in /home/stack/<stack> . 2.4. Mapping bare metal node ports to control plane network segments To enable deployment on a L3 routed network, you must configure the physical_network field on the bare metal ports. Each bare metal port is associated with a bare metal node in the OpenStack Bare Metal (ironic) service. The physical network names are the names that you include in the subnets option in the undercloud configuration. Note The physical network name of the subnet specified as local_subnet in the undercloud.conf file is always named ctlplane . Procedure Source the stackrc file: Check the bare metal nodes: Ensure that 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 that sets the physical_network property on the baremetal port fails. To set all nodes to manageable state, run the following command: Check which baremetal ports are associated with which baremetal node: 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 . Because 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: Introspect the nodes before you deploy the overcloud. Include the --all-manageable and --provide options to set the nodes as available for deployment: 2.5. Adding a new leaf to a spine-leaf provisioning network When increasing network capacity which can include adding new physical sites, you might need to add a new leaf and a corresponding subnet to your Red Hat OpenStack Platform spine-leaf provisioning network. When provisioning a leaf on the overcloud, the corresponding undercloud leaf is used. Prerequisites Your RHOSP deployment uses a spine-leaf network topology. Procedure Log in to the undercloud host as the stack user. Source the stackrc undercloud credentials file: In the /home/stack/undercloud.conf file, do the following: Locate the subnets parameter, and add a new subnet for the leaf that you are adding. A subnet represents an L2 segment in the routed spine and leaf: Example In this example, a new subnet ( leaf3 ) is added for the new leaf ( leaf3 ): Create a section for the subnet that you added. Example In this example, the section [leaf3] is added for the new subnet ( leaf3 ): Save the undercloud.conf file. Reinstall your undercloud: Additional resources Adding a new leaf to a spine-leaf deployment
[stack@director ~]USD cp /usr/share/python-tripleoclient/undercloud.conf.sample ~/undercloud.conf local_ip = 192.168.10.1/24 undercloud_public_host = 10.1.1.1 undercloud_admin_host = 192.168.10.2 local_interface = eth1 enable_routed_networks = true subnets = leaf0,leaf1,leaf2 local_subnet = leaf0 undercloud_nameservers = 10.11.5.19,10.11.5.20 [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 [stack@director ~]USD openstack undercloud install [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 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 | +-------+--------+ sudo dhcrelay -d --no-pid 192.168.10.10 192.168.10.1 -i eth0 -i eth1 -i eth2 -i eth3 sudo dhcrelay -d --no-pid 192.168.10.10 192.168.10.1 -iu eth0 -id eth1 -id eth2 -id eth3 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 ! [stack@director ~]USD source ~/stackrc (undercloud)USD openstack baremetal node list openstack baremetal node set --resource-class baremetal.<ROLE> <node> (undercloud)USD openstack baremetal node set --resource-class baremetal.COMPUTE-LEAF2 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13 - name: <role> count: 1 defaults: resource_class: baremetal.<ROLE> - name: <role> count: 1 hostname_format: <role>-%index% ansible_playbooks: - playbook: bm-deploy-playbook.yaml defaults: resource_class: baremetal.<ROLE> profile: control networks: - network: external subnet: external_subnet - network: internal_api subnet: internal_api_subnet01 - network: storage subnet: storage_subnet01 - network: storage_mgmt subnet: storage_mgmt_subnet01 - network: tenant subnet: tenant_subnet01 network_config: template: templates/multiple_nics/multiple_nics_dvr.j2 default_route_network: - external source ~/stackrc openstack baremetal node list for node in USD(openstack baremetal node list -f value -c Name); do openstack baremetal node manage USDnode --wait; done openstack baremetal port list --node <node-uuid> 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 overcloud node introspect --all-manageable --provide source ~/stackrc subnets = leaf0,leaf1,leaf2,leaf3 [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 [leaf3] cidr = 192.168.13.0/24 dhcp_start = 192.168.13.10 dhcp_end = 192.168.13.90 inspection_iprange = 192.168.13.100,192.168.13.190 gateway = 192.168.13.1 masquerade = False openstack undercloud install