I am having major packet loss issues with a "peering partner" of Cox.net while trying to reach 24.105.30.129. The issue is mainly with xe-5-1-0.edge5.Dallas3.Level3.net and what seems like ae-5.r01.dllstx04.us.bb.gin.ntt.net. I will preempt the "have you tried power cycling" your device replies with yes. I have tested everything, changed cables, had the modem directly into my computer, ipconfig /flush DNS, ect ect. This is a typical test I will run and what shows the packet loss and where. |------------------------------------------------------------------------------------------|| WinMTR statistics || Host - % | Sent | Recv | Best | Avrg | Wrst | Last ||------------------------------------------------|------|------|------|------|------|------|| 192.168.1.1 - 0 | 338 | 338 | 0 | 0 | 1 | 0 || 10.49.208.1 - 0 | 338 | 338 | 6 | 8 | 17 | 8 || 100.122.224.234 - 0 | 338 | 338 | 7 | 9 | 20 | 8 || 100.122.224.174 - 0 | 338 | 338 | 7 | 12 | 45 | 11 || dalsbprj02-ae2.0.rd.dl.cox.net - 0 | 338 | 338 | 19 | 30 | 97 | 20 || xe-5-1-0.edge5.Dallas3.Level3.net - 0 | 338 | 338 | 19 | 34 | 53 | 46 || ae-5.r01.dllstx04.us.bb.gin.ntt.net - 52 | 110 | 53 | 0 | 46 | 51 | 45 || ae-0.att.dllstx04.us.bb.gin.ntt.net - 0 | 338 | 338 | 46 | 53 | 63 | 51 || cr2.la2ca.ip.att.net - 0 | 338 | 338 | 53 | 63 | 75 | 60 || 12.122.2.82 - 0 | 338 | 338 | 53 | 67 | 208 | 68 || 12-122-254-238.attens.net - 0 | 338 | 338 | 54 | 72 | 258 | 68 || mdf001c7613r0002.lax1.attens.net - 1 | 330 | 328 | 54 | 72 | 432 | 55 || mdf001c7613r0002.lax1.attens.net - 47 | 119 | 64 | 64 | 77 | 199 | 66 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 || No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 ||________________________________________________|______|______|______|______|______|______| This issue is very troubling for me and others, who from what it seems to be they do not even realize where the problem is happening. As paying a customer of Cox I have no way to contact this Level3.net and or NTT.net. From what I understand Cox pays money to these peering partners to connect to the rest of the internet. How does this get fixed?

@matt850 Looking at the results you've shared it appears what you're seeing at Level 3/NTT is actually ICMP de-prioritization and not loss. I'm more curious about what's going on at the last 2 hops before the replies stop. In order to understand if ICMP de-prioritization is occurring one must look past the hop in question to see what's really happening which appears to be blocked on Blizzard's end.

It also sounds like the peering issue is closer to Blizzard's side - in that case you might get more traction pursuing it on that side of the connection. It appears to be the 12.x.x.x/8 and the *.attens.ent that are showing the >100ms connection times. There is also the fact that the mdf001c7613r0002.lax1.attens.net is mentioned twice, that appears to be an edge router/firewall. It might be dropping the packets due to prioritization as well, plus adding a bit of latency. There is a drop between Level3.net and ntt.net, but it only seems to be responses from that jump versus pass-through, which would support a prioritization of pass-through versus direct response (the mentioned ICMP de-prioritization) see here for a FAQ: http://www.dslreports.com/faq/16203 - specifically: "This is what you are seeing when you do a traceroute and one hop is showing loss or high latency while the next is just fine. You can tell it is just a case of the host in question taking its time to respond because if there was real packet loss that host would impact all the other hops because it sits between you and them."

Tracing route to 24.105.30.129 on port 80Over a maximum of 30 hops.1 1 ms 0 ms 0 ms 192.168.1.1 2 9 ms 6 ms 9 ms 10.49.208.1 3 9 ms 14 ms 7 ms 100.122.224.234 4 9 ms 15 ms 12 ms 100.122.224.172 5 21 ms 28 ms 23 ms 68.1.2.121 [dalsbprj02-ae2.0.rd.dl.cox.net]6 48 ms 22 ms 22 ms 4.59.32.93 [xe-5-1-0.edge5.Dallas3.Level3.net]7 39 ms * 28 ms 129.250.3.233 [ae-5.r01.dllstx04.us.bb.gin.ntt.net]8 58 ms 58 ms 52 ms 129.250.8.238 [ae-0.att.dllstx04.us.bb.gin.ntt.net]9 57 ms 57 ms 57 ms 12.123.16.78 [cr2.dlstx.ip.att.net]10 54 ms 67 ms 60 ms 12.122.2.82 11 62 ms 91 ms 68 ms 12.123.132.209 12 57 ms 61 ms 54 ms 206.16.68.42 13 60 ms 58 ms * 206.16.68.42 14 * * * Request timed out.15 * * * Request timed out.16 * * * Request timed out.17 * * * Request timed out.18 * * * Request timed out.19 * * * Request timed out.20 * * * Request timed out.21 * * * Request timed out.22 * * * Request timed out.23 * * * Request timed out.24 * * * Request timed out.25 * * * Request timed out.26 * * * Request timed out.27 * * * Request timed out.28 * * * Request timed out.29 * * * Request timed out.30 * * * Request timed out.Trace Complete. I have started using Tracetcp with WinPcap. I have run over 20 tests using various ports other than 80. Which I do not even know if that is the best one to use because it is just for HTTP traffic from what I understand. The research I did came to show that this method should get around the ICMP de-prioritization issues. All of the tests show issue at: [ae-5.r01.dllstx04.us.bb.gin.ntt.net] The completely unhelpful "tech" support people at Cox only bring mention to the lack of degradation of my ping before and after the hop. I suppose that can be argued but I do not know any other tests to do to show where the problem is. The truth that is clear to me is that for me and over several dozen other Cox internet users in Northwest Arkansas are experiencing instances of lag / delay while playing Hearthstone and other Blizzard games. For some of us we have set up a hotspot from our LTE phones and connected our computer and experiences 0 lag while in game. The hours I have spent with Cox and Blizzard Tech support have been completely unhelpful. The tech support at Blizzard said they would at least make an attempt to contact some of these peering partners but they let me know there would be little to expect as they are not peering partners of theirs. The Cox Tech support keeps out right refusing to help in this. They are refusing to make any contact with the Level3 or NTT.net peering partners to see if there is an issue. "There's no reason you can't use your connection for online gaming however assistance for this is not provided by us. We would have to defer to the game providers technical support for assistance with gaming specific issues.:" The gaming provider in this case has no control on where my connection is routed while on its way to them. So this just leaves me at the mercy of Cox to try and care.

Let me see if I can get a hi-level view of the situation. Cox connects to Level3 (Backbone provider) (That is the peering that Cox has control over) Level3 connects to NTT (Nippon telephone and telegraph?) NTT connects to AT&T AT&T connects to blizzard datacenter According to your conclusions the problem exists between NTT and Level3, or NTT and AT&T The problem with your conclusion is #1 - there is no problem before or after that hop, if that hop was dropping packets you would see problems downstream. Dallas, Texas is the location of Blizzard's servers - so they need to escalate to their peering with the backbone (Level3). If the problem was occurring BEFORE Level3, then it's on Cox - after Level3 it's on the other side of the internet so-to-speak. This wouldn't be the first time Blizzard had issues with their peering - and cox can only control the route into the backbone, not out of it.

Well actually this evening I have been noticing something odd going on where Cox is connecting to ntt.net and level3 dropped out of the picture for a bit. |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 192.168.1.1 - 0 | 419 | 419 | 0 | 0 | 1 | 0 | | 10.49.208.1 - 0 | 419 | 419 | 6 | 9 | 15 | 9 | | 100.122.224.236 - 0 | 419 | 419 | 6 | 9 | 16 | 12 | | 100.122.224.172 - 0 | 419 | 419 | 7 | 12 | 85 | 11 | | dalsbprj01-ae1.0.rd.dl.cox.net - 0 | 419 | 419 | 18 | 25 | 105 | 27 | | ae-12.r08.dllstx09.us.bb.gin.ntt.net - 0 | 419 | 419 | 19 | 29 | 56 | 39 | | ae-5.r01.dllstx04.us.bb.gin.ntt.net - 49 | 142 | 73 | 27 | 29 | 38 | 28 | | 192.205.37.145 - 0 | 419 | 419 | 27 | 48 | 71 | 64 | | cr2.la2ca.ip.att.net - 0 | 419 | 419 | 58 | 62 | 69 | 60 | | gar29.la2ca.ip.att.net - 0 | 419 | 419 | 58 | 67 | 235 | 59 | | gar29.la2ca.ip.att.net - 0 | 419 | 419 | 57 | 70 | 408 | 61 | | mdf001c7613r0002.lax1.attens.net - 0 | 419 | 419 | 59 | 73 | 409 | 64 | | mdf001c7613r0002.lax1.attens.net - 50 | 139 | 70 | 0 | 65 | 207 | 59 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | | No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 | |________________________________________________|______|______|______|______|______|______| WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider In this case I guess it is ntt.net with ntt.net? The issue is the problem of lag and delays that I am having in a Blizzard game. From what I have been monitoring while Level3 disappeared earlier I had 0% packet loss showing in winMTR and I had no delay in the game. Then Level3 showed back up, with packet loss showing and the delay / lag returned. In winMTR it showed 0% packet loss before and after the Level3. So for whatever reason when winMTR shows packet loss either at a Level3 or a NTT.net it is a good indication that something is wrong. So the argument about no problem before or after a hop is sound I guess but for when I notice it with a 100% correlation of when I am also having issues then that is what I am using for my conclusion.

Peering Partners | Cox Community

12 Replies

Replies have been turned off for this discussion

ChrisL
Former Moderator
@matt850

Looking at the results you've shared it appears what you're seeing at Level 3/NTT is actually ICMP de-prioritization and not loss. I'm more curious about what's going on at the last 2 hops before the replies stop. In order to understand if ICMP de-prioritization is occurring one must look past the hop in question to see what's really happening which appears to be blocked on Blizzard's end.
grymwulf
Contributor II
It also sounds like the peering issue is closer to Blizzard's side - in that case you might get more traction pursuing it on that side of the connection. It appears to be the 12.x.x.x/8 and the *.attens.ent that are showing the >100ms connection times. There is also the fact that the mdf001c7613r0002.lax1.attens.net is mentioned twice, that appears to be an edge router/firewall. It might be dropping the packets due to prioritization as well, plus adding a bit of latency.

There is a drop between Level3.net and ntt.net, but it only seems to be responses from that jump versus pass-through, which would support a prioritization of pass-through versus direct response (the mentioned ICMP de-prioritization) see here for a FAQ: http://www.dslreports.com/faq/16203 - specifically: "This is what you are seeing when you do a traceroute and one hop is showing loss or high latency while the next is just fine. You can tell it is just a case of the host in question taking its time to respond because if there was real packet loss that host would impact all the other hops because it sits between you and them."
matt850
New Contributor

Tracing route to 24.105.30.129 on port 80
Over a maximum of 30 hops.
1 1 ms 0 ms 0 ms 192.168.1.1
2 9 ms 6 ms 9 ms 10.49.208.1
3 9 ms 14 ms 7 ms 100.122.224.234
4 9 ms 15 ms 12 ms 100.122.224.172
5 21 ms 28 ms 23 ms 68.1.2.121 [dalsbprj02-ae2.0.rd.dl.cox.net]
6 48 ms 22 ms 22 ms 4.59.32.93 [xe-5-1-0.edge5.Dallas3.Level3.net]
7 39 ms * 28 ms 129.250.3.233 [ae-5.r01.dllstx04.us.bb.gin.ntt.net]
8 58 ms 58 ms 52 ms 129.250.8.238 [ae-0.att.dllstx04.us.bb.gin.ntt.net]
9 57 ms 57 ms 57 ms 12.123.16.78 [cr2.dlstx.ip.att.net]
10 54 ms 67 ms 60 ms 12.122.2.82
11 62 ms 91 ms 68 ms 12.123.132.209
12 57 ms 61 ms 54 ms 206.16.68.42
13 60 ms 58 ms * 206.16.68.42
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace Complete.

I have started using Tracetcp with WinPcap. I have run over 20 tests using various ports other than 80. Which I do not even know if that is the best one to use because it is just for HTTP traffic from what I understand. The research I did came to show that this method should get around the ICMP de-prioritization issues. All of the tests show issue at:

[ae-5.r01.dllstx04.us.bb.gin.ntt.net]

The completely unhelpful "tech" support people at Cox only bring mention to the lack of degradation of my ping before and after the hop. I suppose that can be argued but I do not know any other tests to do to show where the problem is.

The truth that is clear to me is that for me and over several dozen other Cox internet users in Northwest Arkansas are experiencing instances of lag / delay while playing Hearthstone and other Blizzard games. For some of us we have set up a hotspot from our LTE phones and connected our computer and experiences 0 lag while in game.

The hours I have spent with Cox and Blizzard Tech support have been completely unhelpful. The tech support at Blizzard said they would at least make an attempt to contact some of these peering partners but they let me know there would be little to expect as they are not peering partners of theirs. The Cox Tech support keeps out right refusing to help in this. They are refusing to make any contact with the Level3 or NTT.net peering partners to see if there is an issue.

"There's no reason you can't use your connection for online gaming however assistance for this is not provided by us. We would have to defer to the game providers technical support for assistance with gaming specific issues.:"

The gaming provider in this case has no control on where my connection is routed while on its way to them. So this just leaves me at the mercy of Cox to try and care.
grymwulf
Contributor II
Let me see if I can get a hi-level view of the situation.

Cox connects to Level3 (Backbone provider) (That is the peering that Cox has control over)

Level3 connects to NTT (Nippon telephone and telegraph?)

NTT connects to AT&T

AT&T connects to blizzard datacenter

According to your conclusions the problem exists between NTT and Level3, or NTT and AT&T

The problem with your conclusion is #1 - there is no problem before or after that hop, if that hop was dropping packets you would see problems downstream.

Dallas, Texas is the location of Blizzard's servers - so they need to escalate to their peering with the backbone (Level3). If the problem was occurring BEFORE Level3, then it's on Cox - after Level3 it's on the other side of the internet so-to-speak. This wouldn't be the first time Blizzard had issues with their peering - and cox can only control the route into the backbone, not out of it.
matt850
New Contributor
Well actually this evening I have been noticing something odd going on where Cox is connecting to ntt.net and level3 dropped out of the picture for a bit.

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 419 | 419 | 0 | 0 | 1 | 0 |
| 10.49.208.1 - 0 | 419 | 419 | 6 | 9 | 15 | 9 |
| 100.122.224.236 - 0 | 419 | 419 | 6 | 9 | 16 | 12 |
| 100.122.224.172 - 0 | 419 | 419 | 7 | 12 | 85 | 11 |
| dalsbprj01-ae1.0.rd.dl.cox.net - 0 | 419 | 419 | 18 | 25 | 105 | 27 |
| ae-12.r08.dllstx09.us.bb.gin.ntt.net - 0 | 419 | 419 | 19 | 29 | 56 | 39 |
| ae-5.r01.dllstx04.us.bb.gin.ntt.net - 49 | 142 | 73 | 27 | 29 | 38 | 28 |
| 192.205.37.145 - 0 | 419 | 419 | 27 | 48 | 71 | 64 |
| cr2.la2ca.ip.att.net - 0 | 419 | 419 | 58 | 62 | 69 | 60 |
| gar29.la2ca.ip.att.net - 0 | 419 | 419 | 58 | 67 | 235 | 59 |
| gar29.la2ca.ip.att.net - 0 | 419 | 419 | 57 | 70 | 408 | 61 |
| mdf001c7613r0002.lax1.attens.net - 0 | 419 | 419 | 59 | 73 | 409 | 64 |
| mdf001c7613r0002.lax1.attens.net - 50 | 139 | 70 | 0 | 65 | 207 | 59 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

In this case I guess it is ntt.net with ntt.net?

The issue is the problem of lag and delays that I am having in a Blizzard game. From what I have been monitoring while Level3 disappeared earlier I had 0% packet loss showing in winMTR and I had no delay in the game. Then Level3 showed back up, with packet loss showing and the delay / lag returned. In winMTR it showed 0% packet loss before and after the Level3. So for whatever reason when winMTR shows packet loss either at a Level3 or a NTT.net it is a good indication that something is wrong.

So the argument about no problem before or after a hop is sound I guess but for when I notice it with a 100% correlation of when I am also having issues then that is what I am using for my conclusion.
ChrisL
Former Moderator
@matt850

I think you may be trying to find a problem where one doesn't exist. Based on the results you've posted I'd suggest contacting Blizzard and seeing what is going on here. See my highlights below for areas of concern:

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 338 | 338 | 0 | 0 | 1 | 0 |
| 10.49.208.1 - 0 | 338 | 338 | 6 | 8 | 17 | 8 |
| 100.122.224.234 - 0 | 338 | 338 | 7 | 9 | 20 | 8 |
| 100.122.224.174 - 0 | 338 | 338 | 7 | 12 | 45 | 11 |
| dalsbprj02-ae2.0.rd.dl.cox.net - 0 | 338 | 338 | 19 | 30 | 97 | 20 |
| xe-5-1-0.edge5.Dallas3.Level3.net - 0 | 338 | 338 | 19 | 34 | 53 | 46 |
| ae-5.r01.dllstx04.us.bb.gin.ntt.net - 52 | 110 | 53 | 0 | 46 | 51 | 45 |
| ae-0.att.dllstx04.us.bb.gin.ntt.net - 0 | 338 | 338 | 46 | 53 | 63 | 51 |
| cr2.la2ca.ip.att.net - 0 | 338 | 338 | 53 | 63 | 75 | 60 |
| 12.122.2.82 - 0 | 338 | 338 | 53 | 67 | 208 | 68 |
| 12-122-254-238.attens.net - 0 | 338 | 338 | 54 | 72 | 258 | 68 |
| mdf001c7613r0002.lax1.attens.net - 1 | 330 | 328 | 54 | 72 | 432 | 55 |
| mdf001c7613r0002.lax1.attens.net - 47 | 119 | 64 | 64 | 77 | 199 | 66 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 67 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|

Tracing route to 24.105.30.129 on port 80
Over a maximum of 30 hops.
1 1 ms 0 ms 0 ms 192.168.1.1
2 9 ms 6 ms 9 ms 10.49.208.1
3 9 ms 14 ms 7 ms 100.122.224.234
4 9 ms 15 ms 12 ms 100.122.224.172
5 21 ms 28 ms 23 ms 68.1.2.121 [dalsbprj02-ae2.0.rd.dl.cox.net]
6 48 ms 22 ms 22 ms 4.59.32.93 [xe-5-1-0.edge5.Dallas3.Level3.net]
7 39 ms * 28 ms 129.250.3.233 [ae-5.r01.dllstx04.us.bb.gin.ntt.net]
8 58 ms 58 ms 52 ms 129.250.8.238 [ae-0.att.dllstx04.us.bb.gin.ntt.net]
9 57 ms 57 ms 57 ms 12.123.16.78 [cr2.dlstx.ip.att.net]
10 54 ms 67 ms 60 ms 12.122.2.82
11 62 ms 91 ms 68 ms 12.123.132.209
12 57 ms 61 ms 54 ms 206.16.68.42
13 60 ms 58 ms * 206.16.68.42
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 * * * Request timed out.
23 * * * Request timed out.
24 * * * Request timed out.
25 * * * Request timed out.
26 * * * Request timed out.
27 * * * Request timed out.
28 * * * Request timed out.
29 * * * Request timed out.
30 * * * Request timed out.
Trace Complete.

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 419 | 419 | 0 | 0 | 1 | 0 |
| 10.49.208.1 - 0 | 419 | 419 | 6 | 9 | 15 | 9 |
| 100.122.224.236 - 0 | 419 | 419 | 6 | 9 | 16 | 12 |
| 100.122.224.172 - 0 | 419 | 419 | 7 | 12 | 85 | 11 |
| dalsbprj01-ae1.0.rd.dl.cox.net - 0 | 419 | 419 | 18 | 25 | 105 | 27 |
| ae-12.r08.dllstx09.us.bb.gin.ntt.net - 0 | 419 | 419 | 19 | 29 | 56 | 39 |
| ae-5.r01.dllstx04.us.bb.gin.ntt.net - 49 | 142 | 73 | 27 | 29 | 38 | 28 |
| 192.205.37.145 - 0 | 419 | 419 | 27 | 48 | 71 | 64 |
| cr2.la2ca.ip.att.net - 0 | 419 | 419 | 58 | 62 | 69 | 60 |
| gar29.la2ca.ip.att.net - 0 | 419 | 419 | 58 | 67 | 235 | 59 |
| gar29.la2ca.ip.att.net - 0 | 419 | 419 | 57 | 70 | 408 | 61 |
| mdf001c7613r0002.lax1.attens.net - 0 | 419 | 419 | 59 | 73 | 409 | 64 |
| mdf001c7613r0002.lax1.attens.net - 50 | 139 | 70 | 0 | 65 | 207 | 59 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 83 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|

Why is the traffic highlighted in red taking you in circles within Blizzard's network?
matt850
New Contributor
Yes. I have contacted Blizzard several times and hit dead ends every time. This is the same experience I have got with Cox tech support as well. I may have mentioned this before but what is interesting is some times when:

xe-5-1-0.edge5.Dallas3.Level3.net

disappears like below, I have no issues in Hearthstone (24.105.30.129).

|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 19 | 19 | 0 | 0 | 0 | 0 |
| 10.49.208.1 - 0 | 19 | 19 | 6 | 9 | 11 | 11 |
| 100.122.224.236 - 0 | 19 | 19 | 9 | 10 | 12 | 10 |
| 100.122.224.174 - 0 | 19 | 19 | 9 | 12 | 16 | 15 |
| dalsbprj01-ae1.0.rd.dl.cox.net - 0 | 19 | 19 | 71 | 73 | 75 | 73 |
| ae-12.r08.dllstx09.us.bb.gin.ntt.net - 0 | 19 | 19 | 70 | 72 | 75 | 74 |
| ae-5.r01.dllstx04.us.bb.gin.ntt.net - 0 | 19 | 19 | 70 | 72 | 75 | 74 |
| ae-0.att.dllstx04.us.bb.gin.ntt.net - 0 | 19 | 19 | 70 | 75 | 79 | 79 |
| cr2.dlstx.ip.att.net - 0 | 19 | 19 | 104 | 109 | 120 | 108 |
| 12.122.2.82 - 0 | 19 | 19 | 106 | 110 | 120 | 108 |
| gar29.la2ca.ip.att.net - 0 | 19 | 19 | 104 | 112 | 143 | 107 |
| 12-122-254-238.attens.net - 0 | 19 | 19 | 105 | 109 | 119 | 108 |
| mdf001c7613r0002.lax1.attens.net - 0 | 19 | 19 | 107 | 110 | 124 | 109 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 3 | 0 | 0 | 0 | 0 | 0 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

I am not sure about the statement that there is not a problem. I not a network engineer or anything but I just keep monitoring when I have issues and have draw correlations from what I am recording logs of.
Becky
Moderator
Hi Matt,

Have you provided trace route data to Blizzard Support? I think ChrisL and Grymwulf have provided valid points and analysis. Is Blizzard able to explain what's happening in the last 2 hops before the replies stop?
appleaddct
New Contributor
I'm definitely having issues with Level3 as well.
ChrisL
Former Moderator
@appleaddct

Looking at the results you've posted I'd say the problem is likely much closer to home as the loss appears to be starting between the router and our gateway. Can you bypass the router and try that test again?