Howdy, Stranger!

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


Does anyone have reliable, stable TCP over IPv6 on their OVH VPS in the UK?
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.

Does anyone have reliable, stable TCP over IPv6 on their OVH VPS in the UK?

A situation that I have only just come across, it might be on VPSs outside the UK but I only have UK based ones to go by.

I have a VPS in OVH's UK London data center.
I have a VPS in another VPS provider's UK data center, BrightBox in this instance (but it's affecting other VPSs I have with other providers too and other UK ISPs).

When trying to connect from the BrightBox VPS to OVH VPS using http/https or SSH over IPv6 it's unreliable, sometimes it goes through instantly, sometimes there's a delay, sometimes it timeouts completely. If using IPv4 there are no issues.

On the OVH VPS I have IPv6 connectivity, I can ping6 google.com and can make TCP connections to various websites like google etc, apt will connect okay. If I try to connect to the BrightBox VPS over IPv6 then I get the timeouts, delayed connection, or sometimes it goes through instantly. Again using IPv4 there are no issues.

An mtr trace shows packet loss around the start (or end when reversing direction) of the OVH routers, only on IPv6, IPv4 shows none.

Using the OVH looking glass to traceroute to my OVH VPS, I don't see any packet loss on either IPv6 or IPv4.

Pings bewteen the VPSs always go through, they never slow down or timeout, it only seems to be TCP traffic that exhibits the problem.

I have no issues connecting other VPS to other VPS, e.g. BrightBox to Bytemark over IPv6, the common denominator are the OVH VPSs.

OVH support tell me they have no issues, it's my fault and I haven't configured my server correctly, even though the issue is present when the VPS is in rescue mode. I have several OVH VPSs and they all exhibit the problem. IPv6 is configured to their guide using the settings from the control panel.

So is it me or is anyone else experiencing the same?

Comments

  • ClouviderClouvider Member, Patron Provider

    What does the mtr both ways show ?

  • @Clouvider said: What does the mtr both ways show ?

    mtr6 in his case. I was going to ask the same.

  • ClouviderClouvider Member, Patron Provider

    Thanked by 1Erisa
  • The_ToecutterThe_Toecutter Member
    edited August 2022

    Start: 2022-08-12T16:34:14+0100
    HOST: OVH VPS Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
    1. AS16276 _gateway (2001:41d0:801:2000::1) 0.0 0.1 0.4 0.0% 25 25 0.2 0.2 0.2 0.6 0.1
    2. AS??? fd00::ffe 0.1 0.1 0.9 0.0% 25 25 0.2 0.3 0.2 1.2 0.2
    3. AS16276 2001:41d0:0:1:3::657f 0.0 0.0 0.1 0.0% 25 25 0.4 0.4 0.3 0.5 0.0
    4. AS16276 2001:41d0:0:1:3::64c6 0.0 0.0 0.1 0.0% 25 25 0.4 0.4 0.3 0.5 0.0
    5. AS16276 2001:41d0:0:1:3::64d8 0.1 0.0 0.1 0.0% 25 25 0.4 0.4 0.3 0.5 0.0
    6. AS16276 2001:41d0:0:50::4:574 0.2 0.1 0.5 0.0% 25 25 1.1 1.1 1.0 1.6 0.1
    7. AS16276 2001:41d0:0:50::5:3038 0.1 0.0 0.1 0.0% 25 25 0.5 0.4 0.4 0.5 0.0
    8. AS16276 2001:41d0:0:50::5:f902 0.8 0.4 1.3 16.0% 25 21 1.6 1.3 0.9 2.5 0.4
    9. AS16276 be103.lon-thw-sbb1-nc5.uk.eu (2001:41d0::176) 0.1 0.1 0.2 56.0% 25 11 1.1 1.2 1.1 1.4 0.1
    10. AS??? ??? 0.0 0.0 0.0 100.0 25 0 0.0 0.0 0.0 0.0 0.0
    11. AS??? 2001:7f8:4::1167:1 34.8 9.6 100. 0.0% 25 25 35.8 6.4 0.8 100.8 20.9
    12. AS4455 2a02:27f0::50 0.2 2.7 28.1 0.0% 25 25 8.1 9.6 7.9 36.3 5.7
    13. AS4455 2a02:27f0:2:438::2 0.0 0.1 0.4 0.0% 25 25 8.1 8.2 8.1 8.5 0.1
    14. AS51059 BrightBox VPS 0.0 0.1 0.2 0.0% 25 25 8.5 8.5 8.4 8.6 0.1

    Start: Fri Aug 12 16:34:53 2022
    HOST: BrightBox VPS Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
    1. AS51059 2a02:1348:17c:d52e::1 0.0 0.0 0.1 0.0% 25 25 0.3 0.3 0.2 0.4 0.0
    2. AS51059 vlan114.cr2.ifl.gb1.brightbox.com (2a02:1348:0:4::3) 0.1 0.1 0.3 0.0% 25 25 0.3 0.3 0.3 0.6 0.0
    3. AS4455 2a02:27f0:2:438::1 0.2 1.1 12.4 0.0% 25 25 1.0 1.5 0.8 13.2 2.4
    4. AS4455 2a02:27f0::41 2.4 2.8 18.4 0.0% 25 25 7.8 9.5 7.7 26.4 3.9
    5. AS??? 2001:7f8:4::3f94:2 1.7 0.7 2.1 36.0% 25 16 8.3 8.7 8.2 10.4 0.5
    6. AS16276 be300.lon-drch-sbb1-nc5.uk.eu (2001:41d0::260e) 0.1 0.1 0.3 68.0% 25 8 8.6 8.5 8.3 8.6 0.0
    7. AS16276 2001:41d0:aaaa:100::3 2.2 6.6 14.2 0.0% 25 25 22.7 22.7 14.0 32.0 5.7
    8. AS16276 2001:41d0:aaaa:100::2 0.4 0.1 0.4 40.0% 25 15 8.6 8.4 8.2 8.7 0.0
    9. AS16276 vl1273.lon1-eri1-d2-a75.uk.eu (2001:41d0::6cf) 61.9 5.8 61.9 48.0% 25 13 80.5 15.2 8.7 80.5 19.8
    10. AS16276 2001:41d0:0:50::5:f905 0.1 4.1 50.4 0.0% 25 25 8.3 10.3 8.2 58.7 10.1
    11. AS16276 2001:41d0:0:50::5:302f 0.0 0.2 0.6 0.0% 25 25 8.9 9.0 8.7 9.5 0.0
    12. AS16276 2001:41d0:0:50::4:57b 0.0 0.2 1.0 0.0% 25 25 8.3 8.3 8.2 9.2 0.0
    13. AS16276 2001:41d0:0:1:3::64db 0.0 0.2 1.1 0.0% 25 25 8.3 8.4 8.2 9.3 0.0
    14. AS16276 2001:41d0:0:1:3::64c9 0.1 0.1 0.2 0.0% 25 25 8.3 8.3 8.2 8.4 0.0
    15. AS16276 2001:41d0:0:1:3::654c 0.0 0.1 0.6 0.0% 25 25 8.2 8.2 8.1 8.7 0.0
    16. AS??? ??? 0.0 0.0 0.0 100.0 25 0 0.0 0.0 0.0 0.0 0.0
    17. AS16276 OVH VPS 0.3 0.1 0.3 0.0% 25 25 8.6 8.4 8.3 8.6 0.0

  • Not sure that's formatted very well!

  • You said mostly TCP connections are failing?
    I would try tcptraceroute6 in this case and see if there are any drops.
    Or iperf3/hping3 if you don't mind setting those up on both ends.

    I suspect there is something going with 2a02:27f0::41, AS4455.
    Can you make the same test over IPv4 and show the mtr?

  • Yep, icmp seems to always get through, it's tcp connections that are troublesome.

    Start: 2022-08-12T16:55:36+0100
    HOST: OVH VPS Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
    1. AS16276 _gateway () 0.0 0.0 0.2 0.0% 25 25 0.2 0.2 0.1 0.3 0.0
    2. AS??? 192.168.143.254 0.0 0.0 0.1 0.0% 25 25 0.2 0.2 0.2 0.3 0.0
    3. AS??? 10.13.160.126 0.0 0.0 0.2 0.0% 25 25 0.3 0.3 0.3 0.5 0.0
    4. AS??? 10.13.158.156 0.0 0.0 0.1 0.0% 25 25 0.3 0.3 0.2 0.4 0.0
    5. AS??? 10.13.158.178 0.0 0.0 0.1 0.0% 25 25 0.3 0.3 0.3 0.4 0.0
    6. AS??? 10.72.4.120 0.1 0.1 0.3 0.0% 25 25 0.7 0.7 0.5 0.9 0.1
    7. AS??? 10.73.32.58 0.0 0.0 0.1 0.0% 25 25 0.3 0.3 0.2 0.4 0.0
    8. AS??? 10.73.249.4 18.5 3.5 19.6 0.0% 25 25 62.7 7.4 0.7 62.7 15.4
    9. AS16276 be103.lon-drch-sbb1-nc5.uk.eu (91.121.215.118) 0.0 0.1 0.6 0.0% 25 25 0.9 1.0 0.8 1.5 0.1
    10. AS??? 10.200.0.141 0.7 7.9 95.7 0.0% 25 25 1.1 5.1 1.0 97.1 19.2
    11. AS8553 25577xe-0-0-2-0.mario.as34270.net (195.66.225.36) 0.0 1.0 10.3 0.0% 25 25 0.9 1.4 0.9 11.2 2.1
    12. AS34270 xe-0-0-0-0.yoshi.as34270.net (85.91.232.6) 0.0 0.1 0.5 0.0% 25 25 9.4 9.4 9.4 10.0 0.1
    13. AS34270 no-dns-yet.inetc.co.uk (85.91.239.110) 0.0 0.1 0.2 0.0% 25 25 9.4 9.4 9.3 9.6 0.1
    14. AS51059 BrightBox VPS 0.0 0.1 0.4 0.0% 25 25 9.5 9.5 9.4 9.8 0.1

    Start: Fri Aug 12 16:57:10 2022
    HOST: BrightBox VPS Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
    1. AS??? 10.243.84.185 0.0 0.0 0.1 0.0% 25 25 0.1 0.1 0.1 0.2 0.0
    2. AS??? vlan114.cr2.ifl.gb1.brightbox.com (172.16.0.3) 0.0 0.1 0.2 0.0% 25 25 0.2 0.2 0.2 0.4 0.0
    3. AS34270 no-dns-yet.inetc.co.uk (85.91.239.109) 0.0 1.2 14.6 0.0% 25 25 0.4 1.1 0.3 14.9 2.9
    4. AS34270 xe-0-0-0-0.mario.as34270.net (85.91.232.5) 0.1 0.1 0.4 0.0% 25 25 8.8 8.8 8.8 9.2 0.0
    5. AS??? 10.200.0.139 0.1 0.2 1.1 0.0% 25 25 9.5 9.5 9.2 10.3 0.0
    6. AS??? ??? 0.0 0.0 0.0 100.0 25 0 0.0 0.0 0.0 0.0 0.0
    7. AS??? ??? 0.0 0.0 0.0 100.0 25 0 0.0 0.0 0.0 0.0 0.0
    8. AS??? ??? 0.0 0.0 0.0 100.0 25 0 0.0 0.0 0.0 0.0 0.0
    9. AS16276 be101.lon1-eri1-g2-nc5.uk.eu (91.121.215.119) 0.5 2.8 31.6 0.0% 25 25 10.0 11.4 9.7 41.6 6.3
    10. AS??? ??? 0.0 0.0 0.0 100.0 25 0 0.0 0.0 0.0 0.0 0.0

  • @luckypenguin said:

    I suspect there is something going with 2a02:27f0::41, AS4455.

    No problem connecting to another VPS on another network that goes through that same router though, it's only when going to OVH that I'm getting a problem.

  • sgjohnstonsgjohnston Member
    edited October 2022

    I know this is three months old, but I have almost exactly the same issue with two OVH VPSs in the UK, including the reaction from OVH support! I first noticed the issue as poor response to http and ssh, and have subsequently narrowed it down:

    • only IPv6, not v4
    • Not ICMP, that is fine
    • for TCP it seems to be the SYN packet that is dropped, once the SYN/ACK arrives everything works perfectly for that connection
    • UDP also appears to have the issue, but with each packet, as you might guess
    • It is bidirectional for me, so incoming connections to my server, plus outgoing from the server. So, the easiest way to test it is “curl -6 google.com”. That will either work immediately, be slow (and TCPdump confirms that lots of SYNs are lost), or time out (all SYNs lost).
    • mtr is interesting (again to google.com). Default ICMP mtr works flawlessly with no or little loss. Using the -T option (TCP SYN packets instead of ICMP) had large amounts of loss, mirroring the problem.

    OVH support have supposedly investigated, and found nothing (even though, as the OP says, it happens in rescue mode as well). I’m pretty baffled, it almost seems like some sort of IDS or something watching connections, and running out of resources to fulfill the connection. But once it is made, everything is good.

    Any other thoughts welcome!

    Thanked by 1rm_
  • rm_rm_ IPv6 Advocate, Veteran
    edited October 2022

    @sgjohnston said: it almost seems like some sort of IDS

    OVH is famous for their powerful and no-extra-cost DDoS filtering, but the world's worst kept secret is that it only protects IPv4. Maybe they are starting to implement some on IPv6, clumsily, or just tried something simplistic for now, and as you witness, having a ton of side-effects.

    I do not seem to have the issue in RBX1 on a dedicated server, tested with repeated "curl -I6 google.com".

  • OVH support have just confirmed to me that their mitigation doesn't apply to IPv6 traffic. Unfortunately, they are completely denying any responsibility for the problem, even though it seems clear that it only exists when the OVH network to VPS is involved. I guess I just need to give up on this, and either not run IPv6 on their VPSs, or change to another provider that does actually work. Strange, if I was OVH I would want to get to the bottom of what was going on!

    Thanked by 1muddy
  • Late to the party, but I am in exactly the same boat.

    I can add that it only seems to be an OVH-UK issue. We use VPS'ses in 5 different OVH datacentres, and only the London one has this issue, all others work fine.

    Also, there is no issue between the VPSses, even from across the pond, so it seems to be a network edge issue.

    We've now been offered new VPSses in other DC's, with a transfer of the remaining credits, so if you're not limited to using the London DC, that might be a solution.

  • @The_Toecutter said:
    A situation that I have only just come across, it might be on VPSs outside the UK but I only have UK based ones to go by.

    I have a VPS in OVH's UK London data center.
    I have a VPS in another VPS provider's UK data center, BrightBox in this instance (but it's affecting other VPSs I have with other providers too and other UK ISPs).

    When trying to connect from the BrightBox VPS to OVH VPS using http/https or SSH over IPv6 it's unreliable, sometimes it goes through instantly, sometimes there's a delay, sometimes it timeouts completely. If using IPv4 there are no issues.

    On the OVH VPS I have IPv6 connectivity, I can ping6 google.com and can make TCP connections to various websites like google etc, apt will connect okay. If I try to connect to the BrightBox VPS over IPv6 then I get the timeouts, delayed connection, or sometimes it goes through instantly. Again using IPv4 there are no issues.

    An mtr trace shows packet loss around the start (or end when reversing direction) of the OVH routers, only on IPv6, IPv4 shows none.

    Using the OVH looking glass to traceroute to my OVH VPS, I don't see any packet loss on either IPv6 or IPv4.

    Pings bewteen the VPSs always go through, they never slow down or timeout, it only seems to be TCP traffic that exhibits the problem.

    I have no issues connecting other VPS to other VPS, e.g. BrightBox to Bytemark over IPv6, the common denominator are the OVH VPSs.

    OVH support tell me they have no issues, it's my fault and I haven't configured my server correctly, even though the issue is present when the VPS is in rescue mode. I have several OVH VPSs and they all exhibit the problem. IPv6 is configured to their guide using the settings from the control panel.

    So is it me or is anyone else experiencing the same?

    I experience this issue too in Gravelines on a Kimsufi dedi. Currently it is usable but in the past few weeks IPv6 connections were usualy broken. The support is not helpful in harder problems than an SSD replace, I contacted with them with a rescue OS related problem and they suggested to me near 5x that if I can't manage my server contact with their partners, and they only provide unmanaged server. However the rescue provided by OVH so I don't know how can a partner or I fix the problem. Their service usualy very stable but the support might be better a lot.

  • @WanWizard said:
    Late to the party, but I am in exactly the same boat.

    I can add that it only seems to be an OVH-UK issue. We use VPS'ses in 5 different OVH datacentres, and only the London one has this issue, all others work fine.

    Also, there is no issue between the VPSses, even from across the pond, so it seems to be a network edge issue.

    We've now been offered new VPSses in other DC's, with a transfer of the remaining credits, so if you're not limited to using the London DC, that might be a solution.

    Interesting that the non UK DC is ok, I might try that. I’ve learned a bit more about the problem, which is interesting but not much help in getting OVH to take it seriously!

    • I tried connecting from an AWS VM in the USA to my OVH VM, that worked fine always. From two different sites in the UK the problem exists, which makes me think that it is part of the OVH infrastructure connecting into the UK backbone that is the problem.

    • It is just TCP SYN packets that are the issue (there may be UDP issues too). Once the initial SYN gets through, everything is good. This feels like some sort of connection following firewall that isn’t working properly (although there are supposedly no firewalls for IPv6 with OVH).

    • I discovered by accident that TCP port 25 always works, it doesn’t have the above SYN problem. This again makes me think there is a firewall type device (or maybe load balancer) that is configured to allow 25 through, but nothing else (at least not the ports I have tried).

    I don’t have much hope in the, fixing it, they seem to be not at all interested; if it was me I would want to know where my network was broken!

  • We use these VPSses as part of our CDN, and we get complaints from all over the world about connectivity issues.

    So it's not UK only, but it might be related to how traffic is routed towards the London DC, as OVH has their own fibre to a lot of internet exchanges.

    My 2ct's is also on some sort of mitigation device on one specific ingress route, but I can't get the message across, they simply won't listen.

    They keep asking for mtr output, which is ICMP and works fine. When I send them the results of mtr on TCP/22 or TCP/80, they ignore it. They only test from within the OVH network (which works fine) of use ICMP (which also works fine).

    I tried to give them all info from 4 different locations, to no avail.

    Very frustrating, given the fact I've designed datacentres and networks for a living, and have over 30 years of networking under my belt :( .

  • Hello,

    I have been having this issue for quite a while now - since the middle of last year sometime - although it's hard to pinpoint as I think we're encountering exactly the same thing. Same setup, same problem: occasionally, IPv6 just doesn't connect on TCP/UDP - whereas ICMP packets seemingly work flawlessly. Whenever the SYN packet does come in to the interface, the connection works correctly after that.

    I have re-opened a ticket with OVH about this issue, as it's causing some quite significant issues on the services that I provide to various customers, and I'm pleased to have found others with the same problem - so it's not just me!

    Does anyone have any further analysis of this problem?

  • Same problem here on a SG vps, I don't have this problem on ks-le-1 machine:

    tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
    listening on ens3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    14:37:17.814053 IP6 redacted.46206 > 2606:4700::6810:84e5.https: Flags [S], seq 3252521723, win 64800, options [mss 1440,sackOK,TS val 1999943385 ecr 0,nop,ws
    cale 7], length 0
    14:37:18.839060 IP6 redacted.46206 > 2606:4700::6810:84e5.https: Flags [S], seq 3252521723, win 64800, options [mss 1440,sackOK,TS val 1999944410 ecr 0,nop,ws
    cale 7], length 0
    14:37:19.904155 IP6 2606:4700::6810:84e5.https > redacted.46206: Flags [S.], seq 1386797916, ack 3252521724, win 64704, options [mss 1360,sackOK,TS val 517262
    766 ecr 1999943385,nop,wscale 13], length 0
    

    Most likely a firewall issue. But it's OVH, so i doubt they care about ipv6 connectivity issues...

  • m2bm2b Member
    edited January 2023

    Hello, I work at OVH in network departments. If someone can PM me details of this IPv6 issue on VPS, i'll be glad to look at it.

  • @m2b said:
    Hello, I work at OVH in network departments. If someone can PM me details of this IPv6 issue on VPS, i'll be glad to look at it.

    Fantastic, I've PMed.

  • The issue is now resolved, please contact me if you still have issue.

  • Great job m2b :)

  • rm_rm_ IPv6 Advocate, Veteran

    It appears I now get this on my dedi in RBX1. Does anyone have the same issue recently?

    # httping -t 3 -6 2001:41d0:1:8b3b::1
    PING 2001:41d0:1:8b3b::1:80 (/):
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=0 time=147.32 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=1 time=147.29 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=2 time=147.28 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=3 time=147.18 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=4 time=147.52 ms 
    connect time out
    
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=6 time=147.25 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=7 time=147.38 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=8 time=147.26 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=9 time=147.63 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=10 time=147.09 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=11 time=146.95 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=12 time=147.44 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=13 time=146.96 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=14 time=147.18 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=15 time=147.07 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=16 time=147.35 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=17 time=147.25 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=18 time=147.37 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=19 time=147.64 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=20 time=146.97 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=21 time=147.29 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=22 time=147.11 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=23 time=147.19 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=24 time=147.42 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=25 time=147.44 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=26 time=147.08 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=27 time=147.54 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=28 time=147.58 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=29 time=146.64 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=30 time=147.08 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=31 time=147.09 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=32 time=147.18 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=33 time=147.35 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=34 time=147.46 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=35 time=147.82 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=36 time=147.58 ms 
    connect time out
    
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=38 time=146.89 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=39 time=147.25 ms 
    connect time out
    
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=41 time=147.31 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=42 time=147.04 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=43 time=147.33 ms 
    connect time out
    
    timeout while receiving reply-headers from host
    connect time out
    
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=47 time=147.79 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=48 time=147.29 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=49 time=147.40 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=50 time=147.30 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=51 time=147.31 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=52 time=147.17 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=53 time=147.18 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=54 time=147.31 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=55 time=147.20 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=56 time=147.05 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=57 time=147.27 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=58 time=147.40 ms 
    connect time out
    
    connect time out
    
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=61 time=147.16 ms 
    connect time out
    
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=63 time=147.28 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=64 time=147.30 ms 
    connected to [2001:41d0:1:8b3b::1]:80 (152 bytes), seq=65 time=146.98 ms 
    ^CGot signal 2
    --- http://2001:41d0:1:8b3b::1/ ping statistics ---
    66 connects, 57 ok, 13.64% failed, time 104239ms
    round-trip min/avg/max = 146.6/147.3/147.8 ms
Sign In or Register to comment.