Configure multiple DHCP ranges using Subnet resources

To facilitate multi-rack and other types of distributed bare metal datacenter topologies, the dnsmasq DHCP server used for host provisioning in Container Cloud supports working with multiple L2 segments through network routers that support DHCP relay.


Networks used for hosts provisioning of a managed cluster must have routes to the PXE network (when a dedicated PXE network is configured) or to the combined PXE/management network of the management cluster. This configuration enables hosts to have access to the management cluster services that are used during host provisioning.

To configure DHCP ranges for dnsmasq, create the Subnet objects tagged with the ipam/SVC-dhcp-range label while setting up subnets for a managed cluster using CLI.

For every dhcp-range record, Container Cloud also configures the dhcp-option record to pass the default route through the default gateway from the corresponding subnet to all hosts that obtain addresses from that DHCP range. You can also specify DNS server addresses for servers that boot over PXE. They will be configured by Container Cloud using another dhcp-option record.


  • The Subnet objects for DHCP ranges should not reference any specific cluster, as DHCP server configuration is only applicable to the management or regional cluster. The label that specifies the region will be used to determine where to apply the DHCP ranges from the given Subnet object. The Cluster reference will be ignored.

  • The baremetal-operator chart allows using multiple DHCP ranges in the dnsmasq.conf file. The chart iterates over a list of the dhcp-range parameters from its values and adds all items from the list to the dnsmasq configuration.

  • The baremetal-operator chart allows using single DHCP range for backwards compatibility. By default, the KAAS_BM_BM_DHCP_RANGE environment variable is still used to define the DHCP range for a management or regional cluster nodes during provisioning.

Override the default dnsmasq settings

The dnsmasq configuration options dhcp-option=3 and dhcp-option=6 are absent in the default configuration. So, by default, dnsmasq will send the DNS server and default route to DHCP clients as defined in the dnsmasq official documentation:

  • The netmask and broadcast address are the same as on the host running dnsmasq.

  • The DNS server and default route are set to the address of the host running dnsmasq.

  • If the domain name option is set, this name is sent to DHCP clients.

If such default behavior is not desirable during deployment of managed clusters:

  1. Open the management cluster spec for editing.

  2. In the baremetal-operator release values, remove the dnsmasq.dhcp_range parameter:

    - helmReleases:
      - name: baremetal-operator
  3. Set the desired DHCP ranges and options using the Subnet objects as described in Configure DHCP ranges for dnsmasq.

Configure DHCP ranges for dnsmasq

  1. Create the Subnet objects tagged with the ipam/SVC-dhcp-range label.

    To create the Subnet objects, refer to Create subnets.

    Use the following Subnet object example to specify DHCP ranges and DHCP options to pass the default route and DNS server addresses:

    apiVersion: ""
    kind: Subnet
      name: mgmt-dhcp-range
      namespace: default
        ipam/SVC-dhcp-range: "" baremetal region-one

    After creating the above Subnet object, the following dnsmasq parameters will be set using the baremetal-operator Helm chart:

    The dnsmasq parameters composed from the Subnet object




    DHCP range is set according to the cidr and includeRanges parameters of the Subnet object. The mgmt-dhcp-range-0 tag is formed from the Subnet object name and address range index within the Subnet object.


    The default router option is set according to the gateway parameter of the Subnet object. The tag is the same as in the dhcp-range parameter.


    Optional, available when the nameservers parameter is set in the Subnet object. The DNS server option is set according to the nameservers parameter of the Subnet object. The tag is the same as in the dhcp-range parameter.

  2. Verify that the changes are applied to dnsmasq.conf:

    kubectl --kubeconfig <pathToMgmtOrRegionalClusterKubeconfig> \
    -n kaas get cm dnsmasq-config -ojson| jq -r '.data."dnsmasq.conf"'

Configure DHCP relay on ToR switches

For servers to access the DHCP server across the L2 segment boundaries, for example, from another rack with a different VLAN for PXE network, you must configure DHCP relay service on the border switch of the segment. For example, on a top-of-rack (ToR) or leaf (distribution) switch, depending on the data center network topology.

In Container Cloud, the dnsmasq server listens on the PXE interface of the management cluster node.

To configure DHCP relay, you need to specify the address(es) of a DHCP helper or the server that handles DHCP requests.

Depending on the PXE network setup, select from the following options:

  • If the PXE network is combined with the management network, identify LCM addresses of the management cluster nodes:

    kubectl -n default get lcmmachine -o wide

    In the output, select the addresses from the INTERNALIP column to use as the DHCP helper addresses.

  • If you use a dedicated PXE network, identify the addresses assigned to your nodes using the corresponding IpamHost objects:

    kubectl -n default get ipamhost -o yaml

    In status.netconfigV2 of each management cluster host, obtain the interface name used for PXE network and collect associated addresses to use as the DHCP helper addresses. For example:

            dhcp4: false
            dhcp6: false
            - ens3

    In this example, k8s-pxe is the PXE interface name and is the address to use as one of the DHCP helper addresses.