Bug 1841135 - Increase default provisioning DHCP range
Summary: Increase default provisioning DHCP range
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Bare Metal Hardware Provisioning
Version: 4.4
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.6.0
Assignee: Beth White
QA Contact: Eldar Weiss
Depends On:
Blocks: dit
TreeView+ depends on / blocked
Reported: 2020-05-28 12:59 UTC by Dave Wilson
Modified: 2020-10-27 16:02 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
The default DHCP range for the provisioning network was increased to include the remainder of the subnet to better support large deployments. The range is still configurable if users would like to use less of the subnet for DHCP.
Clone Of:
Last Closed: 2020-10-27 16:01:56 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github openshift installer pull 3768 0 None closed Bug 1841135: baremetal: increase default provisioning dhcp range 2020-11-30 08:31:51 UTC
Red Hat Product Errata RHBA-2020:4196 0 None None None 2020-10-27 16:02:36 UTC

Description Dave Wilson 2020-05-28 12:59:38 UTC
Description of problem: default provisioning DHCP range is too low for large scale BM deploys. Can we set it at .10 to $subnet_max instead of .10 to .100?

Version-Release number of selected component (if applicable): 4.4

How reproducible: 100%

Steps to Reproduce:
1. Deploy > 90 BM nodes

Actual results: Node will not get DHCP offer on pxe due to 90 max leases

Expected results: Node pxe's and provisions

Additional info:

Comment 3 Stephen Benjamin 2020-06-02 16:26:24 UTC
The DHCP range is configurable to be as large as a user likes. There's no limitation there. A user can set provisioningDHCPRange in the install-platform, so I think this is much lower priority than currently indicated.

In general we expect the provisioning subnet to be dedicated and owned by the cluster, so updating the default to be $SUBNET_MAX may be a reasonable thing to do. It needs a bit more discussion, but I think we can leave this open to have a look at it in the 4.6 cycle.

I do not think we should backport it, as it would be quite surprising if you're used to deploying 4.4 and made assumptions about the provisioning network that suddenly become untrue in a z-Stream.

Comment 6 Eldar Weiss 2020-07-15 15:09:07 UTC
Description of problem: default provisioning DHCP range is too low for large scale BM deploys. 

Version-Release number the fix was verified on: 4.6.0-0.nightly-2020-07-15-065024.

Steps to verify fix:
1. Run this on the provisionhost for both IPV4 and IPV6
oc get provisioning -o yaml | grep provisioningDHCPRange
Actual results:
IPV4 example:
        f:provisioningDHCPRange: {}
IPV6 example:
        f:provisioningDHCPRange: {}
        provisioningDHCPRange:     fd00:1101::a,fd00:1101::ffff:ffff:ffff:fffe 
Expected results: wide range for IP addresses, as seen above.
Additional info:

Comment 8 errata-xmlrpc 2020-10-27 16:01:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (OpenShift Container Platform 4.6 GA Images), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.