Bug 1286478

Summary:	LIBREPO prefers IPv6 over a private mirror
Product:	[Fedora] Fedora	Reporter:	Scott K Logan <logans>
Component:	librepo	Assignee:	Tomas Mlcoch <tmlcoch>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	22	CC:	jmracek, jsilhan, mluscon, packaging-team-maint, pnemade, tmlcoch, vmukhame
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-04 03:16:12 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 Scott K Logan 2015-11-29 22:15:42 UTC

Description of problem:
When DNF chooses a mirror, it selects IPv6 where it should *always* prefer a private mirror if available.

Version-Release number of selected component (if applicable): 1.1.3-1.fc22

How reproducible: 100%

Steps to Reproduce:
1. Start from a location where a private mirror should be used
2. Clean DNF cache
3. Use iptraf-ng or wireshark to monitor network activity
4. run dnf makecache

Actual results:
DNF uses IPv6 mirrors instead of the private mirror it got from the metalink.

Expected results:
Relevant DNF preferences should be:
1. Private IPv6
2. Private IPv4
3. Public IPv6
4. Public IPv4

Additional info:
I have verified that the private mirror shows up correctly in the metalink/mirrorlist. If I force DNF to IPv4 using the "-4" switch, DNF correctly uses the private mirror.

I have also observed this using f21's 0.6.4-7.fc21.

Comment 1 Jaroslav Mracek 2015-11-30 12:24:16 UTC

Librepo is responsible for mirror chose.

Comment 2 Scott K Logan 2015-12-14 06:48:26 UTC

Thomas -

Any initial thoughts on this bug? It is making our on-campus private mirror practically useless, as-is.

--scott

Comment 3 Scott K Logan 2016-04-04 03:16:12 UTC

This is probably caused by mirrormanager not knowing what the IPv4 address of the client is when it is hit via IPv6, and that IPv6 address not belonging to the suggested IP blocks for the private mirror.

In any case, I don't seen anything that could be done short of always hitting mirrormanager through IPv4.

I doubt there will be any ambition to change the existing behavior. Now that I have an understanding of what was causing this, I can work around it. I'll just close this out then.

Thanks,

--scott