Bug 1792493 - [ipi on baremetal] [4.3] DHCPv6 addresses break IP subnet check
Summary: [ipi on baremetal] [4.3] DHCPv6 addresses break IP subnet check
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Installer
Version: 4.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.3.z
Assignee: Stephen Benjamin
QA Contact: Victor Voronkov
URL:
Whiteboard:
Depends On: 1792467
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-17 17:41 UTC by Ben Nemec
Modified: 2020-02-25 06:18 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1792467
Environment:
Last Closed: 2020-02-25 06:17:59 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift baremetal-runtimecfg pull 43 0 None closed [release-4.3] Bug 1792493: Convert /128 addresses to /64 again 2020-03-12 09:13:14 UTC
Red Hat Product Errata RHBA-2020:0528 0 None None None 2020-02-25 06:18:15 UTC

Description Ben Nemec 2020-01-17 17:41:10 UTC
+++ This bug was initially created as a clone of Bug #1792467 +++

Description of problem: DHCPv6 addresses all have a /128 netmask, which breaks the check in baremetal-runtimecfg for whether an IP is in the same subnet as the VIP.  This causes deployments using IPv6 to fail when starting mdns-publisher because it doesn't know what address to listen on.

In the short term we will just assume /64 for IPv6 addresses, but eventually we need to look up the correct netmask and use that.

Comment 3 Victor Voronkov 2020-02-11 07:21:32 UTC
Verified on OCP 4.3.0-0.nightly-2020-02-03-115336-ipv6.1

Deployment of cluster with 3 masters and 0 workers succeeded, DHCPv6 addresses has /64 netmask

virsh net-dhcp-leases baremetal
 Expiry Time          MAC address        Protocol  IP address                Hostname        Client ID or DUID
-------------------------------------------------------------------------------------------------------------------
 2020-02-11 09:59:34  52:54:00:54:9c:63  ipv6      fd2e:6f44:5dd8:c956::124/64 provisionhost-0 00:03:00:01:52:54:00:54:9c:63
 2020-02-11 10:11:21  52:54:00:85:f1:4a  ipv6      fd2e:6f44:5dd8:c956::121/64 master-0        00:03:00:01:52:54:00:85:f1:4a
 2020-02-11 10:16:00  52:54:00:93:14:83  ipv6      fd2e:6f44:5dd8:c956::103/64 master-1        00:03:00:01:52:54:00:93:14:83
 2020-02-11 10:10:06  52:54:00:e2:f6:a0  ipv6      fd2e:6f44:5dd8:c956::13a/64 master-2        00:03:00:01:52:54:00:e2:f6:a0

Comment 5 errata-xmlrpc 2020-02-25 06:17:59 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, and where to find the updated
files, follow the link below.

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

https://access.redhat.com/errata/RHBA-2020:0528


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