#10835 IPv6 issues with pagure.io (CI fetch failed)
Closed: Invalid by andyp. Opened by andyp.

According to @fabbione who manages the CI server, this might be due to an IPv6 issue on the pagure.io side. In the CI logs we see:
Caused by: hudson.plugins.git.GitException: Command "git fetch --tags --force --progress -- https://pagure.io/gfs2-utils.git +refs/heads/*:refs/remotes/origin/*" returned status code 128: stdout: stderr: fatal: unable to access 'https://pagure.io/gfs2-utils.git/': Operation timed out after 300032 milliseconds with 0 out of 0 bytes received

Some detail from IRC:

< fabbione> i can access the raw https socket over ipv6
< fabbione> # telnet pagure.io 443
< fabbione> Trying 2620:52:3:1:dead:beef:cafe:fed8...
< fabbione> Connected to pagure.io.
< fabbione> Escape character is '^]'.
< fabbione> AndyP: it works over IPv4, so I suspect it´s on the pagure side
< fabbione> it´s working randomly

So some investigation still needed to find the root cause I think, but let's investigate on both sides. Are there known IPv6 issues with pagure.io?


There aren't any known issues with ipv6 I can see. The usual issue is that somewhere between 'your ip' and ' pagure.io' is not routing ipv6 but is doing ipv4. This seems to happen a lot lately with the general excuse being that some in between routers 'ipv6' support was not as great as is advertised. The ipv6 routing tables are much bigger than the ipv4 ones and various older routers will 'forget' until banged on by their network operator :frowning:

Please attach a traceroute6 or mtr and timestamps so we can see if it is one of the routers we can yell at.

There aren't any known issues with ipv6 I can see. The usual issue is that somewhere between 'your ip' and ' pagure.io' is not routing ipv6 but is doing ipv4. This seems to happen a lot lately with the general excuse being that some in between routers 'ipv6' support was not as great as is advertised. The ipv6 routing tables are much bigger than the ipv4 ones and various older routers will 'forget' until banged on by their network operator :frowning:

Please attach a traceroute6 or mtr and timestamps so we can see if it is one of the routers we can yell at.

tracepath6 pagure.io

1?: [LOCALHOST] 0.008ms pmtu 1500
1: porco.fugedabout.it 0.082ms
1: porco.fugedabout.it 0.061ms
2: 2a01:4f9::a:4:a 0.653ms
3: core31.hel1.hetzner.com 78.644ms
4: juniper4.dc1.hel1.hetzner.com 0.510ms
5: ae53.edge1.Helsinki1.Level3.net 0.752ms asymm 6
6: no reply
7: 2001:1900:2100::3932 126.259ms
8: 2620:52:3:fffe::2 132.436ms
9: 2620:52:3:fffd::2 125.998ms asymm 10
10: 2620:52:3:fffc::2 146.833ms
11: 2620:52:3:1:ffff:ffff:ffff:fffe 138.501ms
12: 2620:52:3:1:dead:beef:cafe:fed8 126.608ms !A
Resume: pmtu 1500

Host Loss% Snt Last Avg Best Wrst StDev
1. porco.fugedabout.it 33.3% 4 0.1 0.1 0.1 0.1 0.0
2. 2a01:4f9::a:4:a 0.0% 4 0.4 0.8 0.4 1.8 0.7
3. core32.hel1.hetzner.com 0.0% 4 8.4 4.2 0.4 8.4 4.3
4. juniper4.dc1.hel1.hetzner.com 0.0% 4 0.4 0.5 0.4 0.6 0.1
5. ae53.edge1.Helsinki1.Level3.net 0.0% 3 0.8 0.8 0.7 0.8 0.0
6. lo-0-v6.ear3.Washington1.Level3.net 0.0% 3 119.5 119.6 119.5 119.6 0.0
7. 2001:1900:2100::3932 0.0% 3 125.9 125.9 125.9 126.0 0.0
8. 2620:52:3:fffe::2 0.0% 3 149.0 146.5 133.9 156.6 11.5
9. 2620:52:3:fffd::2 0.0% 3 125.9 125.9 125.9 125.9 0.0
10. 2620:52:3:fffc::2 0.0% 3 211.9 168.5 145.3 211.9 37.6
11. 2620:52:3:1:ffff:ffff:ffff:fffe 0.0% 3 134.8 190.0 130.8 304.3 99.0
12. 2620:52:3:1:dead:beef:cafe:fed8 0.0% 3 126.2 126.2 126.1 126.2 0.0

Hi @smooge Andy was a tad too fast to file the ticket.. didn´t have enough time to dig on our side. It appears to be an issue on our side tho.

Host Loss% Snt Last Avg Best Wrst StDev
1. porco.fugedabout.it 97.9% 96 0.1 0.1 0.1 0.2 0.0
2. 2a01:4f9::a:4:a 0.0% 96 0.6 1.1 0.3 34.6 4.0

The interesting bit now is figuring out why localhost is dropping 98% of Ipv6 packets...

I must've had too much coffee this morning. Closing the issue as it's not a Fedora infra problem.

Metadata Update from @andyp:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

@smooge the problem is our side, you can close this ticket.

Thanks
Fabio

Metadata