XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    XOA Failing on Check-in

    Scheduled Pinned Locked Moved Xen Orchestra
    19 Posts 6 Posters 778 Views 5 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A Offline
      acomav
      last edited by

      I was able to fix it in mine by disabling IPv6. (Which we don't run).

      sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
      sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
      In order to verify that IPv6 is disabled, run:

      cat /proc/sys/net/ipv6/conf/all/disable_ipv6
      If the output is 1, we can say IPv6 is in disable state.

      This is a temp fix until next reboot. Read here for a permanent solution:

      https://bobcares.com/blog/debian-12-disable-ipv6/

      After disabling IPv6, 'xoa check' immediately started working.

      1 Reply Last reply Reply Quote 0
      • olivierlambertO Offline
        olivierlambert Vates 🪐 Co-Founder CEO
        last edited by

        So it could be a peering issue in IPv6. On my side, no problem, where are you based?

        A 1 Reply Last reply Reply Quote 0
        • A Offline
          acomav @olivierlambert
          last edited by

          @olivierlambert

          I am in Australia.

          1 Reply Last reply Reply Quote 0
          • DanpD Online
            Danp Pro Support Team
            last edited by

            Isn't this the same issue caused by the Node upgrade? https://github.com/nodejs/node/issues/54359

            notr1ch created this issue in nodejs/node

            closed Happy eyeballs implementation times out prematurely #54359

            A 1 Reply Last reply Reply Quote 0
            • A Offline
              acomav @Danp
              last edited by

              @Danp Interesting. That will be it. Thanks for linking this.
              In the mean time, I've put in a request with the Australian government to move us closer to Europe.
              😄

              1 Reply Last reply Reply Quote 0
              • H Offline
                HamiltonWDS
                last edited by HamiltonWDS

                I can concur that I have had the same issue described above and have a fix for it as well.
                XOA did work after deploying. But then after updating to the latest version "5.101.0 - XOA build: 20241004" and rebooted, Updates were no longer possible, along with some other minor things.

                I applied the fix from the "Happy eyeballs implementation times out prematurely" link above by editing the "/etc/systemd/system/env" file.
                Commands:

                sudo nano /etc/systemd/system/env
                

                Added in the NODE_OPTIONS line after the HOME line as shown below:

                HOME=/tmp
                NODE_OPTIONS='--network-family-autoselection-attempt-timeout=500'
                

                WRITE (CTRL-C) and EXIT (CRTL-X)
                Reboot XOA

                1 Reply Last reply Reply Quote 1
                • olivierlambertO Offline
                  olivierlambert Vates 🪐 Co-Founder CEO
                  last edited by

                  So it's the case in an IPv6 context I assume, right?

                  D H 2 Replies Last reply Reply Quote 0
                  • D Offline
                    DustinB @olivierlambert
                    last edited by

                    @olivierlambert in my case I found an errant DNS setting that was configured before I worked here that was causing some issues, but this issue became obvious after some XOA update and was likely exacerbated.

                    After I fixed up my DNS issue, performance network wide has greatly improved, and XOA hasn't been reporting this specific issue.

                    1 Reply Last reply Reply Quote 0
                    • olivierlambertO Offline
                      olivierlambert Vates 🪐 Co-Founder CEO
                      last edited by

                      @julien-f what do you think?

                      1 Reply Last reply Reply Quote 0
                      • H Offline
                        HamiltonWDS @olivierlambert
                        last edited by HamiltonWDS

                        @olivierlambert said in XOA Failing on Check-in:

                        So it's the case in an IPv6 context I assume, right?

                        I think it is only the time out setting as the primary cause of the problem with IPv6 as a secondary cause.
                        I am also in Australia, and just using IPv4 to Ping the address that I am seeing XOA Updater use, takes about on average 320ms.
                        As from that "Happy eyeballs" link the initial message has, "Node tries to connect to the A address with only 250ms timeout, insufficient for many real-world cases (cellular/satellite links, poorly connected ISPs, far away servers, packet loss, etc). This times out, so node proceed to the last candidate which is supposed to have a longer timeout, however the last candidate is an AAAA address and the host has no IPv6 connectivity so it immediately fails"

                        So it seems that when timeout occurs for those networks outside of the 250ms range, Node then uses an IPv6 address. And for those using only IPv4 networks, well, the connection never occurs.

                        The resolution, but looks to not be implemented (by Node.js), would be for Node to have the last address to be IPv4, or at least have the last IPv4 address with the longer timeout.

                        1 Reply Last reply Reply Quote 1
                        • olivierlambertO Offline
                          olivierlambert Vates 🪐 Co-Founder CEO
                          last edited by

                          Thank you very much for the clear explanation @HamiltonWDS ! This will be really helpful so we find a solution for that. We might default to IPv4 for a lot higher latency, and in the future maybe having closer location mirrors. Let me discuss this internally and schedule an action for that.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post