Australia/New Zealand - High Latency or Connecting to Wrong Servers since 2/Jul/2019

In the US, ISPs in one region will sometimes share a common peer. When the peer has problems, 10-15+ ISPs can also have a problem. (Note: I am not talking about a local peer, I am talking about something larger scale connecting Australia and New Zealand traffic to Blizzard servers.) I don’t have access to the info Blizz used to make the above statement, but my guess would be that something similar is happening for the OCE players.

Edit: Removed link that discussed overburdened internet infrastructure, but was focused on another ISP not discussed in the thread.


That’s how it works already. It looks at the last hop where your ping came from. So let’s say your ISP routed you into the Netherlands, it would connect you to Europe because the last hop is close to the European server.


A good suggestion in my opinion – I don’t know how it would affect things, but would be interesting to see in action. They’ll probably tell you to suggest it in General, since devs peruse that forum.

2 Likes

Hey Arkfox congrats on your insanely fast cable internet that only ever struggles with Overwatch! Sadly however the problem is the ISP so time to switch it up :frowning:

Kaldraydis you are a idiot that has no idea what you are talking about. As someone with 10 years of Network Operations experience I can tell you right now, nothing you have said about how a network works is correct. But on your advice, i did contact my ISP’s Teir 3 agent (which is a American term, we don’t have teir 3 agents here), and the poor dude I spoke to almost wet himself with laughter with your excuse. Blizzard support has just become the laughing stock of the Aussie ISP tech support scene. Keep up the great work!

As for Nicole, “A survey found 36 per cent of respondents [in Australia] have reported experiencing some connection or streaming issues” because they are not hosted locally. Local load balancing (the common peer you talk about) will only add a few ms to any route, and any problem within that peer will be detected instantly by Network Operations and fixed as it will affect all traffic.

It’s cute that both Nicole and Kaldraydis failed to mention the glaring issue…This started after the last patch. You don’t need to have pretty Green or Blue text to realize that YOU changed something with your internal load sharing with the last patch that caused this problem.

But keep blaming our ISP’s, it just shows how clueless your support ‘experts’ are.

3 Likes

Come on Blizzard.

I hate to play this card but as someone with over 6 years of experience in the IT industry looking after extremely complex networks and systems, I need to tell you that you shouldn’t try to explain how this works by reading news articles and pasting them into forum posts. It’s erroneous information and doesn’t really help the cause at all.
Let me lay some facts out for you.

The chances of EVERY SINGLE ISP in NZ/AUS having problems at once are EXTREMELY slim. You know that. Everyone here knows that.

When im matched into an OCE server:

My wife and I play together on the same Overwatch games. She sits behind me. My ping will be 40 and hers will be 80 (according to the in-game net-graph). It could be me 80 and hers 40, it tends to swap. Sometimes both 80 sometimes both 40.

  1. During this time, I have constant pings running from my router, both of our PC’s and my home server. They all sit between 27 and 30ms and are all going to the exact IP that the in-game net-graph is showing. The pings NEVER CHANGE REGARDLESS OF WHAT THE GAME REPORTS

Now, I ask you, how can this be a “problem with the ISP” ?

When I’m NOT matched into an OCE server
I am still continually running pings AND Traceroutes/MTR to the SYD1 and SYD2 servers that I would prefer to be in.

GUESS WHAT, THE PATH THE TRAFFIC TAKES AND LATENCY RTT NEVER CHANGE

Now, I ask you, how can this be a “problem with the ISP” ?

Blue team, please respond.

(edit: I was a bit toxic here and realized the error of my ways, so tidied this up a little, sorry if I offended anyone).

All righty, I’m going to make two separate posts in a row on this, because this particular post is aimed at a few particular posters and it’s not relevant to the issue.

I completely understand that this has been going on for a while, now, and as a result it’s starting to get understandably irritating to deal with. There have also been some communications made with incomplete data, which I will be going back and correcting shortly. However, we’re all trying to work together to get this problem solved. Disagreements are entirely allowed, and we can try to address them. However, we’re going to treat toxicity and personal attacks in this thread like we do in game going forward.

That is to say that unless you’re communicating in a level headed/professional manner and trying to work with us, your posts may be hidden and if the behavior does not improve you may receive forum suspensions. I’m not going to do this lightly. Further, it’s not a tool I will use if I simply disagree with what you say, but will resort to this if the name calling and other unnecessary comments do not cease.

While we would appreciate more data, and the more data we get, the easier we can investigate this, you are not obligated to post here, and we’re not going to sacrifice keeping this investigation civil and constructive. If you don’t want to be constructive, this is not the place for you.

I appreciate your cooperation.

1 Like

Now, on to what’s going on here.

As far as we can tell right now, this is entirely unrelated to the recent patch. From the tests I’ve seen so far on this issue, there are a mix of problems. Some players are having individual packet loss issues which will not be corrected when this ISP level issue is handled. However, there have also been some signs of packet loss and high latency at a major backbone provider which funnels your connections toward our Sydney server. For Australia/New Zealand players, a lot of you will probably be impacted by this. We’re not closing this investigation just yet, but unfortunately we haven’t been getting enough of the information we actually need to get our techs working on this problem.

Without enough tests to convincingly say to them “This is the problem” we can’t even attempt to reach out to peering because they’ll look at our email and reply “Okay where’s the data that makes me care about a gaming company’s experience?”

So, let’s refocus here and try to get that data. A lot of the tests in this thread have shown that your connections to the wrong servers have been fine, and the tests in the other thread were mostly too short to get usable data for. We need to redo some of these tests to give this another look.

For those of you who are still having this problem, please create a WinMTR test during a time when you’re having latency problems on Sydney servers, or if you are getting routed to the wrong server outside of the Practice Range. (The Practice Range will often put you on the wrong server group anyway, so it’s pointless to test here.)

For the “Host” blank, we need you to use this IP address specifically so we can see what’s going on with your test:

37.244.40.1

You want to restart the test every 10-15 minutes until you catch one of these problems. Once you’ve caught one red handed, run the test for about 5 more minutes. This will let us look for problems between your house and our servers which may cause this.

If you have problems with posting it due to a link error, go ahead and copy paste this into your next post, and replace “WinMTR goes here” with your test.

~~~~
WinMTR goes here
~~~~

Again, we appreciate your patience and cooperation throughout all this. This doesn’t mean you should stop notifying the ISPs about this if you do find problems in your WinMTR, but it does mean we’re willing to give this another check to see if there’s maybe something we can do.

1 Like

I can tell you what the problem is. Syd2 is an Equinix server (I think) aussies used to play on PSE2 which was an AWS server.
Maybe Equinix just isn’t as good at handling gaming traffic as AWS or maybe ISPs don’t have good peering with Equinix.

Why don’t you guys open up a few servers on PSE2/AWS and see if it improves?

I don’t think that’s the case. SYD = Sydney, obviously. PSE = Pacific South East. These servers are up in South East Asia somewhere, I suspect Singapore but I’m really not sure. Adding more servers in the PSE area would not help this problem I don’t think – unless I’m completely missing your point.

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                 192-168-1-1.tpgi.com.au -    3 |  635 |  622 |    1 |    1 |    6 |    1 |
|                 10-20-25-79.tpgi.com.au -    1 |  674 |  671 |   13 |   26 |  468 |   13 |
|       203-219-166-66.static.tpgi.com.au -    1 |  667 |  662 |   13 |   17 |  226 |   14 |
|      203-219-107-102.static.tpgi.com.au -    1 |  674 |  671 |   13 |   31 |  676 |   14 |
|      bri-pow-que-wgw1-be-10.tpgi.com.au -    1 |  678 |  676 |   14 |   26 |  537 |   14 |
|           be300.bqueebrdr11.aapt.net.au -    1 |  674 |  671 |   14 |   28 |  528 |   15 |
|Bundle-Ether16.cha-edge902.brisbane.telstra.net -    1 |  678 |  676 |   14 |   28 |  530 |   15 |
|bundle-ether7.cha-core4.brisbane.telstra.net -    1 |  674 |  671 |   14 |   33 |  465 |   15 |
|bundle-ether20.ken-core10.sydney.telstra.net -    1 |  682 |  681 |   28 |   40 |  539 |   30 |
|bundle-ether1.oxf-gw10.sydney.telstra.net -    1 |  674 |  671 |   28 |   42 |  447 |   29 |
|bundle-ether1.sydo-core04.sydney.reach.com -    1 |  674 |  671 |   28 |   43 |  488 |   31 |
|           i-91.sydo10.telstraglobal.net -    1 |  682 |  681 |   28 |   39 |  529 |   29 |
|               unknown.telstraglobal.net -    1 |  678 |  676 |   29 |   44 |  560 |   30 |
|                           137.221.85.35 -    1 |  674 |  671 |   29 |   51 |  465 |   29 |
|         et-0-0-1-pe01-eqsy4.as57976.net -    1 |  678 |  676 |   28 |   48 |  441 |   29 |
|                             37.244.40.1 -    1 |  674 |  671 |   29 |   47 |  446 |   30 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Just played a game and got the brazil server. I’m in Australia. What did you guys do? WTH?!?

You have packet loss to your home router – you need to fix that.

Hey all, My ping has come down from the original 170-180ms mark, however, it seems to fluctuate from its normal 16-18ms all the way up to 90ms. This seems intermittent and doesn’t have a pattern from what I can see. I have lodged a ticket with iiNet in the hopes they can find something. Below are the WinMTR results for tonight.

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                         router.asus.com -    0 |  679 |  679 |    0 |    0 |    5 |    0 |
|                          150.101.42.200 -    0 |  679 |  679 |    1 |    1 |    9 |    1 |
|                 ae10.cr1.cbr2.on.ii.net -    0 |  679 |  679 |    1 |    2 |   38 |    1 |
|                 be12.cr3.syd7.on.ii.net -    0 |  679 |  679 |    5 |    5 |   13 |    6 |
|                be-50.cr2.syd7.on.ii.net -    0 |  679 |  679 |    5 |    5 |   15 |    6 |
|                  ae6.cr2.syd4.on.ii.net -    0 |  679 |  679 |    5 |    7 |   90 |    6 |
|                   57976.syd.equinix.com -    0 |  679 |  679 |    6 |    9 |  117 |    6 |
|        et-0-0-49-br01-eqsy4.as57976.net -    0 |  679 |  679 |    6 |   12 |  142 |    6 |
|         et-0-0-0-pe02-eqsy4.as57976.net -    0 |  679 |  679 |    5 |    8 |   84 |   10 |
|                          137.221.66.135 -    0 |  679 |  679 |    6 |    6 |   15 |    7 |
|                             37.244.40.1 -    0 |  679 |  679 |    6 |    6 |   17 |    7 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

I’m really confused why it’s implemented in this way and I feel the point I was making is somewhat confused.

A few packets can be sent to a player and if that takes .5 seconds (or whatever the threshold may be) to return because I’m connecting to some overseas server then just don’t put me in a game. It’s pointless playing the game with pings that high, no one has fun, often I can’t even communicate with teammates because of a language barrier and it seriously degrades the competitive nature of the game.

This can be achieved in a client as simple as a web browser why can blizzard not implement this simple check? rather than just running with the ping to whatever hop was last used which seems like a pretty poor implementation and doesn’t always give any true representation of the ping the player might experience. Services should be predictable and going of the last hops ping is just not predictable if you cannot be sure what the end users real ping might be.

Furthermore a simple oceanic Region option would help with this and allow further matchmaking diagnostics on Blizzards end if we’re being put in overseas servers.

1 Like

This is true. even in a game connected to syd where you ping seems fine it can go ll the way up to 120 and back down again from one second to the next. I’ll try to capture this at some point.
This is from 5min ago, pretty much constant high ping.
iinet, geelong GMT+10

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.0.1 -    0 |  618 |  618 |    0 |    0 |    2 |    0 |
|                              172.22.0.1 -    0 |  618 |  618 |    3 |    7 |   19 |    7 |
|            be21-450.cr2.mel10.on.ii.net -    0 |  618 |  618 |    5 |    8 |   22 |    8 |
|                be51.cr2.mel11.on.ii.net -    0 |  618 |  618 |   14 |   18 |   35 |   19 |
|                 be55.cr3.syd2.on.ii.net -    0 |  618 |  618 |   14 |   18 |   33 |   18 |
|                 ae15.cr1.syd4.on.ii.net -    0 |  618 |  618 |   14 |   18 |   34 |   21 |
|                  ae3.cr2.syd4.on.ii.net -    0 |  618 |  618 |   15 |   18 |   32 |   17 |
|                   57976.syd.equinix.com -    0 |  618 |  618 |   14 |   22 |  108 |   17 |
|        et-0-0-49-br02-eqsy4.as57976.net -    2 |  579 |  569 |   45 |  132 |  254 |  161 |
|         et-0-0-0-pe02-eqsy4.as57976.net -    1 |  611 |  609 |   21 |  129 |  234 |  115 |
|                          137.221.66.135 -    0 |  618 |  618 |   14 |   18 |   30 |   18 |
|                             37.244.40.1 -    0 |  618 |  618 |   13 |   18 |   35 |   21 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

If that can help… I’m from Mauritius. Usually I connect to EU (~200ms) (US ~300ms) (asia - forget about it)
For the past 24hrs I’ve been getting EU (~310ms), US (~250ms)
That’s how I found out for EU I’m connecting to Amsterdam server instead of CDG Paris and on US I’m on Singapore instead of US east.
Don’t care so much about US but how can I force connect to CDG? That’s all I ask. I have very little time (Dad of 2 babies/ 2 jobs) and now I’m having to trouble shoot in my little spare time… :frowning:

Can someone explain this to me as I’m not tech savy but it seems way too much of a coincidence so I just need an explanation. I don’t have problems with any other games, at all, at any time. No ping spikes, no anything.

Then 11 or so days ago, I can’t connect to HotS games. Game is ready, can’t connect, error. At the same time OW players also start having issues. Blizz solve this problem, but I continue to have ping issues. They say it’s about traffic, but I get it 3am on a weekday.

Can someone explain how this possible and somehow just a coincidence? Wouldn’t it affect me in more ways than to just one game?

There’s a couple good questions here I wanted to address, although we’re going to need more of the information I requested to dig into this more deeply for you all. It sounds like for at least some of you, the behavior changed.

The reason this is only affecting Overwatch for you all is that you’ll be taking a different route to our servers than most any other service or game you play. The internet is kind of like a system of highways, and we expect there’s a traffic jam on the information highway to us. Meanwhile the roads to say, google, or other games, are clear. There’s more information in our common issues sticky for this - under the FAQs.

The reason you’ll sometimes end up on the wrong server is that while you’re queuing for a match of whatever type, the game will ping your computer to see what your latency is. It does this from multiple different servers, and the pings will happen at different times. So what you can end up with in a situation where a part of the internet is getting clogged is this.

The Sydney server pings you, and there’s a problem with the internet between you and us. Say it’s 300 ms or so because of that problem at that point in time.
Los Angeles pings you and sees you have a ping of 180 ms. Better, but not quite what we’re after.
Now the Singapore server pings you, and it sees about 130 ms because the problem with the internet wasn’t flaring up when that ping happened.

130 MS is less than 300, so you end up on Singapore servers (or whichever server has the lowest ping test at the time.) It’s a bit more complicated than this, but that’s the simplified version of how it works.

It’s designed this way intentionally to get you the best connection it can at any given time without insane queue times. Obviously if you end up on the Sydney servers it doesn’t particularly matter while this problem is happening - the latency problem will still be coming and going so you’ll get spikes of latency there too. This is why we’re focusing on trying to find the cause of the issue. As long as it’s happening, there’s a likelihood that no matter what server you end up on, you’re going to have a bad experience, and that’s what we want to try to diagnose and avoid.

If you have suggestions for other ways to handle this, we welcome that feedback, but that’s better for the general forums. Here, we’re focusing on the tech aspect of things so that we can try to help you all resolve the underlying issue in whatever form that takes.

We still need more tests to narrow this down. For those of you having the high latency, or ebbing and flowing latency, please continue following the steps here and posting tests. Remember: when you run the test the problem needs to be actively happening so we can see the issue in the test! The more info we get to compare the more likely we can narrow down the cause.

2 Likes

Previously Australian servers were on PSE2 (AWS Server) now theyre on SYD2 (Equinix Server) My thoughts are that maybe Equinix’s infrastructure in australia isnt quite as good as the AWS servers I have included a WinMTR for both PSE2 (AWS) and SYD2 (Equinix) below as you will see the routing to the AWS is much cleaner and doesnt appear to be triggering hops to telstraglobal which as far as I know is telstras international links.

PSE2

|------------------------------------------------------------------------------------------|

|                                      WinMTR statistics                                   |

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

|                             192.168.1.1 -    0 |   18 |   18 |    0 |    0 |    2 |    0 |

| gateway.qb51.townsville.asp.telstra.net -    0 |   18 |   18 |    5 |    7 |   29 |    5 |

|                         144.130.213.209 -    0 |   18 |   18 |   20 |   20 |   23 |   20 |

|bundle-ether6.cha-core4.brisbane.telstra.net -    0 |   18 |   18 |   21 |   22 |   24 |   22 |

|bundle-ether20.ken-core10.sydney.telstra.net -    0 |   18 |   18 |   35 |   35 |   38 |   36 |

|bundle-ether1.ken-edge901.sydney.telstra.net -    0 |   18 |   18 |   34 |   35 |   37 |   35 |

|              ama1663225.lnk.telstra.net -    0 |   18 |   18 |   34 |   35 |   38 |   34 |

|                   No response from host -  100 |    4 |    0 |    0 |    0 |    0 |    0 |

|                   No response from host -  100 |    4 |    0 |    0 |    0 |    0 |    0 |

|                            52.95.37.199 -    0 |   18 |   18 |   35 |   36 |   42 |   36 |

|                             52.95.36.43 -    0 |   18 |   18 |   34 |   37 |   51 |   43 |

|                          54.240.192.239 -    0 |   18 |   18 |   35 |   37 |   68 |   35 |

SYD2

|------------------------------------------------------------------------------------------|

|                                      WinMTR statistics                                   |

|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |

|------------------------------------------------|------|------|------|------|------|------|

|                             192.168.1.1 -    0 |  321 |  321 |    0 |    0 |    2 |    0 |

| gateway.qb51.townsville.asp.telstra.net -    0 |  321 |  321 |    4 |    6 |   37 |    5 |

|                         144.130.213.209 -    0 |  321 |  321 |   20 |   20 |   35 |   21 |

|bundle-ether6.cha-core4.brisbane.telstra.net -    0 |  321 |  321 |   20 |   22 |   36 |   21 |

|bundle-ether20.ken-core10.sydney.telstra.net -    0 |  321 |  321 |   34 |   35 |   41 |   36 |

|bundle-ether1.oxf-gw10.sydney.telstra.net -    0 |  321 |  321 |   35 |   36 |   46 |   37 |

|bundle-ether1.sydo-core04.sydney.reach.com -    0 |  321 |  321 |   35 |   36 |   42 |   36 |

|           i-91.sydo10.telstraglobal.net -    0 |  321 |  321 |   35 |   35 |   41 |   35 |

|               unknown.telstraglobal.net -    0 |  321 |  321 |   36 |   40 |  118 |   38 |

|        et-0-0-48-br01-eqsy4.as57976.net -    0 |  321 |  321 |   35 |   40 |  161 |   38 |

|         et-0-0-0-pe02-eqsy4.as57976.net -    0 |  321 |  321 |   36 |   38 |  107 |   37 |

|                          137.221.66.135 -    0 |  321 |  321 |   36 |   36 |   44 |   37 |

|                             37.244.40.1 -    0 |  321 |  321 |   35 |   36 |   44 |   36 |

|________________________________________________|______|______|______|______|______|______|

   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

As you can see the “ama1663225” route seems to have a more stable latency than the TelstraGlobal hops.

If you do a search for “sydo10.telstraglobal” youll notice that the first page of google results are latency issues with World of Warcraft and Black Ops yet there are no other games mentioned.

So I dont exactly think this is a Blizzard or and ISP issue but a data centre issue within Equinix which I think would be up to blizzard to resolve as Blizzard is their customer.

But why is there a traffic jam at 3am? I can understand during prime time, but not late at night. Another question. I had traffic jam related issues with my ISP a few years back, during prime time, couldn’t play any games cause it would just spike, but the thing is, it always spiked. No matter what, the entire game was up and down, up and down. Start at 26, spike to 150, go down for a few seconds, spike up, spike down, nothing like what’s happening now.

Why does it spike in some HotS games I play and not others? How can I be in a 25 min game, where my ping doesn’t go below 150 (showing an OCE server with ctrl alt f), then the moment game ends, I requeue, and in under 5 mins I’m in a new game and my ping doesn’t go over 30? How did the traffic clear in that small amount of time but not the 25 min game? It isn’t a case of like, oh it just happened to disappear in that time. It’s a case of. The moment I get in the game, I’ll see myself go up to 150, play the 20 mins, play another, see I go to 25, stay there the entire game, play another, see myself go up to 150 and stay there.

This is for HotS and not OW. I’d ask in the HotS forums but here gets more responses.

Edit: On a good note, not a single bad game all night, 8 games, so thats nice.

I thought my issue was resolved on the weekend but first chance to play this week and it’s back. I appear to be getting correctly matched to the SYD servers repeatedly but the lag issue has returned (170 - 300+ ms) :frowning:

I Winmtr’d the server details from the server that it occurred on.

Is that still correct? i.e. 37.244.10.1 details at start of thread

iinet - Australia 8:30pm AEST

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.0.1 -    0 | 1356 | 1356 |    0 |    0 |    7 |    0 |
|                              172.22.0.1 -    1 | 1333 | 1327 |    3 |   25 |  441 |    5 |
|            be21-450.cr2.mel10.on.ii.net -    1 | 1333 | 1327 |    5 |   26 |  430 |    7 |
|                be51.cr2.mel11.on.ii.net -    1 | 1333 | 1327 |   14 |   37 |  446 |   18 |
|                 be55.cr3.syd2.on.ii.net -    1 | 1333 | 1327 |   15 |   37 |  443 |   19 |
|                 be50.cr2.syd2.on.ii.net -    1 | 1333 | 1327 |   14 |   36 |  445 |   16 |
|                 be51.cr2.syd7.on.ii.net -    1 | 1333 | 1327 |   15 |   37 |  445 |   18 |
|      syd-gls-har-wgw1-be-40.tpgi.com.au -    1 | 1333 | 1327 |   16 |   37 |  450 |   19 |
|  syd-gls-har-int1-hu0-3-0-3.tpgi.com.au -    1 | 1333 | 1327 |   16 |   41 |  454 |   18 |
|                  las-b24-link.telia.net -    1 | 1329 | 1322 |  159 |  184 |  591 |  160 |
|                  ash-bb4-link.telia.net -    1 | 1333 | 1327 |  214 |  237 |  642 |  219 |
|                  prs-bb3-link.telia.net -    1 | 1332 | 1326 |  303 |  324 |  735 |  307 |
|                   prs-b8-link.telia.net -    1 | 1333 | 1327 |  297 |  319 |  725 |  300 |
|   blizzard-ic-348624-prs-b8.c.telia.net -    1 | 1333 | 1327 |  299 |  323 |  730 |  302 |
|              ae1-br02-eqpa4.as57976.net -    1 | 1328 | 1321 |  304 |  344 |  849 |  308 |
|         et-0-0-3-br02-eqam1.as57976.net -    1 | 1330 | 1324 |  312 |  346 | 2520 |  317 |
|        et-0-0-67-pe01-eqam1.as57976.net -    1 | 1328 | 1321 |  334 |  359 |  761 |  338 |
|                           137.221.66.43 -    1 | 1332 | 1326 |  334 |  356 |  762 |  340 |
|                          185.60.114.151 -    1 | 1333 | 1327 |  305 |  327 |  734 |  308 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  271 |    0 |    0 |    0 |    0 |    0 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider