Bug 2030487

Summary: Satellite fails to assign IPv6-only NIC as primary, sets any other NIC with an IPv4 as primary instead
Product: Red Hat Satellite Reporter: Pablo Hess <phess>
Component: RegistrationAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED WONTFIX QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: high Docs Contact:
Priority: unspecified    
Version: 6.10.1CC: inecas, lstejska, lzap, myoder, rlavi, sshtein, swadeley, wpinheir
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-02-07 18:16:21 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Pablo Hess 2021-12-08 22:40:02 UTC
Description of problem:
When registering a host that has 3 NICs (eth0, eth1, eth2) where eth0 is IPv6-only and eth1,eth2 have neither IPv4 nor IPv6 addresses, Satellite selects an IP-less NIC (eth1 during my tests) as primary instead of selecting the only NIC that has an IP address (eth0 with an IPv6 address).

In a more schematic form:

== TEST HOST:
eth0: nice ULA-class IPv6 address; no IPv4 address.
eth1: no IP addresses.
eth2: no IP addresses.

Result: Satellite chooses eth1 as the primary interface.


== SECOND TEST:
eth0: nice ULA-class IPv6 address; no IPv4 address.
eth1: no IP addresses.
eth2: no IPv6 address; IPv4 manually added as 192.168.111.222/24. (note: Satellite does not know the 192.168.111.0/24 subnet.)

Result: Satellite chooses eth2 as the primary interface.



Note that this happens despite Satellite knowing the IPv6 subnet as expected:
* the IPv6 subnet used by the test host exists as a Subnet object on Satellite and is properly configured,
* Satellite itself has an IPv6 address on the same IPv6 subnet,
* Satellite can resolve the test host's name to its IPv6 address only, and can correctly reverse-resolve that IPv6 to the hostname.



Version-Release number of selected component (if applicable):
Satellite 6.9.7 (foreman-2.3.1.25-2.el7sat.noarch)
Satellite 6.10.1 (foreman-2.5.2.17-2.el7sat.noarch)

How reproducible:
100% of the times when using the Register Host method.


Steps to Reproduce:
1. Create IPv6 subnet on Satellite named subnet_ipv6, link it to a domain named example.ipv6.
2. Create on Satellite a hostgroup that links to the new IPv6 subnet and its respective domain and name it hg_ipv6.
3. Create host, give it no IPv4 address and an IPv6 address in the subnet_ipv6 subnet.
4. On the Satellite web UI, generate a Register script by navigating to Hosts > All Hosts > Register Host. Select the hg_ipv6 hostgroup and all other values appropriately.
5. Run the generated register command on the host.

Actual results:
Satellite will never select eth0 -- the NIC with only an IPv6 address -- as primary. In fact, Satellite will not record any IP addresses on eth0. Satellite will even choose eth1 (IP-less) over eth0. Satellite will even say eth1 is in subnet_ipv6 and is the interface whose FQDN matches the test host's name.

Alternatively, when eth1 or eth2 is given any IPv4 address -- even within a subnet Satellite does not know about -- Satellite will choose that NIC over eth0's perfectly functional IPv6 address.

Expected results:
Satellite would know to select the interface that actually works, even if it's an IPv6-only interface.

Additional info:
Output of some key Satellite and host configs will be uploaded to this BZ shortly.

Comment 5 Lukas Zapletal 2022-03-01 10:16:46 UTC
Hey, this is more about registration and/or fact parsing than provisioning. Moving on.

Comment 8 Leos Stejskal 2022-06-09 14:04:34 UTC
Hi,
as Lukas said this is indeed problem of the registration / fact parsing.
I'll try to take a look where exactly lies the problem.

Comment 9 Leos Stejskal 2022-06-15 07:31:38 UTC
Hi,
could you please upload facts generated by the subscription manager: `subscription-manager facts`

Comment 11 myoder 2022-07-07 23:56:34 UTC
Hi Leos,

Just uploaded the facts from one of the hypervisors registered to the Satellite.

Please note, customer had to switch to only ipv6 interfaces to get the hypervisor to register to Satellite correctly.  So these facts won't have any ipv4 addresses.

Comment 12 Leos Stejskal 2022-07-29 07:00:47 UTC
Created redmine issue https://projects.theforeman.org/issues/35292 from this bug

Comment 15 Brad Buckingham 2024-01-09 20:58:59 UTC
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Comment 16 Brad Buckingham 2024-02-07 18:16:21 UTC
Thank you for your interest in Red Hat Satellite. We have evaluated this request, and while we recognize that it is a valid request, we do not expect this to be implemented in the product in the foreseeable future. This is due to other priorities for the product, and not a reflection on the request itself. We are therefore closing this out as WONTFIX. If you have any concerns about this feel free to contact your Red Hat Account Team. Thank you.