Greetings,
I can’t access to us.images.linuxcontainers.org because a timeout from my home network. I tried it on an other network and it works.
Am I blacklisted ?
Can you access uk.images.linuxcontainers.org?
There was a data centre move affecting the US mirror over the weekend. I’m not sure if the IP has changed or not though.
I can access the US mirror from my home connection so seems to be running now.
Can you ping the address?
- Can you access
uk.images.linuxcontainers.org?
yes - Can you ping the address?
yes
64 bytes from gible.canonical.com (91.189.91.21): icmp_seq=1 ttl=52 time=96.8 ms
64 bytes from gible.canonical.com (2001:67c:1562::41): icmp_seq=1 ttl=51 time=88.3 ms
Same issue for images.linuxcontainers.org
What specific error do you actually get?
Oh a timeout, is that on port 80?
Can you try telnetting to port 80 and 443 on the IPv4 and IPv6 address respectively please and see if any of those connect.
https protocol so 443
So IPv6 doesn’t work?
yes it works for IPv6 on telnet.
I’m confused, you say you have a network timeout, but it works on all protocols and IPs?
If you’re getting redirected then you should these the IPs of the images.linuxcontainers.org too please (these look like the cumulative set of uk.images.linuxcontainers.org and us.images.linuxcontainers.org)
images.linuxcontainers.org is an alias for canonical.images.linuxcontainers.org.
canonical.images.linuxcontainers.org has address 91.189.88.37
canonical.images.linuxcontainers.org has address 91.189.91.21
canonical.images.linuxcontainers.org has IPv6 address 2001:67c:1560:8001::21
canonical.images.linuxcontainers.org has IPv6 address 2001:67c:1562::41
The timeout is displayed from my browser but on my LXD host I can’t launch new CT because it’s still on “Creating CTNAME”
All ip matches.
1 Like
So could it be that its not hanging on network, but for some other reason?
Can you enable debug logging and check:
sudo snap set lxd daemon.debug=true; sudo systemctl reload snap.lxd.daemon
sudo tail -f /var/snap/lxd/common/lxd/logs/lxd.log
Did some checking from here, I’m not seeing MTU issues, 1500 on v4/v6 seems functional as does straight http/https access.
Would be nice if you could track down the particular download which is hanging for you so we can take a closer look.
I would try later on a testing host not on my production host.
My local network is on MTU 9000.
I’m not seeing any other report right now but when the server came back up last night after being relocated to a new datacenter, we did have weird routing issues with IPv6 routing. I had the network folks sort it out and it’s looking good from here but there may still be something wrong from your location.
Would certainly be great if you could figure out a file that causes the issue so you can try to curl it over IPv4 or IPv6, then once we know if it’s just one protocol or the other, we can start looking at routes and see if they make sense.
Tracerts
I tried to curl us.images.linuxcontainers.org but it doesn’t respond like when I launch a CT.
Hmm and https://images.linuxcontainers.org sends you to us.images.linuxcontainers.org?
Since you’re coming from France I’d have expected you to be sent to uk.images.linuxcontainers.org instead.