Network Configuration¶

Configuring an IP Subnet¶

An IP subnet may be configured by setting the cidr attribute for a network to the CIDR representation of the subnet.

To configure a network called example with the 10.0.0.0/24 IP subnet:

example_cidr: 10.0.0.0/24

Configuring an IP Gateway¶

An IP gateway may be configured by setting the gateway attribute for a network to the IP address of the gateway.

To configure a network called example with a gateway at 10.0.0.1:

example_gateway: 10.0.0.1

This gateway will be configured on all hosts to which the network is mapped. Note that configuring multiple IP gateways on a single host will lead to unpredictable results.

Configuring an API Virtual IP Address¶

A virtual IP (VIP) address may be configured for use by Kolla Ansible on the internal and external networks, on which the API services will be exposed. The variable will be passed through to the kolla_internal_vip_address or kolla_external_vip_address Kolla Ansible variable.

To configure a network called example with a VIP at 10.0.0.2:

example_vip_address: 10.0.0.2

Configuring an API Fully Qualified Domain Name¶

A Fully Qualified Domain Name (FQDN) may be configured for use by Kolla Ansible on the internal and external networks, on which the API services will be exposed. The variable will be passed through to the kolla_internal_fqdn or kolla_external_fqdn Kolla Ansible variable.

To configure a network called example with an FQDN at api.example.com:

example_fqdn: api.example.com

Configuring Static IP Routes¶

Static IP routes may be configured by setting the routes attribute for a network to a list of routes.

To configure a network called example with a single IP route to the 10.1.0.0/24 subnet via 10.0.0.1:

example_routes:
  - cidr: 10.1.0.0/24
    gateway: 10.0.0.1

These routes will be configured on all hosts to which the network is mapped.

Configuring a VLAN¶

A VLAN network may be configured by setting the vlan attribute for a network to the ID of the VLAN.

To configure a network called example with VLAN ID 123:

example_vlan: 123

Configuring Dynamic IP Address Allocation¶

To configure a network called example with the 10.0.0.0/24 IP subnet and an allocation pool spanning from 10.0.0.4 to 10.0.0.254:

example_cidr: 10.0.0.0/24
example_allocation_pool_start: 10.0.0.4
example_allocation_pool_end: 10.0.0.254

Configuring Static IP Address Allocation¶

To configure a network called example with statically allocated IP addresses for hosts host1 and host2:

example_ips:
  host1: 10.0.0.1
  host2: 10.0.0.2

Advanced: Policy-Based Routing¶

Policy-based routing can be useful in complex networking environments, particularly where asymmetric routes exist, and strict reverse path filtering is enabled.

network_route_tables:
  - name: exampleroutetable
    id: 1

example_rules:
  - from 10.1.0.0/24 table exampleroutetable

example_routes:
  - cidr: 0.0.0.0/0
    gateway 10.1.0.1
    table: exampleroutetable
  - cidr: 10.1.0.0/24
    table: exampleroutetable

IP Addresses¶

An interface will be assigned an IP address if the associated network has a cidr attribute. The IP address will be assigned from the range defined by the allocation_pool_start and allocation_pool_end attributes, if one has not been statically assigned in network-allocation.yml.

Configuring Ethernet Interfaces¶

An Ethernet interface may be configured by setting the interface attribute for a network to the name of the Ethernet interface.

To configure a network called example with an Ethernet interface on eth0:

example_interface: eth0

Configuring Bridge Interfaces¶

A Linux bridge interface may be configured by setting the interface attribute of a network to the name of the bridge interface, and the bridge_ports attribute to a list of interfaces which will be added as member ports on the bridge.

To configure a network called example with a bridge interface on breth1, and a single port eth1:

example_interface: breth1
example_bridge_ports:
  - eth1

Bridge member ports may be Ethernet interfaces, bond interfaces, or VLAN interfaces. In the case of bond interfaces, the bond must be configured separately in addition to the bridge, as a different named network. In the case of VLAN interfaces, the underlying Ethernet interface must be configured separately in addition to the bridge, as a different named network.

Configuring Bond Interfaces¶

A bonded interface may be configured by setting the interface attribute of a network to the name of the bond’s master interface, and the bond_slaves attribute to a list of interfaces which will be added as slaves to the master.

To configure a network called example with a bond with master interface bond0 and two slaves eth0 and eth1:

example_interface: bond0
example_bond_slaves:
  - eth0
  - eth1

Optionally, the bond mode and MII monitoring interval may also be configured:

example_bond_mode: 802.3ad
example_bond_miimon: 100

Bond slaves may be Ethernet interfaces, or VLAN interfaces. In the case of VLAN interfaces, underlying Ethernet interface must be configured separately in addition to the bond, as a different named network.

Configuring VLAN Interfaces¶

A VLAN interface may be configured by setting the interface attribute of a network to the name of the VLAN interface. The interface name must be of the form <parent interface>.<VLAN ID>.

To configure a network called example with a VLAN interface with a parent interface of eth2 for VLAN 123:

example_interface: eth2.123

To keep the configuration DRY, reference the network’s vlan attribute:

example_interface: "eth2.{{ example_vlan }}"

Ethernet interfaces, bridges, and bond master interfaces may all be parents to a VLAN interface.

Configuring Network Roles¶

To configure network roles in a system with two networks, example1 and example2:

admin_oc_net_name: example1
oob_oc_net_name: example1
provision_oc_net_name: example1
oob_wl_net_name: example1
provision_wl_net_name: example2
internal_net_name: example2
public_net_name: example2
tunnel_net_name: example2
external_net_name: example2
storage_net_name: example2
storage_mgmt_net_name: example2
ceph_storage_net_name: example2
ceph_storage_mgmt_net_name: example2
swift_storage_net_name: example2
swift_replication_net_name: example2
inspection_net_name: example2
cleaning_net_name: example2

Overcloud Admin Network¶

The admin network is intended to be used for remote access to the overcloud hosts. Kayobe will use the address assigned to the host on this network as the ansible_host when executing playbooks. It is therefore a necessary requirement to configure this network.

By default Kayobe will use the overcloud provisioning network as the admin network. It is, however, possible to configure a separate network. To do so, you should override admin_oc_net_name in your networking configuration.

If a separate network is configured, the following requirements should be taken into consideration:

• The admin network must be configured to use the same physical network interface as the provisioning network. This is because the PXE MAC address is used to lookup the interface for the cloud-init network configuration that occurs during bifrost provisioning of the overcloud.
• If the admin network is configured as a tagged VLAN, you must configure Kayobe to upgrade cloud-init. This is a temporary workaround for a bug in the current version of cloud-init shipped with CentOS 7.5. Please see Workaround VLAN cloud-init issue for more details.

Overcloud Provisioning Network¶

If using a seed to inspect the bare metal overcloud hosts, it is necessary to define a DHCP allocation pool for the seed’s ironic inspector DHCP server using the inspection_allocation_pool_start and inspection_allocation_pool_end attributes of the overcloud provisioning network.

To configure a network called example with an inspection allocation pool:

example_inspection_allocation_pool_start: 10.0.0.128
example_inspection_allocation_pool_end: 10.0.0.254

Workload Cleaning Network¶

A separate cleaning network, which is used by the overcloud to clean baremetal workload (compute) hosts, may optionally be specified. Otherwise, the Workload Provisoning network is used. It is necessary to define an IP allocation pool for neutron using the neutron_allocation_pool_start and neutron_allocation_pool_end attributes of the cleaning network. This controls the IP addresses that are assigned to workload hosts during cleaning.

To configure a network called example with a neutron provisioning allocation pool:

example_neutron_allocation_pool_start: 10.0.1.128
example_neutron_allocation_pool_end: 10.0.1.195

Workload Provisioning Network¶

If using the overcloud to provision bare metal workload (compute) hosts, it is necessary to define an IP allocation pool for the overcloud’s neutron provisioning network using the neutron_allocation_pool_start and neutron_allocation_pool_end attributes of the workload provisioning network.

To configure a network called example with a neutron provisioning allocation pool:

example_neutron_allocation_pool_start: 10.0.1.128
example_neutron_allocation_pool_end: 10.0.1.195

Workload Inspection Network¶

If using the overcloud to inspect bare metal workload (compute) hosts, it is necessary to define a DHCP allocation pool for the overcloud’s ironic inspector DHCP server using the inspection_allocation_pool_start and inspection_allocation_pool_end attributes of the workload provisioning network.

To configure a network called example with an inspection allocation pool:

example_inspection_allocation_pool_start: 10.0.1.196
example_inspection_allocation_pool_end: 10.0.1.254

Seed¶

By default, the seed is attached to the following networks:

• overcloud admin network
• overcloud out-of-band network
• overcloud provisioning network

This list may be extended by setting seed_extra_network_interfaces to a list of names of additional networks to attach. Alternatively, the list may be completely overridden by setting seed_network_interfaces. These variables are found in ${KAYOBE_CONFIG_PATH}/seed.yml.

Seed Hypervisor¶

By default, the seed hypervisor is attached to the same networks as the seed.

This list may be extended by setting seed_hypervisor_extra_network_interfaces to a list of names of additional networks to attach. Alternatively, the list may be completely overridden by setting seed_hypervisor_network_interfaces. These variables are found in ${KAYOBE_CONFIG_PATH}/seed-hypervisor.yml.

Controllers¶

By default, controllers are attached to the following networks:

• overcloud admin network
• workload (compute) out-of-band network
• workload (compute) provisioning network
• workload (compute) inspection network
• workload (compute) cleaning network
• internal network
• storage network

In addition, if the controllers are also in the network group, they are attached to the following networks:

• public network
• external network
• tunnel network

This list may be extended by setting controller_extra_network_interfaces to a list of names of additional networks to attach. Alternatively, the list may be completely overridden by setting controller_network_interfaces. These variables are found in ${KAYOBE_CONFIG_PATH}/controllers.yml.

Monitoring Hosts¶

By default, the monitoring hosts are attached to the same networks as the controllers when they are in the controllers group. If the monitoring hosts are not in the controllers group, they are attached to the following networks by default:

• overcloud admin network
• internal network
• public network

This list may be extended by setting monitoring_extra_network_interfaces to a list of names of additional networks to attach. Alternatively, the list may be completely overridden by setting monitoring_network_interfaces. These variables are found in ${KAYOBE_CONFIG_PATH}/monitoring.yml.

Storage Hosts¶

By default, the storage hosts are attached to the following networks:

• overcloud admin network
• internal network
• storage network
• storage management network

In addition, if Ceph or Swift is enabled, they can also be attached to the Ceph and Swift mangagment and replication networks.

Virtualised Compute Hosts¶

By default, virtualised compute hosts are attached to the following networks:

• overcloud admin network
• internal network
• storage network
• tunnel network

This list may be extended by setting compute_extra_network_interfaces to a list of names of additional networks to attach. Alternatively, the list may be completely overridden by setting compute_network_interfaces. These variables are found in ${KAYOBE_CONFIG_PATH}/compute.yml.

Other Hosts¶

If additional hosts are managed by kayobe, the networks to which these hosts are attached may be defined in a host or group variables file. See Control Plane Service Placement for further details.