Пользователи фиксируют потери пакетов при соединении с серверами Vultr через провайдеров Новой Зеландии

Have done some mtr from 2degrees AKL, Quic AKL and observing ~1% packet loss to the Vultr SYD test IP either way. Quic does have the better route but doesn't seem to help with packet loss and the highest ping on either connection was Quic as well. 2degrees UFB - 28.4 average (72.1 worst) 2.8 stddev 1.1% packet loss Quic VPS - 23.5 average (150.3 worst) 2.9 stddev 1.0% packet loss Even my Brisbane based VPS is seeing packet loss to Vultr at 0.2% and the worst ping was 101ms. Note I didn't do much testing - just added it into the testing mix after I observed the PL on both my two NZ-based servers. Makes me wonder if it's the other end that's the issue if I'm seeing it on three RSPs taking three very different paths to Vultr. 2deg is via Vocus and APPT, whereas Quic is more direct via SYD Megaport and my Brisbane VPS is via NSW IX. Also I haven't observed any different routings on 2degrees -- consistently via Vocus/AAPT which is a long way around but still giving acceptable pings IMHO. OP, happy to test tomorrow night with the actual IP in question as the Vultr test IP may just be under a bit of pressure and not a good candidate for testing. Guessing the IP the OP is trying to reach is within the 139.180.160.0/20 block as that seems to be routed directly via Vultr's NSW-IX facing edge router on 218.100.53.14. 139.180.165.1 seems to respond to ping unfiltered so maybe use that as the test IP unless OP responds with actual IP. Hey all. Sorry for the slow reply but thank you for jumping into this thread and helping. Genuinely helpful and so much more than I'm getting through the official 2D channels, to. It suggest my original theory of a 2Degrees issue may not have been 100% accurate. @KiwiSurfer mate that's really helpful, cheers. If you're still keen, testing 139.180.162.88 one night would be great. That's the actual server rather than a test IP that might just be busy. For what it's worth, in game I'm seeing 39ms with about 1-2% loss showing, which is almost exactly what you measured. So the loss is definitely real, it's just working out where in the pipeline it's happening. @yitz The server I'm on is 139.180.162.88. And if 218.100.53.14 is Vultr's NSW-IX edge then hops 3 and 4 aren't really 2degrees at all, which changes how I've been arguing this with their support team perhaps. One bit I can't figure out though, OVH's Sydney probe shows no loss to the Vultr test IP. So Sydney to Sydney is fine but three separate trans-Tasman paths aren't. Either something at the NZ/AU end is common to all three, or OVH is getting there a completely different way. Honestly this thread has got further in two days than a month of emails with 2degrees. Appreciate it. Not sure if I'm reading their graphs right, but OVH's probe shows their pings to Choppa is 300us (~0.3ms) which seems too fast. Their probe to Snap is averaging 785us (~0.7ms) which makes no sense - no Tasman path is that quick! Will have a go at that IP over the weekend and report back. Pretty sure 202.37.101.1 is anycasted at a Sydney POP and will be the recursive source IP for DNS queries that come in on their 111.69.69.68/69 resolvers. Under that assumption then the issue lies within a link at their Sydney POP(s) so not even a matter of capacity on trans-Tasman links. Conclusion would be they spent some time earlier in the month shuffling traffic around but didn't actually address the problem ?? I wonder what the constraint is? Pretty sure 202.37.101.1 is anycasted at a Sydney POP and will be the recursive source IP for DNS queries that come in on their 111.69.69.68/69 resolvers. Under that assumption then the issue lies within a link at their Sydney POP(s) so not even a matter of capacity on trans-Tasman links. Conclusion would be they spent some time earlier in the month shuffling traffic around but didn't actually address the problem ?? I wonder what the constraint is? Using an Anycast to measure latency to an ISP based in NZ is an interesting decision. Probably the more accurate one to look. Looks pretty rough. 202.180.64.10 is anycasted too just not in Australia and logically Snap AS23655 is just a stub AS behind AS9790. Still I think whatever issue manifested on the OVH Snap graphs between 2026-08-06 and 2026-08-13 is still hiding somewhere... whether that bad link is owned by Equinix, Vocus or whoever their "upstream" is. Probably the more accurate one to look. Looks pretty rough. 202.180.64.10 is anycasted too just not in Australia and logically Snap AS23655 is just a stub AS behind AS9790. Still I think whatever issue manifested on the OVH Snap graphs between 2026-08-06 and 2026-08-13 is still hiding somewhere... whether that bad link is owned by Equinix, Vocus or whoever their "upstream" is. Well currently to get into AS9790 you go via @Devoli from OVH AU. 45.127.172.93 before it hands off to AS9790. Annoying how that is also an Anycast IP... although that stays in NZ fortunately ;). Ramblings from a mysterious lady who's into tech. Warning I may often create zingers. Want broadband cheap and made for tech enthusiasts? Go look over at Quic. Use R177510EBNVXP for free setup at check out. Well currently to get into AS9790 you go via @Devoli from OVH AU. 45.127.172.93 before it hands off to AS9790. Annoying how that is also an Anycast IP... although that stays in NZ fortunately ;). 45.127.172.93 is 2degrees not Devoli https://www.peeringdb.com/asn/9790 AS4610.sydney.equinix.com is a reference to their old transit AS "odyssey networks" a international transit provider operated by Orcon/Kordia and selling to other NZ ISPs circa 2012-2014. I'm saying there is a possibly a problem on a link used by 2degrees in Sydney to connect within the IXs (Megaport/NSW-IX) and POP facilities (Equinix SY1/2/3/4). Well currently to get into AS9790 you go via @Devoli from OVH AU. 45.127.172.93 before it hands off to AS9790. Annoying how that is also an Anycast IP... although that stays in NZ fortunately ;). 45.127.172.93 is 2degrees not Devoli https://www.peeringdb.com/asn/9790 AS4610.equinix.com is a reference to their old transit AS "odyssey networks" a international transit provider operated by Orcon/Kordia and selling to other NZ ISPs circa 2012-2014. I'm saying there is a possibly a problem on a link used by 2degrees in Sydney within the IXs (Megaport/NSW-IX) and POP facilities (Equinix SY1/2/3/4). I agree with what you're saying don't worry please.... But... You can't fault me for that one. I do believe you are correct and Hurricane Electric here (I do use bgp.tools and HE) is incorrect hence why I thought it appears to be a Devoli IP but guess not! Ramblings from a mysterious lady who's into tech. Warning I may often create zingers. Want broadband cheap and made for tech enthusiasts? Go look over at Quic. Use R177510EBNVXP for free setup at check out. Oh yes very naughty of Devoli to be announcing IXP link-nets although I think the problem of DDoSing IXP ports is largely solved now through filtering and routing security. Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly to your computer or smartphone by using a feed reader.