Hello, We host a CentOS Mirror in EE https://mirror.cspacehostings.com/centos/ When performing updates for the last several months we are connected to a Mirror in Finland than our own mirror in EE, this has been observed also from our client machine and peers/ISP with whom we share the mirror servers optimization. Our Internal Infrastructure and Client downstream are Running CentOS 7.
# yum update Loaded plugins: fastestmirror, universal-hooks Loading mirror speeds from cached hostfile * base: ftp.funet.fi * epel: mirror.cspacehostings.com * extras: ftp.funet.fi * updates: ftp.funet.fi
We are in the same downstream/IP range, but it appears as if our mirror does not exist.
We host base/extras and update all of it and mirror shows up to date as well https://mirror-status.centos.org/#ee What is the algorithm and logic behind this redirection?
The logic is first to validate your mirror and then add it in the country list. Just had a look at the crawler logs and :
http://mirror.cspacehostings.com/centos/7.9.2009/nfv/x86_64/common/ - 500 read timeout ipv4 http://mirror.cspacehostings.com/centos/ going in timeout mirrors
So it seems that crawler has issue (but not always) to reach your server. From that node :
curl -o /dev/null --silent -w 'Establish Connection time : %{time_connect}s\nStart Transfer time: %{time_starttransfer}s\nTotal: %{time_total}s\n' http://mirror.cspacehostings.com/centos/7.9.2009/updates/x86_64/ Establish Connection time : 0.145s Start Transfer time: 14.810s Total: 14.810s
Can you investigate at your side eventually for slow response time for ip 8.43.84.240 (mirror-status.centos.org and the crawler public ip address)
Metadata Update from @arrfab: - Issue assigned to phsmoura - Issue tagged with: medium-gain, medium-trouble, mirror-linux
We were just revisiting tickets without feedback and gave this one a try :
curl -o /dev/null --silent -w 'Establish Connection time : %{time_connect}s\nStart Transfer time: %{time_starttransfer}s\nTotal: %{time_total}s\n' http://mirror.cspacehostings.com/centos/7.9.2009/updates/x86_64/ Establish Connection time : 0.147s Start Transfer time: 0.266s Total: 0.266s
So it seems something was updated as now it's all good and our mirror crawler could validate you mirror. We then tested that it's included in mirrorlists for your country and it's the case :
curl 'http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=updates&cc=ee' http://mirrors.xtom.ee/centos/7.9.2009/updates/x86_64/ http://mirror.cspacehostings.com/centos/7.9.2009/updates/x86_64/ http://ftp.funet.fi/pub/mirrors/centos.org/7.9.2009/updates/x86_64/ http://centos.mirror.far.fi/7.9.2009/updates/x86_64/ http://centos.koyanet.lv/centos/7.9.2009/updates/x86_64/ http://centos.linux.edu.lv/7.9.2009/updates/x86_64/ http://mirror.vpsnet.com/centos/7.9.2009/updates/x86_64/ http://mirror.docker.ru/centos/7.9.2009/updates/x86_64/ http://mirror.corbina.net/pub/Linux/centos/7.9.2009/updates/x86_64/ http://ftp.nsc.ru/pub/centos/7.9.2009/updates/x86_64/
So it seems all resolved. Closing now
Metadata Update from @arrfab: - Issue close_status updated to: Fixed with Explanation - Issue status updated to: Closed (was: Open)
Hello, Thanks for the revert, I tried running the script locally but seems to resolve funet.fi on our list.
I had setup a latency monitoring, results are during different times of the day the latency varies from 111seconds to 230seconds. At times timing out on the flexential - telia backbone during interconnection in either direction. But it could be some firewall on 8.43.84.240 filtering our requests. On our end I have tweaked HTTP to increased timeout and keepalive requests. No FW here.
$ traceroute 8.43.84.240 traceroute to 8.43.84.240 (8.43.84.240), 30 hops max, 60 byte packets 1 45.142.100.33 (45.142.100.33) 0.319 ms 0.302 ms 0.279 ms 2 be5164.nr01.b069785-0.tll01.atlas.cogentco.com (149.6.188.105) 1.598 ms 1.575 ms 1.552 ms 3 be2825.rcr51.tll01.atlas.cogentco.com (154.25.10.98) 0.639 ms 0.634 ms 0.632 ms 4 be3740.ccr21.sto03.atlas.cogentco.com (154.54.60.190) 6.412 ms 6.566 ms 6.388 ms 5 be3376.ccr21.sto01.atlas.cogentco.com (130.117.50.226) 6.740 ms be3377.ccr21.sto01.atlas.cogentco.com (154.54.36.90) 6.687 ms be3376.ccr21.sto01.atlas.cogentco.com (130.117.50.226) 6.955 ms 6 telia.sto01.atlas.cogentco.com (130.117.14.234) 6.416 ms 6.747 ms 6.709 ms 7 s-bb2-link.ip.twelve99.net (62.115.139.186) 6.880 ms 6.975 ms 7.025 ms 8 kbn-bb2-link.ip.twelve99.net (62.115.139.173) 17.361 ms 17.330 ms 19.308 ms 9 nyk-bb2-link.ip.twelve99.net (80.91.254.91) 98.518 ms 98.912 ms 98.729 ms 10 nyk-b2-link.ip.twelve99.net (62.115.137.99) 98.428 ms 98.638 ms 98.320 ms 11 viawest-ic350578-nyk-b2.ip.twelve99-cust.net (62.115.181.147) 96.527 ms 96.497 ms 96.892 ms 12 be22.bbrt02.ewr01.flexential.net (148.66.237.192) 115.059 ms 115.029 ms 114.852 ms 13 be210.bbrt02.iad10.flexential.net (148.66.239.36) 114.890 ms 114.879 ms 114.974 ms 14 be10.bbrt01.iad10.flexential.net (148.66.239.22) 113.325 ms 112.951 ms 112.912 ms 15 be209.bbrt02.ral01.flexential.net (66.51.5.117) 115.420 ms 115.376 ms 115.345 ms 16 be32.crrt02.ral01.flexential.net (148.66.238.113) 115.090 ms 115.262 ms 115.122 ms 17 128.136.224.140 (128.136.224.140) 134.630 ms 134.610 ms 134.578 ms 18 8.43.84.1 (8.43.84.1) 152.069 ms 152.033 ms 152.004 ms 19 8.43.84.3 (8.43.84.3) 126.008 ms 125.979 ms 120.107 ms 20 8.43.84.4 (8.43.84.4) 132.908 ms 132.878 ms 132.848 ms 21 8.43.84.254 (8.43.84.254) 123.242 ms 119.240 ms 119.192 ms 22 ip-8-43-84-240.rdu2c.fabric8.io (8.43.84.240) 115.299 ms !X 115.295 ms !X 115.220 ms !X
Was wondering if there is a mirror probe in EU?
Metadata Update from @cspaceh: - Issue status updated to: Open (was: Closed)
Hello, After through optimization on the network and webserver we were able to resolve this successfully. Thank you for all the information provided. Hence closing the issue. :)
Metadata Update from @cspaceh: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.