Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Webhorizon down... again - Page 6
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Webhorizon down... again

12346»

Comments

  • MumblyMumbly Member
    edited May 2023

    For me was up for some minute or so and then it died.

    I checked if next few lines in /etc/sysctl.conf do any change, but no difference. Still dead.

        net.ipv6.conf.venet0.accept_ra = 0
        net.ipv6.conf.venet0.use_tempaddr = 0
        net.ipv6.conf.venet0.accept_ra_defrtr = 0
        net.ipv6.conf.venet0.addr_gen_mode = 1
    
  • FatGrizzlyFatGrizzly Member, Host Rep

    @Mumbly said:
    For me was up for some minute or so and then it died.

    I checked if next few lines in /etc/sysctl.conf do any change, but no difference. Still dead.

        net.ipv6.conf.venet0.accept_ra = 0
        net.ipv6.conf.venet0.use_tempaddr = 0
        net.ipv6.conf.venet0.accept_ra_defrtr = 0
        net.ipv6.conf.venet0.addr_gen_mode = 1
    

    Hi,

    We are working on this issue, I'm suspecting that the NDP advertisements aren't reaching the VM's. We are working on a fix.

    Thanked by 1Mumbly
  • FatGrizzlyFatGrizzly Member, Host Rep

    Hi,

    DE v6 is up.

  • MumblyMumbly Member

    @FatGrizzly said: Hi,

    DE v6 is up.

    I checked it, it was required reboot to make it work, it was up for maybe minute or less and then it died again.

  • FatGrizzlyFatGrizzly Member, Host Rep

    @Mumbly said:

    @FatGrizzly said: Hi,

    DE v6 is up.

    I checked it, it was required reboot to make it work, it was up for maybe minute or less and then it died again.

    @Abd can you check further

  • AbdAbd Member, Patron Provider
    edited May 2023

    I believe it's related to this bug

    https://bugs.openvz.org/browse/OVZ-7421

    Will look into it

  • MumblyMumbly Member
    edited May 2023

    @Abd said:
    I believe it's related to this bug

    https://bugs.openvz.org/browse/OVZ-7421

    Will look into it

    @EthernetServers experienced the same:

    With much regret, we had to disable IPv6 support.

    This is due to a bug in the latest OpenVZ 7 kernel (3.10.0-1160.80.1.vz7.191.4) which was released back in December 2022.

    Other providers have noticed the same problem: https://www.webhostingtalk.com/showthread.php?t=1890578&p=10391419#post10391419

    Exactly when IPv6 support will return, I am not sure - it sadly may be a case of waiting until OpenVZ 9 matures a bit more, which we do plan on updating to next year when OpenVZ 7 is EOL.

    Moving back to 3.10.0-1160.53.1.vz7.185.3 seems to solve issue.

    Thanked by 1Abd
  • AbdAbd Member, Patron Provider

    @Mumbly said:

    @Abd said:
    I believe it's related to this bug

    https://bugs.openvz.org/browse/OVZ-7421

    Will look into it

    @EthernetServers experienced the same:

    With much regret, we had to disable IPv6 support.

    This is due to a bug in the latest OpenVZ 7 kernel (3.10.0-1160.80.1.vz7.191.4) which was released back in December 2022.

    Other providers have noticed the same problem: https://www.webhostingtalk.com/showthread.php?t=1890578&p=10391419#post10391419

    Exactly when IPv6 support will return, I am not sure - it sadly may be a case of waiting until OpenVZ 9 matures a bit more, which we do plan on updating to next year when OpenVZ 7 is EOL.

    Moving back to 3.10.0-1160.53.1.vz7.185.3 seems to solve issue.

    I have implemented a workaround. It should be fine now. :)

  • MumblyMumbly Member
    edited May 2023

    @Abd said:
    I have implemented a workaround. It should be fine now. :)

    I don't have heart to tell you but...

    root@germany:~# curl ipv6.google.com
    curl: (7) Failed to connect to ipv6.google.com port 80: No route to host
    
    root@germany:~# ping6 ipv6.google.com -c 2
    PING ipv6.google.com(fra24s07-in-x0e.1e100.net (2a00:1450:4001:82a::200e)) 56 data bytes
    From 2a05:xxxx:xxxx:xxx::xxxx icmp_seq=1 Destination unreachable: Address unreachable
    From 2a05:xxxx:xxxx:xxx::xxxx icmp_seq=2 Destination unreachable: Address unreachable
    
    --- ipv6.google.com ping statistics ---
    2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 2544ms
    

    root@germany:~# ip -6 route
    2a05:xxxx:xxxx:xxxx::/64 dev venet0 proto kernel metric 256 pref medium
    default dev venet0 metric 1024 pref medium
    

    root@germany:~# ifconfig
    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 1000  (Local Loopback)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 0  bytes 0 (0.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    venet0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500
            inet 127.0.0.1  netmask 255.255.255.255  broadcast 0.0.0.0  destination 127.0.0.1
            inet6 2a05:xxxx:xxxx:xxxx::3333  prefixlen 64  scopeid 0x0<global>
            inet6 2a05:xxxx:xxxx:xxxx::2222  prefixlen 64  scopeid 0x0<global>
            inet6 2a05:xxxx:xxxx:xxxx::1111  prefixlen 64  scopeid 0x0<global>
            inet6 2a05:xxxx:xxxx:xxxx::1  prefixlen 64  scopeid 0x0<global>
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)
            RX packets 135  bytes 11582 (11.3 KiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 89  bytes 11066 (10.8 KiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    
    venet0:0: flags=211<UP,BROADCAST,POINTOPOINT,RUNNING,NOARP>  mtu 1500
            inet 10.37.10.162  netmask 255.255.255.0  broadcast 10.37.10.255  destination 10.37.10.162
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 0  (UNSPEC)
    

    (I restarted it before that just in case...)

    Thanked by 1Abd
  • defaultdefault Veteran

    6 pages... is this a popcorn drama?

  • MumblyMumbly Member

    @default said: is this a popcorn drama?

    Nah, not at all. Just technical challenges :)

  • emghemgh Member, Megathread Squad

    @Mumbly Have you tried clicking ”yes” and ”no” at the exact same time?

  • defaultdefault Veteran

    @emgh said:
    @Mumbly Have you tried clicking ”yes” and ”no” at the exact same time?

    Is this possible at Webhorizon?

  • emghemgh Member, Megathread Squad

    @default said:

    @emgh said:
    @Mumbly Have you tried clicking ”yes” and ”no” at the exact same time?

    Is this possible at Webhorizon?

    It’s always possible

  • EthernetServersEthernetServers Member, Patron Provider

    @Mumbly @Abd If you do manage to get IPv6 working under 191.4, I wouldn't mind hearing the solution :)

    Thanked by 2sgno1 Abd
  • old bump here but your Poland mevspace openvz Ryzen node has had failed ipv6 for over a week now.

  • @default said:

    @emgh said:
    @Mumbly Have you tried clicking ”yes” and ”no” at the exact same time?

    Is this possible at Webhorizon?

    The answer is yes and no at the same time.

    Thanked by 1emgh
  • emghemgh Member, Megathread Squad

    @TimboJones said:

    @default said:

    @emgh said:
    @Mumbly Have you tried clicking ”yes” and ”no” at the exact same time?

    Is this possible at Webhorizon?

    The answer is yes and no at the same time.

    So .. maybe?

  • my NAT VPS has been down since past 48+ hours. the control panel iframe loads nothing. ticket's been pending since i first discovered the issue but i hope it gets resolved soon.

    are others facing similar outage rn?

  • himalrhimalr Member

    @jignes_k said:
    my NAT VPS has been down since past 48+ hours. the control panel iframe loads nothing. ticket's been pending since i first discovered the issue but i hope it gets resolved soon.

    are others facing similar outage rn?

    Yes, lax1-usa Los Angeles NAT VPS is down for almost a day now. They haven't responded to the ticket and there's no response on their discord server either.

    Thanked by 1jignes_k
  • hk jp sg are fine now. outage is quite normal..just report it to abd

  • @saywhat13 said:
    hk jp sg are fine now. outage is quite normal..just report it to abd

    the paris one seems to still be down. i've gotten a response on the ticket but still waiting on the fix.

    Thanked by 1ask_seek_knock
  • himalrhimalr Member

    My lax1-usa NAT VPS seems to be up now.

  • it's been over a week now since downtime for my nat vps. it is beyond unreasonable for me now.

  • @jignes_k said:
    it's been over a week now since downtime for my nat vps. it is beyond unreasonable for me now.

    the issue has been finally resolved without seemingly any loss of data.

  • AbdAbd Member, Patron Provider

    @jignes_k said:

    @jignes_k said:
    it's been over a week now since downtime for my nat vps. it is beyond unreasonable for me now.

    the issue has been finally resolved without seemingly any loss of data.

    Unfortunately, the nat vps node was down for a week due to a client's unauthorized port scans over the shared IPv4 address. As a result, the datacenter took the necessary action of blocking our server to mitigate any potential risks.

    Resolving this issue required extensive negotiation with the datacenter. They initially demanded a server reinstallation before allowing unsuspension, which would have resulted in significant data loss for all clients. We worked with them to find a more reasonable solution which took time.

    pleased to inform you that the case has now been resolved, and the par1-fra node is back up and running. :)

    Thanked by 1dusst
  • @Abd said:

    @jignes_k said:

    @jignes_k said:
    it's been over a week now since downtime for my nat vps. it is beyond unreasonable for me now.

    the issue has been finally resolved without seemingly any loss of data.

    Unfortunately, the nat vps node was down for a week due to a client's unauthorized port scans over the shared IPv4 address. As a result, the datacenter took the necessary action of blocking our server to mitigate any potential risks.

    Resolving this issue required extensive negotiation with the datacenter. They initially demanded a server reinstallation before allowing unsuspension, which would have resulted in significant data loss for all clients. We worked with them to find a more reasonable solution which took time.

    pleased to inform you that the case has now been resolved, and the par1-fra node is back up and running. :)

    Wow, you are still alive.

    If you still have some brain cells and empathy left, you close your shop.

Sign In or Register to comment.