Bug 1286478 - LIBREPO prefers IPv6 over a private mirror
LIBREPO prefers IPv6 over a private mirror
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: librepo (Show other bugs)
22
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Tomas Mlcoch
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-29 17:15 EST by Scott K Logan
Modified: 2016-04-03 23:16 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-03 23:16:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Scott K Logan 2015-11-29 17:15:42 EST
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 07:24:16 EST
Librepo is responsible for mirror chose.
Comment 2 Scott K Logan 2015-12-14 01:48:26 EST
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-03 23:16:12 EDT
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

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