Scaleway unstable IPv6
New on LowEndTalk? Please read our 'Community Rules' by clicking on it in the right menu!

Scaleway unstable IPv6

WebDudeWebDude Member
edited May 25 in Help

I've made sure that MLD is allowed in firewall configuration. Yet the IPv6 connectivity is really unstable. Does anyone know what might be causing it? UFW & Ubuntu is on the server, no special IPv6 configuration has been applied. Server type: 1-M

After some analysis, I think I've got nothing wrong with my configuration. Their network just seems exceptionally bad. Huge packet loss, complete loss of connectivity for long periods etc. And I mean like tens of minutes... Seems so bad, it's probably routing issue.

I'll log some more data, but so far it seems devastatingly bad. I mean, if you try using IPv6 you're just seriously shooting yourself in leg.

Btw. They didn't allow me to register to their forum, that's why this question is here.

Comments

  • ldarcyldarcy Member

    Open a ticket with Scaleway's support?
    I had quite bad experience with IPv6 with them as well, opened a ticket and they said they are about to revamp ipv6 network so it is going to be better. I moved on so not sure what is the status of that project.

  • WebDudeWebDude Member
    edited May 26

    After monitoring the issue in details with automated monitoring for around a week and after analyzing logs. It seems kind of route flapping. Connectivity between two locations is ok for a few hours, and then can go totally dead for 4 hours and so on.

    I guess it's the classic situation, where anyone who cares, refuses to use the IPv6 because it works so darn badly (at ScaleWay) and because of that, they don't bother fixing it.

    I just disabled IPv6 for the server, because it caused all kind of trouble. Better having none than something which is totally unusable.

    There are routing loops, hop limit exceeded and stuff.

    I've got bunch of IPv6 enabled servers in other data centers around Europe and I haven't seen this ridiculously bad problems ever so far. Usually it's like if they're having serious network issues they first fix IPv4 and IPv6 comes later. And that might cause some networking issues, but that's something which happens very rarely. Not even yearly.

    Edit: Just opened a ticket with IP addresses, AS numbers, some logs and stuff. Let's see what they say.

  • ClouviderClouvider Member, Provider

    Mtr ?

    If it’s not production I’d just in case drop the firewall entirely to make sure this is not on your end.

    Clouvider Leading UK Cloud Hosting solution provider || UK Dedicated Servers Sale || Tasty KVM Slices || Latest LET Offer

    Web hosting in Cloud | SSD & SAS True Cloud VPS on OnApp | Private Cloud | Dedicated Servers | Colocation | Managed Services

  • classyclassy Member

    Amsterdam or Paris?

    Are you a UI/UX designer or web/app developer? Join our Discord: https://discord.gg/uJPUZuQ

  • WebDudeWebDude Member

    @Clouvider said:
    Mtr ?

    1. 2001:bc8:0:1::18a 85.7% 8 42.3 42.3 42.3 42.3 0.0
    2. 2001:bc8:400:1::e2 12.5% 8 41.9 41.9 41.6 42.3 0.0
      1. 2001:bc8:400:1::ce 25.0% 8 277.9 172.9 41.5 382.8 150.1
      2. 2001:bc8:400:1::d5 0.0% 8 42.2 42.0 41.8 42.3 0.0
      3. 2001:bc8:400:1::d6 0.0% 8 315.2 202.3 42.1 374.7 142.9
      4. 2001:bc8:400:1::d5 0.0% 8 41.6 41.9 41.5 42.5 0.0
      5. 2001:bc8:400:1::d6 28.6% 8 166.9 173.3 42.0 312.3 132.9
      6. 2001:bc8:400:1::d5 0.0% 8 42.0 41.8 41.4 42.0 0.0
      7. 2001:bc8:400:1::d6 0.0% 8 244.2 201.2 41.9 370.2 147.9
      8. 2001:bc8:400:1::d5 0.0% 8 41.6 41.9 41.6 42.1 0.0
      9. 2001:bc8:400:1::d6 25.0% 8 295.6 200.4 42.0 454.5 181.3
      10. 2001:bc8:400:1::d5 0.0% 8 42.3 41.8 41.4 42.3 0.0
      11. 2001:bc8:400:1::d6 50.0% 8 346.8 309.7 42.2 459.4 184.3
      12. 2001:bc8:400:1::d5 0.0% 8 41.6 41.9 41.4 43.2 0.4
      13. 2001:bc8:400:1::d6 42.9% 8 323.6 347.6 42.9 569.3 226.6
      14. 2001:bc8:400:1::d5 0.0% 8 41.7 41.9 41.7 42.2 0.0
      15. 2001:bc8:400:1::d6 14.3% 8 441.2 306.0 42.1 695.1 299.8
      16. 2001:bc8:400:1::d5 0.0% 8 42.1 42.0 41.5 42.2 0.0
      17. 2001:bc8:400:1::d6 57.1% 8 572.3 250.1 42.7 572.3 282.9
      18. 2001:bc8:400:1::d5 0.0% 8 41.9 41.8 41.3 42.3 0.0
      19. 2001:bc8:400:1::d6 71.4% 8 306.6 174.7 42.7 306.6 186.6
      20. 2001:bc8:400:1::d5 0.0% 8 42.0 41.9 41.6 42.1 0.0
      21. 2001:bc8:400:1::d6 57.1% 8 654.1 246.4 42.3 654.1 353.0

    Loopiti loop.

  • WebDudeWebDude Member

    @classy said:
    Amsterdam or Paris?

    Amsterdam

    To some sites like cloudflare.com connectivity is perfect. And to some sites like github and ipv6.google, it's mostly out. But can randomly work, meaning that it's not total loss of connectivity either.

  • v3ngv3ng Member

    Github doesn't have IPv6 yet.

  • WebDudeWebDude Member

    I just disabled Scaleways IPv6 and switched to 6to4 which works much better than their native implementation. Sure, it's broken at times, but still much less broken than native IPv6.

  • rm_rm_ Member

    WebDude said: Edit: Just opened a ticket with IP addresses, AS numbers, some logs and stuff. Let's see what they say.

    So what did they say?

    WebDude said: I just disabled Scaleways IPv6

    You repeated that 2 times already.

  • WebDudeWebDude Member
    edited June 13

    @rm_ said:

    WebDude said: Edit: Just opened a ticket with IP addresses, AS numbers, some logs and stuff. Let's see what they say.

    So what did they say?

    They said rebooting the server from control panel would help. Doing the traditional full VM cold restart. Of course it didn't change a thing. The ticket was still open, and there were no new comments from their side during this time.

    I used 6to4 for around three weeks. I've been re-testing native IPv6 since Sunday. And it has been working well. Without ridiculous packet loss, all destinations reachable and without the Scaleway's routing loops. - For now. Let's see if the issue comes back later.

    My guess is that they changed something to fix the issue. This is the unfortunate situation of IPv6 with many providers. It works so badly, nobody uses it, and because it works so badly, nobody wants to use it, and therefore nobody wants to use any effort to fix it. With every provider so far IPv6 is obviously a second-class citizen.

    I've been running logged traces from seven different European data centers monitoring the connectivity to the Scaleway instances in Amsterdam. During this time I haven't seen serious issues now.

    I commented the SW ticket, and closed it. Just wondering, if they bother to read comments on closed tickets or not. It also seem to greatly vary between providers.

    Thanked by 1rm_
  • WebDudeWebDude Member

    And about that github comment, that's true. It's not over IPv6 at all. And I don't know if it's even technically counted as github, because release assets seem to be coming from Amazon. But that's still very slow to ScaleWay. And sure i'ts over IPv4.

    github-production-release-asset-xxxxxx.s3.amazonaws.com

    Just to clarify it out. When I posted the list, I just listed sites, which I remember that I've observed to be surprisingly slow for an reason or another.

    Case closed, everything's "good" now.

Sign In or Register to comment.