Wanted to post here to see if anyone else was having similar issues. Ran a tracert just now since getting random lag/disconnect spikes and here’s what I found (forgive the extra spaces - it wasn’t letting me post with “links”). Located in Southern California. Any thoughts?
Also wanted to note that I used Blizzard’s looking glass tool and it appears the issue is the Blizzard servers (specifically IP 137. 221 .83 . 84 → 1310.388 ms 1310.404 ms 1310.405 ms). Submitted tech support ticket with dxdiag, msinfo, and tracert files as they requested as well).
Tracing route to 137 .221 .105 .2 over a maximum of 30 hops
1 1 ms <1 ms <1 ms (masked IP)
2 10 ms 7 ms 8 ms (masked IP)
3 12 ms 10 ms 10 ms 100 . 120 . 106 . 138
4 11 ms 8 ms 11 ms 100 . 120 . 104 . 26
5 10 ms 17 ms 13 ms langbprj01-ae1 .rd .la .cox .net [68 .1 .1 .13]
6 9 ms 12 ms 9 ms 68.105.30.130
7 58 ms 210 ms 219 ms ae1-br01-eqla1 .as57976 .net [137 .221 .68 .33]
8 * * * Request timed out.
9 18 ms 14 ms 16 ms et-0-0-0-pe03-swlv10 .as57976. net [137 .221 .83 .85]
It appears there is significant latency at hop 7 to the router at 137.221.68.
If you’re referring to the timeout at hop 8 that’s very normal. Tracert works by sending a dummy UDP packet with the time-to-live (TTL) field in the IP header set to 1. Each router a packet passes through decrement the TTL field. If TTL reaches 0 it discards the packet and sends an ICMP Time Exceeded notification back to the sender. This is how tracert knows which router the packets are passing through. It then increments TTL by 1 and resends the packet so the second router can respond. Some routers are configured to not send ICMP packets due to security concerns, this causes tracert to report a timeout.
Ya that’s what I thought. Hopefully the support ticket sheds some light on what’s happening on blizzard’s end, as that 137.221.xxx.xx are their IP addresses.
That specific router is configured to give less priority to the test packets, so the responses are delayed. This makes it look like there’s high latency at the router, when in fact it’s operating normally and processing game traffic through it just fine.
If you check the latencies on the final 2 hops you’ll see those are nice and low. If that previous router were really having an issue causing high latency then the problem would persist down to the final hops as well. So this lets us know that the high latency shown there is not an issue.
Slashco I would try leaving the WinMTR running in the background while you play and see if you can capture the disconnect happening. There can be cases where disconnects or lag spikes don’t show up in connection tests, but if you can capture it we can at least check it out to see if any issues show up.