NA - Horrible Latency & ping spikes - Game unplayable

Technical Support
1

Finally throwing in the towel for this as I’ve hit my wits end for the disgusting amount of lag that is present in EVERY single game played since the last update was done to OW which seemed to introduce that Nvidia Reflex option, so it has been about 3 weeks of nothing but lag, disconnects, rubber-banding & full disconnects to the point I am not able to re-join the game once it allows the connection to Blizzard again for the login and I end up getting penalties and warnings like crazy for something completely out of my control…

I am no stranger to seeing network related issues with OW post-updates to the game and the way I optimize/secure my home network has me performing captures to determine which outbound traffic is not able to route through due to various policies and I make the necessary changes - I have done this since playing from day1 Launch Day of this game and I do the process for EVERYTHING else either game or non-gaming related, a very familiar and common process for me that is a rinse-repeat scenario these days.

I have noticed that every update seems to introduce more & more new servers along with new additional ports (sometimes) in to the mix that between the Blizzard Game Client exe, Overwatch exe & the Blizzard Agent exe there are dozens of different servers that are all being connected to & if ignored it also would seem that any one or combination of those other servers has enough importance to be able to severely impact the network performance while playing if their connection issue isn’t resolved…that is of course servers other than the main one that is connected to which is seen using ctrl+shift+n.

I read far too many of the troubleshooting posts here and they all seem to focus on a single endpoint for these issues, the IP from the ctrl+shift+n, and seem to avoid completely a large list of additional connections that are happening alongside the main server connection that do have a massive impact on how that game will perform. Depending on who’s in the game and where they are geographically located your PC will make and hold connections to Amazon Data Servers for that geographical region.
All the handles/names listed were from the IP search on arin to check registrar info/ownership & all of the connections were isolated to the 3 executables only that were listed previously.

I should note I am located in Western Canada as well.

A Small portion of Amazon servers that OW/Blizzard exe’s will connect out to:
Amazon Data Services Brazil ADSB-3, Singapore ADSS-3, Japan AMAZON-ASIA-SIN3, AMAZON-GRU Brazil, AMAZON-SIN Singapore - to just name a few as an example (There are countless others in my growing whitelist) and any issues with data routing between you and those servers will cause brutal disconnect/reconnect issues almost immediately after joining the game lobby for the duration of your playing with the individual that introduced the new server connection.

For another example of a subset of whitelisted addresses, there are countless connections to multiple addresses owned within the blocks for handles:
US-BLIZZARD1-20120416, GOOGL-2, GOOGLE-CLOUD, BLIZZARD ENTERTAINMENT - BLIZZA-3, BLIZZARD MNT-BLIZZARD, MNT-BLIZZARD Blizzard Peering Abuse BP5978-RIPE, MNT-BLIZZARD Blizzard Peering Abuse BPA18-RIPE, Amazon Technologies Inc. AMAZON-2011L, Amazon Technologies Inc. AT-88-Z (And sooooo many more but it would be far too much text to paste them all) and any issues with data routing between you and those servers will vary in response/severity for lag spikes, overall high ping & game disconnects.

Another important set of connections is out to the provider for the voice chat within OW, Vivox. These connections are particularly painful as issues connecting to any addresses located within any of the various VIVOX-BSN, Vivox, Inc, Vivox handles will cause crippling lag spikes whenever someone joins / leaves the game and eventually completely crater and cause the game to lock up every single time.

The above may be a lot of text but it could be 100x more if I went in to further detail and listed everything that has been compiled over the course of playing OW…I guess the overall point I am looking to make is that the game relies on many more connections and servers to function properly and lots of people seem to never get a resolution to their issues that are identical in every way to mine that I am now facing, and I’ve burned countless hours on this and have even done a 100% vanilla network setup with no rules, direct router connection with single endpoint device & nothing else connected or online - but yet face the exact same problem, for weeks now starting when the game was last updated - previous to that it was business as usual with no disconnect issues and a ping that always hovered around the 40ms-65ms range.

I am looking to see if there can be a resolution to this issue as I show 0 blocked/dropped connections when playing (For any of the 3 executables, both TCP & UDP were checked) & nothing at all is indicating a problem on my end and I have ruled out every possible scenario for hardware & firewall rules/policies during troubleshooting. Below is the WinMTR capture done during a match and as it shows there is very minimal loss of packets and the values are nothing alarming, but yet in-game it was 100% rubber-banding from start to finish and spikes so high it went to 700+ ping and would lock up for 4-5 seconds before going down and doing the fast-forward catch-up thing. The server it connected me to during that match was 24.105.10.90…Looking for some help on what to do next as finally out of fresh ideas.

`|------------------------------------------------------------------------------------------|

| WinMTR statistics |

Host - % Sent Recv Best Avrg Wrst Last
10 0 0 50 - 1 3951 3948 0 0 18 1
10 0 0 1 - 1 3889 3870 1 2 16 1
70 77 224 1 - 1 3861 3835 12 50 1613 20
rc3no-be123-1 cg shawcable net - 1 3880 3859 13 50 1394 18
rc2wt-be100 wa shawcable net - 1 3904 3889 28 65 1879 51
rc6wt-tge0-10-0-11 wa shawcable net - 1 3907 3893 28 72 1882 37
ae1-br01-eqse2 as57976 net - 1 3857 3830 57 102 1914 78
xe-0-0-0-1-br01-eqsv5 as57976 net - 1 3879 3858 57 100 1921 64
et-0-0-29-br02-eqsv5 as57976 net - 1 3884 3864 57 101 1790 61
xe-0-0-1-1-br02-eqla1 as57976 net - 1 3860 3834 54 102 1916 62
137 221 68 91 - 1 3880 3859 57 99 1919 66
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
No response from host - 100 793 0 0 0 0 0
________________________________________________ ______ ______ ______ ______ ______ ______
2

Not sure about 0% lost, as the first node in this line is showing a bit of loss. We never see all 3951 packets appear in the test again. Plus, the response times on those following Shaw nodes does suggest something is happening with them, and would explain ping times over 700ms. You might try PingPlotter and use UDP again instead of ICMP to see what kind of results happen and share them here?

3

Hi Nicole,

I can see the confusion with my statement for that, the 0 dropped connections was checked via the firewall logs to ensure there wasn’t any connections being blocked for any reason and every connection made via the OW and Blizzard executables was successful in getting out and back in again. I can definitely post another ping results but the packet loss shown being <1% for any of the nodes is not something I feel is much concern and that example of 3951 there was only 3 packets total that were lost throughout that entire time which would not be noticeable in any way for this. If those lost packets were from any connection that as done via lets say TCP then that lost packet would be re-sent as TCP protocol uses packet sequence numbers between source-destination nodes so nothing would be completely lost in this case. UDP being a stateless protocol is generally implemented with a threshold to provide a buffer to compensate for a % of packets lost and the amount seen during that capture in no way should have triggered any disconnects or multiple seconds of complete lag. As for the worst values for the pings, they always happened right at the very start, and just for a brief split second when as soon as I pressed start on the program to begin the pings and they never went back to those numbers again so they too are possibly a bit misleading.

Here was another test to 24.105.13.31 during a ~13 minute match. I experienced the same issues with constant spikes and no more than 20 seconds of what appeared to be normal play at any given moment throughout that match. The below results just don’t line up with what the game experience is & again I can’t see anything working against me that would be causing this.

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                               10.0.0.50 -    0 |  753 |  753 |    0 |    0 |    2 |    1 |
|                                10.0.0.1 -    0 |  750 |  750 |    1 |    1 |   25 |   2  |
|                             70.77.224.1 -    1 |  750 |  749 |   13 |   25 |  511 |   19 |
|          rc3no-be123-1.cg.shawcable.net -    1 |  750 |  749 |   12 |   28 |  428 |   20 |
|            rc2wt-be100.wa.shawcable.net -    0 |  753 |  753 |   29 |   48 |  495 |   38 |
|     rc6wt-tge0-10-0-11.wa.shawcable.net -    0 |  753 |  753 |   29 |   49 |  465 |   50 |
|              ae1-br01-eqse2.as57976.net -    1 |  750 |  749 |   58 |   76 |  457 |   60 |
|       xe-0-0-0-1-br01-eqsv5.as57976.net -    0 |  753 |  753 |   58 |   78 |  564 |   70 |
|        et-0-0-29-br02-eqsv5.as57976.net -    0 |  753 |  753 |   57 |   81 |  574 |   95 |
|        xe-0-0-1-1-br02-eqla1.as57976.net -    0 |  753 |  753 |   56 |   81 |  546 |  167 |
|                           137.221.68.93 -    0 |  753 |  753 |   57 |   80 |  535 |  107 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  151 |    0 |    0 |    0 |    0 |    0 |

|________________________________________________|______|______|______|______|______|______|
  WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider'
4

Hey there Enursha,

Looking this over, it definitely doesn’t seem like the problem shows in the new winMTR logs. The first ones were a bit more dicey looking but winMTR does have a tendency to throw bogus information in the first few pings of the test. That said, you mentioned you’re doing some pretty advanced firewall gymnastics. The vast majority of our players do not have any such problem regardless of the number of connections they’re running. Your router should be able to process the connections that we use with little difficulty assuming it’s configured correctly. Some of the things you mentioned are simply not the same experience as most players get. (For example, having performance issues when people join/leave voice channels isn’t normal.)

Did you mess with any Quality of Service or SIP ALG settings in your router? If so, can you disable both functions? Does the problem persist if you bypass your router and wire directly to your modem (assuming you have the option) or back up your firewall configuration then default the firewall temporarily?

5

Do these issues happen during high-volume hours? I.e. evenings and weekends when there are more players online? I’m having similar problems in Canada on the East Coast, see my thread and compare your issues with mine… They seem somewhat similar to me. My hypothesis is that the issues lie within the Equinix internet exchanges. Unfortunately Blizzard will not/cannot approach Equinix unless they get a high enough volume of reports from the same geographical area and ISP.

Here is a WinMTR result I ran for a while tonight. Shows the same pattern as you, which is that high latency begins at Equinix hops.

 |------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.4 -    0 | 4539 | 4539 |    0 |    0 |   28 |    0 |
|                             192.168.0.1 -    0 | 4538 | 4538 |    2 |   12 |  121 |   12 |
|                            10.128.208.1 -    0 | 4538 | 4538 |    7 |   11 |  111 |   12 |
|    host-24-139-20-42.public.eastlink.ca -    0 | 4538 | 4538 |    7 |   12 |  103 |   13 |
|            on-grmd-dr002.on.eastlink.ca -    1 | 4534 | 4533 |   14 |   19 |  132 |   17 |
|            on-grmd-br002.on.eastlink.ca -    1 | 4534 | 4533 |   15 |   20 |  116 |   22 |
|            on-bari-br001.on.eastlink.ca -    0 | 4538 | 4538 |   13 |   19 |  118 |   15 |
|                eqix-ix-ch1.blizzard.com -    0 | 4538 | 4538 |   28 |   49 |  156 |   29 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|         et-0-0-0-pe04-eqch2.as57976.net -    1 | 4523 | 4519 |   27 |  172 |  391 |  191 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |  909 |    0 |    0 |    0 |    0 |    0 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider

Here is another convenient sample that replicates your issues nicely…

|------------------------------------------------------------------------------------------|
|                                      WinMTR statistics                                   |
|                       Host              -   %  | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
|                             192.168.1.4 -    0 |  318 |  318 |    0 |    0 |    3 |    3 |
|                             192.168.0.1 -    0 |  318 |  318 |    2 |   14 |   55 |   13 |
|                            10.128.208.1 -    0 |  318 |  318 |    9 |   15 |   56 |   14 |
|    host-24-139-20-42.public.eastlink.ca -    0 |  318 |  318 |    9 |   15 |   63 |   15 |
|            on-grmd-dr002.on.eastlink.ca -    0 |  318 |  318 |   16 |   23 |   80 |   21 |
|            on-grmd-br002.on.eastlink.ca -    0 |  318 |  318 |   17 |   24 |   81 |   23 |
|            on-bari-br001.on.eastlink.ca -    0 |  318 |  318 |   15 |   21 |   72 |   16 |
|                eqix-ix-ch1.blizzard.com -    0 |  318 |  318 |   29 |   46 |  124 |   34 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|         et-0-0-0-pe04-eqch2.as57976.net -    0 |  318 |  318 |   34 |  148 |  342 |  146 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|                   No response from host -  100 |   64 |    0 |    0 |    0 |    0 |    0 |
|________________________________________________|______|______|______|______|______|______|
   WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
6

Hi There!

Thanks for taking the time to read and respond to my issue! I use a PFSense firewall that handles all my network & I have been using the setup I have now for a handful of years and only recently I began having this persistent and rather perplexing issue with OW and I have been playing OW since Launch Day. I block all unsolicited inbound connections (more or less standard for every firewall device) but I also block all Outbound connections as well which is where the “gymnastics” come in to play. I set up my rules for what can route outbound based on either just port, external IP & sometimes by LAN source. It has become rather easy to get new things working correctly using PFSense utilities that can easily log which ports and IP’s an app is attempting to use and in the case of anything Blizzard or OW related I will place allow rules to the entire external subnet from my gaming PC and for TCP ports will add to an alias list each port or port ranges required and for UDP it is right open from 10000-65535 to the subnets. I run a Snort IDS engine on the firewall that is not sitting “inline” for the scanning but rather creates copies of packets going inbound/outbound on the WAN interface and analyzes the copy for anything matching its heuristic/app/intrusion signature settings - but that is a separate process ran by the firewall and doesn’t interrupt the flow of packets or hinder them in any way.

I use Cloudflare encrypted DNS as my provider with all DNS queries being answered by the firewall from any devices on my LAN as the firewall is utilizing DNS resolver & forwarder features, but since this is not a DNS problem I’ll skip the rest of that - I did try going straight to a public DNS like googles 8.8.8.8 and ISP’s own servers but saw 0 difference.

That would be just about anything that would/could affect the flow of traffic for this particular situation so there is not too much advance networking in play when it comes to this PC.

I do not do anything with SIP ALG or QOS on this firewall (all those settings exist on another router in the LAN handling all wireless connections where the majority of other devices connect to first, my PC’s do not connect to that device are hardwired to the LAN switch)

I have no problems utilizing VOIP services and can use Telus RingCentral, Skype, MagicJack from my mobile that connects to the wireless router (Which is hardwired to the LAN switch) and can also use RingCentral, Skype, MagicJack from any of my hardwired PC’s without any issue. I am not using VLAN’s on my network and haven’t QOS’d anything or done any sort of priority routing/filtering of traffic.

From my troubleshooting process and to further my understanding of all components involved I found that whenever I purposely blocked anything that would connect to Vivox (whether it is port ranges it uses or IP’s within it’s block) and players would join/leave a game I could drastically manipulate the laggy behavior & re-enabling the allow functionality would then bring it back to normal behavior which was not seeing any latency change at all when others join/leave. This however is not the case anymore & with my block logs showing nothing and analyzing PC connections via netstat I can match the PC connections (UDP/TCP) to their connection within the allow logs on the firewall along with their traffic data count…So I do not appear to be missing any ports or IP’s but yet I still experience the same issue as if the behavior is being triggered by something elsewhere.

I have skipped my firewall completely and ran straight from modem to PC and yet I still experience these problems with almost no change whatsoever in gameplay. I had even disabled all AV & all Firewall features on the PC while connected directly to the modem as a quick last ditch effort to try and narrow it down but even still with absolutely no network firewall protection / any AV services I was getting my insane lag and disconnects.

I have tried from another PC on the network as well which proved no difference and it too showed the same signs as my main one.

Hey!
Looking at your results and yep, I do see some similarities for sure! I have also found other posts located on other forums for OW about people within Canada experiencing this type of issue and they too, unable to find any solution that is within their ability to control.
Time of day does not seem to be a factor (in my case at least) as the severity does not change whether it is 8am MST , noon MST, midnight MST or 2am MST.

7

I have deliberated in great detail with Blizzard about this through a support ticket. Despite every piece of evidence pointing to the fault being Blizzard’s, or one of their service providers (i.e. Equinix), responsibility, they have refused to investigate the issue further and can only recommend using a paid VPN service to circumvent the issue. The only method they have alluded to in which the result would be them investigating the problem is if enough “public discussion” around the issue exists. So, here I am. Best of luck, I look forward to continuing to monitor the thread.

1 Like
8

Western Canada here also. YYC. No problems with Telus. Potentially shaws new “Fiber+” which isn’t actually fiber but just is named fiber on the package? We tried it recently as we have like 140~ down 45~ up telus, and shaw introduced “fiber+” aka 300/500/750/1gb/1.5gb down, but all the packages are “up to 100mbps” upload, and we got a measily 13 up on their test here the other week so we sent them packing. Also shaw drops connection 247. Has 8-12+ hr downtimes multiple times a month. It would be no surprise to me if you’re in the same area and went with their new package and are realizing the big download, crap upload packages they offer that are unstable as all hell arent worth it vs telus’ “OK” down/up balanced packages. Makes me glad shaws test didnt go well, not only would i be on unstable internet I’d be on the worst traceroutes ever.